More than 8 data bytes
Why would you want to send more data bytes in a single message – what is the advantage of that? The advantage is simply the higher data rate, as the overhead is relatively lower. A CAN Classic message requires 111 bit timesNote to send 8 data bytes. That corresponds to an overhead of 73 per cent! A CAN FD message can send 64 data bytes in 568 bit timesNote, with an overhead of just 11 per cent. In practice, downloading software will be about twice as fast!
Note: including 3 bits of inter-frame space; any bit stuffing has been disregarded here.Maximum number of data bytes
Within a CAN message, the number of data bytes cannot be increased excessively, so as not to compromise the real-time nature of the bus. The longer a message is, the longer the bus remains occupied by that message. This could lead to a build-up of messages that also need to be transmitted. Such a build-up compromises the real-time nature of the system. After all, this causes oscillatory behaviour, particularly in the case of control and status messages in closed-loop control systems.
For this reason, two measures have been implemented in CAN FD:
- The 64-byte limit is closely linked to the increase in data byte transfer rate to 8 Mbit/sec. After all, by transmitting 8 times as many data bytes 8 times as fast, the net time taken remains (practically) the same. In this way, CAN FD messages take up (roughly) the same amount of time on the bus as before.
- CAN FD controllers are able to temporarily suspend the transmission of long CAN FD messages – i.e. those containing more than 8 data bytes – to allow other messages time and space to use the bus.
If long FD messages are used solely for software downloading, this will not be an issue. This generally occurs when the system is in a configuration or maintenance state where real-time performance is not a factor.
Data length
As with CAN 2.0, the number of data bytes is defined in the DLC field of the CAN FD message. To avoid unnecessary overhead for small CAN messages – i.e. those with few data bytes – it was decided not to increase the number of bits in the DLC field. As in standard CAN only 9 of the 16 (4 bits) in the field had a value, the remaining 7 positions are now filled for CAN FD. The result is that no more than 8 data bytes can be selected variably, but only in defined increments.
| Aantal | CAN Classic Data length | |||
|---|---|---|---|---|
| Data byte's | DLC3 | DLC2 | DLC1 | DLC0 |
| 0 | 0 | 0 | 0 | 0 |
| 1 | 0 | 0 | 0 | 1 |
| 2 | 0 | 0 | 1 | 0 |
| 3 | 0 | 0 | 1 | 1 |
| 4 | 0 | 1 | 0 | 0 |
| 5 | 0 | 1 | 0 | 1 |
| 6 | 0 | 1 | 1 | 0 |
| 7 | 0 | 1 | 1 | 1 |
| 8 | 1 | 0 | 0 | 0 |
| CAN FD Data length | ||||
| 12 | 1 | 0 | 0 | 1 |
| 16 | 1 | 0 | 1 | 0 |
| 20 | 1 | 0 | 1 | 1 |
| 24 | 1 | 1 | 0 | 0 |
| 32 | 1 | 1 | 0 | 1 |
| 48 | 1 | 1 | 1 | 0 |
| 64 | 1 | 1 | 1 | 1 |
CRC
The reliability of communication is one of the major advantages of CAN. The CRC, which is 15 bits long as standard in CAN Classic, forms part of the safety chain. This CRC is based on a Hamming code with h=6: two different blocks may differ by up to 6 positions, thereby enabling the detection of h-1=5 bit errors per data block.
Due to the increase in the number of data bytes, the CRC will need to be adjusted to still comply with h-6; at the same time, a longer CRC increases the message overhead. For this reason, CAN FD has opted to make the length of the CRC dependent on the number of data bytes.
| Data bytes | CRC length | |
|---|---|---|
| CAN Classic | ≤8 | CRC 15 |
| CAN FD | ≤16 | CRC 17 |
| CAN FD | >16 | CRC 21 |
To prevent synchronisation problems, any necessary stuff bits are inserted into the CAN FD CRC field. The CAN Classic CRC does not use bit stuffing.
