做嵌入式项目的工程师，几乎天天和 “协议” 打交道。小到传感器数据读取，大到多设备协同控制，只要设备需要通讯，就离不开协议。

许多人觉得协议设计很简单，无非就是设计个报文格式。但实际项目里，明明是简单场景，却总出现 “设备连不上”“数据传丢了”“新老设备不兼容” 的问题。实则不是协议难，而是没抓住设计的核心规律。今天就用大白话，跟大家聊聊协议设计那些事儿。

一、别只盯着 “当下能用”，忘了 “后来要改”

最常见的坑，就是设计时只思考 “目前的需求够不够用”，完全没给后续升级留余地。

列如某工程师设计了一个温度采集协议，报文里只包含 “设备地址 + 温度值”，当下用着没问题。可半年后需要增加 “湿度采集” 功能，新设备发的报文里多了湿度字段，老设备根本不认识，直接报错；反过来，老设备发的报文没有湿度字段，新设备也不知道该怎么处理。

更头疼的是，协议里没加 “版本号”，连 “谁是老版本、谁是新版本” 都分不清，最后只能靠硬件升级解决，又费钱又费时间。

避坑小技巧：

1. 设计协议时，先加个 “版本号” 字段（列如 1 个字节，01 代表 V1，02 代表 V2），握手时先确认版本，新版本设备自动兼容老版本逻辑。

2. 报文里留 1-2 个 “预留字段”，后续加功能时直接用，不用改整体格式。

二、别迷信 “理论模型”，要贴合 “物理层特性”

学过 OSI 七层模型的工程师，设计协议时容易 “飘在高层”，忽略了底层物理层的特点 —— 列如用的是 RS485 还是 Ethernet，这些硬件特性直接决定了协议能不能跑通。

举个真实案例：某项目用 RS485 半工通讯（半工就是设备不能同时收发数据，只能 “你说我听，我说你听”），主机给从机发 “保存数据” 命令，要求从机保存完再回复。结果从机保存数据要 5 秒，这 5 秒里其他从机都得等着，整个系统反应变慢。

后来改了逻辑：从机收到命令后，先立刻回复 “收到了”，让主机去处理其他设备；等保存完数据，再等主机 “点名查询” 时，再回复 “保存成功 / 失败”。一下子就解决了效率问题。

不同物理层有不同的 “脾气”，设计时得顺着来：

• RS485/RS232

  ：半工为主，别让设备 “同时说话”，重大数据发完最好确认一下。

• I2C

  ：大多用在板级（列如主板上的芯片通讯），信号稳定，不用额外加复杂校验。

• Ethernet/CAN

  ：支持多设备同时发数据（底层会自动处理冲突），紧急情况可以 “主动上报”，不用等主机点名。

三、容错和效率要平衡，别顾此失彼

协议设计有两个核心诉求：一是 “数据要靠谱”（容错），二是 “传输要快”（效率），这两者往往是矛盾的，得找到平衡点。

列如校验方式的选择：

• 奇偶校验最简单，计算快，但只能查出一部分错误；

• CRC 校验能查出几乎所有错误，但计算量大，在低端 CPU 上可能拖慢速度。

如果是传输 “设备状态” 这类短报文，用奇偶校验就够了；但如果是传输 “固件升级包” 这种长数据，就得用 CRC，不然数据错了都不知道。

再说说效率问题：RS485 用 9600 波特率时，1 秒最多传 960 个字节，要是报文里全是 “帧头、帧尾、地址” 这些 “无用信息”，真正的有效数据没多少，效率就很低。

优化小技巧：

1. 常用的报文尽量设计成 “定长”，列如控制命令统一用 16 字节，接收时不用判断 “什么时候算收完”，直接读 16 字节就行，速度更快。

2. 长数据（列如固件包）拆成定长小报文，哪一段传错了，只重发那一段，不用整个重发。

3. Ethernet 别滥用广播：虽然广播方便，但发多了会造成 “广播风暴”，整个网络都会变卡，尽量用 “单播”（点对点发）。

最后总结：协议设计不是 “写报文”，是 “设计系统”

许多人觉得协议就是 “报文格式”，实则不然。一个好的协议，要思考 “目前能用、后来能改、底层适配、容错高效”，本质是设计一套 “设备间的沟通规则”。

记住三个核心：

1. 留版本号，给升级留余地；

2. 贴合物理层，别跟硬件 “对着干”；

3. 平衡容错和效率，别走极端。