摘自涂鸦官方视频教程:https://www.bilibili.com/video/BV1pb41117LD?spm_id_from=333.999.0.0等
摘自:涂鸦IoT开发平台MCU开发接入(Wi-Fi)-App面板
地址:https://www.bilibili.com/video/BV1cK4y1x7Up?spm_id_from=333.999.0.0
摘自:关于初始化与串口数据处理函数
地址:https://www.bilibili.com/video/BV1Hb41117YW?spm_id_from=333.999.0.0
目录
名词解释(DeviceID、UUID、PID == KEY)
什么是设备ID?
英文名DeviceID:设备每次激活配网的时候,云端配网激活分配给到的id,关联配网后与账号、App等相关的实际用户设备数据。
什么是 UUID? (AES 的MESHID?)
涂鸦主联网模块的固件内写入的唯一性设备标示,用于接入涂鸦云时校验合法身份的依据之一,出厂携带,不随反复激活配网而更改。
UUID 和设备ID 的区别是什么? 设备ID 和 UUID 是平级的概念,描述的是设备的唯一性。
UUID着重表示设备硬件的唯一性,IoT设备在生产流程上,涂鸦的厂测工具会为每个涂鸦方案的设备颁发一个在涂鸦全球唯一的UUID和authkey,用于初次的认证授权;
设备ID着重表示设备在云端的实例化对象,设备向涂鸦云发起激活请求并激活成功后,涂鸦会为该设备颁发一个device_ID。
什么是产品 ID/PID?
Product ID,在涂鸦 IoT 开发平台创建的每一个产品都会产生一个唯一的产品编号,关联了产品具体的功能点、App 控制面板等、所有跟这个产品相关的信息。
Product ID,缩写:PID,涂鸦开发平台为每一个独立的产品分配的唯一性标示,当前关联了涂鸦开发体系内几乎所有的产品数字化信息,包括:
产品软硬件模型信息,如产品品类、通讯能力、功能、面板、模块型号、固件key、开发状态、开发方式、配网限制、固件JSON文件、支持第三方服务、支持第三方云等一系列产品属性;
产品生产资料信息,如模块型号、固件key、固件版本、产品热点名称、是否运营商标记、发货标签字段等;
产品在前后台的权限,包含前台客户OTA权限、是否可更改模块、是否可更改固件等;
产品与其他系统的关联信息。
PRODUCT_KEY
开发平台创建产品后生成的16位字符产品唯一标识,就是上面PID的值。在代码protocol.h文件里可以看到,如下图所示:
产品创建(DP功能点)
支持多故障类型上报(一个字节就支持8种故障,置1代表故障),比如0X09就是故障1和故障4同时发生;
字符串型显示一些地址之类的;
透传型不建议使用,取暖器周定时会使用(有空去涂鸦平台标准功能生成一下看看)。。
视频中DP点创建实例:
协议解析
产品Id
产品功能(DP点)
-
通讯协议格式
-
- 串口通讯约定(波特率等)
-
- 帧格式
- 帧格式
-
- 基础协议(模组必须的协议,与功能无关)
-
- 功能协议(和创立的DP点功能有关,平台自动创建的收发数据的值)
协议格式
现在协议最新的版本是03,多了一些功能而已,不过兼容以前的00、01版本,以前的版本可以继续使用。为了以后的升级拓展
模组工作流程图
- 0x08状态查询:模块首次上电、重启
- 0x07状态上报:MCU上报所有DP点数据,作为APP开机面板显示初值
基础协议(模组工作必须指令,与产品功能无关)
基础协议-心跳检测(命令字0x00)
- MCU上电第一次回复00,模组知道MCU是刚刚上电,接下来发送01、02命令字
- MCU后面回复01,表示模组知道第一次的信息已经同步完了,接下来就是正常的心跳,心跳间隔15s
- 心跳包间隔15s作用:假如一直没收到心跳回复,接下来APP会显示设备离线
基础协议-查询产品信息(命令字0x01)
模组心跳包收到正确回复后,模组发送01命令字。
基础协议-查询设定模块工作模式- -配合、自处理(命令字0x02)
一般使用MCU和模块配合的方式
注意:触发方式不一定是按键方式,是由MCU自己决定的,闪烁也不一定是LED灯,可能是WIFI的图标。
b.模块自处理:MCU不用去进行配网的操作以及指示灯的指示
WIFI模块的工作状态通过WIFI的GPIO引脚驱动LED状态显示;
WIFI重置通过检测GPIO输入需求处理。
模块自处理WIFI重置方法为:WIFI检测GPIO入口低电平持续5s以上触发WIFI重置。指示灯与按钮所使用的GPIO管脚由命令配置。
基础协议-报告设备联网状态-(命令字0x03,模块自处理模式没有此命令字)
LED亮灯的模式是MCU去引导的,MCU根据03命令字获得的联网状态进行控制LED闪灯
一旦WIFI状态发生变化,模组主动发送WIFI状态值
基础协议-状态查询与上报–模块首次上电/MCU重启(命令字0x08、0x07)
以上,初始化部分就完成了。
基础协议-配网操作方便和APP连接(命令字0x04、0x05,模块自处理模式没有此命令字)
- smart模式:选择家里WIFI,输入密码即可。配网简单
- AP模式:输入家庭WIFI密码后,需要连接WIFI模组本身产生的AP热点,再跳回APP连接。配网稳定可靠
- 0x04命令字多次调用,两个模式来回切换;
- 0x05命令字进入指定的模式;
- 工作状态下,调用0x04会先切换到Smart模式,继续调用两个模式来回切换
基础协议-产测功能
把产测路由改成tuya_mdea_test这个热点名称,模组收到产测命令去扫描这个热点,从而测试模组的射频性能。
功能协议(数据下发0x06和上报0x07DP点数据)
功能长度就是后面功能指令的长度,比如第二个温度: 功能长度0x04,功能指令值为50,数据位长度不够前面补零,就是0000 0050
模组下发开关指令,状态改变了要上报给APP,因此第一行开关属于可下发可上报,下同。
串口助手使用方法
涂鸦云串口调试助手
这个调试助手只能调试MCU与模组的通信,检验SDK的移植以及串口通信是否调通,不能和手机APP端进行调试
命令字0X08要求MCU上报所有DP功能点初值作为面板显示初值(APP),这个应该是涂鸦自己的SDK
MCU仿真调试助手
安装包在官网下载
移植SDK
有一些51内核的对函数嵌套层级有要求,资源不足的用户可自行对接协议,但是SDK里面的内容和一些运算函数是可以借鉴的。
移植步骤六步走
步骤一:编写MCU基础程序,移植SDK文件
把SDK文件都添加到工程里面,方法参照STM32方法,STM32 的话记得还要添加头文件路径。
步骤二:确认protocol.h宏定义
RAM不够用,数据接收队列大小可适当缩小,只要能及时取出即可
后面的一些功能选择看自己的需求,也就是对宏定义的操作
步骤三:移植protocol.c文件及函数在main中调用
1
2
3、串口单字节发送函数,发送的参数为value
由于这个.c文件引用了串口发送这个函数,所以这个.c文件要引用一下main.h
4、串口接收函数
5、main函数while循环调用串口处理函数
main函数循环调用这个串口处理函数(所有的数据处理都是在接收中断接收完以后,放到接收缓存区进行帧头帧尾的各种判断)
步骤四:DP点数据上报和下发函数处理
1、
初值建议全部设为0;
不建议用户随意调用all_data_update()函数,数据量比较庞大,一直占MCU资源,而且一直对服务器有一定的压力;
如果某一个DP状态变了,比如开关状态变了,上报开关变量的方法就是调用单独的DP点函数。
RAW透传型后面有两个变量
2、
3、
可下发可上传
其他DP功能类比实现。
到这个步骤完成,就可以使用串口调试助手去模拟跑一遍,看对接协议是否正确,保证调试好。
步骤五:配网功能及闪灯函数完善
模组自处理模式不需要这个步骤,因为按键和灯都接在模组端了。
1、
进入配网模式以后,模组会重启,发送WIFI状态、同步状态命令字等。
2、
注:新版函数名称有改动
步骤六:产测功能完善
这六个步骤完成,程序就可以跑起来了!
MCU在线升级
这部分作者没讲。
SDK程序结构解析(初始化与串口数据处理)
wifi_protocol_init初始化函数
在system.h里定义了一段指定大小的队列buf,即bt_queue_buf
queue_in和queue_out分别为队列的入和出,指向bt_queue_buf的首地址,队列的入和出是在串口中断接收函数uart_receive_input内使用的
进入uart_receive_input函数
614行queue_in - queue_out大于开辟的队列缓冲区大小,说明队列满了
618行代表出现一些异常错误
625行queue_in到达队列最底部,此时要让queue_in重新指向起始地址
队列先进先出
wifi_uart_service串口数据处理函数
while内尽量不要有大延时函数,否则接收队列容易满,进而需要加大接收队列缓冲区大小。
647行:
649行:取出数据
652行:判断接收数据的长度
判断帧头是否是55 AA 00 …
data_handle
ifdefine …#else… #endif代表条件编译
上图宏定义:
心跳包回复
209行上报回复的函数(进行拼接):
上图中186行:
上图中141行:
产品信息上传回复
转成字符串发送出去,记得前面讲的是通过ASCII发送?
命令下发:
升级:
获取本地时间、WIFI功能测试:
状态查询,所有数据上报(08命令字):
uart_receive_input串口接收函数
MCU开发接入(Wi-Fi)-APP面板
参考:https://www.bilibili.com/video/BV1cK4y1x7Up?spm_id_from=333.999.0.0
MCU开发接入(Wi-Fi)-OTA功能
摘自:涂鸦IoT开发平台MCU开发接入(Wi-Fi)-OTA功能
地址:https://www.bilibili.com/video/BV1TV411U7fs?spm_id_from=333.999.0.0
说明:视频里讲的是WIFI模组串口协议,就两个命令字0x0a和0x0b,具体参见涂鸦文档,和蓝牙的方式有区别。
蓝牙通用串口协议支持 MCU OTA 功能,通过涂鸦 IoT 平台,先将需要更新的固件文件上传至涂鸦,然后通过蓝牙网关或手机 App(如涂鸦智能)等载体下载固件并透传给蓝牙模组。蓝牙模组再通过涂鸦协议对文件进行分包传输,最后 MCU 接收升级包并写入本地闪存,最终实现固件的升级。
升级过程流程图
升级请求(命令字0xEA)
升级开始的时候由模组向 MCU 发送请求,告知有OTA来了,获取 MCU 串口能传输的最大单包长度。
模组发送:
MCU 回复:
升级文件信息-MCU对比决定是否升级(命令字0xEB)
描述了 MCU-OTA 升级文件信息,MCU 可比较升级信息决定是否升级。
模组发布:
MCU回复:
断点续传:
-
为了支持断点续传,这里会返回设备端已经储存的文件信息。 App 收到信息后,根据设备返回的已储存文件长度,计算新文件对应长度的 CRC32,然后和设备返回的 CRC32 对比。如果两者都吻合,那么在下面的文件起始传输请求中将起始传输偏移量改为该长度值,否则文件起始传输偏移量改为 0,表示从头开始传输。
-
每次断点续传都会完全按照 MCU OTA 流程的顺序,从 OTA 升级请求开始,所以 MCU 端如果有维护升级状态的话,需要在收到模组工作状态为非绑定已连接的其他状态时重置升级状态,以确保可以开始下一个升级流程。
升级文件偏移请求(命令字0xEC)
模组发送:
MCU 回复:
升级数据(命令字0xED)
模组发送:
MCU回复:
升级结束(命令字0xEE)
模组发送:
MCU回复:
SDK相关完善
软件版本号更新
注意:宏定义大小要大于最大包长度
这里工作量主要在MCU的bootloader和flash的读写操作上。
涂鸦平台相关操作
OTA升级实操
此部分摘自:https://www.bilibili.com/video/av971203572/
这是WIFI的OTA升级传输串口协议,和蓝牙的不太一样。
上图中:
步骤④:app应用程序main函数发起中断请求,发现此中断函数是boot里的;
步骤⑤:中断向量偏移到app应用程序里,执行app里的中断函数。
WIFI 产测功能
摘自:涂鸦IoT开发平台MCU开发接入(Wi-Fi)-产测功能
地址:https://www.bilibili.com/video/BV1Ki4y1g7NM?spm_id_from=333.999.0.0
扫描指定路由
可自定义按键按下去调用产测函数。
连接指定路由
产测成功重复进入产测可以重新发送测试命令;
没有收到连上路由的包(账号密码输错了,再次输入它是不会被覆盖掉的)表示模组正在产测中需要重置模组或者重新上电后发送测试命令才有效。