CRC计算源代码怎么用：参数模型、按位与查表实现避坑

简介这是一套面向嵌入式开发、通信协议调试与数据校验学习者的循环冗余校验码CRC计算源码合集覆盖从原理理解到工程落地的常见需求。压缩包共1220个文件约6.65MB以C语言源码和汇编实现为核心辅以Keil、Visual Studio等工程文件与编译产物并包含hex、lst、m51等烧录与列表文件以及crc8、crc16、crc32等不同位宽算法的示例代码目录按算法与平台分块便于按芯片环境和校验宽度检索对照。已有4201人学习下载说明其在CRC入门与项目参考中具备一定认可度。读者可从中获得多种CRC算法的实现思路、生成多项式与寄存器移位处理的具体写法以及单片机环境下的软件优化与硬件模块映射参考配合测试数据和工程配置可用于验证算法正确性、比较不同实现的资源占用与性能并作为文件校验、串口通信、存储校验等场景的移植基础。1. 一份 CRC 源码能不能直接用先看它把哪几个参数写死了串口调试助手发出去的数据对方一直报校验错抓包一比对CRC 字段高低字节反了换到另一台设备上又能对上因为那边的循环冗余校验码计算源代码用的是反射版本。这类问题在嵌入式联调里出现的频率不低最后查下来往往不是算法本身难而是参数模型没对齐。这份 CRC 计算源代码合集解决的就是这件事它把 CRC-8、CRC-16、CRC-32 几种常见参数模型的实现集中到一起按位版和查表版都有C 与 Python 都能找到对应写法。适合正在做通信协议、固件升级包校验、存储扇区完整性检查的从业者也适合刚接触模 2 除法、想拿一份能直接编译运行的代码对照理解的新手。真正要抄之前先确认它把 Poly、Init、RefIn、RefOut、XorOut 这五个值写死成了哪一种否则编译通过也只是碰巧对上。2. CRC 参数模型七个字段决定算法身份少对上一个就全错2.1 多项式与位宽模 2 除法到底在除什么CRC 的计算过程本质上是把数据比特流看成一个 GF(2) 上的多项式乘以 x 的 W 次幂之后对生成多项式做模 2 除法余数就是校验值。模 2 除法的加减法都是异或没有借位和进位所以硬件实现只需要移位寄存器和异或门。位宽 W 决定了寄存器的位数也决定了生成多项式最高位的隐含位置。源码里写的 Poly 值通常是去掉最高位的 W 位形式。以 CRC-32 为例完整多项式是 x^32 x^26 x^23 x^22 x^16 x^12 x^11 x^10 x^8 x^7 x^5 x^4 x^2 x 1源码里写的是 0x04C11DB7最高位的 x^32 被省掉了因为在移位过程中它由寄存器溢出位隐含体现。CRC-16/CCITT 写 0x1021CRC-16/MODBUS 写 0x8005CRC-8 写 0x07都是同样的省略规则。这个省略规则带来一个常见误解有人拿着十六进制多项式去和源码里的常量对发现少了一位以为代码写错了。实际不是。判断一份源码用的是哪个多项式看它异或的那个常量如果代码里出现 0x1021、0x8005、0x04C11DB7 这类值基本能反推出位宽和标准族。位宽还决定了移位时的掩码。W 位寄存器的有效范围是 0 到 (1W)-1代码里常见crc 0xFFFF或crc 0xFFFFFFFF少了这一步高位溢出会污染结果。用 Python 写通用实现时尤其要注意Python 的整数没有固定宽度左移会无限增长必须手动掩码。2.2 初值、异或输出与反射三个最容易抄错的开关Init 是寄存器的初始值常见取值是 0x0000、0xFFFF、0xFFFFFFFF。初值不为零的作用是让前导零也参与运算避免数据开头补零不影响校验值。很多协议规定 Init 为全 1就是为了让接收端在没收到任何字节时也有一个非零的中间状态。XorOut 是最终结果输出前做的异或常见取值是 0x0000 或全 1。它和 Init 全 1 配合使用时能让 CRC 对数据长度变化更敏感。CRC-32/ISO-HDLC 的 Init 和 XorOut 都是 0xFFFFFFFF这两个全 1 不是随便定的互换或者只改一个都会让 check 值变掉。RefIn 和 RefOut 是最容易翻车的两个开关。RefIn 为真时每个输入字节在进入算法前先按位反转实际效果等价于用反转后的多项式从最低位开始算。RefOut 为真时最终余数在异或输出前先反转。工程上这两个开关绝大多数时候同时为真或同时为假但不是强制绑定某些老协议会出现只开一个的情况。这里有一个血泪经验很多人看到 RefOut 为真就在最后加一句crc reverse(crc)却忘了 RefIn 也要处理结果就是对短数据碰巧能对上对长数据越算越偏。反射版本的正确写法是把多项式也反转移位方向改成右移从最低位判断。CRC-16/MODBUS 用的 0xA001 就是 0x8005 的 16 位反转这个对应关系在源码里经常被注释掉看不到就很容易改错。2.3 常见标准速查把名字和五个参数对上号协议文档里经常只写“CRC-16”三个字这时候不能猜得拿参数表去对。下面这张表覆盖了工程里出现频率最高的几种模型Check 列是对字符串1234567899 个 ASCII 字节不含引号计算出的结果可以直接拿来验算。名称位宽PolyInitRefInRefOutXorOutCheckCRC-8/SMBUS80x070x00falsefalse0x000xF4CRC-8/MAXIM-DOW80x310x00truetrue0x000xA1CRC-16/ARC160x80050x0000truetrue0x00000xBB3DCRC-16/MODBUS160x80050xFFFFtruetrue0x00000x4B37CRC-16/CCITT-FALSE160x10210xFFFFfalsefalse0x00000x29B1CRC-16/XMODEM160x10210x0000falsefalse0x00000x31C3CRC-32/ISO-HDLC320x04C11DB70xFFFFFFFFtruetrue0xFFFFFFFF0xCBF43926选型的时候先看对端设备或者文件格式的文档文档没写全就用 Check 值反推。反推的方法是固定数据123456789把候选模型的参数代进去看结果和文档给的示例帧 CRC 是否一致。如果文档连示例帧都没有只能拿一帧真实报文去试试的时候保持数据范围一致别把帧头算进去或者漏算。2.4 用 check 值给源码做体检拿到一份 CRC 源码第一件事不是读它的循环而是跑一遍123456789。下面这段 Python 是按位实现的通用版本参数全部开放可以直接用来对照合集里任意一份实现。def reflect(value, bits): 把 value 的低 bits 位按位反转 result 0 for i in range(bits): if value (1 i): result | 1 (bits - 1 - i) return result def crc_compute(data, width, poly, init, refin, refout, xorout): width: 位宽8/16/32 poly: 省略最高位的生成多项式 init: 寄存器初值 refin: 输入字节是否反转 refout:输出余数是否反转 xorout:输出前异或的值 topbit 1 (width - 1) mask (1 width) - 1 crc init mask for byte in data: if refin: byte reflect(byte, 8) crc ^ (byte (width - 8)) # 字节对齐到寄存器高位 for _ in range(8): if crc topbit: crc ((crc 1) ^ poly) mask else: crc (crc 1) mask if refout: crc reflect(crc, width) return (crc ^ xorout) mask if __name__ __main__: data b123456789 # 三个 check 值对应上表中的三个标准模型 print(hex(crc_compute(data, 8, 0x07, 0x00, False, False, 0x00))) # 0xf4 print(hex(crc_compute(data, 16, 0x8005, 0xFFFF, True, True, 0x0000))) # 0x4b37 print(hex(crc_compute(data, 16, 0x1021, 0xFFFF, False, False, 0x0000))) # 0x29b1 print(hex(crc_compute(data, 32, 0x04C11DB7, 0xFFFFFFFF, True, True, 0xFFFFFFFF))) # 0xcbf43926这段代码里byte (width - 8)是把 8 位字节对齐到 W 位寄存器的高端这是非反射算法的标准写法反射算法则由refin分支先把字节反转再走同样的高位对齐逻辑。topbit用来判断当前余数最高位是否为 1为 1 才需要异或多项式。最后 mask不能省Python 里左移会无限扩位不掩码会导致高位一直累积。这段实现假设width 8。位宽小于 8 的 CRC比如 CRC-4、CRC-5不能直接套这个模板因为width - 8会变成负数移位方向要单独处理。合集里如果包含小位宽实现验证时别拿这段代码去对会误判成源码有错。跑通之后把输出和标准 Check 值逐个对照。三个都对上说明这份实现的参数处理和反射逻辑没问题可以接着看它的接口设计有一个对不上先查 RefIn/RefOut 有没有写反再查掩码有没有漏。3. 两种实现路线按位算法打底查表法换速度3.1 按位实现一次一位把移位方向讲透按位实现是最容易读懂的版本也是查表法的表生成基础。下面以 CRC-16/MODBUS 为例写一份不依赖任何库的 C 实现。#include stdint.h #include stddef.h uint16_t crc16_modbus_bitwise(const uint8_t *data, size_t len) { uint16_t crc 0xFFFF; /* Init寄存器初值 */ for (size_t i 0; i len; i) { crc ^ data[i]; /* 反射算法字节从最低位进入 */ for (int b 0; b 8; b) { if (crc 0x0001) { /* 反射算法判断最低位 */ crc (uint16_t)((crc 1) ^ 0xA001); /* 0xA001 是 0x8005 的 16 位反转 */ } else { crc 1; } } } return crc; /* XorOut0x0000RefOut 已在过程中体现 */ }这段代码有三个关键点。第一crc ^ data[i]是把数据字节直接异或到寄存器低 8 位这是反射算法的写法非反射算法要写成crc ^ (uint16_t)data[i] 8。第二判断位是0x0001而不是0x8000右移而不是左移这是反射算法和多项式反转配套的结果。第三0xA001不是随便写的常量它是 0x8005 按位反转得到的两者描述的是同一个多项式只是计算方向相反。为什么反射算法要用反转多项式直观理解是非反射算法从数据最高位开始处理多项式也按高位对齐反射算法从数据最低位开始处理相当于把整个运算镜像过来多项式自然也要镜像。源码里如果同时出现 0x8005 和右移那就是写错了结果一定对不上 MODBUS 的 Check 值。按位实现的优点是代码短、可读性好、不需要额外内存适合 Flash 紧张的小容量 MCU也适合作为查表法生成表的参考实现。缺点是每个字节要循环 8 次32 位 CRC 在低主频芯片上跑大包会比较吃力。3.2 查表实现256 项表怎么生成、放哪里查表法的思路是把“一个字节 8 次移位”提前算好存成 256 项的表运行时每个字节只做一次查表和一次异或。表的生成方式有两种用按位算法对 0 到 255 每个值跑一遍或者用移位加条件异或直接构造。下面这份是反射版 MODBUS 的表生成和查表实现。#include stdint.h #include stddef.h static uint16_t modbus_table[256]; /* 启动时调用一次生成 256 项查表 */ void crc16_modbus_table_init(void) { for (int i 0; i 256; i) { uint16_t crc (uint16_t)i; /* 反射版字节从低位进入 */ for (int b 0; b 8; b) { if (crc 0x0001) { crc (uint16_t)((crc 1) ^ 0xA001); } else { crc 1; } } modbus_table[i] crc; } } uint16_t crc16_modbus_table(const uint8_t *data, size_t len) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { /* 当前余数低字节与数据字节异或结果作为表索引 */ crc (uint16_t)((crc 8) ^ modbus_table[(crc ^ data[i]) 0xFF]); } return crc; }索引表达式(crc ^ data[i]) 0xFF的含义是把当前余数的低 8 位和数据字节异或得到一个 0 到 255 的值用这个值查表再把余数右移 8 位和查表结果异或。移位的方向和表生成时保持一致反射版右移非反射版左移并用(crc (width - 8))取高字节做索引。非反射版的表生成稍有不同字节要放到高位static uint16_t ccitt_table[256]; void crc16_ccitt_table_init(void) { for (int i 0; i 256; i) { uint16_t crc (uint16_t)(i 8); /* 非反射版字节放高位 */ for (int b 0; b 8; b) { if (crc 0x8000) { crc (uint16_t)((crc 1) ^ 0x1021); } else { crc 1; } } ccitt_table[i] crc; } }这两份表不能混用。反射表配反射查表逻辑非反射表配非反射查表逻辑混了之后结果看着像 CRC 但又对不上任何标准值是最难查的一类问题。判断方法很简单看表生成时字节是(uint16_t)i还是(uint16_t)(i 8)前者配右移后者配左移。表放在哪里也有讲究。256 项 uint16_t 占 512 字节256 项 uint32_t 占 1024 字节对 RAM 只有几 KB 的芯片不算小。常见做法是把表声明为const放在 Flash启动时算一次写进 RAM 副本如果连 RAM 副本都放不下就直接在 Flash 里查速度慢一点但省内存。还有一种折中方案是 16 项 nibble 表每次处理 4 位内存占用降到 32 字节或 64 字节速度比按位快、比 256 项表慢适合资源卡得很死的场景。3.3 按位与查表的取舍速度、空间和可读性三种实现放在一起对比选择依据就清楚了。实现方式表大小每字节操作典型耗时72MHz MCU1KB 数据适用场景按位08 次移位判断数百微秒Flash 极小、数据量小、教学对照16 项 nibble 表32/64 字节2 次查表数十微秒RAM 紧张、中等数据量256 项字节表512/1024 字节1 次查表几微秒到十几微秒通信协议、固件校验、大包为主耗时那一列是量级参考具体数值跟编译器优化、Flash 等待周期、数据是否在缓存里都有关系别拿它当精确 benchmark。真正要选的时候看两个约束RAM 余量和单帧最大长度。一帧几十字节的传感器协议按位实现完全够用没必要为了省几微秒塞一张表一帧几 KB 的固件升级包查表法的优势才明显。还有一点容易被忽略查表法的代码体积比按位法大因为表本身占 Flash。如果芯片 Flash 只有 8KB256 项 uint32_t 表就吃掉 1KB加上其他代码可能就紧张了。这种时候 nibble 表是更合理的选择用两次查表换 16 分之一的表空间。4. 接进工程整块、流式、帧内三种调用形态4.1 整块计算入参、长度与返回类型整块计算的接口最直接传指针和长度返回校验值。看起来没什么可设计的但落地时几个细节会决定它好不好用。#include stdint.h #include stddef.h /* * 返回值CRC 结果 * data数据起始地址允许为 NULL 当 len 为 0 * len 数据长度单位字节 */ uint16_t crc16_modbus(const uint8_t *data, size_t len) { uint16_t crc 0xFFFF; if (data NULL) { return crc; /* 空数据返回初值调用方自行决定是否接受 */ } for (size_t i 0; i len; i) { crc ^ data[i]; for (int b 0; b 8; b) { crc (crc 0x0001) ? (uint16_t)((crc 1) ^ 0xA001) : (uint16_t)(crc 1); } } return crc; }长度参数用size_t而不是int避免大包时符号溢出指针加const表明函数不会修改输入缓冲区空指针在长度为 0 时返回初值这是一个约定调用方要么在调用前判空要么接受这个行为并在协议层处理。返回值用uint16_t而不是int防止调用方拿去做有符号比较时出现负数。这一层最容易被误用的是“数据范围”。计算范围必须和对端严格一致只算载荷还是连帧头一起算算不算长度字段算不算 CRC 字段本身。这些在协议文档里通常有一句话漏看就会导致整帧校验永远失败。4.2 流式续算init/update/final 三段式通信收包往往不是一个完整缓冲区而是中断里一个字节一个字节进来或者 DMA 分几次搬完。这时候需要流式接口把计算状态保存在上下文结构里。#include stdint.h #include stddef.h typedef struct { uint16_t crc; /* 当前余数跨多次 update 保留 */ } crc16_ctx_t; void crc16_stream_init(crc16_ctx_t *ctx) { ctx-crc 0xFFFF; /* Init 只在这里做一次 */ } void crc16_stream_update(crc16_ctx_t *ctx, const uint8_t *data, size_t len) { for (size_t i 0; i len; i) { ctx-crc ^ data[i]; for (int b 0; b 8; b) { ctx-crc (ctx-crc 0x0001) ? (uint16_t)((ctx-crc 1) ^ 0xA001) : (uint16_t)(ctx-crc 1); } } } uint16_t crc16_stream_final(crc16_ctx_t *ctx) { return ctx-crc; /* XorOut0直接返回CRC-32 要在这里异或 */ }三段式的关键是职责分离init只设置初值update可以调用任意多次、每次传任意长度final做输出变换。分段计算和整块计算不一致十有八九是init被调了多次或者XorOut在每段都被应用了一次。正确的用法是整条消息只调一次init、若干次update、最后一次final。如果协议是 CRC-32/ISO-HDLC 这种带 XorOut 的模型final里要写return ctx-crc ^ 0xFFFFFFFF;而update里绝不能做这个异或。RefOut 的处理也放在final但要注意如果实现走的是反射路径RefOut 已经在移位方向里体现了final里不能再反转一次。流式接口还有一个隐藏坑上下文结构体如果被memcpy到别处再继续算本身没问题但如果有人图省事把ctx定义成局部变量、在每次update前重新初始化那就退化成每段独立计算结果必然错。4.3 帧内 CRC字节序、字段位置与传输前的自检算出来的 CRC 值要放进帧里放的时候涉及字节序。以 MODBUS RTU 为例CRC 字段在帧尾低字节在前、高字节在后。很多设备文档只写“CRC16 校验”不写字节序联调时就会看到“CRC 值算对了但设备不认”。#include stdint.h #include stddef.h /* * 组一帧帧头 0xAA 长度 载荷 CRC16低字节在前 * out 缓冲区至少需要 len 4 字节 * 返回整帧长度 */ size_t frame_pack(uint8_t *out, const uint8_t *payload, size_t len) { size_t n 0; out[n] 0xAA; out[n] (uint8_t)len; for (size_t i 0; i len; i) { out[n] payload[i]; } /* 计算范围帧头 长度 载荷具体以协议为准 */ uint16_t crc crc16_modbus(out, n); out[n] (uint8_t)(crc 0xFF); /* MODBUS低字节先发 */ out[n] (uint8_t)(crc 8); return n; }接收端的校验逻辑要和发送端严格镜像先按相同范围算 CRC再把帧内两个字节按相同字节序拼回一个 uint16_t最后比较。比较时不要用memcmp去比两个字节数组因为字节序一旦在某一端写反memcmp会给出“两个都不相等”的模糊结果不如拼成整数后直接比较出错时还能把两个值打出来看。如果协议规定 CRC 字段不参与校验接收端计算时要跳过最后两个字节如果协议规定长度字段不参与计算范围要从载荷开始。这些边界在文档里通常写得很细移植源码时不要照抄示例里的范围先翻协议。5. 避坑与排查五类算不对的场景逐个拆5.1 参数模型对不上文档写着 CRC-16 不等于 MODBUS现象用在线工具算出的 CRC 和设备返回的 CRC 不一致换一个在线工具结果又变了。原因文档只写了“CRC-16”没写参数模型。CRC-16/CCITT-FALSE 和 CRC-16/MODBUS 都是 16 位但前者 RefIn/RefOut 为假、初值 0xFFFF后者 RefIn/RefOut 为真、初值 0xFFFF对同一串数据算出的结果完全不同。在线工具默认的模型也各不相同不选参数就会拿到错误答案。解决从设备协议里找全 Poly、Init、RefIn、RefOut、XorOut 五个值找不到就用示例帧反推。反推时固定123456789把候选模型逐个代进去比对示例帧的 CRC 字段。如果连示例帧都没有只能拿一帧真实报文试试的时候保持计算范围一致别把帧头漏掉或者多算。5.2 分段与整块结果不一致状态没继承现象小包一次算完是对的大包分成几片update之后结果和整包算的对不上。原因每片都调了一次init或者每片都做了一次XorOut。前者把上一片的余数清零了后者让异或值被应用了多次。解决检查调用序列确保一条消息只调一次init、update调多次、最后调一次final。如果代码里没有三段式接口只有一个整块函数那就先把分片数据拼成完整缓冲区再算别在中间层自己攒状态。5.3 文本模式读文件导致 CRC 偏移现象对字符串算 CRC 和在线工具一致对二进制文件算出来永远差一点。原因C 里fopen用了r而不是rbWindows 平台会把0x0D 0x0A转换成0x0A文件长度和内容都变了Python 里open(path)默认文本模式同样会做换行转换。解决二进制文件一律用rb或open(path, rb)。读之前用fstat或os.path.getsize确认长度读完之后再核对一次实际读到的字节数两个数对不上就说明读法有问题。5.4 查表法的隐性开销表每次调用都重算现象换成查表实现后跑大包并没有变快甚至比按位版还慢。原因表生成函数被放在了 CRC 计算函数内部每次调用都重新生成 256 项表或者表声明为普通全局变量放在 Flash每次查表都要走一次 Flash 读取没有缓存到 RAM。解决表生成只放在初始化阶段调用一次计算函数里只查表。表用static修饰避免外部误改需要极致性能时在启动时生成一份 RAM 副本计算时查 RAM 副本。如果用的是编译期常量表确认链接脚本里它落在哪个段别不小心放进了速度最慢的存储区。5.5 跨平台移植类型宽度和整型提升现象同一份代码在 32 位 MCU 上结果正确搬到 64 位平台或者换一个编译器后结果变了。原因用了unsigned long而不是uint32_t不同平台上long的宽度不一样或者移位表达式crc 1里crc是uint16_t参与运算时被整型提升为int移位结果超出 16 位后截断行为依赖实现。解决所有 CRC 中间变量用uint16_t、uint32_t这类定宽类型移位后立即强转回原类型比如crc (uint16_t)(crc 1);跨平台传输时不要直接memcpy结构体按字段序列化。这些做法看起来啰嗦但能避免“换台机器就翻车”的玄学问题。6. 验证与进阶用交叉工具和自检向量把实现钉死写完或者抄完一份实现别急着往固件里放先做两层验证。第一层是标准向量拿123456789跑一遍对照第 2 章表里的 Check 值。第二层是边界向量空数据、单字节、全 0x00、全 0xFF、长度刚好跨过内部缓冲区边界的数据。这两层都过基本能排除参数和移位逻辑的错误。如果手头有reveng或pycrc这类命令行工具可以拿它们做交叉验证。做法是用工具按指定参数生成一份参考实现或者直接对同一串数据算出结果和你手上的源码比对。工具的价值在于它把参数模型显式暴露在命令行上逼着你把 Poly、Init、RefIn、RefOut、XorOut 一个个填清楚填的过程本身就是一次参数复核。更工程化的做法是在代码里内置自检。下面这段 C 代码在启动时跑一遍标准向量结果不对就停在错误处理里避免带着错误的 CRC 实现上线。#include stdint.h #include stddef.h #include stdio.h extern uint16_t crc16_modbus(const uint8_t *data, size_t len); /* 启动自检标准向量 空数据边界 */ int crc_self_test(void) { static const uint8_t vector[] 123456789; uint16_t got crc16_modbus(vector, sizeof(vector) - 1); if (got ! 0x4B37) { /* CRC-16/MODBUS 标准 Check 值 */ printf(crc self test failed: got 0x%04X, expect 0x4B37\n, got); return -1; } if (crc16_modbus(NULL, 0) ! 0xFFFF) { /* 空数据应返回初值 */ return -1; } return 0; }自检函数的两个用例分别覆盖“标准数据”和“空数据”两类路径。sizeof(vector) - 1是为了去掉字符串结尾的\0这个细节在 C 里经常被忽略导致算出来的 CRC 和预期差一个字节。空数据用例检查的是init是否被正确返回如果实现里在空指针时直接崩溃或者返回 0这个用例就会失败能提前暴露接口约定问题。对于 32 位 CRC把 Check 值换成 0xCBF43926同时确认final里做了^ 0xFFFFFFFF。如果自检失败先在update里打印第一个字节处理后的中间余数和手工计算的结果比对定位是移位方向错了还是初值错了。中间余数对不上问题在算法中间余数对得上但最终结果不对问题在final的输出变换。从那以后我每次接入一份新的 CRC 实现都先把123456789跑一遍对照 Check 值再拿一帧真实报文从头到尾对一遍两步都对上才敢往固件里放。这个习惯帮我挡掉过好几次“编译通过、短包正常、长包偶发失败”的隐性错误。希望帮到你。本文还有配套的精品资源点击获取