来源 | 大橙子疯嵌入式
在嵌入式开发的世界里，IAP（In Application Programming，应用内编程） 技术是每个工程师都需要掌握的核心技能之一。与传统的 ISP（In System Programming，系统内编程） 不同，IAP 技术为我们提供了一种更加灵活和实用的固件更新方案。
🔍 技术对比
| 编程方式 | ||
| 典型工具 | ||
| 灵活性 |
OTA（Over The Air Technology，空中下载技术） 则是 IAP 技术的无线升级实现方式，通过蓝牙、WiFi等无线通信方式实现固件的远程更新，大大提升了产品的可维护性和用户体验。
🚀 IAP 技术方案深度解析
在实际产品开发中，IAP 技术的实现远比简单的"两个分区"复杂得多。我们需要考虑：
• ❓ 升级失败怎么办？ • ❓ 如何恢复出厂版本？ • ❓ 如何保证升级的可靠性？ • ❓ 如何优化存储空间使用？
📡 通信协议栈的重要性
开发 IAP 时，通信协议栈（用于接收固件程序）是最基础也是最重要的组件。下面我们来看看几种主流的实现方案：
🎯 一：Bootloader 集成通信协议栈
📋 方案特点
以下方案由 Bootloader 集成通信协议栈，所有编程操作均在 Bootloader 中实现，APP 程序基本不涉及编程操作。
✅ 优点
• 🛡️ 高可靠性：即使没有 APP 程序或 APP 程序异常时也能更新 • 🔧 独立性强：Bootloader 完全独立，不依赖 APP 状态
❌ 缺点
• 📦 占用空间大：Bootloader 相对复杂，Flash 占用空间较大 • 🔄 开发复杂：需要维护两套通信协议
🔄 方案一：直接覆盖式更新
工作流程：
1. 📨 发送升级指令 → MCU 2. 🔄 MCU 复位/跳转 → 进入 Bootloader 3. 🗑️ Bootloader 擦除当前 APP 程序 4. 📥 接收新 APP 程序 → 直接写入 APP 分区
┌─────────────────┬─────────────────┐
│ Bootloader │ APP │
│ Flash │ Flash │
└─────────────────┴─────────────────┘⚠️ 风险提示：升级过程中断电可能导致设备变砖！
🔄 方案二：缓冲式更新
工作流程：
1. 📨 发送升级指令 → MCU 2. 🔄 MCU 复位/跳转 → 进入 Bootloader 3. 📥 接收新 APP 程序 → 写入空白 Flash 4. ✅ 校验成功后 → 擦除旧 APP → 写入新 APP
┌─────────────────┬─────────────────┬─────────────────┐
│ Bootloader │ APP │ 空白Flash │
│ Flash │ Flash │ │
└─────────────────┴─────────────────┴─────────────────┘✅ 优势：升级失败时原程序仍然可用，安全性更高！
🔄 方案三：双APP交替更新
工作流程：
1. 📨 发送升级指令 → MCU 2. 🔄 MCU 复位/跳转 → 进入 Bootloader 3. 📥 接收新 APP 程序 → 写入 APP2 4. ✅ 校验成功后 → 清除 APP1 有效标志 → 设置 APP2 有效标志 5. 🔄 下次更新时 → 擦除 APP1 → 写入新程序到 APP1 → 切换标志
┌─────────────────┬─────────────────┬─────────────────┐
│ Bootloader │ APP1 │ APP2 │
│ Flash │ Flash │ Flash │
└─────────────────┴─────────────────┴─────────────────┘🎯 最佳实践：这是最安全可靠的方案，但需要双倍 Flash 空间！
🎯 二：APP 程序集成通信协议栈
📋 方案特点
以下方案由 APP 集成通信协议栈，编程操作在 Bootloader 和 APP 程序中都有涉及，且至少需要划分三块区域。
✅ 优点
• 💾 空间节省：Bootloader 程序 Flash 占用空间小 • 🚀 开发效率：APP 程序迭代快，功能丰富
❌ 缺点
• ⚠️ 依赖性强：没有 APP 程序时无法实现更新 • 💰 成本较高：Flash 容量需求大 • 🐛 风险较高：APP 程序迭代快，容易出现 bug，影响更新功能
🔄 方案四：APP 接收 + Bootloader 写入
工作流程：
1. 📨 发送升级指令 → MCU 2. 📥 APP 开始接收新程序 → 写入空白 Flash 3. ✅ 校验成功后 → 复位/跳转进入 Bootloader 4. 🗑️ Bootloader 擦除当前 APP 程序 5. 📝 Bootloader 将新程序写入 APP 分区
┌─────────────────┬─────────────────┬─────────────────┐
│ Bootloader │ APP │ 空白Flash │
│ Flash │ Flash │ │
└─────────────────┴─────────────────┴─────────────────┘🤔 为什么不能在 APP 中直接写入？
就像你不能"踩着左右脚上天"一样，程序无法在运行的同时修改自己！
🔄 方案五：APP 完全自主更新
工作流程：
1. 📨 发送升级指令 → MCU 2. 📥 APP 接收新程序 → 写入 APP2 3. ✅ 校验成功后 → 清除 APP1 有效标志 → 设置 APP2 有效标志 4. 🔄 复位后 → Bootloader 根据标志选择启动 APP
┌─────────────────┬─────────────────┬─────────────────┐
│ Bootloader │ APP1 │ APP2 │
│ Flash │ Flash │ Flash │
└─────────────────┴─────────────────┴─────────────────┘💡 特点：只有 APP 涉及编程操作，Bootloader 只负责启动选择！
📊 方案对比总结
🎯 方案选择建议
| 方案一 | ||||
| 方案二 | ||||
| 方案三 | ||||
| 方案四 | ||||
| 方案五 |
⚠️ 重要注意事项
🔧 编译链接问题
方案三 和 方案五 由于程序运行地址不同，需要对 APP 分别进行编译链接，可应用性大打折扣。
📡 OTA 升级特殊考虑
OTA 升级采用无线方式，相比"直接线控升级"：
• 📶 断连风险高：网络不稳定可能导致升级中断 • 🐛 出错概率大：无线传输更容易出现数据错误 • ⏱️ 不适合实时写入：不建议 MCU 每接收一帧数据就立即写入
💡 最佳实践建议
1. 🛡️ 安全第一：优先选择双APP方案（方案三/五） 2. 📦 空间优化：根据产品需求平衡安全性和成本 3. 🔄 容错设计：实现断点续传和校验机制 4. 📊 状态监控：添加升级进度和状态反馈
🎉 结语
IAP/OTA 技术是现代嵌入式产品不可或缺的功能，选择合适的方案需要综合考虑：
• 🎯 产品定位：消费级 vs 工业级 • 💰 成本预算：Flash 容量 vs 功能需求 • 🛡️ 安全要求：可靠性 vs 开发复杂度 • 📱 用户体验：升级成功率 vs 操作便利性
💬 最后：你在项目中用过哪种 IAP 方案？遇到过哪些坑？欢迎在评论区分享你的经验！
