關注、星標公眾號，直達精彩內容

嵌入式設備在運行中需要設置參數，這個工作經常由PC機來實現，需要為雙方通信設計協議，有代表性協議是如下三種：

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

一． 簡單性

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

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

二． 可擴展

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

三． 低耦合

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

四． 穩定性

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

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

五． 高效率

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

將同種操作編碼為一個子集是一種高效手段，如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(換行符)。

-END-

|?整理文章為傳播相關技術，版權歸原作者所有?|

|?如有侵權，請聯系刪除?|

往期好文合集

市場瘋了？ST明年起全線漲價

嵌入式的坑在哪方面?

“2020年嵌入式軟件秋招經驗和對嵌入式軟件未來的一點思考”

??最 后??

?

若覺得文章不錯，轉發分享，也是我們繼續更新的動力。

5T資源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，PCB、FPGA、DSP、labview、單片機、等等！

在公眾號內回復「更多資源」，即可免費獲取，期待你的關注~

總結

以上是生活随笔為你收集整理的三种常见嵌入式设备通信协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。