摘要：很多人觉得协议设计很简单，无非就是设计个报文格式。但实际项目里，明明是简单场景，却总出现 “设备连不上”“数据传丢了”“新老设备不兼容” 的问题。其实不是协议难，而是没抓住设计的核心规律。今天就用大白话，跟大家聊聊协议设计那些事儿。
做嵌入式项目的工程师，几乎天天和 “协议” 打交道。小到传感器数据读取，大到多设备协同控制，只要设备需要通讯，就离不开协议。
很多人觉得协议设计很简单，无非就是设计个报文格式。但实际项目里，明明是简单场景，却总出现 “设备连不上”“数据传丢了”“新老设备不兼容” 的问题。其实不是协议难，而是没抓住设计的核心规律。今天就用大白话，跟大家聊聊协议设计那些事儿。
最常见的坑，就是设计时只考虑 “现在的需求够不够用”，完全没给后续升级留余地。
比如某工程师设计了一个温度采集协议，报文里只包含 “设备地址 + 温度值”，当下用着没问题。可半年后需要增加 “湿度采集” 功能，新设备发的报文里多了湿度字段，老设备根本不认识，直接报错；反过来，老设备发的报文没有湿度字段，新设备也不知道该怎么处理。
更头疼的是，协议里没加 “版本号”，连 “谁是老版本、谁是新版本” 都分不清，最后只能靠硬件升级解决，又费钱又费时间。
避坑小技巧：
设计协议时，先加个 “版本号” 字段（比如 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 别滥用广播：虽然广播方便，但发多了会造成 “广播风暴”，整个网络都会变卡，尽量用 “单播”（点对点发）。
很多人觉得协议就是 “报文格式”，其实不然。一个好的协议，要考虑 “现在能用、以后能改、底层适配、容错高效”，本质是设计一套 “设备间的沟通规则”。
记住三个核心：
来源：硬件十万个为什么
