远程升级
远程升级是一个项目中绕不开的功能
关于远程升级的成熟方案有很多
在此简要备份几种
1. 固件编译烧录流程
- 准备好BOOT固件，编译生成hex文件
- 准备好APP固件，编译生成hex文件和bin文件，注意修改版本号，周期等出厂运行参数
- 合并BOOT和APP的固件，生成hex文件
- 准备bin文件的信息，版本号+总包大小+分包+长度+校验
- 烧录修改NB模组波特率的固件，自动检测波特率是否115200，
- J-LINK连接，全片擦除，烧录合并的固件
- 使用j-link command 连接，在特定的芯片内部地址写入app固件的信息
- 保存后，使用j-link读出整个芯片的程序
- 这个固件就是最终生产烧录的程序
- 重命名保存
- 配合烧录器或着J-link command 烧录设备的ID
- 此流程完成
问题1：
修改模组波特率为什么不嵌入到APP程序中？
答：一次执行的步骤能减少APP代码大小，交给烧录器完成
烧录器第一次先自动烧录修改检测波特率的程序
然后第二次烧录正式的固件
问题2：
为什么要写入固件的信息？
答：在BOOTloader中第一次运行，BOOT需要知道运行的app基本信息，
这个是需要烧录器在特定的地址写入特定长度的自定义数据
这个不是所有的烧录器都支持的
所以使用j-link command把这些信息写入，在读出整个固件，
减少一个步骤
问题3：设备ID是怎么写进去的
设备ID是使用烧录器的滚码操作，这个功能不支持不叫烧录器吧
2. 升级方案1
- 升级方案是根据具体的硬件资源来确定
- 使用的芯片内部128K FLASH
- 其中BOOTloader为16K空间，APP为102K空间
- 外部存储器为W25Q16,分为两个区域，第一个区域为运行APP的备份区，第二个区域为升级固件的下载区
- BOOT的功能简述：
- 上电判断是否需要升级（1）不升级跳转APP,
- (2)升级先判断下载区的升级信息对不对，正确判断下载区的版本和运行区版本
- 如果下载区版本号高，第一步先把运行区的固件备份，第二步把下载区的固件搬运到运行区
- 第三步校验后开始运行
- APP的功能简述：
- 业务流程上报完成之后，请求一下最新的版本
- 发现线上有新的版本，请求平台开始升级
- 平台回复允许升级之后，开始下载固件代码
- 下载完成之后，写入固件升级的标志位，写入升级固件的信息
- 然后复位，等待BOOTloader处理
问题1：
下载固件方式，效率如何，
答：使用TCP方式下载固件，固件分包大小和下载间隔做了测试，最终使用分包长度256字节和500毫秒做出平衡
问题2：丢包率高吗？丢包如何处理
答：100次样本实测440包丢包2-3包，可以说在100%以内，（TCP粘包的知识）
丢包个数如果大于设定的值，那就重新开始一轮，这样比较快
丢包个数如果小于设定的值，那就一包一包的开始请求补包
问题3：此种方案缺点？
答：下载固件的时间长，理论上需要4分钟左右时间，加上信号干扰等丢包因素，
如果备份区的固件损坏，并且下载区固件也损坏呢，这时候需要备份两个固件了，
但是实际情况硬件不可能这么多资源供你使用
只有代码写的好,boot加单app也是游刃有余
升级方案2
- 使用HTTP的通讯方式下载可以吗
- 超文本传输
