参考资料
《PIC16PIC18器件的高速串行自举程序》《8位PIC MCU自举程序代码生成器》
云端用自己的服务器。
1 首先要获取 目录下的版本号。 并经过判断是否下载。
2 要分段下载数据，并依次更新。 这个在HTTP1.1协议上可以实现。
材料都好了， 大体细节也都好了，一步一步的玩一下。
2018 0902
我下载了AN1310ui.exe，官网的。
解压后， 里面有PIC16 ,PIC18的 APP 和 BOOTLD 的程序。
令人遗憾的是 都是老版本的IDE 编写的， 没有新的IED MPLAB X
打开APP ，只是个简单的程序。
BOOTLD 是用汇编写的， 这么多年没有看汇编了，实在是。。。没看。
奇怪的是PIC18 的BOOTLD 可以编译成功，
PIC16的却编译失败，说没有定义RC7 ，简单修改一下，编译也没有成功，就放弃了。
官网的DEMO 都不能编译通过，看来官方不太重视这个很久了。
把BOOTLD的 程序，改一下芯片，按照配置位建议设置 改了一下配置位。 并用PIK3 下载下去。
上电，打开AN1310ui.exe，在一次不好就倒换RX,TX,之后，连接上了。
能看到BOOTLD的程序。 当然都是0XFF， 在ROM的最后有个区域是不允许写了，看来是被BOOTLD 占了。
下个个APP的HEX , 点击下载，好长时间，没有任何显示。
再查看里面的程序，明显是被写进去了。。。。。连个回馈也没有。。。差评。
这个BOOTLD 延续了MICROCHIP 一贯的思维， 开机的时候，检查RC7 是否被按下来决定是否进入自举还是应用程序。
这个不是我想要的，我想应该是接收到特殊的指令后，开始进入自举程序。
这个自举程序还是用汇编写的。。。谁愿意去改动呢？
2018 0903
MPLAB X 在MCC中把BOOTLD 集成了，作为一个LIB 使用。 在16系列中 提示可以使用，但是没有经过仔细验证。
也就是说使用要小心，可能有一定的局限。
加载BOOTLD 后，生成工程，在正常的文件之外，又生成了2个文件 BOODLOAD.H BOODLOAD.C .
里面写的程序 风格不太像官方的风格。
里面写的还算详细。。。也是在上电判断是否有updata的标志位，据此来跳转到app 还是 boodld.
这个不符合我想要的云端升级的标准，估计要重新改写这个bootld。
--------- 2018 0915
升级程序的另一个难点是分段升级。 这个主要是AIR模块来完成。
主要步骤： 1) AIR202 通电后， 发UART 给MCU 要求获取企业号和软件版本 {"id":"?"} 波特率是115200
2） MCU 得到JOSN 的ID 后， 回复 {"CompanyID": "XXX", "Version":"xxx"}
3 ） AIR202 得到 Company and version 的ID 后，和网上服务器获取的 企业ID 版本号进行比较，如果条件符合，开始拉数据下来。
4） 数据是256 或固定的字节拉下来的。
AIR202 通过以下格式 发送给MCU
{ Mode:hex/bin,
blockCount :xx, --是第几段数据
blockLength:xxx, -- 这一段的数据长度
Data:........... -- 数据
}
5） MCU 接收到数据后， 进行解码 并处理，处理完毕后，发送回应
{ "CheckCode" : "xxx" }
6） air202 接收到后，和自己的校验码 比较，成功，则继续拉数据。
GRPS模块的程序已经做好，数据已经可以GET到，并验证。 下一步就是MCU的uart IAP 了。
2018 10 19
- 上一篇： ESP8266 云端升级
- 下一篇： air202用LUAT 连接ONENET
EE直播间
更多
-
提升毫米波信号测试精度 直播时间： 12月18日 14:00 -
EE Talk主题专访系列直播-对话：释放 Wi-Fi 7 在高带宽应用中的技术潜力 直播时间： 12月19日 10:00
关闭
站长推荐
/2 
/2
文章评论（0条评论）
登录后参与讨论