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

為什么需要checksum

前段時間分享ISO 11898內容的時候，提到了幀結構里的CRC場。

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

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

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

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

checksum舉例

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

checksum的計算方式

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

模256就是不考慮大于等于255的進位，只做8位以內的算術加法，即求和的值不會比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，那就把進位和該字節的Bit 0~Bit 7再求和。

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

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