短文标题：CRC校验：Modbus数据帧的“指纹”
【传播知识 手有余香🌹】转发此文到朋友圈 赠送 于振南老师 知识视频合集哦！
你有没有想过一个问题：Modbus-RTU数据帧传输时，可能受干扰出错。接收方怎么知道数据有没有被篡改？答案是：CRC校验。发送方根据数据内容，计算一个16位的“指纹”附在帧尾。接收方收到后，也用同样的算法计算指纹。两个指纹匹配 → 数据正确。不匹配 → 数据被篡改。CRC，就是数据帧的“身份证”。
那个“多项式”的数学，Modbus-RTU用的CRC16，多项式是：x^16 + x^15 + x^2 + 1（0x8005）。不是简单的累加和。累加和太弱——两个字节同时出错（一个+1，一个-1），和不变，错误发现不了。CRC用多项式除法，任何一个bit出错，余数都会变。检测能力比累加和强几个数量级。
那个“模2除法”的计算，CRC的计算过程：
- 把数据看作一个很大的二进制数
- 除以多项式（模2除法——不进位，不借位）
- 余数就是CRC
听起来复杂，但硬件做起来很快。软件可以用查表法。
那个“查表法”的优化，查表法：预先算好256个字节的CRC值。计算时，每个字节查一次表，移位，异或。
uint16_t crc16(uint8_t *buf, int len)
{
uint16_t crc = 0xFFFF;
for (int i = 0; i < len; i++) {
crc = (crc >> 8) ^ crc_table[(crc ^ buf[i]) & 0xFF];
}
return crc;
}
查表比逐位计算快8倍。那个“初始值”的约定Modbus-RTU的CRC初始值是0xFFFF（不是0x0000）。为什么？因为0xFFFF可以检测出数据帧开头的0x00字节。这是协议设计者的“心眼”。那个“字节序”的陷阱CRC16是两个字节，发送时低字节在前，高字节在后。0x1234 → 先发0x34，再发0x12。这是Modbus-RTU的规定。如果你搞反了，校验永远通不过。这是初学者最常见的坑。
那个“错误”的检测能力，CRC16能检测出：
- 所有单bit错误
- 所有双bit错误
- 所有奇数个bit错误
- 所有长度≤16位的突发错误
- 99.9969%的长突发错误
几乎不可能漏检。那个“硬件CRC”的加速有些单片机有硬件CRC模块。只需要把数据喂给硬件，CRC自动算出来。比软件查表更快，不占CPU。STM32的CRC模块，用的是多项式0x04C11DB7，和Modbus不同，需要转换。
这个故事给我们的启示，为什么Modbus要用CRC校验？因为工业现场干扰多。数据传错了，可能会误动作——电机该停时转，阀门该关时开。CRC，就是确保“收到的和发的一样”。它是数据帧的“指纹”。指纹对上了，数据可信。对不上，数据丢弃。
写在最后，下次你用Modbus通信，别只管发数据。想想那个附在帧尾的CRC。它是数据帧的“守护神”。一个字节错了，它都能发现。
（本文灵感源于于振南《新概念ARM32单片机》教程中对CRC校验的深刻讲解，感谢作者将数学在工程中的应用讲得如此通透。）
如果您觉得这个故事对您有启发，欢迎点赞、转发，让更多工程师看到这个藏在CRC背后的“指纹”哲学。关注我，一起探索嵌入式世界里那些“守护数据”的硬核真相。
