From 5d8f7b818f2459192347126cd7b7ee41769ca7b7 Mon Sep 17 00:00:00 2001
From: MrScothh <167884257+MrScothh@users.noreply.github.com>
Date: Mon, 21 Sep 2026 18:35:37 +0200
Subject: [PATCH] serial: 1 KB receive buffers on F7 and H7

At 230400 a GPS can deliver up to 460 bytes between two runs of the task that
drains its port, and a 256 byte buffer drops whatever does not fit. On a bench
with a NEO-F10N at 230400 the receiver was never identified: its 258 byte
MON-VER reply cannot survive in a buffer smaller than itself while the regular
navigation messages keep arriving. With 1 KB buffers the same receiver was
identified immediately, with no timeouts and no errors.

The F7 and H7 have the RAM for it: 4.5 to 6 KB for all the ports a target
defines, against 96 KB free on the smallest F7 target in the maintenance build
and 363 KB on the smallest H7 one. The F405 targets have 13 to 18 KB left and
the AT32F435 targets between 1.5 and 3 KB, so they keep what they have.

The note about occupied sizes being returned as uint8_t no longer held: the
driver functions and the ring indices are all 32 bit.
---
 src/main/drivers/serial_uart.h | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/src/main/drivers/serial_uart.h b/src/main/drivers/serial_uart.h
index 4c1e6d57508..43abf130916 100644
--- a/src/main/drivers/serial_uart.h
+++ b/src/main/drivers/serial_uart.h
@@ -22,24 +22,35 @@
 // Since serial ports can be used for any function these buffer sizes should be equal
 // The two largest things that need to be sent are: 1, MSP responses, 2, UBLOX SVINFO packet.
 
-// Size must be a power of two due to various optimizations which use 'and' instead of 'mod'
-// Various serial routines return the buffer occupied size as uint8_t which would need to be extended in order to
-// increase size further.
-#define UART1_RX_BUFFER_SIZE    256
+// Size must be a power of two due to various optimizations which use 'and' instead of 'mod'.
+// Occupied and free sizes are returned as uint32_t, so a buffer may exceed 256 bytes.
+
+// At 230400 a GPS delivers up to 460 bytes between two runs of the task that drains its
+// port, and whatever does not fit is lost: a u-blox MON-VER reply alone is 258 bytes. The
+// F7 and H7 have the RAM to spare, a few KB against 96 KB free on the smallest F7 target
+// and 363 KB on the smallest H7 one. The F405 targets have 13 KB left and the AT32F435
+// ones between 1 and 3 KB, so those keep their 256
+#if defined(STM32H7) || defined(STM32F7)
+#define UART_RX_BUFFER_SIZE_DEFAULT     1024
+#else
+#define UART_RX_BUFFER_SIZE_DEFAULT     256
+#endif
+
+#define UART1_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART1_TX_BUFFER_SIZE    256
-#define UART2_RX_BUFFER_SIZE    256
+#define UART2_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART2_TX_BUFFER_SIZE    256
-#define UART3_RX_BUFFER_SIZE    256
+#define UART3_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART3_TX_BUFFER_SIZE    256
-#define UART4_RX_BUFFER_SIZE    256
+#define UART4_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART4_TX_BUFFER_SIZE    256
-#define UART5_RX_BUFFER_SIZE    256
+#define UART5_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART5_TX_BUFFER_SIZE    256
-#define UART6_RX_BUFFER_SIZE    256
+#define UART6_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART6_TX_BUFFER_SIZE    256
-#define UART7_RX_BUFFER_SIZE    256
+#define UART7_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART7_TX_BUFFER_SIZE    256
-#define UART8_RX_BUFFER_SIZE    256
+#define UART8_RX_BUFFER_SIZE    UART_RX_BUFFER_SIZE_DEFAULT
 #define UART8_TX_BUFFER_SIZE    256
 
 typedef enum {