实现功能概要
这节和上一节的功能一样(只不过上节是利用Wi-Fi模块,这节是利用GPRS模块)
用户程序里面加入MQTT通信,执行用户程序的时候,
通过接收MQTT的升级命令实现升级.
凡是可以实现MQTT通信的上位机皆可控制单片机升级.
通信控制协议和上一节一样
注:所有的实现MQTT的软件,统称为MQTT上位机 一,MQTT上位机通过MQTT发送获取设备信息指令 {"data":"updata","cmd":"DeviceInfo"} //设备接收到回复 {"data":"updata","model":"STM32_AT8266","version":"1.0.2"}//假设现在的型号是STM32_AT8266,当前设备硬件版本是1.0.2 二,MQTT上位机根据型号使用http访问云端存放的记录更新信息的文件 "型号" 列如:上位机使用http访问 "http://47.92.31.46/hardware/"+STM32_AT8266+"/"+"updatainfo.txt" 假设updatainfo.txt文件信息是: {"version":"1.0.4","details":"1,优化了部分BUG;2,测试升级;3,支持升级STM32程序;4,修改XXXBUG"} 后面的 "details":"1,优化了部分BUG;2,测试升级;3,支持升级STM32程序;4,修改XXXBUG" MQTT上位机可作为升级提示信息,提示给用户 注:版本号最大设置为20字节 三,MQTT上位机对比版本号,如果不一致,则发送以下指令 {"data":"updata","cmd":"start"} 注:测试时可直接发送此指令 //设备接收到回复 {"data":"updata","status":"start"} 四,设备连接上MQTT发送的第一条消息为 "{"data":"status","status":"online","UpdataStatus":"UpdataSuccess","version":"1.0.4"}" UpdataSuccess 更新成功 RunAppErr 上次更新的程序没有运行起来 NoUpdata 没有更新 DataAddressError 更新的数据有错误 DataOverflow 数据溢出 DataDownloadTimeout 下载超时 MainTimeout 更新超时 FlashWriteErr 写Flash失败 FlashEraseErr 擦除Flash失败 VersionLenErr 版本号长度 等于0 或者大于20 VersionAlike 版本号一致,是最新程序,无需更新 ---------------------------------------------------------------- 控制指令,查询继电器状态 {"data":"switch","bit":"1","status":"-1"} 设备回复 {"data":"switch","bit":"1","status":"1"} 或者 {"data":"switch","bit":"1","status":"0"} 六,控制指令,控制继电器吸合 {"data":"switch","bit":"1","status":"1"} 设备回复 {"data":"switch","bit":"1","status":"1"} 七,控制指令,控制继电器断开 {"data":"switch","bit":"1","status":"0"} 设备回复 {"data":"switch","bit":"1","status":"0"}
快速测试: 测试准备工作
一,下载单片机程序(BootLoader)
二,下载第一份用户程序
三,STM32和Air202 串口1 通信
四,安装APP
注:APP和上一节一样,如果安装了不需要重复安装
如果上一节更改为了自己的服务器,请重新安装.或者直接看下面更改为自己的服务器测试部分
快速测试: 扫描二维码绑定设备
一,打开APP 扫描添加设备
快速测试: 现在用APP控制更新
一.点击设备进入,设备控制页面,点击最下面的检查更新
三.设备开始更新
注:这个时候最好手动复位下模块(这次的板子未引出复位引脚,单片机无法实现硬件复位)
四,更新完成以后
应用到自己的服务器(修改BootLoader程序)
一,修改为自己的Web服务器的IP地址和端口号,文件访问路径自己随意.
应用到自己的服务器(修改用户程序1)
一, 修改为自己的MQTT信息,如果前面修改了设备型号,此处也要做修改.
应用到自己的服务器(修改用户程序2)
一, 修改为自己的MQTT信息,如果前面修改了设备型号,此处也要做修改.
应用到自己的服务器(把文件放到Web服务器中)
一,拷贝记录设备版本的updatainfo.txt文件,和用户程序1文件(Progect.bin),用户程序2文件(Progect2.bin)到服务器
二,拷贝效果如下
注:这次的设备取了一个型号 STM32_MQTT_AT_GPRS
应用到自己的服务器(修改APP)
一,修改APP访问的MQTT信息
二,修改APP访问的http信息
三,卸载原来的APP,用软件安装最新的
应用到自己的服务器(测试)
一,下载单片机程序(BootLoader)
二,现在只下载了BootLoader ,咱们不人为下载用户程序了,让单片机自动下载进去
长按PB5大约3S,待指示灯快闪以后松开,即可自动更新程序
三.等到单片机更新完程序,执行刚更新的用户程序,连接上MQTT以后,指示灯会1S 闪耀
注:如果等了3分钟没有出现闪耀说明没有更新进去,可重新按照上面步骤重试
(由于内存限制,已经无法使用液晶来提示!抱歉)
四.点击APP的 检查更新
因为是刚更新进去的程序,所以当然是最新版本了.
五.去云端修改下版本
六.点击APP的 检查更新
七,手动复位下,下一版本的单片机将加上硬件复位
七.更新完成
代码制作步骤(BootLoader程序)
一,拷贝升级篇第二节里面的BootLoader程序到当前目录
二,修改BootLoader程序的型号为STM32_MQTT_AT_GPRS
代码制作步骤(用户程序)
一,拷贝基础篇的 "测试APP扫描Air202上面的二维码绑定通过MQTT控制设备" 程序到当前目录
二,拷贝升级篇 "测试STM32远程乒乓升级,基于(GPRS模块AT指令TCP透传方式),定时访问升级"
用户程序里面的IAP文件和stmflash文件到现在的用户程序工程里面
三,添加文件,包含头文件,去掉oled程序(因为加上oled内存就超了,具体看上一节)
四,设置软件生成bin文件
五,用户程序加上获取更新状态,获取版本和处理更新状态
拷贝路径: 升级篇的用户程序main里面(随便找一篇就可以)
5.1 获取更新状态,程序版本
5.2 处理更新状态,清除更新状态
咱的这个处理呢!加在用户程序连接上MQTT,向MQTT发送的第一条消息里面
注:直接把上一节拷贝过来就可以(反正只要实现了透传了,后期处理啥都是一样了)
六,用户程序加上处理MQTT升级相关指令
6.1,用数组存储型号,这个型号记得和BootLoader程序保持一致
6.2,在原来处理MQTT数据的地方加上处理更新部分
单独运行用户程序,测试下通信
一,为了方便测试,我把程序中发布和订阅的主题设置成自定义的
二,不过呢,我还是改一下,毕竟咱连接的一个MQT服务器,订阅和发布的主题只要对应便建立通信了
如果大家都用1111作为发布的主题,2222作为订阅的主题来测试,有可能别人控制我的设备
我也有可能也控制了别人的设备.
三,打开调试助手,我重新做了一个新版的C#的MQTT调试助手
四,设置好参数
五,别忘了拨动开关,手机卡,天线
六,下载单片机程序,正常操作以后,MQTT客户端会收到设备发送的连接上MQTT以后的第一条信息
因为没有加BootLoader程序初始化版本 所以version 就是空的.
七,发送询问设备信息指令 {"data":"updata","cmd":"DeviceInfo"}
八,发送个升级指令,看看是否回复,然后看看是否重启 {"data":"updata","cmd":"start"}
注:实际应用请使用一个引脚控制模块重启
请在每个程序文件的此处修改(注,本人的板子现在未引出复位引脚,下一批板子将跟进)
如果没有复位可能出现一直发送 AT+CIPSHUT ,模块要等到好久才有反应过来
现在测试可人为进行复位!
配置生成第一份bin文件
一,修改配置
二,编译,生成bin文件
复制出来一份用户程序作为第二份程序文件
一,复制一份用户程序文件
二,配置一下中断向量偏移,还有这份文件运行的位置
三,设置一下生成的bin文件的名字
四,编译
