1. OTA升级概述：无线MCU为什么需要OTA？
大家好，我是你们的老朋友。今天咱们聊聊OTA升级。
先问个问题：你手里的智能设备，出厂后还能改功能吗？
传统MCU开发，程序烧进去就焊死了。想改？要么拆机接烧录器，要么把产品召回来。这在消费电子、物联网场景里，基本等于自杀。
OTA（Over-The-Air）升级，说白了就是让设备通过无线网络自己更新固件。不用拆机，不用连线，甚至用户都感知不到。
1.1 为什么无线MCU必须支持OTA？
我做过一个智能门锁项目，出货两万台。三个月后，发现蓝牙配对协议有个兼容性bug。如果没有OTA，这两万把锁得全部拆下来返厂——成本够再开一条产线了。
具体来说，OTA解决了几个痛点：
- 远程修复：安全漏洞、协议兼容性问题，云端一键下发补丁。
- 功能迭代：产品上市后还能加新功能，比如增加一种传感器算法。
- 降低运维成本：不用派工程师上门，不用发顺丰到付。
- 提升用户体验：用户无感升级，设备越用越“聪明”。
1.2 OTA升级的三种典型架构
我这些年接触过的OTA方案，基本可以归为三类。每种都有它的脾气。
| 架构类型 | 核心特点 | 适用场景 | 典型代表 |
|---|---|---|---|
| 云端架构 | 固件包存储在云服务器，设备直连下载 | Wi-Fi、蜂窝网络设备，带宽充足 | AWS IoT OTA、阿里云OTA |
| 本地架构 | 通过本地网关、手机App或U盘中转 | 蓝牙Mesh、Zigbee、低功耗设备 | 手机App推送、网关代理升级 |
| 混合架构 | 云端+本地协同，分级下发 | 大规模分布式系统，多协议并存 | 智能家居全屋方案 |
1.2.1 云端架构
这是最直接的方案。设备直接连接云服务器，下载固件包，校验，写入。
优点很明显：架构简单，部署快，版本管理方便。但缺点也致命——设备必须保持在线，而且对Flash和RAM要求高。我见过一个项目，用ESP32做OTA，固件包1.2MB，下载到一半Wi-Fi断了，设备直接变砖。后来加了断点续传和双区备份才搞定。
1.2.2 本地架构
本地架构，说白了就是找个“中间人”帮忙传固件。这个中间人可以是手机App、本地网关，甚至是一台笔记本电脑。
举个例子：你做一个蓝牙温湿度传感器，电池供电，功耗极低。它不可能一直连着Wi-Fi。那怎么升级？通过手机App连接传感器，把固件分包发过去，传感器收到后校验、写入、重启。
这种架构的好处是：设备不需要一直在线，功耗低，成本也低。但坏处是：升级速度慢，而且依赖中间设备。我曾经帮客户调试一个Zigbee网关升级，网关从云端下载固件，再分发给子设备。结果子设备有30多个，一个一个发，发了整整两个小时。
1.2.3 混合架构
混合架构，是我个人比较推荐的一种。它把云端和本地的优势结合起来。
典型流程是这样的：
- 云端存储固件包，管理版本和升级策略。
- 本地网关（或边缘节点）从云端拉取固件。
- 网关通过本地协议（蓝牙、Zigbee、Z-Wave）分发给子设备。
- 子设备升级完成后，上报状态给网关，网关再同步到云端。
这样做的好处是：子设备不用直接连外网，功耗低；网关负责重试和校验，可靠性高；云端统一管理，运维方便。
1.3 三种架构的对比总结
我整理了一张表，方便你快速对比：
| 维度 | 云端架构 | 本地架构 | 混合架构 |
|---|---|---|---|
| 网络依赖 | 高（设备直连云） | 低（依赖本地链路） | 中（网关连云，子设备连网关） |
| 升级速度 | 快（带宽大） | 慢（低功耗短距协议） | 中（取决于网关策略） |
| 设备功耗 | 高（需长时间射频工作） | 低（可分段休眠） | 低（子设备只需短距通信） |
| 可靠性 | 中（断网风险） | 高（本地重试机制） | 高（网关可做缓冲和校验） |
| 运维复杂度 | 低（云端统一管理） | 高（需维护中间设备） | 中（需协调云端和本地） |
| 典型成本 | 云服务费用高 | 硬件成本低 | 网关硬件+云服务 |
1.4 架构选型建议
选哪种架构，其实没有标准答案。我一般会问自己三个问题：
- 设备连什么网？ Wi-Fi/蜂窝 → 云端架构；蓝牙/Zigbee → 本地或混合。
- 设备功耗要求多严？ 电池供电且希望用一年以上 → 本地或混合；插电设备 → 云端。
- 设备数量多少？ 几十个 → 本地架构够用；成千上万 → 必须上混合架构。
1.5 本章知识结构图
下面这张图，帮你理清三种架构的关系和适用边界：