labview i2ccrc校验码计算方法

你知道有限域或者模2除法吗？不知道那下面就没法讲了。

CRC算法基于有限域GF(2)，通过在p位数据后附加r位校验构成CRC校验码。r位校验码的生成是由校验数据模哪扰袭2除一个不可约多项式G(x)得到的，G(x)常用取值有420、84210、8541等（每一位数字代表该数字对应的项系数是1）。我通过一个例子简单说明一下算法过程： 假设CRC校验为(7,4)，即7位CRC码，其中4位为数据位，3位为校验位。用于生成的不可约多项式为G(x)=x_+x+1=1011=310。现在需要传输的数据李纳m(x)为1101=x_+x_+1。首先乘以x_，即在后面李兄添3个零，变成1101000。接着计算有限域GF(2)=F2[X]/G(x)下x^6+x^5+x^3的同余式，即用G(x)=1011模2除1101000，得到结果为1111余001，这个余数001就是我们所求的校验码。将余数001添加到原多项式m(x)末尾，变成1101001，这个序列就是最终的CRC校验码。

    最近困扰笔者的是一个通信设备的CRC16（循环冗余校验）的计算问题。设备协议是通过抓包得到的，但是CRC16校验一直不准确，最开始笔者因为CRC校验只有应用于modbus这一种，后来在领导的提点下枝盯握才知道原来CRC16计算有很多公式。笔者在ip33网页上的CRC计算工具上面一个个试，发现居然没有一个是准确的，那就意味着不能准确定位到计算模型。

    那可能只有一种：设备的CRC循环冗余校验是自定义的参数模型。

    无从下手。从设备手册入手，以前看过手册给的C语言的计算方法，笔者以前根据这个计算方法挪到LabVIEW的公式节点(formula node)上计算结果与抓包结果也不一致，当时是放弃了。昨晚又看了一遍具体的说明，重新用公式节点编写手册中的计算方法，还是不准确！根据手册内的蛛丝马迹，最开始笔者以为是那里面的byte0没有写清除，于是加上DLE数据通信换码符（\），不对；加上确认06字符，不对；改变字节数组的顺序，还是不对。

    今天带娃期间，笔者也一直在想这个问题。今晚哄娃睡觉后，笔者再次打开昨晚写的公式节点，和以前的MODBUS CRC对比了一下，突然发现一个问题：公式节点不支持指针，公式节点照搬C语言时，自增i的问题，笔者将其写成了db = bufp[i++]，  i重复自增了。C语言指针自增定位到字节数组的每一个字节，但是 bufp[i]已经在for循环中自增了。

    不动脑子的后果！ 同时在这一次计算中，笔者在数据 *** 作中发现了两个函数：交换字节和交换字。还记得以前高低字节交换花了很大力气猛庆，移位啥的再组合，现在一个函数搞定，交换字可以交换高低16位的数字。

    有时候是需要一点灵感的，还记得大学毕业论文是角度和弧度没有转换导致计算错误，一直纠结了好久，突然有一天脑海突然浮现出角度要转换成弧度，那一刻感觉开光了。有时还得多想一想！最近发现系列文章-为什么这么设计（Why’s THE Design），计算机领域中一个具体的问题并从不同的角度讨论这种设计的优缺点，觉得很有意思。思维方式是要训练的，多学习多涉猎是一种保持头脑清醒，避免“犯困” 的方式则慎。

方法如下：

CRC-16码由两个字节构成，在开始时CRC寄存器的每一位都预置为1，然后把CRC寄存器与8-bit的数据进行异或(异或：二进制运算 相同为0，不同为1；0^0=00^1=11^0=11^1=0)， 之后对CRC寄存器从高到低进行移位，在最高位（MSB）的位置补零，而最低位（LSB，移位后已经被移出CRC寄存器）如果为1，则把寄存器与预定义的多项式码进行异或，否则如果LSB为零，则无需进行异或。重复上述的由高至低的移位8次，第一个8-bit数据处睁余理完毕，用此时CRC寄存器的值纳早扮与下一个8-bit数据异或并进行如前一个数据似的8次移位。所有的字符处理完成后CRC寄存器内的值即为最终的CRC值。

1．设置CRC寄存器，并给其赋值FFFF(hex)。

2．将数据的第一个8-bit字符与16位CRC寄存器的低8位进行异或，并把结果存入CRC寄存器。 3．CRC寄存器向右移一位，MSB补零，移出并检查LSB。

4．如果LSB为0，重复第三步；若LSB为1，CRC寄存器与多项式码相异或。

5．重复第3与第4步直到8次移位全部完成。洞灶此时一个8-bit数据处理完毕。

6．重复第2至第5步直到所有数据全部处理完成。

7．最终CRC寄存器的内容即为CRC值。

CRC(16位)多项式为 X16+X15+X2+1，其对应校验二进制位列为1 1000 0000 0000 0101。

---