嵌入式硬件通信接口協(xié)議-UART（五）數據包設計與解析

　　上一節講到起止式SST(Start-Stop-Type)幀結構協(xié)議，該協(xié)議利用幀頭、長(cháng)度、校驗構建幀結構，基于幀結構能實(shí)現對數據包的可靠、準確傳輸。

　　應用層數據包設計思路

　　回到工程本身，幀結構中的數據包才是應用程序最終需要解析使用的，且與具體的業(yè)務(wù)需求有關(guān)。

　　這篇文章將簡(jiǎn)單介紹，在數據包里如何設計應用層的交互指令，從而實(shí)現具體的業(yè)務(wù)需求。分享個(gè)思路，就當拋磚引玉了。

　　類(lèi)似于幀結構，在設計數據包時(shí)，根據交互邏輯的具體需求，同樣采用逐字節組成字段，字段組成數據包，從而完成指令交互。

　　具體到項目中，一般地有目標地址、源地址、指令類(lèi)型、傳輸方向、級聯(lián)序號、參數ID、參數值等等。

　　字段的定義因項目需求而定，以上提及的字段可能存在且不限于此。

　　以下介紹在具體項目中，對數據包設計與解析思路。工程實(shí)踐中方法眾多，相信很多經(jīng)驗嫻熟的老工程師肯定都有各自巧妙的編程思路，歡迎在本頁(yè)留言交流。

　　項目案例

　　基于nRF51822的BLE終端設備，與上位機使用UART通信，物理線(xiàn)路使用USB轉UART。

　　數據包定義

　　類(lèi)型定義

　　參數名&參數值定義

　　根據以上定義，可以為應用程序設計指令解析的結構體，結構體中所定義的類(lèi)型type和參數名para，使用枚舉類(lèi)型定義：

　　常規解析過(guò)程

　　解析函數，一般地會(huì )把輸入參數的 *indata，利用一個(gè)新的結構體指針指向該輸入參數，之后的解析使用結構體指針來(lái)對數據處理，增強代碼可讀性!

　　上述截圖中的定義方式出現了警告，這里需要做個(gè)如下的強制轉換：

　　常規的判斷處理，多采用switch(){case :}聯(lián)合if(...){;}else(...){;}判斷邏輯，這個(gè)模式的判斷處理架構如下：

　　以上的做法，依次去判斷類(lèi)型type、參數名para，然后直接處理。當這兩個(gè)字段的枚舉成員數量少，倒還可以這么判斷;但是如果工程需要擴展、業(yè)務(wù)有了新的需求，那么if(...){;}else(...){;}的逐一判斷將會(huì )使得解析函數里的代碼量巨大!

　　總結有這幾個(gè)缺點(diǎn)：

　　1.業(yè)務(wù)需求有多少個(gè)類(lèi)型或者其他分支，就需要多少個(gè)這樣的判斷邏輯，對于編寫(xiě)代碼變成個(gè)體力活;

　　2.在代碼查看、維護時(shí)，面對的還是羅列了一大堆的switch(){case :}和if(...){;}else(...){;}語(yǔ)句;

　　3.增刪功能時(shí)，需要找到代碼中具體的判斷位置，然后小心翼翼給注釋或者修改掉。

　　這里已經(jīng)沒(méi)有任何的技術(shù)含量，基本上就是復制粘貼判斷語(yǔ)句、修改判斷對象，說(shuō)到底也就是個(gè)查表的過(guò)程!

　　構建查表方式解析

　　既然要查表，當然是有個(gè)while()循環(huán)，然后遞增某一變量來(lái)查表的過(guò)程。在這里，數據包結構體中定義的類(lèi)型type、參數名para，都可以作為查表的對象，該如何選擇?

　　假設：

　　1.以類(lèi)型作為查表對象，假如查表后類(lèi)型等于查詢(xún)參數，那么參數名仍然是個(gè)多個(gè)分支的情況，要么繼續查表要么繼續采用switch(){case :}或者if(...){;}else(...){;}來(lái)判斷眾多不同的參數名;

　　2.以參數名作為查表對象，假如查表后參數名等于設備運行狀態(tài)，那么類(lèi)型需要做最多三種判斷：查詢(xún)、設置、其他。

　　對比以上兩種，必然是第2個(gè)更能提高編程效率、縷清邏輯框架。

　　要查表就要建表，建表的結構體，以參數名para作為被查對象，并且以回調函數的形式執行查表結果。建表如下：

　　說(shuō)是建表，其實(shí)就是定義一個(gè)結構體數組，數組的每個(gè)元素都是結構體類(lèi)型，這里的結構體，主要由數據包協(xié)議的參數名和回調函數組成，定義如下：

　　在執行數據包解析的時(shí)候，查表的思路是：

　　1.先創(chuàng )建一個(gè)表結構的指針*ptable指向表的開(kāi)始位置，也就是指向數組內第一個(gè)元素{ECHO, dcapp_dev_echo}

　　2.再創(chuàng )建一個(gè)數據包結構的指針*pbuf指向輸入數據首地址

　　3.通過(guò)遞增ptable指針，對ptable與pbuf的參數名成員進(jìn)行比對

　　4.最后執行ptable指針對應回調函數

　　以上的思路，放到代碼中，僅僅數行就可以實(shí)現對輸入數據包參數名的解析!高效、清晰!

　　另外，建表時(shí)，把無(wú)效參數名對應的值和對應的回調函數放在最后，這樣做的好處是查完整個(gè)表，無(wú)需區分是否找到對應的參數名，而直接執行指針對應的回調函數即可。

　　這樣即使是未找到參數名，也會(huì )執行表中最后一個(gè)元素，就是錯誤解析的回調函數dcapp_parser_err()。

　　有了這樣一個(gè)查表的處理方式，增刪指令功能就變得簡(jiǎn)單太多了!增加功能，只需要在表中添加參數名和對應的回調函數，刪除某功能，也是回到表中找到對應的參數名和回調函數即可!

　　總結一下，雖然查表方式非常清晰，但是對應的回調函數內部，需要獨自處理和實(shí)現，并且每個(gè)參數名都需要單獨處理。相比于采用switch(){case :}聯(lián)合if(...){;}else(...){;}判斷邏輯，確實(shí)清晰很多。

　　以上的查表思路，來(lái)源于經(jīng)歷的項目，同時(shí)還參考了

　　《STM32CubeExpansion_MEMSMIC1_V1.1》

　　這個(gè)ST官方的數字麥克風(fēng)開(kāi)源項目示例，作為USB音頻設備時(shí)，類(lèi)似的回調函數方式：

　　調試截圖

　　正確解析了數據包的參數名之后，對應的函數執行結果是打印輸出調試信息，如下截圖：

　　以上是初步的解析效果，可以通過(guò)回調函數，正確地跳轉到對應的函數執行。具體的處理仍需要針對項目的業(yè)務(wù)需求而設計，在此不做更多的延伸。