简介围绕STM32CUBE双串口DMA互透传的完整工程资料面向已具备STM32基础、希望掌握UART1与UART2经DMA高效收发与转发的嵌入式开发者可用于学习HAL库串口配置、DMA通道设置、传输完成中断及错误回调等关键环节对连续、不定长数据的收发场景尤具参考意义。压缩包为rar格式共143个文件、约3.62MB主要由h头文件、c源文件、o目标文件、d依赖文件与crf浏览信息文件构成另含ioc配置、uvprojx工程和map、axf等编译产物工程结构较完整便于直接打开对照与复现实验。已有1872人学习下载说明该实践案例具有较好的参考价值。读者可从中获得基于STM32F1系列HAL库的双串口DMA互透传工程组织、串口与DMA初始化思路、中断服务函数处理方式、串口异常排查线索及编译调试参照适合作为课程设计、毕业设计或设备间数据转发项目的学习样板。1. 两个串口互透传代码写到第三版才敢上产线双串口 DMA 互透传这个需求最早是在一个模拟项目里碰到的主控板一路 UART 接上位机另一路接子模块中间需要把两边的数据原样转发不许丢字节、不许攒包延迟。裸机轮询版本跑通只花了一个下午但连续跑两天必丢帧接收溢出错误像幽灵一样随机出现。后来把两路串口都改成 DMA 收发CPU 占用从 40% 压到个位数才真正敢放到长时间运行的场景里。这篇就围绕 STM32Cube 环境把「两路 UART 各挂 DMA、双向透传」这件事从配置、代码到踩坑完整拆一遍。适合手里有 STM32 开发板、已经能跑通单串口收发、想进一步搞定 DMA 透传链路的人如果你还在纠结串口中断和 DMA 该选谁看完也能建立一个清晰的选型判断。2. CubeMX 里那几个勾选项DMA 配置的取舍逻辑2.1 为什么透传场景必须让接收端走 DMA先把这个决定的理由说透不然 CubeMX 里几个勾选项选错了后面怎么调都是白搭。串口透传的本质是「收到的字节别在中断里待太久尽快搬进缓冲区、再搬出去」。用传统中断方式每来一个字节 CPU 进一次 ISR波特率一高、两路同时收中断频率翻倍主循环里稍微有个耗时操作接收寄存器就被新字节覆盖触发 ORE 溢出错误。血泪经验是只要透传链路是常开的、波特率超过 115200接收端就必须上 DMA。STM32 的 USART 外设给收发各留了一条 DMA 通道请求接收端配成循环模式DMA 控制器自己把 DR 寄存器里的字节搬到内存CPU 只在缓冲区攒够一半或全满时才被叫醒。发送端则配成普通模式一帧数据搬完触发传输完成中断省去了逐字节等待 TXE 标志的轮询。这套组合下来两条串口同时满速跑CPU 也只是偶尔进一次回调。但要提一句边界DMA 循环模式意味着接收缓冲区是个环形DMA 不会停所以「一帧数据到哪里结束」必须由软件自己判断。业界通行做法是打开串口的 IDLE 空闲中断总线静默一个字节时间就认为一帧收完配合 HAL 库的HAL_UARTEx_ReceiveToIdle_DMA()拿到本次实际收到的长度。这个 API 是整条链路的地基后面所有代码都围着它转。2.2 CubeMX 逐项配置与参数含义打开 CubeMX 新建工程选好芯片型号之后串口部分按下面的步骤点。这里用 USART1 和 USART2 举例实际用哪两路按板子接线来但配置逻辑完全一致。第一步在 Connectivity 里把两个 USART 的 Mode 都设为 Asynchronous波特率先填 115200、8 数据位、1 停止位、无校验这个组合兼容性最好调试阶段别急着上高波特率。第二步切到 DMA Settings 页签给每个 USART 各加两条 DMA 请求具体参数如下表外设DMA 方向ModePriority数据宽度外设/内存用途USART1_RXPeripheral To MemoryCircularHighByte / Byte循环接收USART1_TXMemory To PeripheralNormalMediumByte / Byte单次发送USART2_RXPeripheral To MemoryCircularHighByte / Byte循环接收USART2_TXMemory To PeripheralNormalMediumByte / Byte单次发送接收端选 Circular 是关键Normal 模式下 DMA 搬完预设长度就停了后续字节进不来。发送端选 Normal每次发一帧启动一次发完即止。优先级上接收高于发送避免接收缓冲被发送任务挤占。数据宽度统一 Byte串口是字节流配成 Half Word 反而会错位。第三步NVIC 里把两个 USART 的全局中断都使能DMA 通道的中断 CubeMX 会自动勾上不用手动改。最后生成代码时Toolchain 选 MDK-ARM 或 STM32CubeIDE 都行代码骨架是一样的。提示生成代码后先别急着写业务用HAL_UART_Transmit()把两个串口各发一句字符串确认硬件接线和波特率没错再往上叠 DMA。很多「DMA 不工作」的排查到最后都是 TX/RX 线接反或者共地没接。2.3 初始化阶段的隐形坑先启动接收再进主循环CubeMX 生成的MX_DMA_Init()默认排在MX_USARTx_UART_Init()之前这个顺序是对的DMA 控制器要先于外设初始化。但真正容易翻车的是接收启动的时机。HAL_UARTEx_ReceiveToIdle_DMA()必须在主循环之前调用而且两个串口都要调漏掉一路就是「能发不能收」。我一般会在main.c的while (1)上方、所有外设初始化完成之后加一段启动代码/* USER CODE BEGIN 2 */ uint8_t rx_buf1[RX_BUF_SIZE]; uint8_t rx_buf2[RX_BUF_SIZE]; /* 启动两路串口的空闲中断DMA接收缓冲区由DMA循环填充 */ if (HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buf1, RX_BUF_SIZE) ! HAL_OK) { Error_Handler(); } if (HAL_UARTEx_ReceiveToIdle_DMA(huart2, rx_buf2, RX_BUF_SIZE) ! HAL_OK) { Error_Handler(); } /* USER CODE END 2 */这里的RX_BUF_SIZE是单个接收环形缓冲区的容量建议取 256 或 512别贪大。缓冲区越大DMA 半满/全满中断来得越晚帧延迟越高太小又容易在高速率下被覆盖。透传场景下一帧数据通常不超过几十字节256 是性价比比较稳的档位。HAL_UARTEx_ReceiveToIdle_DMA()的第三个参数传的是缓冲区总长度不是期望接收长度这一点和普通HAL_UART_Receive_DMA()一致但配合 IDLE 中断后它的语义变成了「环形缓冲区的物理大小」后面计算偏移量全靠它。3. 接收链路ReceiveToIdle_DMA 加环形缓冲区的组合拳3.1 空闲中断回调里到底拿到了什么HAL_UARTEx_ReceiveToIdle_DMA()的机制值得掰开讲清楚否则回调里的Size参数一定会用错。DMA 在循环模式下持续把 USART 数据寄存器搬到rx_buf同时硬件在检测到总线空闲收到一帧后静默超过一个字节传输时间时置位 IDLE 标志HAL 库把 IDLE 和 DMA 的半传输/传输完成事件统一收口到HAL_UARTEx_RxEventCallback()这个弱函数里。回调原型是void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size)关键在Size这个参数。它表示「从本次接收启动、或者从上一次回调之后到现在一共往缓冲区里写入了多少个字节」而不是缓冲区总长度也不是当前写指针的绝对位置。HAL 库内部维护了一个RxXferCount每次半传输或传输完成中断都会更新它IDLE 触发时把已收字节数报上来。但这里有个非常隐蔽的行为DMA 半传输中断HT也会触发这个回调。也就是说如果一帧数据刚好跨过缓冲区一半的位置你会在没收到完整帧的情况下被叫醒一次Size报的是半缓冲区的长度。这就是很多人写透传时数据被拦腰截断的根因。处理办法是在回调里自己判断事件来源或者干脆用「累计接收计数 环形缓冲区写指针」的方式绕开对Size绝对语义的依赖。3.2 环形缓冲区结构与转发逻辑透传链路不能收到一帧就直接在回调里调发送因为发送是阻塞的DMA 启动也要时间回调里待太久会影响下一帧接收。标准做法是回调只负责把数据写进软件环形缓冲区主循环或者一个低优先级任务从环形缓冲区取数据、启动 DMA 发送。下面这套结构用了很久稳定#define RING_BUF_SIZE 1024 typedef struct { uint8_t buf[RING_BUF_SIZE]; volatile uint16_t head; /* 写指针只在接收回调里改 */ volatile uint16_t tail; /* 读指针只在发送任务里改 */ volatile uint16_t count; /* 当前有效字节数 */ } RingBuffer_t; static RingBuffer_t ring1 {0}; /* USART1 收到的数据待从 USART2 发出 */ static RingBuffer_t ring2 {0}; /* USART2 收到的数据待从 USART1 发出 */ /* 向环形缓冲区写入返回实际写入字节数 */ static uint16_t RingBuffer_Write(RingBuffer_t *rb, const uint8_t *data, uint16_t len) { uint16_t written 0; while (written len rb-count RING_BUF_SIZE) { rb-buf[rb-head] data[written]; rb-head (rb-head 1) % RING_BUF_SIZE; rb-count; } return written; /* 返回值小于len说明缓冲区满需要上层处理丢包 */ } /* 从环形缓冲区读出返回实际读出字节数 */ static uint16_t RingBuffer_Read(RingBuffer_t *rb, uint8_t *data, uint16_t len) { uint16_t read 0; while (read len rb-count 0) { data[read] rb-buf[rb-tail]; rb-tail (rb-tail 1) % RING_BUF_SIZE; rb-count--; } return read; }head和tail都用volatile修饰因为一个在中断上下文改、一个在主循环改编译器优化不能把它们缓存进寄存器。count字段让「缓冲区空/满」的判断不用靠 headtail 这种有歧义的方式读写双方各自维护逻辑更直白。容量取 1024 是为了扛住两路短暂速率不匹配的突发比如上游一口气发了 800 字节、下游 DMA 还没来得及搬完。接收回调的实现要同时处理两路并且把数据写进对应的环形缓冲区void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { /* USART1收到的数据最终要从USART2转发出去 */ RingBuffer_Write(ring1, rx_buf1, Size); /* 循环模式下DMA不会停无需重新启动接收 */ } else if (huart-Instance USART2) { RingBuffer_Write(ring2, rx_buf2, Size); } }逻辑说明这里直接信任Size作为本次新增字节数写进环形缓冲区。循环模式下 DMA 持续运转回调返回后不需要再调HAL_UARTEx_ReceiveToIdle_DMA()重启这一点和普通 DMA 接收不同漏掉这个认知会导致有人反复重启接收、把 DMA 配置打乱。参数Size的取值范围是 0 到RX_BUF_SIZE正常帧不会为 0如果调试时发现老是 0多半是波特率不匹配导致 IDLE 误触发。3.3 半传输中断造成的重复写入怎么规避上一节留了个尾巴HT 中断也会触发这个回调。在某些 HAL 版本里Size在 HT 事件下报的是「已传输一半」的累计值而不是增量直接当增量写进环形缓冲区就会重复。判断办法是看 HAL 版本行为稳妥做法是加一层去重记录上一次处理的Size如果本次Size小于上次且差值不合理就按增量重新算。更省心的方案是重写HAL_UART_OnRxEvent里的处理或者干脆不用Size做增量语义改为在回调里用「DMA 当前剩余计数」反推写指针位置。具体做法是调用__HAL_DMA_GET_COUNTER(huart-hdmarx)拿到 DMA 还剩多少没搬用RX_BUF_SIZE - 剩余得到当前写到的绝对位置再和上一次记录的绝对位置做环形差值这个差值才是真正新增的字节数。这套算法不受 HT/TC/IDLE 事件类型影响任何一次回调都能算对。static uint16_t last_pos1 0; void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { /* 用DMA剩余计数反推绝对写位置规避HT事件的Size语义歧义 */ uint16_t remain __HAL_DMA_GET_COUNTER(huart-hdmarx); uint16_t pos RX_BUF_SIZE - remain; uint16_t new_bytes; if (pos last_pos1) { new_bytes pos - last_pos1; } else { new_bytes RX_BUF_SIZE - last_pos1 pos; /* 环形回绕 */ } last_pos1 pos; RingBuffer_Write(ring1, rx_buf1[(pos RX_BUF_SIZE - new_bytes) % RX_BUF_SIZE], new_bytes); } /* USART2同理维护独立的last_pos2 */ }参数说明__HAL_DMA_GET_COUNTER返回 DMA 当前剩余待传输字节数循环模式下它从RX_BUF_SIZE递减到 0 后自动重装。pos就是缓冲区里最新写入位置的下标。环形回绕那一段是核心pos last_pos1说明这一轮 DMA 已经绕回缓冲区头部新增字节数要拆成「尾部剩余 头部新增」两段算。这段代码比直接用Size多了几行但换来的是在 HT/TC/IDLE 任意事件下都不会重复或漏算长期跑下来更踏实。4. 发送链路从回调直发到状态机队列的演进4.1 为什么不能在回调里直接调 Transmit_DMA最早的版本图省事在接收回调里直接拿Size调HAL_UART_Transmit_DMA()把数据甩给另一路串口。小流量测试一切正常压力一上来就出问题发送函数内部要检查gState状态机如果上一帧 DMA 还没发完第二次调用直接返回HAL_BUSY这一帧数据就丢了。透传链路里丢一帧可能就是一个协议包报废现场表现为「偶尔少几个字节」查起来极其痛苦。根因是HAL_UART_Transmit_DMA()不是可重入的它依赖huart-gState做互斥。回调上下文里连续触发两次第二次必然失败。另外发送缓冲区如果是局部变量DMA 还没搬完函数就返回了栈上数据被覆盖发出去的是乱码。这两个坑叠加就是「回调里直发」这个方案无法上产线的理由。正确姿势是发送侧也做一个状态机环形缓冲区里攒够数据检查发送通道空闲gState HAL_UART_STATE_READY才启动一次 DMA发完在HAL_UART_TxCpltCallback()里清标志、看还有没有待发数据有就接着发下一段。主循环里只做「搬运」不做「等待」。4.2 发送状态机与双通道调度下面这套调度逻辑放在主循环里两路各跑各的互不阻塞static uint8_t tx_buf1[TX_CHUNK_SIZE]; static uint8_t tx_buf2[TX_CHUNK_SIZE]; /* 主循环里周期调用负责把环形缓冲区的数据往对向串口搬 */ void Transparent_Process(void) { /* 方向1USART1收到 - USART2发出 */ if (huart2.gState HAL_UART_STATE_READY ring1.count 0) { uint16_t n RingBuffer_Read(ring1, tx_buf1, TX_CHUNK_SIZE); if (n 0) { HAL_UART_Transmit_DMA(huart2, tx_buf1, n); } } /* 方向2USART2收到 - USART1发出 */ if (huart1.gState HAL_UART_STATE_READY ring2.count 0) { uint16_t n RingBuffer_Read(ring2, tx_buf2, TX_CHUNK_SIZE); if (n 0) { HAL_UART_Transmit_DMA(huart1, tx_buf2, n); } } }逻辑说明TX_CHUNK_SIZE控制单次搬运的粒度取 128 或 256。粒度太小DMA 启动开销占比高太大一帧数据要等前面积压的发完才轮到增加延迟。gState判断是必要的但要注意它不是原子的主循环里单线程调用没问题如果放到 RTOS 任务里、且有其他地方也操作同一个串口就得加互斥。tx_buf1和tx_buf2必须是静态或全局的生命周期要覆盖整个 DMA 传输过程这一点不能用局部数组。发送完成回调里只做轻量处理不需要重启什么下次主循环自然会接着搬void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { /* DMA发送完成gState由HAL库自动置回READY此处仅可用于统计或指示灯 */ if (huart-Instance USART1) { tx_done_cnt1; } else if (huart-Instance USART2) { tx_done_cnt2; } }4.3 收发速率不匹配时的缓冲策略透传最怕两头速率不一致。比如 USART1 接的模块以 921600 突发发 500 字节USART2 那头只有 115200环形缓冲区瞬间被灌满多出来的数据只能丢。RingBuffer_Write的返回值在这里起作用了写不满说明缓冲区溢出得有明确的丢包策略而不是默默截断。常见做法有三种。第一种是直接丢弃超出部分简单粗暴适合上层协议自带重传的场景。第二种是覆盖最老的数据保新弃旧适合状态上报类数据。第三种是反压上游通过拉低流控引脚让对端暂停前提是硬件有 RTS/CTS 且对端支持。我一般用第一种加计数器溢出了就累加一个rx_overflow_cnt调试时读出来看链路压力。缓冲区容量按「最坏突发长度 × 2」估算比如最坏一帧 500 字节环形缓冲区就开到 1024 以上给调度留出余量。注意RingBuffer_Write里count RING_BUF_SIZE的判断在单生产者单消费者模型下是安全的但如果收发都跑在中断里、或者多个任务并发访问同一个环形缓冲区count和count--就不是原子的了必须加临界区保护关中断或互斥量否则会出现计数漂移导致缓冲区「假空」。5. 避坑五个让透传丢字节的细节5.1 现象接收正常但转发后少最后几个字节原因发送侧HAL_UART_Transmit_DMA()启动后立即返回如果此时主循环紧接着又调用一次比如另一方向恰好有数据HAL 库内部检查gState会发现上一次还没完成返回 BUSY这部分数据在RingBuffer_Read时已经从缓冲区取走了但没发出去等于丢了。现象就是每次突发结束时尾部少几个字节。解决把RingBuffer_Read和HAL_UART_Transmit_DMA的顺序调整为先确认gState READY再读并且在发送完成回调里才更新读指针。更稳妥的做法是读出不立即推进tail等TxCpltCallback确认发完再提交读指针实现「读-发-确认」三步。代码上多一个pending状态但能彻底消除这类丢失。5.2 现象运行几小时后偶发 ORE 溢出错误透传卡死原因两路串口都在高波特率下工作DMA 优先级配置不当或者某个回调里执行时间过长比如在里面做 Flash 写、或者调用了阻塞的打印函数导致 DMA 请求得不到及时响应USART 数据寄存器被新字节覆盖ORE 标志置位。一旦 ORE 置位且没清除HAL 库的接收状态机就卡在错误状态后续数据全丢。解决接收 DMA 通道优先级设为 High 甚至 Very High发送通道 MediumUSART 全局中断优先级不要高于 DMA。回调里只做内存拷贝不调任何可能阻塞的函数。另外在HAL_UART_ErrorCallback()里加恢复逻辑清 ORE 标志、重新启动HAL_UARTEx_ReceiveToIdle_DMA()让链路能自愈。这个错误回调不加现场一旦 ORE 就只能复位。5.3 现象波特率改高之后数据错位字节顺序乱原因DMA 数据宽度配成了 Half Word 或 Word而串口是字节流。外设数据寄存器是 8 位有效配成 16 位宽度后DMA 每次搬两个字节高字节是无效填充内存里数据就错位了。另一种情况是内存和外设的数据宽度配得不一致比如外设 Byte、内存 Half Word同样会错。解决DMA 配置里外设和内存的数据宽度都必须是 Byte对齐方式 Increment两个地址都递增。CubeMX 里改完记得重新生成代码手改hdma_usartx_rx.Init.MemDataAlignment容易漏。改完用示波器或者逻辑分析仪抓一下 TX 波形确认字节间隔正常。5.4 现象单路收发都正常两路同时跑就互相干扰原因两个串口的中断优先级配成一样或者 DMA 通道被分配到同一个 DMA 控制器下的冲突通道。STM32 不同型号的 DMA 通道映射不一样CubeMX 自动分配时偶尔会把两个 USART 的请求放到同一个 Stream 上虽然它会报冲突警告但有人忽略警告强行生成运行时就是一个通道抢占另一个。解决在 CubeMX 的 DMA 配置页确认每个 USART 的 RX/TX 落在不同的 DMA Stream/Channel 上冲突时手动换一个空闲通道。NVIC 里给两个 USART 分配相同抢占优先级、不同子优先级避免一方长时间占用。如果芯片 DMA 资源紧张考虑用 DMAMUX部分型号支持灵活映射或者退一步把其中一路改成中断方式。5.5 现象空闲中断触发太频繁CPU 占用不降反升原因IDLE 中断在总线每静默一个字节时间就触发一次。如果对端发送是「逐字节发送、字节间有间隔」的模式比如某些传感器按位拼包、或者软件模拟串口时序IDLE 会疯狂触发每次回调都进一次中断比轮询还费 CPU。这类场景下 DMA 的优势被抵消了。解决先确认对端是不是真的逐字节发送如果是改用「接收长度达到预设值才处理」的策略关掉 IDLE 中断只靠 DMA 半满/全满事件驱动或者用定时器做超时判断。另一种办法是在回调里加最小间隔过滤连续两次回调间隔小于阈值就合并但这属于补丁治标不治本。根本上还是要和对端协商帧格式让帧内有连续字节流。6. 压测与边界验证把波特率上限和延迟摸出来透传链路写完不等于能用得用数据把边界摸清楚。我一般会做三组测试每组都记录具体数值后面现场出问题时有对照基线。第一组是单向满速灌包。用 PC 端串口工具通过 USB 转串口往 USART1 以固定波特率连续发递增序列USART2 接另一个串口工具接收比对收发的字节数和内容。从 115200 开始每档翻倍往上试直到出现丢包或 ORE记录下稳定工作的最高波特率。这个值通常受限于 USB 转串口芯片和线材质量而不是 MCU 本身所以测试时要换几种转接板交叉验证。我这边实测下来普通杜邦线 1 米以内921600 能稳定跑再往上就得用屏蔽线、缩短走线。第二组是双向同时灌包。两路同时高速发数据观察环形缓冲区溢出计数rx_overflow_cnt。如果溢出频繁说明缓冲区容量不够或者调度粒度太粗调大RING_BUF_SIZE或减小TX_CHUNK_SIZE再测。这一组能暴露单路测试发现不了的 DMA 通道争用问题前面 5.4 那个坑就是这么抓出来的。第三组是延迟测量。在 USART1 收到一个特定标记字节时翻转一个 GPIO在 USART2 发出这个字节时再翻转同一个 GPIO用逻辑分析仪测两个边沿之间的时间差。这个延迟由「IDLE 判定时间 回调处理 主循环调度间隔 发送 DMA 启动」四段组成正常在几十微秒量级。如果测出来是毫秒级多半是主循环里有其他耗时任务把Transparent_Process()的调用间隔拉长了得把它挪到定时器中断或者提高调度频率。/* 延迟测量用的GPIO翻转放在接收回调和发送完成回调里 */ void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_SET); /* 收到即拉高 */ /* ...原有写环形缓冲区逻辑... */ } } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_0, GPIO_PIN_RESET); /* 发完拉低 */ } }这段测量代码只在调试阶段加测完记得删掉GPIO 翻转本身也会引入几微秒开销长期跑没必要留着。最后一个习惯每次改完 DMA 配置或者缓冲区参数我都会把三组测试重跑一遍哪怕只改了一个数字。透传链路的问题往往不是逻辑错而是时序和容量在边界上的微妙失衡改一个参数可能把原来隐藏的溢出暴露出来。从那以后我每次调串口参数都强制走一遍压测流程哪怕只是把波特率从 115200 改到 230400。希望这套配置加代码骨架能帮你少走几个弯路把双串口 DMA 互透传一次跑稳。本文还有配套的精品资源点击获取