STM32双串口DMA互透传：空闲中断+软FIFO实践

简介：STM32Cube 双串口 DMA 互透传工程面向嵌入式开发初学者、电子竞赛选手与需要提升串口吞吐能力的工程师，聚焦 UART1 与 UART2 之间基于 DMA 的双向数据转发，解决传统轮询或中断方式在连续、不定长数据收发时频繁占用 CPU、处理效率偏低的问题。压缩包共 143 个文件、约 3.62MB，包含 20 个 C 源文件与 42 个 H 头文件，另有 CubeMX 的 .ioc 配置、Keil 的 .uvprojx 工程以及编译生成的 .o、.d、.crf、.axf、.map 等中间文件和输出文件，便于直接打开对照外设配置与构建结果。已有 1872 人学习下载。工程涵盖串口与 DMA 初始化、DMA 收发启动、传输完成中断处理及串口错误回调等关键环节，可作为双串口透传、数据转发和 HAL 库 DMA 调试的参考模板，帮助读者理解配置流程、验证方法与常见排错思路，也适合用于学习串口参数设置、DMA 通道分配和中断优先级安排。

1. 窄带与宽带：两个串口互拷，为什么我最后没敢用 memcpy 轮询

前阵子接手一个采集盒子的固件，两头都只能靠串口对话：一边是 115200 的老传感器，另一边是 921600 的通信模组，中间那颗 STM32 干的活说白了就一句话——左边进来什么，右边原样吐出去，反向也一样。听上去是memcpy就能糊弄过去的事，真上手才发现坑不少：轮询会把主循环固定死在等字节上，而两边波特率差八倍，一旦发送侧跟不上，丢包丢得毫无征兆。这套基于 STM32Cube 的双串口 DMA 互透传工程解决的就是这件事：两路 USART 各自挂 DMA，用空闲中断做变长分帧，中间加一层软 FIFO 做速率解耦。它适合手里已经有 CubeMX 骨架、想让两路串口各跑各的又不互相拖累的开发者，也适合刚学完 HAL 库、第一次给串口接 DMA 的同学拿来对着改。

2. 技术选型与 CubeMX 配置：双串口 DMA 的时钟、中断与模式怎么点

2.1 先把吞吐算清楚，再决定缓冲区开多大

串口透传最容易被忽略的一步是算账。8N1 格式下每字节 10 bit，115200 对应大约 11.5 KB/s，921600 对应大约 92 KB/s。这意味着从慢口往快口转，永远是“喂不饱”；从快口往慢口转，才是真正会出事的方向——92 KB/s 的数据涌进来，出口只有 11.5 KB/s，差出来的部分必须有地方待着，否则只能丢。

我一般是这么定尺寸的：接收缓冲区RX_BUF_SZ只跟单帧最大长度有关，取 256 够应付绝大多数传感器帧；发送 FIFOTX_FIFO_SZ则跟“两边速率差 × 允许的阻塞时间”有关，快转慢的场景建议 1024 起步，2 的幂方便取模编译成按位与。真要长时间跑满 8 倍速率差，任何有限 FIFO 都会溢出，这时候要么加硬件流控，要么在上层做丢帧策略——这一点后面避坑章节会展开。

轮询方式的问题不在于慢，而在于它把 CPU 绑在了字节上。115200 下一个字节间隔 87 μs，主循环里稍微有个延时或者 Flash 操作，就可能错过 RXNE。DMA 把“搬字节”这件事交给硬件，CPU 只在“一帧结束”的时候被打断一次，中断次数从每字节一次降到每帧一次，这个差别在 921600 下非常明显。

2.2 CubeMX 里必须点开的几项配置

新建工程后，时钟树先配到芯片能跑的最高主频，然后按下面这张表点。这里有个细节：两路串口的波特率不需要相等，透传本来就允许两端异步。

配置项	USART1	USART2	说明
Mode	Asynchronous	Asynchronous	8N1，无硬件流控
Baud Rate	115200	921600	两端独立，互不影响
DMA RX	USART1_RX / Circular	USART2_RX / Circular	优先级 Low，内存自增
DMA TX	USART1_TX / Normal	USART2_TX / Normal	每次发送重新装填
NVIC	USART1 global IRQ	USART2 global IRQ	抢占优先级 1
NVIC	DMA 对应 Stream IRQ	DMA 对应 Stream IRQ	抢占优先级 2，必须比串口低

最后一行是我见过最容易翻车的地方。串口中断里会去调HAL_UART_Transmit_DMA，如果 DMA 流中断的抢占优先级比串口还高，就会出现串口中断正改着 HAL 状态机、DMA 中断插进来又改一遍的情况，表现为偶发的数据错位甚至卡死。数字越小优先级越高，所以 DMA 的数值要大于等于串口。

另外，CubeMX 生成的main.c里初始化顺序是有讲究的：

/* main.c 里的调用顺序不能调换 */ MX_GPIO_Init(); MX_DMA_Init(); /* 必须先开 DMA 时钟，再初始化用到 DMA 的外设 */ MX_USART1_UART_Init(); MX_USART2_UART_Init();

MX_DMA_Init()里做的是__HAL_RCC_DMA1_CLK_ENABLE()和 NVIC 配置。如果手工挪过顺序，或者把串口初始化提到前面，HAL_UART_Init里挂 DMA 时会因为 DMA 控制器时钟没开而直接返回错误，表现是串口能收但永远不进 DMA 回调。这个坑不报错、不打印，只表现为不工作，排查起来相当费时间。

2.3 Normal 还是 Circular，取决于你要不要留一条应对后续问题的路

接收侧我强烈建议在 CubeMX 里直接选 Circular。Normal 模式下 DMA 搬满Size个字节就自己停了，如果你的帧长恰好等于缓冲区长度，下一次传输不会自动开始，得靠中断重新Start。而变长帧场景下，帧长本来就飘忽，Normal 模式会让“什么时候该重挂”这件事变得很难判断。

发送侧反而要用 Normal。原因很直接：发送是“我说了算”的动作，每次HAL_UART_Transmit_DMA传一段确定的长度，传完触发TxCpltCallback，语义清晰。如果用 Circular，DMA 会在缓冲区里无限绕圈发同一段数据，除非你精确地在某个时刻去HAL_DMA_Abort，那个时序极难掐准，通常会造成尾部多发一截重复数据。

提示：部分 HAL 版本在UART_Start_Receive_DMA内部会重新设置 DMA 模式，导致你在 CubeMX 里选 Normal 也不一定生效。所以判断依据不要看图形界面，去看stm32f4xx_hal_uart.c里那个函数实际写了什么，或者干脆按 Circular 的心理预期去写代码，任何时候都假设它可能环绕。

3. 工程结构拆解：一个字节从 USART1 进、从 USART2 出的完整链路

3.1 生成代码与应用代码的边界

STM32Cube 生成的工程有个特点：所有用户代码都塞在USER CODE BEGIN/USER CODE END之间，重新生成不会丢。但真正撑起业务的部分不该待在这些缝里，我的习惯是单独开一对app_uart.c/h，生成代码只负责“把外设配起来”。

Project/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ ├── usart.h │ │ └── app_uart.h # 应用层接口，透传逻辑全在这里 │ └── Src/ │ ├── main.c # 只在 USER CODE 区调 app_uart_init() │ ├── stm32f4xx_it.c # 中断入口，CubeMX 生成，不用改 │ ├── usart.c # CubeMX 生成的 MX_USARTx_UART_Init │ └── app_uart.c # 端口对象、软 FIFO、回调实现 ├── Drivers/ │ ├── CMSIS/ │ └── STM32F4xx_HAL_Driver/ └── Project.ioc # 配置源头，改配置只改这个

这样拆的好处是重生成代码时不用提心吊胆。改波特率、加一路串口、换芯片型号，都只在 CubeMX 里动，app_uart.c里只依赖huart1/huart2两个句柄，几乎不用碰。反过来说，如果透传逻辑写进了usart.c的USER CODE区，下一次点“Generate Code”之后，你得逐段肉眼比对有没有被覆盖，那种感觉很不保险。

app_uart.h里只暴露两个函数：一个初始化、一个转发。真正的实现细节——FIFO 指针怎么绕、回调里怎么重挂 DMA——全部藏在.c文件里。这个边界划清楚之后，后面要在中间插协议解析层，只需要改port_forward的实现，上层调用方完全无感。

3.2 数据链路：DMA → 空闲中断 → 软 FIFO → DMA

整条链路是四段，每段解决一个不同的问题，缺一段都会出毛病。

第一段是 DMA 硬件搬运。串口每收到一个字节，DMA 控制器直接从DR寄存器读到内存缓冲区，CPU 完全不参与。这一步解决的是“高频小数据搬运”的效率问题。

第二段是空闲中断分帧。串口总线上两个字节之间只要有超过一个字符时间的静默，硬件就会置位 IDLE 标志。对变长帧协议来说，这个“静默”天然就是帧边界，比任何自定义的帧头帧尾判断都可靠。HAL 库把它封装成了HAL_UARTEx_ReceiveToIdle_DMA，回调里直接给你“这一帧收了多少字节”，省掉了自己读SR再读DR清标志的那套操作。

第三段是软 FIFO。这是很多人会跳过的一步，也是最容易出问题的一步。原因在于HAL_UART_Transmit_DMA是非阻塞的，但它同时只能有一个传输在跑。如果上一帧还在发，下一帧就到了，这个函数会返回HAL_BUSY，数据直接丢掉。921600 下一帧 100 字节只要 1 ms 左右就发完，而快转慢的场景里，出口发这 100 字节要 8 ms，中间必然有新的帧进来。软 FIFO 就是在这两个速率之间做缓冲。

第四段是发送 DMA。FIFO 里有数据、且当前没有传输在跑的时候，取一段连续内存交给 DMA，传完在TxCpltCallback里推进尾指针、再取下一段。

3.3 中断优先级与临界区

这套结构里有个隐含前提：FIFO 的头指针只在一个上下文里写，尾指针只在另一个上下文里写。我的做法是把所有 FIFO 操作都放进中断上下文——RxEventCallback是中断，TxCpltCallback也是中断，两者不会互相打断（同一个串口的 RX 和 TX 各自独立，但都通过同一个 FIFO 结构体访问）。

即便如此，还是要小心嵌套。如果 USART1 的回调正在写 port2 的 FIFO，此时 USART2 的中断（优先级相同或更高）插进来也去写 port2 的 FIFO，头指针就会错乱。解决办法很简单：把两路串口中断设成相同的抢占优先级，Cortex-M 内核默认不允许同优先级中断互相抢占，天然互斥。如果因为别的原因必须设成不同优先级，那就在fifo_put外面套一层__disable_irq()/__enable_irq()，代价是关中断时间变长，注意别在里面做耗时操作。

4. 核心模块拆解：几个函数把双向透传跑起来

4.1 端口对象与启动函数

先定义一个结构体把一路串口需要的东西全装进去，这样同一套代码对着两路串口各跑一遍，不用写两份。

/* app_uart.h */ #ifndef APP_UART_H #define APP_UART_H #include "main.h" #define RX_BUF_SZ 256 /* 单帧上限，超过这个长度的数据会被硬件拆成多帧 */ #define TX_FIFO_SZ 1024 /* 必须是 2 的幂，取模才能编译成按位与 */ typedef struct { UART_HandleTypeDef *huart; uint8_t rx_buf[RX_BUF_SZ]; /* DMA 直接写入，不要放栈上 */ uint8_t tx_buf[TX_FIFO_SZ]; volatile uint16_t tx_head; /* 写侧推进，只在接收回调里改 */ volatile uint16_t tx_tail; /* 读侧推进，只在发送完成回调里改 */ volatile uint16_t tx_inflight; /* 当前这一笔 DMA 的长度 */ volatile uint8_t tx_busy; uint32_t drop_cnt; /* FIFO 满而丢弃的字节数，调参时看这个 */ } uart_port_t; void app_uart_init(void); void port_forward(uart_port_t *dst, const uint8_t *data, uint16_t len); #endif

volatile加在tx_head/tx_tail/tx_inflight上不是形式主义。这几个变量在中断里改、在主循环或另一个中断里读，不开优化时没问题，一开-O2编译器就可能把它们缓存在寄存器里，导致循环永远看不到变化——这类问题单步调试时完全正常，全速跑就出问题，非常难找。

启动函数里做两件事：关掉半满中断、挂上接收 DMA。

void app_uart_init(void) { /* 关掉 DMA 半满中断：我们只在 IDLE 时结算，HT 中断纯属白跑一趟 */ __HAL_DMA_DISABLE_IT(huart1.hdmarx, DMA_IT_HT); __HAL_DMA_DISABLE_IT(huart2.hdmarx, DMA_IT_HT); HAL_UARTEx_ReceiveToIdle_DMA(&huart1, port1.rx_buf, RX_BUF_SZ); HAL_UARTEx_ReceiveToIdle_DMA(&huart2, port2.rx_buf, RX_BUF_SZ); }

参数说明：__HAL_DMA_DISABLE_IT的第一个参数是DMA_HandleTypeDef *，直接从huart->hdmarx取；第二个是中断类型。半满中断在“小包高频”的场景下会把中断次数翻倍，而透传根本不需要知道“收到一半了”这件事，关掉能省下可观的 CPU 时间。

HAL_UARTEx_ReceiveToIdle_DMA第三个参数是缓冲区长度，DMA 最多搬到这个长度就绕回。注意两个rx_buf必须是全局或静态存储，放函数栈上会在 DMA 还在写的时候被回收。

4.2 空闲事件回调：取长度、转发、重挂 DMA

这个回调是整个透传的核心，所有分帧逻辑都在这里。

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart->Instance == USART1) { port_forward(&port2, port1.rx_buf, Size); /* USART1 -> USART2 */ HAL_UARTEx_ReceiveToIdle_DMA(&huart1, port1.rx_buf, RX_BUF_SZ); } else if (huart->Instance == USART2) { port_forward(&port1, port2.rx_buf, Size); /* USART2 -> USART1 */ HAL_UARTEx_ReceiveToIdle_DMA(&huart2, port2.rx_buf, RX_BUF_SZ); } }

Size是硬件算出来的“这一帧实际收了多少字节”，从 1 到RX_BUF_SZ都可能。这里不做任何裁剪或拼接，收到多少就转多少，透传的语义就是原样搬运。

末尾那次重挂不能省。HAL 的 ReceiveToIdle 在触发一次 IDLE 事件之后，内部状态并不总是能自动续上——不同系列、不同 HAL 版本行为不一致。统一在回调最后重挂一次，代价是一次函数调用，换来的确定性很值。我见过有人只在初始化时挂一次，结果就是“能收第一帧，之后静默”，现象极具迷惑性。

4.3 发送软 FIFO 与 TxCplt 续传

发送侧的关键是“永远不阻塞、也不丢”。写侧入队：

static uint16_t fifo_put(uart_port_t *p, const uint8_t *d, uint16_t len) { uint16_t n = 0; while (n < len) { uint16_t next = (uint16_t)((p->tx_head + 1) & (TX_FIFO_SZ - 1)); if (next == p->tx_tail) { /* 满了一圈，只能丢 */ p->drop_cnt += (len - n); break; } p->tx_buf[p->tx_head] = d[n++]; p->tx_head = next; } return n; }

环形队列留一个空位来区分“满”和“空”，所以实际可用容量是TX_FIFO_SZ - 1。& (TX_FIFO_SZ - 1)这个写法依赖容量是 2 的幂，编译器会直接生成一条 AND 指令；如果改成% TX_FIFO_SZ，在不支持硬件除法的 Cortex-M0 上会退化成软件除法，耗时几十个周期，在高频回调里很可观。

泵函数负责把 FIFO 里的内容喂给 DMA：

static void fifo_pump(uart_port_t *p) { if (p->tx_busy || p->tx_head == p->tx_tail) return; uint16_t len; if (p->tx_head > p->tx_tail) { len = p->tx_head - p->tx_tail; } else { len = (uint16_t)(TX_FIFO_SZ - p->tx_tail); /* 先发到尾部，回绕留给下一次 */ } p->tx_inflight = len; p->tx_busy = 1; if (HAL_UART_Transmit_DMA(p->huart, &p->tx_buf[p->tx_tail], len) != HAL_OK) { p->tx_busy = 0; p->tx_inflight = 0; } }

回绕时只发到缓冲区尾部，剩下那截等TxCpltCallback触发后再发。这样每次交给 DMA 的一定是一段连续内存，HAL_UART_Transmit_DMA不需要关心环形结构。代价是多一次中断，但正确处理了“头指针小于尾指针”这个绕回来的情况——不处理的话，长度会算成一个巨大的值，DMA 直接把整个缓冲区包括垃圾一起发出去。

发送完成回调里推进尾指针，然后立刻再泵一次：

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { uart_port_t *p = (huart->Instance == USART1) ? &port1 : &port2; p->tx_tail = (uint16_t)((p->tx_tail + p->tx_inflight) & (TX_FIFO_SZ - 1)); p->tx_inflight = 0; p->tx_busy = 0; fifo_pump(p); /* 还有余量就接着发，形成流水线 */ }

fifo_pump在这里被递归地调用（严格说是被回调再触发回调，不是真递归调用栈），形成一条“发完一段接着发下一段”的流水线，直到 FIFO 空了才停。

4.4 错误回调：ORE 之后怎么把串口救回来

串口错误回调如果不写，出问题之后就是永久性静默，只能靠复位恢复。

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) { if (huart->ErrorCode & (HAL_UART_ERROR_ORE | HAL_UART_ERROR_FE | HAL_UART_ERROR_NE)) { /* ORE 会让 RXNE 一直有效，不清掉 DMA 永远等不到下一个字节 */ __HAL_UART_CLEAR_OREFLAG(huart); huart->ErrorCode = HAL_UART_ERROR_NONE; } if (huart->Instance == USART1) { HAL_UARTEx_ReceiveToIdle_DMA(&huart1, port1.rx_buf, RX_BUF_SZ); } else if (huart->Instance == USART2) { HAL_UARTEx_ReceiveToIdle_DMA(&huart2, port2.rx_buf, RX_BUF_SZ); } }

__HAL_UART_CLEAR_OREFLAG内部是“先读 SR 再读 DR”，这个顺序是硬件手册规定的，反了清不掉。清完标志还不够，必须重新挂 DMA——出错时 HAL 会把RxState置成HAL_UART_STATE_READY或直接停掉 DMA，不重挂的话后续数据全进不来。

还有一点：H7 系列带 D-Cache 的芯片，rx_buf如果落在可缓存区域，DMA 写进去的数据可能还在缓存里没落到内存，CPU 读到的是旧值。解决办法是在读缓冲区之前调SCB_InvalidateDCache_by_Addr，或者干脆用 MPU 把这块内存配成 non-cacheable。F4/F1 没有这个问题，跨平台移植时特别容易忘。

5. 避坑与常见问题排查：这几处问题我都遇到过

5.1 现象：能收第一帧，之后彻底静默

原因通常是回调里没有重挂HAL_UARTEx_ReceiveToIdle_DMA。初始化时挂的那一次只覆盖一轮传输，IDLE 事件处理完之后 HAL 内部状态就停了，硬件层面 DMA 可能还在绕圈，但 HAL 已经不再往里送回调。表现就是上电后第一条数据转发正常，后面再也收不到。

解决办法是在HAL_UARTEx_RxEventCallback的每个分支末尾都重挂一次，包括HAL_UART_ErrorCallback里也要挂。别指望“DMA 是 Circular 就会自动续”，HAL 的状态机和硬件是两套东西。

5.2 现象：快转慢时drop_cnt一直涨，数据成段丢失

这是缓冲区不够，不是代码有 bug。921600 转 115200 是 8 倍速率差，1024 字节的 FIFO 在出口满载时只能缓冲约 89 ms 的数据，超过这个窗口进来的数据只能丢。

按需处理：第一优先是把TX_FIFO_SZ加到 2048 或 4096，确认 RAM 够用；第二是在协议层加应答/重传，让上层感知到丢包；第三才是开硬件流控，用RTS/CTS让发送方在 FIFO 快满时停下来。前两条改代码，第三条改硬件，按项目阶段选。

5.3 现象：偶发整段乱码，重启才能恢复

八成是 ORE（溢出错误）没清。当上一帧还没被 DMA 搬走、下一个字节又到了，硬件会置位 ORE，此后RXNE保持有效，但 DMA 已经不再响应请求。HAL 在检测到 ORE 时会进HAL_UART_ErrorCallback，如果这个函数是空的（CubeMX 默认生成的就是空的__weak版本），那就永远清不掉。

按 4.4 那样实现错误回调，清标志加重挂，问题就消失了。顺便提醒一句：huart->ErrorCode手动清一下，否则下次判断还是旧值。

5.4 现象：两个串口一起开，数据错位或直接 HardFault

中断优先级冲突。USART 中断里调用HAL_UART_Transmit_DMA，这个函数会改gState、设置 DMA 回调指针、启动 DMA。如果 DMA 流中断的抢占优先级比 USART 高，它可能在这中间插进来执行TxCpltCallback，此时 HAL 的状态还没设完，回调里读到的tx_inflight是上一笔的旧值，尾指针就推错了。

解决办法：CubeMX 里把 USART 的抢占优先级设成数值更小（即更高），DMA 流设成数值更大。同一路串口的 RX 和 TX 用不同的 DMA 流时，这两条流之间不要设成互相能抢占的优先级关系。

5.5 现象：单步调试一切正常，全速跑就丢字节

调试器打断点会暂停整个系统，串口硬件和 DMA 却可能继续工作（取决于调试配置），恢复运行时缓冲区的状态已经和代码预期对不上了。这类“调试正常、运行异常”的问题几乎都跟时序有关，单步没有参考价值。

改用别的验证手段：在drop_cnt上打断点或者用 SWO 打印计数、用 GPIO 翻转做时序标记、用逻辑分析仪抓两路串口的波形对齐时间轴。我一般会在port_forward里加一个空闲的 GPIO 置高、返回前置低，示波器上看这一路的高电平宽度就知道转发耗时和触发频率，比打日志准得多。

6. 二次开发：在透传层上接一个协议网关

透传跑通之后，下一步通常是“不想再原样搬了，我想看懂中间的数据”。这时候不需要动app_uart.c的任何逻辑，只要在port_forward中间插一个钩子。

/* 返回值是处理后的输出长度，返回 0 表示这一帧丢弃 */ typedef uint16_t (*frame_hook_t)(const uint8_t *in, uint16_t in_len, uint8_t *out, uint16_t out_max); static frame_hook_t g_hook = NULL; /* 默认透传，不装钩子就是原样搬 */ void port_forward(uart_port_t *dst, const uint8_t *data, uint16_t len) { uint8_t stage[RX_BUF_SZ]; uint16_t out_len = len; if (g_hook) { out_len = g_hook(data, len, stage, sizeof(stage)); if (out_len == 0) return; /* 校验失败或过滤掉 */ data = stage; } fifo_put(dst, data, out_len); fifo_pump(dst); }

stage这块临时缓冲放在栈上没问题，fifo_put会立刻把内容拷进 FIFO，函数返回后就不再用。frame_hook里可以做 CRC 校验、帧头过滤、单位换算、协议转换——比如把 Modbus RTU 转成自定义二进制帧，或者把一路的 ASCII 指令翻译成另一路的十六进制。因为钩子是函数指针，装与不装只是运行时的一次判空，默认不开时和原来的透传行为完全一致，不会引入额外开销。

验证方法我一般走这么一套：PC 上开两个 USB 转串口模块，分别接到板子的两路，用一个脚本双向灌固定模式的数据（递增序列最好用，能直接看出丢在第几个字节）。跑十分钟，比对两端的接收内容，同时读drop_cnt和huart->ErrorCode。递增序列比随机数据好用得多，因为一旦丢包，后面的序号全错位，肉眼一眼就能看出从哪儿开始丢。

最后说个血泪教训：我早期写这类透传，习惯性把drop_cnt当成“理论上不会增长的计数器”，代码里不处理它，只在调试时瞄一眼。结果有一次现场反馈“偶尔丢数据”，我远程连上去一看计数器已经几百万了，从第一分钟就在丢，只是没人发现。从那以后我每次做串口透传，都会在初始化时把drop_cnt和两路的ErrorCode挂到同一个调试结构体里，用 SWO 或者一路空闲串口定时吐出来，不敢再靠“看起来正常”来判断。希望这套东西能帮你少走一遍我走过的路。

本文还有配套的精品资源，点击获取