嵌入式設備在運行中需要設置參數，設備這個工作經常由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(換行符)。
免責聲明：本文來源網絡，免費傳達知識，版權歸原作者所有。如涉及作品版權問題，請聯系我進行刪除。
最后
以上就是本次的分享，如果覺得文章不錯，轉發、在看，也是我們繼續更新的動力。
猜你喜歡：
干貨 | 結構體、聯合體嵌套使用的一些實用操作
2020年精選原創筆記匯總
1024G 嵌入式資源大放送！包括但不限于C/C++、單片機、Linux等。在公眾號聊天界面回復1024，即可免費獲取！
免責聲明：本文內容由21ic獲得授權后發布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
