SBUS 这个协议在航模和机器人圈子里太常见了接收机出来一根线一根信号线就能拿到十几个通道的数据。但真到 STM32 上用 HAL 库去接它很多人第一反应是串口中断收呗结果一上电就发现数据帧长度固定 25 字节波特率还是反常规的 100000 加 8E2 配置用普通中断一个字节一个字节进中断CPU 基本被这 25 个字节绑死稍微跑点别的任务就开始丢帧。我最早做云台控制板的时候就是这么干的主循环里稍微加个 PID 运算SBUS 就开始间歇性失联排查了半天才发现是接收环节把 CPU 吃满了。后来换成DMA 循环接收 IDLE 空闲中断 状态机这套组合才算真正把这个问题解决干净。DMA 负责把串口数据默默搬进缓冲区CPU 完全不参与搬运IDLE 中断负责在一帧数据收完、总线空闲下来的那一刻通知我状态机负责在中断之外把原始字节流解析成有意义的通道值。三者各司其职CPU 占用率从原来的百分之十几直接降到几乎可以忽略。这篇就把这套方案的完整实现思路、配置细节和踩过的坑一次讲清楚适合已经会用 CubeMX 点灯、但对 DMA 和串口空闲中断还不太熟的嵌入式开发者。1. 先把 SBUS 这个协议的特殊性摸清楚1.1 它为什么不能用普通串口参数去接SBUS 是 Futaba 那套体系里的串行总线协议物理层是反相 UART也就是说它的电平逻辑跟标准 TTL 串口是反的。这一点是新手最容易翻车的地方你直接把接收机的信号线接到 STM32 的 RX 上串口配置全对但就是收不到任何数据示波器一看波形全是反的。解决办法要么加一个反相电路一个三极管加两个电阻就行要么用带反相功能的接收机要么在软件层面把极性反过来处理。我一般推荐硬件反相稳定且不占 CPU。参数上它也很另类波特率100000不是常见的 9600 或 115200数据格式是8 位数据、偶校验、2 位停止位也就是常说的 8E2。STM32 的 USART 外设完全支持这套参数CubeMX 里把 Parity 设成 Even、Stop Bits 设成 2 就能对上。这里有个细节开了偶校验之后HAL 库接收到的数据字节最高位会被校验位占用所以你在解析前必须把每个字节跟 0x00 做一次与运算或者干脆在 CubeMX 里把 Word Length 设成 9 位来容纳校验位。我习惯用 8 位数据加校验的方式解析时统一 0x00清掉最高位简单直接。1.2 25 字节一帧里到底装了什么SBUS 一帧固定25 个字节结构非常规整字节位置内容说明0帧头 0x0F固定起始标志1-2216 个通道数据每通道 11 位共 22 字节23标志位包含失控、丢帧等状态24帧尾 0x00固定结束标志16 个通道每个 11 位加起来 176 位正好 22 字节。这个位打包方式是 SBUS 解析的核心难点它不是每个通道占固定字节而是像流水一样把 11 位一位一位拼起来。比如通道 1 占第 1 字节的全部 8 位加第 2 字节的低 3 位通道 2 占第 2 字节的高 5 位加第 3 字节的低 6 位以此类推。手动去移位拼接非常容易出错所以后面状态机里我会用一个循环统一处理。通道值的范围是172 到 1811中位大约在 992。这个范围不是 0 到 2047是因为 SBUS 协议本身留了余量。实际用的时候你需要做一个线性映射把它转成舵机或电调能接受的范围。标志位字节里bit0 是丢帧标志bit1 是失控保护标志这两个在飞控里非常关键一定要读出来做安全判断。1.3 为什么循环 DMA IDLE是天生一对普通 DMA 接收有个问题你不知道一帧什么时候结束。如果用 DMA 普通模式收满指定长度就停但 SBUS 帧长固定 25 字节理论上可以设成收 25 字节触发一次。可实际中如果中间丢了一个字节整个缓冲区就错位了后面全乱。而DMA 循环模式让缓冲区首尾相接DMA 永远在转不会停配合IDLE 空闲中断就完美了总线上一帧数据发完会有一段空闲时间USART 硬件检测到空闲就触发 IDLE 中断我在中断里读取 DMA 当前写指针的位置就知道这一帧收到了多少字节、从哪里开始。这套组合的精髓在于DMA 负责搬运IDLE 负责定界CPU 只在帧结束时被唤醒一次。相比每字节一次中断CPU 负载降低了一个数量级。而且循环模式下缓冲区是环形复用的不需要每次重新启动 DMA代码更简洁。2. CubeMX 里那些容易配错的参数2.1 USART 参数与 DMA 请求的对应关系在 CubeMX 里配置 USART 时几个关键项必须一次到位Baud Rate100000Word Length8 BitsParityEvenStop Bits2ModeAsynchronous然后在 DMA Settings 里添加 USART_RX 请求模式选Circular数据宽度 Byte。这里有个坑很多人只加了 RX 的 DMA忘了 NVIC 里要开USARTx global interrupt。IDLE 中断属于 USART 的全局中断范畴不开这个IDLE 永远不会触发。我见过不止一个项目卡在这里代码逻辑全对就是收不到帧结束信号。另外 DMA 的优先级建议设成 Medium 或 High别设 Low。如果系统里还有别的 DMA 通道在跑比如 ADC 采集优先级太低会导致串口 DMA 被抢占缓冲区指针更新不及时IDLE 中断里读到的位置就不准。2.2 缓冲区大小的取舍循环 DMA 的缓冲区大小不是随便定的。太小了一帧 25 字节还没收完就被覆盖太大了浪费 RAM 而且 IDLE 中断里处理的数据跨度大。我的经验是设成帧长的整数倍再留点余量比如 64 字节或 128 字节。64 字节能容纳两帧多即使 IDLE 中断响应稍有延迟也不会丢数据。这里要理解循环 DMA 的写指针回绕问题DMA 写到缓冲区末尾会自动回到开头继续写。所以你在 IDLE 中断里计算这一帧收了多少字节时不能简单用当前指针减上次指针必须考虑回绕。我一般用一个last_pos变量记录上次处理到的位置然后uint16_t cur_pos BUFFER_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); uint16_t len (cur_pos last_pos) ? (cur_pos - last_pos) : (BUFFER_SIZE - last_pos cur_pos);__HAL_DMA_GET_COUNTER返回的是 DMA 剩余待传输数量用缓冲区总长减去它就是当前写指针位置。这个宏在 HAL 库里是现成的不用自己去读寄存器。2.3 中断优先级的实际影响IDLE 中断的优先级要结合你的系统来定。如果 SBUS 只是遥控输入优先级中等即可但如果你的飞控对遥控响应实时性要求极高可以适当提高。不过要注意IDLE 中断里不要做太重的活我见过有人在中断里直接跑通道映射和滤波结果中断执行时间过长影响了其他外设。正确做法是中断里只做标记一帧到达 拷贝数据到解析缓冲真正的解析放到主循环或任务里。3. 状态机解析把 25 字节变成 16 个通道3.1 为什么不用一次性解析而要上状态机有人会问帧长固定 25 字节帧头帧尾都固定直接判断一下不就行了要什么状态机这话在理想情况下没错但实际串口通信里会遇到各种异常上电瞬间收到半帧、干扰导致帧头错位、丢字节导致后续全乱。如果不用状态机一旦错位你可能要等很久才能重新同步。状态机的价值在于逐字节推进、随时可复位。它把解析过程拆成等帧头、收数据、验帧尾几个明确状态任何一个环节不满足就回到初始状态重新找帧头。这样即使中间出错最多丢一帧下一帧立刻能重新同步。对于 SBUS 这种连续不断发送的协议这个特性非常重要。3.2 状态划分与转移条件我用的状态机比较简单三个状态足够STATE_HEAD等待帧头 0x0FSTATE_DATA接收 23 个数据字节含通道和标志位STATE_END校验帧尾 0x00转移逻辑是这样的在 HEAD 状态收到 0x0F 就进 DATA同时把数据索引清零DATA 状态每收一个字节存进临时数组收满 23 个进 ENDEND 状态检查是不是 0x00是就标记一帧完整否则丢弃重来。整个过程用一个index变量跟踪进度逻辑清晰出错也好排查。这里有个细节标志位字节第 23 字节也在 DATA 状态里收收完之后单独解析它的 bit0 和 bit1。我习惯把它存到一个sbus_flags变量里主循环里判断失控标志来决定是否进入保护逻辑。3.3 11 位通道数据的位拼接技巧这是整个解析里最绕的部分。16 个通道、每个 11 位、共 22 字节位是连续排列的。最直观的做法是用一个位缓冲区把 22 字节全部展开成 176 位然后每 11 位切一刀。但这样代码量大、效率低。更优雅的做法是用一个循环配合移位uint8_t byte_index 0; uint8_t bit_index 0; for (int ch 0; ch 16; ch) { uint16_t value 0; for (int b 0; b 11; b) { if (data[byte_index] (1 bit_index)) { value | (1 b); } bit_index; if (bit_index 8) { bit_index 0; byte_index; } } channels[ch] value; }这段代码逐位读取逻辑上绝对正确但效率一般。实际项目中我会用查表或者预计算的移位方案优化不过在 100000 波特率下一帧 25 字节的解析时间完全够用没必要过度优化。先把功能跑通再谈性能。解析出来的原始值范围是 172 到 1811需要映射到实际用途。比如控制舵机通常映射到 1000 到 2000 微秒控制电调映射到 1000 到 2000 也是常见做法。映射公式uint16_t mapped (raw - 172) * 1000 / (1811 - 172) 1000;注意这里用整数运算先乘后除避免精度损失。如果 raw 超出范围要做限幅处理防止异常值把执行机构打飞。4. 中断服务函数与主循环的配合4.1 IDLE 中断里到底该做什么IDLE 中断服务函数是整个方案的中枢但它必须轻。我的做法是void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); uint16_t cur_pos BUFFER_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); uint16_t len (cur_pos last_pos) ? (cur_pos - last_pos) : (BUFFER_SIZE - last_pos cur_pos); if (len 0) { memcpy(parse_buf, dma_buf[last_pos], len); frame_len len; frame_ready 1; } last_pos cur_pos; } HAL_UART_IRQHandler(huart1); }注意几个点第一先清 IDLE 标志再处理否则会反复进中断第二HAL_UART_IRQHandler要放在最后调用它处理其他串口中断标志第三拷贝数据用memcpy而不是逐字节循环效率高第四只做标记不解析。提示__HAL_UART_CLEAR_IDLEFLAG这个宏在不同 HAL 版本里实现不一样有的版本需要先读 SR 再读 DR 才能清掉。如果发现中断反复触发检查一下这个宏的实际展开。4.2 主循环里的状态机驱动主循环里检测frame_ready标志一旦置位就把parse_buf里的数据喂给状态机。这里有个设计选择状态机是在中断里跑还是主循环里跑我强烈建议主循环。中断里跑状态机一旦解析逻辑复杂或者加了调试打印中断时间会失控。主循环里跑即使这一帧没处理完下一帧数据也在 DMA 缓冲区里等着不会丢。主循环的结构大概是这样while (1) { if (frame_ready) { frame_ready 0; sbus_parse(parse_buf, frame_len); } // 其他任务 }sbus_parse里就是前面说的状态机逻辑。如果收到的frame_len不是 25直接丢弃说明这一帧不完整或者有干扰。4.3 丢帧与失控的处理策略SBUS 标志位里的丢帧和失控标志必须认真对待。丢帧说明信号质量差失控说明接收机没收到发射机信号。我的处理策略是连续丢帧超过阈值比如 10 帧降低控制输出或进入悬停失控标志置位立即进入保护状态输出预设的安全值正常帧恢复后平滑过渡回正常控制避免突变这些逻辑放在主循环里跟状态机解析解耦。中断只管收主循环管业务职责分明。5. 实测中那些文档不会告诉你的坑5.1 上电第一帧永远是垃圾数据这个坑我踩过好几次。STM32 上电时 USART 和 DMA 初始化有先后顺序如果 DMA 还没准备好串口就开始收数据第一帧往往是残缺的。解决办法是在初始化完成后先清一次缓冲区和last_pos并且状态机在收到第一个完整帧之前不输出任何控制量。另外接收机上电也需要时间通常几百毫秒后才开始发有效数据所以上电后延时一小段再使能接收更稳妥。5.2 偶校验导致的最高位污染前面提过开了偶校验后HAL 库读到的字节最高位是校验位不是数据。如果你直接拿这个字节去解析通道值会全错。我一开始没注意调了半天以为位拼接写错了后来才发现是校验位在捣乱。解决办法就是在解析前统一data[i] 0x7F把最高位清掉。这个操作对帧头 0x0F 和帧尾 0x00 没影响因为它们最高位本来就是 0。5.3 DMA 缓冲区回绕时的数据断裂循环 DMA 最隐蔽的坑是一帧数据可能跨越缓冲区末尾和开头。比如缓冲区 64 字节上一帧结束在位置 60这一帧 25 字节就会写到 60 到 63 再回绕到 0 到 20。如果你在 IDLE 中断里只从last_pos拷贝到cur_pos遇到回绕就会拷错。我前面的代码里用了一个三元表达式处理回绕但更稳妥的做法是分两段拷贝先拷last_pos到缓冲区末尾再拷开头到cur_pos。这个细节在数据量大或者中断延迟高的时候特别重要。5.4 中断里调用 HAL 库函数的隐患HAL_UART_IRQHandler在中断里调用是标准做法但要注意它内部可能会调用回调函数。如果你在回调里做了耗时操作整个中断就废了。我的建议是要么不用 HAL 的回调机制直接在 IRQHandler 里处理 IDLE要么用回调但保证回调里只做标记。另外HAL 库某些版本的HAL_UART_IRQHandler会检查错误标志并做处理如果串口有噪声导致错误中断频繁触发也会拖慢系统。可以在初始化时适当配置错误中断的使能。5.5 波特率误差的累积效应100000 这个波特率不是标准值STM32 的 USART 分频器不一定能精确分出来。如果时钟配置不当波特率误差可能超过 2%导致偶发性的帧错误。我一般会在 CubeMX 里检查一下实际波特率确保误差在 1% 以内。如果误差偏大可以微调系统时钟或者 USART 的分频系数。这个在 F1 系列上尤其要注意F4 和 H7 的时钟树更灵活问题少一些。6. 从能跑到好用几个进阶优化方向6.1 双缓冲让解析和接收彻底解耦单缓冲区在极端情况下会有竞争IDLE 中断正在往parse_buf拷贝主循环同时在读parse_buf。虽然概率低但一旦发生就是数据错乱。解决办法是双缓冲中断拷贝到 buffer A主循环处理 buffer B处理完交换。用一个标志位控制交换时机简单有效。对于高可靠性场景这个优化值得做。6.2 用定时器做帧超时兜底IDLE 中断依赖总线空闲但如果接收机故障一直拉着总线不放IDLE 永远不触发你就一直收不到帧。加一个定时器做超时检测如果超过正常帧间隔SBUS 一般 14ms 一帧超时设 30ms还没收到完整帧就主动复位状态机和 DMA 指针。这是工业级应用里常见的兜底手段。6.3 通道数据的滤波与死区原始通道值会有抖动直接拿去控制电机会有细微抖动。我一般加一个一阶低通滤波filtered filtered * 0.8 raw * 0.2;再配合一个死区判断变化小于阈值就不更新输出。这样控制手感更稳也能延长舵机寿命。滤波系数根据你的控制周期调整周期短可以取小一点周期长取大一点。6.4 把解析结果打包成结构体散落的全局变量多了容易乱我习惯把 SBUS 相关的东西打包成一个结构体typedef struct { uint16_t channels[16]; uint8_t flags; uint8_t frame_lost; uint8_t failsafe; uint32_t last_frame_tick; } SBUS_Data_t;这样传递和调试都方便也便于后续扩展。结构体里带上时间戳主循环里可以判断数据新鲜度超时就报警。这套方案我从 F103 一直用到 F407 和 H7核心逻辑没变过只是时钟配置和 DMA 通道号不同。SBUS 解析本身不复杂难的是把接收、定界、解析、容错这几件事拆清楚各归各位。DMA 循环接收解决搬的问题IDLE 中断解决界的问题状态机解决解的问题三者配合好了CPU 几乎无感稳定性也上来了。最后提醒一句调试阶段一定要把原始字节流打印出来看别一上来就盯着通道值很多时候问题出在帧结构层面通道值只是表象。