STM32应对SBUS协议：DMA+空闲中断解析与编码全攻略

简介：这是一份面向STM32开发者的S.BUS协议完整解析与编码实现，压缩包内含源文件，提供UART配置、DMA接收、中断处理、数据解码与反码转换等核心逻辑的C语言实现。全套代码基于STM32F407设计，适配无人机、机器人等遥控设备场景，帮助读者直接在工程中集成S.BUS通信能力，省去查阅协议文档和底层寄存器调试的时间。相关文件仅2个，主要为sbus.c源文件与sbus.h头文件，包体约4KB，结构精简。目前已有7000余人学习下载，适合具备一定嵌入式基础、希望高效接入Futaba遥控链路或深入理解S.BUS帧格式的开发者参考。通过DMA方式降低CPU占用，同时覆盖错误检测与恢复机制，是学习完整SBUS收发流程和工程化移植的良好起点。

1. 引子：SBUS 这条总线，接法不对就是玄学

把遥控器接收机的 SBUS 输出接到 STM32 串口，很多人第一次都会翻车：明明接线对了，串口助手打印出来的却是满屏 0xFF 和 0x00，摇杆怎么拨都没反应。问题不在协议本身，而在 SBUS 用了三样反直觉的东西——100000 波特率、8E2 校验格式、反相电平，任何一个没配对都白搭。这份资源把 SBUS 在 STM32 上从解析到编码完整落地：接收端用 DMA 加空闲中断抓帧，按位拆包还原 16 通道摇杆值；发送端把姿态数据打包成 SBUS 帧，按固定周期喂给飞控或电调。适合正在搞飞控、遥控车、机械臂这类需要遥控输入的项目，也适合想把协议细节彻底搞明白的开发者。

2. 协议格式与硬件适配：25 字节帧结构、100000 波特率和反相电平

2.1 一帧 25 字节：从 0x0F 到 0x00 的位流真相

SBUS 一帧是固定 25 字节，比普通串口数据包紧凑得多。帧布局拆开看是四段：

这里最反直觉的是 16 个通道只占了 22 字节而不是 32 字节，因为每个通道不是 8bit 而是 11bit。16 × 11 = 176bit，除以 8 正好 22 字节，一个 bit 都不浪费。11bit 能表达 0~2047 的范围，舵机标准脉宽 1ms~2ms 对应通道值 352~1696，中位值 1024。有些接收机的输出会超过这个范围，所以解析时我一般会留出 173~1811 的整体安全区间做判断，但不强行钳位，交给上层业务决定要不要做限幅。

通道值为什么要 11bit 而不是 16bit？因为遥控链路带宽有限，10bit 又不够覆盖舵机满行程加死区，11bit 是当时权衡下来的结果。这也是 SBUS 能在一个波特率下塞进 16 通道的原因。

2.2 串口参数：8E2 格式和 100000 波特率

SBUS 的串口参数不是常见的 9600 或 115200，而是 100000 波特率、8 数据位、偶校验、2 停止位，简称 8E2。它比常见的 8N1 每个字节多 2bit（校验位 + 多一个停止位），所以 25 字节实际要传 300bit，在 100000 波特率下传输时间约 3ms。

看一组标准参数配置：

在 CubeMX 里配置时，波特率 100000 不在下拉列表里，直接手动输入即可。需要注意一个混淆点：开启偶校验以后，CubeMX 生成代码里的 WordLength 字段往往是UART_WORDLENGTH_9B。这不是说有效数据变成 9 位，而是硬件把校验位算进去了，实际数据寄存器里能读到的还是低 8 位。HAL 初始化代码长这样：

huart1.Init.BaudRate = 100000; huart1.Init.WordLength = UART_WORDLENGTH_9B; // 8数据位 + 1偶校验位 huart1.Init.StopBits = UART_STOPBITS_2; huart1.Init.Parity = UART_PARITY_EVEN; huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;

这里UART_WORDLENGTH_9B是新手最容易踩的坑：以为要选 8 位，结果生成代码里是 9 位就慌。实际上校验位在硬件层面被消费掉了，软件层拿到的还是 8bit 数据。如果你配成UART_WORDLENGTH_8B加偶校验，硬件反而无法正确对齐 SBUS 的帧边界，解析出来的通道值会周期性错乱。

2.3 反相信号：为什么 STM32 的 RX 引脚收不到正常数据

SBUS 物理层是反相 UART 信号：空闲时为低电平，起始位是高电平，与标准 UART 的极性完全相反。STM32 的串口外设默认认为空闲是高电平，直接把接收机 SBUS 输出接到 RX，MCU 会认为总线一直处于非空闲状态，收到的字节全是 0xFF 或者 0x00，数据完全不可用。

解决办法按优先级排有三个：

第一个是外部反相电路。最省事的做法是拿一个 NPN 三极管加两个电阻：SBUS 信号经过 1kΩ 电阻接到三极管基极，发射极接地，集电极通过 10kΩ 上拉到 3.3V 同时接 STM32 的 RX。SBUS 空闲低电平时三极管截止，RX 被上拉到高；数据位高电平时三极管导通，RX 被拉低，极性正好翻过来。

第二个是确认接收机是否提供了非反相输出。不少接收机除了标准 SBUS 反相引脚，还会额外引出一路非反相的串行输出（常见标法为 SBUS 和非反相 SBUS），如果有就直接用非反相引脚，硬件上一根线都不用加。

第三个是查看所用 STM32 系列的 USART_CR3 寄存器是否带 RXINV/TXINV 极性反转位。部分新系列有这个功能，但经典 F1/F4 基本没有，所以要翻参考手册确认，不要凭印象写代码。

3. 接收侧实现：DMA 加空闲中断抓帧，再按位拆包还原通道

3.1 为什么不用单字节中断：25 次中断换 1 次中断

SBUS 一帧 25 字节在 100000 波特率下要传 3ms 左右，帧周期普通模式 14ms、快速模式 7ms。如果用单字节接收中断，每一帧会产生 25 次中断，虽然 STM32 主频能扛住，但每次中断都要压栈出栈、进驱动回调，主循环里跑控制算法时很容易被频繁打断，抖动不小。

这套实现用的是 DMA 加空闲中断：DMA 把一整串字节搬进内存缓冲区，CPU 完全不参与每个字节的搬运；等到一帧传完、总线出现空闲电平，串口产生 IDLE 中断，这时只打断一次，CPU 一次性处理 25 字节。代码量不大，但效果明显。

启动接收用HAL_UARTEx_ReceiveToIdle_DMA，这是 HAL 库封装好的 API，它把 DMA 接收和空闲中断绑定在一起：

#define SBUS_FRAME_LEN 25 #define SBUS_RX_BUF_LEN (SBUS_FRAME_LEN * 4) uint8_t sbus_dma_buf[SBUS_RX_BUF_LEN]; void SBUS_StartReceive(void) { // 缓冲区比一帧长，DMA 有足够余量，避免临界状态丢数据 HAL_UARTEx_ReceiveToIdle_DMA(&huart1, sbus_dma_buf, SBUS_RX_BUF_LEN); }

接收完成后 HAL 库会回调HAL_UARTEx_RxEventCallback，在这个回调里解析数据并重新启动 DMA：

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart != &huart1) { return; } SBUS_OnFrame(sbus_dma_buf, Size); // 关键：必须重新启动 DMA，否则只收一次就再也不进回调 HAL_UARTEx_ReceiveToIdle_DMA(&huart1, sbus_dma_buf, SBUS_RX_BUF_LEN); }

Size是从上次启动到本次空闲中断之间实际接收到的字节数，正常情况下等于 25，但干扰和沾帧时可能不是，所以不能直接拿它当帧长用。另外如果固件库版本较老，没有HAL_UARTEx_ReceiveToIdle_DMA这个 API，就用标准库自己写 IDLE 中断：进入中断后读SR和DR清除 IDLE 标志，再用 DMA 的CNDTR寄存器算出接收长度，思路完全一样。

3.2 帧同步：不是收到 25 字节就一定是完整一帧

DMA 启动的时机不保证刚好对齐在帧头，可能从一帧中间开始抓，也可能因为上一帧刚结束、下一帧马上开始导致缓冲区里出现粘帧。所以处理帧的第一步永远是找帧头帧尾对齐，而不是按长度硬切。

void SBUS_OnFrame(const uint8_t *buf, uint16_t len) { if (len < SBUS_FRAME_LEN) { return; // 字节数不够一帧，直接丢弃 } // 滑窗搜索：帧头 0x0F 在起点，帧尾 0x00 在偏移 24 的位置 for (uint16_t i = 0; i <= len - SBUS_FRAME_LEN; i++) { if (buf[i] == 0x0F && buf[i + 24] == 0x00) { SBUS_ParseFrame(&buf[i]); break; } } }

帧尾 0x00 本身不是独一无二的值，通道数据区里也可能出现 0x00，所以这里必须同时校验帧头和帧尾，并且间距正好是 24 字节。如果只查帧头 0x0F，偶尔会把通道数据里的 0x0F 当成帧头，解析结果错乱。这个滑窗搜索足够应付沾帧场景，代价是几次内存比较，耗时可以忽略。

除了对齐，还要考虑丢帧。接收机断电、信号遮挡时总线上会停止发帧，如果代码没做超时判断，飞控会一直拿旧数据继续控制，那是很危险的事。实践中我一般加一个接收时间戳，超过 100ms 没有新帧就把通道值强制置为安全状态，具体逻辑放在上层业务里。

3.3 位拆包：从 176bit 里还原 16 个 11bit 通道

这是整个解析最核心的一段。16 个通道每个 11bit，从帧的第 2 字节开始连续排列，没有填充位。解析思路是把跨越字节边界的 11bit 通过移位和掩码重新拼出来。

void SBUS_ParseFrame(const uint8_t *f, uint16_t ch[16], uint8_t *flags) { // f[1]~f[22] 共 22 字节 = 176bit，正好承载 16 通道 x 11bit // 每个通道起始位偏移 = 通道号 * 11，用移位拼出 11bit 有效值 ch[0] = ((uint32_t)f[1] | (uint32_t)f[2] << 8 | (uint32_t)f[3] << 16) & 0x07FF; ch[1] = ((uint32_t)f[2] >> 3 | (uint32_t)f[3] << 5) & 0x07FF; ch[2] = ((uint32_t)f[3] >> 6 | (uint32_t)f[4] << 2 | (uint32_t)f[5] << 10) & 0x07FF; ch[3] = ((uint32_t)f[4] >> 1 | (uint32_t)f[5] << 7) & 0x07FF; ch[4] = ((uint32_t)f[5] >> 4 | (uint32_t)f[6] << 4) & 0x07FF; ch[5] = ((uint32_t)f[6] >> 7 | (uint32_t)f[7] << 1 | (uint32_t)f[8] << 9) & 0x07FF; ch[6] = ((uint32_t)f[9] >> 2 | (uint32_t)f[10] << 6) & 0x07FF; ch[7] = ((uint32_t)f[10] >> 5 | (uint32_t)f[11] << 3) & 0x07FF; ch[8] = ((uint32_t)f[12] | (uint32_t)f[13] << 8 | (uint32_t)f[14] << 16) & 0x07FF; ch[9] = ((uint32_t)f[13] >> 3 | (uint32_t)f[14] << 5) & 0x07FF; ch[10] = ((uint32_t)f[14] >> 6 | (uint32_t)f[15] << 2 | (uint32_t)f[16] << 10) & 0x07FF; ch[11] = ((uint32_t)f[16] >> 1 | (uint32_t)f[17] << 7) & 0x07FF; ch[12] = ((uint32_t)f[17] >> 4 | (uint32_t)f[18] << 4) & 0x07FF; ch[13] = ((uint32_t)f[18] >> 7 | (uint32_t)f[19] << 1 | (uint32_t)f[20] << 9) & 0x07FF; ch[14] = ((uint32_t)f[20] >> 2 | (uint32_t)f[21] << 6) & 0x07FF; ch[15] = ((uint32_t)f[21] >> 5 | (uint32_t)f[22] << 3) & 0x07FF; *flags = f[23]; // 标志字节：ch17/ch18/丢帧/失控保护 }

逐段解释这串移位逻辑。以通道 0 为例，它占位流的 bit0~bit10，其中 bit0~bit7 落在第 2 字节（f[1]），bit8~bit10 落在第 3 字节（f[2]）的低 3 位。所以f[1] | f[2] << 8 | f[3] << 16拼出了一个 24bit 的数，再& 0x07FF只留低 11 位，就是通道 0 的值。

再看通道 1，它从 bit11 开始，对应 f[2] 的 bit3 到 f[3] 的 bit5，所以先把 f[2] 右移 3 丢掉低 3 位，再把 f[3] 左移 5 放到高位，两者相或。每个通道起始位置都不同，表达式里的移位位数就是该通道在 176bit 流中的起始偏移对 8 取模。

这里有个必须注意的细节：所有参与移位的 f[n] 都要强制转成uint32_t。如果直接写f[2] << 8，编译器会按 uint8_t 运算，移位超过 8 位直接变 0，这是新手最容易踩的坑，我早期就因为这个排查了整整一个下午。

解析完成后可以顺手做个范围检查：

for (int i = 0; i < 16; i++) { if (ch[i] < 173 || ch[i] > 1811) { // 超出 SBUS 协议原始范围，标记该帧无效 return; } }

注意 173~1811 是协议物理极限，不是所有接收机都用满这个范围，所以这个检查只管极端越界，不做钳位。不同接收机的实际输出范围最好在调试阶段打出来看一下，避免把有效数据误杀。

4. 发送侧实现：通道值打包编码、定时器节奏和 DMA 发送

4.1 编码：把 16 个通道值塞回 22 字节数据区

编码是解码的逆过程，把每个 11bit 通道值按起始偏移写进 22 字节缓冲区。这里我用的是一种通用写法，不依赖手推算出的偏移表，维护起来更省心：

void SBUS_BuildFrame(uint8_t *f, const uint16_t *ch, uint8_t flags) { f[0] = 0x0F; // 先清空数据区，避免上一帧残留的位污染本次数据 for (int i = 1; i <= 22; i++) { f[i] = 0; } // 每个通道 11bit，按起始位偏移写入 for (int c = 0; c < 16; c++) { uint16_t val = ch[c] & 0x07FF; uint16_t bit_off = c * 11; // 该通道在 176bit 流里的起始偏移 uint8_t byte_idx = bit_off / 8; // 对应数据区第几个字节 uint8_t bit_idx = bit_off % 8; // 字节内的起始位 // 一个通道最多跨越 3 个字节，用 32 位临时变量承接 uint32_t tmp = (uint32_t)val << bit_idx; for (int i = 0; i < 3; i++) { if (byte_idx + i < 22) { f[1 + byte_idx + i] |= (uint8_t)(tmp >> (i * 8)); } } } f[23] = flags & 0x0F; f[24] = 0x00; }

这段代码的核心在tmp = val << bit_idx。因为 val 是 11bit，bit_idx 最大是 7，左移后 tmp 最多 18bit，存在 uint32_t 里完全够用，不会溢出。循环里的f[1 + byte_idx + i]把 tmp 的低 8 位、中 8 位、高 8 位依次写入连续字节，用|=是因为同一个目标字节可能同时承接上一个通道的尾部和当前通道的头部。

为什么要零帧数据区？因为 16 个通道的 11bit 是紧密排列的，某些字节只写了部分位，如果不先清零，上一次编码残留的高位会混进这次的通道值里，导致飞控收到的通道肩并肩地乱跳。这类问题很难从波形上看出来，属于那种排查到最后发现是初始化漏了的低级错误。

性能上，这个循环在 72MHz 主频下十几条指令就完事，一帧 3ms 的传输时间相比微乎其微，完全不需要预计算偏移表来优化。如果强迫症想省这几微秒，可以把 byte_idx 和 bit_idx 预计算成一张常量表，但可读性会差不少，我建议先跑通再改。

4.2 发送节奏：为什么必须用定时器加 DMA

SBUS 是周期广播式的，接收端不回应，发送端必须按固定周期持续发帧。周期一般选 7ms（快速模式）或 14ms（普通模式），不能靠主循环 delay 来实现，因为主循环一旦被其他任务阻塞，发送间隔就忽长忽短，飞控那边会认为信号异常。

标准做法是定时器中断里组帧，DMA 发送:

static uint8_t sbus_tx_frame[25]; static uint16_t sbus_tx_channels[16]; void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == SBUS_TIM) { // 用当前通道数据组帧，然后 DMA 发出，不阻塞 CPU SBUS_BuildFrame(sbus_tx_frame, sbus_tx_channels, 0x00); if (HAL_UART_Transmit_DMA(&huart1, sbus_tx_frame, 25) != HAL_OK) { // 如果上次 DMA 还没发完，返回 HAL_BUSY，这次直接跳过 } } }

定时器周期怎么算？以 72MHz 的 APB1 定时器时钟为例，先分频到 1MHz，即 Prescaler = 72 - 1，再设 Period = 14000 - 1，定时器 14000 次计数就是 14ms。对应代码如下：

htim4.Init.Prescaler = 72 - 1; // 72MHz / 72 = 1MHz，计数周期 1us htim4.Init.Period = 14000 - 1; // 14000 x 1us = 14ms

HAL_UART_Transmit_DMA是异步的，调用后立刻返回，CPU 可以继续干别的。每次进入中断前，上一帧的 25 字节早就发完了（3ms 远小于 7ms 周期），所以正常情况下不会撞车；万一撞了，返回HAL_BUSY，跳过这一帧也比阻塞在中断里强，中断里跑阻塞发送是绝对不可取的。

4.3 验证编码结果：把 STM32 当成一个 SBUS 信号源

编码写完怎么验证？最直接的方法是用逻辑分析仪或者示波器看 TX 引脚的波形，确认波特率、帧间隔和数据位排列符合协议。没有仪器的话，还有一招：把 STM32 的 TX 通过反相电路接到飞控的 SBUS 输入，在飞控地面站里看通道监视器，摇杆值变化能实时反映出来，说明编码链路是通的。

整套编码代码在闭环里的角色是替代接收机输出。比如我想测试一块飞控板但手上没有遥控器，就可以让 STM32 固定输出一组通道值，验证飞控的油门响应、失控保护逻辑，比手动拨摇杆稳定得多。这个思路做自动化测试特别有用，还能顺便测出飞控对丢帧、failsafe 标志位的反应是否符合预期。

5. 避坑记录：SBUS 接入 STM32 最容易翻车的几个点

5.1 现象：串口助手打印满屏 0xFF 和 0x00

原因：SBUS 是反相电平，直接接 STM32 的 RX，极性不匹配，MCU 把所有位都读反了。这不是波特率问题，也不是代码问题。

解决：确认接收机是否有非反相输出引脚；没有就用 NPN 三极管做反相电路，或者确认所用 STM32 系列是否支持 USART 极性反转寄存器。我每次换新板子都会先看参考手册确认，不在这一步省时间。

5.2 现象：通道值偶尔跳变到 2047 或 0，摇杆不动也跳

原因：帧同步只查了帧头 0x0F，没查帧尾 0x00，导致把通道数据区里恰巧出现的 0x0F 当成帧起始，后续 24 字节整体错位。

解决：帧头帧尾同时校验，且间距必须正好是 24 字节；另外解析表达式里的移位必须用 uint32_t 强转，否则 uint8_t 左移超过 8 位会变成 0，拼出的通道值就是 0 或 2047 这种极端值。

5.3 现象：只有第一帧正常，之后再无新数据

原因：HAL_UARTEx_ReceiveToIdle_DMA是一次性的，DMA 接收完成后没有重新启动，或者重启顺序放在了解析之后、但因为中途 return 而跳过了。

解决：把重启 DMA 的调用放在回调函数最末尾，保证任何分支都能执行到。如果发现一帧数据正在接收时又重启了 DMA，会覆盖缓冲区，那就在回调开头用标志位通知主循环延后处理，不要在中断里做太多事。

5.4 现象：用定时器发 SBUS 帧，间隔忽长忽短，飞控时断时连

原因：发送端用了阻塞式HAL_UART_Transmit或者主循环 delay 控制帧周期，其他任务一插队，帧间隔就乱套。

解决：定时器中断只负责组帧和触发 DMA，发送交给 DMA 异步完成，帧间隔由定时器周期严格决定。还要检查定时器预分频和 Period 计算是否准确，用示波器测一下帧头间隔比对着调，最稳。

5.5 现象：接上接收机以后单片机频繁复位

原因：SBUS 输出和 STM32 引脚电平不匹配，接收机的地和单片机地没有共地，或者 3.3V 引脚被外部 5V 电平灌入。

解决：先确认接收机供电电压和逻辑电平和单片机一致，共地必须保证；如果接收机输出幅度接近 3.3V 上限，串一个小电阻再进 RX，防止脉冲毛刺打坏引脚。这块我之前吃过亏，一个 100Ω 电阻就能解决的事，当时排查了半天的程序逻辑。

6. 二次开发：把 SBUS 解析改造成遥控舵机控制器

拿到这套解析代码以后，最自然的改造是把通道值映射成舵机 PWM 输出。假设定时器输出比较通道配置成了 PWM 模式，周期 20ms，通道值 352~1696 对应脉宽 1ms~2ms，映射公式如下：

// ch_value 是 SBUS 原始通道值，返回 0~65535 对应的比较寄存器值 uint32_t duty = 500 + (uint32_t)(ch_value - 352) * 1500 / (1696 - 352);

500 到 2000 单位是微秒，再根据定时器计数频率换算成 CCR 值。注意先转 uint32_t 再乘，避免 16 位溢出。映射完以后在定时的 PWM 中断或者更新事件里一次性更新 4~8 路舵机，控制周期稳定在现有 SBUS 帧率上。

第二个值得加的是超时保护。飞控场景里信号丢失不能继续用旧值控制，我会在解析外层放一个时间戳，超过 100ms 没收到新帧就把油门通道归零并置 failsafe 标志：

if (sbus_last_tick_ms - sbus_last_frame_ms > 100) { // 信号丢失，油门通道强制回中，舵机保持 }

第三个方向是数据记录。把解析出的 16 通道值每帧打包成 32 字节二进制记录，写到 SD 卡或者通过 USB 虚拟串口吐给地面站，后期可以做飞行数据回放分析，比单纯看串口文本直观得多。

这套代码我在多个项目里复用后最大的感受是：SBUS 本身不复杂，复杂的是那些看不见的边界条件——粘帧、丢帧、极性、校验位。从那以后我每次调 SBUS 相关的板子，都会先拿示波器看 RX 引脚的波形确认极性正常，再进代码调试，省掉了很多冤枉路。希望这套解析加编码的实现能帮你把 SBUS 这条路一次走通。

本文还有配套的精品资源，点击获取