STM32 HAL库SBUS接收实战：DMA循环+IDLE中断+状态机解析

SBUS 这个协议在航模和机器人圈子里太常见了接收机出来一根线一根信号线就能拿到十几个通道的遥控数据接线简单、抗干扰也还行。但真到 STM32 上用 HAL 库去接它很多人第一版代码都会翻车——要么数据断断续续要么帧对不齐要么 CPU 被串口中断拖死。我前后在 F103 和 F407 上都做过 SBUS 接收最后稳定下来的方案就是DMA 循环接收 串口 IDLE 中断 状态机解析这套组合。下面把我踩过的坑、参数怎么算、状态机怎么设计完整讲一遍。1. 先把 SBUS 的物理层和帧格式吃透1.1 为什么 SBUS 不能直接接普通串口SBUS 是 Futaba 定义的串行总线协议物理层是反相 UART波特率100000 bps8 个数据位2 个停止位偶校验8E2。注意这里有两个反直觉的点第一它的电平是反的普通串口空闲是高电平SBUS 空闲是低电平第二波特率是 100k 而不是常见的 115200。所以硬件上你必须做两件事之一要么用一个反相电路一个三极管加两个电阻就能搞定要么直接用 STM32 的串口反相功能。F0、F3、F7、G0、G4、H7 这些系列的 USART 支持硬件反相配置USART_CR2里的RXINV和TXINV位就行但F1 和 F4 的 USART 不支持硬件反相这是很多人第一次做 F103/F407 SBUS 时最容易被卡住的地方。我最早在 F103 上就是没注意这点接上去一个字节都收不到示波器一看波形全是反的后来加了个反相三极管才通。如果你用的是 F1/F4反相电路推荐用 2N7002 或者 S8050 这类小管子基极串 1k 电阻集电极上拉 10k 到 3.3V信号从集电极取。实测这个电路在 100k 波特率下边沿足够干净不需要额外整形。1.2 一帧 25 字节到底装了什么SBUS 一帧固定25 字节帧头0x0F帧尾0x00部分接收机是0x04或0x14取决于是否触发 failsafe 和 frame lost 标志。中间 22 字节承载 16 个通道每个通道 11 位按小端位序紧密排列。具体拆法是这样的22 字节 176 位16 通道 × 11 位 176 位刚好对齐。解析时把 22 字节当成一个 176 位的位流从低位往高位依次切出 16 个 11 位数据。每个通道原始值范围是172 到 1811中位大约 992。换算成百分比或者 PWM 脉宽时用这个公式channel_us (raw - 172) * 1000 / (1811 - 172) 1000也就是把 172~1811 线性映射到 1000~2000 微秒。这个换算在做舵机控制或者电机混控时是必须的直接拿原始值去算会偏。第 23 字节是标志位bit0 是 frame lostbit1 是 failsafebit2 是 failsafe 激活。第 24 字节在部分协议版本里是 RSSI 或者预留。实际解析时我一般只关心帧头帧尾和标志位中间 22 字节直接丢给状态机。注意不同厂家的接收机帧尾可能不一样有的固定 0x00有的在失控时变成 0x04。如果你写死只认 0x00失控时就收不到帧了。稳妥做法是帧尾只做参考主要靠帧头 0x0F 和长度 25 来同步。2. 为什么选 DMA 循环接收而不是中断逐字节收2.1 中断逐字节收的致命问题SBUS 一帧 25 字节100k 波特率下每字节 10 位1 起始 8 数据 1 停止偶校验其实占 1 位实际是 11 位含校验算下来一帧大约 2.75ms每字节间隔约 110us。如果用HAL_UART_Receive_IT逐字节收每 110us 就进一次中断一帧进 25 次接收机以 14ms 周期发帧的话平均每秒进中断约 1800 次。这个频率本身不算高但问题在于HAL 库的中断回调里有大量状态判断和锁操作实际开销远大于理论值而且一旦你在回调里做解析主循环就被拖住了。更麻烦的是逐字节中断收在帧与帧之间没有明确的边界你得靠字节计数来对齐一旦丢一个字节后面全乱而且很难恢复。我早期就是这么写的飞控一上电数据就飘查了半天发现是某次中断延迟导致丢字节帧同步彻底崩了。2.2 DMA 循环模式的核心优势DMA 循环接收Circular Mode的思路是让 DMA 在后台把串口数据源源不断地搬进一个环形缓冲区CPU 完全不参与搬运。缓冲区大小设成25 的整数倍比如 50 或者 100 字节。这样无论帧从哪个位置开始DMA 都会一直往里填不会溢出只要 CPU 及时处理。配置上在 CubeMX 里把 USART 的 DMA 接收通道打开模式选Circular数据宽度 Byte优先级中等即可。然后调用HAL_UART_Receive_DMA(huart2, sbus_rx_buf, SBUS_BUF_SIZE);这一句调用之后DMA 就一直在后台跑你不需要再管它。缓冲区我一般设 50 字节也就是两帧的长度这样即使处理稍有延迟也不会覆盖正在解析的帧。2.3 循环缓冲区的读写指针怎么管DMA 循环模式下硬件会不断更新NDTR寄存器表示还剩多少字节没搬。当前写入位置可以用write_pos SBUS_BUF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart2_rx);读指针由我们自己维护。每次 IDLE 中断触发时从读指针读到写指针处理完更新读指针。因为是循环的读指针追上写指针时要绕回。这里有个细节读指针和写指针相等时无法区分空和满所以要么留一个字节不用要么用 IDLE 中断来界定处理边界。我选后者因为 SBUS 帧之间有明显的空闲间隔IDLE 中断天然就是帧边界。3. IDLE 中断帧边界的天然信号3.1 IDLE 中断到底在什么时候触发串口 IDLE 中断的触发条件是接收完一个字节后总线保持空闲状态超过一个字节传输时间。对 SBUS 来说帧内字节是连续发的帧与帧之间有明显的间隔接收机每 14ms 发一帧帧本身只占 2.75ms剩下 11ms 都是空闲。所以每帧结束都会触发一次 IDLE 中断这正好是我们要的帧边界。配置上在HAL_UART_Receive_DMA之后手动使能 IDLE 中断__HAL_UART_ENABLE_IT(huart2, UART_IT_IDLE);注意 HAL 库没有直接提供 IDLE 中断的使能 API必须用这个宏。然后在stm32fxxx_it.c的USART2_IRQHandler里处理。但 HAL 库默认的 IRQHandler 会调用HAL_UART_IRQHandler它不处理 IDLE所以我们要在调用它之前先判断 IDLE 标志。3.2 在 HAL 框架下正确接管 IDLE 中断标准做法是在USART2_IRQHandler里这样写void USART2_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart2, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart2); sbus_idle_callback(); } HAL_UART_IRQHandler(huart2); }这里有个坑清除 IDLE 标志必须先读 SR 再读 DRHAL 的__HAL_UART_CLEAR_IDLEFLAG宏已经帮你做了这个序列直接用就行。如果你自己写寄存器操作顺序错了标志清不掉会一直进中断。另一个坑是有些人在 IDLE 回调里直接调用HAL_UART_DMAStop再重启这是完全没必要的而且会引入间隙丢数据。循环 DMA 模式下IDLE 中断只是告诉你这一帧收完了DMA 本身不用停继续跑就行。3.3 IDLE 中断和 DMA 半传输中断的区别有人会问DMA 不是有半传输HT和传输完成TC中断吗能不能用那个代替 IDLE答案是不行。HT 和 TC 是基于缓冲区位置的不是基于数据内容的。如果帧长度和缓冲区大小不成整数倍关系HT/TC 触发的位置和帧边界对不上你会拿到半截帧。IDLE 是基于总线空闲的和帧边界天然对齐这才是正确选择。我实测过用 TC 中断处理缓冲区设 25 字节时勉强能用但一旦接收机帧率变化或者有丢帧就会错位。换成 IDLE 之后无论帧从哪个位置开始每次 IDLE 都能拿到完整的一帧。4. 状态机解析把字节流变成通道值4.1 为什么不能直接在 IDLE 回调里解析IDLE 回调是在中断上下文里执行的解析 25 字节涉及位操作和循环耗时可能几十微秒。虽然不算长但中断里做重活是坏习惯而且如果解析过程中又来了新数据可能出问题。正确做法是IDLE 回调只做一件事——把当前帧拷贝到一个待处理缓冲区置一个标志位然后退出。真正的解析放在主循环里看到标志位再处理。这样中断上下文极短主循环也不阻塞两边解耦。4.2 状态机的状态划分解析状态机我一般分四个状态状态含义触发条件动作IDLE等待帧头收到 0x0F进入 HEADHEAD已收到帧头累计 25 字节进入 PARSEPARSE解析数据解析完成进入 CHECKCHECK校验帧尾帧尾合法输出通道值回 IDLE实际实现时因为 IDLE 中断已经帮我们切好了帧状态机可以简化成逐字节喂入 帧头同步。我通常这样写typedef enum { SBUS_STATE_IDLE, SBUS_STATE_RECEIVING, SBUS_STATE_COMPLETE } sbus_state_t; typedef struct { sbus_state_t state; uint8_t buf[25]; uint8_t idx; uint16_t channels[16]; uint8_t frame_lost; uint8_t failsafe; } sbus_t;喂字节的函数void sbus_feed_byte(sbus_t *s, uint8_t b) { switch (s-state) { case SBUS_STATE_IDLE: if (b 0x0F) { s-buf[0] b; s-idx 1; s-state SBUS_STATE_RECEIVING; } break; case SBUS_STATE_RECEIVING: s-buf[s-idx] b; if (s-idx 25) { s-state SBUS_STATE_COMPLETE; } break; default: break; } }这个状态机的核心是帧头同步只有收到 0x0F 才开始计数这样即使中间丢了字节下一帧的 0x0F 也能重新同步。比单纯靠字节计数健壮得多。4.3 11 位通道值的位操作解析22 字节解析成 16 个 11 位值最直观的写法是位流拼接static void sbus_decode(sbus_t *s) { uint32_t bits 0; int bit_cnt 0; int ch 0; for (int i 1; i 22; i) // buf[1] 到 buf[22] { bits | (uint32_t)s-buf[i] bit_cnt; bit_cnt 8; while (bit_cnt 11 ch 16) { s-channels[ch] bits 0x7FF; bits 11; bit_cnt - 11; } } s-frame_lost (s-buf[23] 0) 0x01; s-failsafe (s-buf[23] 1) 0x01; }这段代码把 22 字节拼成一个位流每次凑够 11 位就切一个通道出来。注意bits用uint32_t因为最多会累积 81018 位32 位足够。这个写法比逐位循环快很多实测在 F103 72MHz 下解析一帧不到 5us。解析出来的原始值范围是 172~1811中位 992。如果你要转成微秒用前面那个公式如果只是做比例控制直接归一化到 -1~1 也行float norm (raw - 992) / 819.0f; // 大约 -1 到 15. 缓冲区管理和帧同步的实战细节5.1 循环缓冲区的读指针更新时机IDLE 中断触发时我们从读指针读到写指针把这段数据喂给状态机。但这里有个细节写指针是 DMA 当前写入位置读指针到写指针之间的数据是刚收到的。因为 DMA 是循环的如果读指针大于写指针说明数据绕回了要分两段读。void sbus_idle_callback(void) { uint16_t wp SBUS_BUF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart2_rx); while (sbus_rp ! wp) { sbus_feed_byte(sbus, sbus_rx_buf[sbus_rp]); sbus_rp (sbus_rp 1) % SBUS_BUF_SIZE; } }这段代码在中断里跑但只做字节搬运不做解析耗时可控。注意sbus_rp要声明为volatile因为它在中断和主循环之间共享。5.2 帧率监控和丢帧检测SBUS 接收机正常帧率是 14ms 一帧也就是约 71Hz。如果超过一定时间没收到完整帧说明链路有问题。我一般用一个计数器在主循环里做超时检测if (HAL_GetTick() - last_frame_tick 50) { // 超过 50ms 没收到帧认为链路断开 sbus_online 0; }同时利用帧里的 frame_lost 和 failsafe 标志做双重判断。实测下来接收机在信号弱时会先置 frame_lost再置 failsafe最后输出固定值。所以你的控制逻辑里要处理这三种状态正常、丢帧但还有数据、失控。5.3 双缓冲避免解析时数据被覆盖如果主循环解析一帧需要较长时间而 DMA 又在往同一个缓冲区写可能解析到一半数据被覆盖。解决办法是双缓冲IDLE 中断里把当前帧拷贝到 buffer A主循环解析 buffer A 的同时DMA 继续往 buffer B 写。或者更简单因为 SBUS 帧率只有 71Hz解析只要几微秒单缓冲完全够用只要保证解析时不被中断打断太久即可。我实际项目里用的是单缓冲加标志位主循环看到frame_ready标志就解析解析完清标志。因为解析极快从来没出过覆盖问题。但如果你在主循环里还做了其他耗时操作建议还是上双缓冲。6. 常见翻车现场和排查思路6.1 一个字节都收不到先查硬件。用示波器看接收机输出如果空闲是高电平说明你没做反相SBUS 空闲应该是低电平。F1/F4 用户重点查这个。如果波形是对的但收不到查波特率是不是 100000停止位是不是 2校验是不是偶校验。CubeMX 里这些都要手动改默认是 115200/1/None。6.2 数据能收到但通道值乱跳大概率是帧同步问题。检查你的状态机是不是靠帧头 0x0F 同步的如果只是靠字节计数丢一个字节就全乱。另外检查 IDLE 中断有没有正确使能如果没使能你可能在用 TC 中断帧边界对不上。还有一种可能是 DMA 缓冲区太小比如设成 25 字节DMA 写满一圈刚好一帧但如果帧起始位置和缓冲区起始位置不对齐就会跨圈读指针处理时容易漏。建议缓冲区设 50 或 100 字节留足余量。6.3 偶尔丢帧或数据延迟检查 IDLE 回调里是不是做了太多事。如果回调里直接解析解析期间可能错过下一次 IDLE。正确做法是回调只搬运解析放主循环。另外检查主循环里有没有长时间阻塞的操作比如HAL_Delay这会导致标志位处理不及时。还有一个隐蔽的坑DMA 和 CPU 同时访问缓冲区时的缓存一致性问题。在 F7/H7 这些带 D-Cache 的芯片上DMA 写的是内存CPU 读的可能是缓存里的旧数据。解决办法是把缓冲区放在非缓存区或者手动做 cache invalidate。F1/F4 没有 D-Cache不用管这个但如果你从 F1 换到 H7这个问题一定会遇到。6.4 失控保护不生效检查帧里的 failsafe 标志位有没有正确解析。第 23 字节 bit1 是 failsafebit0 是 frame_lost。有些接收机在失控时会把通道值设成固定值比如全部 992 或者全部 172同时置标志位。你的控制逻辑要同时看标志位和通道值不能只看一个。7. 性能实测和参数调优7.1 中断频率和 CPU 占用按 71Hz 帧率算IDLE 中断每秒触发 71 次每次搬运约 25 字节加上状态机喂字节总耗时估计在 10us 以内。CPU 占用率不到 0.1%基本可以忽略。对比逐字节中断的 1800 次/秒这套方案的中断负载降低了 25 倍。7.2 缓冲区大小的选择缓冲区大小优点缺点适用场景25 字节最小内存跨圈易错位不推荐50 字节两帧余量内存略增推荐100 字节四帧余量内存浪费高帧率或慢处理我一般用 50 字节兼顾内存和余量。如果你在主循环里还有其他重活用 100 字节更稳。7.3 波特率误差的影响STM32 的 USART 波特率是分频得到的100000 这个值不是所有主频都能整除。比如 F103 72MHzUSARTDIV 72M / (16 * 100000) 45刚好整除误差 0。但如果你用的是 8MHz 外部晶振倍频到 72M实际可能有微小偏差。误差超过 2% 就可能丢字节。用 CubeMX 配置时它会自动算分频值并显示误差尽量选误差小于 1% 的配置。8. 从 SBUS 延伸到其他串口协议的通用思路这套DMA 循环 IDLE 中断 状态机的组合其实不限于 SBUS。任何帧长度固定或可变、帧间有空闲间隔的串口协议都能用比如PPM 转串口类似 SBUS帧间有空闲Modbus RTU帧间有 3.5 字符空闲IDLE 中断正好用自定义二进制协议帧头 长度 数据 校验状态机同步核心思想就三条DMA 负责搬运IDLE 负责切帧状态机负责解析。把这三层解耦代码就清晰了调试也容易。我在做 Modbus 从机时直接套用这套结构把状态机换成 Modbus 的解析逻辑半天就跑通了。最后分享一个调试技巧如果你不确定 IDLE 中断有没有触发可以在回调里翻转一个 GPIO用示波器看。正常应该每 14ms 一个脉冲。如果脉冲间隔不对说明帧率有问题如果没脉冲说明 IDLE 没使能或者标志没清掉。这个土办法比打串口打印快得多也不会干扰时序。