做通信和嵌入式开发的人几乎都有过被 CRC 支配的经历串口收到的数据偶尔错一个位Modbus 从站直接不回包Flash 里读出来的固件解压到一半报校验失败。这些问题的共同点就是背后站着一个叫CRC循环冗余校验的东西。它不像 MD5、SHA 那样不可逆也不像奇偶校验那样简陋到只能抓单比特错误它刚好卡在算得快、抓得准、实现便宜这个甜点上所以从串口协议、存储校验到以太网帧尾几十年来一直是默认选项。这篇东西不讲论文只讲两件事直接计算法一位一位推慢但看得懂和查表法用一张 256 项的数组换速度工程上真正在用的写法。我会把参数模型、反射、异或输出这些平时最容易被忽略的细节都摊开说顺便把大家搜得最多的几个问题——在线 CRC 校验计算器怎么用、查表法怎么算传感器温度原始值、千兆链路为什么突然冒出一堆接收 CRC 错误、安装包解压报 CRC error 怎么办——一并捋一遍。不管你是刚学嵌入式的学生还是被现场问题折磨的工程老兵看完应该都能直接把代码抄走用。1. 从一次串口翻车说起CRC 到底在防什么1.1 校验和与奇偶校验为什么不够用早期的串口协议很多用累加和做校验就是把所有字节相加取低 8 位。这种做法的问题在于它对错误没有形状上的分辨力。举个例子两个字节的传输过程中如果发生0x01和0x02互换位置累加和完全不变如果某个字节从0x10变成0x20同时另一个字节从0x20变成0x10累加和也照样不变。更致命的是如果某个字节加上0x01另一个字节减去0x01校验和纹丝不动。这种错误在电磁干扰环境下并不罕见。奇偶校验更弱它只保证1 的个数的奇偶性任意偶数个比特翻转都能完美躲过。工业现场里电机启停、继电器吸合产生的瞬态干扰很容易一次打翻 2 个、4 个比特这时候奇偶校验等于没装。CRC 的思路完全不同。它把整段数据当作一个巨大的二进制数拿它去除一个约定的生成多项式把余数当作校验值。除法的过程会让每一个数据位都参与运算而且参与的方式是非线性的——某一位翻转余数的变化取决于它所在的位置。这就带来了几个关键性质所有单比特错误必被抓到所有双比特错误必被抓到在合理的多项式长度下所有长度不超过校验位宽的突发错误必被抓到。这比累加和强了不止一个数量级。1.2 CRC 的核心思想把比特流当成多项式要理解 CRC得先接受一个有点反直觉的设定每一个比特就是多项式的一个系数。比如数据字节0xC2二进制是11000010在 CRC 的世界里它被读成1·x^7 1·x^6 0·x^5 0·x^4 0·x^3 0·x^2 1·x^1 0·x^0 x^7 x^6 x生成多项式也是一样。CRC-8 常用的0x07展开就是x^8 x^2 x 1注意这里有一个隐藏的最高位x^8因为 CRC-8 的8指的就是这个最高次幂。CRC-16/MODBUS 的多项式0x8005展开是x^16 x^15 x^2 1同理隐藏了x^16。接下来的运算全部定义在GF(2) 域上规则简单到离谱加法不进位减法不借位加法和减法都是异或。1 1 00 - 1 1。这意味着整个除法过程中不存在比较大小这个动作只看最高位是 0 还是 1是 1 就异或一次除数是 0 就跳过。还有个关键点CRC 计算前要把数据左移 W 位W 是校验位宽也就是在数据末尾补 W 个零。这一步很多人初学时想不通其实原因很简单——除法做完之后余数的位数是和除数对齐的只有先把被除数抬高 W 位算出来的余数才刚好是 W 位宽才能直接当作校验值附加在数据后面。1.3 参数模型同一个名字下藏着好几种结果这一段是新手最容易踩的坑。你搜CRC-16网上能翻出七八种不同的实现同一个数据算出来的结果天差地别然后你开始怀疑自己的代码是不是写错了。实际上一个完整的 CRC 算法由五个参数共同确定缺一不可poly多项式生成多项式的低 W 位表示最高位隐含init初始值寄存器在开始计算前的初值常见0x0000或0xFFFFrefin输入反射每个输入字节是否按位倒序后再进入运算refout输出反射最终结果是否按位倒序输出xorout结果异或最终结果是否再异或一个固定值比如大家最熟悉的 CRC-16/MODBUS参数是poly0x8005, init0xFFFF, refintrue, refouttrue, xorout0x0000而 CRC-16/CCITT-FALSE 是poly0x1021, init0xFFFF, refinfalse, refoutfalse, xorout0x0000。两者多项式完全不同初始值一个全 1 一个全 1这个碰巧一样反射设置相反结果自然对不上。提示判断自己的实现对不对有一个万能方法——用标准测试串1234567899 个 ASCII 字符不含结尾的\0算一次把结果和官方 check 值比对。CRC-16/MODBUS 应该是0x4B37CRC-16/CCITT-FALSE 是0x29B1CRC-32 是0xCBF43926。这三个值记牢能省掉你至少半天调试时间。2. 直接计算法一位一位推出来的笨办法2.1 手推一遍模 2 除法把 CRC 的底摸清在写代码之前拿纸笔推一遍是最有效的。用一个超小规模的例子假设生成多项式是10114 位对应x^3 x 1这里校验位宽 W3数据是1101。第一步数据末尾补 3 个零被除数变成1101000。第二步做模 2 长除法规则只有一个看当前窗口的最高位是 1 就异或除数是 0 就跳过。被除数1 1 0 1 0 0 0 除数 1 0 1 1 第1步 取前4位 1101最高位1异或 1011 1101 ⊕ 1011 0110 拉下一位 0窗口变成 0110 0 第2步 当前前4位 1100跳过前导0对齐最高位1异或 1011 1100 ⊕ 1011 0111 拉下一位 0 第3步 当前前4位 1110最高位1异或 1011 1110 ⊕ 1011 0101 拉下一位 0 第4步 当前前4位 1010最高位1异或 1011 1010 ⊕ 1011 0001最终余数是001这 3 位就是 CRC 值。整个过程没有任何进位借位也没有大小比较全是异或。你把这段手推吃透后面看代码就是把纸面动作翻译成循环而已。顺便说一句这个例子本质上就是 CRC-3 的雏形。真实的 CRC-8、CRC-16、CRC-32 只是把位宽拉长逻辑一字不改。2.2 位级移位实现的 C 代码与逐步注释把上面的长除法翻译成代码就是所谓的直接计算法也叫位级算法、bit-by-bit。它的特点是每个字节要循环 8 次每次处理一位。#include stdint.h #include stddef.h /* * CRC-8 位级实现 * poly 0x07 (x^8 x^2 x 1, 最高位隐含) * init 0x00 * refin false, refout false, xorout 0x00 */ uint8_t crc8_bitwise(const uint8_t *data, size_t len) { uint8_t crc 0x00; for (size_t i 0; i len; i) { /* 把当前字节异或进寄存器高位等价于把数据位推进除法窗口 */ crc ^ data[i]; for (int bit 0; bit 8; bit) { if (crc 0x80) { /* 最高位为1左移后异或多项式 */ crc (uint8_t)((crc 1) ^ 0x07); } else { /* 最高位为0只左移 */ crc (uint8_t)(crc 1); } } } return crc; }这段代码里crc ^ data[i]这一步是理解的关键。它看起来像是偷懒实际上是把长除法里取前 8 位并异或的动作融合进去了。你可以这样理解寄存器里保存的是当前除法窗口的状态异或进一个字节相当于一次性把 8 位数据推到窗口的高 8 位接下来的 8 次移位就把这 8 位逐位消化掉了。再看 16 位版本结构几乎一模一样只是宽度和多项式常量变了/* * CRC-16/CCITT-FALSE 位级实现 * poly 0x1021, init 0xFFFF * refin false, refout false, xorout 0x0000 */ uint16_t crc16_ccitt_false_bitwise(const uint8_t *data, size_t len) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { crc ^ (uint16_t)data[i] 8; for (int bit 0; bit 8; bit) { if (crc 0x8000) { crc (uint16_t)((crc 1) ^ 0x1021); } else { crc (uint16_t)(crc 1); } } } return crc; }注意crc ^ (uint16_t)data[i] 8里的左移 8 位。这是因为 16 位寄存器的高 8 位才是窗口的高位字节数据必须推到那里才能参与最高位判断。如果你写成了crc ^ data[i]那算出来的就是完全错误的东西而且错误很隐蔽只有对比 check 值才会发现。2.3 直接法的性能账什么时候它反而更合适直接计算法每个字节要执行 8 次分支判断加移位在 72MHz 的 Cortex-M3 上粗略估算每字节约 40 到 60 个时钟周期。传 1KB 数据就要 4 万到 6 万个周期大概 0.6 到 0.8 毫秒。在大多数低速场景9600bps 串口、1MHz 的 I2C这完全不是问题因为你收数据本身就更慢。但有两种情况它反而更值得选。第一种是只算极短数据。比如某些传感器的单帧只有 2 个字节查表法初始化 256 项数组的开销显著大于直接算。虽然表可以预先生成放在 Flash 里但如果只是偶尔算一次直接法代码更短占用的 Flash 更少。第二种是RAM 和 Flash 极度紧张的场合。一张 256 项的 uint16_t 表占 512 字节 Flash对有些 8 位单片机来说是笔不小的开销。如果 Flash 只剩最后 1KB那就老老实实用位级算法用时间换空间。实操心得位级算法的分支if-else在流水线处理器上会有分支预测失败的开销。如果追求极致可以把它改成无分支写法crc (crc 1) ^ ((crc 15) ? poly : 0);或者用-(crc 15) poly这类技巧。不过在绝大多数嵌入式场景里这点优化意义不大可读性更重要。3. 查表法把 8 次循环压成一次查表3.1 表的本质一个字节的高 8 位余数预先算好查表法的核心洞察是一个字节只有 256 种可能。既然每个字节都要走 8 次相同的移位判断那为什么不把这 256 种输入对应的8 次移位后的结果提前算出来存成一张表具体地说对于 16 位 CRC当你把一个字节异或进寄存器高 8 位之后接下来 8 次移位的结果只取决于这个 8 位值的组合。把寄存器高 8 位记作H字节记作B那么H ^ B这个 8 位值经过 8 次移位异或后的结果是可以预先穷举的。这就是表的第(H ^ B)项。完整的推导稍微绕但用一句话概括就是把寄存器拆成高 8 位和低 8 位两部分高 8 位负责查表低 8 位负责位移。查表结果再和移位后的低 8 位异或就得到了更新后的寄存器值。/* 查表法计算 16 位 CRC非反射版本 */ uint16_t crc16_table_driven(const uint8_t *data, size_t len, const uint16_t table[256], uint16_t init) { uint16_t crc init; for (size_t i 0; i len; i) { /* 高8位与数据字节异或后查表结果再与低8位左移8位后的值异或 */ crc (uint16_t)((crc 8) ^ table[((crc 8) ^ data[i]) 0xFF]); } return crc; }整个循环体只有一次数组索引、两次异或、一次移位没有内层循环没有分支。在有指令缓存的 MCU 上这个循环通常能跑到每字节 8 到 12 个时钟周期比位级算法快 4 到 6 倍。3.2 256 项表的生成代码表不是手写出来的是程序算出来的。而且最关键的是表必须用和你最终算法一致的多项式和反射配置来生成。这一点出错的话查表和直接算的结果会永远对不上而且很难 debug。下面是生成表的代码用的是位级算法的内核#include stdint.h /* 生成 CRC-16/CCITT-FALSE 查表poly0x1021, 非反射 */ void crc16_ccitt_false_init_table(uint16_t table[256]) { for (int i 0; i 256; i) { uint16_t crc (uint16_t)(i 8); for (int bit 0; bit 8; bit) { if (crc 0x8000) { crc (uint16_t)((crc 1) ^ 0x1021); } else { crc (uint16_t)(crc 1); } } table[i] crc; } }看出来了吗生成表的内层循环和位级算法的内层循环是同一段代码只是输入变成了i 8i从 0 到 255。这不是巧合——表的每一项就是把这个 8 位值放到寄存器高位、低 8 位清零之后走完 8 次移位的余数。对于反射版本比如 CRC-16/MODBUS代码要相应改成从低位往高位走/* 生成 CRC-16/MODBUS 查表poly0x8005 反射后为 0xA001 */ void crc16_modbus_init_table(uint16_t table[256]) { for (int i 0; i 256; i) { uint16_t crc (uint16_t)i; /* 注意不再左移8位 */ for (int bit 0; bit 8; bit) { if (crc 0x0001) { crc (uint16_t)((crc 1) ^ 0xA001); /* 右移用反射多项式 */ } else { crc (uint16_t)(crc 1); } } table[i] crc; } } /* 反射版查表计算 */ uint16_t crc16_modbus(const uint8_t *data, size_t len, const uint16_t table[256], uint16_t init) { uint16_t crc init; for (size_t i 0; i len; i) { crc (uint16_t)((crc 8) ^ table[(crc ^ data[i]) 0xFF]); } return crc; }这里有个特别容易搞混的点0x8005反射之后变成0xA001这个值是把0x8005的 16 个位从头到尾倒过来得到的。很多人在写反射版时表用0x8005生成计算时却用右移算法结果当然是错的。注意反射版本里crc i而不是crc i 8移位方向是不是判断的是最低位0x0001不是最高位0x8000。这四处必须同时改改一处漏一处就是灾难现场。3.3 4 位半字节表省空间的折中方案256 项的表在 16 位 CRC 下要占 512 字节在 32 位 CRC 下要占 1024 字节。对于资源紧张的 MCU可以用半字节查表法表只存 16 项每次处理半个字节成本是循环次数翻倍。/* 16 项半字节表CRC-16/CCITT-FALSE 版本 */ void crc16_nibble_init_table(uint16_t table[16]) { for (int i 0; i 16; i) { uint16_t crc (uint16_t)(i 12); for (int bit 0; bit 4; bit) { if (crc 0x8000) { crc (uint16_t)((crc 1) ^ 0x1021); } else { crc (uint16_t)(crc 1); } } table[i] crc; } } uint16_t crc16_nibble_calc(const uint8_t *data, size_t len, const uint16_t table[16]) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { /* 先处理高 4 位 */ crc (uint16_t)((crc 4) ^ table[((crc 12) ^ (data[i] 4)) 0x0F]); /* 再处理低 4 位 */ crc (uint16_t)((crc 4) ^ table[((crc 12) ^ (data[i] 0x0F)) 0x0F]); } return crc; }速度大概是 256 项表的一半多但 Flash 占用从 512 字节降到 32 字节差距巨大。我在几个 Flash 只有 8KB 的老项目里用过这个方案效果很稳。选择逻辑很简单要么用速度换空间半字节表要么用空间换速度256 项表没有免费的午餐。3.4 反射输入输出到底在反射什么反射reflection这个词翻译得不太好容易让人想歪。它其实就一个动作把 8 个比特的先后顺序倒过来。0b11000000反射后变成0b00000011。为什么要反射这跟历史上的硬件实现有关。早期一些通信协议比如以太网的某些层在发送时是低位先发LSB first而 CRC 的数学定义是高位先算MSB first。为了让硬件实现更简单不需要额外的位反转电路工程师干脆把多项式也反过来写整个算法从低位开始处理这样数据流进来就能直接算。对软件实现来说反射的影响体现在三个地方第一输入反射意味着每个字节在参与运算前要按位倒序。整字节 256 项查表法里这个倒序动作被吸收进了表的设计中所以你看到代码里没有显式的位反转但表是用反射多项式生成的。第二输出反射意味着最终结果要按位倒序一次。不过在整字节查表法里有个小技巧如果 init 也做了相应的处理refin 和 refout 的反射效果在很多实现里会被抵消或合并。这就是为什么有些库的代码看起来没做反射却能算出正确结果。第三初始值和结果异或在反射语境下也要跟着变。比如 init 从0xFFFF反射后还是0xFFFF全 1 不变但0x1234反射后就变成0x2C48了。如果你不想踩这个坑最简单的做法是认准一张参数表照抄。下面这张表是工程上最常用的几个模型直接抄进代码注释里就行。4. 参数表格与在线工具交叉验证4.1 常用 CRC 参数模型对照表模型名位宽多项式初始值输入反射输出反射结果异或123456789 结果CRC-880x070x00否否0x000xF4CRC-8/MAXIM80x310x00是是0x000xA1CRC-16/ARC160x80050x0000是是0x00000xBB3DCRC-16/MODBUS160x80050xFFFF是是0x00000x4B37CRC-16/CCITT-FALSE160x10210xFFFF否否0x00000x29B1CRC-16/XMODEM160x10210x0000否否0x00000x31C3CRC-16/KERMIT160x10210x0000是是0x00000x2189CRC-16/X-25160x10210xFFFF是是0xFFFF0x906ECRC-32320x04C11DB70xFFFFFFFF是是0xFFFFFFFF0xCBF43926CRC-32/C320x1EDC6F410xFFFFFFFF是是0xFFFFFFFF0xE3069283这张表的价值在于先对号入座再写代码。别一上来就闷头写写完发现参数选错了白忙活。4.2 用在线 CRC 校验计算器做三点验证网上有很多在线 CRC 校验计算器输入十六进制数据就能出结果。很多人拿它当作弊工具其实它的正确用法是做交叉验证。我的习惯是用三点验证法第一点用空数据或者单个字节0x00去算。这一步主要验证初始值有没有设置对因为空数据的 CRC 就等于 init经过各种反射和异或之后的值。第二点用单字节0x01或者0x80去算。这一步能暴露移位方向和反射设置的问题。0x01在反射配置下和0x80在不反射配置下结果会有明显差异。第三点也是最重要的一点用标准串123456789去算对照 4.1 那张表的最后一列。三点全对说明你的五个参数设置完全正确这时候再去写查表法基本不会出问题。实操心得在线计算器有个坑很多网站的输入框默认按十六进制字符串解析你输入123456789它会当成 9 个十六进制字节0x12 0x34 0x56 0x78 0x9?字符数不整就直接截断或者报错。所以输入标准串时要用 ASCII 模式或者干脆输入313233343536373839123456789的十六进制表示。这一点我第一次用的时候被坑了很久明明代码没问题就是和在线工具对不上。4.3 传感器场景用查表法校验温度原始数据很多数字传感器在 I2C 或者单总线上返回的原始数据都带 CRC 校验位比如温湿度传感器常见的格式是数据高字节 数据低字节 CRC-8。这里的 CRC-8 通常是poly0x31, init0xFF或者poly0x07, init0x00具体看数据手册。为什么这里必须用 CRC 而不是简单的累加因为传感器和主控之间的连接往往是几厘米到几十厘米的排线周围还有电机、继电器、开关电源在工作单比特翻转的概率不低。CRC-8 能抓住所有单比特错误和大部分双比特错误误判概率约 1/256对温度读数这种应用足够了。用查表法算校验的过程是这样的以poly0x31, init0xFF为例#include stdint.h /* 生成 CRC-8/0x31 查表用于传感器数据校验 */ static void crc8_sensor_init_table(uint8_t table[256]) { for (int i 0; i 256; i) { uint8_t crc (uint8_t)i; for (int bit 0; bit 8; bit) { if (crc 0x80) { crc (uint8_t)((crc 1) ^ 0x31); } else { crc (uint8_t)(crc 1); } } table[i] crc; } } /* 用查表法校验 2 字节数据 1 字节 CRC */ int crc8_sensor_verify(const uint8_t table[256], const uint8_t *frame) { uint8_t crc 0xFF; /* init 0xFF */ crc table[crc ^ frame[0]]; crc table[crc ^ frame[1]]; return (crc frame[2]) ? 1 : 0; }注意这里我没有做最后的输出异或xorout0x00也没有反射。如果换成别的传感器参数可能不同一定要查手册。手册里通常会写清楚 poly、init以及是否反射。很多新手直接在手册里找CRC两个字看到多项式就抄忽略了 init 和反射结果校验永远失败。还有一个细节有些传感器的 CRC 计算范围包括从机地址或者状态位不只是数据本身。这个范围一定要看手册的时序图把 CRC 的起始字节和结束字节标出来。我在一个项目里就因为多算了一个状态字节整整调了一下午。5. 现场排查CRC 报错到底该怀疑谁5.1 千兆以太网接收方向大量 CRC 错误的排查顺序这是被搜得最多的现场问题之一某款千兆 PHY 芯片比如 YT8521 这类百兆工作完全正常一协商到千兆接收方向就开始冒大量 CRC 错误丢包严重。这类问题的排查有明确的优先级顺序别上来就怀疑芯片坏了。第一步先分层确认错误计数在哪里增长。MAC 侧的计数器和 PHY 侧的计数器是分开的先看清楚是 PHY 收到的帧就带 CRC 错误还是 MAC 到 PHY 之间的接口比如 RGMII出了问题。前者说明是线缆或者模拟链路问题后者说明是数字时序问题。这个判断能省掉一半的排查时间。第二步为什么百兆正常千兆不正常。这个现象本身信息量很大。百兆以太网只用到 4 对双绞线中的 2 对收一对、发一对而千兆要用满全部 4 对双向同时工作。同时千兆的编码方式和符号率对信号完整性的要求高得多。所以只要有一对线的质量不达标、一个水晶头的某个触点接触不良、或者 PCB 上某对差分线阻抗控制不好百兆可能完全看不出来千兆就原形毕露。第三步按概率排查物理层网线确认是 Cat5e 及以上长度在 100 米以内。劣质网线的线对绞距不均匀近端串扰严重。最直接的验证方法就是换一根确定质量好的短网线比如 1 米的成品线如果换了就好问题定位完成。水晶头千兆必须 8 芯全通且线序正确。用测线仪看 8 个灯是不是依次全亮全灭。很多时候是压线钳力度不够某一芯接触不良百兆没事因为不用那两对千兆就崩。PCB 差分走线千兆的差分阻抗要求 100Ω±10%走线要等长、尽量短、参考平面完整。如果差分对跨了分割的地平面或者走线长度差异超过几毫米千兆下就会出现明显误码。变压器和共模电感网络隔离变压器的带宽不够或者共模抑制比差也会在千兆下暴露。确认变压器型号支持千兆速率。第四步看数字接口时序。如果错误计数在 MAC-PHY 接口侧重点看 RGMII 的 TX/RX delay 配置。千兆下 RGMII 的时钟是 125MHz数据是双沿采样建立保持时间的余量比百兆小得多。很多 PHY 支持内部延时需要和 MAC 侧的延时配置匹配一个开一个不开或者两个都开都会导致采样点偏移。这个配置通常在设备树或者 PHY 寄存器里属于典型的能通但误码率高的故障模式。第五步时钟质量。千兆对参考时钟的抖动更敏感。25MHz 晶振的频偏要在 ±50ppm 以内相位噪声也要达标。用示波器看一下时钟波形如果抖动明显偏大换一个晶振试试。实操心得遇到百兆正常千兆出问题我一般会先做两件事——换一根短的好网线以及用芯片自带的线缆诊断功能看四个线对的长度和阻抗是否一致。这两个动作加起来不超过十分钟能覆盖掉八成以上的问题。真正需要动烙铁改 PCB 的情况其实很少。5.2 压缩包 CRC error 的正确处理姿势另一个高频场景是解压安装包时报gzip: stdin: invalid compressed data --crc error。这个报错和上面的物理层问题完全是两回事它属于数据完整性问题。gzip 格式在每个压缩块末尾存了一个 CRC-32 值解压时会实时计算并比对。报 CRC error 意味着解压出来的数据和压缩时记录的不一致。可能的原因有第一下载不完整。网络中断、断点续传失败、下载工具缓存问题都会导致文件少了几个字节。这时候 gzip 可能能解压出一部分但在校验块时失败。第二传输介质或存储故障。U 盘老化、硬盘坏道、内存条故障都可能让文件在复制过程中悄悄损坏。这种情况最阴险因为文件大小看起来完全正确。第三合并分卷时出错。如果安装包是分卷压缩的用cat part1 part2 full.tar.gz这种方式合并一定要确认顺序正确、没有缺卷。合并顺序错了照样能解压一部分然后报 CRC 错误。正确的处理流程是先去官网下载页找 SHA256 或者 MD5 校验值用sha256sum或者certutil -hashfile算一遍本地文件。如果哈希对不上那就是文件损坏重新下载。如果哈希对得上还报 CRC 错误那就要怀疑解压工具本身的版本问题或者文件系统的问题了。注意重新下载时尽量用官方的直链不要用来源不明的镜像也不要用带加速功能的下载器这些工具在某些情况下会返回被篡改的内容。另外下载完先校验再解压这个习惯能省下大量时间。5.3 自定义协议 CRC 对不上的常见原因清单自己写协议时收发两端 CRC 对不上是最常见的问题。按我踩过的坑原因基本就这几类按出现频率排序参数不一致。这是第一名占一半以上。发送端用poly0x1021, init0x0000接收端用poly0x1021, init0xFFFF初始值差一点点结果就完全不一样。解决办法是把参数写进协议文档代码里用宏定义统一管理。字节序搞反。CRC-16 计算出来是 16 位拆成两个字节传输时是高字节在前还是低字节在前一定要写清楚。Modbus 是低字节在前很多自定义协议是高字节在前。这个错了接收端算出来正好是高低字节颠倒的值。计算范围不一致。CRC 到底算哪些字节包不包含帧头包不包含长度字段包不包含数据长度本身这些问题必须在协议里定死。常见错误是发送端算的时候包含了长度字段接收端算的时候没包含。结构体对齐导致的隐藏字节。用 C 语言定义协议结构体时编译器可能会在字段之间插入填充字节。发送端用memcpy把结构体直接发出去接收端按字段逐个算 CRC两边的字节流就不一样了。解决办法是加__attribute__((packed))或者手动按字节序列化。反射方向搞反。发送端用了反射版本的多项式接收端用了非反射版本或者反过来。这种错误的结果通常是总是差一个固定的变换比较有辨识度。字符串结尾的\0。如果协议里传的是字符串发送端算 CRC 时算上了结尾的\0接收端没算或者反过来。这种错误在测试短文数据时不容易发现因为短字符串的\0位置很特殊。数据在传输中被修改。比如某个中间设备网关、转换器自作主张修改了数据字段但没重新算 CRC。这种情况比较少见但确实存在排查时可以用抓包工具对比收发两端的原始字节流。5.4 排查速查表与调试代码片段下面这张表是我自己常用的排查清单按现象到最可能原因组织现象最可能原因快速验证方法所有数据 CRC 都差一个固定值初始值不一致算空数据的 CRC应该等于 init 的变换值高低字节颠倒字节序问题把结果的 16 位高低字节交换后再比对短数据对长数据错计算范围不一致打印双方参与计算的字节序列固定模式的数据对随机数据错结构体填充字节用sizeof检查结构体大小是否符合预期单比特错双比特也对多项式选错了用标准串验证多项式校验值偶尔对偶尔错数据在传输中被改抓包对比收发两端原始数据CRC 错误集中出现在某个时间段电磁干扰或者电源波动用示波器看电源纹波和信号质量配合排查下面这段调试代码可以快速打印中间状态比在脑子里推演快得多#include stdio.h #include stdint.h #include stddef.h /* 带调试输出的 CRC-16 位级计算用于对比排查 */ uint16_t crc16_debug(const uint8_t *data, size_t len, uint16_t poly, uint16_t init) { uint16_t crc init; printf(init 0x%04X, poly 0x%04X\n, init, poly); for (size_t i 0; i len; i) { crc ^ (uint16_t)data[i] 8; for (int bit 0; bit 8; bit) { if (crc 0x8000) { crc (uint16_t)((crc 1) ^ poly); } else { crc (uint16_t)(crc 1); } } printf(after byte[%zu]0x%02X: crc 0x%04X\n, i, data[i], crc); } return crc; }把两端的这段输出贴在一起对比第一个出现差异的字节位置就是问题源头。这个技巧看起来笨但在我处理过的协议兼容问题里它是最快见效的。最后再分享一个我自己养成的习惯每写一个新协议的 CRC 实现第一件事不是联调而是拿标准串123456789跑一遍 check 值。这个动作只要五分钟但能挡掉后面可能躺在床上的三个小时。CRC 这东西参数对了就是对的错了就是全错没有差不多的中间状态——所以与其在联调时抓瞎不如在写代码时就把参数钉死。
