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”,一个为大家打造的技术知识提升基地,您的"点赞""转发"都是对我最大的支持。
推荐好文 点击蓝色字体即可跳转