如果你在搞航模、飞控、四足机器人或者任何带遥控接收链路的板子SBUS这个协议基本绕不开。它一帧看起来就25字节真要在STM32上收得干净利落反相电平、接近100000的波特率、偶校验加2停止位、约3ms一帧的节奏随便哪个细节翻车收到的就是乱码或者断流。我最近把项目从标准库迁到HAL库顺手把SBUS接收重构成一套“DMA循环接收 IDLE中断 状态机解析”的组合在F103和G070上都跑过一段时间效果很稳。这篇文章就把方案选型、CubeMX配置、核心代码和实践中踩过的坑完整写出来给准备在HAL库下做SBUS解析的朋友一个能直接参考的模板。1. SBUS协议不是“普通串口”这些参数必须先搞清楚1.1 25字节帧结构拆解起始、数据、标志、结束SBUS协议是Futaba提出的一种串行总线协议底层物理形式就是一个UART但参数比较特殊波特率1000008个数据位偶校验2个停止位。对应到CubeMX里就是100000、8E2。很多第一次接触的人习惯性照搬115200或者8N1结果就是完全收不到有效数据。一帧SBUS数据固定25字节按顺序拆开看第1字节起始字固定为0x0F。第2到第23字节22个字节塞下16个比例通道每个通道11bit一共176bit正好22字节。第24字节标志字节bit7对应第17通道开关量bit6对应第18通道bit5表示帧丢失bit4表示接收机进入保护模式。第25字节结束字固定为0x00。这里有个容易忽略的点虽然ST在CubeMX里把8E2显示成“8位数据”但线上每字节实际是起始1位 数据8位 偶校验1位 停止2位共12位。25字节就是300个位时间在100000波特率下正好约3ms所以很多接收机可以跑到大约300Hz的更新频率。理解这个时间关系很重要后面算DMA缓冲区大小、判断“多久没收到帧算信号丢失”时都要用到。1.2 为什么强推“DMA循环接收 IDLE中断”组合先看最朴素的方案在串口接收中断里一个字节一个字节地读每来一个字节就打断CPU一次。100000波特率下哪怕按12位一字节算每秒也有约8333个字节也就是每秒进中断8333次。对于只想解析一个遥控链路来说这个开销可以忍受但如果你同时在做电机控制、姿态解算、显示刷新中断频繁被打断很容易影响其他时敏任务的执行节奏。DMA循环接收的意义是把“搬运数据”这个苦力活交给DMA控制器。USART硬件每收到一个字节DMA自动把它写进内存缓冲区CPU根本不用管。配合IDLE空闲中断只有在串口线上出现空闲时CPU才被中断一次这时DMA已经把一个完整或连续的数据块收进缓冲区了。对SBUS这样“突发一帧、然后空闲几毫秒”的协议来说DMAIDLE几乎是量身定做的组合。我自己用的对比可以给一个直观感受方案CPU开销实时性实现难度实测印象逐字节RX中断高每字节都进中断好低数据少时够用多个外设共存时容易卡顿DMA循环 IDLE低只有空闲时进中断好中帧连续且稳定CPU占用很低定时器模拟USART中高一般高不推荐纯属自虐DMA循环模式还有一个好处它等于在内存里维护了一个环形队列DMA不断往缓冲区写数据CPU根据自己的节奏在IDLE中断里读取和处理。只要缓冲区没有写满覆盖解析逻辑晚一点处理也不会丢数据。这一点在调试高优先级中断冲突时很救命。1.3 状态机在整套方案里的分工DMA和IDLE只解决“怎么把串口字节流接进来”的问题但不保证每次IDLE中断触发时缓冲区内正好只有一帧完整SBUS数据。实际情况下可能发生这些事上电瞬间接收机发送了垃圾字节缓冲里有残缺数据。CPU中断响应不及时IDLE触发时DMA已经写了1.5帧。DMA缓冲区正好在解析过程中发生回绕字节顺序跨越缓冲首尾。帧头0x0F出现在通道数据里造成假同步。这时候就需要一个状态机来逐字节处理字节流负责识别帧头、收集25字节、校验帧尾、再把通道数据解析出来。状态机不关心DMA缓冲有多大、也不关心DMA指针在哪里它只面对一个字节一个字节的“数据流”。这是整套架构里最稳定的一层。2. 硬件反相与CubeMX配置2.1 先确认SBUS电平极性常见反相电路SBUS物理层是反相UART信号。常规UART空闲状态是高电平起始位是低电平SBUS恰恰相反空闲状态是低电平起始位是高电平。这也是很多新手把接收机SBUS引脚直接连到STM32 RX后结果串口收到的全是乱码的根本原因。调试时最有效的办法是示波器先看波形。把探针点在SBUS信号线上如果发现空闲时是低电平那么这是一个反相信号必须在进入STM32 USART之前把它反相成标准UART电平。最简单的反相电路可以用一个NPN三极管完成SBUS信号通过1kΩ电阻接三极管基极。发射极接地。集电极通过10kΩ上拉电阻接到3.3V同时集电极接STM32的RX引脚。SBUS信号为高电平时三极管导通输出被拉低信号为低电平时三极管截止上拉电阻把输出拉高。这样就把反相逻辑再反转一次变成标准UART电平。需要注意如果接收机SBUS引脚输出的是5V电平需要确认三极管基极电阻和信号幅度是否合适。如果板子上本来就带SBUS反相接口比如很多飞控的SBUS输入引脚那就直接连不用再外接。判断标准很简单用示波器看空闲电平空闲为高就可以直接接USART。2.2 CubeMX里配置100000波特率串口和循环DMA在STM32CubeMX里配置这套方案的步骤不算复杂但有几个选项必须卡准。我以常见的STM32F103C8T6为例USART1做SBUS接收在RCC里打开外部高速时钟时钟树配到72MHzUSART1模式选择Asynchronous参数区设置Baud Rate填100000Word Length选8Parity选EvenStop Bits选2切到DMA Settings标签添加USART1_RX方向PeripheralToMemoryMode一定要选CircularNVIC里使能USART1全局中断DMA中断可以不开生成工程。这里专门说下波特率。72MHz主频下USART1的输出频率计算公式是fck / (16 * USARTDIV)要让波特率等于100000USARTDIV就是72000000 / (16 * 100000) 45。BRR寄存器值45算下来实际波特率正好100000没有任何误差。如果换了G070这类芯片64MHz主频下BRR等于40同样精确。不少人担心100000波特率不常用会不会因为晶振偏差导致误码。实际上STM32串口对波特率有一定容错100k这个量级对时钟偏差不算敏感。只要不是用极度不准的内部RC并在全温度范围跑问题都不大。2.3 缓冲区大小怎么选256字节是“宽松”的选择DMA缓冲区大小没有硬性规定但直接影响代码健壮性。SBUS一帧25字节大约3ms一帧12位每字节换算下来每秒数据量约8.3KB。如果缓冲区太小比如只给32字节DMA转几圈就可能覆盖还没被CPU读走的旧数据缓冲区给大一些CPU即使偶尔被高优先级任务卡住几百微秒也不会出事。稳妥起见我习惯把DMA缓冲设成256字节这样可以容纳约10帧数据内存占用也完全可以接受。如果单片机RAM紧张64字节也能跑代价是IDLE中断处理代码必须写得很快并且要认真处理回绕。后面第三部分会专门讲回绕计算。启动DMA接收的代码很简单只需要在初始化时调用一次HAL_UART_Receive_DMA(huart1, sbus_dma_buf, SBUS_RX_BUF_SIZE); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE);之后DMA会一直在后台循环搬运不用重复启动。3. 代码实现IDLE中断与状态机解析3.1 数据结构定义与全局变量写代码前先把数据结构定清楚。我习惯把“接收”和“解析”分开接收层管DMA缓冲和位置指针解析层管帧状态和通道结果。#define SBUS_FRAME_LEN 25 #define SBUS_RX_BUF_SIZE 256 static uint8_t sbus_dma_buf[SBUS_RX_BUF_SIZE]; static volatile uint16_t sbus_last_pos 0; typedef enum { SBUS_STATE_IDLE 0, SBUS_STATE_DATA } SbusParseState; typedef struct { SbusParseState state; uint16_t idx; uint8_t frame[SBUS_FRAME_LEN]; } SbusParser; static SbusParser sbus_parser; static uint16_t sbus_channels[16]; static uint8_t sbus_flags; static volatile uint8_t sbus_frame_ready; static uint32_t sbus_last_tick;sbus_dma_buf是DMA写入的缓冲区sbus_last_pos记录CPU上次处理到的位置sbus_parser保存状态机进度sbus_channels最终存16个通道的原始11bit值。sbus_frame_ready是供主循环查询的帧标志直接放在中断里处理时要留意用volatile修饰。3.2 中断入口这样写先清IDLE标志再读DMA计数器USART1中断函数的写法是整个方案的核心。我的做法是在调用HAL的通用中断处理函数之后再检查IDLE标志void USART1_IRQHandler(void) { HAL_UART_IRQHandler(huart1); if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); uint16_t cur_pos SBUS_RX_BUF_SIZE - (uint16_t)__HAL_DMA_GET_COUNTER(hdma_usart1_rx); sbus_process_bytes(cur_pos); } }这里有两个细节值得展开。第一为什么先调用HAL_UART_IRQHandler再判断IDLEHAL库内部处理中断时会读取状态寄存器和数据寄存器借此清除一部分标志。把IDLE判断放在其后面可以减少和HAL内部逻辑打架的概率。不同HAL版本对IDLE中断的处理方式有差异但“自己检查标志”的方式在所有版本上都适用是最不依赖库版本的做法。第二cur_pos的含义要搞清楚。DMA计数器是向下递减的初始值等于缓冲区大小每接收一个字节减1。所以在IDLE触发那一刻CPU算出来的“DMA当前写入位置”就是缓冲区大小 - DMA计数器值。sbus_last_pos记录了上次处理到的位置这两个位置之间就是新收到的字节区间。3.3 从环形缓冲取数必须处理回绕sbus_process_bytes负责把DMA缓冲里的新字节交给状态机。环形缓冲最常见的坑就是回绕必须写成分段读取。static void sbus_process_bytes(uint16_t cur_pos) { if (cur_pos sbus_last_pos) { for (; sbus_last_pos cur_pos; sbus_last_pos) { sbus_parser_feed(sbus_parser, sbus_dma_buf[sbus_last_pos]); } } else { for (; sbus_last_pos SBUS_RX_BUF_SIZE; sbus_last_pos) { sbus_parser_feed(sbus_parser, sbus_dma_buf[sbus_last_pos]); } sbus_last_pos 0; for (; sbus_last_pos cur_pos; sbus_last_pos) { sbus_parser_feed(sbus_parser, sbus_dma_buf[sbus_last_pos]); } } }当cur_pos sbus_last_pos时说明IDLE虽然触发了但DMA这个周期内没有新数据进来直接跳过处理即可。代码里两个分支自然覆盖了这种情况因为两个循环条件都不满足。还有一个处理顺序问题整个解析过程是在中断里做的要保证DMA不会在这期间覆盖掉正在读取的数据。256字节缓冲区加上SBUS本身只有3ms一帧的数据率中断里处理25字节乘以若干帧的耗时极短远小于缓冲区被覆盖的时间所以这个方案是安全的。如果缓冲区设得特别小同时主循环还在中断里做耗时操作那就要小心了。3.4 状态机逐字节找帧头、收帧、验帧尾sbus_parser_feed函数接收一个字节按状态机逻辑更新解析状态static void sbus_parser_feed(SbusParser *p, uint8_t byte) { switch (p-state) { case SBUS_STATE_IDLE: if (byte 0x0F) { p-frame[0] byte; p-idx 1; p-state SBUS_STATE_DATA; } break; case SBUS_STATE_DATA: if (byte 0x0F p-idx ! 1) { p-frame[0] byte; p-idx 1; break; } p-frame[p-idx] byte; if (p-idx SBUS_FRAME_LEN) { if (p-frame[SBUS_FRAME_LEN - 1] 0x00) { sbus_decode_frame(p-frame); } p-state SBUS_STATE_IDLE; p-idx 0; } break; default: p-state SBUS_STATE_IDLE; p-idx 0; break; } }这里对“数据中又出现0x0F”的情况做了额外处理如果当前正在收集数据又收到一个0x0F并且这不是刚进入DATA状态后的第一字节就认为之前的同步是可疑的直接把当前0x0F作为新的帧头重新收集。这个策略能有效应对上电垃圾数据和串口误码造成的错帧恢复。有人可能会问如果SBUS通道数据里正好出现0x0F会不会被误判成帧头确实存在这种可能但因为一帧最后必须有0x00结束字而且0x0F后面的24个字节还必须满足通道数据范围、flags位相对合理的条件实际误判概率极低。如果更严格可以在解析后检查16个通道值是否都在0到2047范围内把不合理帧丢弃。3.5 22字节解出16路11bit通道值SBUS的16个通道并不是按字节对齐存放的而是连续按位排列每个通道11bit从第一个通道开始逐位往后排。由于11不是8的整数倍必然出现跨字节拼接的情况。我用的解包逻辑如下static void sbus_decode_frame(const uint8_t *f) { sbus_channels[0] ((f[1] | (f[2] 8)) ) 0x07FF; sbus_channels[1] (((f[2] 3) | (f[3] 5)) ) 0x07FF; sbus_channels[2] (((f[3] 6) | (f[4] 2) | (f[5] 10)) ) 0x07FF; sbus_channels[3] (((f[5] 1) | (f[6] 7)) ) 0x07FF; sbus_channels[4] (((f[6] 4) | (f[7] 4)) ) 0x07FF; sbus_channels[5] (((f[7] 7) | (f[8] 1) | (f[9] 9)) ) 0x07FF; sbus_channels[6] (((f[9] 2) | (f[10] 6)) ) 0x07FF; sbus_channels[7] (((f[10] 5) | (f[11] 3)) ) 0x07FF; sbus_channels[8] ((f[12] | (f[13] 8)) ) 0x07FF; sbus_channels[9] (((f[13] 3) | (f[14] 5)) ) 0x07FF; sbus_channels[10] (((f[14] 6) | (f[15] 2) | (f[16] 10)) ) 0x07FF; sbus_channels[11] (((f[16] 1) | (f[17] 7)) ) 0x07FF; sbus_channels[12] (((f[17] 4) | (f[18] 4)) ) 0x07FF; sbus_channels[13] (((f[18] 7) | (f[19] 1) | (f[20] 9)) ) 0x07FF; sbus_channels[14] (((f[20] 2) | (f[21] 6)) ) 0x07FF; sbus_channels[15] (((f[21] 5) | (f[22] 3)) ) 0x07FF; sbus_flags f[23]; sbus_frame_ready 1; sbus_last_tick HAL_GetTick(); }看明白一条公式就好办。拿第二个通道举例它从第11位开始所以需要取frame[2]的高5位和frame[3]的低6位。frame[2] 3把高5位移到最低位frame[3] 5把低6位移到第5到10位两者按位或后与0x07FF相与得到11bit数值。其余通道同理。解码出来的原始值范围是0到2047常见的接收机中位在992附近。使用时要根据具体遥控器的行程做映射。最稳的做法是上电时让用户把摇杆打到最大最小校准出每个通道的实际min和max再映射到百分比或目标量程。如果不想校准也可以先用固定参数比如把一个通道从992到1792当成正行程但不同遥控器会存在偏差。3.6 信号丢失与保护模式检测SBUS接收机在遥控器关闭或超出范围时会停止输出有效帧。由于DMA循环接收本身不会主动报“没有新数据”所以必须在主循环里靠时间判断。我的做法是每次成功解析一帧就更新sbus_last_tick然后在主循环中检查if (HAL_GetTick() - sbus_last_tick 20) { sbus_signal_lost(); }20ms这个值比一帧3ms长但又不会大到让人感觉“信号已经断了还傻等”。进入信号丢失状态后可以把所有通道输出到一个安全值比如油门通道归零、其他通道保持中位。另外协议标志字节里的bit4和bit5也要用好。bit4置1表示接收机进入了保护模式通常意味着遥控器信号丢失bit5置1表示当前帧是在信号不稳定时补发的帧。实际项目里可以拿这两个位做分级告警比单纯靠超时更灵敏。4. 我在项目中踩过的坑与排查速查4.1 最容易翻车的事DMA循环计数器回绕计算我最早写这套代码时犯过一个错把DMA计数器差值当成“新增数据量”直接用memcpy(解析缓存, 缓冲, 差值)去拷贝。前几次能对上一旦缓冲发生回绕拷贝出来的字节顺序就是乱的帧头怎么都找不对。后来改成用sbus_last_pos和cur_pos双指针处理每次循环只读一个字节喂状态机问题就消失了。所以这里想强调一句环形缓冲的读取千万不要想当然必须显式判断区间分两段处理。4.2 IDLE标志清了但一直重进中断这个现象往往不是“没清干净”而是根本没有新数据到达但IDLE事件在空闲状态下会反复触发。比如上电后SBUS接收机还没输出USART线一直处于空闲电平IDLE中断会立刻来一次如果你在中断里没有判断cur_pos ! sbus_last_pos就会陷入频繁空转。解决方法是代码里加好“没有新数据就返回”的语义。我写sbus_process_bytes时已经通过循环条件自然规避了空转问题但如果你自己重写一遍务必记得不能一看IDLE标志就慌慌张张去解析要先确认DMA有没有新数据。4.3 反相问题默认波形就是反的如果你用的接收机SBUS输出本来就需要反相而板子上没有对应电路接收到的数据会是半乱码状态。不是完全收不到而是里面会夹杂许多错误字节同步也时好时坏。排查方法不是反复改软件而是先确认物理层。用示波器看SBUS信号的空闲电平空闲为低就说明需要反相。确认硬件无误后再调软件不然一个问题查一整天都定位不到根因。4.4 中断优先级太低导致处理延迟DMA本身不需要CPU参与所以即使串口中断优先级低数据也会先被DMA写进缓冲不会立刻丢失。但IDLE中断处理如果被其他更长的高优先级中断长期抢占缓冲还是可能被新数据覆盖。我的经验是把USART1中断优先级设得足够高比如抢占优先级0、子优先级0同时保证中断服务函数里只做“读计数器、喂状态机、设置标志”这些轻量操作。不要在中断里做浮点映射、打印、发送数据这类耗时操作映射放到主循环里做。4.5 不同HAL版本对IDLE回调的处理差异新版HAL库其实已经提供了HAL_UARTEx_RxEventCallback这类与空闲事件相关的回调接口但不同的固件包版本行为不完全一致。如果你的项目同时要兼容F1和G0系列或者升级过CubeMX生成的代码最不容易出问题的写法还是我前面展示的在USART1_IRQHandler里手动检查UART_FLAG_IDLE不依赖HAL的版本特性。4.6 常见问题速查表现象常见原因处理办法完全收不到SBUS数据波特率/校验/停止位配置不对确认设置为100000、8E2数据乱码、偶发错帧SBUS反相电平没处理示波器看空闲电平加反相电路只收到一帧就不再更新DMA不是Circular模式在CubeMX中把DMA Mode改为CircularIDLE中断一直触发但无数据上电空闲或DMA未启动检查是否调用了HAL_UART_Receive_DMA解析出的通道值跳动大主循环里频繁重复处理同一帧检查sbus_last_pos更新逻辑中断卡顿影响其他任务在中断里做了耗时操作中断里只做标记映射和业务放主循环信号丢失后通道保持最后值没有做超时置安全值主循环检查HAL_GetTick差值超时统一输出安全值最后再分享一点经验这套方案我从F103用到G070中间还换过几个不同版本的HAL固件包只要硬件反相和DMA配置没搞错代码几乎可以平移。做这类底层接收我个人的习惯是先把示波器或者逻辑分析仪接上亲眼确认波形极性、帧间隔和波特率再开始动代码。很多看起来像“程序bug”的问题最后都发现是物理层没搞对。后续如果想在这个框架上继续玩可以尝试把S.BUS2的遥测数据包也解析出来或者在状态机里增加自动检测16通道和18通道两种模式。思路都一样DMA循环接收负责不丢数据IDLE中断负责告诉你“一帧来了”状态机保证无论数据怎么错乱都能找回帧头。这三件事做好SBUS解析基本就稳了。