Repository navigation
Conversation
inavflight/inav to kijan007/innav master update
merge master
Contributor
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
Branch Targeting SuggestionYou've targeted the
If This is an automated suggestion to help route contributions to the appropriate branch. |
|
Test firmware build ready — commit Download firmware for PR #11658 252 targets built. Find your board's
|
sensei-hacker
added
the
hardware needed
Added targetr for ATOMRC F405 NAVI MINI with blackbox flash storage
Member
|
Hello. Are you a representative of the manufacturer? |
…msp-wind feat(msp): add MSP2_INAV_WIND (0x2231) to expose wind estimator
…reement check_conditions() deferred every #if defined(MACRO) condition check to the end of one combined probe file, after all group headers were already included, so it saw a macro as "on" if defined anywhere regardless of order. resolve_types() instead probes a struct field access, which is governed by that struct's own header's #ifdef guard evaluated at its actual position in the same header sequence. When a macro was only defined by a header appearing later than the struct needing it, the two functions could disagree, crashing settings generation. Interleave each group's headers with that group's own condition checks in one pass, so check_conditions() evaluates macro visibility at the same in-order position resolve_types() implicitly relies on.
…tring check_conditions() deduped its probes by condition string, so a condition was only ever checked once, at whichever group/member first used it. Since the probe's truth is now position-dependent (per the previous commit), the same condition string appearing on a later group at a different header- inclusion position would silently reuse the earlier, possibly-wrong result instead of being re-evaluated for its own position. Several real conditions in settings.yaml (USE_ADC, USE_BARO, USE_PITOT, ...) are reused across multiple groups, so this was live, not theoretical. Fixed by tagging each group/member occurrence with its own unique probe and storing the resolved boolean directly on that object, so occurrences of the same condition string at different positions are evaluated independently. Verified with a synthetic fixture reproducing the same condition string on two groups straddling the header that defines it: the earlier group now correctly resolves false and the later group true, where both previously resolved to the same (wrong, for one of them) value. Confirmed byte- identical generated settings_generated.h/.c for MATEKF722PX and the maths/time/msp_refactor unit-test targets, and the same 57/58 unit test pass rate as before (one pre-existing, unrelated failure).
…b-ordering-bug Fix settings.rb check_conditions()/resolve_types() header-order disagreement
getEstimatedHorizontalWindSpeed() was called unconditionally, so once
the wind estimate becomes invalid (e.g. the 15-minute stationary-altitude
timeout in wind_estimator.c), MSP2_INAV_WIND kept sending the last
computed windSpeed/windAngle instead of zero. estimatedWind[] is never
reset when hasValidWindEstimate clears, only the flags byte reflected
validity. This contradicted the message's own documentation ("returns
zeroes when wind estimation is not compiled in or not yet valid") and
diverged from every other consumer of this API (gps.c, osd.c,
rth_estimator.c, navigation.c, imu.c, mavlink_streams.c,
logic_condition.c, pitotmeter.c), all of which check
isEstimatedWindSpeedValid() before reading the value rather than relying
on the estimator to self-zero.
Reported by Qodo's automated review on PR iNavFlight#11761 (a release/9.1 ->
maintenance-10.x merge that carried this pre-existing bug forward,
unrelated to that merge itself). Fixed at the source (release/9.1) so it
flows forward on the next maintenance-10.x sync.
…wind-zero-on-invalid Fix MSP2_INAV_WIND returning stale non-zero values when invalid
Member
|
Just an FYI for contributors: The tentative schedule for INAV 10 is to have a full release in mid December. That means RC2 needs to be in early to mid November, which places INAV 10.0RC1 at September 1. Please plan to have any new features for INAV 10.0 ready for RC1 no later than September 1. After that, 10.1 will follow about six to seven months later. |
Removing HD_3016 from the enum in commit 7ec7f0d (PR iNavFlight#10540) shifted every later member's implicit ordinal down by one, so currentOsdMode now sends HD_6022 as wire value 2 instead of 3. WTFOS goggles/VTX firmware hardcodes 3 for its 60x22 mode, so the OSD canvas renders shifted. Fixes iNavFlight#11764
Keep the published protocol reference in sync with the corrected wire values for resolutionType_e.
Run the actual generator instead of hand-editing, so the docs match gen_docs.sh output exactly and pick up other enums that had drifted since these files were last regenerated.
…nique Stub only -- captures the buffer-decoupling and shrink-audit technique from the MSP tunnel reply buffer fix before it's lost, ahead of the tracked document-ram-flash-optimization-practices project writing the full guide and linking it from Development.md.
Surfaces RAM/flash regressions and creep on every PR instead of only via a hard CI failure (motivated by PR iNavFlight#11718's terrain-cache RAM overflow, which was only caught because CI happened to fail on that specific board). Extracts flash/RAM usage from each build's .elf right after compiling (no second build of the base branch), persists a baseline per branch as a release asset in the pr-test-builds companion repo, and diffs 4 representative targets (one per MCU family) against it on PR builds.
Several steps spliced \${{ }} expressions directly into run: script text
instead of passing them through env: — including one value (base_ref) that
round-trips through an artifact from a less-trusted PR build before being
used to construct a release tag. Route all of them through env: and
validate base_ref against safe git-ref characters before use.
Increased the noise threshold from 32 to 256 bytes to filter out minor changes.
…-noise Size diff comment noise
do/while with a decrementing post-condition ran 6 WHO_AM_I attempts instead of 5, adding an extra 150ms delay on the chip-absent boot autodetect path. Replaced with a plain for loop, matching the fix already applied to accgyro_icm40609d.c (66247db), which was modeled on this file.
…rence Replace the PR iNavFlight#11718 seed stub with the full strategy guide. Each technique is stated as a rule with a short example rather than a per-PR anecdote. Reconciles the two previously-contradictory sections on static-in-header linkage: the rule is to be wary of `static` in a header (private copy per including TU, prefer extern + one .c definition), with the exception that pure, stateless static-inline functions are safe while the compiler inlines or discards them.
…-optimization-91 docs: expand RAM/flash optimization guide, rewrite as rule-first reference
Release/9.1 to master
…etry-loop-off-by-one Fix off-by-one in ICM42605 WHO_AM_I retry loop
…term-threshold-orphan Remove orphaned servo_autotrim_iterm_threshold field
Member
The size-diff workflow stored one baseline per branch, clobbered on every push, so PRs were compared against the base branch's LATEST tip. When the base advances after a PR forks, the delta includes unrelated changes (PR iNavFlight#11785 showed a stale +9,788 B RAM figure that actually belonged to iNavFlight#11438; the PR's real marginal RAM was ~120 B). Publish per-commit baselines alongside the branch-tip pointer: - publish-baseline now stores size-baseline-<COMMIT_SHA> (primary) in addition to size-baseline-<BRANCH> (backward-compat latest-tip pointer), and prunes per-commit baselines to the newest 50 per branch (plus a global cap) so iNavFlight/pr-test-builds can't grow unbounded. Per-commit releases carry a machine-readable branch marker in their notes so pruning can group them. Resolve the PR's true base commit on the comparison side: - pr-comment computes the merge-base of PR head and base ref via the compare API (verified to resolve fork-PR head SHAs), fetches the exact per-commit baseline, and falls back to the nearest ancestor commit that has one by walking the base branch's first-parent chain. The branch-tip baseline is deliberately NOT a fallback — comparing against it is the stale-delta bug this fixes. All new SHA/ref inputs are regex-validated before use in shell commands or release tags. - The comment header now names the baseline commit used ("vs. base commit `abcd123`"), with a note when a nearest-available baseline was used; the graceful "no size baseline available" path is unchanged. Also fixes two pre-existing size-diff-comment tests whose notable-delta expectations predated NOISE_THRESHOLD_BYTES being raised to 256.
Pruning is housekeeping after the baseline publish; a prune failure must not fail the nightly publish job (the baseline itself already landed). Warn loudly instead.
…, header consistency - publish-size-baseline: jq capture of the notes' `branch:` line needed the (?m) flag — without it, ^/$ anchored to the whole (multi-line) string, the capture never matched, and every per-commit baseline collapsed into the '?' bucket, so pruning treated all branches as one and deleted every baseline of the less-active branches (destructive data loss). Pruning now also tracks an explicit set of all tags instead of relying on awk's create-on-reference side effect. - fetch-size-baseline: the exact merge-base baseline is now retried as the first step of the ancestor walk, so a transient download failure on the exact commit degrades to a nearest-ancestor baseline instead of skipping the exact commit for that run. - size-diff-comment: only name the baseline commit in the header when a baseline report actually exists (no contradictory header), and reword the no-baseline note for accuracy during rollout (pre-existing PRs' merge-bases never advance; rebase refreshes them).
…ine-commit-matching Fix size-diff baseline comparison: compare against the PR's merge-base commit, not the branch tip
Release/9.1 to master
The publish-baseline job in ci-size-report.yml called .github/scripts/publish-size-baseline.sh without an actions/checkout step, so the runner workspace was empty and the script invocation failed with exit 127. No per-commit baselines were ever published, and every PR's size-diff comment reported "no size baseline is available yet". Add the checkout as the job's first step, and add explicit reminders in the workflow, the two size-baseline scripts, and the workflow README that repo scripts must never be called from a job that has not checked out a known branch first.
The job now checks out the repo (to run .github/scripts from the workspace), so declare the contents: read that checkout needs, matching the sibling pr-comment job in the same file.
…ine-publish-checkout Fix size-baseline publishing: check out repo before calling scripts
Rebuild of PR iNavFlight#11827's content change on a clean branch based off release/9.1, preserving exactly the branch's file delta (+45/-2): - Correct the WS2812 DMA buffer figures: the element type is timerDMASafeType_t (uint32_t) on every F4/F7/H7/AT32 family since 2019, so the full 3,115-element buffer is 12,460 B and the 2x4-LED circular design is 768 B, not the previously stated 6,230 B / 384 B. The >16x reduction ratio is unchanged. - Add three generalizable RAM techniques from the PR iNavFlight#11785 (terrain AGL hold) review: budget speculative cache reads against the shared cache's size (lookahead capped at (CACHE_SIZE - 3) * 540 m plus a time horizon); consume an existing cache in place, never a private copy; keep a feature's whole static state in one caller-owned struct (the entire hold state machine is ~100 B of static RAM).
Clarified example regarding buffer size requirements for MSP handlers.
…-optimization-seed docs: expand RAM/flash optimization guide, rewrite as rule-first reference
Release/9.1 to master. Github action size baseline, ram/flash guidance
Contributor
Author
|
@sensei-hacker We expect to receive the final version of the flight control board soon. We will provide it to you once basic testing confirms it is functioning correctly. Thank you. |
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
…reads it The board registers its ICM42605 through common_hardware.c, which takes the interrupt pin from ICM42605_EXTI_PIN. GYRO_1_EXTI_PIN is not read for this gyro, so the pin was ignored and the gyro had no interrupt line.
Member
|
I pushed a one-line change to this branch: GYRO_1_EXTI_PIN is not read for the ICM42605 (common_hardware.c uses ICM42605_EXTI_PIN), so the PC15 interrupt pin was being ignored; renamed it, and on a bench ACCTON_GFF4 the gyro interrupt (PC15) is now claimed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support for the new flight controller: ACCTON_GFF4
Hardware Specifications
Build command: