1. OTA 概述与演进：从刷机到 FOTA

大家好，我是你们这门课的老朋友。做嵌入式系统有些年头了，OTA 升级这块，我踩过的坑可能比你们吃过的盐还多（笑）。今天咱们先不急着写代码，把 OTA 的来龙去脉捋清楚。

说白了，OTA 就是「Over-The-Air」——空中下载技术。但你别小看这四个字母。十年前，给设备升级固件，你得拿着烧录器，一根线一根线地接。现在呢？点个按钮，全球的设备都能自动更新。这背后，是整整一代工程师的血泪史。

1.1 从刷机到 FOTA：一部「偷懒」史

我刚开始做嵌入式那会儿，升级固件全靠 JTAG 或者串口。每次升级，都得把设备拆开，接上烧录器，等上十几分钟。要是产品卖出去几万台，你就得派人去现场一台台刷。那场面，想想都头大。

后来有了 SOTA（Software Over-The-Air），算是迈出了第一步。但早期的 SOTA 其实很原始——设备连上服务器，把整个固件包下载下来，然后自己写进 Flash。说白了，就是把「用线刷」变成了「用网刷」，本质没变。

真正的转折点是 FOTA（Firmware Over-The-Air） 的出现。FOTA 不只是下载，它还能管理升级流程、校验完整性、处理失败回滚。我记得 2015 年做车机项目时，第一次用 FOTA 方案，老板问我：「万一升级到一半断电了怎么办？」我说：「FOTA 有恢复机制。」他半信半疑。后来真有一台测试车在升级时被拔了电瓶，重启后自动回滚到旧版本，他才彻底放心。

1.2 主流 OTA 方案对比：全量、增量、AB 系统

做 OTA 方案选型时，我经常被问到：「哪种方案最好？」我的回答永远是——看场景。没有银弹。

下面这张表，是我这些年做项目总结出来的，建议你收藏。

方案	原理	升级包大小	存储开销	失败恢复	典型场景
全量升级	下载完整固件，覆盖写入	大（整个固件）	低（只需一个分区）	差（变砖风险高）	MCU、小内存设备
增量升级	只下载差异部分，合并写入	小（通常 10%~30%）	低（需临时存储差分包）	中（合并失败可重试）	物联网、带宽受限场景
AB 系统升级	双分区轮流启动，后台升级	大（整个固件）	高（需双倍存储）	强（无缝回滚）	车机、手机、高端 IoT

1.3 全量升级：简单粗暴，但别滥用

全量升级是最原始的方式。设备把整个固件包下载下来，然后擦除旧分区，写入新固件。

优点很明显：

• 实现简单，逻辑清晰
• 不需要差分算法，兼容性好
• 适合资源受限的 MCU

缺点也很致命：

• 升级包大，下载慢，流量贵
• 升级过程中一旦断电或通信中断，设备直接变砖
• 没有回滚能力

1.4 增量升级：省流量，但别小看差分算法

增量升级的核心是差分算法——比较新旧固件，只生成差异部分。设备下载差分包后，在本地合并成完整固件再写入。

常用的差分算法有：

• bsdiff：压缩率高，但内存消耗大
• hdiffpatch：平衡了压缩率和性能
• xdelta：轻量级，适合 MCU

我个人的习惯是：如果设备内存大于 512KB，优先用 bsdiff；如果内存紧张，用 xdelta 更稳妥。

1.5 AB 系统升级：最安全，但最「贵」

AB 系统升级，也叫无缝升级。设备有两个系统分区（A 和 B），当前运行在 A 分区。升级时，后台把新固件写入 B 分区，写完后标记 B 为「可启动」。下次重启时，从 B 分区启动。如果 B 启动失败，自动回滚到 A。

为什么说它最安全？因为升级过程中，当前系统一直在正常运行。用户完全无感知。

代价也很明显：

• 存储空间翻倍（两个分区）
• 实现复杂度高（需要处理分区切换、启动计数、回滚策略）
• 对硬件有要求（Flash 容量要够大）

我做车机项目时，用的就是 AB 系统。车规级要求升级失败率低于 0.01%，AB 系统是唯一能满足的方案。

1.6 一张图看懂 OTA 技术演进

下面这张 SVG 图，是我梳理的 OTA 技术演进路线。你可以看到，从手动刷机到 AB 系统，每一步都是为了解决前一步的痛点。

1.7 如何选择？我的经验法则

你可能会问：「那我到底该用哪种？」我一般按下面这个思路来选：

1. 看 Flash 容量：如果剩余空间不足固件大小的 1.5 倍，别想 AB 系统，老老实实用全量或增量。
2. 看升级频率：每月升级一次以上，优先考虑增量，省流量就是省钱。
3. 看安全等级：车规、医疗、工业控制，必须上 AB 系统。消费电子，全量 + 恢复模式就够了。
4. 看网络环境：2G/3G 弱网环境，增量升级是唯一选择。WiFi 环境，全量升级也没问题。