【MCU】一种"灵活且省资源"的IAP升级方案

1、聊一聊

     每当你疲惫的时候听一下这首歌曲，或许会重新振奋，其实我们每个人都是"一名soldier"。

2、正文部分

1

前言 

    IAP升级功能对于一款以MCU为核心的成熟嵌入式产品算是标配吧，采用烧录接口通过烧录盒进行固件写入算是最方便的办法，而且还具备调试功能确实省心，完全不用太担心变“砖头”。

    但是如果你的产品位于山顶，水底，国外等等，又或者在一个非常难拆的盒子里面，你还会选择插入烧录盒写入吗?想想都觉得头皮发麻，那么一个安全稳定的IAP在线升级功能就变得尤为重要了。

    bug菌很久以前也有写过一些IAP的文章，大家可以在号内搜索，其中这篇是值得一看的 :

    今天主要是跟大家分享一种灵活且省资源的IAP处理方案。

2

双boot方案的缺点

    下图是前面链接文章IAP_V3.0的结构体示意图：

    从图中可以看到该方案中瓜分出两部分Flash分别用于boot1和boot2，内部Flash对于MCU是非常宝贵的资源，在MCU内部指令预取等的优化下，程序在Flash上运行程序效率是较高的，所以boot占据太大的Flash确实有点浪费。

    同时一旦我们的程序由boot跳转到APP，这就意味着boot的生命周期暂时结束，那么boot所占据的Flash也就没办法得到利用了，所以我们采用一种更为优化的方案来进行IAP升级。

3

灵活且省资源的IAP

    其实对于资源的节省无非就是时间换空间、空间慌时间等等之类的，而在整个过程中，boot使用的RAM与APP使用的RAM是分时复用的，一般RAM的大小相对FLash偏小，所以直接加载APP不是特别合适，但是加载boot却是绰绰有余，于是就有了如下设计:

解析一下：

• 1 ) 该方案通过外部加载相对较复杂的boot2到RAM中运行，从而可以大大节省Flash，那么boot1的功能相对就比较简单，当APP完整且不需要进行升级的时候，直接从boot1跳转到APP执行即可。

• 2 ) 而当需要进行App更新，那么就需要从外界加载boot2升级控件包，boot1加载boot2的方式有多种，可以通过简单的通信协议接收数据然后写入到RAM，或者是通过驱动外部存储获得boot2.bin加载到RAM，最后在RAM中直接运行boot2。

• 3 ) boot2相对boot1更加复杂，其可以支持多种协议、多种方式升级和处理， boot2通过更加复杂的协议甚至加密、解密后得到App数据，然后进行Flash的擦写，完成以后跳转执行新的App程序，当跳转到App其RAM重新复位且接管整个RAM，boot2消失，运行App程序。

• 4）所以这里通过每次升级加载boot2，利用时间换空间充分利用程序在RAM中运行来更加灵活的升级应用程序。
  

3、结束语

    这里bug菌就把今天的IAP升级方案介绍完了，做开发其实主要是思路清晰，相关的技术细节都可以通过各种途径获取到。

    好了，这里是公众号:“最后一个bug”，一个为大家打造的技术知识提升基地，您的"点赞""转发"都是对我最大的支持。

推荐好文  点击蓝色字体即可跳转