嵌入式開發在很多場景下都需要進行通訊，那么通訊協議就必不可少，有代表性的通訊協議是如下三種：

從上表可以看到，一般嵌入式設備內存和運算性能都有限，因此固定二進制是首選通信協議。

一． 簡單性

保證協議是一個簡單的方案，晦澀難懂往往意味著實現困難和容易出錯。協議的結構宜采用平面方式，每個域作用明確，數據域盡可能設計得長度和位置固定，注釋詳盡，文檔清晰，實例豐富，讓人盡快上手和理解。

協議一般都需要以下域：幀頭，長度，幀類型，目標地址，源地址，數據，校驗，幀尾。

二． 可擴展

必須保證將來增加功能和更改硬件后協議仍能勝任工作，這往往是通過預留空間來實現，協議的變更應該只是量的增加，不至于引起協議結構的變化。

三． 低耦合

理想情況下每個協議包是原子信息，即本協議包不與其他協議包牽連，以防止通訊丟幀和設置牽連帶來的錯誤。

四． 穩定性

協議包長度適宜：太小包含的信息過少，協議包的種類繁多，容易引起通訊混亂和牽連錯誤；太大包含的信息過多，可讀性較差，組幀和解幀的工作困難，還會帶來通訊易受干擾的缺陷，一般協議長度以最小原子性信息為標尺。

協議必須包括校驗機制，以便于接收方判別協議包正確完整接收，如果出錯需要較好的機制來確保通訊成功（如重傳）。

五． 高效率

按信息類型區分協議包類別，如：設置網絡信息參數，設置當前運行參數，可以區分開來，方便程序處理。

將同種操作編碼為一個子集是一種高效手段，如Read操作，編碼為0x0010，Write操作，編碼為0x0020。

數據盡可能設計成同構模式，如果實在有差異，至少將同類型數據放置在一起，這樣程序可以充分利用指針和線性尋址加速處理。

六． 易實現

盡量減少復雜算法的使用，如，通訊鏈路穩定，數據幀的校驗碼可以由CheckSum代替CRC。除非資源非常緊張，否則不要將過多的信息擠壓在一個數據里，因為它會帶來可讀性差和實現困難。

七．軟件開發

盡可能地讓硬件ISR完成驅動工作，不要讓“進程”參與復雜的時序邏輯，否則處理器將步履蹣跚且邏輯復雜！如：

接收固定長度的數據幀，可以使用DMA，每接收完一幀DMA_ISR向進程發消息。小心處理DMA斷層異常（接收的數據幀長度正常但數據錯誤，數據為上幀的后半部分+本幀的前半部分）。

接收不定長的數據幀，可以使用狀態機，當接收到“幀尾數據”時向進程發消息。小心數據紊亂和超時異常（數據紊亂時需要將狀態機及時復位，超時一般使用定時器監控）。

八. 考慮硬件

如果通信鏈路是高速總線（如SPORT可達100Mbps），一般設計成一幀產生一次中斷，它通過長度觸發的DMA來實現，需要將協議設計成固定長度，如附錄A。它具備高效率，但靈活性較差。

如果通信鏈路是低速總線（如UART一般100kbps），一般接收一字節產生一次中斷，可以將協議設計成變長幀，如附錄B。它具備高靈活性，但效率較低。

上圖顯示了PC發送數據幀的格式，總長為64字節，是4字節的整倍數，符合絕大部分32位處理器結構體對齊的特性。

0x3C：INT8U，幀頭，可見字符’<’

Len：INT8U，本幀的總數據長度，在圖4即為64

Dst：INT8U，標識目標設備的ID號

Src：INT8U，標識源設備的ID號

Data：56字節的存儲區，內容依賴于具體的通信幀（實例見表2）

Cmd：INT16U，數據幀的類別

CS：INT8U, 對它前面所有數據（62字節）進行8位累加和校驗

0x7D：INT8U, 幀尾，可見字符’｝’

Data域數據結構實例：

一個基于變長格式的UART通信協議實例：

PC與iWL880A（一種無線通信產品，詳見www.rimelink.com）通信幀采用變長格式，如下圖所示。大部分設備（常見為PC機）對于接收以“回車符”的機制很好處理，協議中的Tail就等于0x0D(換行符)。

審核編輯：湯梓紅