做嵌入式項目的工程師，幾乎天天和 “協議” 打交道。小到傳感器數據讀取，大到多設備協同控制，只要設備需要通訊，就離不開協議。

很多人覺得協議設計很簡單，無非就是設計個報文格式。但實際項目里，明明是簡單場景，卻總出現 “設備連不上”“數據傳丟了”“新老設備不兼容” 的問題。其實不是協議難，而是沒抓住設計的核心規律。今天就用大白話，跟大家聊聊協議設計那些事兒。

一、別只盯著 “當下能用”，忘了 “以后要改”

最常見的坑，就是設計時只考慮 “現在的需求夠不夠用”，完全沒給后續升級留余地。

比如某工程師設計了一個溫度采集協議，報文里只包含 “設備地址 + 溫度值”，當下用著沒問題。可半年后需要增加 “濕度采集” 功能，新設備發的報文里多了濕度字段，老設備根本不認識，直接報錯；反過來，老設備發的報文沒有濕度字段，新設備也不知道該怎么處理。

更頭疼的是，協議里沒加 “版本號”，連 “誰是老版本、誰是新版本” 都分不清，最后只能靠硬件升級解決，又費錢又費時間。

避坑小技巧：

設計協議時，先加個 “版本號” 字段（比如 1 個字節，01 代表 V1，02 代表 V2），握手時先確認版本，新版本設備自動兼容老版本邏輯。

報文里留 1-2 個 “預留字段”，后續加功能時直接用，不用改整體格式。

二、別迷信 “理論模型”，要貼合 “物理層特性”

學過 OSI 七層模型的工程師，設計協議時容易 “飄在高層”，忽略了底層物理層的特點 —— 比如用的是 RS485 還是 Ethernet，這些硬件特性直接決定了協議能不能跑通。

舉個真實案例：某項目用 RS485 半工通訊（半工就是設備不能同時收發數據，只能 “你說我聽，我說你聽”），主機給從機發 “保存數據” 命令，要求從機保存完再回復。結果從機保存數據要 5 秒，這 5 秒里其他從機都得等著，整個系統反應變慢。

后來改了邏輯：從機收到命令后，先立刻回復 “收到了”，讓主機去處理其他設備；等保存完數據，再等主機 “點名查詢” 時，再回復 “保存成功 / 失敗”。一下子就解決了效率問題。

不同物理層有不同的 “脾氣”，設計時得順著來：

RS485/RS232：半工為主，別讓設備 “同時說話”，重要數據發完最好確認一下。

I2C：大多用在板級（比如主板上的芯片通訊），信號穩定，不用額外加復雜校驗。

Ethernet/CAN：支持多設備同時發數據（底層會自動處理沖突），緊急情況可以 “主動上報”，不用等主機點名。

三、容錯和效率要平衡，別顧此失彼

協議設計有兩個核心訴求：一是 “數據要靠譜”（容錯），二是 “傳輸要快”（效率），這兩者往往是矛盾的，得找到平衡點。

比如校驗方式的選擇：

奇偶校驗最簡單，計算快，但只能查出一部分錯誤；

CRC 校驗能查出幾乎所有錯誤，但計算量大，在低端 CPU 上可能拖慢速度。

如果是傳輸 “設備狀態” 這類短報文，用奇偶校驗就夠了；但如果是傳輸 “固件升級包” 這種長數據，就得用 CRC，不然數據錯了都不知道。

再說說效率問題：RS485 用 9600 波特率時，1 秒最多傳 960 個字節，要是報文里全是 “幀頭、幀尾、地址” 這些 “無用信息”，真正的有效數據沒多少，效率就很低。

優化小技巧：

常用的報文盡量設計成 “定長”，比如控制命令統一用 16 字節，接收時不用判斷 “什么時候算收完”，直接讀 16 字節就行，速度更快。

長數據（比如固件包）拆成定長小報文，哪一段傳錯了，只重發那一段，不用整個重發。

Ethernet 別濫用廣播：雖然廣播方便，但發多了會造成 “廣播風暴”，整個網絡都會變卡，盡量用 “單播”（點對點發）。

最后總結：協議設計不是 “寫報文”，是 “設計系統”

很多人覺得協議就是 “報文格式”，其實不然。一個好的協議，要考慮 “現在能用、以后能改、底層適配、容錯高效”，本質是設計一套 “設備間的溝通規則”。

記住三個核心：

1.留版本號，給升級留余地；

2.貼合物理層，別跟硬件 “對著干”；

3.平衡容錯和效率，別走極端。