Skip to content

Latest commit

 

History

History
 
 

wifi

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
MHCW03P
MHCW03P
 
 
README.md
README.md
 
 
testing.md
testing.md
 
 
基于MIIO模组的WiFi产品设计规范.md
基于MIIO模组的WiFi产品设计规范.md
 
 

README.md

WIFI-模组接入

模组接入方式适合于不具备通讯能力的产品，需要将小米智能模组嵌入现有产品的电路中。将MIIO模组作为透传通道，通过串口和主控芯片进行业务逻辑交互。

目录

开发准备

小米IoT开放平台>开发引导中小米IoT开放平台接入相关介绍，请务必提前阅读。

模组调试

WIFI模组硬件简介

小米MHCW03P模组开发板

外观图：

外观图

管脚图：

管脚图

原理图：

原理图

LOG输出测试

  • MHCW03P模组LOG输出口  74880 8N1
  • 我们可以通过这个口看到模组工作状态。
  • 模组上电后，可以看到一个典型的LOG输出，包含固件版本 firmware， 设备DID digital_did， MAC地址mac address 等。

log

_|      _|  _|_|_|  _|_|_|    _|_|
_|_|  _|_|    _|      _|    _|    _|
_|  _|  _|    _|      _|    _|    _|
_|      _|    _|      _|    _|    _|
_|      _|  _|_|_|  _|_|_|    _|_|  

OTP read OK
JENKINS BUILD NUMBER: N/A
BUILD TIME: N/A
BUILT BY: N/A
firmware: 1.2.5
MIIO APP VER: N/A
MIIO MCU VER: N/A
ESP SDK VER: 1.3.0(2ecfb74)
digital_did is 12593364
mac address is f0b42905b742

串口通信测试

  • 你只需要通过串口(115200 8N1)即可与小米模组进行通信，如图：

  • 通过串口工具打开串口，输入help既可以得到支持的串口命令列表，此时证明串口工作正常。

uart

FAQ

  • Q：模组无法启动，没有打印内容或者打印内容非常少，发现不了AP怎么回事？
  • A：请检查连接线路是否OK，并确认GPIO0是否被拉低进入烧录模式或者GPIO15被拉高无法正常启动。如果还有问题，请咨询开发人员。
  • Q：启动时在串口打印的乱码是怎们回事？
  • A：启动时打印的乱码为boot段代码，请确定串口设置波正确。串口转USB工具请不要使用PL2303，推荐使用CP2102,串口工具minicom中波特率可能无法更改，推荐使用SecureCRT。确定VCC接入电压稳定性。
  • Q：通信串口输入help后无反应是怎么回事？
  • A：可尝试输入“echo on”打开回显，如果返回“ok”则证明通信正常，可再次输入help获取命令列表。通过串口工具通信时，建议打开回显功能，方便查看。
>echo on
<ok

产品固件开发

模组工作原理

MIIO芯片提供一套可读的串口文本命令，供外部芯片调用，MIIO芯片只负责网络通讯，而不关心外部芯片业务逻辑。
主控MCU与模组间使用文本指令通过串口进行交互，模组负责与服务器以Json形式通信，无需MCU关心。

文本命令采用“一问一答”的方式，每条命令，无论执行成功与否，都会返回结果或错误提示。
下文中，示例里的“↑”和“↓”分别代表命令和结果。有时，也称二者为“上行”信息和“下行”信息。因为在涉及到云通信的命令里，“上”代表发往云端，“下”代表从云端发来。

一个典型的上行例子（温度传感器上报温度）：

  1. 传感器探知当前温度为26度
  2. 传感器调用MIIO芯片的props命令，通过MIIO芯片向云端上报温度属性：props temp 26

一个典型的下行例子（手机app打开电源开关）：

  1. 手机app发出打开开关指令
  2. MIIO芯片接收到app的下行消息，并翻译为文本命令：set_power on
  3. 主控MCU不停的使用get_down命令轮询MIIO芯片，得到了set_power on命令
  4. 主控MCU完成电源打开的操作
  5. 主控MCU调用result ok，告知MIIO芯片成功完成
  6. MIIO芯片回复ok，告知结果已收到

关于JSON RPC

当通过云端与设备通信进行调试时，指令将以JSON字符串的形式出现。相关调用规范和返回值请参考：指令调用规范.pdf  

变量，函数的命令风格遵循GNU-C风格，小写字母，下划线分隔就可以了。（拒绝驼峰式...）

WIFI串口命令

WIFI串口命令介绍见串口命令  

注意：模组串口命令均以\r为结尾。

上行指令：get_down，result，error，model，mcu_version，props，restore等。
下行指令：MIIO_mcu_version_req，MIIO_model_req，MIIO_net_change，update_fw。
以上为模组工作必需指令，需要开发者在固件中进行实现。

MCU上电后，需要先使用“model”，“mcu_version”设置model，固件版本号。

固件实现方法

正常工作情况下，设备MCU通过串口与模组进行通信，模组向云端发送或获取信息。

完整接入实现需要MCU通过串口指令与模组进行通信，实现以下功能：

  • 与模组进行交互获取某些信息（如），或控制模组完成某些动作。
  • 模组接收云端下发的方法，通过串口发送至MCU，MCU完成相应动作。
  • MCU需要上报某些属性和方法时，通过相应串口指令发送给模组，模组将其上报至云端。
  • MCU通过串口接收到模组保留的下行指令时，做出相应响应。

MCU及模组正常工作模式为：

  1. 主控MCU根据产品功能定义在内部实现串口通信相关逻辑。
  2. 主控MCU向模组循环发送“get_down”指令，以轮询模式，从模组处获取云端下发的指令。（推荐get_down指令循环周期为200ms）
  3. 若模组回复“down none”，则暂无需要完成的命令，继续使用“get_down”命令轮询模组。
  4. 若模组回复具体指令，则根据获取的下行指令，完成相应操作。
  5. 指令执行后，调用“result”命令向模组发送命令执行结果。模组芯片回复“ok”表示结果已收到。
  6. MCU对于模组的各项操作，均需使用相应串口指令，通过串口与模组通信。
  7. 建议检测属性变化超过一定范围时，使用“props”指令上报当前属性值，不允许正常属性高频率上报。
  8. 当有设定事件（Event）发生时，通过“event”指令上报事件。

固件功能调试

注意：绑定设备所使用的小米账号需在该产品白名单内，否则无法发现设备。

若您的APP端米家扩展程序已经完成主要功能，可以通过APP进行测试。

若您的扩展程序未开发完成，或需要差异测试定位问题，同样可以在开放平台中进行云端调试。

开放平台调试

设备连入账号后，你可以在开发平台>功能调试中看到该设备。
open521
open522
在1处选择测试功能，测试方法和对应指令，并可在2处修改指令。3处发送指令，并可点击“功能定义”进入功能编辑界面。

通过测试功能及方法选择，可以逐条测试固件对于功能的实现情况。

miIO.info是一个基本命令，你随时都可以向设备发送，查询设备的基本信息

产品固件管理

固件平台上传

产品固件完成后，需要在开发平台上进行上传，并注意版本号必须符合平台规范，否则将影响后续固件升级功能。  
open611

固件上传与CRC验证

MCU固件需要尾部添加CRC后再上传，你可以使用我们提供的工具自行添加（甚至可以集成到你的编译脚本里面）。
open612

上传时请认真填写固件信息，其中MCU版本号格式为四位数字。

版本号上报

MCU上电后，设置产品的mcu_version。

>mcu_version 1000
<ok

固件OTA升级

升级流程说明

在MIIO芯片加主控MCU的串口方案中，MIIO芯片通过串口向MCU提供升级功能。升级功能由文本命令触发，并完成握手。数据传输使用了Xmodem协议，以数据全文校验通过表示成功结束，以超时退出表示失败。数据传输中文本命令暂停响应。为完成固件升级任务，MCU需实现如下功能：

  1. MCU的应用固件必须能够识别升级命令，重启进入bootloader
  2. bootloader必须能够完成握手过程
  3. bootloader必须支持Xmodem数据接收，数据块大小为128B
  4. bootloader必须支持Xmodem数据两种校验中的至少一种：校验和 或 CRC
  5. MCU应用固件必须能够在适当时候通过mcu_version命令告知当前固件版本号，一般是一开始
  6. 当MCU接收了不完整的数据（如中途断电），重启后bootloader应该能够发现，并停留在bootloader里的升级握手流程里
  7. 为保证能够从错误中恢复，bootloader应该实现一个固定时长的握手窗口（详见下面）
步骤 MIIO芯片 用户MCU
1 MIIO芯片接到来自网络的升级命令，开始下载用户MCU固件文件到缓冲区，下载完成并交验通过。
2 关闭除升级所需之外的所有文本命令。所剩可执行命令为：get_down,result.对其他所有命令调用都返回error ↑get_down
↓down update_fw
↑result "ready" ↓ok
3 收到result "ready"后，进入Xmodem模式 收到ok后，进入Xmodem模式
4 Xmodem传输 Xmodem接收
5 传输完成，退出Xmodem模式，重新打开所有文本命令，擦除下载缓冲区里的固件 接收完成，校验通过，重启。
6 用mcu_version报告新版本号

注意：

  1. MIIO模组串口命令以“\r”作为结尾，例如“get_down\r”。
  2. MCU通电存在延迟，建议MCU通电1s后发送“get_down”指令获取升级命令。
  3. MIIO模组通过http连接下载固件，同MCU通过Xmodem协议进行数据传输。
  4. 传输数据包为128B，加上Header,Packet Number,CherckSum共计134字节。
  5. 传输最后一个包时，如果有效数据不足128B，则补齐为1A FF FF FF…若128B,则补加一个数据包，数据为1A FF FF
  6. Xmodem传输数据握手时，第一个NAK或C用于确定校验方式，第二个NAK或C开始传输数据。因此超时时间不宜过长。

update

对特殊情况下控制设备不做升级的处理

  1. 定义“ota_state”属性，在设备处于某些工作状态、电量不足或其他等暂时不能升级的状态时，MCU通过串口指令“props ota_state busy”上报属性至服务器，则此时设备不会检查到更新。设备转到可升级状态时，上报“ota_state idle”，则可正常检查更新。
  2. 若在MCU上报ota_state状态前，模组已收到ota指令，可按如下情况处理：正常升级流程中，模组收到服务器ota指令后会下载升级包，下载完成后通过串口向MCU下发update_fw指令，MCU回复“ready”，则正常进入升级流程。若MCU当前状态不可升级，可暂不进行回复，待状态可升级后再正常进入升级流程。

对升级中意外断电的处理

如果升级握手不成功或者在Xmodem传输中意外断电，则MCU没有接收到完整地固件，需要重新传输。在上表中，MIIO下载的MCU固件会有相应的头部标识，通过头部标识可以区分固件种类（wifi固件、app固件或mcu固件），在传输成功后即擦除缓冲区中的头部标识。如果握手不成功或Xmodem传输中意外断电，MIIO没有擦除头部，在上电重启后检测缓冲区中的头部和crc，如果mcu固件的头部和crc校验通过则在MCU bootloader里预留的一个刚上电后的时间窗口里，和MCU握手，使其进入升级流程。为使该机制有效，做如下约定：

  1. MIIO模块与MCU必须同时上电
  2. MIIO模块和MCU上电后，完成最基本的初始化后（要求时间很短，100ms内），进入握手时间窗口，窗口持续1s
  3. MIIO模块在窗口内首先校验下载缓冲区里的MCU固件，包括头信息、CRC，如果校验通过，则进入握手等待
  4. MCU在窗口内，一直快速（间隔小于100ms）向MIIO模块发送get_down，并检查是否有down update_fw

xmodem协议

你可以下载xmodem源代码，然后集成到你的主控MCU当中。

通过开放平台调试

编译好固件，添加CRC32，上传，获取固件的url后，你可以向设备发送如下命令来启动MCU OTA过程：

{"method":"miIO.ota","params": {"mcu_url":"xxxxxxx"},"id":1}

固件测试及上线

固件开发完成后，在开发平台中进行上传并关联此版本固件已实现的功能，你就可以开始进行测试了。
open71

白名单测试时，只有该产品白名单成员能够进行测试，请确定测试成员均在白名单范围中。  

测试完成后，申请上线，等待审核。

返回目录