CAN通信协议里一种checksum校验和的方法

看到了一种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就说明该帧报文数据是正确的，可以接收。否则该帧报文弃之不用。