介绍几种的常见物联网WiFi模块的OTA方案

　　在物联网开发中，OTA升级（firmware update Over The Air）是模组必备的功能，本文将以RTL8711、乐鑫8266 、庆科3186 wifi模块为例介绍几种的常见的ota方案，并进行对比总结。
　　RTL8711 ota升级方案
　　方案简介
　　8711flash分区如下图：
　　
　　RTL 8711AF flash分为bootloader、校验信息区、系统信息区、默认固件区，可升级固件区，用户区，默认固件区存放通过烧录方式更新的固件，可升级固件区存放通过ota升级方式更新的固件。这两个区只有可升级固件区是可以用于ota升级的。ota固件升级其实就是IAP（In ApplicationProgramming）应用编程，一般包含两个程序：Bootloader程序和APP程序。以RTL8711AF为例，芯片上电后固定从Bootloader启动。
　　Bootloader主要负责：
　　（1）读取每个区应用程序签名信息；
　　（2）判断应用程序该从哪个区启动；
　　（3）把对应的falsh区的应用程序拷贝到SRAM，跳转到SRAM运行应用程序。
　　APP程序负责：
　　（1）定期发送http请求向服务器获取最新固件信息；
　　（2）和当前固件对比，确定是否需要更新，如果需要更新从服务器下载最新固件到用于ota的flash区；
　　（3）更新flash区签名，软件复位。
　　固件下载的过程中会对固件进行校验检查以确认下载的固件是完整正确的包。
　　8711 bootloader 程序流程如下图，从系统参数中获取到两个存固件的flash区的地址后，去读取这两个区的签名，在看哪个区的签名是“81958711”便从哪个区启动。
　　
　　8711 ota APP程序流程图下图，从系统参数获取了可升级区的地址后，去擦除该区，再从服务器下载新的固件写到flash去，最后对该区签名进行更新，并把另一区的签名也更新。
　　
　　
　　8711 ota方案优缺点
　　8711ota方案把flash分成两个区，一个区固定用于烧录，一个区用于ota升级，比较简单，容易实现；缺点是产品出厂后，若某次ota升级过程断电或断网升级失败flash被破坏，再次上电只能跑另一个烧录区固件，即出厂时烧录的第一个固件版本，无法跑上一个版本。
　　那能不能两个区都用于ota升级，这次升级A区下次升级B区，交替升级，当升级失败跑另一个区？此时就是上一个版本了。可以，需要重新设计整个方案。
　　固定一个区烧录一个区ota升级这样实现起来简单，若设计成两个区交替升级是否可以？比较复杂，原因是：
　　1、不同区的固件编译条件是不同的，编译时要设置相应flash区的起始地址和大小，所以生成的固件也不同，发布版本时需要发布两个固件。
　　2、如果要设计成两个区都可ota升级，需要有系统信息记录目前程序跑的分区，ota升级时先获取目前程序跑在哪个区，再从服务器下载另一个区对应的固件，bootloader启动时也需要知道应该从哪个区去启动，比较繁琐。
　　
　　乐鑫ESP8266 ota方案
　　方案简介
　　乐鑫方案采用的就是上文说的双区交替升级方案，下图为乐鑫8266 flash分区图，分区1和分区2都是可以进行ota升级的。
　　
　　系统参数区存储了一个标志位，标识系统起来后应该去跑哪个区（即图中user1.bin或user2.bin）。系统启动时先去运行boot，boot读取该标志位，然后再到对应的区去读取固件运行。
　　举个例子，初始状态运行版本V0.1的user1.bin，系统参数区标志位为使用user1.bin。当需要升级时，上传V0.2版本的固件suer1.bin和user2.bin到云端服务器，ESP8266 wifi板执行升级时，先读取系统标志位，确定当前用的是user1.bin，然后从服务器端下载user2.bin存储到分区2，如果user2.bin是正确无误的固件，且下载成功，修改系统参数区标志位为分区2然后重启。重启后首先去读取该标志位，读到是分区2，然后从分区2启动。
　　如果下载固件过程中断网或断电造成下载失败，则系统再次启动时，分区标志位为使用user1.bin，此时跑的就是上一个版本，而不是出厂时的第一个版本。
　　乐鑫方案优缺点
　　乐鑫方案的优点是可以实现升级失败时回到上一个版本，而不是回到第一个版本。缺点就是每次发布版本要同时发布两个升级文件，有点繁琐，万一发布错了，user1.bin和user2.bin搞反了，导致某次升级下载的升级文件与分区不匹配，那wifi板就直接变砖头了没有挽救的余地。
　　
　　庆科EMW3165方案
　　方案简介
　　庆科方案不但解决了升级失败时无法回到上一版本的问题，还很简单。跟上述一样分为bootloader和app程序，不一样的是固件启动运行时步骤稍有不同。
　　同样在APP程序中发起HTTP请求查询服务器是否有新的固件版本并进行下载，并固定存储到片外的flash区、修改固件的参数信息、重启。重启后做的第一件事是去检查固件参数信息，是否有新的固件？若有将片外flash区的固件搬运到片内flash区，跳转到那里运行。
　　庆科3165的flash区域规划如下图：
　　
　　Bootloader放置在片内Flash的0x08000000地址，大小为64K，设备上电后首先跳到这里执行；
　　Application放置在片内Flash的0x08010000地址；PARAMETER_1和PARAMETER_2（备份用）记录固件参数信息的区域，它们放在片外Flash；
　　OTA_TEMP区域为OTA固件存储区域，放在片外Flash，Application从网络下载bin文件然后写到该区域，而Bootloader从这个区域搬运固件到Application区域。
　　升级过程：
　　（1）Application查询服务器是否有新的固件需要下载，若有下载到OTA_TEMP区；
　　（2）修改PARAMETER_1参数，记录固件信息；
　　（3）重启
　　（4）Bootloader读取PARAMETER_1参数，判断OTA_TEMP区是否有新固件需要更新；
　　（5）若有把OTA_TEMP区的固件搬运到内置flash区；
　　（6）跳转到Application程序去执行。
　　庆科方案优缺点
　　优点很明显了，这种方式既保证了升级过程失败再次上电跑的是上一版本，又很简单，发版本时只需发一个固件就好不像乐鑫那么复杂。
　　聪明之处在于分开两个flash区，一个专门用于下载存储固件，另一个专门运行程序。这样就避免了发版本时要发两个固件，又避免了上电启动需要判断从哪个区去启动。下载固件过程若断电下载失败，再次启动先去读取固件参数，发现没有新版本，那此时跑原来片内flash的固件即上一版本固件。
　　缺点暂时没有发现，可能是上电后需要去搬运固件时间会稍微长一点？古北的模块用的也是这种方案，从使用体验上来看并没有明显感觉时间长。