今天重點給大家分析下機智云整個程序的數(shù)據(jù)格式，機智云運行這么穩(wěn)定得益于整個數(shù)據(jù)格式合理規(guī)范命名，我們直接進入主題

首先定義了一個數(shù)據(jù)類型為gizwitsProtocol_t 的全局變量，如下

/** 協(xié)議全局變量 **/

gizwitsProtocol_t gizwitsProtocol;

我們追蹤下結構體的定義

__packed typedef struct

{

uint8_t issuedFlag;

uint8_t protocolBuf［MAX_PACKAGE_LEN］;

uint8_t transparentBuff［MAX_PACKAGE_LEN］;

uint32_t transparentLen;

uint32_t sn;

uint32_t timerMsCount;

uint32_t lastReportTime;

protocolWaitAck_t waitAck;

eventInfo_t issuedProcessEvent; //控制事件

eventInfo_t wifiStatusEvent; //WIFI狀態(tài) 事件

volatile gizwitsReport_t lastReportData;

gizwitsIssued_t issuedData; //云端下發(fā)控制報文數(shù)據(jù)

moduleStatusInfo_t wifiStatusData; //WIFI 狀態(tài)信息（信號強度）

}gizwitsProtocol_t;

之前一直沒見過__packed，百度下才知道__packed是字節(jié)對齊的意思， 比如說int float double char它的總大小是4 + 4 + 8 + 1 = 17

但如果不用__packed的話，系統(tǒng)將以默認的方式對齊（假設是4字節(jié)），那么它占4 + 4 + 8 + 4 = 20；（不足4字節(jié)以4字節(jié)補齊）。

這里主要定義了一些gizwits協(xié)議的下發(fā)報文標志、緩沖區(qū)、數(shù)據(jù)長度、sn、系統(tǒng)時間、上次上報數(shù)據(jù)的時間、重發(fā)機制定義、控制事件、WiFi狀態(tài)事件、上次上報的數(shù)據(jù)、云端下發(fā)的控制報文以及WiFi狀態(tài)信息這些數(shù)據(jù)的定義，這里我們重點關注幾個就行了。

首先是 gizwitsIssued_t ，這個結構體里面定義了2個結構體，一個是控制功能Flag，一個是對應的Value，如下所示

__packed typedef struct {

attrFlags_t attrFlags;

attrVals_t attrVals;

}gizwitsIssued_t;

__packed typedef struct {

uint8_t LED_OnOff:1;

uint8_t LED_Color:1;

uint8_t LED_R:1;

uint8_t LED_G:1;

uint8_t LED_B:1;

uint8_t Motor_Speed:1;

}attrFlags_t;

__packed typedef struct {

uint8_t LED_OnOff:1;

uint8_t LED_Color:2;

uint8_t reserve:5;

uint8_t LED_R;

uint8_t LED_G;

uint8_t LED_B;

uint16_t Motor_Speed;

}attrVals_t;

我們看到，有LED_OnOff、LED_Color、LED的RGB值，以及電機轉(zhuǎn)速這6個功能可以被控制，那么這個結構體是在哪里被賦值的呢？我們這主函數(shù)的while循環(huán)中找到gizwitsHandle這個函數(shù)，進去之后追蹤到protocolGetOnePacket這個函數(shù)，這個函數(shù)就是從gizwits的接收緩沖中拿一個完整的數(shù)據(jù)包出來，不懂的可以結合我們第二講的串口環(huán)形buff，進去一看就明白了。好，到這里我們就接到一幀從WiFi模塊發(fā)送到MCU的信號幀了，協(xié)議是將接收的數(shù)據(jù)放gizwitsProtocol的protocolBuf這個數(shù)組的，我們接著往下看，

recvHead = （protocolHead_t*）gizwitsProtocol.protocolBuf;

我們往上看recvHead的定義，是一個protocolHead_t的指針，顧名思義，這個應該是協(xié)議頭，我們進去看看

/******************************************************

* 協(xié)議標準頭

********************************************************/

__packed typedef struct

{

uint8_t head［2］;

uint16_t len;

uint8_t cmd;

uint8_t sn;

uint8_t flags［2］;

} protocolHead_t;

協(xié)議頭包括5部分，包頭header固定為0xFFFF，len指從cmd開始到整個數(shù)據(jù)包結束所占用的字節(jié)，命令字節(jié)cmd表示具體的命令定義，sn由發(fā)送方給出，原路返回就是，標志位flag默認0，之后便是數(shù)據(jù)區(qū)與校驗和了，這里將gizwitsProtocol.protocolBuf強制轉(zhuǎn)換成protocolHead_t格式 賦給recvHead ，之后就可以通過recvHead 調(diào)用協(xié)議頭的各項成員數(shù)據(jù)了，然后通過recvHead-》cmd判斷相應的命令進去相應的語句中去執(zhí)行不同的命令，這里我們看下CMD_ISSUED_P0，這個的意思是命令為WiFi向MCU發(fā)送數(shù)據(jù)的命令，我們繼續(xù)執(zhí)行，來到protocolIssuedProcess這個函數(shù)，進去之后，我們看看數(shù)據(jù)是怎么定義的

protocolReport_t *protocolIssuedData = （protocolReport_t *）inData;

首先，將gizwitsProtocol.protocolBuf強制轉(zhuǎn)換成protocolReport_t這個類型的指針，我們看看protocolReport_t的定義，看表面，應該是協(xié)議上報數(shù)據(jù)格式的定義

__packed typedef struct

{

protocolHead_t head;

actionType_t action;

gizwitsReport_t reportData;

uint8_t sum;

} protocolReport_t;

這里包括協(xié)議頭、動作、上報數(shù)據(jù)與校驗和四部分，我們重點看看gizwitsReport_t，其定義為

__packed typedef struct {

devStatus_t devStatus;

}gizwitsReport_t;

__packed typedef struct {

uint8_t LED_OnOff:1;

uint8_t LED_Color:2;

uint8_t reserve_0:5;

uint8_t LED_R;

uint8_t LED_G;

uint8_t LED_B;

uint16_t Motor_Speed;

uint8_t Infrared:1;

uint8_t reserve_1:7;

uint8_t Temperature;

uint8_t Humidity;

uint8_t Alert_1:1;

uint8_t Alert_2:1;

uint8_t reserve_2:6;

uint8_t Fault_LED:1;

uint8_t Fault_Motor:1;

uint8_t Fault_TemHum:1;

uint8_t Fault_IR:1;

uint8_t reserve_3:4;

}devStatus_t;

這個結構體的定義符合了MCU 主動發(fā)送狀態(tài)時或者回復 wifi 模塊的狀態(tài)查詢時攜帶 p0 命令和完整數(shù)據(jù)區(qū) 之后，issuedAction = protocolIssuedData-》action;通過issuedAction 判斷 P0 command 命令碼，這里我們進入ACTION_CONTROL_DEVICE，將P0區(qū)的數(shù)據(jù)轉(zhuǎn)換成事件格式，由下面這行代碼實現(xiàn)

dataPoint2Event（（gizwitsIssued_t *）（inData+sizeof（protocolP0Head_t））， &gizwitsProtocol.issuedProcessEvent）;

這個函數(shù)將P0數(shù)據(jù)區(qū)的數(shù)據(jù)強制轉(zhuǎn)換成gizwitsIssued_t格式的數(shù)據(jù)，也就是我們上面介紹的事件Flag和事件Value。 我們還看到有一個gizwitsProtocol.issuedProcessEvent作為實參傳到函數(shù)中，這個也是在gizwitsProtocol_t結構體中定義的，我們看下其結構體定義

__packed typedef struct {

uint8_t num;

uint8_t event［EVENT_MAX］;

}eventInfo_t;

這個結構體將上面?zhèn)魅氲臄?shù)據(jù)轉(zhuǎn)換成相應的時間格式，每個num對應一個事件，處理完之后直接進入對應num處理對應時間就OK了。

處理完這些之后，將gizwitsProtocol.issuedFlag置1， 然后判斷gizwitsProtocol.issuedFlag，進入下面函數(shù)

if（1 == gizwitsProtocol.issuedFlag）

{

gizwitsProtocol.issuedFlag = 0;

eventProcess（&gizwitsProtocol.issuedProcessEvent， （uint8_t *）&gizwitsProtocol.issuedData， sizeof（gizwitsIssued_t））;

memset（（uint8_t *）&gizwitsProtocol.issuedProcessEvent，0x0，sizeof（gizwitsProtocol.issuedProcessEvent））;//WORK_DONE

}

接下來就看到控制LED的實際出處了

case SetLED_OnOff：

if（LED_OnOn == issuedData-》attrVals.LED_OnOff）

{

reportData.devStatus.LED_OnOff = LED_OnOn;

ledRgbControl（254，0，0）;

}

else

{

reportData.devStatus.LED_OnOff = LED_OnOff;

ledRgbControl（0，0，0）;

}

下面的處理函數(shù)大家就都可以看懂了，可能講的有點亂，但是如果跟著代碼看的話還是很容易理解的，我們看下面這幅圖就一目了然了，我將協(xié)議中所有的結構體定義以及連接關系都詳細的標注出來不了，參考這個理解會事半功倍！