serial: receive through DMA where the target names a stream by MrScothh · Pull Request #12033 · iNavFlight/inav

MrScothh · 2026-09-25T14:08:53Z

This builds on #12001, the GPS port's own receive buffer. Its four commits show here until it is merged; the last three are this PR, the third from its review.

Stacked on this one: #12062 (send through DMA), #12128 (the stream rule), #12129 (DMA on every UART) and #12132 (CRSF and SBUS receivers on DMA). Merged from here up, each one's diff shows only its own commits.

What this adds

A UART can receive through a DMA stream instead of an interrupt per byte. A target turns it on per port with UARTx_RX_DMA; a port without one, and a target that names none, build and behave as before.

How

The stream fills the port's own ring, and the head is read back from the transfer counter, so nothing above the driver changes.
A port whose owner takes each byte through rxCallback (the serial receiver protocols, which frame by timing) stays on the interrupt even when a stream is named.
F4 and F7 wire each receiver to fixed streams, so a tag naming another one is a build error. H7 and AT32 route through the DMAMUX.
On H7 the ring of a port receiving through DMA moves to D2 SRAM (DMA_RAM), out of the data cache and within reach of DMA1 and DMA2.
A stream that any of the target's timer outputs is mapped to is left to the timers, because the serial ports open before the motors do.
serialSetRxBuffer() from gps: satellite details twice a second, and a 512 byte receive buffer for the GPS port #12001 goes through a new optional vtable entry. A UART receiving through DMA restarts its stream on the new ring. On targets with RX DMA the GPS ring is placed where a stream can reach it: D2 SRAM on H7, plain RAM on F4, F7 and AT32F43x (CCM is out of reach on F4, INAV's F7 linker scripts say DMA cannot reach DTCM, and I don't know that RAM1 is reachable on AT32). Everywhere else it stays in FASTRAM.
Fixed on the way: on F7, H7 and AT32 the interrupt handler tested the RX flag without its enable bit, so a port receiving through DMA could have lost a byte to the interrupt raised for what it sends.
docs/development/targets/timer-dma-conflicts.md gets a section on choosing a stream.
Enabled on TBS_LUCID_H7_WING for UART2, on DMA2 stream 5.

Measured

TBS Lucid H7 Wing, NEO-F10N on UART2 at 115200, one minute, a bench build of this change with and without UART2_RX_DMA. That build sits on an older base and carries interrupt counters that are not part of this PR:

UART2	Interrupts per second	CPU
Byte interrupt	1086	0.07 %
DMA	6	< 0.01 %

At 480 MHz the load was small to begin with. What the stream adds is that it keeps receiving while interrupts are masked, where the byte interrupt has to be served before the next byte arrives.

With this branch, GPS on UART2 through DMA: the receiver is identified with no errors or timeouts at 115200 and after autobaud to 230400, and NAV-PVT arrives at the configured 10 Hz. Over ten reboots at 230400 there were 1 error and 2 timeouts at startup, against 1 and 1 over nine reboots with the byte interrupt, so that remainder is not the stream's.

Against #12001, built from the same base:

Target	Flash	RAM
TBS_LUCID_H7_WING (UART2 on DMA)	+408 B	DTCM -512 B, D2 +768 B (the UART2 ring and the GPS ring)
MATEKH743	+64 B	unchanged
MATEKF722	+96 B	unchanged
MATEKF405	+56 B	unchanged
BLUEBERRYF435WING	-24 B	unchanged

The size comment below is measured against an older base (86a0441) and includes #12001: the +512 B it shows in CCM, TCM or DTCM on targets that do not receive through DMA is #12001's GPS ring, not this PR.

Not tested

The H743 and an F7 (Diatone Mamba F722, see Tested on an F7 below) have received through DMA. F4 and AT32 build, and their stream tables follow the reference manuals, but no board of those families has run it.

After review

On F7 the GPS ring is in plain RAM when the port receives through DMA: it was in DTCM, which INAV's F7 linker scripts say DMA cannot reach.
Rebased on the current maintenance-10.x with gps: satellite details twice a second, and a 512 byte receive buffer for the GPS port #12001.

A receive stream restarted on a new ring sets the UART's DMA request again (28ef068). On F7 and H7 stopping
the stream cleared it and only a reprogramming of the port set it back, so after serialSetRxBuffer() the port
heard nothing until the next baud, mode or option change. Today's only caller, the GPS, changes the baud rate
right after, so it never showed. With a test patch that swaps a larger GPS ring in 10 s after boot:

3 boots each	without	with
FLYWOOF722PRO	a timeout on every boot, 130-133 packets at 15 s	no timeout, 152-155 packets
KAKUTEH7MINI	a timeout on every boot, 114-117 packets at 15 s	no timeout, 139-148 packets

F4 and AT32 already set the request when the stream starts. TBS_LUCID_H7_WING +16 B of flash; no other target
compiles it.

On F7 the GPS ring goes in DMA_RAM as on H7 (79dcdb5). A port's receive stream gets a ring of its own there only where DMA_RAM is uncached, that is with F7: enable the D-cache, DMA buffers in a non-cacheable SRAM2 region #12119's D-cache, which sets DMA_RAM_UNCACHED (d2cafb6, after a Qodo point on serial: leave a UART only the DMA streams a timer output will use #12128): without it DMA_RAM is plain RAM and that ring would only duplicate the port's own. With the D-cache, a ring left in cached RAM could hand the CPU a line cached before the stream filled it. I did not see that fail at 115200 (FLYWOOF722PRO with F7: enable the D-cache, DMA buffers in a non-cacheable SRAM2 region #12119, the GPS sending on the interrupt, 0-1 errors per boot with the rings in cached RAM and in DMA_RAM alike), so this follows the cache rule rather than a measured failure. No target in the tree names an F7 receive stream today.

Built on F4, F7, H7, AT32 and SITL; KAKUTEF7 and KAKUTEF7HDV fit their ITCM. On the TBS Lucid H7 Wing after review: the GPS on UART2 works through receive DMA.

Tested on an F7 (2026-10-06)

Diatone Mamba F722 2022B, image of #12062 (which carries this PR) merged on the current maintenance-10.x, with UART1_RX_DMA DMA_TAG(2, 5, 4), UART3_RX_DMA DMA_TAG(1, 1, 4) and UART3_TX_DMA DMA_TAG(1, 3, 4) added to the target (DMA1 streams 1 and 3 belong to no timer of this board; UART1's transmit stream, DMA2 stream 7, is TIM8_CH4's, so UART1 cannot send through DMA there). serialpassthrough on UART3 with TX3 and RX3 joined, random bytes written and read back at the same time from the host:

256 KB each way, UART3 looped	USART3 interrupts	transmit DMA interrupts	bytes lost
maintenance-10.x (byte interrupt), 921600	262 156, one per byte	0	0
this merge, 921600	0	3 074, one per about 85 bytes	0
this merge, 921600 then 2 000 000 (512 KB)	0	6 155	0, 197 kB/s at 2 Mbaud

The interrupt counters were a local test commit, not part of the PR. A CRSF receiver on UART1 with UART1_RX_DMA named keeps its byte callback and works (RX rate 994, channels and RSSI as expected). F4 and AT32 still untested.

Note for testers: the branch has maintenance-10.x merged in since 28ef068, #11943 (flash flush) included, so an image from this head builds as tested.

qodo-code-review · 2026-09-25T14:09:00Z

ⓘ 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 · 2026-09-25T14:10:08Z

PR Summary by Qodo

Add target-configured DMA reception for UART ports

✨ Enhancement 🐞 Bug fix 📝 Documentation 🧪 Tests 🕐 40+ Minutes

AI Description

• Adds optional circular DMA reception while preserving interrupt fallback and callback-driven
 ports.
• Supports DMA-safe buffer replacement and enlarges the u-blox GPS receive ring.
• Documents stream selection, enables UART2 DMA, and reduces u-blox satellite traffic.

Diagram

graph TD
    CFG["Target DMA tag"] --> OPEN["UART open"] --> ELIGIBLE{"DMA eligible?"}
    ELIGIBLE -->|Yes| DMA["Circular RX DMA"] --> RING["Receive ring"] --> API["Serial consumers"]
    ELIGIBLE -->|No| IRQ["Byte RX interrupt"] --> RING
    GPS["GPS buffer swap"] --> DMA
    GPS --> RING

High-Level Assessment

The following are alternative approaches to this PR:

1. DMA staging buffer with copy

➕ Separates DMA producer state from the public serial ring.
➕ Can use transfer-complete or idle events for explicit producer updates.
➖ Adds memory copies and another buffer.
➖ Introduces DMA interrupts and more latency.
➖ Requires broader changes above the UART driver.

2. HAL receive-to-idle API

➕ Provides explicit chunk boundaries and standardized HAL callbacks.
➕ Could simplify transfer-counter polling on supported STM32 families.
➖ Does not provide a consistent implementation across F4, F7, H7, and AT32.
➖ Adds HAL callback and rearming complexity.
➖ May generate more interrupts than continuous circular DMA.

Recommendation: Keep the PR's circular DMA-to-ring design. Reading the hardware transfer counter preserves the existing serial API, avoids copies and DMA interrupts, and provides a clean interrupt fallback when a stream conflicts or the owner requires per-byte callbacks. The staging-buffer and receive-to-idle alternatives add overhead or weaken cross-platform consistency.

Files changed (17) +690 / -21

Enhancement (9) +265 / -18

serial.cAdd generic receive-buffer replacement +25/-0

Add generic receive-buffer replacement

• Adds serialSetRxBuffer(), delegating to an optional driver hook or atomically replacing the ring for simpler drivers. Existing buffered data is intentionally discarded.

src/main/drivers/serial.c

serial.hExpose receive-buffer replacement through the serial API +4/-0

Expose receive-buffer replacement through the serial API
• Adds the public serialSetRxBuffer() declaration and an optional setRxBuffer vtable operation for drivers with additional receive state.
src/main/drivers/serial.h

serial_uart.cIntegrate RX DMA with the legacy STM32 UART path +8/-4

Integrate RX DMA with the legacy STM32 UART path

• Attempts DMA reception when opening RX ports, derives the ring head from DMA state, and wires UART-specific buffer replacement into the vtable. Ports without usable DMA retain RXNE interrupts.

src/main/drivers/serial_uart.c

serial_uart.hTrack active UART receive DMA channels +7/-4

Track active UART receive DMA channels
• Adds optional RX DMA state to each UART port and clarifies that receive buffers may exceed 256 bytes.
src/main/drivers/serial_uart.h

serial_uart_hal.cPreserve RX DMA across HAL UART reconfiguration +13/-4

Preserve RX DMA across HAL UART reconfiguration

• Restores the UART DMA request after HAL initialization, starts DMA before reconfiguration, and reads buffered-byte counts from the DMA-derived head. It also exposes DMA-aware receive-buffer replacement.

src/main/drivers/serial_uart_hal.c

serial_uart_hal_at32f43x.cIntegrate RX DMA with the AT32 HAL UART path +8/-4

Integrate RX DMA with the AT32 HAL UART path
• Starts configured receive DMA during port opening, uses the transfer count for ring occupancy, and installs the DMA-aware buffer replacement hook.
src/main/drivers/serial_uart_hal_at32f43x.c

serial_uart_impl.hCentralize UART RX DMA policy and ring handling +100/-0

Centralize UART RX DMA policy and ring handling

• Validates fixed F4/F7 mappings, rejects streams reserved by timer outputs, and provides DMA-aware head calculation and buffer replacement. Stub implementations preserve existing builds when RX DMA is disabled.

src/main/drivers/serial_uart_impl.h

serial_uart_stm32f4xx.cImplement circular UART RX DMA for STM32F4 +92/-0

Implement circular UART RX DMA for STM32F4
• Adds per-UART stream lookup and circular byte transfers directly into receive rings. DMA is skipped for unavailable streams, non-RX ports, and callback-based receivers.
src/main/drivers/serial_uart_stm32f4xx.c

gps_ublox.cReduce u-blox satellite-detail message frequency +8/-2

Reduce u-blox satellite-detail message frequency

• Requests NAV-SIG and NAV-SAT at approximately 2 Hz instead of every navigation epoch. This reduces serial bandwidth while retaining satellite-list and OSD detail updates.

src/main/io/gps_ublox.c

Bug fix (1) +20 / -0

gps.cGive u-blox GPS a 512-byte DMA-safe receive ring +20/-0

Give u-blox GPS a 512-byte DMA-safe receive ring

• Allocates a dedicated 512-byte receive buffer for u-blox GPS and installs it after opening the port. Memory placement changes by platform so configured DMA engines can access it safely.

src/main/io/gps.c

Tests (1) +7 / -0

gps_null_port_unittest.ccStub receive-buffer replacement in GPS tests +7/-0

Stub receive-buffer replacement in GPS tests
• Adds a no-op serialSetRxBuffer() implementation so the GPS null-port unit test links with the new serial API.
src/test/unit/gps_null_port_unittest.cc

Documentation (1) +57 / -0

timer-dma-conflicts.mdDocument UART RX DMA configuration and conflicts +57/-0

Document UART RX DMA configuration and conflicts
• Explains how targets select UART receive streams, which mappings are valid, and when ports fall back to interrupts. It also documents timer, ADC, UART, and H7 memory constraints.
docs/development/targets/timer-dma-conflicts.md

Other (5) +341 / -3

serial_uart_at32f43x.cImplement AT32F43x UART receive DMA +97/-1

Implement AT32F43x UART receive DMA

• Maps UART receivers through DMAMUX, configures circular peripheral-to-memory transfers, and falls back when DMA is unavailable or callbacks are required. The IRQ handler no longer consumes RX data owned by DMA.

src/main/drivers/serial_uart_at32f43x.c

serial_uart_stm32f7xx.cImplement STM32F7 UART RX DMA and IRQ isolation +97/-1

Implement STM32F7 UART RX DMA and IRQ isolation
• Configures fixed-channel circular streams and coordinates the UART request with HAL reconfiguration. RX interrupts no longer read bytes while DMA owns reception.
src/main/drivers/serial_uart_stm32f7xx.c

serial_uart_stm32h7xx.cImplement cache-safe STM32H7 UART RX DMA +137/-1

Implement cache-safe STM32H7 UART RX DMA

• Adds DMAMUX-based circular reception and allocates configured UART rings in uncached, DMA-accessible D2 SRAM. The IRQ path avoids consuming DMA-owned bytes, and UART initialization selects the DMA-safe rings.

src/main/drivers/serial_uart_stm32h7xx.c

target.hEnable UART2 RX DMA on TBS Lucid H7 Wing +2/-0

Enable UART2 RX DMA on TBS Lucid H7 Wing
• Assigns UART2 reception to DMA2 stream 5, avoiding the target's timer-output and ADC stream mappings.
src/main/target/TBS_LUCID_H7_WING/target.h

common_post.hDerive the UART RX DMA feature flag +8/-0

Derive the UART RX DMA feature flag
• Enables USE_UART_RX_DMA automatically whenever a target defines at least one UARTx_RX_DMA stream.
src/main/target/common_post.h

qodo-free-for-open-source-projects · 2026-09-25T14:12:08Z

Code Review by Qodo

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

1. Satellite details update too slowly 🐞 Bug ≡ Correctness

Description

ubloxSatInfoRate() calculates the message interval from the configured ubloxNavHz even when
configureRATE() clamps or overrides the receiver's actual navigation frequency. With a valid value
such as 200 Hz on a pre-version-24 receiver, navigation is limited to 20 Hz while satellite messages
are emitted every 100 epochs, affecting the satellite list and on-screen extra statistics only once
every five seconds.

Code

src/main/io/gps_ublox.c[961]
+    return MAX(1, (gpsState.gpsConfig->ubloxNavHz + 1) / 2);

Evidence
The helper directly uses the user-configured rate, while configureRATE() independently limits
older protocols to 20 Hz and old hardware to 5 Hz. The setting accepts values through 200 Hz, so the
mismatch is reachable with supported configuration rather than malformed input.
src/main/io/gps_ublox.c[958-962]
src/main/io/gps_ublox.c[532-537]
src/main/io/gps_ublox.c[1134-1146]
src/main/fc/settings.yaml[1882-1889]

Agent prompt

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

## Issue description
Satellite message intervals are derived from the requested navigation frequency, although receiver version limits, old hardware handling, or a rejected rate can result in a lower effective frequency. This makes NAV-SAT and NAV-SIG updates substantially slower than the intended approximately two updates per second.
## Fix Focus Areas
- src/main/io/gps_ublox.c[958-962]
- src/main/io/gps_ublox.c[532-537]
- src/main/io/gps_ublox.c[1134-1146]
## Recommended Fix
Calculate the satellite-message interval from the effective navigation frequency after applying the same protocol and hardware limits used by `configureRATE()`. If rate configuration falls back to 5 Hz after a rejection, reconfigure the satellite-message interval for that effective rate as well.

ⓘ 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 keep summaries lean with Findings visible per group, which tucks the rest behind a View link

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

github-actions · 2026-09-25T14:37:46Z

RAM / Flash usage vs. base commit e87050f — commit d2cafb6

Using the nearest available size baseline — the PR's exact base commit has no stored baseline yet.

Target	Flash Δ	RAM Δ
MATEKF405	+152 B (+0.02%)	CCM: +512 B (+1.57%) RAM: +8 B (+0.01%)
MATEKF722	+216 B (+0.04%)	ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%) TCM: +512 B (+2.02%)
MATEKF765	+432 B (+0.06%)	DTCM_RAM: +512 B (+1.79%) SRAM1: ±0 B (±0.00%)
MATEKH743	+256 B (+0.03%)	D2_RAM: ±0 B (±0.00%) DTCM_RAM: +512 B (+3.95%) ITCM_RAM: ±0 B (±0.00%) RAM: ±0 B (±0.00%)

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

github-actions · 2026-09-25T14:38:05Z

Test firmware build ready — commit d2cafb6

Download firmware for PR #12033

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.

NAV-SIG (M9, M10) and NAV-SAT (M8) were requested at every navigation epoch. They feed only the satellite list in the CLI, yet they are most of what the receiver sends: NAV-SIG carries 16 bytes for each tracked signal, several hundred bytes per epoch on a multi-constellation receiver, against about 100 for the NAV-PVT that navigation runs on. They are now requested every (gps_ublox_nav_hz + 1) / 2 epochs, which is about twice a second at any navigation rate.

A receive buffer has to hold what arrives between two runs of the task that drains it. For the GPS task, 20 ms apart, that is up to 230 bytes at 115200 and 460 at 230400, and a reply to a poll has to fit whole: MON-VER alone can be 258 bytes. With the 256 bytes every port has, a NEO-F10N at 230400 was never identified, because its MON-VER reply was always cut. The GPS port now gets a 512 byte buffer of its own, in FASTRAM, where there is room: CCM on F405, RAM1 on AT32F43x. serialSetRxBuffer() swaps it in right after the port is opened. Every other port keeps its 256 bytes. The note that occupied sizes are returned as uint8_t no longer held: the driver functions and the ring indices are all 32 bit.

The satellite details also feed the OSD's GPS extra stats, not only gpssats, so the comment now says both. The comments are one line each, the buffer states the rate it covers (230400; at 460800 and above a NAV-PVT plus a large NAV-SIG can still overflow it), its size is asserted to be a power of two because softserial masks with size - 1, and it only exists where the u-blox provider does, the only one that opens a port. The note in serial_uart.h about sending a UBLOX SVINFO was stale.

A UART receiving through a DMA stream costs no interrupt per byte, and keeps the bytes that arrive while interrupts are held off. A target turns it on per port with UARTx_RX_DMA; a port without one, and a target that names none, build and behave exactly as before. The stream fills the port's own ring, whose head is read back from the transfer counter, so nothing above the driver changes. Ports whose owner takes each byte through rxCallback (the serial receivers, which frame by timing) stay on the interrupt even when a stream is named. F4 and F7 wire each receiver to fixed streams, so a tag naming another is a build error. H7 and AT32 route through the DMAMUX. On H7 the ring moves to D2 SRAM, out of the data cache. A stream any timer output is mapped to is left to the timers, since MSP ports open before the motors do. On F7, H7 and AT32 the interrupt handler tested the RX flag without the enable, so a port receiving through DMA could have lost a byte to the interrupt raised for what it sends; it now leaves the data register alone. Enabled on TBS_LUCID_H7_WING for UART2, on DMA2 stream 5.

serialSetRxBuffer() only swapped the ring's pointer and size, but a DMA stream keeps writing to the memory it was started on, so a port receiving through DMA would have gone on filling its old ring while the reader looked at the new one. The serial vtable gets an optional setRxBuffer, which the UARTs implement by swapping the ring and, if a stream is running, starting it again on the new one. The GPS ring must then be memory a stream can reach on targets that receive through DMA: D2 SRAM on H7 rather than DTCM, and on F4 and AT32F43x plain RAM rather than CCM or RAM1. Everywhere else it stays in FASTRAM, so a target without UARTx_RX_DMA builds exactly as before. On the TBS Lucid H7 Wing, GPS on UART2 through DMA2 stream 5, NEO-F10N: identified with no errors or timeouts at 115200 and after autobaud to 230400, NAV-PVT at the configured 10 Hz. Over ten reboots, 1 error and 2 timeouts at startup, against 1 and 1 over nine with the byte interrupt.

iNavFlight#12119 turns the F7 D-cache on and makes DMA_RAM an uncached SRAM2 region. A ring left in cached RAM could then hand the CPU a line it cached before the stream filled it. The rings go in DMA_RAM, as on H7; on F7 that is plain RAM until iNavFlight#12119, so on its own this changes nothing. Not seen to fail at 115200: FLYWOOF722PRO with iNavFlight#12119 and the GPS sending on the interrupt had 0-1 errors per boot with the rings in cached RAM and in DMA_RAM alike.

On F7 and H7, stopping the stream clears USART_CR3_DMAR and only uartReconfigure() set it again. After serialSetRxBuffer() the stream ran but the UART never fed it, and with the byte interrupt off for a DMA port the port stayed deaf until the next baud, mode or option change. The GPS got away with it because the u-blox driver changes the baud rate right after swapping its ring. F4 and AT32 already set the request when the stream starts. With a test patch that swaps a larger GPS ring in 10 s after boot, FLYWOOF722PRO and KAKUTEH7MINI had a timeout on every boot without this and none with it.

On F7 DMA_RAM is plain RAM until iNavFlight#12119 turns the D-cache on and makes it an uncached SRAM2 section, so until then each ring only duplicated the port's own, 256 B per UART with a receive stream. They are compiled only where build_config.h says DMA_RAM is uncached (DMA_RAM_UNCACHED, set together with the D-cache), so either PR can go in first.

The F7 UART receive rings of iNavFlight#12033 are compiled only then; without the D-cache the port's own ring does.

qodo-free-for-open-source-projects Bot reviewed Sep 25, 2026

View reviewed changes

Comment thread src/main/io/gps_ublox.c

This was referenced Sep 28, 2026

serial: send through DMA where the target names a stream #12062

Open

gyro: read the ICM426xx on its data-ready interrupt (H7) #12064

Open

gyro: data-ready reads on F4 and F7 #12065

Open

MrScothh added 9 commits September 28, 2026 13:09

Trim comments to the reasons the code doesn't show

5b310b4

gps: stub serialSetRxBuffer in the heartbeat test

f6c16c8

Trim comments to the reasons the code doesn't show

56e686b

gps: on F7 too, the ring a receive stream fills is not in DTCM

86745b2

MrScothh force-pushed the feature/uart-rx-dma branch 3 times, most recently from b415c3f to 86745b2 Compare September 28, 2026 19:20

MrScothh mentioned this pull request Sep 30, 2026

srxl2: a Smart ESC on a board's ESC connector #12087

Closed

sensei-hacker added the New Feature label Oct 3, 2026

sensei-hacker added this to the 10.1 milestone Oct 6, 2026

sensei-hacker added the Testing Required label Oct 6, 2026

MrScothh added 2 commits October 6, 2026 23:33

Merge maintenance-10.x into feature/uart-rx-buffer

fd12836

Merge feature/uart-rx-buffer into feature/uart-rx-dma

3aedf3c

MrScothh mentioned this pull request Oct 7, 2026

F7: enable the D-cache, DMA buffers in a non-cacheable SRAM2 region #12119

Open

MrScothh added 2 commits October 8, 2026 02:03

This was referenced Oct 8, 2026

serial: leave a UART only the DMA streams a timer output will use #12128

Open

serial: DMA on every UART, the stream picked at runtime where the target names none #12129

Open

MrScothh added a commit to MrScothh/inav that referenced this pull request Oct 8, 2026

build: say where DMA_RAM is uncached on F7

4d2c700

The F7 UART receive rings of iNavFlight#12033 are compiled only then; without the D-cache the port's own ring does.

This was referenced Oct 8, 2026

serial: CRSF and SBUS receivers on DMA, handed each frame when the line goes idle #12132

Open

UART TX and RX on output pads #12143

Open

Navigation Menu

Repository navigation

serial: receive through DMA where the target names a stream - #12033

serial: receive through DMA where the target names a stream#12033
MrScothh wants to merge 14 commits into
iNavFlight:maintenance-10.xfrom
MrScothh:feature/uart-rx-dma

MrScothh commented Sep 25, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Sep 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 25, 2026 •

edited

Loading

Uh oh!

Uh oh!

github-actions Bot commented Sep 25, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 25, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

MrScothh commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this adds

How

Measured

Not tested

After review

Tested on an F7 (2026-10-06)

Uh oh!

qodo-code-review Bot commented Sep 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 25, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

github-actions Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MrScothh commented Sep 25, 2026 •

edited

Loading

qodo-free-for-open-source-projects Bot commented Sep 25, 2026 •

edited

Loading

github-actions Bot commented Sep 25, 2026 •

edited

Loading

github-actions Bot commented Sep 25, 2026 •

edited

Loading