★ FEATURED ARTICLE 做嵌入式、搞电子开发的朋友十有八九会碰到这样一个问题设备之间要通信走什么协议Modbus、CANopen这些公开协议要么偏重、要么格式不太贴自己的场景很多时候最顺手的方案就是自己定义一套规则。这也就是圈子里常说的“黑通道协议”——一段只有通信双方内部约定好、对外不公开的私有通信链路。“黑”这个字说的是协议实现对外像黑盒一样不可见别人只能抓到物理层波形但解析不出你的业务数据它跟任何灰色操作都没有关系。可以先给个明确结论自定义黑通道协议完全可行而且这是嵌入式开发、工控设备、消费电子内部通信里非常成熟的做法。只要物理层用的是稳定的串口、SPI、CAN这类标准电气连接数据链路层往上帧头怎么设、校验怎么做、重传怎么定、加不加密都是你自己说了算。这篇文章我会从“为什么需要自定义协议”讲起一路拆到帧结构设计、收发代码实现、常见坑位排查最后再聊点让私有通道更可靠、更“黑”的加固思路。适合刚开始做通信协议设计、或者正被串口粘包半包折磨的朋友参考。1. 黑通道协议到底是什么我们为什么需要自己定义1.1 “黑通道”的准确画像很多人第一次听到“黑通道协议”会以为是什么隐藏技巧其实就是指私有协议。通信双方各自持有同一套协议约束文档这套文档不在任何公开标准里设备之间按照这套“内部规矩”收发数据。帧头的字节含义、数据字段的顺序、校验算法、应答时序都由设计者自己预先定义接收方拿到一串字节后按照规则逐段拆解。跟公开协议相比黑通道协议最大的特征是“按需定制”。Modbus RTU的确在工控领域遍地都是但它一个报文里功能码、寄存器地址、数据区是固定排布的CANopen的OD对象字典确实管理能力很强但要想真正用起来至少要啃一遍将近几百页的规范文档。可现实场景往往很轻一个单片机采集温度另一个单片机接收并控制风扇中间只是几十字节的往来用Modbus不是不行但总有种“杀鸡用牛刀”的别扭感——报文里塞了一堆你根本用不上的字段调试复杂度还上来了。自定义协议真正解决的问题是“精确匹配需求”。我有多少个传感器数据要传就分配多少个字节我要几种控制指令就划分几个类型号我担心数据被干扰就自己挑一种够用的校验算法。链路越简单、越封闭、越可控这种自定义方案就越有优势。1.2 什么场景该用什么场景千万别碰自定义不是万能的我见过不少工程师一上来就自创协议结果设备要跟第三方的上位机对接对面根本不认最后不得不返工改标准协议。这里有一条很实用的判断线通信两端是否都由你掌控、或者协议的开发者和使用者是同一拨人。适合自定义的场景有这么几类板级通信例如MCU和Wi-Fi模组之间通过串口交换数据模组固件也是自己烧录的。同一产品内部的传感器节点汇总主控板和各从板之间交互协议由自己的研发团队定义。给特定客户定制的成套设备客户只关心“能用”不会去拆你的通信细节。有保密需求不想让外部轻易看懂交互内容的场合。不适合自定义的场景也很明确需要满足多厂商混用的工控现场不同品牌的PLC和仪表互联这时候老老实实走公开标准哪怕文档再厚也得啃或者你的产品要过某些行业的互通性认证那协议必须符合规范几乎没有私有空间。用一句俗话总结你的地盘你做主别人的地盘按别人的规矩来。1.3 自定义协议的代价很多人一开始没想清楚“自由”是有成本的自定义协议最大的代价不是写代码而是“沟通成本”。协议本质是双方甚至多方的事只要有另一方就必须有一份书写清晰的协议文档定义清楚所有字段、边界和时序。我见过太多小型项目两个人口头定了帧格式代码里注释也懒得写半年后设备出问题对着串口抓包谁也看不懂当初的设计意图。另一个代价是测试成本。用标准协议市面上有现成的调试工具和测试用例用私有协议你得自己写上位机脚本模拟对端自己构造异常帧去测边界。这两块工作量在排期时经常被低估。所以自定义协议之前先想清楚不是“能不能”而是“值不值”。2. 动手设计协议帧结构、校验、超时一个都不能少2.1 设计前先列需求清单别急着写码协议设计最忌讳“先写代码再看看”。我用过最省事的方法是先在一张纸上把所有约束条件列清楚再在这个框架下填内容。需要明确的问题至少有这几项通信方向半双工还是全双工比如常见串口UART是单通道同一时刻只能一方说话。数据量级一次交互传几个字节还是几十上百个字节这决定长度字段占几位。实时性要求数据多久要到达对端这决定要不要做分包和实时通道。可靠性要求链路环境是否恶劣干扰大不大这决定校验强度。节点数量是点对点还是主机带多个从机这决定要不要在帧里加地址字段。硬件资源MCU的RAM/Flash有多少这决定缓冲区能开多大也决定能用多重的校验算法。把这些答案写下来协议的大致轮廓就出来了。举个例子一块主控板带五个温湿度传感器节点每个节点的数据量很小一共就是温度两字节、湿度两字节。那帧里不需要地址吗需要的因为主机要区分数据来自哪个节点但如果是一对一链路地址字段就可以省掉能少传一字节是一字节。2.2 帧头怎么选这里面大有讲究帧头是接收方识别一帧开始的标志选不好后面全是坑。最普通的做法是固定一个字符比如0xAA但单字节帧头有个致命问题如果数据区里恰好出现0xAA而前面的信息又不完整接收方就可能把数据字节误认为帧头后面整个解析就错位了。所以工程上普遍用“双字节帧头”比如连续收到0xA5 0x5A才认为一帧开始。双字节的好处是误判概率从1/256降到1/65536对大多数噪声环境已经够用。帧头取值还有讲究尽量选不容易出现在高频噪声里的组合同时避免和帧内常用数据撞车。业界常见的0xAA 0x55补码对因为太对称在某些带校验线反转的链路上容易整帧被识别反我习惯用0xA5 0x5A这两个字节在二进制上互为“频率均衡”组合干扰环境下的误触发概率更低。如果链路里传的数据本身也可能频繁出现帧头就需要额外手段要么在数据区做“转义”遇到帧头字节前插入转义符接收后再还原类似HDLC的做法要么干脆不依赖固定帧头而是用预设长度和定时器来切分帧。第一种适合长数据帧第二种适合短固定帧需要自己权衡。2.3 字段设计类型、长度、数据、校验的排布逻辑一份典型的自定义帧大概长这样帧头 帧类型 数据长度 数据区 校验。每个字段都有存在的理由。帧类型用来区分这帧是心跳、是数据上报、还是命令下发。用一字节定义最多256种一般项目几十种就顶天了如果不加类型字段接收方拿到数据都不知道该往哪个业务逻辑里送等于寄了封信没写标题。数据长度字段告诉接收方数据区有多大。它和状态机配合是解决“半包粘包”问题的关键。有了长度字段接收方就知道还需要等多少字节才能凑齐一帧。长度的位数取决于数据区上限我用一字节做长度数据区就最多255字节实际上我会给它留安全余量数据上限设在240字节防止内存边界问题。校验字段是自定义协议里最容易偷懒又最不该偷懒的部分。最简单的累加和所有字节加起来取低八位确实能防一部分误码但两个字节错位互换它就发现不了。稍微好一点的是CRC16两个字节能检出几乎所有的单比特和双比特错误在串口链路上性价比极高。更强的CRC32多用在可靠性要求极高的场合代价是多占两个字节的带宽。下面是一张我自己项目里用过的协议模板可以直接抄去改字段长度说明帧头11B固定0xA5帧头21B固定0x5A帧类型1B0x01心跳0x02数据上报0x03命令下发数据长度1B数据区字节数上限0xF0数据区N B业务数据长度由上一字段决定CRC162B校验范围从“帧类型”到“数据区末尾”低字节在前2.4 超时、重传、心跳让链路真正可靠帧设计完协议还缺一层“行为约定”。串口通信不是每次都一帆风顺数据在物理链路上可能被电磁干扰打碎可能因为双方时钟偏差丢位也可能某一方死机后通信中断。可靠的链路协议需要三套机制心跳机制。设备空闲时定时发一个心跳帧告诉对方“我还活着”。接收方如果超过N个心跳周期没收到任何数据就判定链路中断可以报警或者自动进入重连逻辑。心跳周期不宜太短太短浪费带宽我一般按下位机任务调度周期来定常见10秒一个心跳。超时重传机制。对于命令帧发送方发出后必须等对方回一个应答帧。如果超过设定的超时时间没收到应答就重发重发次数一般限制3次超过就报链路异常。超时时间不能拍脑袋定要根据链路最长往返时间乘上系数。串口波特率9600时一个字节大约1ms一帧二十字节的往返加上对方处理时间超时设500ms到1秒是比较宽裕的。乱序处理机制。如果链路是多帧连续传输帧处理的顺序很重要。可以在帧里加一字节序列号每发一帧加一接收方拿序列号判断是否漏帧。这个机制用上之后排查丢包问题会省力很多。3. 一个可直接复用的收发实现从封包到状态机解析3.1 先定协议规范再写代码设计完协议后我习惯把规范写成一张表格直接放进代码仓库方便所有人查阅。下面是我近期项目里用的一个简化版规范我拿它做例子。帧类型值数据区内容心跳帧0x01无数据长度0传感器上报0x02节点号1B 温度2B 湿度2B命令下发0x03目标节点1B 命令码1B协议收发代码我会分成两个独立模块封包函数负责构造发送帧解析状态机负责从字节流里切出完整一帧。这两块分开写后续加新命令时不会互相影响。3.2 发送端封包C语言最容易写错的是CRC范围发送端逻辑不复杂但有两个容易出错的地方一个是CRC计算的范围另一个是输出字节顺序。下面这段是我实际用的封包代码。#include stdint.h #include string.h #define FRAME_HEAD1 0xA5 #define FRAME_HEAD2 0x5A #define FRAME_DATA_MAX 240 static uint16_t crc16_update(uint16_t crc, uint8_t byte) { int i; crc ^ byte; for (i 0; i 8; i) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } return crc; } static uint16_t crc16_buf(const uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; while (len--) crc crc16_update(crc, *buf); return crc; } int frame_build(uint8_t *out, uint8_t type, const uint8_t *data, uint8_t len) { uint16_t crc; if (out NULL || (len 0 data NULL)) return -1; if (len FRAME_DATA_MAX) return -1; out[0] FRAME_HEAD1; out[1] FRAME_HEAD2; out[2] type; out[3] len; if (len 0) memcpy(out[4], data, len); /* 注意CRC范围是帧类型长度数据帧头不参与校验 */ crc crc16_buf(out[2], len 2); out[4 len] (uint8_t)(crc 0xFF); out[5 len] (uint8_t)(crc 8); return 6 len; }这里必须强调CRC校验范围从“帧类型”开始到“数据区末尾”结束帧头故意不参与计算。原因有两个一是帧头本身是固定数不参与校验不损失校验强度二是接收端在状态机里还没完整识别帧头之前就开始累计CRC的话逻辑会变得复杂容易把帧头中可能出现的伪数据也混进计算里。至于低字节在前这是我在协议文档里直接写死的字节序约定。不同项目可能选高字节在前没有对错但一旦选了全链路必须统一否则双方CRC永远校验不过。3.3 接收端状态机解决粘包和半包的核心武器接收端是有技术含量的一步。串口数据到达不像是一次性的一帧底层驱动很可能是几个字节几个字节地到也有可能两帧数据连在一起到达这就是半包和粘包问题。半包容易理解一帧数据被拆成几段传过来了粘包也不难理解两帧数据紧挨着传过来了中间没有分隔。处理这种情况很自然的想法是“先攒够一帧再解析”但攒多少算够那就得靠之前设计的长度字段了。工程上最优雅的做法是写一个状态机每收到一个字节就喂给状态机状态机内部根据当前的进度决定怎么处理这个字节。我用文字加表格把状态流转描述一遍大家理解起来比直接看代码要容易。当前状态收到字节行为等待帧头10xA5进入等待帧头2等待帧头1其他继续保持等待等待帧头20x5A进入接收帧类型等待帧头20xA5仍等待帧头2因为可能连发了两个0xA5等待帧头2其他回到等待帧头1接收帧类型任意保存类型累计CRC进入接收长度接收长度任意保存长度累计CRC进入数据区接收数据区任意保存数据累计CRC收满后进入接收CRC低字节接收CRC低字节任意保存低字节进入接收CRC高字节接收CRC高字节任意保存高字节比对CRC回到等待帧头1这套状态机的核心思想是“每到一个字节只判断一次移动一格”。粘包时前一个帧解析完状态机会自动归位继续解析下一个帧头半包时状态机完整保留在“数据区只收了一半”的位置等待剩余的字节到来。整个过程不需要大缓冲来攒数据RAM占用极小非常适合单片机。我直接把代码贴出来这段代码我在多个平台跑过可直接移植。enum { ST_WAIT_HEAD1, ST_WAIT_HEAD2, ST_TYPE, ST_LEN, ST_DATA, ST_CRC_LO, ST_CRC_HI }; typedef struct { uint8_t state; uint8_t type; uint8_t len; uint8_t recv_len; uint8_t data[FRAME_DATA_MAX]; uint16_t crc_calc; uint16_t crc_recv; } rx_parser_t; static void parser_reset(rx_parser_t *p) { p-state ST_WAIT_HEAD1; p-len 0; p-recv_len 0; } static int parser_feed(rx_parser_t *p, uint8_t byte) { switch (p-state) { case ST_WAIT_HEAD1: if (byte FRAME_HEAD1) p-state ST_WAIT_HEAD2; break; case ST_WAIT_HEAD2: if (byte FRAME_HEAD2) p-state ST_TYPE; else if (byte FRAME_HEAD1) p-state ST_WAIT_HEAD2; /* 连续两个帧头字节继续等 */ else p-state ST_WAIT_HEAD1; break; case ST_TYPE: p-type byte; p-crc_calc crc16_update(0xFFFF, byte); p-state ST_LEN; break; case ST_LEN: p-len byte; p-crc_calc crc16_update(p-crc_calc, byte); p-recv_len 0; p-state (p-len 0) ? ST_CRC_LO : ST_DATA; break; case ST_DATA: if (p-recv_len FRAME_DATA_MAX) { p-data[p-recv_len] byte; p-recv_len; p-crc_calc crc16_update(p-crc_calc, byte); } if (p-recv_len p-len) p-state ST_CRC_LO; break; case ST_CRC_LO: p-crc_recv byte; p-state ST_CRC_HI; break; case ST_CRC_HI: p-crc_recv | (uint16_t)(byte 8); if (p-crc_recv p-crc_calc) { /* 一帧有效数据交给上层业务处理 */ parser_reset(p); return 1; } parser_reset(p); return -1; } return 0; }用这个状态机有几个好处它天然抗粘包两帧连在一起发过来第一帧解析完状态机直接回到ST_WAIT_HEAD1第二次进到ST_CRC_HI时新帧的CRC又会被正常解析它也天然抗帧头误同步假设数据区出现0xA5 0x5A状态机并不会误认为帧头因为它此刻正处于ST_DATA状态字节会被当作数据处理。3.4 上位机快速验证用Python模拟一帧没有对端设备测试的时候我习惯用Python先模拟一下封包和拆包把协议逻辑跑通再烧到单片机上。下面这段脚本可以快速算出CRC并组成发送帧。import struct def crc16(data: bytes) - int: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 crc 0xFFFF return crc # 构造一帧传感器上报节点1温度0x0119(281)湿度0x0258(600) data bytes([0x01, 0x19, 0x01, 0x58, 0x02]) frame_body bytes([0x02, len(data)]) data crc crc16(frame_body) frame bytes([0xA5, 0x5A]) frame_body struct.pack(H, crc) print(hex:, frame.hex().upper())把这段输出和单片机串口抓到的数据一对比马上就能看出封包逻辑对不对。我每次调试新协议都会先在PC端把收发脚本写好再用串口转USB接到开发板上这个流程能帮我省至少半天排查时间。4. 实战踩坑记录粘包、乱码、CRC失败的排查思路4.1 为什么我收不到任何数据串口一片空白这种情况下先别怀疑协议逻辑协议还没跑到那一步。优先查三样东西波特率、接线、共地。单片机串口和USB转串口模块的波特率不一致收端就是全乱码TX接RX、RX接TX这最基础的交叉接法也经常有人搞反共地问题更容易被忽视两个设备电源不共地收端大概率只能收到噪声或干脆无数据。用示波器量一下波形是最快的方法能直接看到有无信号跳变。如果波形正常但收不到数据就要检查串口中断配置了很多MCU的串口中断只在空闲状态下有效帧头发送太快导致中断没来得及触发。4.2 乱码不是协议问题是参数问题收得到数据但全是乱码几乎可以锁定是波特率不匹配或者是电平不匹配。嵌入式调试时常用的CP2102、CH340这类USB转串口模块是TTL电平如果对面设备是RS232电平正负电压而没有转成TTL收到的只能是一堆乱码。还有一个隐形杀手是USB转串口的“丢字节”低端模块在波特率较高时存在偶发丢字节925600以上尤其明显。这时候可以在协议里多发一遍完整数据帧接收方拿第一帧校验失败的数据做调试信息打印基本能定位到。4.3 CRC一直不对90%是范围不一致这是我被问过最多的问题代码里接收端校验失败总是在同一帧类型上。绝大多数情况是三个原因发送方和接收方CRC范围不一致一个把帧头算进去了另一个没算字节序反了发送方按高字节在前而接收方按低字节在前或者发送方计算CRC前忘了重置初值。排查方法很简单固定一帧数据分别打印发送端封包函数算出的CRC、解析状态机累计的CRC、帧尾收到的CRC三个值对照一下就知道了。这里最容易犯的错误是发送端用上位机脚本算好CRC填进去但上位机脚本的CRC实现和单片机码不一样比如多项式选错或初值不同。4.4 状态机卡死链路一断就恢复不了状态机卡死往往是因为没有“复位机制”。假如状态机已经走到ST_DATA等待接收剩余数据但发送方因为异常只发了半帧就停了状态机就会一直停在ST_DATA之后来的正常帧全被当成数据吃掉链路就永久错乱了。解决办法是给状态机加一个超时看门狗不管当前处于哪个状态只要超过一定时间没收到新字节强制回到ST_WAIT_HEAD1。超时时间我一般设成帧长传输时间的3到5倍数据量很小时设50ms足够数据量大时按波特率算。伪代码示意if (millis() - last_byte_time FRAME_TIMEOUT_MS) { parser_reset(rx_parser); last_byte_time millis(); }这个复位逻辑要放在主循环或定时中断里每次收到字节更新last_byte_time。只要链路异常丢帧看门狗就能及时把解析器拉回正轨。4.5 调试工具组合一个人也能排查问题很多时候自定义协议出问题原因不在协议本身而在于调试手段不够。我现在的标准调试组合是三件套逻辑分析仪抓物理层波形串口助手看收发数据流PC端Python脚本做协议验证。逻辑分析仪主要看帧的时序关系和波特率误差串口助手用来发固定测试帧比如直接手动输入一帧心跳帧字节串看设备能不能正确应答Python脚本用来批量构造边界帧测长度字段上下限、数据区出现帧头等情况。这套组合排查一次链路问题比单纯看代码快一个量级。5. 让“黑通道”更黑更稳序号、加密、版本号5.1 序列号与应答机制防重放也防丢帧前面说过序列号能辅助判断丢包但它更大的价值在安全场景。设想一个控制设备发“打开电灯”指令如果被第三方抓包重放就可以在你不注意时偷偷打开电灯。加入序列号后接收端但凡收到和上一个序列号相同或非连续递增的帧就直接丢弃或报警。序列号用一字节就能实现循环递增配合应答帧状态机解析还能判断帧是否乱序。代价是每帧多一字节工程量很小。5.2 数据加密怎么选轻量还是够用更重要“黑通道”如果想要更强保密性数据区就得加密。加密算法选择主要看主控资源。低端8位MCU跑AES有点吃力可以用XOR混淆加CRC碰撞校验虽然不能防专业破解但至少让抓包的人看不出明文资源稍微宽裕些的比如带硬件AES的芯片直接上AES-CTR是最省心的选择因为CTR模式不需要对数据做填充每一帧数据长度不变加解密开销也小。这里要提醒一句加密算法本身不是私有的协议设计你自己定但加密算法建议用公开成熟的自己发明加密算法在工程上风险极高一旦被破解整个协议就全废了。5.3 协议版本号人人都该加却常被忽略不少人在自定义协议里省掉了版本号等到协议升级那天就会吃大亏。老设备用的V1版本协议新设备升级到V2帧类型定义完全不同两边一对上就是灾难。解决方案很简单在帧头之后加一个字节的协议版本号接收端收到帧后先看版本号版本不符直接丢弃或按兼容逻辑处理。版本号和帧类型一样参与CRC计算这样任何一个字段被改动都会被对端识别出来。5.4 自定义协议的测试清单越详细越好协议写完不代表链路就能稳定跑。我习惯把所有边界情况列成一张测试清单逐条过一遍再发布到项目里数据区长度为0的空帧能不能正常解析。数据区长度超过上限时发送端拒绝接收端不越界。数据区里故意塞入帧头字节能不能被正确处理。连续发送多帧帧与帧之间无间隔粘包模拟能不能逐帧解析。在帧中间人为断开再继续发看超时机制和状态机能否恢复。修改帧体内任意一个字节CRC是否能校验失败。这些测试每条都对应前面提到的机制如果哪条没过说明协议实现里对应环节有缺陷。我的经验是花半天把这些边界测一遍后面的联调就能非常顺。写协议、写状态机其实远没有想象中那么神秘。真正难的永远是那几条容易被忽略的细节CRC范围、超时复位、字节序约定、版本号。我第一次做自定义协议时就是栽在CRC范围不一致上两个板子抓包抓了一整个下午最后才发现发送方把帧头也算进了校验接收方没算。从那以后我给自己定了个规矩协议文档里必须用表格把所有字段范围和校验范围写清楚代码注释里同步写一句CRC范围再也没因为这个翻过车。如果你正要开始做自定义协议我的建议是先把协议文档画成一张表格确保自己写清楚帧头、类型、长度、数据、校验五个要素的取值范围和顺序再动笔写代码。别嫌麻烦这套习惯能帮你省下后面无数个抓狂的夜晚。
阅读完成 · 觉得有帮助？
