SBUS 这东西玩航模、做飞控、搞机器人遥控接收的人迟早要正面撞上。我第一次在 STM32F103 上试着解 SBUS 时光是把串口收到的数据变成 16 个通道值就折腾了整整两个晚上——第一晚死在 100000 波特率和 8E2 这两个非标准参数上第二晚死在轮询还是中断收的纠结里。最后定下来的方案就是这套组合HAL 库 DMA 循环接收 IDLE 中断 状态机解析。定稿后我连续开机跑了一个周末遥控器全程上电一帧都没丢通道值稳定得像用示波器量过一样。这套东西并不只对 SBUS 有用。凡是突发式、变长、带帧头帧尾的串口协议比如 Modbus RTU、MAVLink、常见的自定义指令帧都可以直接套同一个骨架。所以我下面先讲清楚 SBUS 协议本身为什么要这么设计再讲 CubeMX 配置、DMA 循环接收的代码框架、状态机解析和位操作提取最后把实测踩过的坑列出来。新手照着走一遍能跑通被串口丢字节折磨过的人也能从里面找到对应的解。1. SBUS 协议本身藏着四个必须提前知道的特点1.1 反相电平F103 上必须加一级硬件反相SBUS 的物理层和普通 UART 最大的区别是它是在 UART 基础上做了电平反相。普通 UART 空闲时是高电平SBUS 空闲时是低电平普通 UART 的起始位是低电平SBUS 的起始位是高电平。如果你直接把接收机的 SBUS 引脚接到 STM32 的 RX 上收到的全是乱码因为串口外设把每一个电平都理解反了。解决思路有两条第一硬件上用三极管做一级反相器第二用支持串口信号反相的 MCU 型号在寄存器里直接把 RXINV 置位。STM32F103 的 USART 没有 RXINV/USART 信号反相功能所以 F103 上老老实实用硬件反相。我用的电路非常传统SBUS 信号输出经 10kΩ 电阻接到 NPN 三极管2N3904 或 S8050 都行的基极发射极接地集电极接一个 10kΩ 上拉电阻到 3.3V同时把集电极引到 STM32 的 RX 引脚。SBUS 空闲时为低电平三极管截止集电极被上拉为高UART 看到的是正常的空闲高电平SBUS 来起始位时为高电平三极管导通集电极被拉低UART 看到正常的起始位低电平。这样一进一出电平就被还原成普通 UART 信号了。如果你的接收机输出的是 5V 的 SBUS这个电路同样能用基极限流电阻负责把基极电流限制住集电极上拉到 3.3V 也保证了 STM32 引脚不会吃到 5V 电平。注意一点少数接收机的 SBUS 输出是开漏结构如果逻辑分析仪上看到信号幅度不够或者波形上沿很缓就在 SBUS 输入那端对地加一个 10kΩ 下拉电阻确切说给开漏信号加上拉具体看输出结构这个属于见招拆招不用一开始就加。1.2 100000 baud 与 8E2跟常用的 115200/9600 完全不同SBUS 的波特率是 100000不是 115200也不是 9600。串口助手随便设一个 115200 就去抓包的人抓出来的全是错位乱码。更麻烦的是帧格式SBUS 事实标准是 8 数据位 偶校验 2 停止位缩写 8E2。这里有个特别容易翻车的点在 STM32 HAL 里配置 8 数据位 校验位时Word Length 要选 9 Bits (including Parity)对应参数 UART_WORDLENGTH_9B UART_PARITY_EVEN UART_STOPBITS_2。很多人想当然地选 8 Bits结果奇偶校验位把数据挤掉了一位解出来的通道值完全错位。原理是STM32 USART 的字长包含校验位M 位设成 9 位帧、同时开启偶校验硬件才能腾出 8 位给真实数据校验位由硬件自动剥离DMA 收到的仍然是干净的 8 位字节。这个配置我在 CubeMX 里反复验证过选 8E2 就对了。个别接收机或者某些固件模式输出的可能是 8N2 甚至 8N1如果你发现帧错误率极高、解析值偶尔跳变再回来确认一下手里接收机的实际输出格式。但绝大多数接收机包括主流的 Futaba/FrSky 系都是 8E2照这个配没问题。1.3 25 字节帧结构1 字节帧头 22 字节通道数据 1 字节标志 1 字节帧尾SBUS 一帧固定 25 字节结构如下字节 0帧头固定 0x0F字节 1~2216 个通道的 11 位数据共 176 位正好 22 字节字节 23标志字节里面打包了第 17/18 通道、丢帧标志、Failsafe 标志字节 24帧尾固定 0x00这个结构决定了两个事第一帧的长度是固定的 25 字节但通道数据是 11 位打包的不是每个通道一个字节解包时必须做位操作第二帧头 0x0F 和帧尾 0x00 并不是协议层独有的通道数据里完全可能恰好出现 0x0F 或 0x00所以光凭找到一个 0x0F还不能确认是帧头必须配合帧尾校验和状态机来处理。1.4 14ms 的帧周期决定了接收方案的天花板SBUS 接收机一般每 14ms 发一帧部分支持高速模式的接收机是 7ms。算一下100000 baud 下一个 8E2 字符是 1 起始位 8 数据位 1 校验位 2 停止位共 12 位耗时 120us。一帧 25 字节就是 300 位约 3ms。也就是说接收机每 14ms 里花 3ms 连续发一帧然后有约 11ms 的总线空闲时间。这个3ms 突发 11ms 空闲的节奏非常关键。它意味着每一帧数据在串口线上都是一个清晰的突发块块和块之间有足够长的静默期。这个静默期正好可以被 UART 的 IDLE 中断捕捉到——于是就有了下面要讲的方案选型。2. 接收方案取舍轮询、逐字节中断、DMAIDLE 到底差在哪2.1 轮询接收帧间隙只有 11ms主循环一忙就丢最简单的做法是在主循环里不断查 RXNE 标志来一个字节读一个。SBUS 一帧 3ms 内要连续读出 25 个字节平均 120us 就得读一次。主循环里一旦穿插了耗时操作比如刷 OLED、写 Flash、跑 PID 运算字节就漏了。而且轮询模式下的漏是静默的你不会立刻发现等到通道值跳动才意识到丢帧定位成本很高。轮询唯一的优点是代码极其简单适合在调试初期验证电平反相和波特率配置是否正确正式跑系统就别指望它了。2.2 逐字节中断能跑但系统一紧张就丢字节用 USART 的 RXNE 中断每个字节进一次中断看起来比轮询靠谱。算下来每秒大约 1700 多次中断25 字节 × 71 帧单次中断处理也就几百个周期CPU 占用其实不高。问题在于中断处理必须保证在下一个字节到达前完成退出一旦有更高优先级的中断抢占了 USART 中断或者某段代码关了中断超过 120usRXNE 里的字节就会被新字节覆盖丢得神不知鬼不觉。我最早一版就是用逐字节中断写的调试时好好的接入电机驱动、打开 PWM 输出后通道值开始随机跳。查了半天才定位到是中断被其他外设中断延迟了。后来干脆弃用逐字节中断换成 DMA问题一次性消失。2.3 DMA 循环接收 IDLE 中断一次突发只打扰 CPU 一次DMA 的活是每当 RXNE 置位DMA 控制器自动把数据寄存器里的字节搬到内存缓冲区完全不占用 CPU。这解决了两件事第一不管 CPU 当时在忙什么只要 DMA 及时字节与字节之间 120usDMA 响应完全是纳秒级搬运字节就不会丢第二CPU 的中断负担从每 120us 一次变成每 14ms 一次——因为每次突发结束后UART 检测到总线空闲超过一个字符时间会置 IDLE 标志并触发一次 IDLE 中断。这个中断频率只有约 71 次/秒随便什么优先级都不会跟别的外设打架。IDLE 中断里我们只需要读取 DMA 计数器算出这次突发收了多少字节然后把这些字节喂给解析逻辑。CPU 的负担从逐字节伺候变成每帧收一次快递天壤之别。2.4 为什么不用 DMA 半满/全满中断来切帧很多人会问DMA 不是有半传输完成和传输完成两个中断吗能不能用它们来判断一帧数据收完了关键问题是边界不对齐。假设缓冲区开 64 字节半满中断在搬满 32 字节时触发但 SBUS 一帧只有 25 字节帧边界跟 32 字节的半满点没有任何对齐关系。一帧数据可能落在缓冲区的前半段、后半段也可能正好跨过 32 字节分界线。用半满/全满事件去切帧你不得不自己做跨半满点的帧碎片拼装最终还是得写一个按字节顺序处理的状态机而且还要额外处理边界情况。IDLE 中断就不同了——它对应的是串口线上一个突发结束了这天然就是 SBUS 的帧边界语义完全匹配。所以对于 SBUS 这类突发 空闲的协议IDLE 中断是最自然的切帧信号。3. CubeMX 配置与硬件反相电路3.1 一个 NPN 三极管搞定电平反相前面说过 F103 没有信号反相功能硬件反相电路是必须的。完整接线如下SBUS 输出脚 → 10kΩ 电阻 → NPN 三极管基极三极管发射极接 GND集电极接 10kΩ 上拉电阻到 3.3V同时集电极引出接 STM32 的 RX 引脚比如 USART1 的 PA10。焊接和调试的时候注意三点一是基极电阻不要省它是限制基极电流的直接接三极管基极有烧管风险二是上拉电阻必须接 3.3V不能接 5V否则 STM32 引脚承受不住三是如果你买的接收机 SBUS 输出已经是 3.3V 推挽电平同样需要过反相电路不能因为电压够就直连。判断反相电路有没有焊对最直接的方法是用逻辑分析仪量 STM32 的 RX 引脚接收机上电但没发数据时RX 引脚应该是稳定的高电平遥控器动一下摇杆时能看到一串低电平起始的低电平脉冲流。如果 RX 引脚空闲时是低电平说明反相没生效或者三极管接反了。3.2 UART 参数100000、8E2 在 CubeMX 里怎么填CubeMX 里 USART1 配置如下Mode: AsynchronousBaud Rate: 100000Word Length: 9 Bits (including Parity)Parity: EvenStop Bits: 2其他默认再次强调 Word Length 这个坑。CubeMX 界面里当 Parity 选 Even 后Word Length 选项会变成8 Bits (including Parity)和9 Bits (including Parity)两种。SBUS 需要 8 个真实数据位所以必须选 9 Bits (including Parity)。选 8 Bits 的话数据位只有 7 位解出来的通道值全是错位的而且这种错误非常隐蔽——数据看起来有点像但不连续一查一个准。3.3 DMA 配置细节在 CubeMX 的 DMA Settings 里给 USART1_RX 添加一个 DMA 请求Direction: Peripheral To MemoryMode: Circular循环模式Peripheral Increment: DisableMemory Increment: EnablePeripheral Data Width: ByteMemory Data Width: BytePriority: High这里最核心的是 Circular 模式。DMA 在循环模式下会把缓冲区当成环形来用收满 64 字节后自动回绕到缓冲区头部继续写不需要 CPU 干预。配合读取 DMA 计数器的方式我们可以在任意时刻知道缓冲区里从某个位置开始的新数据有多少这就是后面处理循环缓冲的基础。3.4 NVIC 优先级分配CubeMX 里启用 USART1 全局中断。DMA 通道的中断要不要开在循环模式 IDLE 这套方案里DMA 传输完成中断基本用不上但建议把 DMA 的全局中断也打开至少能捕获到 DMA 传输错误比如配置错误导致的 overrun调试期很有用。优先级上USART1 中断要高于普通业务外设因为 IDLE 中断虽然只有 71 次/秒但每次处理需要及时完成。如果你后面接了 FreeRTOS注意中断优先级不能高于可管理的中断优先级否则一些队列操作会出问题。4. 核心代码DMA 循环接收 IDLE 中断的正确姿势4.1 启动接收的完整顺序初始化部分很简单在 CubeMX 生成的代码基础上加两行#define SBUS_BUF_SIZE 64 static uint8_t sbus_dma_buf[SBUS_BUF_SIZE]; void sbus_start(void) { HAL_UART_Receive_DMA(huart1, sbus_dma_buf, SBUS_BUF_SIZE); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); }第二行经常被漏掉。HAL_UART_Receive_DMA 只负责配置 DMA 并启动接收它不会自动使能 IDLE 中断必须手动调 __HAL_UART_ENABLE_IT。漏了这行DMA 照样收数据但永远不会有 IDLE 事件你的解析代码永远不执行表现就是串口好像收了东西但程序毫无反应。DMA 缓冲区大小我推荐 64 字节。一帧 25 字节64 字节能容纳两帧多给解析留足余量。如果接收机开 7ms 高速模式或者协议变长帧可能连续来多帧可以加大到 128、256代价只是几十字节内存无所谓。4.2 USART1_IRQHandler 与 IDLE 处理接下来是最核心的代码——IDLE 中断处理。完整的中断服务函数这样写void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE) __HAL_UART_GET_IT_SOURCE(huart1, UART_IT_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); sbus_handle_idle(); } HAL_UART_IRQHandler(huart1); }sbus_handle_idle是核心逻辑static volatile uint16_t sbus_consume_pos 0; void sbus_handle_idle(void) { uint16_t remain __HAL_DMA_GET_COUNTER(huart1.hdmarx); uint16_t cur SBUS_BUF_SIZE - remain; while (sbus_consume_pos ! cur) { sbus_feed_byte(sbus_dma_buf[sbus_consume_pos]); sbus_consume_pos (sbus_consume_pos 1) % SBUS_BUF_SIZE; } }这十几行代码里藏着两个关键点。第一__HAL_DMA_GET_COUNTER读出 DMA 当前还剩下多少个字节没搬CNDTR 寄存器用缓冲区大小减掉它就是 DMA 已经搬到缓冲区的字节总数。第二因为 DMA 是循环模式这个总数是回绕的所以我们需要一个sbus_consume_pos记录上一次消费到缓冲区的哪个位置。每次 IDLE 事件到达时从sbus_consume_pos到当前位置cur之间的所有字节就是新收到的数据喂给状态机逐个处理。为什么这样做而不是直接清零计数器、从头开始收因为 DMA 循环模式下计数器是硬件自动递减回绕的你清零它并不能让数据从缓冲区头部开始只会把事情搞乱。用消费位置 当前写位置两个指针做环形队列是最稳的。% SBUS_BUF_SIZE的取模运算保证了缓冲区回绕时位置正确。缓冲区开成 2 的幂64、128、256可以直接用 (SBUS_BUF_SIZE - 1)替代取模速度更快。4.3 新旧两条 HAL 路线的差异备忘如果你用的 STM32CubeF1 版本比较新v1.8 之后HAL 提供了HAL_UARTEx_ReceiveToIdle_DMA它把 DMA 接收和 IDLE 中断打包在一起IDLE 事件会回调HAL_UARTEx_RxEventCallbackHAL_UARTEx_ReceiveToIdle_DMA(huart1, sbus_dma_buf, SBUS_BUF_SIZE); void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart-Instance USART1) { /* Size 表示本次事件对应的接收字节数不同 HAL 版本语义有差异务必实测确认 */ } }这个新 API 的确省事但它有个坑不同版本 HAL 里Size参数的语义不一样有的版本传的是从启动 API 到当前的累计接收数有的传的是距上次事件的增量而且累计数在循环模式下还可能跨越 65536 回绕。我自己的建议是如果你只是跑 SBUS 这一类固定小帧协议老老实实用HAL_UART_Receive_DMA 手动 IDLE 处理逻辑完全可控不依赖 HAL 版本行为如果你确实想用新 API务必先在回调里把 Size 的值串口打印出来确认你手里的 HAL 版本到底是哪种语义再继续往下写。还有一点提醒不要在 IDLE 中断里做重活。状态机喂字节本身很快但如果你在中断里直接做浮点运算、printf、刷显示处理时间一旦超过 11ms 的空闲窗口下一帧来了你的中断还没退出就会出问题。正确做法是中断里只做收数据、喂状态机、置标志通道提取和业务使用放到主循环。5. 状态机解析怎么把 25 字节帧从连续字节流中切出来5.1 为什么需要状态机帧边界和 DMA 缓冲区边界不对齐有了 IDLE 中断我们能拿到一次突发的数据但这不等于拿到一帧正好 25 字节的数据。原因有两个第一DMA 缓冲区是环形的一帧 25 字节可能从缓冲区的任意位置开始也可能跨过缓冲区末尾回绕到开头第二系统刚上电时解析器可能正好从一帧的中间开始接收第一次拿到的是一个残缺帧。如果直接依赖缓冲区索引 0 就是帧头代码会很脆弱。状态机的思路是不去管帧和缓冲区的对齐关系只关心字节流的序列。每来一个字节状态机判断它该处于什么状态、该做什么事。这样无论帧从哪里开始、跨不跨缓冲区边界只要字节顺序对状态机就能正确把帧切出来。5.2 状态机定义与实现状态就两个等待帧头、收集数据。#define SBUS_FRAME_LEN 25 #define SBUS_HEADER 0x0F #define SBUS_FOOTER 0x00 static volatile uint8_t sbus_frame[SBUS_FRAME_LEN]; static volatile uint8_t sbus_frame_idx 0; static void sbus_feed_byte(uint8_t byte) { static uint8_t state 0; /* 0: 等待帧头, 1: 收集数据 */ if (state 0) { if (byte SBUS_HEADER) { sbus_frame[0] byte; sbus_frame_idx 1; state 1; } } else { sbus_frame[sbus_frame_idx] byte; if (sbus_frame_idx SBUS_FRAME_LEN) { if (sbus_frame[SBUS_FRAME_LEN - 1] SBUS_FOOTER) { /* 完整合法帧拷贝出来交给主循环 */ for (uint8_t i 0; i SBUS_FRAME_LEN; i) { sbus_rx_frame[i] sbus_frame[i]; } sbus_rx_ready 1; } state 0; sbus_frame_idx 0; } } }注意几个细节。状态机在等待帧头时对每一个不是 0x0F 的字节都直接丢弃直到碰到 0x0F 才开始收集。如果碰到的是残余错误帧里的伪帧头 0x0F它收集完 25 字节后帧尾校验大概率不通过因为字节 24 不是 0x00此时直接回到等待帧头状态重新搜索下一个 0x0F。这就是自同步机制即使中途错了最多错一帧下一帧立刻恢复。帧尾校验非常便宜但价值很大。如果去掉这个校验一个恰好等于 0x0F 的通道数据字节就能让状态机误判产生一整帧垃圾数据。加上帧尾 0x00 校验误判概率大幅下降。如果你想让协议更健壮可以再加一个时间校验记录上一帧完成的时间判断当前帧头与上一帧尾的间隔是否接近 14ms偏差超过阈值就直接丢弃重新同步。这个属于进阶加固基础版不需要。5.3 16 通道数据解包11 位拆包的位运算SBUS 一帧的通道区域是 22 字节里面打包了 16 个 11 位数据。通道 1 从通道区域第 0 位开始通道 2 从第 11 位开始依此类推。拆包的思路是对每个通道 i它的起始位 i × 11起始字节 起始位 / 8字节内偏移 起始位 % 8然后用移位把跨越 2~3 个字节的 11 位数据拼出来。static void sbus_unpack(const uint8_t *frame) { const uint8_t *data frame 1; /* 跳过帧头指向 22 字节通道区域 */ for (uint8_t i 0; i 16; i) { uint16_t bitpos i * 11; uint16_t byteidx bitpos / 8; uint8_t bitoff bitpos % 8; uint32_t v; v data[byteidx] bitoff; v | (uint32_t)data[byteidx 1] (8 - bitoff); v | (uint32_t)data[byteidx 2] (16 - bitoff); sbus_data.ch[i] v 0x07FF; } sbus_data.ch17 frame[23] 0x01; sbus_data.ch18 (frame[23] 1) 0x01; sbus_data.lost_frame (frame[23] 2) 0x01; sbus_data.failsafe (frame[23] 3) 0x01; sbus_data.new_data 1; }这个公式对 bitoff 从 0 到 7 的所有情况都适用。最后用 0x07FF 掩码把 11 位取出来多余的高位全部丢弃。写这段代码时注意两点一是 data[byteidx 2] 的读取在边界情况最后一个通道会读到标志字节但因为掩码把不需要的位都滤掉了结果不受影响前提是你传入的 frame 是完整 25 字节二是不要用浮点运算去除 8 取余直接用整数除法和按位与STM32F103 跑这个 16 次循环大约几个微秒完全可以在主循环里做。5.4 通道范围映射与 Failsafe 处理解出来的裸通道值范围一般在 172 到 1811 之间不同接收机略有差异中值约 992。做飞控时通常需要映射成 1000~2000us 的 PWM 脉宽值#define SBUS_RANGE_MIN 172 #define SBUS_RANGE_MAX 1811 #define SBUS_RANGE_LEN (SBUS_RANGE_MAX - SBUS_RANGE_MIN) uint16_t sbus_ch_to_us(uint16_t raw) { uint32_t us 1000UL (uint32_t)(raw - SBUS_RANGE_MIN) * 1000UL / SBUS_RANGE_LEN; if (us 1000) us 1000; if (us 2000) us 2000; return (uint16_t)us; }映射后的值记得做限幅。有些接收机在遥控器打满舵时会输出超出标称范围的值不限幅的话后面接舵机、接电调都会有风险。Failsafe 处理是 SBUS 的一个重要特性。当遥控器关机或信号丢失时接收机不会停止发送而是持续输出带 failsafe 标志的帧通道值保持最后状态或预设值。所以在业务代码里判断遥控器是否断开不能只看是否还能收到串口数据要看lost_frame和failsafe标志位。我实测下来丢信号后接收机大约 300ms 内就会把 lost_frame 置 1failsafe 跟随其后。飞控系统里这两位的读取频率应该放在控制循环里而不是只在初始化时读一次。6. 实测验证和调试中容易翻车的地方6.1 先解决有没有数据再谈解析对不对我把整个调试过程分成两步这两步的顺序不能反。第一步验证物理层。接收机上电遥控器开机用逻辑分析仪量 STM32 RX 引脚三极管集电极确认空闲高电平、有数据时出现串口波形。再确认波特率用逻辑分析仪解码时选择 100000 baud 8E2应当能解出 0x0F 开头、0x00 结尾的 25 字节帧。如果这一步就乱码先别碰代码回过去查反相电路和 CubeMX 参数。第二步验证解析层。用一个 USART2 作为调试口把原始收到的字节和解析出的通道值打印出来。调试时不要用 SBUS 这根线同时收发SBUS 是接收机单向输出的调试信息走另一路串口。打印频率别太快每帧打印一次就够了否则调试串口本身会占用大量 CPU。6.2 最容易踩的 5 个坑现象根因处理方案全部乱码波特率设成 115200改成 100000通道值错位 / 整体偏移Word Length 选了 8 Bits改成 9 Bits (including Parity)IDLE 中断从不触发漏使能 UART_IT_IDLE启动后调用 __HAL_UART_ENABLE_IT偶发丢帧、首帧总残缺缓冲区太小或解析器从帧中间启动缓冲区 64 起步状态机强制搜索帧头帧尾不匹配导致整帧废弃部分接收机帧尾非 0x00确认接收机输出格式必要时放宽帧尾校验第一个坑最经典。很多人潜意识里觉得串口就是 9600 或 115200SBUS 的 100000 看起来像笔误于是被自动纠正成 115200然后所有数据都变得不可理解。第二个坑前面已经反复强调8E2 的8是数据位但 STM32 HAL 的 Word Length 参数包含校验位必须配 9 位帧才能得到 8 位数据。第四个坑里的首帧残缺属于正常现象状态机设计已经处理了你会在主循环里看到第一个完整可用帧出现在第二次 IDLE 之后不要惊慌。6.3 把同一套 DMAIDLE状态机迁移到其他协议这套架构最大的价值是可复用。DMA 循环接收 IDLE 中断解决的是突发性串口数据如何可靠、高效地收进来这个通用问题状态机解决的是帧边界和缓冲区边界不对齐时如何正确切帧这个通用问题。迁移到其他协议只需要替换状态机里的帧头、帧长和校验逻辑。Modbus RTU 就是个典型例子。Modbus RTU 用 3.5 个字符时间的静默来分隔帧如果波特率 9600一个字符约 1ms3.5 字符约 3.5msF103 的 IDLE 中断默认是 1 个字符时间的空闲检测和 3.5 字符时间不匹配。这种场景就不能直接用 IDLE 切帧要么改用定时器在收到第一个字节后计时超时后判帧结束要么在状态机里自己数字节、按功能码和数据长度收完整帧。所以你发现没有DMAIDLE 这套底层框架完全不用动变的只是上层状态机的内容。另外如果你要做 SBUS 模拟器飞控模拟软件需要接收 SBUS 输入那就用另一个 USART 做发送。发送方向用 DMA 更简单预先在内存里拼好 25 字节帧调用 HAL_UART_Transmit_DMA 发出然后在 HAL_UART_TxCpltCallback 里等下一个发送周期14ms 发一次。SBUS 发送同样需要反相电路注意发送脚也要过三极管反相器才能接到接收机或模拟器设备上。6.4 一点个人经验我从这套方案里最大的体会是串口接收不该是业务代码的负担。把DMA 搬运 IDLE 通知 状态机解析封装成独立的模块后业务代码只需要读取sbus_data.ch[]和几个状态位根本不关心底层是中断还是 DMA。后来我把这套模块从 F103 移植到 F407、G474几乎只改了缓冲区大小和 CubeMX 引脚配置状态机一行没动。最后分享两个调试期的小技巧。第一SD 卡或 Flash 里记录原始字节流遇到疑难问题时回放分析比实时打断点靠谱得多——实时打断点会改变时序很多偶发问题一打断点就复现不出来了。第二状态机里的每个状态转换都加一个只占一位的调试变量跑飞了之后把它打印出来能直接看到字节流停在哪一步比盯着波形猜快得多。
