STM32串口不定长接收：DMA+空闲中断方案详解与避坑指南-北京尧图网络

搞嵌入式的人迟早都会遇到这么一件事MCU 串口收到的数据不是定长的。可能是 AT 指令那种“以 \r\n 结尾”的文本帧可能是 Modbus 那种“每次几十字节但长度不确定”的报文也可能是传感器模块随机吐出来的一段不定长数据。如果用查询或者单字节中断去处理短报文没问题数据一多、系统任务一多CPU 就被串口数据拖着走原本用来做控制、滤波、显示的时间全被挤没了。这篇文章要说的就是 STM32F103 上一种非常经典、也非常实用的串口收法DMA 搬运串口空闲中断IDLE判帧一次性解决“不定长接收”和“CPU 被频繁打断”两个问题。整个方案用 HAL 库实现配合 CubeMX 生成工程代码量不大稳定性却非常可靠。适合刚入门 STM32 但想跳过“轮询收发”阶段的朋友也适合已经在做项目、想把手头的串口程序从“中断收一个字节”改成“一帧一帧收”的同学。我自己在多个电磁阀控制项目、传感器采集项目里都用这套方案跑数据实测 115200 波特率下连续传几百 K 字节不出错CPU 占用也比“每字节中断”低了一个量级。下面我把整个方案从原理到代码、从踩坑到验证完整拆开讲一遍。1. 项目需求与方案选型为什么必须上 DMA 空闲中断1.1 串口接收的三个痛点越做项目越明显很多从 51 或者标准库入门的朋友第一次做串口收发普遍是这样的套路HAL_UART_Receive_IT收一个字节进中断每次进中断丢进一个自己的数组攒够固定长度再去解析。这个套路在协议固定、通信量小的时候没什么问题但它有三个很现实的痛点第一是CPU 被打断的频率太高。115200 波特率下大约 11.5 微秒就有一个字节进来也就是说 CPU 每 11 微秒就要被中断一次。如果系统里还有定时器、ADC、外部中断这些任务中断越嵌套越深主循环反而被挤得没法干活。这种场景下你调一个 PID 都可能因为串口中断太多导致控制周期抖动。第二是不定长数据没法“攒够固定长度再处理”。很多协议的帧长是可变的比如“帧头长度字节数据校验”解析的前提是知道这一帧在哪结束可单纯靠接收中断你并不知道帧尾在哪。常见的笨办法是每次收一个字节就启动一个超时定时器超过几个毫秒没新数据就当帧结束能凑合用但代码会很绕。第三是接收缓冲区不好管理。如果你的设备要连续处理好几帧数据手动维护数组读写下标非常容易出 bug——收快了丢帧收慢了覆盖调到最后自己在哪儿改的都不知道。这三个痛点凑到一块DMA 空闲中断就成了 F103 上性价比最高的解法。我们做项目的本质是“用硬件能完成的活就别让 CPU 做”串口数据搬运是典型的内存拷贝类工作DMA 天生就是干这个的而帧什么时候结束USART 外设本身就有个“线上空闲”的事件可以告诉我们。两者一组合CPU 要做的事就只剩“收到一帧完整数据后去解析”了。1.2 三种串口接收方案横向对比接收方式CPU 开销不定长支持代码复杂度适合场景轮询查询 RXNE极高全程死等需配合超时判断简单调试用、极低速通信单字节接收中断高每字节进一次中断需软件攒帧中等短报文、低频通信DMA 空闲中断极低一帧只进一次中断硬件判帧结束天然支持中等偏低数据量中等以上、协议不固定帧长DMA 接收定时器超时低需定时器配合支持适合帧间间隔不定偏高帧间隔不明确、需要时间窗口切割从上表能看出来DMA 空闲中断的核心优势在于“一帧数据只触发一次处理”整个数据搬运过程 CPU 完全不参与。空闲中断又是串口硬件自己检测的——接收线上超过一个字节时间没有新数据硬件自动拉高 IDLE 标志。这个特性拿来切分不定长帧极其顺手设备端一次性把一串数据发过来线上数据流结束的瞬间空闲中断就到了。1.3 F103 的硬件基础快速过一遍相关外设STM32F103 是 Cortex-M3 内核主频 72MHz但型号之间差异不小。做串口 DMA 方案时你最需要关注的是 DMA 控制器和外设的对应关系推荐拿中型以上型号比如 STM32F103C8T6/RBT6/ZET6它们都有两个 DMA 控制器。USART1 的收发通道固定挂在 DMA1 上TX 是 DMA1 通道 4RX 是 DMA1 通道 5。如果用的是 USART2/3对应的通道编号也不同这个后面我会专门提一句。另一个值得留意的点是F103 的 DMA 不支持缓冲区半满中断和全满中断之外的 Third 级模式多缓冲就是它没有链表式的外设到内存联动所以我们在程序设计上要用“循环缓冲区 NDTR 寄存器剩余计数”来推算一帧数据在缓冲区的实际位置。这部分是代码的核心我会在后面的原理拆解里详细展开。2. 硬件准备与 CubeMX 工程搭建2.1 最小系统连接与硬件选型建议选 STM32F103C8T6蓝板或者自制最小系统都很常见网上几块钱就能找到或者 RBT6 的核心板。串口通信走 PA9USART1_TX和 PA10USART1_RX直接接 USB-TTL 的 RX 和 TX交叉连接共地波特率默认 115200。如果是自制最小系统注意给芯片配上 8MHz 晶振和 2 个 22pF 负载电容STM32 内部虽然也有 HSI 振荡器但做通信项目还是用 HSE PLL 倍频到 72MHz 更稳。调试工具方面ST-Link V2 是首选SWD 四线SWDIO、SWCLK、GND、3.3V就能下载和调试。如果你手头只有串口 ISP也可以用 FlyMcu 烧录但调试效率会低不少建议有条件还是上 ST-Link。这里补充一个硬件层面的细节USART 和 DMA 的中断都归 NVIC嵌套向量中断控制器管CubeMX 里勾选即可不需要额外接外部中断线。DMA 通道和串口是硬绑定的不用查原理图选通道是芯片设计好的固定映射关系。2.2 CubeMX 串口和 DMA 的具体配置打开 STM32CubeMX选好芯片型号后直接点击 PA9 和 PA10 引脚在弹窗里选USART1_TX和USART1_RX这一步会让两个引脚自动切换到复用功能。然后左侧分类里进Connectivity - USART1模式选 Asynchronous异步模式波特率填 115200数据长度 8 Bit一般配合无校验校验位 None停止位 1 Bit上面这些是常规配置真正决定方案成败的是下面两项DMA 设置和NVIC 设置。在 USART1 配置页切到 DMA 选项卡点击 Add发送通道选USART1_TX方向MemoryToPeripheral接收通道选USART1_RX方向PeripheralToMemory两个 DMA 通道的模式都选 Normal 或 Circular这里很有讲究。接收通道必须选 Circular循环模式因为不定长帧什么时候来、来几帧都是不可预知的循环模式可以让 DMA 自动绕着缓冲区连续写入我们靠 NDTR 判断新数据位置发送通道选 Normal 模式每次发送前重新设置长度发送完成自动停止这样最干净。DMA 数据宽度外设和外设宽度都选 Byte传输字节序选 Byte8位地址增量方面内存地址打勾 Increment Address外设地址不打勾因为外设数据寄存器地址是固定的。优先级设 Medium 或 High 都行F103 上串口速率不高优先级影响不大但建议接收比发送高半级。NVIC 设置页面里打开 USART1 global interrupt 和 DMA1 channel4/5 interrupt。这一步很多人漏掉导致代码里HAL_UART_Receive_DMA启动后不进回调排查半天发现只是中断没开。2.3 生成工程的 HAL 库版本与兼容性处理CubeMX 版本不同生成的 HAL 库代码会有细微差异。新版本的 HAL 库比如 1.11.x 之后提供了HAL_UARTEx_ReceiveToIdle_DMA这个函数把“空闲中断 DMA 接收”打包成了一个接口回调是HAL_UARTEx_RxEventCallback比较省事。老版本比如 1.6.x 或更早没有这个 API需要我们自己在USART1_IRQHandler里手动处理空闲标志。我下面的代码会给一个手动处理空闲中断的通用写法也附一个新版 API 的使用方式。通用写法不依赖库版本任何一个带标准 HAL 的 F103 工程都能直接抄建议读者优先采用。CubeMX 生成时注意选 “Copy only the necessary library files” 可以把 HAL 库裁剪得更小生成后打开 Keil 工程确认一下 Device 型号和 C/C 的宏定义STM32F103xB等是否匹配。2.4 F103 时钟树与波特率精度CubeMX 默认外部晶振 8MHz进 Clock Configuration 页面把 HCLK 配置到 72MHzAPB2 外设时钟保持 72MHzUSART1 挂在这个总线上APB1 保持在 36MHz。只要这里没配错USART1 在 115200 波特率下误差小于 0.1%基本不会出现乱码。顺带说一句很多人调试串口时发现“打印乱码”十有八九是时钟树没配置或者 USB-TTL 转出来的波特率和你设置的波特率不一致。先用逻辑分析仪看波形或者用串口助手自带的“HEX 显示”看一下数据格式是不是 AA 55 这种固定字节能快速判断是硬件连线问题还是时钟问题。3. DMA 收发逻辑拆解数据是怎么在芯片里流动的3.1 DMA 搬运的本质外设到内存的“搬家公司”DMA 这个东西翻译成“直接内存访问”有点生硬我更喜欢叫它“数据搬家公司”。你要做的是告诉搬家公司“把 USART 接收数据寄存器里的字节搬到内存这个地址去”“搬多少字节”然后你就可以去干别的了。每到一个字节搬运工自动搬一次全部搬完或者缓冲区处理完一圈再通知你一声。这其中的关键不是“自动搬”而是“搬运过程中 CPU 不用管”。在没有 DMA 的 MCU 上每个字节到串口后 CPU 都要去读 DR 寄存器再存到内存这期间 CPU 不能干别的。有了 DMA发送方向也一样——你只要把内存里一块缓冲区的地址告诉 DMA它自己会把数据逐个塞到串口往外发发完你再收到“发送完成”的通知。F103 有两个 DMA 控制器DMA1 负责所有 USART、SPI、I2C、TIM 的常规通道DMA2 主要给 ADC 和 SDIO。串口 1 的收发通道分别是 DMA1 通道 4 和 5。做工程前先把这张映射表刻在脑子里很多时候板子没反应排查到最后发现就是 DMA 通道加错或者映射关系搞混了。3.2 空闲中断IDLE判帧的原理线上一静帧就结束串口空闲中断是个平时没什么存在感、用对了非常爽的功能。它的触发条件非常简单USART 接收线上持续一个字节时间没有收到任何新数据。也就是说单片机端接收完一个字节后如果之后没有紧跟着下一个字节硬件就认为“线路空了”拉高 IDLE 标志触发中断。对于一个典型的设备响应帧设备侧通常在发完最后一个字节之后不会再立刻回复下一帧两帧之间至少会有几个毫秒的间隔。对 115200 波特率来说一个字节时间是 86.8 微秒只要两帧间隔大于一个字节时间空闲中断就能准确地把帧尾切出来。这比定时器超时判帧有个天然优势它是硬件自动的不需要你手动开定时器、清定时器、比较时间戳。只要你协议里帧与帧之间有间隔哪怕只有几百微秒它也能稳稳地切开。如果协议是“背靠背”连续不停发数据、帧间隔小于一个字节时间那不管用什么方案都没法在硬件层切分只能靠协议里的长度和帧头去软件切——这一点大家做协议设计时心里有数就行。3.3 接收缓冲区状态机一帧进来之后发生了什么整个接收流程其实就是一个小型状态机状态只有三个空闲状态没有数据在接收DMA 持续等待缓冲区里全是旧数据。接收状态DMA 正在把新数据往缓冲区里搬此时缓冲区的位置在往前走用户程序不动缓冲区。帧完成状态空闲中断触发我们把“当前 DMA 写到哪了”记下来打开“帧就绪”开关让主循环来取。主循环看到“帧就绪”就把缓冲区里从上一帧结束位置到当前结束位置之间的数据复制出来解析。注意这里的复制必须快如果主循环处理太慢、下一帧又来了数据就会覆盖掉没解析完的内容。这也是做这套方案时唯一要重点保护的地方。后面我会给一个“帧完成标志分析后清标志”的机制来保证安全。4. 核心代码实现与逐段解读4.1 串口与 DMA 初始化代码CubeMX 会生成MX_USART1_UART_Init和MX_DMA_Init两块初始化我们不需要大改但要在自己的用户代码里补一段“接收缓冲区初始化”。以最简单的写法为例/* 定义接收缓冲区和状态标志 */ #define RX_BUF_SIZE 256 uint8_t rx_buffer[RX_BUF_SIZE] __attribute__((aligned(4))); // 4字节对齐DMA搬运效率更高 volatile uint16_t rx_ndtr_last 0; /* 上次帧结束时 DMA 剩余计数 */ volatile uint8_t rx_frame_ready 0; /* 一帧数据就绪标志 */ /* 用户初始化函数CubeMX生成的MX_*之后调用 */ void UART_DMA_RX_Init(void) { /* 清统计变量 */ rx_ndtr_last RX_BUF_SIZE; rx_frame_ready 0; /* 启动 DMA 循环接收 */ HAL_UART_Receive_DMA(huart1, rx_buffer, RX_BUF_SIZE); /* 启动空闲中断处理手动开USART的IDLE中断允许位 */ __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); }__attribute__((aligned(4)))看着是个细节实际很重要。F103 的 DMA 搬运 8 位数据时对地址对齐要求没那么严格但我见过不少板子因为数组定义没对齐导致 DMA 传输错位的案例统一在数组声明时加上 4 字节对齐是省心做法。4.2 空闲中断回调手动处理 IDLE 标志的正确姿势老版本 HAL 库中HAL_UART_IRQHandler不会处理空闲中断所以我们必须先调用它处理常规的接收错误、发送完成等中断再自己判断 IDLE 标志。这一步的代码是整套方案最核心的部分void USART1_IRQHandler(void) { /* HAL 库标准处理函数处理RXNE、TC、ORE等 */ HAL_UART_IRQHandler(huart1); /* 空闲中断标志检测 */ if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { /* 清除 IDLE 标志先读SR再读DR */ __HAL_UART_CLEAR_IDLEFLAG(huart1); /* 计算当前DMA还剩多少个字节没搬据此推算已接收数据长度 */ uint16_t ndtr_now __HAL_DMA_GET_COUNTER(hdma_usart1_rx); if (ndtr_now ! rx_ndtr_last) { /* 新一帧到达根据循环缓冲区的位置关系计算这帧数据的位置和长度 */ uint16_t rx_len (rx_ndtr_last - ndtr_now RX_BUF_SIZE) % RX_BUF_SIZE; /* 将帧就绪信息交给主循环处理 */ g_rx_frame_len rx_len; g_rx_frame_start rx_ndtr_last % RX_BUF_SIZE; rx_frame_ready 1; rx_ndtr_last ndtr_now; } } }这个函数里有两个细节解释一下。第一为什么要读 NDTR 计数器。DMA 工作在循环模式时缓冲区会被反复从头写到尾。ndtr寄存器保存的是“还剩多少字节没搬完”RX_BUF_SIZE是总大小两者相减就是已经写入的字节数。上一帧结束时我们记住的rx_ndtr_last和现在的ndtr_now对比中间差值就是新收到的长度。如果 DMA 绕了一圈差值加一个RX_BUF_SIZE再取模正好等于实际数据长度数学上完美闭环。第二为什么先读 SR 再读 DR。这是 STM32 参考手册里对清除 IDLE 标志的硬性要求先读状态寄存器SR再读数据寄存器DR硬件才会把 IDLE 标志清掉。__HAL_UART_CLEAR_IDLEFLAG(huart1)这个宏内部实际做的就是read SR再read DR所以你直接调宏也没问题但我们必须知道它为什么这么做不然将来换老库或者裸机标准库时就会卡住。4.3 主循环里安全地处理帧数据中断里只管置标志位和拷贝数据指针用户代码在主循环里看到标志后再处理。最简单的处理方式是这样uint8_t process_frame(uint8_t *data, uint16_t len) { /* 解析流程根据你自己的协议写 */ /* 演示打印收到的长度 */ printf(Recv %d bytes\r\n, len); HAL_UART_Transmit_DMA(huart1, data, len); return 0; } void main_loop(void) { while (1) { if (rx_frame_ready) { rx_frame_ready 0; /* 先清标志再处理防止重入 */ uint8_t *frame_data rx_buffer[g_rx_frame_start]; uint16_t frame_len g_rx_frame_len; /* 如果一帧数据跨过了缓冲区尾部需要拆成两段处理 */ if (g_rx_frame_start frame_len RX_BUF_SIZE) { uint16_t first_part RX_BUF_SIZE - g_rx_frame_start; process_frame(rx_buffer[g_rx_frame_start], first_part); process_frame(rx_buffer[0], frame_len - first_part); } else { process_frame(frame_data, frame_len); } } /* 其他任务 */ } }这里最容易被忽略的问题是缓冲区回绕wrap-around。DMA 循环接收数据写满缓冲区后会从头再写。如果某一帧恰好跨过了缓冲区尾部它在内存里就不是连续的一块而是“尾段头段”两段。不处理回绕直接按照地址去解析就会把不相关的旧数据也当成帧内容解出来的东西完全不对。我上面代码里的if (g_rx_frame_start frame_len RX_BUF_SIZE)分支就是干这个的这种细节你自己跑几天可能都碰不到但一旦数据量大了迟早会出问题。另一个细节是rx_frame_ready 0一定要放在处理之前。如果放在处理之后处理期间又来了新帧中断把标志置 1处理完旧帧后你顺手清 0 会把新帧标志一起清掉导致丢帧。先清标志再干活这是嵌入式多任务协作的黄金习惯。4.4 DMA 发送两种方式与 TX 完成回调发送方向我实际项目中两种方式都在用。简单短报文直接阻塞发送就行但长一些的数据建议用 DMA 发送免得 CPU 在那里死等。阻塞发送HAL_UART_Transmit(huart1, tx_data, tx_len, 1000); /* 1秒超时 */DMA 发送HAL_UART_Transmit_DMA(huart1, tx_data, tx_len);注意 DMA 发送有个常见陷阱在上一帧 DMA 还没发完的时候再次调用HAL_UART_Transmit_DMA会导致数据混乱。解决方法是靠发送完成回调做一个“忙标志”volatile uint8_t tx_busy 0; void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { tx_busy 0; /* DMA 发送完成 */ } } uint8_t uart_send_dma(uint8_t *buf, uint16_t len) { if (tx_busy) return 1; /* 忙拒绝发送 */ tx_busy 1; HAL_UART_Transmit_DMA(huart1, buf, len); return 0; }发送完成后tx_busy清零主循环里就可以继续发下一帧。实测中 DMA 发送 512 字节在 115200 波特率下需要约 44 毫秒这期间 CPU 完全可以去做别的事。注意 DMA 发送的buf在发送完成之前不能被改写所以如果要发的数据是局部变量或者频繁改动的全局数组最好先把数据拷到独立发送缓冲区再启动 DMA——这个和接收缓冲区加volatile是同一类“防止编译器和执行顺序给你挖坑”的问题。4.5 新版 HAL 库的简化 APIReceiveToIdle_DMA 怎么用如果你用的是 CubeMX 生成的较新工程HAL 库版本高于 1.11可以直接用HAL_UARTEx_ReceiveToIdle_DMA内部就把空闲中断和 DMA 接收整合好了。用法如下/* 启动接收 */ HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buffer, RX_BUF_SIZE); /* 回调函数 */ void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { /* Size 就是空闲中断触发时收到的字节数 */ uint8_t *frame_data rx_buffer; uint16_t frame_len Size; /* 处理帧 ... */ /* 继续启动下一次接收 */ HAL_UARTEx_ReceiveToIdle_DMA(huart1, rx_buffer, RX_BUF_SIZE); } }这个 API 的好处是简洁但有两个限制第一它要求接收缓冲区在每次触发后就“手动重新启动”如果没有在回调里再次调用启动函数后续数据就不会继续接收第二它内部的空闲中断处理逻辑在不同 HAL 版本上略有差异某些旧版本存在 IDLE 标志清除时序的 bug。所以我个人建议如果项目刚起步、没有历史代码包袱直接使用手写的 IDLE 中断方案所有逻辑都在自己眼皮底下出了问题能查得清清楚楚。5. 实测过程与调试记录5.1 测试环境与用例设计我手头的测试硬件是自制的 F103ZET6 核心板一个 CH340 USB-TTL 小板电脑上用串口调试助手往板子发数据。测试分四类测试项目数据内容预期结果定长短帧发 8 字节间隔 100ms 发 1000 次每次正确收到 8 字节无丢失无错位不定长帧随机长度 1~200 字节间隔 50ms按帧切分正确长度与发送端一致高速连续帧每 2ms 发 100 字节持续 5 秒无覆盖无丢帧帧分割正确回环测试接收数据原样 DMA 发送回上位机上位机收到的数据与发送内容一致实测下来前两类测试毫无悬念地过了。第三类测试暴露了一个问题如果主循环解析速度跟不上接收速度即使 DMA 不丢数据缓冲区也可能被绕过来覆盖。解决办法是增大缓冲区从 256 扩到 1024同时把主循环里的解析逻辑做好优先级保障。第四类回环测试用 512 字节长帧时出现了 TX 重入问题原因就是上一帧 DMA 没发完就开始发下一帧加了tx_busy保护后解决。5.2 逻辑分析仪抓波形验证时序调试串口最直观的手段是逻辑分析仪不需要很贵的型号几十块钱的 8 通道分析仪就可以。把通道接在 USART1_TX 引脚上上位机用分析仪自带的串口协议解析功能能看出每一帧数据的实际波形和字节间隔。我实际抓过一次连续 3 帧数据的波形帧与帧之间的间隔大约 1.5ms而一帧内部字节间隔不到 10 微秒。这种间隔差异正是空闲中断能准确切帧的依据。如果你看不到空闲中断触发可以先把两帧间隔拉大到几十毫秒确认方案通了之后再缩短间隔逐步逼近极限。5.3 缓冲区大小和帧间隔的匹配原则缓冲区设多大没有绝对答案要根据你的最大帧长、帧速率和主循环处理耗时来定。我的经验公式是缓冲区至少大于最大帧长的 2 倍且在极限帧速率下主循环解析一帧的时间必须小于一帧的到达间隔。比如最快每 2ms 来一帧 100 字节的帧而主循环耗时超过 2ms那缓冲区再大也白搭必须优化解析流程。更稳妥的做法是双缓冲Ping-Pong这个我在下一章详细说。6. 常见问题与避坑实录6.1 第一帧数据总是丢很多人都遇到过这个问题板子上电后第一次发数据没反应第二次开始就正常了。原因通常是HAL_UART_Receive_DMA是在串口初始化之后才启动的而设备端可能在初始化完成之前就已经发数据了DMA 没启动自然收不到。解决方法是上电后尽快启动 DMA 接收如果你的硬件上电时序允许把UART_DMA_RX_Init()放到主循环开头调用或者在初始化完成后发一帧无关数据刷新一下。另一个隐蔽原因是空闲中断标志复位问题。CubeMX 生成的初始化流程里串口外设复位时 IDLE 标志可能是置位的第一次进入中断时去读 NDTR 发现是全缓冲区长度导致误判。这属于 HAL 库版本差异问题我在代码里用rx_ndtr_last初始化为RX_BUF_SIZE就是为了让第一次空闲中断时的长度计算为 0从根本上避开这个问题。6.2 接收内容乱码或者字节错位排查顺序一定是先查波特率再查接线最后查 DMA 配置。波特率方面重点看时钟树是否 72MHz如果 APB2 变成 36MHz 而配置还是按 72MHz 算出来的波特率就是错一半。接线方面重点查 TX-RX 交叉和共地很多人 USB-TTL 没接 GND导致偶尔能通、数据不全。DMA 配置方面重点查通道映射是否是美国USART1的DMA1通道4/5方向是否设反。此外还有一个小概率问题SPL 标准库时代常遇到HAL_UART_Receive_DMA的 LENGTH 参数和数据宽度不匹配——F103 DMA 外设数据宽度设为 Byte 时长度就是字节数设为 Half Word 时长度是半字数。我们配置里全用 Byte 就最简单。6.3 中断优先级设置不当导致的帧丢失NVIC 里如果 USART1 中断优先级低于某个频繁触发的中断源空闲中断可能一直被延后。但空闲中断属于“延后最多丢一帧边界”不至于造成系统崩溃可若你的系统里有高频率的外部中断比如旋转编码器每毫秒触发一次且优先级比串口高串口接收帧间隔又短那丢帧是必然的。我给的做法是接收相关中断UART DMA RX优先级设为最高或者次高发送 DMA 中断设为低一级其他外设尽量让路。毕竟串口通信一旦乱序排查成本远高于其他外设。6.4 缓冲区溢出与双缓冲策略数据量较大、或者主循环处理时延不确定的项目建议别省这个功夫直接上双缓冲。思路是开两个同样大小的缓冲区DMA 交替往 A/B 里写主循环解析 A 时 DMA 写 B解析 B 时 DMA 写 A。判断 DMA 当前写到哪个缓冲区看 NDTR 落在 A 还是 B 的范围内即可。这样即使主循环处理慢了一帧也不会马上覆盖还没解析的数据系统容忍度大大提升。付出的代价只是两倍 RAM而在数据处理类项目里这个内存换稳定性是完全值得的。#define BUF_SEG_SIZE 256 uint8_t rx_buf[2][BUF_SEG_SIZE]; void USART1_IRQHandler(void) { /* HAL处理 */ HAL_UART_IRQHandler(huart1); if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); uint32_t ndtr_now __HAL_DMA_GET_COUNTER(hdma_usart1_rx); /* 判断落在哪个半段 */ uint8_t seg_index (ndtr_now BUF_SEG_SIZE) ? 1 : 0; /* 该半段接收完成交给主循环处理下一段继续接收 */ g_active_seg seg_index; rx_frame_ready 1; } }双缓冲的关键是DMA 缓冲区和逻辑分段必须保持一致。用一个大数组人为切成两半还是直接用两个数组效果一样但要注意 NDTR 在循环模式下是一个递减计数器切分时用ndtr_now BUF_SEG_SIZE就能判断当前写入位置落在第二段还是第一段这个边界条件建议在代码注释里写清楚不然过了两个月自己都看不懂。6.5 容易被编译器坑的 volatile 问题只要中断和主循环共用一个变量就必须加volatile修饰这不是风格问题是 C 标准规定的语义问题。比如rx_frame_ready如果编译器在某个循环里把它优化成寄存器副本那中断里改成 1 主循环根本感知不到。我见过有人把这个标志去掉 volatile 之后程序运行几分钟就“死掉”其实是中断一直在被触发但主循环看不到标志缓冲区越积越满。养成习惯所有中断和主循环共享的标志变量、计数变量一律加 volatile没有一个例外。6.6 空闲中断标志清除顺序的坑__HAL_UART_CLEAR_IDLEFLAG在 HAL 里是个宏它扩展成读 SR 再读 DR。但如果你使用的库版本比较旧这个宏可能写得不对只清了 SR 没读 DR结果标志永远清不掉中断触发一次之后就不再触发后续帧了。遇到这种情况的解决办法是手动写清除代码/* 手动标准清除读SR读DR */ uint32_t tmp huart1-Instance-SR; tmp huart1-Instance-DR; (void)tmp; /* 防止编译告警 */放到代码里替换宏调用。这也是为什么我在 4.2 节建议直接使用标准库的“读两次”写法不让 HAL 宏替你猜。F103 的串口是还是老架构SR/DR 读时序本身就是一种协议读懂它就是真正吃透这套方案。6.7 当帧间隔不足一个字节时间时的补救前面说过如果设备端连续发两个不同的帧中间间隔小于一个字节时间115200 下约 87 微秒空闲中断是切不开这两帧的。这属于方案本身的适用范围限制。补救的办法是调整协议层让发送端在帧与帧之间强制加至少 1 个字节的间隔比如两帧之间发一个空字节或空闲字符或者改成软件超时判帧或者要求发送端发完一帧后等待接收端回应再发下一帧。实际项目里我最常用的是最后一种主从一问一答天然规避不定长帧的黏连问题。7. 这套方案还能怎么延伸DMA 空闲中断的思路不仅限于 STM32F103它本质上是“硬件外设 DMA 硬件事件判帧”的组合。换到 GD32、AT32、HC32、APM32 这些国产芯片上原理完全一样只是寄存器名和 DMA 通道映射略有差别。前阵子我在 GD32F303 和 HC32F460 上也复现了同样的方案发现国产芯片对“读 SR 再读 DR 清标志”的处理和 ST 的坑几乎一模一样只要你理解了 F103 的这套逻辑换芯片的成本极低。另一个延伸方向是多串口同时使用。F103 有多个 USART每个串口都可以独立挂 DMA。只要 RAM 够用把每个串口的接收缓冲区开好中断里分别判断实例就能让一个 MCU 同时打理好几路串口设备。我在一个传感器采集项目里就是这样用的USART1 接 4G 模块USART2 接 GPSUSART3 接主控通信三路全部走 DMA 空闲中断主循环统一调度几十个小时连续运行不出问题。随着数据量增长你还会碰到“怎么把收到的二进制帧可靠地存到 Flash 或者转发到另一个接口”这类问题那属于业务层的设计范围。但只要底层这套串口收发的骨架是稳的上层的业务逻辑怎么改都有保障。说实话串口是嵌入式最基础也最不可或缺的接口。哪天你调试一个电路板打印不出日志、收不到数据第一反应一定先查串口。把串口收发做得又稳又省 CPU能为你后面所有项目省下大量的调试时间。这套 DMA 空闲中断不定长接收的方案是我个人在 F103 上用得最多、也最推荐新手掌握的一套串口代码希望看了这篇拆解和避坑记录之后你也能在自己板子上跑起来少走几年弯路。

STM32串口不定长接收：DMA+空闲中断方案详解与避坑指南

相关推荐

让AI输出难读的6个习惯清单：asd-ste100-skill扫描检查表，人人可立即上手

NumPy 入门：掌握 Python 数据处理的基础能力

插件开发实战：从plugin.json到TypeScript SDK与CLI全解析

更多资讯

DeepSeek V4 + Claude Code thinking mode 400 错误修复方案：TaoToken 统一 Key 通道配置指南

多GPU机架怎么搭？openrig开源框架从选型到理线的完整实战

Vista.js 路由完全指南：文件路由、动态参数与嵌套布局一次讲透

AI agent软件安装总失败？把endpoint改到TaoToken的排查清单

基于MCP（模型上下文协议）的招聘推荐业务架构设计：TaoToken统一Key接入AI Agent实践

IDE插件机制深度解析：从activationEvents到CLI协同

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？