OTA学习教程

0.序言一方面我在写带wifi模块的项目时就打算实现ota已经实现了分区但是还没有具体实操所以一方面打算学习ota另一方面。这次选用了超子的物联网开发板使用的国产GD32熟悉这个新的芯片并完成OTAOTA的用途有很多下载方式也有不同后面会根据项目实际心得进行更新1.OTA简介与分类一篇参考的优质博客 常见的OTA升级方案总结1.1简介OTA的全称是​​Over-the-Air Technology​​空中下载技术其本质是通过无线通信网络实现设备软件件的远程更新。根据升级对象的不同OTA可分为两大类型。一个完整的OTA系统包含​​“云-管-端”三层架构​​1.云端服务器存储更新包执行版本管理、数字签名加密等操作。2.通信管道通过4G/5G、Wi-Fi等网络传输数据需考虑断点续传、流量压缩技术。3.终端设备包含BootLoader引导程序、应用程序分区、备份区等核心模块这里云端可以使用现成免费的平台对于安全传输需要涉及AES数字签名来保证安全传输CRC保证数据完整无误1.2 OTA类型1.2.1 检查升级进入面板这里不会主动提示用户需要升级新的固件只有用户点到设备详情中的检查固件升级才会弹框提醒。1.2.2 提醒升级进入面板app主动检测一次升级若有新版本固件则弹窗提示升级用户可以选择升级也可以点取消关闭弹框正常通过面板操作设备。1.2.3 强制升级进入面板app主动检测一次升级若当前设备固件有新版本则弹框覆盖点击确定进入升级若点取消则会返回即不升级无法在当前面板操作此设备。1.2.4 静默升级不通过app设备正常情况下本身与云端保持长连接会轮循检查是否有新的设备强制升级的固件。如果有设备强制升级的固件设备就会直接去升级这里不需要app端。1.3 OTA升级方式首先介绍下芯片的flash分区。如图起始地址一般存放bootload其它空间有的存储业务数据有的存储系统数据等我们的固件存放在APP应用区。下面就是常见的分区OTA的升级分类方式有很多种可以根据分区划分还可以根据升级范围划分下面是我自己理解的分类当然这包括了常见的所以方式1.3.1 乒乓升级两个大小相同的分区APP1、APP2如果当前在APP1分区执行代码升级时就把固件下载到APP2分区。升级成功后设备重启模组切换到APP2分区执行下次再升级就切换到APP1分区一直这样轮询。1.传统乒乓升级优点升级时不影响当前运行的 APP失败后可回滚到另一分区可靠性高。缺点需要维护两套完全独立的 APP 工程开发、调试、版本管理成本翻倍占用双倍 APP 分区的 Flash 空间注意这里指的需要两个工程我们先明确一点就是在运行时我们需要把运行地址与flash的地址进行链接对应但是app1和app2的分区不一样地址也不一样所以当我们在链接运行地址时需要准备app1版本和app2版本的固件这样在执行时才能正确的链接到相应的分区。而一般更新的流程是读取当前Bootloader的OTA标志然后反馈上去然后更新另一个分区的程序进行下载举个通俗例子你写了一个全局变量g_ota_flag编译时预设运行地址是 APP1 分区0x10000链接器会把g_ota_flag绑定到0x10000 0x200这个地址如果把这个固件放到 APP2 分区0x190000运行程序会依然去0x10000 0x200读取g_ota_flag而这个地址已经不是g_ota_flag的实际存放地址程序直接跑飞。2.SRAM乒乓升级上面传统乒乓的特点是需要两次编译维护两个工程但是下面的流程是先把当前运行的分区程序拷贝到SRAM里进行运行然后再更新另一个分区因为程序都是从SRAM的同一个地址开始运行的所以app1和app2不用区分运行地址的链接因为都是搬运到SRAM的同一个地址进行运行这样只需要维护一个工程不用频繁的变动地址优点仅需维护一个 APP 工程升级时将 APP 加载到 SRAM 运行脱离 Flash 依赖可直接擦写 Flash 分区支持失败回滚。缺点要求芯片有足够大的 SRAM需能容纳整个 APP 程序仅适用于支持 “SRAM 中运行程序” 的芯片1.3.2 全量升级两个大小相同的分区APP、OTA。APP分区存放要执行的固件当OTA升级时会先把OTA数据包写入OTA分区然后再将OTA数据搬移到APP数据区最后从APP数据区启动执行。1.经典冗余全景升级就是程序始终都是在APP区BACKUP区是一个备份区可以在片外然后使用备份区覆盖APP区原理升级时先将新固件拷贝到BACKUP分区再从BACKUP覆盖到APP分区通过 “拷贝→覆盖” 完成全量更新。2.全量压缩两个大小相同的分区APP、OTA。 APP分区存放要执行的固件OTA分区存放OTA数据的压缩包bootload启动时会先将OTA压缩包解压再搬移到APP分区。其中APP分区会比OTA分区要大可以大大节省空间。就是我们使用的备份区是通过压缩算法得到后的这样传输比较小但是后面需要解压覆盖会增加压缩算法相关消耗特点减少固件传输和存储的空间占用缺点是增加了解压的算力开销且仍需占用 Flash 存储压缩包优点固件包经压缩如 gzip、LZ77后体积减小 30%~50%降低传输带宽和时间兼容原有全量升级流程缺点设备端需增加解压算法占用额外的 RAM 和 CPU 算力压缩 / 解压会增加升级耗时1.3.3 差分升级差分升级又叫增量更新是将旧版本与新版本的数据文件做差分得到升级部分的补丁即差分包用户下载了差分包之后将旧版本数据与差分包进行组合以得到新版本的数据文件多数采用BSDiff差分算法。可以这么理解差分升级并不是重新安装新的更新包而是根据新旧版本差异生成一个补丁包客户端可以下载补丁包完成更新。那么BSDiff差分算法是什么BSDiff 是一个差量更新算法它在服务器端运行BSDiff 算法产生 patch 包在客户端运行 BSPatch 算法将旧文件和 patch 包合成新文件。BSDiff基本步骤1对 old 文件中所有子字符串形成一个字典。2对比 old 文件和 new 文件产生 diff string 和extra string。3将 diff string 和 extra string 以及相应的控制字用zip压缩成一个 patch 包。BSPatch基本步骤客户端合成patch的基本步骤1接收patch包2解压patch包。3还原new文件。下面是几种升级方式1.差分升级基础版架构BOOTAPPDIFF分区DIFF存放差分算法生成的 Patch 包原理通过差分算法计算新旧固件的差异生成 Patch 包并写入DIFF分区再在设备端将 Patch 包打在原有 APP 上完成更新PATCH→覆盖**特点**仅传输差异数据省流量和 Flash但对固件差异度敏感差异大时效果不佳2.差分压缩其实在差分的基础上对补丁进行压缩然后解压出来再进行覆盖架构BOOTAPPZIPDIFF分区。原理先对差分 Patch 包做压缩存储到ZIP分区后解压再将解压后的 Patch 包应用到 APP 分区先解压→PATCH→覆盖**特点**在差分基础上进一步压缩更省空间但缺点是 “太占 Flash”实际使用场景有限3.差分压缩恢复后覆盖防变砖上面的方案是直接在app上进行合并失败会变砖这里把解压的和app进行合并放在这个NEW APP区之后再进行覆盖APP架构BOOTAPPZIPNEW APP分区新增NEW APP分区作为临时固件存储区原理压缩的差分包解压后先在NEW APP分区还原出完整新固件再从NEW APP拷贝覆盖到原APP分区解压→PATCH→还原→拷贝→覆盖特点解决了基础差分升级可能导致的设备变砖问题但需额外的NEW APP分区Flash 占用成本更高4.差分压缩流式架构BOOTAPPZIP分区无额外的 DIFF/NEW APP 分区原理采用流式处理将压缩的差分包边解压、边打 Patch、边覆盖到 APP 分区流式操作解压→打 PATCH→覆盖直接原地更新特点无需额外分区Flash 利用率高但对设备的实时处理能力要求较高需保证流式操作的稳定性2.Bootloader编写这里实现GD32的Bootloader要实现的功能如下串口IAP2.1 串口IAP功能要实现串口IAP功能我们使用串口传递大量的数据所以需要使用DMA但是现在对于数据接收的接收和处理这个问题是我们需要考虑的因为如果处理速度比接收速度太慢这样接收的数据回卷时就有可能覆盖还未处理的数据这里有两种方式一种是自定义的环形队列另一种是分块指针对主要要实现分块发送和处理