看到了一種checksum校驗和的方法，分享給大家。

為什么需要checksum

前段時間分享ISO 11898內(nèi)容的時候，提到了幀結(jié)構(gòu)里的CRC場。

CAN信號在傳輸?shù)臅r候，有可能會因為干擾、攻擊之類的原因產(chǎn)生錯誤，比如發(fā)送方要發(fā)1，結(jié)果傳輸錯誤，到接收方那就成0了。為了避免這種比特錯誤，數(shù)據(jù)鏈路層做了CRC（Cyclic Redundancy Check）校驗。

但是，CRC并不能檢測到所有的差錯，有些方式是可以騙過去的，就像黑客攻破防火墻一樣。為了盡可能保證數(shù)據(jù)傳輸?shù)臏蚀_性，我們用的CAN通信里還增加了checksum校驗和，checksum在傳輸層。

當然，checksum起初被發(fā)明是因為有些通信的數(shù)據(jù)鏈路層沒有CRC，新出的一種校驗方法。

另外，CRC和checksum只能做到無差錯接收，而不是可靠接收。接收方如果發(fā)現(xiàn)了比特錯誤，這幀報文不要了，那必然是少了一幀報文。為了避免這個問題，CAN有重傳和確認機制，接收方會發(fā)出信號告訴發(fā)送方有錯誤，那發(fā)送方將重傳該幀報文，接收方收到后回復確認后結(jié)束。

checksum舉例

我見過幾種checksum方式，下面以最近看到的一個為例。僅做分享。

checksum的計算方式

從上圖可以看出，這幀報文里Byte 0是checksum的值。checksum是所有字節(jié)模256的和的反。這里的所有字節(jié)就是Byte 1到Byte 7。

模256就是不考慮大于等于255的進位，只做8位以內(nèi)的算術(shù)加法，即求和的值不會比255（0xFF）更大了。

那怎么做到不比255（0xFF）大呢？求和后超過255的進位（Carry），再去求和（ADD）。這個進位（Carry）是放到LSB（Least Significant Bit，二進制的最低位）去求和的。

模256的和是sum，再對sum取反（inverted），得出checksum。

checksum的計算舉例

從圖里的例子可以計算，Byte 1（0x4A）+Byte 2（0x55）=0x9F，這里進位是0。

然后0x9F+Byte 3（0x93）=0x132，這個0x132就比0xFF大了，進位是1，那就把進位和該字節(jié)的Bit 0~Bit 7再求和。

依次計算，最后求得sum=0x20。再取反，得出checksum=0xDF。

接收方收到數(shù)據(jù)后，算出Byte 1到Byte 7的sum，再與發(fā)送方發(fā)出的checksum（Byte 0）相加，得出0xFF就說明該幀報文數(shù)據(jù)是正確的，可以接收。否則該幀報文棄之不用。