This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.
View the complete Table of Contents →
The Controller Area Network has been around for decades, and despite its age, Classical CAN remains remarkably well suited to embedded control applications.
That longevity is not an accident. CAN was designed around a relatively small number of principles that solve some difficult networking problems in an elegant way. Before looking at CAN FD and the improvements it introduced, it is worth reviewing what made Classical CAN so successful in the first place.
The Basic Properties of Classical CAN
Classical CAN is a multi-master, message-oriented communication system. There is no central bus controller deciding which node is allowed to communicate. Any node may begin transmitting when the bus is idle.
When two or more nodes attempt to transmit at the same time, CAN resolves the conflict through priority-based, non-destructive arbitration.
This is one of the most important characteristics of CAN.
Multi-Master Bus Access
Every CAN node has equal access to the communication medium. There is no master that must grant permission before another node can transmit.
This has an important practical consequence: the failure of one node does not normally prevent the rest of the network from communicating.
It also makes CAN particularly attractive for distributed embedded systems.
Priority-Based, Non-Destructive Arbitration
When several nodes begin transmitting simultaneously, the CAN identifier determines which message receives access to the bus.
CAN performs this arbitration bit by bit.
Dominant bits override recessive bits. A transmitting node continuously monitors the actual state of the bus. If it transmits a recessive bit but detects a dominant bit, it knows that another message has higher priority.
The losing node stops transmitting.
The important point is that the winning message continues without interruption.
There is no collision in the Ethernet sense, no corrupted frame that must be discarded, and no wasted transmission caused by the arbitration process.
The losing node simply waits until the bus becomes available and attempts transmission again.
This is why describing CAN arbitration as “non-destructive” is so important.
Message-Oriented Communication
CAN does not fundamentally address individual nodes.
Instead, it identifies messages.
The CAN identifier describes the meaning and priority of a message rather than specifying a destination address.
For example, a particular identifier might represent engine speed, hydraulic pressure, wheel speed, or another application-specific parameter.
Every node sees the transmitted message. Each CAN controller can then use acceptance filtering to determine whether that message is relevant to the application.
This provides CAN with its multicast capability: one transmitted message can provide information to several nodes simultaneously without having to send separate copies to each receiver.
Configuration Flexibility
Because messages are identified independently of individual nodes, CAN networks can be remarkably flexible.
A new node can listen to an existing message without requiring the transmitting node to know that the new receiver exists.
Likewise, multiple nodes can consume the same information.
This loose coupling between producers and consumers is one of CAN’s greatest architectural strengths.
Remote Data Requests
Classical CAN also defines Remote Frames.
A Remote Frame allows a node to request transmission of a Data Frame with the corresponding identifier.
Remote Frames have never been equally important in all CAN applications, and many higher-layer protocols do not depend on them. Nevertheless, they are part of the Classical CAN specification.
As we will see later, CAN FD eliminated Remote Frames.
Error Detection and Fault Confinement
Another reason for CAN’s success is its extensive error-management system.
CAN does not depend on a single mechanism to determine whether communication was successful. It uses several complementary methods, including:
Bit monitoring
Bit stuffing checks
CRC checking
Frame format checking
Acknowledgement checking
When an error is detected, nodes can signal the condition using an Error Frame. The affected message is discarded and, under normal circumstances, automatically transmitted again.
This is quite different from losing arbitration.
A node that loses arbitration has not experienced an error. It simply lost access to a higher-priority message and will try again later.
A message destroyed by an actual communication error, on the other hand, must be retransmitted.
CAN also keeps track of communication errors through transmit and receive error counters.
This allows the controller to distinguish between occasional disturbances and a node that is repeatedly causing communication problems.
Depending on the accumulated error count, a CAN controller can transition through different error states and ultimately enter the Bus-Off state.
A defective transmitter can therefore remove itself from active bus communication rather than continuously interfering with the rest of the network.
That fault-confinement mechanism is another fundamental strength of CAN.
Data Consistency Throughout the Network
CAN was also designed to provide system-wide data consistency.
All active receivers observe the same transmission and participate in its error detection. If a serious transmission error is detected, the frame is invalidated rather than being silently accepted by only part of the network.
This behavior is extremely important in distributed control systems where several electronic control units may depend on the same information.
The Limitations of Classical CAN
For all its strengths, Classical CAN has two limitations that became increasingly significant as embedded systems grew more complex.
The first is payload size.
A Classical CAN Data Frame can carry a maximum of:
8 data bytes
The second limitation is communication speed.
Classical high-speed CAN is traditionally associated with bit rates of up to:
1 Mbit/s
And even 1 Mbit/s is not practical over arbitrary cable lengths. As CAN networks become physically longer, the achievable bit rate decreases because signal propagation delays become increasingly important during arbitration.
Neither limitation was particularly troublesome when CAN was developed. Eight bytes can carry a surprising amount of control information, particularly when the application is exchanging temperatures, pressures, switch states, RPM values, and similar signals.
But applications changed.
Software became larger. Diagnostic communication became more demanding. Electronic control units needed to exchange greater quantities of data.
Eight bytes started looking rather small.
And 1 Mbit/s started looking rather slow.
This is where CAN FD enters the picture.
CAN FD: More Data and More Speed
CAN FD stands for CAN with Flexible Data Rate.
The name describes one of its most important features, but CAN FD actually addresses both of the major Classical CAN limitations.
It increases the amount of data that can be transported in one frame, and it allows part of that frame to be transmitted at a higher bit rate.
At the same time, it retains many of the characteristics that made CAN attractive in the first place.
CAN FD remains a multi-master, message-oriented network using CAN identifiers, priority-based arbitration, acceptance filtering, error detection, acknowledgement, and fault confinement.
In other words, CAN FD did not abandon CAN.
It extended it.
From 8 Bytes to 64 Bytes
The most obvious difference is payload size.
Classical CAN supports payloads from zero through eight bytes.
CAN FD extends the maximum payload to 64 bytes.
For payloads greater than eight bytes, however, not every byte count can be selected. CAN FD defines the following payload sizes:
0–8, 12, 16, 20, 24, 32, 48, and 64 bytes
That is a substantial increase.
A single CAN FD frame can therefore carry eight times as much application data as the maximum Classical CAN frame.
This can also improve efficiency. Instead of transmitting several individual CAN frames—each with its own identifier, arbitration, control information, CRC, acknowledgement, and interframe spacing—a larger amount of data can be transported within a single CAN FD frame.
But increasing the payload alone would create another problem.
A 64-byte CAN frame transmitted at the traditional CAN bit rate would occupy the bus for a relatively long time.
CAN FD addresses that problem with its second major feature.
Two Bit Rates Within One Frame
CAN FD can use two different bit rates during the transmission of a single frame.
This sounds unusual at first, but the reasoning behind it is quite logical.
During arbitration, all nodes competing for access to the bus must be able to observe each other’s transmitted bits.
That requirement places physical limits on the maximum possible bit rate. A signal must have enough time to propagate through the network and be observed by the participating nodes before the arbitration decision is made.
But once arbitration is finished, only one node is transmitting.
There is no longer any competition for the bus.
CAN FD takes advantage of this.
The arbitration portion of the frame is transmitted using the normal nominal bit rate.
After arbitration, the transmitter can switch to a higher bit rate for the data portion of the frame.
Conceptually, we can think of it as:
Normal CAN speed → Arbitration → Higher data speed → Return to normal CAN speed
The Bit Rate Switch, or BRS, bit indicates whether the higher data-phase bit rate is being used.
This is the “Flexible Data Rate” in CAN FD.
It is important to understand that CAN FD does not simply make the entire CAN network run faster.
The arbitration phase still operates according to the timing requirements imposed by CAN’s multi-master arbitration mechanism.
CAN FD accelerates the portion of the frame where that restriction can be relaxed.
What CAN FD Did Not Change
This is perhaps the most important point.
CAN FD did not replace the fundamental communication philosophy of CAN.
The network is still message-oriented.
It is still multi-master.
Messages still have identifiers.
Those identifiers still determine priority during arbitration.
Arbitration is still non-destructive.
Nodes can still use acceptance filters to select the messages they need.
CAN still provides acknowledgement, error detection, retransmission, and fault confinement.
The major changes are primarily about moving more data and moving that data faster.
There are protocol changes required to support those capabilities, of course. CAN FD introduced changes to the frame format, CRC mechanisms, data-length coding, and other details.
But from an application architecture perspective, CAN FD is still very recognizably CAN.
One Feature That Disappeared
There is one Classical CAN feature worth mentioning specifically because CAN FD did not carry it forward.
CAN FD does not support Remote Frames.
Only Data Frames are used for CAN FD communication.
In practice, this is rarely a serious limitation. Modern higher-layer protocols generally provide their own mechanisms for requesting information when such functionality is required.
Classical CAN Versus CAN FD
The most important differences can therefore be summarized fairly simply:
CharacteristicClassical CANCAN FDNetwork architectureMulti-masterMulti-masterCommunication modelMessage-orientedMessage-orientedArbitrationPriority-based, non-destructivePriority-based, non-destructive11-bit identifiersYesYes29-bit identifiersYesYesMaximum payload8 bytes64 bytesMultiple bit rates within a frameNoYesFaster data phaseNoYesRemote FramesYesNoAcceptance filteringYesYesError detectionYesYesFault confinementYesYes
Seen this way, the evolution from Classical CAN to CAN FD was actually quite conservative.
The designers did not discard the characteristics that made CAN reliable and useful. They addressed two increasingly important restrictions: the amount of data that could be transported in a frame and the amount of time required to transport it.
An Evolution Rather Than a Replacement
I have always considered the elegance of Classical CAN to be its greatest strength.
It solves bus access, message prioritization, error detection, retransmission, and fault confinement at the protocol level while remaining comparatively simple for an embedded developer to use.
CAN FD recognized that this basic architecture was still valuable.
What had changed were the demands placed on the network.
Eight bytes were no longer always enough.
And the traditional CAN bit rate was no longer always fast enough.
CAN FD therefore extended CAN rather than replacing its fundamental architecture.
Follow CAN Bus Embedded Development
New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.