UIXO协议
UIXO协议
UIXO简化协议
1. UIXO模块支持热插拔(即插即用),不需要用户电脑里安装任何软件不需任何配置,只要有浏览器就可以。然后在对应的硬件浏览器网页里,参照界面说明读取信息和配置控制UIXO模块。
2. UIXO模块具有串口波特率自适应的特性,上电后通过向WI-FI串口发送测试信息,检测request信息是否是test来完成模块的波特率自适应。
3. 小模块的协议将公开,并且提供描述符样例代码帮助用户制造和DIY兼容设备和新设备。
4. 模块的协议将划分团队官方认证设备和用户自定义设备。
5. 经过官方认证的的设备可以自动识别型号,由硬件浏览器自动分享和从网上下载配置文件和驱动,具有优化的显示图标和专用的参数配置页面,官方认证设备将可以通过网络更新单片机固件,使用TwinkleStar官方服务器,认证设备的制造商将可以把新版固件提交TwinkleStar服务器审核后发布并更新到所有的模块中(通过进入刷机模式串口来写入小模块固件)。
6. 未经官方认证的自定义设备允许用户建立自定义的配置页面和配置参数。
总结:这是一种远优于传统arduino电子积木的方案,结合团队正在完成的硬件浏览器非常适合在物联网环境下采集数据和完成物理世界的控制。
7. 来自TwinkleStar的请求分为(在MODE位)
设备类型描述请求(0x01:device descriptor request)
地址设置请求(0x02:device address request)
设备配置格式请求(0x03:configuation formate request)
设备配置请求(0x04:configuration request)
设备报告格式请求(0x05:report format request)
数据请求(0x06:In action data request)
配置更新请求(0x07:save the current configuration toflash)
默认配置请求(0x08:restore default configuation)
固件更新请求(0x09:mode ISP request)
设备信息帮助请求(0x0A:help info in ASCII mode ISP request)
IO口配置请求(0x0B:IO configuration request )
IO口功能请求(0x0C: IO function request)
特殊函数请求(0x0D: Special function request)
特殊功能顺序请求(0x0E: Special function sequence request)
8.来自串口单片机的数据分为(类似于MODE位)
设备类型描述
地址
配置
配置格式
报告格式
数据请求
数据报告
IO口配置报告
IO口功能报告
特殊函数报告
特殊功能顺序报告
模块枚举的流程如下
1. 模块插入TwinkleStar的WI-FI接口系统上电启动载入默认设备配置说明(有kernel底层自载入该UIXO模块设备配置说明,同时由TwinkleStar发起询问WHO ARE YOU,以此做双层保护)
2. 波特率自适应方式:模块接收TwinkleStar请求,回复test直到TwinkleStar找到合适的波特率。之后按协议发送数据。
3. 单片机开始发送数据或者TwinkleStar开始发送数据(具体见设备描述分类)
4. 当单片机未按请求回复自己的地址的时候重发test等待设备描述符请求(可能是拔出或者更换)按照返回数据重新流程或者关闭WI-FI分配给别的模块
UIXO-Andromeda协议制定
1. 整体结构(总体来讲):
TwinkleStar端协议:
0x48 | 0x59 | 0x3C | 0x** | 0x** | 0x** | 0x** |
头 | 头 | 头 | SIZE | MODE | DATA | Checksum |
结构说明:
帧头:0x48 0x59 0X3C
内容:从SIZE到DATA,SIZE指的是从MODE到DATA的字节长度,从0开始计数。
帧尾:Checksum是从MODE到DATA的所有字节异或。
MCU协处理器端协议:
0x48 | 0x59 | 0x3E | 0x** | 0x** | 0x** | 0x** |
头 | 头 | 头 | SIZE | MODE | DATA | Checksum |
结构说明:
帧头:0x48 0x59 0X3E
内容:从SIZE到DATA,SIZE指的是从MODE到DATA的字节长度,从0开始计数。
帧尾:Checksum是从MODE到DATA的所有字节异或。
2. 当硬件浏览器端询问WHO ARE YOU时,单片机返回设备描述(包括PID,UID)
设备描述格式0x48;0x59;0x3E;[设备描述符大小{字节数包括桢头}][设备类{0x00,0x01,0x02,0x03,0x04,0x05}];[设备制造商{0x00代表TwinkleStar团队,0xff代表用户自定义,中间的数值代表不同的认证小模块制造商}];[设备绝对ID号高字节];[设备绝对ID号低字节];[设备硬件版本号];{可选的xml格式页面描述,用于配制硬件浏览器中的设备页面};校验位
3. 说明MODE位上的作用
当MODE位等于以下时,相应作用见下面说明
设备类型描述请求(0x01:device descriptor request)
地址设置请求(0x02:device address request)
设备配置格式请求(0x03:configuation formate request)
设备配置请求(0x04:configuration request)
设备报告格式请求(0x05:report format request)
数据请求(0x06:In action data request)
配置更新请求(0x07:save the current configuration toflash)
默认配置请求(0x08:restore default configuation)
固件更新请求(0x09:mode ISP request)
设备信息帮助请求(0x0A:help info in ASCII mode ISP request)
IO口配置请求(0x0B:IO configuration request )
IO口功能请求(0x0C: IO function request)
特殊函数请求(0x0D: Special function request)
特殊功能顺序请求(0x0E: Special function sequence request)
思想:封装
API
机制,意在更加灵活的搭建应用。
4. 重点说明一:设备信息帮助请求(0x0A:help info in ASCII mode ISP request)
如果硬件浏览器发送以下信息
0X48 | 0X59 | 0X3C | 0X00 | 0X0A | 0X0A |
头 | 头 | 头 | SIZE | MODE | Checksum |
MCU端会发送一系列UIXO模块的帮助配置信息,以及此开发板说明信息
5. 重点说明二:IO口配置请求(0x0B:IO configuration request )
如果硬件浏览器发送以下信息
48 | 59 | 3C | 0X** | 0X0B | 0X** | 0X** | 0X** | 0X** |
头 | 头 | 头 | SIZE | MODE | IO | IO_MODE | Config_data | Checksum |
格式介绍:
硬件浏览器配置,由硬件浏览器发起请求格式
0x48
;
0x59
;
0x3C ;[ 请求描述长度
0(SIZE_LENGHT) ];[ 请求帧
1(MODE) ] ;[ 请求帧
2(IO) ];[ 请求帧
3(IO_MODE) ];[ 请求帧
4(Config_data) ];[ 数据校验
(Checksum) ]
SIZE指的是报告描述长度,从请求帧开始到数据校验之前的字节数,并且从0开始计数。
请求帧1是MODE,模式请求选择,例如请求设备制造商,这里是0X01;请求确定波特率,即是0x00;IO口配置请求是0x0B;IO口功能请求是0x0C。
请求帧2是IO,即IO端口选择。
请求帧3是IO_MODE,即请求该IO口模式配置,例如0x00是标准IO口输入输出配置模式;0X01是PWM输出配置模式;0X02是ADC配置模式;0X03是IIC配置模式;0X04是SPI配置模式;0X05是串口配置模式。
请求帧4是Config_data,即请求该IO口在模式配置数据参数,例如在标准IO输入输出配置模式下,0x00是标准IO口输入配置;0X01是标准IO口输出配置;其他等等,见以后说明。
数据校验是Checksum位,即从MODE开始到checksum之前的所有数据异或。
6. 重点说明四:特殊函数请求(0x0D: Special function request)
思想:增减机制
7. 重点说明五:特殊功能顺序请求(0x0E: Special function sequence request)
思想
:
顺序机制,进化机制