CRC校驗查表法原理及實現(CRC-16)
https://blog.csdn.net/AgonyRR/article/details/107810982?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param
緒論
在網上瀏覽了很多關於CRC校驗的文章,基本上都是針對CRC校驗原理的闡述以及關於CRC校驗查表法的實際應用以及具體軟體實現方法。
至於查的表是怎麼來的,軟體為什麼要這樣實現很多文章並沒有說明。本篇文章就針對這兩點問題進行總結和歸納,有錯誤的地方歡迎大家評論區指出,不勝感激。
注意:本篇文章不涉及CRC校驗的基本原理,如果不瞭解CRC的基本原理,請移步至如下連結:
CRC查詢表法推導及程式碼實現比較
以下的CRC查表法的軟體實現及推導過程均建立在modbusRTU協議使用的CRC-16標準。
查表法的表是怎麼來的?
CRC16演算法的生成多項式x 16 + x 15 + x 2 + 1 x^{16}+x^{15}+x^2+1x16+x15+x2+1,十六進位制表示為0x8005(因為4個位元組所以X^16的1可以捨去0X18005變為0X8005)。
CRC16常見的表格中的資料是按照先傳輸LSB,訊息右移進暫存器來計算的。因此需要判斷暫存器的最低位LSB,同時要將0x8005按位顛倒後(0xA001)根據LSB的情況決定是否與暫存器異或即可。
CRC16的表格中對應的數依次為0~255計算出來的CRC值,因此,此處只選取其中一兩個數作為例項計算CRC值。
具體步驟如下所示:
1)從0~255中選取需要計算的數,將其對應的十六進位制數放入一個長度為16的暫存器的低八位,高八位填充0;
2)如果暫存器的末位LSB為1,將暫存器的數值右移1位,再與0xA001位異或,否則僅將暫存器右移1位;
3)重複第2步,直到低八位全部右移出暫存器;
4)暫存器中的值則為校驗碼。
例如選擇0x01作為計算CRC值:
CRC-16的表格計算
舉例:0x0001
多項式:0xA001
初始值:0x0000
以下為二進位制顯示
00000001 高八位填充0,與初始值異或 得到:
00000000 00000001 第一次
由於LSB=1 右移一位,高位添0
00000000 00000000 與0xA001異或 得到:
10100000 00000001第二次
由於LSB=1 右移一位,高位添0
01010000 00000000 與0xA001異或 得到:
11110000 00000001 第三次
由於LSB=1 右移一位,高位添0
01111000 00000000 與0xA001異或 得到:
11011000 00000001 第四次
由於LSB=1 右移一位,高位添0
01101100 00000000 與0xA001異或 得到:
11001100 00000001 第五次
由於LSB=1 右移一位,高位添0
01100110 00000000 與0xA001異或 得到:
11000110 00000001 第六次
由於LSB=1 右移一位,高位添0
01100011 00000000 與0xA001異或 得到:
11000011 00000001 第七次
由於LSB=1 右移一位,高位添0
01100001 10000000 與0xA001異或 得到:
11000001 10000001 第八次
由於LSB=1 右移一位,高位添0
01100000 11000000 與0xA001異或 得到:
11000000 11000001 結束 得到0xC0 C1
此數值即為CRC校驗值,該數值也是CRC校驗表上的0x01位置上的值
我們對照一下CRC校驗表,C0 C1分別為兩張表中位置為1的數值(0開始),CRC校驗表見“軟體實現方法”部分。
當然,細心的朋友在實際應用的時候發現,如果使用CRC-16(modbus)引數模型計算CRC校驗和上面的計算結果有很大差異,我們這裡使用CRC校驗計算器來計算校驗和,連結如下:
連結: CRC線上計算
設定如截圖所示:
計算結果為807E,並不是我們之前計算出來的C0C1。
原因就在於初始值不一樣,modbus引數模型要求初始值為FFFF,而CRC校驗表中的資料是利用初始值0000計算得到的,如果將初始值更改為0000,其他引數不變的話,我們可以利用計算器很順利的得到C0C1,如下截圖所示:
modbus引數模型在計算多組資料時,上一個資料計算出來的CRC校驗和是儲存在CRC暫存器中,參與下一個資料的計算。
這裡總結了一下使用modbus引數模型計算CRC-16的計算步驟:
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值。
軟體實現方法
const uint32_t auchCRCHi[256] =
{
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40
};
const uint32_t auchCRCLo[256] =
{
0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04,
0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09, 0x08, 0xC8,
0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC,
0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3, 0x11, 0xD1, 0xD0, 0x10,
0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4,
0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A, 0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38,
0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C,
0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26, 0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0,
0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4,
0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F, 0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68,
0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C,
0xB4, 0x74, 0x75, 0xB5, 0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0,
0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54,
0x9C, 0x5C, 0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98,
0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80, 0x40
};
void crc16_str_sent(uint32_t *ptr, uint32_t len)
{
WORD_BYTE calc_crc;
uint32_t uIndex;
calc_crc.word=0xffff;
for(; len; len--)
{
uIndex = calc_crc.byte.low ^ (*ptr);
calc_crc.byte.low = calc_crc.byte.high ^ auchCRCHi[uIndex];
calc_crc.byte.high = auchCRCLo[uIndex];
ptr++;
}
(*ptr) = calc_crc.byte.low;
ptr++;
(*ptr) = calc_crc.byte.high;
}
uint32_t crc16_str_rece(uint32_t *ptr, uint32_t len)
{
WORD_BYTE calc_crc;
uint32_t uIndex;
uint32_t dat;
calc_crc.word=0xffff;
for(; len; len--)
{
uIndex = calc_crc.byte.low ^ (*ptr);
calc_crc.byte.low = calc_crc.byte.high ^ auchCRCHi[uIndex];
calc_crc.byte.high = auchCRCLo[uIndex];
ptr++;
}
if( ((*ptr)==calc_crc.byte.low) && ((*(ptr+1))==calc_crc.byte.high) )
dat = 1;
else
dat = 0;
return(dat);
}
注意:以上程式碼僅僅作為參考程式碼,使用不同的編譯器需要對程式碼進行簡單的移植或處理即可使用。
相關文章
- CRC校驗原理
- CRC校驗原理簡介及C程式碼實現說明C程式
- 【CRC筆記】CRC-16 MAXIM-DOW C語言實現筆記C語言
- 【CRC校驗方法】+【FPGA實現(傳送端)】FPGA
- 求助:EXCEL,VB,實現 CRC16 校驗Excel
- CRC演算法原理、推導及實現演算法
- USB中TOKEN的CRC5與CRC16校驗(神奇的工具生成Verilog實現)
- C實現奇偶校驗
- CRC(迴圈冗餘校驗)和CBC(密碼塊鏈)密碼
- SpringMVC實現引數校驗SpringMVC
- Spring Validation最佳實踐及其實現原理,引數校驗沒那麼簡單!Spring
- AOP如何實現及實現原理
- SpringBoot分組校驗及自定義校驗註解Spring Boot
- laravel-sms 實現阿里雲手機傳送簡訊驗證碼及校驗Laravel阿里
- JS實現 CRC加密 ModbusCRC16JS加密
- SpringMVC實現原理及解析SpringMVC
- KVO使用及實現原理
- Promise原理探究及實現Promise
- NNLM原理及Pytorch實現PyTorch
- vue 實現原理及簡單示例實現Vue
- .NET中特性+反射 實現資料校驗反射
- 常見的校驗演算法crc(32),md5(128),sha1(160)演算法
- Linux網路安全技術與實現第2章之原理及實驗Linux
- TreeMap原理實現及常用方法
- DES原理及程式碼實現
- LRU cache原理及go實現Go
- JSONP 跨域原理及實現JSON跨域
- MapReduce原理及簡單實現
- Spring Boot實現通用的介面引數校驗Spring Boot
- 驗證碼原理及驗證
- CGLib動態代理原理及實現CGLib
- consistent hash 原理,優化及實現優化
- Svm演算法原理及實現演算法
- RPC基本原理及實現RPC
- HashMap實現原理及原始碼分析HashMap原始碼
- ARouter原理剖析及手動實現
- synchronized實現原理及鎖優化synchronized優化
- simple-mybatis的原理及實現MyBatis