看到了一種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)文棄之不用。
-
CAN通信
+關(guān)注
關(guān)注
5文章
94瀏覽量
17923 -
接收機(jī)
+關(guān)注
關(guān)注
8文章
1184瀏覽量
53555 -
二進(jìn)制
+關(guān)注
關(guān)注
2文章
795瀏覽量
41703 -
CRC校驗(yàn)
+關(guān)注
關(guān)注
0文章
84瀏覽量
15245 -
信號(hào)傳輸
+關(guān)注
關(guān)注
4文章
431瀏覽量
20227
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論