看到了一種checksum校驗(yàn)和的方法，分享給大家。

為什么需要checksum

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

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

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

當(dāng)然，checksum起初被發(fā)明是因?yàn)橛行┩ㄐ诺臄?shù)據(jù)鏈路層沒有CRC，新出的一種校驗(yàn)方法。

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

checksum舉例

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

checksum的計(jì)算方式

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

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

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

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

checksum的計(jì)算舉例

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

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

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

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