STM32高效解析SBUS：DMA循环接收与IDLE中断实战

1. 为什么 SBUS 解析值得单独拿出来讲

SBUS 这个协议在航模、机器人、工业遥控领域用得非常多，说白了它就是一根串口线传 16 个通道的遥控数据。很多人第一次接触 SBUS 的时候会觉得奇怪：明明波特率是 100000，校验位是偶校验，停止位是 2 位，数据还是反相的，这些参数跟常规串口配置完全不一样。更麻烦的是它一帧 25 个字节，每 14 毫秒来一帧，如果你用传统的“接收中断里一个字节一个字节读”的方式，CPU 会被频繁打断，稍微复杂一点的项目根本扛不住。

我在实际项目里踩过最典型的坑就是：用 HAL 库的HAL_UART_Receive_IT单字节接收，主循环里还要跑 PID 和电机控制，结果遥控数据丢帧严重，飞机在空中直接失控。后来换成 DMA 循环接收加 IDLE 中断，再配一个状态机做协议解析，整个系统才稳下来。这套方案的核心思路是：DMA 负责把数据无声无息地搬到内存，IDLE 中断负责告诉你“一帧结束了”，状态机负责把原始字节翻译成 16 个通道值。三者各司其职，CPU 占用率极低，实时性也有保障。

这篇文章适合谁看？如果你正在用 STM32 做飞控、机器人遥控接收、云台控制、或者任何需要解析 SBUS 信号的嵌入式项目，并且已经会用 CubeMX 配置基本外设，那这篇内容可以直接抄作业。如果你还没接触过 DMA 和 IDLE 中断，也没关系，我会把每个环节的原理和配置都拆开讲清楚。

注意：SBUS 是 Futaba 的专有协议，接收机输出的是反相串口信号。STM32 的 USART 外设本身不支持硬件反相，所以必须外加一个反相电路，或者用软件方式处理。这一点后面会详细说。

2. 整体方案设计与核心思路拆解

2.1 为什么不用传统接收中断

先算一笔账。SBUS 波特率 100000，偶校验，2 位停止位，一帧 25 字节。每帧间隔 14ms，也就是说每秒大约 71 帧，每帧 25 字节，总共每秒约 1785 个字节。如果每个字节都触发一次接收中断，那每秒就是 1785 次中断。听起来好像不多？但问题是每次中断都要进 HAL 库的中断处理函数，里面有一堆状态判断和回调分发，实际开销远不止“读一个寄存器”那么简单。

更关键的是，SBUS 帧内字节之间的间隔非常短。100000 波特率下，一个字节（含起始位、8 数据位、校验位、2 停止位，共 12 位）的传输时间是 120 微秒。如果 CPU 在某个中断里多待了一会儿，下一个字节就可能丢失。丢一个字节，整帧 25 字节就全废了，因为 SBUS 没有帧头标识，你没法知道丢的是哪一帧的哪个位置。

DMA 循环接收的好处就在这里：你给 DMA 一个 25 字节的缓冲区，让它不停地循环填充，CPU 完全不用管每个字节的搬运。IDLE 中断则是在串口总线空闲时触发，告诉你“这一帧数据已经收完了”。两者配合，CPU 只需要在 IDLE 中断里打个标记，主循环或者任务里再去解析缓冲区就行。

2.2 状态机在解析中的角色

SBUS 一帧 25 字节的格式是这样的：

16 个通道每个 11 位，总共 176 位，正好 22 字节。解析的时候需要把这 22 字节按位拆开，每 11 位组成一个通道值。这个位操作如果写在中断里，代码会很长，而且容易出错。状态机的思路是：把解析过程分成几个状态，每个状态只做一件事，主循环里轮询状态机，收到完整帧就切换状态。

我一般用三个状态就够了：等待帧头、接收数据、校验并输出。实际实现的时候，因为 DMA 已经在后台把数据收完了，状态机其实只需要做“检查帧头是否正确、检查帧尾是否正确、拆包”这三步。但为了代码清晰，我还是会把它写成状态机的形式，方便后续扩展。

2.3 DMA 循环模式与普通模式的选择

这里有一个关键决策：DMA 用循环模式还是普通模式？

普通模式下，DMA 传输完指定数量的数据就停止，需要重新启动。如果你用普通模式，每次 IDLE 中断里都要重新配置 DMA，代码麻烦不说，还容易在重新配置的窗口期丢数据。

循环模式下，DMA 传输完指定数量后自动回到缓冲区开头继续传输，永远不停。你只需要在 IDLE 中断里读取当前 DMA 的剩余传输数量，就能知道这一帧收了多少字节。对于 SBUS 这种固定长度、连续不断的协议，循环模式是唯一合理的选择。

但循环模式也有一个坑：如果缓冲区大小设成 25，而实际一帧也是 25 字节，那 DMA 的写指针和读指针会刚好重合，你没法判断这一帧是新数据还是旧数据。我的做法是把缓冲区设成 50 字节（两帧的大小），这样即使有一帧延迟，也不会覆盖正在解析的数据。IDLE 中断里通过__HAL_DMA_GET_COUNTER获取剩余计数，算出这一帧的实际长度和起始位置。

3. 核心细节解析与实操要点

3.1 硬件反相电路不能省

STM32 的 USART 引脚默认是高电平空闲，起始位是低电平。SBUS 信号经过接收机内部反相后，输出的是反相串口：空闲时低电平，起始位是高电平。如果你直接把 SBUS 信号接到 STM32 的 RX 引脚，串口会一直认为总线在活动状态，根本收不到正确的帧。

解决方案有两种：

• 硬件反相：用一个 NPN 三极管或者专用反相芯片（比如 74HC14）把信号反相后再接入 RX。这是最稳妥的做法，推荐优先考虑。
• 软件反相：有些 STM32 型号支持 USART 的 TX/RX 引脚互换，或者支持内部反相配置。但并不是所有型号都有这个功能，查参考手册确认。如果没有，就只能用硬件反相。

我个人的经验是：不要在这上面省事。一个三极管加两个电阻的成本不到五毛钱，但如果你试图用软件方式绕过，调试时间可能要多花好几个小时。

3.2 CubeMX 中的串口配置

在 CubeMX 里配置 USART 的时候，参数必须严格按 SBUS 的要求来：

• Baud Rate：100000
• Word Length：8 Bits
• Parity：Even
• Stop Bits：2
• Data Direction：Receive Only（如果你只接收）
• Over Sampling：16 Samples

这里有一个细节：HAL 库在配置偶校验的时候，会把数据长度自动扩展为 9 位（8 数据位 + 1 校验位）。所以你在代码里看到huart->Init.WordLength可能是UART_WORDLENGTH_9B，这是正常的，不用改。

DMA 配置方面，在 DMA Settings 里添加 USART_RX 的 DMA 请求，模式选 Circular，数据宽度都是 Byte，优先级可以设 Medium 或 High。NVIC 里记得把 USART 的全局中断打开，因为 IDLE 中断是通过 USART 中断向量触发的。

3.3 IDLE 中断的使能与处理

HAL 库默认不开启 IDLE 中断，你需要手动调用：

__HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE);

这行代码放在MX_USART1_UART_Init()之后、主循环之前。注意，IDLE 中断和 DMA 传输完成中断是两回事。DMA 传输完成中断在循环模式下永远不会触发（因为循环模式不产生完成事件），所以你必须依赖 IDLE 中断来判断帧结束。

IDLE 中断的处理函数在stm32f1xx_it.c里的USART1_IRQHandler中。HAL 库的中断处理函数会先判断中断标志，然后调用相应的回调。但 IDLE 中断没有专门的 HAL 回调，你需要自己在USART1_IRQHandler里手动清除标志并处理：

void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); // 这里做帧结束处理 sbus_idle_callback(); } HAL_UART_IRQHandler(&huart1); }

注意：清除 IDLE 标志的顺序很重要。必须先读 SR 寄存器再读 DR 寄存器，HAL 库的__HAL_UART_CLEAR_IDLEFLAG宏已经帮你做了这件事。如果你自己写清除逻辑，顺序错了标志清不掉，中断会一直触发。

3.4 缓冲区设计与 DMA 计数读取

前面提到缓冲区设成 50 字节。具体做法是：

#define SBUS_BUF_SIZE 50 uint8_t sbus_dma_buf[SBUS_BUF_SIZE]; HAL_UART_Receive_DMA(&huart1, sbus_dma_buf, SBUS_BUF_SIZE);

在 IDLE 中断里，通过__HAL_DMA_GET_COUNTER(&hdma_usart1_rx)获取 DMA 剩余传输数量。假设剩余数量是remain，那么这一帧的结束位置就是SBUS_BUF_SIZE - remain。但 SBUS 一帧固定 25 字节，所以你需要从结束位置往前推 25 字节，找到帧头 0x0F，然后把这 25 字节拷贝到一个独立的解析缓冲区里。

为什么要拷贝？因为 DMA 在后台还在继续写，如果你直接在 DMA 缓冲区上解析，解析到一半数据可能被新帧覆盖。拷贝到独立缓冲区只需要 25 字节的内存，但能保证解析过程的原子性。

拷贝的时候要注意环形缓冲区的边界问题。如果结束位置小于 25，说明帧跨越了缓冲区末尾，需要分两段拷贝。这个逻辑写起来不复杂，但很容易漏掉，建议单独写一个函数处理。

4. 实操过程与核心环节实现

4.1 状态机设计与代码实现

状态机我一般定义三个状态：

typedef enum { SBUS_STATE_WAIT_HEADER, SBUS_STATE_RECEIVE_DATA, SBUS_STATE_PARSE } sbus_state_t;

实际运行流程是这样的：

1. WAIT_HEADER：检查拷贝过来的 25 字节缓冲区第一个字节是不是 0x0F。如果不是，丢弃并回到等待状态。如果是，进入 RECEIVE_DATA。
2. RECEIVE_DATA：检查第 24 字节是不是 0x00。如果不是，说明帧尾错误，丢弃并回到 WAIT_HEADER。如果是，进入 PARSE。
3. PARSE：把 22 字节通道数据拆成 16 个 11 位的值，存入sbus_channels[16]数组。解析完成后回到 WAIT_HEADER，等待下一帧。

拆包的核心代码是这样的：

void sbus_parse_channels(uint8_t *buf, uint16_t *channels) { channels[0] = ((buf[1] | buf[2]<<8) & 0x07FF); channels[1] = ((buf[2]>>3 | buf[3]<<5) & 0x07FF); channels[2] = ((buf[3]>>6 | buf[4]<<2 | buf[5]<<10) & 0x07FF); channels[3] = ((buf[5]>>1 | buf[6]<<7) & 0x07FF); channels[4] = ((buf[6]>>4 | buf[7]<<4) & 0x07FF); channels[5] = ((buf[7]>>7 | buf[8]<<1 | buf[9]<<9) & 0x07FF); channels[6] = ((buf[9]>>2 | buf[10]<<6) & 0x07FF); channels[7] = ((buf[10]>>5| buf[11]<<3) & 0x07FF); channels[8] = ((buf[11]>>8| buf[12]<<0 | buf[13]<<8) & 0x07FF); channels[9] = ((buf[13]>>3| buf[14]<<5) & 0x07FF); channels[10] = ((buf[14]>>6| buf[15]<<2 | buf[16]<<10) & 0x07FF); channels[11] = ((buf[16]>>1| buf[17]<<7) & 0x07FF); channels[12] = ((buf[17]>>4| buf[18]<<4) & 0x07FF); channels[13] = ((buf[18]>>7| buf[19]<<1 | buf[20]<<9) & 0x07FF); channels[14] = ((buf[20]>>2| buf[21]<<6) & 0x07FF); channels[15] = ((buf[21]>>5| buf[22]<<3) & 0x07FF); }

这段代码看起来有点绕，但逻辑是固定的：每个通道 11 位，从第 1 字节开始按位偏移。你可以用循环加移位的方式写得更通用，但展开写执行效率更高，编译器也能更好地优化。

4.2 通道值映射与死区处理

SBUS 的通道原始值范围是 172 到 1811，中点是 992。但实际遥控器输出的范围可能略有不同，我见过 174 到 1809 的，也见过 170 到 1813 的。如果你直接把原始值当 PWM 占空比用，会出现中位偏移和行程不对称的问题。

我的做法是做一个线性映射，把原始值映射到 -1000 到 +1000 的范围：

int16_t sbus_map_channel(uint16_t raw) { int32_t val = (int32_t)raw - 992; if (val > 819) val = 819; if (val < -819) val = -819; return (int16_t)(val * 1000 / 819); }

这里的 819 是 1811 减去 992 的结果。映射之后，中位是 0，满行程是 ±1000，后续做 PID 或者混控的时候非常方便。

死区处理也很重要。遥控器摇杆在中位附近通常有几微秒的抖动，如果不做死区，电机会一直有微小输出。我一般设 10 到 20 的死区：

if (abs(mapped) < 15) mapped = 0;

这个值可以根据你的遥控器实际情况调整。太大会导致操控不灵敏，太小会抖动。

4.3 失效保护与帧丢失处理

SBUS 的第 23 字节是标志位，其中 bit2 表示帧丢失，bit3 表示失效保护。这两个标志非常关键，尤其是在飞控项目里。

帧丢失意味着接收机没有收到发射机的信号，但还在输出最后一帧数据。失效保护意味着接收机已经进入预设的失控保护状态。我的处理方式是：一旦检测到失效保护标志，立即把所有通道值归零或者切换到预设的安全值。

if (buf[23] & 0x08) { // 失效保护触发 for (int i = 0; i < 16; i++) { sbus_channels[i] = 0; } sbus_failsafe_flag = 1; }

另外，我还建议加一个超时检测。如果超过 50ms 没有收到新的 SBUS 帧，就认为接收机断连，主动进入安全状态。这个超时可以用一个简单的计数器实现，在 IDLE 中断里清零，在主循环里累加。

4.4 主循环中的任务调度

状态机的解析和通道映射不应该放在中断里做。中断里只做最轻量的操作：拷贝数据、设置标志位。真正的解析、映射、控制逻辑都放在主循环里。

我的主循环结构大概是这样的：

while (1) { if (sbus_frame_ready) { sbus_frame_ready = 0; sbus_state_machine(); } if (sbus_parse_done) { sbus_parse_done = 0; sbus_update_channels(); control_loop(); } // 其他任务 }

这样中断的响应时间极短，不会影响其他外设的中断处理。如果你用的是 RTOS，可以把状态机放在一个低优先级的任务里，通过信号量或者消息队列触发。

5. 常见问题与排查技巧实录

5.1 收不到数据或者数据全是乱码

这是最常见的问题，排查顺序如下：

我遇到过一次特别隐蔽的问题：反相三极管的基极电阻太大，导致信号上升沿变缓，在 100000 波特率下偶尔误码。后来把电阻从 10k 换成 4.7k 就好了。所以如果你用的是三极管反相，电阻值不要太大。

5.2 IDLE 中断频繁触发

IDLE 中断在总线空闲时触发，但如果你的串口配置有问题，比如停止位设成了 1 位，而 SBUS 实际是 2 位，那每个字节后面都会出现一个短暂的空闲状态，导致 IDLE 中断在每个字节后都触发。

解决方法很简单：确认停止位是 2 位。另外，如果你在 IDLE 中断里没有正确清除标志，中断也会反复触发。HAL 库的__HAL_UART_CLEAR_IDLEFLAG宏会先读 SR 再读 DR，顺序不能错。

5.3 DMA 缓冲区数据错位

如果你发现解析出来的通道值偶尔跳变或者错位，很可能是 DMA 缓冲区的读写冲突。DMA 在后台写，你在前台读，如果读的时候 DMA 刚好写到同一个位置，数据就会不一致。

解决方案有两个：一是把缓冲区设成两帧大小，读的时候避开 DMA 正在写的区域；二是在 IDLE 中断里先暂停 DMA，拷贝完再恢复。我一般用第一种，因为暂停 DMA 会引入额外的延迟。

还有一个细节：__HAL_DMA_GET_COUNTER返回的是剩余传输数量，但这个值在 DMA 循环模式下会不断变化。你需要在 IDLE 中断里第一时间读取它，不要等到主循环里再读，否则计数可能已经变了。

5.4 通道值抖动严重

通道值抖动通常有三个来源：遥控器摇杆本身的抖动、SBUS 传输误码、解析代码的位操作错误。

先排除解析错误：用固定的测试数据喂给解析函数，看输出是否稳定。如果解析没问题，再看遥控器。有些廉价遥控器的摇杆电位器磨损后会在中位附近抖动，这种情况只能加死区或者换遥控器。

如果是传输误码，检查反相电路和线缆长度。SBUS 信号线不要超过 30cm，太长容易受干扰。如果必须长距离传输，考虑用屏蔽线或者降低波特率（但 SBUS 标准就是 100000，降不了）。

5.5 与其它 DMA 通道冲突

STM32 的 DMA 控制器有多个通道，每个通道可以映射到不同的外设。如果你同时用了串口 DMA、ADC DMA、SPI DMA，可能会遇到通道冲突或者优先级反转的问题。

我的建议是：给 SBUS 的 DMA 通道设最高优先级，因为它的实时性要求最高。在 CubeMX 的 DMA Settings 里可以直接设优先级。另外，检查一下 DMA 控制器是否支持你所用的通道组合，有些低端型号的 DMA 通道映射是固定的，不能随意分配。

提示：如果你用的是 STM32F103，USART1_RX 通常映射到 DMA1 Channel5。这个通道和 SPI1_RX、TIM2_CH1 等外设有冲突，配置的时候要注意。

6. 性能优化与扩展思路

6.1 CPU 占用率实测

我用 STM32F103C8T6 跑这套方案，主频 72MHz，实测 CPU 占用率不到 3%。具体数据是：IDLE 中断每 14ms 触发一次，每次执行时间约 2 微秒；状态机解析一帧约 8 微秒；通道映射和控制循环约 20 微秒。加起来每 14ms 消耗约 30 微秒，占用率约 0.2%。剩下的 CPU 时间完全可以跑 PID、姿态解算、电机控制等任务。

如果你用 STM32F4 或者 F7 系列，主频更高，占用率会更低。这套方案的可扩展性很好，加几个通道或者换更复杂的控制算法都不会有压力。

6.2 双缓冲与零拷贝优化

如果你对性能有极致要求，可以试试双缓冲方案：准备两个 25 字节的解析缓冲区，IDLE 中断里交替使用。DMA 缓冲区只负责接收，解析缓冲区负责处理，两者完全隔离。这样连拷贝操作都可以省掉，直接在 DMA 缓冲区上解析，但需要确保解析速度跟得上帧率。

零拷贝的另一个思路是用 DMA 的双缓冲模式（Double Buffer Mode），STM32 的某些 DMA 控制器支持这个功能。配置好之后，DMA 自动在两个缓冲区之间切换，你只需要在中断里处理当前非活动缓冲区即可。这个方案最优雅，但配置起来稍微复杂一点，适合对性能有极致要求的场景。

6.3 从 SBUS 扩展到其他协议

这套“DMA 循环接收 + IDLE 中断 + 状态机”的框架不仅适用于 SBUS，还可以扩展到很多其他串口协议：

• CRSF 协议：波特率 420000，帧头 0xC8，长度可变。状态机需要增加一个“读取长度”的状态。
• Modbus RTU：帧间隔 3.5 个字符时间，IDLE 中断天然适合检测帧结束。状态机需要处理地址、功能码、CRC 校验。
• 自定义二进制协议：只要帧头固定、长度固定或者有长度字段，都可以用这套框架。

我后来做的一个项目里，同一个串口既要收 SBUS 又要收调试信息，我就是用状态机根据帧头区分协议类型，一套代码处理两种数据，非常灵活。

6.4 调试技巧与工具推荐

调试 SBUS 的时候，光看代码很难发现问题。我一般会用以下几个工具：

• 逻辑分析仪：抓 RX 引脚的波形，看波特率、帧间隔、数据内容是否正确。便宜的逻辑分析仪几十块钱就能买到，但能省下大量调试时间。
• 串口助手：把解析后的通道值通过另一个串口打印出来，实时观察通道变化。
• STM32 ST-LINK Utility：直接查看内存中的 DMA 缓冲区和解析结果，不用改代码加打印。
• Keil 的 Logic Analyzer：如果你用 Keil 调试，可以在仿真模式下看变量的实时波形，非常直观。

我个人最推荐逻辑分析仪。SBUS 的问题十有八九出在硬件层面，逻辑分析仪能一眼看出来是信号问题还是代码问题。

7. 我踩过的坑与实操心得

第一个坑是忘记使能 IDLE 中断。CubeMX 生成的代码默认不开启 IDLE 中断，我一开始以为 DMA 配置好了就能收数据，结果调试了半天发现 IDLE 中断根本没触发。后来在MX_USART1_UART_Init()后面加了一行__HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE)才搞定。这个坑很低级，但确实容易忘。

第二个坑是DMA 缓冲区大小设成了 25。当时想着一帧正好 25 字节，缓冲区设 25 最省内存。结果发现 DMA 写指针和读指针经常重合，解析出来的数据时好时坏。后来改成 50 字节，问题立刻消失。所以缓冲区一定要留余量，不要卡着帧长度设。

第三个坑是在中断里做浮点运算。我一开始把通道映射的除法写在 IDLE 中断里，结果发现中断执行时间从 2 微秒涨到了 20 微秒。STM32F103 没有硬件浮点单元，浮点除法是软件模拟的，非常慢。后来把映射逻辑挪到主循环里，中断只做数据拷贝和标志设置，问题解决。

第四个坑是反相电路的供电问题。我用三极管反相的时候，发射极接地，集电极通过上拉电阻接 3.3V，基极接 SBUS 信号。结果发现输出信号的高电平只有 2.5V 左右，STM32 识别为高电平但 margin 不够，偶尔误码。后来把上拉电阻从 10k 换成 4.7k，高电平升到 3.1V，稳定了。所以上拉电阻的阻值要根据实际信号源的内阻来调，不能随便选。

第五个坑是多个串口共用 DMA 控制器时的优先级问题。我在一个项目里同时用了 USART1 收 SBUS 和 USART2 收 GPS 数据，两个都用了 DMA。结果发现 SBUS 偶尔丢帧，GPS 数据倒是很正常。查了半天发现是 DMA 通道优先级设反了，GPS 的优先级比 SBUS 高，导致 SBUS 的 DMA 请求偶尔被延迟。把 SBUS 的 DMA 优先级调到最高之后，问题解决。

这些坑说到底都是细节问题，但嵌入式开发就是这样，一个细节没注意到，整个系统就不稳定。我的建议是：每配置一个外设，都单独测试通过之后再集成。不要一次性把所有外设都配好再调试，出了问题你根本不知道是哪个环节的错。