Bootloader 实战 (2)：可靠传输 —— 抛弃 YMODEM，手写一个抗干扰的私有 OTA 协议

第一篇我们搞定了“怎么跳过去”，这一篇我们要解决“怎么传过来”。

很多初学者写 Bootloader 喜欢偷懒，直接移植一个 YMODEM 协议。但真到了做产品时你会发现：YMODEM 简直是“温室里的花朵”。它假设信道是连续的、可靠的，一旦遇到蓝牙（BLE）分包、RS485 总线冲突，或者波特率稍微有点误差，升级过程就会极其痛苦，经常卡在 99% 失败。

这一篇，我们要带读者从零设计一个“私有 OTA 协议”，并教会他们用**状态机（FSM）**来解析数据。这是嵌入式软件工程中最显功力的地方。

Bootloader 实战 (2)：可靠传输 —— 抛弃 YMODEM，手写一个抗干扰的私有 OTA 协议

前言 很多人问：为什么不用标准的 YMODEM 或 XMODEM？ 因为标准协议是为 80 年代的电话线设计的。在现代物联网场景下（特别是 BLE、LoRa 或复杂的 RS485 总线），我们需要一个更轻量、更灵活、能容忍“断断续续”传输的协议。 今天，我们不谈虚的理论，直接设计一个基于状态机、带校验、支持断点续传的工业级私有协议。

一、 为什么我们要“造轮子”？

在动手写代码前，先看清痛点：

1. 被动的超时机制： YMODEM 极其依赖超时判断（比如 1秒收不到数据算超时）。但在 BLE 环境下，一包数据可能就要传 200ms，很容易误判。

2. 死板的帧长： 标准协议通常固定 128 或 1024 字节一包。但如果你的 Flash 扇区是 2KB，或者蓝牙 MTU 只有 20 字节，这种不匹配会导致极其复杂的缓存管理。

3. 缺乏业务指令： 标准协议只能传文件。但实际 OTA 中，我们往往需要：“查询版本号”、“擦除指定区域”、“重启设备”等指令。

结论： 一个优秀的 OTA 协议，必须是**“指令驱动”**的，而不是单纯的“数据流”。

二、 协议帧设计：越简单越好

不要搞复杂的 XML 或 JSON，MCU 只有几 KB 内存，二进制帧才是王道。

我们可以定义一个变长的数据帧结构：

typedef struct {
    uint8_t  head[2];   // 帧头：固定 0xAA 0x55，用于同步
    uint8_t  len;       // 长度：Payload 的长度
    uint8_t  cmd;       // 指令：如 0x01=擦除, 0x02=写入, 0x03=校验
    uint8_t  payload[256]; // 数据载荷