1、课程导论与环境概览：OTA升级概念、升级包类型、环境搭建总览图
各位好，欢迎来到《OTA升级包制作环境搭建指南》的第一章。
我是这门课的主讲。在嵌入式行业摸爬滚打了十几年，我经手过的设备从几块钱的MCU到几万块的工控主板都有。OTA升级这事儿，说白了就是让设备能“自己给自己治病”。
你想想看，产品卖出去了，发现有个bug，或者想加个新功能，难道还让用户寄回来？或者派工程师拎着烧录器上门？那成本可就太高了。OTA就是通过网络，把修复包或者新功能包，像手机系统更新一样，直接推送到设备上。
1.1 什么是OTA升级？
OTA，全称Over-the-Air，空中下载技术。它不是一个单一的技术，而是一套完整的工程体系。
我个人习惯把OTA拆成三个核心动作：
- 打包：把新的固件、文件系统、配置参数，按照特定格式封装成一个“升级包”。
- 传输：通过HTTP、MQTT、CoAP等协议，把这个包从云端服务器安全地送到设备本地存储。
- 执行：设备在本地校验包的完整性，然后引导加载程序（Bootloader）把新固件写入指定分区，最后重启生效。
我在项目中遇到过最头疼的情况，就是升级包传输到一半网络断了，设备变砖。所以，后面我们会花大量篇幅讲“断点续传”和“安全校验”，这些都是血的教训换来的经验。
1.2 升级包的主要类型
不是所有升级都用同一种包。选哪种，取决于你的硬件资源、网络带宽和升级场景。我整理了一个表格，方便你对比：
| 类型 | 核心原理 | 包体大小 | 适用场景 | 风险等级 |
|---|---|---|---|---|
| 全量镜像包 | 整个固件镜像（如.bin文件）整体替换 | 大（几MB~几百MB） | 首次烧录、重大版本升级 | 低（结构简单） |
| 差分增量包 | 只包含新旧版本之间的差异部分（bsdiff/hdiff算法） | 小（几KB~几MB） | 带宽受限、频繁小版本迭代 | 中（依赖基准版本） |
| 压缩流式包 | 边下载边解压写入，不占用额外存储空间 | 中等（压缩后大小） | Flash空间紧张的MCU设备 | 高（写入失败恢复困难） |
| 多分区组合包 | 同时包含bootloader、kernel、rootfs、app等多个分区镜像 | 大（组合后） | 系统级OTA（如Linux设备） | 中（需协调分区顺序） |
我的建议： 如果你的设备Flash大于32MB，且网络条件好，优先用全量包，简单可靠。如果设备只有2MB Flash，那必须上差分包。我曾经在一个仅有1MB Flash的Wi-Fi模组上做OTA，差分包从500KB压到80KB，才勉强塞进去。
1.3 环境搭建总览图
做OTA升级包，不是装一个软件就完事了。它需要一个完整的工具链环境。下面这张图，是我自己梳理的“OTA升级包制作环境”核心架构。你看一眼，心里就有谱了。
这张图展示了从“输入”到“输出”再到“验证部署”的完整链路。你不需要现在就记住所有细节，但请记住这个核心逻辑：输入 -> 加工 -> 输出 -> 验证。我们这门课，就是围绕这个链路，把每一环的工具和环境都搭起来。
1.4 你需要准备什么？
在开始动手之前，我建议你先检查一下自己的“工具箱”。下面这几样东西，是必须的：
- 一台Linux主机（Ubuntu 20.04/22.04 或 CentOS 7+）。Windows用户可以用WSL2或者虚拟机。我个人强烈推荐Ubuntu 22.04，包管理最省心。
- 基本的C/C++编译环境（gcc、g++、make、cmake）。后面编译差分工具和签名工具会用到。
- Python 3.8+。很多打包脚本和自动化工具都是用Python写的。
- Git。版本管理，不用多说。
- 至少20GB的空闲磁盘空间。别小看这个，编译工具链、下载SDK、存放固件，空间很快就吃掉了。
注意： 千万不要在生产环境的服务器上直接搭建这个环境。我曾经有个同事，直接在线上打包服务器上做实验，结果把生产环境的Python版本搞坏了，导致整个CI/CD流水线停了半天。请务必在独立的开发机或虚拟机上操作。
1.5 本章小结
这一章我们聊了OTA升级的本质，就是“远程治病”。也看了四种常见的升级包类型，各有各的脾气。最后那张总览图，是整个课程的骨架。