参考:
一、CRC
循环冗余校验(Cyclic Redundancy Check, CRC)是一种根据网络数据包或计算机文件等数据产生简短固定位数校验码的一种信道编码技术,主要用来检测或校验数据传输或者保存后可能出现的错误。它是利用除法及余数的原理来作错误侦测的。
其实就是通过在原来的数据D基础上通过增加一些比特位(多项式减一位,如多项式为n,则添加n-1位)的数据F,使得拼凑而成的数据T可以被取模(取余)为0。通过这种方式,接收方可以检验数据位有没有变化,而且CRC也可以以取模值不同判断出哪一位或者哪几位出错进行纠正。
通过上面的解释我们知道
(n :多项式位数)
因此是原数据左移n-1位加上F,得到数据T。
很多人想问为什么要左移n-1位,或者说而
先说求得F的方法常用的就是模2运算,以一个n位的数据为例子(100110),其多项式P也为m位(11001),在不进行补0的情况下,第一次运算得余数最多为(m-1)位,数据首位和多项式P首位都是1
————1———
11001|100110
|11011
_________
1000
其次我们算到最后一位,这次依然剩下4位余数,而且都在原数据的正下方,若想被整除,原数据必须加上这些数据,这样就会导致数据有进位的情况,而在原数据基础上补上4(m-1)个0之后,余数都会在补的后4(m-1)位内(可能少于4位,此时在余数前面补0,凑齐4位即可),这样可以将原数据左移四位后加上余数的新的数据T,这样保证了T可以被多项式P取模后恒为0.
————11——
11001|100110
|11011
_________
10000
11001
——————————
1001
而多项式的位数一般由开发者设定或者选择,常用的有以下几种。
二、常用CRC版本
多项式有一些原则必须遵守,多项式的首位和末位都要是1.
名称 | 多项式 | 表示法 | 应用举例 |
CRC-8 | X8+X2+X+1 | 0X107 | |
CRC-12 | X12+X11+X3+X2+X+1 | 0X180F | telecom systems |
CRC-16 | X16+X15+X2+1 | 0X18005 | Bisync, Modbus, USB, ANSI X3.28, SIA DC-07, many others; also known as CRC-16 and CRC-16-ANSI |
CRC-CCITT | X16+X12+X5+1 | 0X11021 | ISO HDLC, ITU X.25, V.34/V.41/V.42, PPP-FCS |
CRC-32 | X32+X26+X23+X22+X16+X12+ X11+X10+X8+X7+X5+X4+X2+X+1 | 0x104C11DB7 | ZIP, RAR, IEEE 802 LAN/FDDI, IEEE 1394, PPP-FCS |
CRC-32C | X32+X28+X27+X26+X25+X23+X22+X20+X19+ X18+X14+X13+X11+X10+X9+X8+X6+1 | 0x11EDC6F41 | iSCSI, SCTP, G.hn payload, SSE4.2, Btrfs, ext4, Ceph |
三、如何用查表法实现CRC校验(软件实现)
我们以CRC-CCITT为例:
通常的CRC算法在计算一个数据段的CRC值时,其CRC值是由求解每个数值的CRC值的和对CRC寄存器的值反复更新而得到的。这样,求解CRC的速度较慢。通过对CRC算法的研究,我们发现:一个8位数据加到16位累加器中去,只有累加器的高8位或低8位与数据相作用,其结果仅有256种可能的组合值。因而,我们可以用查表法来代替反复的运算,这也同样适用于CRC32的计算。
因此建立一个有256值得数组表,因此也叫查表法
const uint16_t Table[256] =
{
0x0000U, 0x1021U, 0x2042U, 0x3063U, 0x4084U, 0x50A5U, 0x60C6U, 0x70E7U,
0x8108U, 0x9129U, 0xA14AU, 0xB16BU, 0xC18CU, 0xD1ADU, 0xE1CEU, 0xF1EFU,
0x1231U, 0x0210U, 0x3273U, 0x2252U, 0x52B5U, 0x4294U, 0x72F7U, 0x62D6U,
0x9339U, 0x8318U, 0xB37BU, 0xA35AU, 0xD3BDU, 0xC39CU, 0xF3FFU, 0xE3DEU,
0x2462U, 0x3443U, 0x0420U, 0x1401U, 0x64E6U, 0x74C7U, 0x44A4U, 0x5485U,
0xA56AU, 0xB54BU, 0x8528U, 0x9509U, 0xE5EEU, 0xF5CFU, 0xC5ACU, 0xD58DU,
0x3653U, 0x2672U, 0x1611U, 0x0630U, 0x76D7U, 0x66F6U, 0x5695U, 0x46B4U,
0xB75BU, 0xA77AU, 0x9719U, 0x8738U, 0xF7DFU, 0xE7FEU, 0xD79DU, 0xC7BCU,
0x48C4U, 0x58E5U, 0x6886U, 0x78A7U, 0x0840U, 0x1861U, 0x2802U, 0x3823U,
0xC9CCU, 0xD9EDU, 0xE98EU, 0xF9AFU, 0x8948U, 0x9969U, 0xA90AU, 0xB92BU,
0x5AF5U, 0x4AD4U, 0x7AB7U, 0x6A96U, 0x1A71U, 0x0A50U, 0x3A33U, 0x2A12U,
0xDBFDU, 0xCBDCU, 0xFBBFU, 0xEB9EU, 0x9B79U, 0x8B58U, 0xBB3BU, 0xAB1AU,
0x6CA6U, 0x7C87U, 0x4CE4U, 0x5CC5U, 0x2C22U, 0x3C03U, 0x0C60U, 0x1C41U,
0xEDAEU, 0xFD8FU, 0xCDECU, 0xDDCDU, 0xAD2AU, 0xBD0BU, 0x8D68U, 0x9D49U,
0x7E97U, 0x6EB6U, 0x5ED5U, 0x4EF4U, 0x3E13U, 0x2E32U, 0x1E51U, 0x0E70U,
0xFF9FU, 0xEFBEU, 0xDFDDU, 0xCFFCU, 0xBF1BU, 0xAF3AU, 0x9F59U, 0x8F78U,
0x9188U, 0x81A9U, 0xB1CAU, 0xA1EBU, 0xD10CU, 0xC12DU, 0xF14EU, 0xE16FU,
0x1080U, 0x00A1U, 0x30C2U, 0x20E3U, 0x5004U, 0x4025U, 0x7046U, 0x6067U,
0x83B9U, 0x9398U, 0xA3FBU, 0xB3DAU, 0xC33DU, 0xD31CU, 0xE37FU, 0xF35EU,
0x02B1U, 0x1290U, 0x22F3U, 0x32D2U, 0x4235U, 0x5214U, 0x6277U, 0x7256U,
0xB5EAU, 0xA5CBU, 0x95A8U, 0x8589U, 0xF56EU, 0xE54FU, 0xD52CU, 0xC50DU,
0x34E2U, 0x24C3U, 0x14A0U, 0x0481U, 0x7466U, 0x6447U, 0x5424U, 0x4405U,
0xA7DBU, 0xB7FAU, 0x8799U, 0x97B8U, 0xE75FU, 0xF77EU, 0xC71DU, 0xD73CU,
0x26D3U, 0x36F2U, 0x0691U, 0x16B0U, 0x6657U, 0x7676U, 0x4615U, 0x5634U,
0xD94CU, 0xC96DU, 0xF90EU, 0xE92FU, 0x99C8U, 0x89E9U, 0xB98AU, 0xA9ABU,
0x5844U, 0x4865U, 0x7806U, 0x6827U, 0x18C0U, 0x08E1U, 0x3882U, 0x28A3U,
0xCB7DU, 0xDB5CU, 0xEB3FU, 0xFB1EU, 0x8BF9U, 0x9BD8U, 0xABBBU, 0xBB9AU,
0x4A75U, 0x5A54U, 0x6A37U, 0x7A16U, 0x0AF1U, 0x1AD0U, 0x2AB3U, 0x3A92U,
0xFD2EU, 0xED0FU, 0xDD6CU, 0xCD4DU, 0xBDAAU, 0xAD8BU, 0x9DE8U, 0x8DC9U,
0x7C26U, 0x6C07U, 0x5C64U, 0x4C45U, 0x3CA2U, 0x2C83U, 0x1CE0U, 0x0CC1U,
0xEF1FU, 0xFF3EU, 0xCF5DU, 0xDF7CU, 0xAF9BU, 0xBFBAU, 0x8FD9U, 0x9FF8U,
0x6E17U, 0x7E36U, 0x4E55U, 0x5E74U, 0x2E93U, 0x3EB2U, 0x0ED1U, 0x1EF0U
};
uint16_t add(const uint8_t *bytes, unsigned len)
{
uint16_t value_ = 0xa635; //初始值,根据CRC类型设定
while(len--)
{
value_ = ((value_ << 8) ^ Table[(uint16_t)((value_ >> 8) ^ *bytes) & 0xFFU]) & 0xFFFFU;
bytes++;
}
return value_;
}
该查表法大家肯定都见过很多次,但是其中的原理其实很多人不理解,包括我自己,因为这与我们一路顺下来的思路并不一致。
在参考了大佬的文章之后,贴出来给大家看 CRC校验值计算的方法,
该查表法原理
* 以 E9AAEE为例
* 先计算E9的crc值===>91
* 先算E9AA =>gencrc8_temp(0xE9AA)==>3B
* 恰好相当于E9的crc值异或AA:gencrc8_temp(0xE9)^AA==>3B
* 接着以3B作为EE的高8位计算getcrc8_temp(3BEE)===>4F
* 恰好相当于3B的crc值异或EE:gencrc8_temp(0x3B)^AA==>4F
* 最后计算4F的crc gencrc8_temp(0x4F)===>EA 这个值机最终的CRC值
*
* 数学原理
* NM=M*X^r
* E900=E9*X^8==>
* (X^7+X6+X^5+X^3+1)*X8=X^15+X^14+x^13+X^11+^X8
* 由因为求E9的校验值,其实就是求E900/G 的余数CRC1
* 有因为只算高8位,所以E900/G和E9AA/G的商是相等的
* 设E9为K,AA为L,K/G和AA/G的商为N
* E900=K*X^8
* GN+CRC1=K*X^8
* E9AA=K*X^8+L
* GN+CRC2=K*X^8+L
* K*X^8-CRC1=K*X^8+L-CRC2
* CRC2=K*X^8+L-K*X^8+CRC1
* =L+CRC1
* 由因为模2运算的加减法相当于异或运算
* 所以CRC2=CRC1^L
* E9AA的校验值CRC2相当于E900的CRC1^AA
*
以上原理主要介绍了8位CRC校验,因此比较容易理解TALBLE[256]的来由,因为8位数据最大就是256,全部列出来即可,那么16位和32位的是256^2和256^4个表?很显然据我们查阅资料得到16位和32位的都是256元素的表,只是里面的数据是16位和32的。
当然CRC的查表法只是软件实现的一种以空间换时间的方法,软件实现最基本的方法是用代码实现CRC的逻辑
四、硬件方式实现CRC值(寄存器)
以寄存器的方式获得CRC值
以CRC16-CCITT 为例,其多项式为:0x1021(实际上其为0x11021)
原理: 先将原有数据