2. 固件版本管理：版本号的定义、语义化版本、版本存储区域设计
版本管理这事儿，看着简单，其实坑不少。我见过太多团队在版本号上栽跟头——要么升级时版本判断出错，要么回滚时找不到正确的固件。说白了，版本号就是固件的身份证，搞不清楚这个，后面的回滚保护全是空谈。
2.1 版本号的定义与结构
版本号不是随便写个数字就完事的。它要承载几个关键信息：
- 唯一性：每个固件版本必须有唯一的标识
- 可比较：能判断哪个版本更新、哪个更旧
- 可追溯：通过版本号能关联到具体的发布信息
我个人习惯把版本号拆成两部分：内部版本号和展示版本号。内部版本号给系统用，展示版本号给人看。
内部版本号（推荐格式）
// 32位无符号整数，按位划分
// Bit 31-24: 主版本 (Major)
// Bit 23-16: 次版本 (Minor)
// Bit 15-8: 补丁版本 (Patch)
// Bit 7-0: 构建号 (Build)
#define VERSION_MAJOR(x) (((x) >> 24) & 0xFF)
#define VERSION_MINOR(x) (((x) >> 16) & 0xFF)
#define VERSION_PATCH(x) (((x) >> 8) & 0xFF)
#define VERSION_BUILD(x) ((x) & 0xFF)
// 示例：0x01020003 → v1.2.0-build3
uint32_t fw_version = 0x01020003;为什么用32位整数？因为比较起来快啊！一个减法就知道谁新谁旧。我在一个物联网项目里见过有人用字符串存版本号，结果每次比较都要做字符串解析，升级流程硬生生慢了200毫秒。
2.2 语义化版本（SemVer）
语义化版本，说白了就是给版本号定个规矩。格式是 MAJOR.MINOR.PATCH：
| 字段 | 含义 | 什么时候增加 |
|---|---|---|
| MAJOR | 主版本号 | 不兼容的API变更、存储格式变化、安全机制升级 |
| MINOR | 次版本号 | 新增功能，但向后兼容 |
| PATCH | 补丁版本号 | Bug修复、性能优化，无功能变化 |
但在嵌入式固件里，我建议再加一个字段——硬件兼容性标识。你想想看，同一个固件可能跑在不同硬件版本上，搞混了可就麻烦了。
我的经验：在版本号中嵌入硬件兼容性掩码。比如高8位表示支持的硬件版本，低24位表示固件版本。这样升级时先检查硬件兼容性，不匹配直接拒绝升级，省得变砖。
2.3 版本存储区域设计
版本信息存哪儿？这是个大学问。我见过有人把版本号写在代码里，每次升级都要重新编译——这哪行啊！
正确的做法是：版本信息必须存储在非易失性存储器中，并且要独立于固件镜像。
我推荐的设计方案是这样的：
// 版本信息结构体
typedef struct {
uint32_t magic; // 魔数，用于校验有效性（0xA5A5A5A5）
uint32_t version; // 当前固件版本号
uint32_t compatible_hw; // 兼容的硬件版本掩码
uint32_t build_time; // 构建时间戳
uint16_t crc16; // 结构体CRC校验
uint8_t reserved[14]; // 保留字段，用于扩展
} __attribute__((packed)) version_info_t;存储区域划分建议：
| 区域 | 地址范围 | 大小 | 存储内容 |
|---|---|---|---|
| Bootloader区 | 0x0000 - 0x3FFF | 16KB | 启动加载器 + 版本信息副本 |
| 版本信息区 | 0x4000 - 0x40FF | 256B | 当前固件版本、回滚版本、硬件兼容性 |
| 固件Slot A | 0x4100 - 0x7FFF | 16KB | 主固件镜像A |
| 固件Slot B | 0x8000 - 0xBFFF | 16KB | 备份固件镜像B |
| 配置参数区 | 0xC000 - 0xFFFF | 16KB | 用户配置、校准数据 |
注意：版本信息区必须使用双备份机制。我曾经在一个项目中只存了一份版本信息，结果写入时突然掉电，版本号变成了0xFFFFFFFF，系统直接认为固件损坏，拒绝启动。后来我改成写两份，读的时候取两份的交集，再也没出过问题。
2.4 版本管理的核心流程
嗯，这里要画个图，把整个版本管理的逻辑串起来。
2.5 版本升级的兼容性检查
升级时不能只看版本号大小。我总结了一套检查规则：
- 硬件兼容性检查：新固件是否支持当前硬件版本
- 主版本号检查：主版本不同，必须走完整升级流程（不能增量升级）
- 次版本号检查：次版本不同，允许增量升级，但要检查配置兼容性
- 补丁版本号检查：补丁版本不同，直接覆盖升级即可
- 回滚版本检查：新版本必须高于当前版本，否则拒绝升级
避坑指南：我曾经遇到过一个案例，某设备从v2.0.0升级到v2.1.0后，发现新功能依赖的硬件外设不存在。原因是v2.1.0只支持硬件版本B，而设备是硬件版本A。从那以后，我在版本信息里强制加入了硬件兼容性掩码，升级前必须做匹配检查。
2.6 版本信息的读写保护
版本信息区是固件升级的命门，必须做好保护：
| 保护措施 | 实现方式 | 作用 |
|---|---|---|
| CRC校验 | 每次写入时计算CRC16，读取时校验 | 检测数据损坏 |
| 双备份 | 主区和备份区各存一份 | 防止写入中断导致数据丢失 |
| 写保护 | Bootloader中设置Flash写保护 | 防止应用层误写 |
| 版本回滚计数器 | 记录回滚次数，限制最大回滚次数 | 防止无限回滚攻击 |
嗯，版本管理这块儿，说白了就是要把规则定清楚，把存储设计好。你想想看，如果版本号都搞不清楚，后面的回滚保护机制根本无从谈起。我见过太多项目，前期版本管理一团糟，后期升级回滚时各种踩坑。
记住一句话：版本号是固件的身份证，版本存储区是固件的保险柜。这两样搞扎实了，后面的回滚保护才能站得住脚。