[MrScothh]

Builds on #12064 (read the ICM426xx on its data-ready interrupt), which is H7 only and builds on #12061. Their commits show here until they are merged, with copies of the fixes from their review; the rest are this PR: the same read on F4 and F7, the interrupt pins of F4 and F7 boards, the fixes from its review, and data-ready on by default.

CI needs #12075. The red build (7) here is KAKUTEH7WING failing in common/log.c: the settings generator drops USE_LOG for that target because of how it reads the compiler's output, not because of this code. #12075 fixes the generator. The same tree builds locally.

On by default, run on two F7 boards and not yet on an F4 (Flywoo F722 Pro V2 and Diatone Mamba F722, see below). With gyro_data_ready = AUTO (the default) F4 and F7 read the ICM426xx on data-ready where the target declares the pin; where no interrupt comes, the gyro is read from its registers as before. set gyro_data_ready = OFF goes back to polling.

What changes

The read goes through DMA. The data-ready PR reads the gyro out of the SPI FIFO on H7. F7 has a 4-byte FIFO and F4 none, so here every data-ready read goes through two DMA streams, like the longer reads on H7:

• The SPI stays enabled, as it is for the main loop's transfers. Setting its DMA requests (receive first, as the reference manuals say) starts the read, and the receive stream's end-of-transfer interrupt ends it.
• Stopping clears the requests, lets a byte still going out finish, and drops what comes back, so the main loop's next transfer starts clean.
• Each SPI's request can use one or two streams (RM0090, RM0410; the same table Betaflight uses). At the end of initialisation the first one nobody owns, and no serial port is named for, is taken. With none free, the gyro is polled.
• The buffers stay out of the F4's CCM RAM, which the DMA can not reach.

The ADC can move to its other stream. On F4 and F7 each SPI request can use only one or two fixed streams, and on many boards the ADC holds DMA2 stream 0 while a timer holds the other stream SPI1 could receive on. ADC1 can also use DMA2 stream 4: when both streams an SPI needs are taken and the ADC has one of them, the ADC is stopped, moved to the other stream if it is free, and started again, once, at the end of initialisation. The receive stream is claimed before the transmit one is looked for, so a move for the transmit side can not put the ADC back onto it. By a count over the targets' timer and serial stream tables, this is what gives 43 of them a free pair of streams.

Why most of this is already tested. The turn-taking with the main loop, the queue, the fallbacks and the DMA stream programming are shared with H7, where they ran on the bench, the stream programming included (a 15-byte read through DMA, 716 000 samples, no error). What is new here is the SPI side: how F4 and F7 start and end a transfer with DMA.

What could still go wrong, and what a first test must look at:

• A transfer that never ends is caught: after 300 µs it is taken off the bus, and after three of those the gyro goes back to register reads for good.
• Bytes that arrive shifted by one would not be caught by anything. The gyro would read wrong values. That is what a first test must rule out, on the bench, before flying.

Targets

Pins come from Betaflight's config for the same board, only where both configs agree on the gyro's CS pin and SPI bus. In a folder with several targets, only those Betaflight confirms get the pin.

Pins added (IMU 1, and IMU 2 where there is one):

• PC4: AIKONF4V2, AXISFLYINGF7PRO, BETAFPVF722, BLADE_F4, BOTWINGF405, BROTHERHOBBYF405V3, CADDXF4_AIO_ELRS, DAKEFPVF405, DAKEFPVF722, FLASHHOBBYF405, FLASHHOBBYF722, FOXEERF405V2, FOXEERF722V4 (and _X8), FURYF4OSD (not MAMBAF405), HAKRCF405V2, HGLRCF405V2, IFLIGHT_BLITZ_F722, IFLIGHT_BLITZ_F722_X1 (and _OSD), MAMBAF405_2022B, MAMBAF722_2022B, MATEKF405SE (and _PINIO), PRINCIPIOTF7, RADIOLINKF405, RADIOLINKF722, SKYSTARSF405AIO (not HD, HD2), SKYSTARSF405V2, SOLOGOODF722, SPEDIXF405, SPEDIXF722, SPEEDYBEEF405MINI, SPEEDYBEEF405V4, TAKERF722SE, TMOTORF7 (not HD), TMOTORF7V2, TMOTORVELOXF7V2, WARPF7
• PC3: FLYWOOF722PRO, GEPRCF405, GEPRCF405_BT_HD, GEPRCF722, HAKRCF405D
• Others: BOTWINGF722 PC13; FLYWOOF405PRO (and HD) and JHEF405PRO PB13, which they already declared as GYRO_INT_EXTI; FLYWOOF745 (and NANO) PE1; FOXEERF745AIO_V3 PD0; GEPRC_F722_AIO (and _UART3) and GEPRCF722_BT_HD PA8; HAKRCF411D PA1; HUMMINGBIRD_FC305 PB6; IFLIGHT_BLITZ_F7_AIO PD0; KAKUTEF4 and KAKUTEF4V2 PC5 (not V23, V24); MATEKF405TE (and _SD) PC15
• Two IMUs: GEPRCF745_BT_HD PD0 / PD8; HAKRCF722V2 PC4 / PB10 (both on SPI1, so only the primary reads on data-ready)
• Declared but not passed until now: AOCODARCF722AIO PC4

Fixed, where INAV and Betaflight disagreed. INAV never read these pins, so a wrong value never showed; Betaflight uses its pins on every flight:

• KAKUTEF4WING: PB12, now PB2.
• AOCODARCF405AIO: PC5, now PC4. Every other pin of that target matches Betaflight's config for the board, and on the rest of the Aocoda F405 family PC5 is a PINIO. No ICM426xx there, so nothing reads it yet.

Already declared, not checked against Betaflight (no config there), and used with ON: FLYDRAGONPRO PB3, HGLRCF722LITE PC4. AIKONF4V3, DAKEFPVF722X8 and KAKUTEF7MINIV3 also declared theirs, and they match Betaflight.

Left out: ZEEZF7 and ZEEZF7V2, where Betaflight's pin is I2C3 SDA and the beeper in INAV; SPEEDYBEEF405WING, where Betaflight declares none; SPEEDYBEEF405AIO, where Betaflight's PE9 is on port E, which the INAV target does not enable; 54 targets with no Betaflight config to compare against.

Size

Against #12064:

Target	MCU	Flash
MATEKF405SE	F405	+4232 B
MATEKF722SE	F722	+3028 B (about 99.1% of its 480 KB)
MATEKH743, TBS_LUCID_H7_WING	H743	0
BLUEBERRYF435WING	AT32F435	0

The H7 and AT32 builds do not change. Built without warnings on all five.

Not tested, testing wanted

Two F7 boards have run this (see below); nothing has run on an F4, and I have not checked the ADC move on hardware. Please try it on a board from the lists above, props off first.

1. get gyro_data_ready shows AUTO, the default.
2. In the CLI, resource lists the gyro's interrupt pin as MPU1 EXTI. If it does not, data-ready was not set up: no pin, a wrong pin, or no free DMA stream.
3. The important one: in the Setup and Sensors tabs, with the board still, the gyro reads close to zero and the accelerometer about 1 g down; moved by hand, both follow the board on the right axes, with the right signs. Wrong or noisy values mean bytes are read out of place: set gyro_data_ready = OFF and please report it.
4. tasks: the GYRO task average drops by several µs.
5. A blackbox log with GYRO_RAW and ACC, board still and moving.
6. Then a flight, if all of that is fine.

A report of which board, which MCU, and what was checked is very welcome, even if everything simply works.

After review

• On F4 the interrupt is on the rising edge: it was on no edge at all, so F4 would have fallen back to reading the registers.
• A read stopped on F4 clears the overrun it may leave.
• SPEEDYBEEF405AIO no longer gets a pin: PE9 is on port E, which its target does not enable, and it did not build.
• On by default: AUTO now reads the ICM426xx on data-ready on F4 and F7 too.
• FLYWOOF405S_AIO's ICM-42605 gets PB13 (its GYRO_INT_EXTI, and Betaflight's), which my comparison script missed: it read a #define without a value as swallowing the next line. With that fixed, no pin added before changes.
• The fixes from gyro: read the ICM426xx on its data-ready interrupt (H7) #12064's and spi: H7 and F7 send bytes back to back, and two H7 transfer faults fixed #12061's review.

Built on F4, F7, H7, AT32 and SITL; KAKUTEF7 and KAKUTEF7HDV fit their ITCM. F7 has run on two boards (see below); F4 is untested on hardware.

Related PRs

• gyro: BMI270, ICM-45686, LSM6DXX and the MPU IMUs on data-ready #12066 and gyro: read the ICM426xx through its FIFO on data-ready (off by default) #12067 build on this one.
• Streams that a target names for UART DMA (serial: receive through DMA where the target names a stream #12033 receive, serial: send through DMA where the target names a stream #12062 transmit) are left to the serial ports.

Tested on more boards (2026-10-06)

Testing: the branch has maintenance-10.x merged in since e642af2, with #12032 (H7 SPI2-4 divisors) and #11943 (flash flush), so an image from this head builds as tested below.

Tested 2026-10-06 on an F7, Flywoo F722 Pro V2 (ICM-42688-P on SPI1, EXTI PC3), image merged on maintenance-10.x
f6579d2: resource shows C03: MPU1 EXTI, GYRO task 12 -> 3 us average; IMU at rest acc (29, -4, 506) with 0.3 of
noise, gyro 0 +-0.1; moved by hand 25 s, gravity propagated by the gyro vs the accelerometer 8.0 deg median with the
true signs, 16 to 77 deg with any axis flipped; blackbox at rest 103 s at 989 Hz with no iteration gap, and 431 s at
200 Hz with 21 s of motion (gyroRaw consecutive duplicates 3.8 %, |acc| 1.00 g). F4 still untested.

A second F7 the same day, a Diatone Mamba F722 2022B (ICM-42688-P on SPI1, EXTI PC4), image merged on maintenance-10.x: resource C04: MPU1 EXTI, GYRO task 12 -> 3 us average, IMU at rest acc (-100, -31, 511) noise 0.4, moved by hand 60 s with peaks of 477 to 574 deg/s and gyro-propagated gravity vs accelerometer 8.0 deg median (18 to 45 deg with an axis flipped), blackbox at rest 12.6 s at 990 Hz with no missing iteration.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add opt-in F4/F7 gyro data-ready reads and improve SPI transfers

✨ Enhancement 🐞 Bug fix ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

AI Description

• Add interrupt-driven ICM426xx reads on F4/F7, while keeping polling as the default there.
• Allocate DMA streams after initialization, with ADC relocation and polling fallbacks when
 resources are unavailable.
• Add board interrupt pins and improve F7/H7 SPI throughput and transfer recovery.

Diagram

graph TD
  Board["Board pin definitions"] --> IMU["ICM426xx IMU"] --> EXTI["Data-ready EXTI"] --> Bus["SPI bus arbiter"] --> DMA["SPI DMA streams"] --> Queue["Sample queue"] --> Task["Gyro task"]
  ADC["ADC stream owner"] -->|"relocate if needed"| DMA
  Task -->|"poll on fallback"| Bus

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Retain polling on F4/F7

• ➕ Avoids untested DMA and ADC-stream interactions.
• ➕ Adds no flash or interrupt workload.
• ➖ Keeps the CPU waiting for SPI reads.
• ➖ Cannot consume each data-ready sample through the new path.

2. Require dedicated DMA assignments per target

• ➕ Makes stream selection explicit and board-specific.
• ➕ Avoids relocating the ADC at runtime.
• ➖ Requires configuration across many boards.
• ➖ Leaves otherwise usable boards without a free stream pair.

Recommendation: Keep the shared, opt-in implementation and polling fallback rather than duplicating a per-board transfer path. Do not enable F4/F7 in AUTO until bench tests verify byte alignment, timeout recovery, and ADC relocation on representative boards.

Files changed (120) +1717 / -134

Enhancement (19) +1506 / -69

config_eeprom.cSuspend reads before flash writes +5/-0

Suspend reads before flash writes

• Stops data-ready activity before EEPROM writes stall interrupt execution.

src/main/config/config_eeprom.c

accgyro.cQueue interrupt-produced gyro samples +33/-0

Queue interrupt-produced gyro samples

• Adds bounded FIFO push and pop operations for samples consumed by the gyro task.

src/main/drivers/accgyro/accgyro.c

accgyro.hDefine gyro data-ready state +54/-0

Define gyro data-ready state

• Adds mode, driver, state, and sample-queue fields, plus queue and active-read helpers.

src/main/drivers/accgyro/accgyro.h

accgyro_data_ready.cCoordinate EXTI reads and sample fallback +225/-0

Coordinate EXTI reads and sample fallback

• Starts supported reads, caches accelerometer and temperature data, and queues completed samples. Pauses full queues and falls back to register reads when samples stop.

src/main/drivers/accgyro/accgyro_data_ready.c

accgyro_data_ready.hDefine the data-ready driver contract +53/-0

Define the data-ready driver contract

• Describes register reads, sample parsing, tested-family gating, and fallback callbacks.

src/main/drivers/accgyro/accgyro_data_ready.h

accgyro_icm42605.cSupport ICM426xx data-ready samples +54/-0

Support ICM426xx data-ready samples

• Declares combined and gyro-only reads, decodes their samples, and reuses fresh accelerometer and temperature values. AUTO permits the path only on H7.

src/main/drivers/accgyro/accgyro_icm42605.c

adc.hExpose ADC1 DMA relocation +6/-0

Expose ADC1 DMA relocation

• Declares the F4/F7 operation for moving ADC1 away from a conflicting stream.

src/main/drivers/adc.h

adc_stm32f4xx.cClaim and relocate F4 ADC DMA +33/-0

Claim and relocate F4 ADC DMA

• Registers ADC DMA ownership and moves ADC1 between DMA2 streams 0 and 4 when the alternative is free.

src/main/drivers/adc_stm32f4xx.c

adc_stm32f7xx.cClaim and relocate F7 ADC DMA +27/-0

Claim and relocate F7 ADC DMA

• Registers ADC DMA ownership and restarts ADC1 on its alternate free DMA2 stream when needed.

src/main/drivers/adc_stm32f7xx.c

bus_busdev_spi.cCoordinate SPI selection and register transfers +24/-8

Coordinate SPI selection and register transfers

• Acquires and releases buses around device selection and speed changes. Uses one address-plus-data transfer on F7/H7.

src/main/drivers/bus_busdev_spi.c

bus_spi.cImplement F4 DMA-backed gyro reads +81/-0

Implement F4 DMA-backed gyro reads

• Adds F4 receive/transmit buffers and DMA completion handling. Starts and stops reads while clearing residual received data.

src/main/drivers/bus_spi.c

bus_spi.hExpose SPI data-ready and combined-transfer APIs +21/-0

Expose SPI data-ready and combined-transfer APIs

• Declares asynchronous read setup, interrupt requests, bus acquisition, and F7/H7 register transfers.

src/main/drivers/bus_spi.h

bus_spi_data_ready.cArbitrate interrupt and main-loop SPI access +179/-0

Arbitrate interrupt and main-loop SPI access

• Defers competing reads, bounds wait time, and disables the asynchronous path after three stalled transfers.

src/main/drivers/bus_spi_data_ready.c

bus_spi_data_ready_dma.cAllocate and operate gyro DMA streams +251/-0

Allocate and operate gyro DMA streams

• Claims free receive/transmit streams while respecting serial reservations and ADC ownership. Programs streams and routes completion or errors to the SPI driver.

src/main/drivers/bus_spi_data_ready_dma.c

bus_spi_data_ready_impl.hDefine family-specific SPI/DMA hooks +65/-0

Define family-specific SPI/DMA hooks

• Separates common read arbitration from MCU-specific transfer and DMA operations.

src/main/drivers/bus_spi_data_ready_impl.h

bus_spi_hal_ll.cPipeline F7/H7 transfers and add asynchronous reads +313/-46

Pipeline F7/H7 transfers and add asynchronous reads

• Sends up to two bytes ahead, combines register addresses with payloads, and recovers from transfer timeouts. Adds H7 FIFO-or-DMA and F7 DMA data-ready paths.

src/main/drivers/bus_spi_hal_ll.c

sdcard_spi.cProtect SD-card initialization clocks +3/-0

Protect SD-card initialization clocks

• Acquires the SPI bus around dummy clocks sent without selecting an SD-card device.

src/main/drivers/sdcard/sdcard_spi.c

fc_init.cStart data-ready reads after initialization +3/-0

Start data-ready reads after initialization

• Defers gyro setup until other DMA users have claimed their streams.

src/main/fc/fc_init.c

gyro.cIntegrate queued samples into gyro processing +76/-15

Integrate queued samples into gyro processing

• Propagates the setting, starts eligible gyros after initialization, and processes queued primary and secondary samples. Preserves register reads when samples are unavailable.

src/main/sensors/gyro.c

Bug fix (3) +10 / -4

adc_stm32h7xx.cRegister H7 ADC stream ownership +6/-0

Register H7 ADC stream ownership

• Marks the ADC's DMA stream as owned so data-ready allocation cannot take it.

src/main/drivers/adc_stm32h7xx.c

target.hCorrect Aocoda F405 interrupt pin +3/-3

Correct Aocoda F405 interrupt pin

• Changes the MPU6000, MPU6500, and BMI270 interrupt definitions from PC5 to PC4.

src/main/target/AOCODARCF405AIO/target.h

target.hCorrect Kakute Wing interrupt pin +1/-1

Correct Kakute Wing interrupt pin

• Changes the ICM42605 interrupt definition from PB12 to PB2.

src/main/target/KAKUTEF4WING/target.h

Documentation (1) +12 / -0

Settings.mdDocument gyro_data_ready +12/-0

Document gyro_data_ready

• Explains supported IMUs, AUTO/ON/OFF behavior, and the untested opt-in F4/F7 path.

docs/Settings.md

Other (97) +189 / -61

CMakeLists.txtBuild data-ready drivers +4/-0

Build data-ready drivers

• Adds the gyro coordinator, SPI arbitration, and DMA implementation to common sources.

src/main/CMakeLists.txt

nvic.hAssign gyro data-ready interrupt priority +2/-0

Assign gyro data-ready interrupt priority

• Gives EXTI and transfer completion the same priority so they do not preempt each other.

src/main/drivers/nvic.h

settings.yamlExpose AUTO/ON/OFF gyro setting +9/-0

Expose AUTO/ON/OFF gyro setting

• Adds the conditional gyro_data_ready setting with AUTO as its default.

src/main/fc/settings.yaml

gyro.hDeclare gyro mode and startup API +12/-0

Declare gyro mode and startup API

• Appends the default-zero data-ready setting and declares its mode and late-start entry point.

src/main/sensors/gyro.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/AIKONF4V2/target.h

target.cPass Aocoda F722 interrupt to bus descriptor +1/-1

Pass Aocoda F722 interrupt to bus descriptor

• Replaces NONE with the existing ICM42605 interrupt pin in SPI registration.

src/main/target/AOCODARCF722AIO/target.c

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/AXISFLYINGF7PRO/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/BETAFPVF722/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/BLADE_F4/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/BOTWINGF405/target.h

target.hDeclare PC13 gyro interrupt +1/-0

Declare PC13 gyro interrupt

• Assigns PC13 to the ICM42605 interrupt.

src/main/target/BOTWINGF722/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/BROTHERHOBBYF405V3/target.h

target.cRegister both H743 gyro interrupts +2/-2

Register both H743 gyro interrupts

• Passes both declared interrupt pins to their ICM42605 SPI descriptors.

src/main/target/BROTHERHOBBYH743/target.c

target.hDeclare dual H743 gyro pins +2/-0

Declare dual H743 gyro pins

• Assigns PB2 and PE15 to the two ICM42605 interrupts.

src/main/target/BROTHERHOBBYH743/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/CADDXF4_AIO_ELRS/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/DAKEFPVF405/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/DAKEFPVF722/target.h

target.cRegister primary H743 IMU interrupt +5/-5

Register primary H743 IMU interrupt

• Passes the primary interrupt pin to each primary IMU SPI descriptor.

src/main/target/DAKEFPVH743/target.c

target.hDeclare primary H743 interrupt +1/-0

Declare primary H743 interrupt

• Defines PC4 as the primary IMU interrupt pin.

src/main/target/DAKEFPVH743/target.h

target.cRegister both H743 PRO IMU interrupts +10/-10

Register both H743 PRO IMU interrupts

• Passes primary and secondary interrupt pins to the corresponding IMU SPI descriptors.

src/main/target/DAKEFPVH743PRO/target.c

target.hDeclare dual H743 PRO interrupts +2/-0

Declare dual H743 PRO interrupts

• Defines PC4 and PB2 for the primary and secondary IMUs.

src/main/target/DAKEFPVH743PRO/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/FLASHHOBBYF405/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/FLASHHOBBYF722/target.h

target.hReuse declared Flywoo interrupt +1/-0

Reuse declared Flywoo interrupt

• Connects ICM42605_EXTI_PIN to the board's existing GYRO_INT_EXTI definition.

src/main/target/FLYWOOF405PRO/target.h

target.cRegister Flywoo F722 interrupt +1/-1

Register Flywoo F722 interrupt

• Passes the ICM42605 interrupt pin to its SPI device descriptor.

src/main/target/FLYWOOF722PRO/target.c

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/FLYWOOF722PRO/target.h

target.hDeclare PE1 gyro interrupt +1/-0

Declare PE1 gyro interrupt

• Assigns PE1 to the ICM42605 interrupt.

src/main/target/FLYWOOF745/target.h

target.cRegister both Flywoo H743 interrupts +2/-2

Register both Flywoo H743 interrupts

• Passes each gyro's defined interrupt pin to its SPI device descriptor.

src/main/target/FLYWOOH743PRO/target.c

target.hDeclare Flywoo H743 gyro pins +2/-0

Declare Flywoo H743 gyro pins

• Assigns PB2 and PE15 to the two gyro interrupts.

src/main/target/FLYWOOH743PRO/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/FOXEERF405V2/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/FOXEERF722V4/target.h

target.hDeclare variant-specific PD0 interrupt +1/-0

Declare variant-specific PD0 interrupt

• Assigns PD0 to the ICM42605 in the applicable target variant.

src/main/target/FOXEERF745AIO/target.h

target.hScope PC4 to verified FURY variant +3/-0

Scope PC4 to verified FURY variant

• Declares the ICM42605 interrupt on PC4 except for MAMBAF405.

src/main/target/FURYF4OSD/target.h

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/GEPRCF405/target.h

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/GEPRCF405_BT_HD/target.h

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/GEPRCF722/target.h

target.hDeclare PA8 gyro interrupt +1/-0

Declare PA8 gyro interrupt

• Assigns PA8 to the ICM42605 interrupt.

src/main/target/GEPRCF722_BT_HD/target.h

target.cRegister GEPRC dual-IMU interrupts +4/-4

Register GEPRC dual-IMU interrupts

• Passes both interrupt pins to the MPU6000 and ICM426xx SPI registrations.

src/main/target/GEPRCF745_BT_HD/target.c

target.hDeclare GEPRC dual-IMU pins +2/-0

Declare GEPRC dual-IMU pins

• Defines PD0 for IMU1 and PD8 for IMU2.

src/main/target/GEPRCF745_BT_HD/target.h

target.hDeclare PA8 gyro interrupt +1/-0

Declare PA8 gyro interrupt

• Assigns PA8 to the ICM42605 interrupt.

src/main/target/GEPRC_F722_AIO/target.h

target.cRegister TAKER H743 dual interrupts +4/-4

Register TAKER H743 dual interrupts

• Passes both interrupt pins to the MPU6000 and ICM426xx SPI registrations.

src/main/target/GEPRC_TAKER_H743/target.c

target.hDeclare TAKER H743 IMU pins +2/-0

Declare TAKER H743 IMU pins

• Defines PD0 for IMU1 and PD8 for IMU2.

src/main/target/GEPRC_TAKER_H743/target.h

target.cRegister HAKRC F405D interrupt +1/-1

Register HAKRC F405D interrupt

• Passes the ICM42605 interrupt pin to its SPI descriptor.

src/main/target/HAKRCF405D/target.c

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/HAKRCF405D/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/HAKRCF405V2/target.h

target.hDeclare PA1 gyro interrupt +1/-0

Declare PA1 gyro interrupt

• Assigns PA1 to the ICM42605 interrupt.

src/main/target/HAKRCF411D/target.h

target.cRegister both HAKRC F722 IMU interrupts +6/-6

Register both HAKRC F722 IMU interrupts

• Passes the two gyro interrupt pins to MPU6000, ICM426xx, and BMI270 registrations.

src/main/target/HAKRCF722V2/target.c

target.hDeclare two F722 gyro pins +2/-0

Declare two F722 gyro pins

• Defines PC4 and PB10 for the two gyros sharing SPI1.

src/main/target/HAKRCF722V2/target.h

target.cRegister dual HAKRC H743 interrupts +2/-2

Register dual HAKRC H743 interrupts

• Passes both ICM426xx interrupt pins to their SPI descriptors.

src/main/target/HAKRCH743/target.c

target.hDeclare dual HAKRC H743 pins +2/-0

Declare dual HAKRC H743 pins

• Assigns PB2 and PC14 to the two ICM426xx interrupts.

src/main/target/HAKRCH743/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/HGLRCF405V2/target.h

target.cRegister Hummingbird gyro interrupt +1/-1

Register Hummingbird gyro interrupt

• Passes the interrupt pin to the ICM426xx SPI descriptor.

src/main/target/HUMMINGBIRD_FC305/target.c

target.hDeclare PB6 gyro interrupt +1/-0

Declare PB6 gyro interrupt

• Assigns PB6 to the ICM42605 interrupt.

src/main/target/HUMMINGBIRD_FC305/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/IFLIGHT_BLITZ_F722/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/IFLIGHT_BLITZ_F722_X1/target.h

target.hDeclare PD0 gyro interrupt +1/-0

Declare PD0 gyro interrupt

• Assigns PD0 to the ICM42605 interrupt.

src/main/target/IFLIGHT_BLITZ_F7_AIO/target.h

target.hScope H7 PRO gyro interrupt +3/-0

Scope H7 PRO gyro interrupt

• Assigns PB2 only for the IFLIGHT_BLITZ_H7_PRO variant.

src/main/target/IFLIGHT_BLITZ_H7_PRO/target.h

target.hReuse declared JHE gyro interrupt +1/-0

Reuse declared JHE gyro interrupt

• Connects ICM42605_EXTI_PIN to the existing GYRO_INT_EXTI definition.

src/main/target/JHEF405PRO/target.h

target.hScope PC5 to supported Kakute revisions +3/-0

Scope PC5 to supported Kakute revisions

• Assigns PC5 only for KAKUTEF4 and KAKUTEF4V2.

src/main/target/KAKUTEF4/target.h

target.hDeclare PE1 gyro interrupt +1/-0

Declare PE1 gyro interrupt

• Assigns PE1 to the ICM42605 interrupt.

src/main/target/KAKUTEH7/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 in the applicable variant.

src/main/target/MAMBAF405_2022A/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 in the applicable variant.

src/main/target/MAMBAF722_2022A/target.h

target.cRegister Mamba H743 gyro interrupt +1/-1

Register Mamba H743 gyro interrupt

• Passes the variant's ICM42605 interrupt pin to its SPI descriptor.

src/main/target/MAMBAH743/target.c

target.hDeclare Mamba H743 variant pins +2/-0

Declare Mamba H743 variant pins

• Defines PC4 or PE15 for the applicable ICM42605 variant.

src/main/target/MAMBAH743/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/MATEKF405SE/target.h

target.hDeclare PC15 gyro interrupt +1/-0

Declare PC15 gyro interrupt

• Assigns PC15 to the ICM42605 interrupt.

src/main/target/MATEKF405TE/target.h

target.cRegister Matek H743 gyro interrupts +3/-3

Register Matek H743 gyro interrupts

• Passes the PB2 and PE15 interrupt pins to their IMU SPI descriptors.

src/main/target/MATEKH743/target.c

target.hDeclare Matek H743 gyro pins +2/-0

Declare Matek H743 gyro pins

• Defines PB2 and PE15 for the two IMU positions.

src/main/target/MATEKH743/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/PRINCIPIOTF7/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/RADIOLINKF405/target.h

target.cRegister Radiolink F722 interrupt +1/-1

Register Radiolink F722 interrupt

• Passes the ICM426xx interrupt pin to its SPI descriptor.

src/main/target/RADIOLINKF722/target.c

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM426xx interrupt.

src/main/target/RADIOLINKF722/target.h

target.hDeclare PD0 gyro interrupt +1/-0

Declare PD0 gyro interrupt

• Assigns PD0 to the ICM42605 interrupt in its conditional IMU configuration.

src/main/target/SEQUREH7/target.h

target.cRegister Simplifly H7 interrupt +1/-1

Register Simplifly H7 interrupt

• Passes the ICM42605 interrupt pin to its SPI descriptor.

src/main/target/SIMPLIFLYH7/target.c

target.hDeclare PC3 gyro interrupt +1/-0

Declare PC3 gyro interrupt

• Assigns PC3 to the ICM42605 interrupt.

src/main/target/SIMPLIFLYH7/target.h

target.hScope PC4 to Skystars AIO +3/-0

Scope PC4 to Skystars AIO

• Declares PC4 only for SKYSTARSF405AIO, excluding the other variants sharing this header.

src/main/target/SKYSTARSF405HD/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SKYSTARSF405V2/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SOLOGOODF722/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SPEDIXF405/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SPEDIXF722/target.h

target.cRegister dual Spedix H743 interrupts +2/-2

Register dual Spedix H743 interrupts

• Passes each ICM426xx interrupt pin to its SPI device descriptor.

src/main/target/SPEDIXH743/target.c

target.hDeclare dual Spedix H743 pins +2/-0

Declare dual Spedix H743 pins

• Assigns PD7 and PE4 to the two ICM426xx interrupts.

src/main/target/SPEDIXH743/target.h

target.hDeclare PE9 gyro interrupt +1/-0

Declare PE9 gyro interrupt

• Assigns PE9 to the ICM42605 interrupt.

src/main/target/SPEEDYBEEF405AIO/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SPEEDYBEEF405MINI/target.h

target.cRegister SpeedyBee V4 interrupt +1/-1

Register SpeedyBee V4 interrupt

• Passes the ICM426xx interrupt pin to its SPI descriptor.

src/main/target/SPEEDYBEEF405V4/target.c

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/SPEEDYBEEF405V4/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/TAKERF722SE/target.h

target.cRegister Lucid H7 gyro interrupts +6/-6

Register Lucid H7 gyro interrupts

• Passes both gyro interrupt pins to the corresponding IMU SPI descriptors.

src/main/target/TBS_LUCID_H7/target.c

target.hDeclare Lucid H7 dual pins +2/-0

Declare Lucid H7 dual pins

• Defines PB2 and PE15 for the two gyro interrupts.

src/main/target/TBS_LUCID_H7/target.h

target.cRegister Lucid Wing gyro interrupts +6/-6

Register Lucid Wing gyro interrupts

• Passes both gyro interrupt pins to the corresponding IMU SPI descriptors.

src/main/target/TBS_LUCID_H7_WING/target.c

target.hDeclare Lucid Wing dual pins +2/-0

Declare Lucid Wing dual pins

• Defines PB2 and PE15 for the two gyro interrupts.

src/main/target/TBS_LUCID_H7_WING/target.h

target.hScope PC4 to verified TMOTOR variant +3/-0

Scope PC4 to verified TMOTOR variant

• Declares the ICM42605 interrupt on PC4 only for TMOTORF7.

src/main/target/TMOTORF7/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/TMOTORF7V2/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/TMOTORVELOXF7V2/target.h

target.hDeclare PC4 gyro interrupt +1/-0

Declare PC4 gyro interrupt

• Assigns PC4 to the ICM42605 interrupt.

src/main/target/WARPF7/target.h

common.hEnable data-ready code for STM32 families +5/-0

Enable data-ready code for STM32 families

• Defines USE_SPI_DATA_READY on F4, F7, and H7; runtime settings still gate use.

src/main/target/common.h

common_hardware.cForward optional ICM42605 interrupt pins +4/-1

Forward optional ICM42605 interrupt pins

• Uses a target-defined interrupt pin in common SPI registration and retains NONE when absent.

src/main/target/common_hardware.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Saving settings can start a DMA read ✓ Resolved

Description

gyroDataReadySuspend() disables EXTI and marks the gyro paused, but its SPI acquire/release pair
leaves the bus-level pending request intact. If a data-ready edge was deferred during an active
read, spiBusRelease() starts that DMA transfer as the hold count reaches zero, immediately before
writeConfigToEEPROM() begins its flash write.

Code

src/main/drivers/accgyro/accgyro_data_ready.c[R176-179]

+        const SPIDevice bus = d->gyro->busDev->busdev.spi.spiBus;
+        spiBusAcquire(bus);
+        spiBusRelease(bus);
+    }

Evidence

The suspend routine disables EXTI, sets paused, and acquires then releases the SPI bus without
clearing pending. The release path starts a pending data-ready read when the hold count reaches
zero, and the EEPROM write follows suspension without another cancellation step; the code's comment
also identifies a DMA read during a flash write as a failure scenario.

src/main/drivers/accgyro/accgyro_data_ready.c[162-179]
src/main/drivers/bus_spi_data_ready.c[46-49]
src/main/drivers/bus_spi_data_ready.c[170-176]
src/main/drivers/accgyro/accgyro_data_ready.c[165-179]
src/main/drivers/bus_spi_data_ready.c[119-132]
src/main/drivers/bus_spi_data_ready.c[164-177]
src/main/config/config_eeprom.c[324-343]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`gyroDataReadySuspend()` can release an already-pending data-ready request after disabling EXTI, starting a DMA read immediately before the EEPROM/flash write.
## Fix Focus Areas
- src/main/drivers/accgyro/accgyro_data_ready.c[165-179]
- src/main/drivers/bus_spi_data_ready.c[164-177]
## Recommended Fix
Add a bus-level suspension or cancellation operation. After disabling EXTI and stopping any active read, clear pending data-ready work under the data-ready interrupt lock before the suspend path releases its bus acquisition, so that release cannot start another DMA transfer; preserve normal pending-request behavior outside suspension.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Failed gyro reads appear successful ✓ Resolved

Description

spiBusTransferRegister() discards the boolean returned by the new H7/F7 spiTransferRegister()
path, and the register-read APIs subsequently return true. When a combined register transfer times
out, busReadBuf() reports success and icm42605GyroRead() decodes whatever bytes remain in its
receive buffer.

Code

src/main/drivers/bus_busdev_spi.c[R137-139]

+#if defined(STM32H7) || defined(STM32F7)
+    spiTransferRegister(instance, reg, rxData, txData, len);
+#else

Evidence

The new transfer implementation returns false on timeout, but its new bus-layer helper is void. The
read-buffer wrapper always returns true, and the gyro driver uses that result to decide whether to
decode the received data.

src/main/drivers/bus_spi_hal_ll.c[460-486]
src/main/drivers/bus_busdev_spi.c[130-143]
src/main/drivers/bus_busdev_spi.c[189-205]
src/main/drivers/accgyro/accgyro_icm42605.c[372-381]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new combined SPI register transfer returns a timeout failure that its bus-layer helper discards.
## Fix Focus Areas
- src/main/drivers/bus_busdev_spi.c[130-143]
- src/main/drivers/bus_busdev_spi.c[190-225]
## Recommended Fix
Make the register-transfer helper return `bool`, propagate the H7/F7 transfer result, and have each register read or write API return that result after deselecting the device.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Timed-out gyro reads break later SPI ✓ Resolved

Description

The F4 spiDataReadyHwStop() disables both DMA streams and only reads DR after allowing an
interrupted transfer to finish, without the subsequent status-register read required to clear a
possible receive overrun. A timeout can leave two outstanding received bytes while RX DMA is
stopped, and later register transfers on that SPI peripheral continue with its error state
uncleared.

Code

src/main/drivers/bus_spi.c[R318-324]

+    spiDataReadyDmaStop(&h->streams);
+    instance->CR2 &= ~(SPI_CR2_TXDMAEN | SPI_CR2_RXDMAEN);
+
+    // A read stopped half way may leave a byte going out: let it finish and drop the echo
+    for (int timeout = 1000; timeout && (!(instance->SR & SPI_SR_TXE) || (instance->SR & SPI_SR_BSY)); timeout--);
+    (void)instance->DR;
+}

Evidence

The timeout path invokes spiDataReadyStop(), which reaches this F4 cleanup code before normal
transfers can continue. The code disables RX DMA first, permits a byte in flight to complete, and
reads only DR; unlike the F7 cleanup path, it has no post-drain status read or explicit error-flag
clear.

src/main/drivers/bus_spi_data_ready.c[146-159]
src/main/drivers/bus_spi.c[313-324]
src/main/drivers/bus_spi_hal_ll.c[681-695]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The F4 data-ready stop path can receive remaining bytes after RX DMA is disabled, but it only drains `DR` and does not complete the peripheral overrun-clear sequence before normal SPI traffic resumes.
Fix Focus Areas
- src/main/drivers/bus_spi.c[318-324]
- src/main/drivers/bus_spi_data_ready.c[146-159]
Recommended Fix
After stopping DMA and waiting for the transfer to become idle, drain received data and read the SPI status register in the required order to clear `OVR` before releasing chip select. Apply this only to the F4 SPI cleanup path and retain the existing F7 FIFO-drain logic.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can move or hide resolved findings to focus on what still needs action

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

Test firmware build ready — commit 7c07383

Download firmware for PR #12065

251 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[github-actions]

RAM / Flash usage vs. base commit 01a7aa3 — commit 7c07383

Using the nearest available size baseline: this build contains base commit d02085d, which has no stored baseline yet, so the deltas also include what was merged to the base since 01a7aa3.

Target	Flash Δ	RAM Δ
MATEKF405 ⚠️	+4316 B (+0.60%)	CCM: -4 B (-0.01%) RAM: +436 B (+0.42%)
MATEKF722	+2572 B (+0.54%)	ITCM_RAM: -872 B (-6.96%) RAM: +548 B (+0.63%) TCM: +4 B (+0.02%)
MATEKF765	+3964 B (+0.52%)	DTCM_RAM: ±0 B (±0.00%) SRAM1: +648 B (+0.52%)
MATEKH743	+3260 B (+0.41%)	D2_RAM: +256 B (+7.84%) DTCM_RAM: ±0 B (±0.00%) ITCM_RAM: -896 B (-5.46%) RAM: +220 B (+0.15%)

See RAM/flash optimization guide for techniques to reduce usage.

[sensei-hacker]

PG note (corrected): this PR appends a field to the end of PG_GYRO_CONFIG with a zero default, so it does not need its own version bump or settings reset (pgLoad copies only the stored bytes over the defaults). The one case not verified is an H7 build without USE_DUAL_GYRO, where the new byte lands in tail padding of the old record; that padding must be zero. Please drop the version bump from this PR unless a reviewer finds a reason it is required. Milestone is 10.1.

[MrScothh]

Done in 4427631: the version stays at 12. Details on #12064.

[MrScothh]

@sensei-hacker tested on an F7 today: a Flywoo F722 Pro V2 (ICM-42688-P on SPI1, interrupt on PC3), image merged on the current maintenance-10.x. Data-ready engages, GYRO task 12 -> 3 us, IMU still and moved by hand consistent, blackbox at rest and in motion with no missing iteration; details in the description under "Tested on more boards". F4 still has no tester. Is there anything else you would like tested?

[MrScothh]

Also ran on a second F7: a Diatone Mamba F722 2022B (ICM-42688-P), with data-ready on. The GYRO task takes 4 us on average instead of 12 polled, 15 at most instead of 22. Moved by hand into three poses, it shows the same axes and signs as polling; the numbers are in #12067 (comment).

[sensei-hacker]

I tested on an F4 (SKYSTARSF405V2), an F7 (X8, including armed blackbox and DShot), and the ACCTON_GFF4 (null case plus data-ready on).
It seems to work well, but the 4KB of flash added will be an issue that needs to be addressed.

[sensei-hacker]

Thanks for the PR! I looked at this with an AI-based tool that read the diff, audited the DMA stream choices and ran it on a few boards. It may well be wrong on any of these points, so please treat them as questions, and correct me if I have misread something.

What we saw on hardware

• DAKEFPVF722X8 (F7, ICM-42605): GYRO task average 10-11 us polled vs 3-4 us with AUTO, load 4.3-4.8% to 1.6-2.0%, total CPU about 37% to 33%. Armed blackbox and DSHOT150 runs showed no mid-run stalls.
• SKYSTARSF405V2 (F4, ICM-42605): fine.

The DMA audit found no stream conflict on the boards we looked at. Nice work on that.

A few things I am curious about

1. Reserved UART streams. spiDmaReserved[] in bus_spi_data_ready_dma.c skips the streams named by UARTn_RX_DMA / UARTn_TX_DMA. As far as I can see, those per-target defines come from serial: receive through DMA where the target names a stream #12033 and serial: send through DMA where the target names a stream #12062 (for example UART2_RX_DMA on TBS_LUCID_H7_WING), so the list is empty until they merge. If they merge after this PR, could a stream picked here for the gyro collide with a stream a target later names for a UART, or does the allocation order at the end of initialisation always give the named UART streams priority?
2. Failure counter. Once three stalls have happened, the bus goes back to polling for the rest of the session. Is there a reason the counter never resets? On a board that has a rare stall every few hours, would a reset on disarm be an option, or is the one-way fallback deliberate?
3. Retry on gyroDataReadyStart. If the DMA stream search fails, does it search again with the same result on the next attempt? It looks as though a "tried and failed" flag could save the repeated work.
4. Flash. The PR adds about 3.4 KB on DAKEFPVF405 (about 2.5 KB is the data-ready core), and it makes F7 targets tight (MATEKF722SE has about 3.9 KB free, DAKEFPVF722X8 is 98.9% full with gyro: read the ICM426xx through its FIFO on data-ready (off by default) #12067). Would an #undef USE_SPI_DATA_READY for the flash-tight targets be acceptable?

Not yet tested

Do you know of runs on an F4 with an SD card on SDIO (SYNERDUINOSTM_F405, PIXRACER)?
@synersignart could probably test that?

[sensei-hacker]

The F722 now fails to build on ITC RAM overflow.

This change to common.h turns on USE_SPI_DATA_READY for F4 and F7 as well as H7.

• gyroUpdate: it grows 80 → 124 B (+44). The disassembly shows the 8-pass counter and the head/tail index compare (ldrb [r7,Initial port of support for multiple types of rangefinder to iNav - for review #128] against [r7,NAV - RTH procedure when close to home #129]), plus extra
  saved registers.
• scheduler: it grows +80 B, and its stack frame goes from 44 to 52 B. No new callees appear, so this is inlining and codegen drift. The callee lists are identical, and its callees are the same afatfs_* SD-card veneers on both sides.
• gyroFilter: it grows +20 B, with 4 fewer instructions. This is codegen drift.

To make room, we can probably NOINLINE some SD-card code. I did that in:
#12169

[MrScothh]

Thanks for testing it on the DAKEFPVF722X8 and the SKYSTARSF405V2, and for #12169: with it KAKUTEF7 and KAKUTEF7HDV fit their ITCM with data-ready on (93.6% and 94.3%), and CI is green again.

1. Reserved UART streams. The list fills itself: it is built at compile time from the target's UARTn_RX_DMA / UARTn_TX_DMA defines, so whichever lands first, a stream a target names for a UART in #12033 or #12062 stays out of the gyro's search in any build that has both. Both sides also check the owner before taking a stream. The gyro takes its streams once, at the end of init (gyroStartDataReady()), after the serial ports, motors, ADC, LED strip and SD card have claimed theirs; a UART that opens later checks the owner too (uartRxDmaAvailable() in #12033, uartDmaStreamAvailable() in #12062 and #12129). So the worst case, a port with no named stream opening after init, is that port running without DMA, as it does today.

2. Failure counter. The one-way fallback is deliberate (the description says so). A read that never ends points to the bus or to the DMA setup rather than to chance, and each one costs the main loop up to 300 µs of waiting plus a bus reset. Resetting the counter on disarm would bring those back on every flight while the cause is still there; three leaves room for a rare glitch before giving up. A reset on disarm is only a few lines if you prefer it, but I'd keep it one-way.

3. Retry on gyroDataReadyStart. The search runs once per boot: gyroStartDataReady() is called once, at the end of init(), and tries at most two read layouts per gyro (with accelerometer and temperature, then gyro only), each one stream search. A failure is not retried, so there is no repeated work to save.

4. Flash. On F4 it is not a concern: +4.3 KB on MATEKF405SE, which stays at 79.6%. On F722 I built all 88 targets from this branch against next-10.1: all of them fit, the PR adds 2.9 to 3.3 KB, and six end above 99%: FLASHHOBBYF722 (99.35%, 3,177 B free), IFLIGHT_BLITZ_F722_X1_OSD, MAMBAF722_2022B, TMOTORF7V2, MATEKF722SE and JHEMCUF722. I'd keep it on everywhere for now and #undef USE_SPI_DATA_READY on a target when that target needs the room, as with other optional features. If you'd rather have it now, I'll add the #undef to those six.

SDIO. I have no F4 with SDIO. From the code there is no conflict: the SDIO driver claims its DMA stream (DMA2 stream 3 or 6) in sdcard_init(), before gyroStartDataReady(), so the gyro's search skips it. And none of the F4/F7 targets with SDIO (SYNERDUINOSTM_F405 and _F405A, PIXRACER, MATEKF765) gets a data-ready pin in this PR, so they read the gyro as before and a run on them would not exercise it.

[MrScothh]

Against an older baseline, as the report says: the ITCM drop on F722 and H743 is #12169, merged into next-10.1 since. The rest is this PR's data-ready reads on F4 and F7, about 4.3 KB on F405 and 2.6 to 3.3 KB on F722; all 88 F722 targets fit, the fullest (FLASHHOBBYF722) at 99.35 %.

[synersignart]

earch skips it. And none of the F4/F7 targets wi

I have a Question on SDIO for F405 if it exist , would the code be similar on the H7 or is it something different

[MrScothh]

@synersignart INAV has SDIO on the F4 too: src/main/drivers/sdcard/sdmmc_sdio_f4xx.c drives the SDIO peripheral with the StdPeriph library and DMA2, and your SYNERDUINOSTM_F405 and F405A targets already build with USE_SDCARD_SDIO, as PIXRACER (F427) does. The F7 and H7 go through sdmmc_sdio_hal.c on the HAL (the H7's SDMMC has its own IDMA), so the low-level file is different, while the card layer above it, sdcard_sdio.c, is shared. This PR touches none of that: the data-ready change is in the gyro drivers only.

[synersignart]

@synersignart INAV has SDIO on the F4 too: src/main/drivers/sdcard/sdmmc_sdio_f4xx.c drives the SDIO peripheral with the StdPeriph library and DMA2, and your SYNERDUINOSTM_F405 and F405A targets already build with USE_SDCARD_SDIO, as PIXRACER (F427) does. The F7 and H7 go through sdmmc_sdio_hal.c on the HAL (the H7's SDMMC has its own IDMA), so the low-level file is different, while the card layer above it, sdcard_sdio.c, is shared. This PR touches none of that: the data-ready change is in the gyro drivers only.

ah ok, yes about the GyroAcc drives in the BMI160 yes alter it on my commit / pull request because for the longest time im using the BMI160 the Gyro and Accelerometer are always oriented in a weird way that prevents Horizon and Angle mode from operating correctly.