CAN FD Data byte's
Meer dan 8 data byte’s
Waarom zou je meer data byte’s in één bericht willen versturen, wat is daar het voordeel van? Het voordeel is simpelweg de hogere data rate omdat de overhead relatief minder wordt. Een CAN 2.0-bericht heeft 111 bit timesOpm nodig om 8 data byte’s te versturen. Dat komt overeen met een overhead van 73%! Een CAN FD-bericht kan 64 data byte’s versturen in 568 bit timesOpm, met een overhead van slechts 11%. In de praktijk zal het downloaden van software ongeveer 2x zo snel gaan!
Maximum aantal data byte's
Binnen een CAN-bericht kan het aantal data byte’s niet extreem opgevoerd worden, om het real-time karakter van de bus geen geweld aan te doen. Hoe langer een bericht, des te langer blijft de bus door dit bericht bezet. Hierdoor zou een opeenhoping van berichten kunnen ontstaan die ook verzonden dienen te worden. Die opeenhoping doet afbreuk aan het real-time karakter. Immers, zeker bij controle- en statusberichten in closed-loop-regelingen ontstaat hierdoor een oscillerend gedrag.
Daarom zijn er in CAN FD twee maatregelen genomen:
- Het maximum van 64 bytes hangt nauw samen met de snelheidsverhoging van de databyte’s van 8 Mbit/sec. Immers door 8x zoveel data byte’s 8x zo snel te versturen, blijft de netto gebruikte tijd immers (praktisch) gelijk. Op deze manier nemen CAN FD berichten (ongeveer) evenveel tijd op de bus in beslag als voorheen.
- CAN FD controllers krijgen de mogelijkheid om het verzenden van lange CAN FD berichten, lees met meer dan 8 data byte’s, enige tijd tegen te houden zodat andere berichten tijd en ruimte krijgen de bus te gebruiken.
Indien lange FD-berichten enkel voor software downloading gebruikt worden, zal dit niet zo spelen. Dat gebeurt in de regel als het systeem in een configuratie/onderhoudsstatus is waarbij het real-time karakter geen rol speelt.
Data-lengte
Net zoals bij CAN 2.0 wordt het aantal data byte’s gedefinieerd in het DLC-veld van het CAN FD-bericht. Om de overhead voor kleine CAN-berichten, lees met weinig data byte’s, niet onnodige te vergoten is er voor gekozen om het aantal bits van het DLC-veld niet te vergoten. Omdat er in standaard CAN slechts 9 van de 16 (4 bits) veld ook een waarde hadden, zijn de overige 7 posities nu voor CAN FD ingevuld. Het gevolg is dat er niet variabel meer dan 8 data byte’s gekozen worden, maar enkel in gedefinieerde stappen.
| Aantal | CAN 2.0 Data lengte | |||
| 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 lengte | ||||
| 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
De betrouwbaarheid van de communicatie is één van de groot voordelen van CAN. Onderdeel van de veiligheidsketen vorm de CRC die bij CAN 2.0 standaard 15 bits lang is. Deze CRC is gebaseerd op een Hamming van h=6: twee verschillende blokken mogen daarbij 6 posities verschillen om zodoende h-1=5 bit-fouten per datablok te herkennen.
Door de toename van het aantal data-bytes zal de CRC aangepast dienen te worden om nog steeds aan h-6 te voldoen, tegelijkertijd vergoot een langere CRC de bericht-overhead. Om deze reden is er bij CAN FD voor gekozen om de lengte van de CRC afhankelijk van het aantal data byte’s te maken.
| Data byte's | CRC-lengte | |
| CAN 2.0 | ≤8 | CRC 15 |
| CAN FD | ≤ 16 | CRC 17 |
| CAN FD | >16 | CRC 21 |
Om synchronisatieproblemen te voorkomen wordt in het CRC-veld van CAN FD eventuele stuff-bits ingevoegd. De CRC van CAN 2.0 kent géén bitstuffing.