一套代码覆盖CRC-8到CRC-32：参数化CRC校验实现与踩坑排查

简介：这份循环冗余校验码（CRC）计算源代码合集面向嵌入式开发、通信协议调试与数据存储校验学习者，聚焦CRC-8、CRC-16、CRC-32等常见算法的代码实现与工程验证。压缩包共1220个文件，约6.65MB，包含C与汇编源文件、头文件、工程配置、编译中间文件及hex、lst、m51等烧录与列表产物，并带有crc8、crc16、crc32等示例数据，便于对照不同实现方式、生成多项式与校验流程。已有4199人学习下载，适合作为课程实验、项目移植和算法比对的参考素材。读者可从中了解逐位与查表思路、单片机软件优化及硬件CRC模块映射，借助现成工程与测试数据验证结果、排查位序和初值差异，进而提升数据传输与存储校验的实践能力。

1. 调试台上的那两字节：为什么我最后还是回去翻这套 CRC 源代码

去年冬天陪一个做传感器的朋友调板子，协议文档上只写了一句话——“末两字节为 CRC 校验”。他用自己攒的代码算了一晚上，回显帧的最后两个字节总是差一位，抓波形、换串口、怀疑电平都试过，最后发现问题出在参数上：设备用的是 CRC-16/Modbus，初值 0xFFFF、输入输出都反射，而他手里那份是 CCITT-FALSE 的写法。这类事在嵌入式和上位机对接里反复出现，难的不是算法本身，而是 CRC 的参数组合太多，名字还经常被叫混。这套循环冗余校验码计算源代码合集，把 CRC-8 到 CRC-32 的常见变种收敛到一套参数模型下，配了位运算、256 项查表、半字节查表三种实现，以及一份拿来做交叉验证的参考实现。想把校验写进通信协议、固件升级包或者存储块的开发者，照着往下读就能跑通。

2. 源码包结构：一套代码怎么同时装下十几种 CRC 变种

2.1 目录划分：接口、实现、参数表三层拆开

这类 CRC 合集最容易写崩的地方，是每来一个新变种就复制一份 c 文件改两个常量，改到第十份的时候没人记得哪份对应哪个设备。合格的组织方式是按职责切三层：头文件只放接口和参数结构体，实现层放算法本身，参数层用一张常量表描述每个变种。常见做法是这样落地：

crc-collection/ ├── include/ │ └── crc.h # 统一接口 + 参数模型结构体 ├── src/ │ ├── crc_bitwise.c # 逐位实现，任意宽度都能跑 │ ├── crc_table256.c # 256 项查表，速度优先 │ ├── crc_nibble.c # 16 项半字节查表，省 RAM │ └── crc_params.c # 常见变种的参数常量 ├── tools/ │ └── gen_table.py # 生成查找表并输出 C 数组 ├── tests/ │ └── test_vectors.c # 标准测试向量回归 └── Makefile

这一层拆开之后，新增一个变种就只是往参数表里加一行，算法文件一行都不用动。工具目录下那个生成脚本也别忽略，查表法的多项式常量是反的、索引是右移还是左移，靠人脑记迟早出错，让脚本生成数组、粘贴进源码，比手抄可靠得多。

2.2 统一参数模型：一个结构体装下 width、poly、init、refin、refout、xorout

CRC 之所以让人头大，是因为同一个名字下面藏了六个自由参数。业界通用的描述方式来自那份被反复引用的 CRC 参数目录，六个字段分别是：宽度 width、生成多项式 poly（省略最高位那个 1）、寄存器初值 init、输入是否反射 refin、输出是否反射 refout、结果异或值 xorout。把这六个字段固化进结构体，所有变种就变成同一套代码的不同实例：

/* crc.h：参数模型，六个字段决定一个 CRC 变种 */ typedef struct { uint8_t width; /* 校验宽度：8 / 16 / 32，决定掩码和移位量 */ uint32_t poly; /* 生成多项式，省略最高位的 1，如 0x1021 表示 x^16+x^12+x^5+1 */ uint32_t init; /* 寄存器初值，Modbus 是 0xFFFF，XMODEM 是 0x0000 */ uint8_t refin; /* 输入反射：每个字节是否低位先入 */ uint8_t refout; /* 输出反射：最终结果是否整体翻转 */ uint32_t xorout; /* 结果异或值，CRC-32 靠它做全 1 翻转 */ } crc_params_t; /* 统一入口：参数 + 数据 + 长度，返回宽位掩码后的结果 */ uint32_t crc_compute(const crc_params_t *p, const uint8_t *data, size_t len);

有了这个结构体，参数表就变得很短，看起来一目了然：

/* crc_params.c：常用变种，新增设备照着格式加一行 */ const crc_params_t CRC16_MODBUS = {16, 0x8005, 0xFFFF, 1, 1, 0x0000}; const crc_params_t CRC16_CCITT_FALSE = {16, 0x1021, 0xFFFF, 0, 0, 0x0000}; const crc_params_t CRC16_XMODEM = {16, 0x1021, 0x0000, 0, 0, 0x0000}; const crc_params_t CRC32_ISO_HDLC = {32, 0x04C11DB7, 0xFFFFFFFF, 1, 1, 0xFFFFFFFF};

参数说明上要留神两个点。poly 是省略最高位的写法，CRC-16 的多项式 x^16+x^12+x^5+1 记作 0x1021，别写成 0x11021，宽度 16 存不下。refin 和 refout 在绝大多数变种里取值相同，但标准里允许不同，通用实现必须分开处理，不能图省事合成一个 flag。这两条如果写反，表现出来的现象就是“算法看着没错，结果就是差一位”。

2.3 三种实现路径的取舍：位运算、256 项查表、半字节查表

同一套参数，算法可以有三份实现，各自对应不同场景。逐位实现最慢但最通用，它不依赖查找表，宽度从 8 到 32 都能算，适合当“标准答案”用来对照；256 项查表最快，一个字节一步，代价是 1KB 的表空间（宽度 32 时）；半字节查表是折中，一次处理 4 位，表只有 16 项，64 字节 RAM 就能放下，速度大概是逐位的三倍多。

选择上有个朴素的经验：上位机、服务器侧、文件校验这些场景，内存不是问题，直接上 256 项表；MCU 上的通信协议，尤其 RAM 只有几 KB 的小片子，用半字节表；如果只是启动时校验一次固件头，数据量不到几十字节，逐位实现反而最省事，连表初始化都省了。

提示：三种实现必须共用同一个参数结构和同一组测试向量，否则改完查表版发现和逐位版对不上，排查成本会翻倍。

3. 核心算法拆解：从 8 次移位到一张表

3.1 位运算版：一个字节到底被移了几次

逐位实现的逻辑其实很短，短到很多人第一次看会怀疑它是不是漏了什么。核心就三步：把当前字节异或进寄存器高位、循环 8 次判断最高位决定是否异或多项式、最后按 refout 和 xorout 做收尾。

/* crc_bitwise.c：通用逐位实现，所有变种共用 */ static uint32_t reflect_bits(uint32_t v, uint8_t bits) { uint32_t r = 0; for (uint8_t i = 0; i < bits; i++) { r = (r << 1) | (v & 1u); /* 从最低位往最高位搬 */ v >>= 1; } return r; } uint32_t crc_bitwise(const crc_params_t *p, const uint8_t *data, size_t len) { const uint32_t mask = (p->width == 32) ? 0xFFFFFFFFUL : ((1UL << p->width) - 1); const uint32_t topbit = 1UL << (p->width - 1); uint32_t crc = p->init & mask; for (size_t i = 0; i < len; i++) { uint8_t byte = data[i]; if (p->refin) byte = (uint8_t)reflect_bits(byte, 8); /* 输入反射 */ crc ^= (uint32_t)byte << (p->width - 8); /* 对齐到高位 */ for (int b = 0; b < 8; b++) { if (crc & topbit) crc = (crc << 1) ^ p->poly; else crc = (crc << 1); crc &= mask; /* 每次移位后截断 */ } } if (p->refout) crc = reflect_bits(crc, p->width); /* 输出反射 */ return (crc ^ p->xorout) & mask; }

逐行说明一下。mask用来把寄存器限制在声明宽度内，宽度 16 时是 0xFFFF，少了这一步，左移会把高位残留进来，结果必然错。topbit是被移出去的那一位，它决定这一轮要不要异或多项式，这是 CRC 多项式除法的本质。byte << (width - 8)把输入字节对齐到寄存器最高字节，宽度 8 时移位量是 0，也成立。注意这个写法隐含 width ≥ 8 的前提，CRC-5、CRC-7 这类窄宽度变种得单独处理对齐，别直接套。

反射的处理顺序也值得说一句。refin 是对每个输入字节单独翻转，refout 是对最终结果整体翻转，两者位置不能互换。有人图省事在返回前统一反射一次，对 refin == refout 的变种结果恰好一样，但遇到两者不同的变种就翻车——这类 bug 往往等到换设备才暴露。

3.2 256 项查表：表里的每个数字是怎么来的

查表法不是什么新算法，它只是把“一个字节异或进寄存器再移 8 次”这个过程提前算好，存成 256 个数。查表的时候一个字节一步，移位 8 次的工作交给了表项。

非反射版的表生成逻辑是这样的：

/* gen_table.c 的核心：为指定多项式和宽度生成 256 项表 */ uint32_t table[256]; void build_table(uint32_t poly, uint8_t width) { uint32_t mask = (width == 32) ? 0xFFFFFFFFUL : ((1UL << width) - 1); uint32_t topbit = 1UL << (width - 1); for (uint32_t i = 0; i < 256; i++) { uint32_t crc = (i << (width - 8)) & mask; /* 把索引放到高位 */ for (int b = 0; b < 8; b++) { crc = (crc & topbit) ? ((crc << 1) ^ poly) : (crc << 1); crc &= mask; } table[i] = crc; /* 存的是处理完这一字节后的贡献值 */ } } /* 查表计算：一个字节一步 */ uint32_t crc_table(const crc_params_t *p, const uint8_t *data, size_t len) { uint32_t crc = p->init & mask_of(p->width); for (size_t i = 0; i < len; i++) { uint8_t idx = (uint8_t)((crc >> (p->width - 8)) ^ data[i]); crc = ((crc << 8) & mask_of(p->width)) ^ table[idx]; } return (crc ^ p->xorout) & mask_of(p->width); }

索引的算法是(crc >> (width - 8)) ^ byte，取的是寄存器最高字节和输入字节异或，物理意义就是“当前余数的高 8 位参与下一轮除法”。移位量width - 8必须跟着宽度走，16 位是右移 8，32 位是右移 24，写死成 8 是新手最容易犯的错。

反射版变种（CRC-32、CRC-16/Modbus 这些）的表不太一样，表项生成时用的是反射后的多项式，索引和移位方向也整个镜像过来：

/* 反射表：CRC-32 用的多项式是 0x04C11DB7 的位反转 0xEDB88320 */ void build_table_reflected(uint32_t poly_reflected) { for (uint32_t i = 0; i < 256; i++) { uint32_t crc = i; for (int b = 0; b < 8; b++) crc = (crc & 1u) ? ((crc >> 1) ^ poly_reflected) : (crc >> 1); table_ref[i] = crc; } } /* 反射版查表：右移 8 位，索引取低字节 */ uint32_t crc32_table_reflected(const uint8_t *data, size_t len) { uint32_t crc = 0xFFFFFFFFu; /* init */ for (size_t i = 0; i < len; i++) crc = (crc >> 8) ^ table_ref[(crc ^ data[i]) & 0xFF]; return crc ^ 0xFFFFFFFFu; /* xorout */ }

把这两份表放在一起看，能明白一个关键点：反射版不是“算完再翻转”，而是从多项式到移位方向全部镜像。所以拿0x04C11DB7去生成反射表，结果一定错，必须换成位反转后的0xEDB88320。这个坑我见过太多次，表现是 CRC-32 与标准库结果完全对不上，但 CRC-16 又正常（因为 16 位那份表是别人给现成的）。

3.3 半字节查表与参考实现：小 RAM 场景和交叉验证

半字节表的存在意义只有一个：省空间。16 项表在 32 位宽度下占 64 字节，比 256 项表小 16 倍，对 RAM 紧张的 MCU 很友好，代价是速度降到查表法的四成左右。写法上是把一次 8 位移位拆成两次 4 位：

/* crc_nibble.c：16 项表，一次处理半个字节 */ uint32_t crc_nibble(const crc_params_t *p, const uint8_t *data, size_t len) { uint32_t crc = p->init; uint32_t mask = (p->width == 32) ? 0xFFFFFFFFUL : ((1UL << p->width) - 1); for (size_t i = 0; i < len; i++) { crc ^= (uint32_t)data[i] << (p->width - 8); /* 字节先进高位 */ for (int n = 0; n < 2; n++) { /* 两轮，每轮 4 位 */ uint8_t idx = (uint8_t)((crc >> (p->width - 4)) & 0x0F); crc = ((crc << 4) & mask) ^ nibble_table[idx]; } } return (crc ^ p->xorout) & mask; }

索引取的是寄存器高 4 位，(width - 4)这个移位量同样跟宽度走。每轮先左移 4 再异或表项，顺序不能反过来，否则高位会被表项污染。

再说参考实现。这类合集里一般会附一份 Python 版本，功能上没什么性能追求，唯一的作用是对拍：同一组参数、同一段数据，C 和 Python 两边结果必须一致，不一致就说明有一边写错了。我常用的是这种纯参数化写法：

# crc_ref.py：参数化参考实现，用来和 C 版对拍 def reflect(value, bits): result = 0 for _ in range(bits): result = (result << 1) | (value & 1) value >>= 1 return result def crc_generic(data, width, poly, init, refin, refout, xorout): mask = (1 << width) - 1 topbit = 1 << (width - 1) crc = init & mask for byte in data: if refin: byte = reflect(byte, 8) crc ^= byte << (width - 8) for _ in range(8): crc = ((crc << 1) ^ poly) & mask if (crc & topbit) else (crc << 1) & mask if refout: crc = reflect(crc, width) return (crc ^ xorout) & mask if __name__ == "__main__": print(hex(crc_generic(b"123456789", 16, 0x8005, 0xFFFF, True, True, 0x0000))) # 0x4b37 print(hex(crc_generic(b"123456789", 32, 0x04C11DB7, 0xFFFFFFFF, True, True, 0xFFFFFFFF))) # 0xcbf43926

这段代码的价值不在跑得快，而在“没有任何优化痕迹，每一步都能对着标准文档核”。当 C 版查表实现和硬件 CRC 外设结果不一致时，先跑这段 Python，就能立刻判断是算法写错还是外设配置错。这个习惯救过我两次，一次是外设配错了反射位，一次是数据长度传成了字节数的一半。

4. 把代码跑起来：编译、测试向量与参数配置

4.1 编译与最小可运行示例

这套代码没有第三方依赖，标准 C99 加一个 Makefile 就能编。上手第一步别急着接协议，先编译跑通一个最小例子，确认工具链和头文件路径没问题：

# 编译静态库和测试程序 make clean && make # 或者手动编一个最小例子 gcc -std=c99 -Iinclude -o demo demo.c src/crc_bitwise.c src/crc_table256.c src/crc_params.c ./demo

demo.c里不用写复杂逻辑，算一段固定字符串、打印十六进制结果就够了：

#include <stdio.h> #include "crc.h" extern const crc_params_t CRC16_MODBUS; extern const crc_params_t CRC32_ISO_HDLC; int main(void) { const uint8_t msg[] = "123456789"; /* 9 字节，标准测试串 */ uint32_t a = crc_compute(&CRC16_MODBUS, msg, 9); uint32_t b = crc_compute(&CRC32_ISO_HDLC, msg, 9); printf("CRC-16/Modbus = 0x%04X (expect 0x4B37)\n", a); printf("CRC-32 = 0x%08X (expect 0xCBF43926)\n", b); return 0; }

参数说明一下。crc_compute的第一个参数是参数结构体指针，直接传常量地址，不用拷；第二个是数据首地址，uint8_t*保证不会因为char的符号性出岔子；第三个是字节数，不是元素个数，sizeof(msg)/sizeof(msg[0])这种写法没错，但传字符串字面量时别把结尾的\0算进去。打印格式%04X和%08X用来对齐宽度，调试时比看十进制直观得多。

编译通过、输出和注释里的期望值对上，这一步才算完。对不上就别往下走了，先把参数表那一行核一遍——十有八九是 poly 或 init 抄错。

4.2 标准测试向量：一组 “123456789” 打天下

CRC 圈子有个约定俗成的测试串，就是 ASCII 的123456789，九个字节，每个变种都有一个官方 check 值。把这张表存进测试程序，每次改动代码跑一遍，比什么都靠谱：

写回归测试的时候，把这张表做成结构体数组，循环跑三种实现，断言三者结果都等于 check。数组里每加一个变种，三种实现就自动被测一遍，这比写一堆 if 判断省事得多：

typedef struct { const char *name; const crc_params_t *params; uint32_t check; /* "123456789" 的期望值 */ } vector_t; static const vector_t vectors[] = { {"CRC-16/Modbus", &CRC16_MODBUS, 0x4B37}, {"CRC-16/CCITT-FALSE", &CRC16_CCITT_FALSE, 0x29B1}, {"CRC-32", &CRC32_ISO_HDLC, 0xCBF43926}, }; for (size_t i = 0; i < sizeof(vectors)/sizeof(vectors[0]); i++) { uint32_t r = crc_compute(vectors[i].params, (const uint8_t *)"123456789", 9); assert(r == vectors[i].check); /* 三种实现各断言一次 */ }

提示：CRC-32C 的多项式是 0x1EDC6F41，和 CRC-32 的 0x04C11DB7 完全不同，check 值也不一样。iSCSI、ext4 这些场景用的是 C 版，别混用。

4.3 新增一个变种：改参数还是加代码

对接新设备时，面对一份只写了“CRC16 校验”的协议文档，第一步是从文档里把六个参数抠出来，抠不出来的话就试。试的办法很土但有效：拿设备返回的一段已知报文，用测试向量表里所有 16 位变种跑一遍，哪个对得上就用哪个。

如果设备用的是表里没有的变种，两种处理方式。参数能凑出来的，直接往crc_params.c加一行常量，算法层一行不动；宽度不是 8 的整数倍（比如某些 CAN 协议用 CRC-15），才需要动位运算实现里的对齐逻辑。我一般会先加常量，跑标准测试串看能不能对上某个已知 check 值，对不上再判断是不是宽度问题，避免一上来就改算法。

配置层面还有个小细节：如果项目里只用一个变种，完全可以把参数结构体优化成宏，省掉一次间接寻址。但别一开始就这么干，等确认变种固定了再优化，否则换设备时又要改回来。

5. 踩坑与排查：反射、掩码、字节序最容易翻车

5.1 移植阶段：四个高频翻车点

现象一：CRC-32 的结果和 zlib 里的 crc32 永远差一个固定值。原因通常是反射处理只做了一半——查表实现用了反射多项式 0xEDB88320，但收尾时的 xorout 忘了加，或者加了两次。解决方式是把最终返回值固定写成crc ^ 0xFFFFFFFF且只写一处，中间过程不碰它；再用标准测试串对一遍，确认得到 0xCBF43926。

现象二：16 位变种在 MCU 上结果正确，换到上位机就错。原因多半是类型问题。C 里int是 32 位，左移 16 位以上不会溢出，但有人为了省空间把寄存器声明成uint16_t，移位后高位直接丢掉，和不截断的算法就对不上了。解决方式是寄存器统一用uint32_t，宽度靠 mask 控制，别用窄类型硬扛。

现象三：查表版对，半字节版偶发错。原因通常是索引没掩码。(crc >> (width - 4)) & 0x0F里的& 0x0F少写一次，索引就可能超过 15，读到表外面去了，结果时对时错，全看内存里放的是什么。解决办法是把表长定义成宏NIBBLE_TABLE_SIZE 16，索引取完再做一次范围断言，调试期把问题暴露出来。

现象四：Modbus 从机回帧校验总是不过，抓包看 CRC 值是对的。这是字节序问题。Modbus 的 CRC 是低字节先发，而很多人按习惯先发高字节，值本身没错，顺序反了。解决方式是在组帧函数里显式拆成两个字节：buf[n] = crc & 0xFF; buf[n+1] = (crc >> 8) & 0xFF;，不要图省事直接 memcpy 一个 16 位变量过去，那样结果依赖 CPU 大小端，换平台就变。

5.2 上线前自检：增量校验和一次性校验必须对齐

协议栈里经常需要边收边算，也就是把数据分几段喂给 CRC，最后出一个总结果。这种增量接口最容易出的问题是 init 和 xorout 被重复执行：每段都初始化一次，或者每段结束都异或一次 xorout，分段算出来的值和一次性算出来的就对不上。

正确的做法是把状态和收尾拆开：

/* 增量接口：update 只推进状态，final 才做反射和异或 */ typedef struct { const crc_params_t *p; uint32_t state; } crc_ctx_t; void crc_init(crc_ctx_t *ctx, const crc_params_t *p) { ctx->p = p; ctx->state = p->init; /* 初值只在这里赋一次 */ } void crc_update(crc_ctx_t *ctx, const uint8_t *data, size_t len) { /* 内部只推进 state，不碰 xorout，也不做 refout */ } uint32_t crc_final(crc_ctx_t *ctx) { uint32_t r = ctx->state; if (ctx->p->refout) r = reflect_bits(r, ctx->p->width); return (r ^ ctx->p->xorout) & mask_of(ctx->p->width); /* 收尾只做一次 */ }

自检方法很直接：把同一段 100 字节数据分别按“一次性算”和“拆成 1+9+90 三段算”跑一遍，结果必须相同。这个用例我建议直接写进单元测试，因为增量接口的 bug 往往在长时间跑数据时才暴露，等到上线再查就贵了。

6. 二次开发：把 CRC 模块接到协议栈里的三个改造点

第一处改造是帧格式。CRC 单独算没有意义，它总是挂在一个帧结构上。我一般会把组帧和校验封成一对函数，帧头、长度、载荷、CRC 四段拼装，接收侧先按长度字段截取，再只对“参与校验的那部分”算 CRC。这里有个容易忽略的点：帧头要不要参与校验，不同协议规定不一样，参数化成一个 offset 和 length，比写死灵活。

/* 组帧：载荷在前，CRC 追加在后，低字节先发（Modbus 风格） */ size_t frame_pack(uint8_t *out, const uint8_t *payload, size_t len, const crc_params_t *p) { out[0] = 0xAA; /* 帧头，是否参与校验看协议 */ out[1] = (uint8_t)len; memcpy(&out[2], payload, len); uint32_t crc = crc_compute(p, out, len + 2); /* 帧头+长度+载荷一起算 */ out[2 + len] = (uint8_t)(crc & 0xFF); out[2 + len + 1] = (uint8_t)((crc >> 8) & 0xFF); return len + 4; }

第二处是硬件 CRC 外设的交叉验证。很多 MCU 自带 CRC 单元，速度快但配置项少，反射和初值经常不支持自由设置。我的做法是保留软件实现作为基准，上电自检时用同一段数据分别跑硬件和软件，结果不一致就直接标记硬件不可用、回退到软件路径。这段自检代码不到二十行，但能挡住“换了个型号外设行为不同”这类问题。

第三处是测试闭环。参数表、标准向量、三种实现，这三样凑齐之后，二次开发的安全性就有底了。我的习惯是每接一个新协议，先把参数写进表，跑一遍123456789的标准 check，再拿一段真实报文验证，两步都过才接进主流程。从那以后我每次改 CRC 相关代码，不管改动多小，都强制走一遍“测试向量 + 分段一致性”这两道检查——血泪经验换来的一条规矩，省下的调试时间远超写测试花的那点功夫。希望帮到你。

本文还有配套的精品资源，点击获取