构建前后兼容且可扩展的OTA升级包
- 背景
- 已有打包方案
- 格式
- 不足
- 引入新方案
- 格式
- 新方案面临的问题
- 设备配套情况
- 云端设备情况
- 如何解决上述问题
背景
原有OTA固件打包方案是固定的，仅能打包三个固件，没有考虑其扩展功能。
由于市场缺货，需要新增加一个其他厂家的MCU来替换缺货的MCU，故市面上的产品OTA升级需要支持当前两种不同的MCU硬件的情况。
已有打包方案
格式
不足
- 仅有总版本号，没有各个固件包的分版本号；
- sign值设置不合理，识别包的类型较为麻烦；
- 没有考虑到各个固件是智能升级（OTA的版本新于当前版本就升级），还是全部升级的模式；
- 仅能支持三个固件，没有为后期的固件包预留位置。(因为data_content的大小，在解析时被写死成了3个，导致无法解析)
- 没有留扩展位。
引入新方案
针对旧方案的不足，优化OTA打包方案。
格式
说明：根据升级时用到的固件情况，可以提前预留当前固件个总数的3倍即可。
新方案面临的问题
设备配套情况
基站+一个或多个CAM
云端设备情况
OTA包是放到云端上的，用户手中的设备版本各种各样, 会面临多种复杂的情况。
- 情况1：旧基站+旧CAM，新的OTA固件包
? 对老设备，要能升级新包。--->OTA包要做成兼容旧包，并能正确解析升级。
- 情况2：旧基站+新CAM，新的OTA固件包
? 对于新设备CAM，要有区分自己固件的能力，以防升级成砖。
-
情况3：新基站+旧CAM
? 新版的基站要有识别CAM端硬件配置的能力，并能进行相应升级。
-
情况4：新基站+新CAM
? 新版的基站要有识别CAM端硬件配置的能力，并能进行相应升级。
以上问题总结如下：
-
新的OTA包支持老版的解析方式；
-
新版MCU的升级接口具有能识别要升级文件的能力；
-
CAM具有向基站上报自身硬件信息的能力；
-
基站要能依据CAM的上报信息，选择相应固件包进行升级。
如何解决上述问题
从上面的问题可以看出，这不是一个简单的OTA打包解包的问题，还有本地升级策略的问题。
针对问题1，我采用得是两种打包方式同时使用，原有的固件使用旧打包程序，新的固件采用新的打包方式。然后将打好的两个包合并成一个包，旧的在先，新的在后。这样就能支持旧基站的解包方式了。
由于对固包进行了扩展，新版基站的OTA解包程序在旧的解包方式上增加一下判断，分辨一下当前的包是原始版本，还是新版本。判断方法也很简单，就是看实际文件大小比较旧包里的计算出来的数据大小，若实际文件大小大于计算值，说明是增加了扩展包，否则就是老版本。
针对问题2，这个要求在OTA设计时，要提前考虑到。
针对问题3，上报硬件信息要提前设计。
针对问题4，设备在进行本地升级时，要加入辨识硬件信息的判断，而且要版本智能升级与全部强制升级的能力。