OTA (Over-The-Air update) 顾名思义就是空中升级, 在无线产品中非常常见, 我们可以借助 OTA 功能远程对设备或产品进行固件更新, 而不需要我们去现场进行维护, 这里我们不具体讲 OTA 的好处, 我们只谈 OTA 实现.
结合笔者经验总结, 本文归纳了四种 OTA 实现方式, 接下来我们具体介绍.
方式一
不用对 OTA 进行分区, 不需要 Bootloader, 直接在运行代码的时候进行 Flash 擦除写入操作, 对于这种方式, 芯片需要支持 IAP 功能, 或者代码放在 RAM 中运行, 否则代码运行时没办法擦除自身的Flash. 这种方式的好处是省空间, 实现简单, 但坏处显而易见, 如果 OTA 过程中断电或者写入数据异常, 则没办法恢复, 一出错整个系统就挂掉了. 要想恢复只能通过手动操作重新写入 Flash.
方式二
引入分区概念, 首先是 Bootloader 分区, 可以用来跳转到指定分区运行, OTA 分区用来存放实现 OTA 功能的代码, 此分区可以固定使用, 代码不需要更新. APP 分区用来存放应用代码. 这种方式 OTA 实现流程如图1所示: 代码正常跑在 APP 分区中, 当接收到 OTA 指令后,修改启动标志,让 Bootloader 跳转到 OTA 分区, 在 OTA 分区中接收数据, 并更新 APP 分区内容, 更新完之后, 再把启动标志修改回来, 让Bootloader 跳转到 APP 跑正常的应用代码, 这样就完成的 OTA 升级, 这里面我们省略了校验等过程, 实际产品中是一定需要的.
这种方式的好处是, OTA 过程比较可靠, 即使 OTA 失败还可以再次 OTA 更新, 因为 OTA 的代码一直是有效的, 不会被改写.另外, OTA 分区代码相对 APP 分区代码来说会比较小, 因为只实现了 OTA 这一个功能, APP 分区代码功能相对来说会复杂些, 占用空间也较大.
图1 图2 图3
方式三
与第二种方式类似, 同样分三个区, 但 APP 与 OTA_APP 分区大小一样, 这里的 OTA_APP 分区存放的是实际的应用代码, 与 APP 区域是对等的, 是用来存放 OTA 接收到的新 APP. 实现流程如图2所示: 代码正常运行在 APP 分区, APP 分区含有 OTA 功能代码, 在接收到 OTA 数据时, 直接把 OTA 数据写到 OTA_APP 中, 完成后,重启系统, 在 Bootloader 中把 OTA_APP 搬到 APP 分区, 这样就实现了 OTA 升级功能, 接着还是在 APP 分区启动, 当然这里面也要去校验数据的完整性.
方式四
同上面两种方式类似,也是基于三个分区, 但 APP 区分成两个 APP1 和 APP2, 这两个区域都是存放可正常运行的代码, bootloader 可以跳转到 APP1 运行, 也可以跳转到 APP2 去运行, 两个分区交替使用, 如图3所示. 如果现在跑在 APP1 中,那下次 OTA 后系统就跑在 APP2 中, 再下次 OTA 后跑在 APP1 中, 这样 APP1-APP2-APP1-APP2-APP1 循环. 举个例子, APP1 和 APP2 分别存放的 v1.0, v1.1 版本固件, 如果系统软件现在跑在 APP2 中, 固件要升级到 v1.3, 那只需要通过 OTA 功能去改写 APP1 的数据(即把原来的 v1.0 用 v1.3 擦除覆盖), 这样 OTA 之后, APP1 存放的是 v1.3, APP2 没变,还是 v1.2, 但这个时候需要把启动选项修改为 APP1. 同样的, 现在 APP1是 v1.3, APP2 是 v1.2, 系统跑在 APP1 中, 我现在要 OTA v1.4 版本, 我只要把 OTA 数据直接写到 APP2 中, 再修改启动项为 APP2 即可, 实现流程如图3所示. 这种方式的好处是可靠性高,不会担心 OTA 不成功会影响用户使用, 至少有一个分区是可用的, 但缺点是难于维护, 在开发阶段你要同时维护两套代码(因为 APP1 和 APP2 存放的位置不一样,需要不同的偏移地址, 需要修改 link 文件才能完成, 所以有两套代码.)
以上四种方式我们分别从三个方面作一下对比:
总结
OTA 功能不难实现, 但要把 OTA 功能做稳定, 不会宕机, 需要考虑很多细节的问题, 如突然断电,数据错误或者不完整等等. 从对比表格中看到方式一是最简单最易于实现的, 但可靠性最低, 做产品最优先的是要保证可靠性, 所以我们一般会选用二, 三, 四这三种方式, 如果结合维护性, 二, 三是最适合的, 这也是我们最常用的两种 OTA 方式.
评论