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 →
Controller Area Network
In this chapter, I will not attempt another detailed explanation of how Classical CAN or CAN FD works. As mentioned in the introduction, there is already an abundance of excellent literature, specifications, tutorials, and websites covering CAN frames, identifiers, arbitration, bit timing, error handling, and the physical layer.
There is little value in repeating all of that here.
Instead, I want to approach CAN from a different direction.
Rather than asking “What is Controller Area Network?”, let us ask the more practical question:
Why are we using it?
That question becomes particularly important when developing embedded systems. Looking only at specifications, CAN may appear almost outdated compared with modern networking technologies. Classical CAN provides a maximum data field of only 8 bytes and operates at bit rates up to 1 Mbit/s. CAN FD improves considerably on those numbers, supporting payloads of up to 64 bytes and allowing the data portion of a frame to be transmitted at substantially higher bit rates.
Compared with Ethernet, however, even CAN FD does not appear particularly impressive.
But raw speed tells only a small part of the story.
A Remarkably Complete Protocol
One of CAN’s greatest strengths is how much functionality is handled by the CAN controller itself.
A CAN controller takes care of functions such as bus access, message arbitration, frame generation, CRC generation and checking, acknowledgment, error detection, error signaling, automatic retransmission, and fault confinement.
In modern microcontrollers, the CAN controller is frequently integrated directly into the processor. Other designs use a separate CAN controller. In either case, a CAN transceiver normally provides the electrical interface between the controller and the two-wire CAN bus.
From the application’s point of view, however, much of the complexity disappears into the hardware.
At its simplest, the software provides a CAN identifier and some data and tells the controller to transmit them. On reception, the application retrieves the identifier and data from the controller. Status information and error conditions can also be monitored, but the application does not have to implement the underlying network protocol itself.
That is an enormous advantage in an embedded system.
It means that sophisticated and reliable network communication can be implemented with relatively modest processor performance, memory, hardware, and software.
Arbitration Without Destroying Messages
CAN’s bus arbitration mechanism is a particularly elegant example.
Suppose two CAN nodes begin transmitting at exactly the same time. In many communication systems, this would result in a collision. Both transmissions would be corrupted, and some mechanism would be required to recover from the collision.
CAN does something different.
During transmission, every CAN node also monitors the bus. Arbitration takes place bit by bit using the CAN identifier. Dominant bits override recessive bits. When a transmitting node sends a recessive bit but detects a dominant bit on the bus, it knows that another message has higher priority.
The losing node simply stops transmitting.
The higher-priority node continues transmitting without interruption.
Nothing has been corrupted.
The node that lost arbitration can attempt transmission again when the bus becomes available.
This is called nondestructive arbitration, and it is one of the reasons CAN works so well for real-time embedded applications. Message priority is inherent in the CAN identifier, and resolving simultaneous bus access does not require destroying the successful transmission.
Reliability Is Built In
CAN was designed for electrically challenging environments, and reliability is not something that must be added later by application software.
Every transmitting node monitors what actually appears on the bus. Frames contain CRC protection. CAN also performs bit-stuffing checks, frame-format checks, acknowledgment checks, and other error-detection functions.
When an error is detected, the erroneous frame is rejected and normally retransmitted automatically.
CAN also maintains error counters that allow nodes experiencing repeated communication problems to restrict themselves and, eventually, disconnect themselves logically from normal bus communication. A defective node therefore has mechanisms preventing it from indefinitely disrupting the entire network.
The probability of an undetected corrupted CAN message is extraordinarily small. This combination of error detection, error signaling, retransmission, and fault confinement is one reason CAN escaped its original automotive environment long ago.
Today, CAN technology can be found in industrial machinery, agricultural equipment, medical equipment, robotics, marine systems, transportation systems, and many other embedded applications.
The common requirement is not necessarily high bandwidth.
It is reliable communication between embedded devices.
Two Wires Can Connect an Entire System
Another major advantage is the physical network itself.
A conventional high-speed CAN network uses a differential two-wire bus, CAN_H and CAN_L. Nodes connect to the same bus rather than requiring individual point-to-point communication links between every device.
Consider what happens as an embedded system grows.
Without a network, adding sensors, controllers, displays, actuators, and other intelligent devices can result in increasingly complicated wiring. With CAN, those devices can exchange information over the same two communication conductors.
In a production CAN network, proper cable characteristics, topology, termination, stub lengths, grounding, and electromagnetic compatibility must of course be considered.
But during development on a workbench, particularly at moderate bit rates and short distances, CAN can be remarkably forgiving. A simple two-wire connection may be sufficient to get several embedded boards communicating with each other.
That makes CAN particularly attractive for experimentation and prototyping.
What About Speed?
This is where CAN is sometimes unfairly judged.
Classical CAN is limited to a maximum bit rate of 1 Mbit/s and a maximum payload of 8 bytes per data frame. CAN FD increases the payload to as much as 64 bytes and allows the data phase of the frame to operate considerably faster than the arbitration phase. Depending on the transceivers, topology, wiring, and network design, data-phase bit rates of several Mbit/s—and up to approximately 8 Mbit/s in suitable implementations—are practical.
Those numbers are tiny compared with modern Ethernet.
But that comparison misses the purpose of CAN.
CAN was never intended to transfer video, large files, database records, or massive streams of data. It was designed primarily to exchange relatively small amounts of information efficiently and reliably between embedded controllers.
An engine controller may need to communicate engine speed.
A temperature sensor may transmit a measured value.
A hydraulic controller may report pressure.
A motor controller may receive a speed command.
A machine controller may announce an alarm condition.
For these applications, 100 Mbit/s or 1 Gbit/s provides little inherent advantage if each useful piece of information consists of only a few bytes.
CAN Versus Ethernet
This leads to an important point that is easy to overlook:
Faster does not automatically mean better.
Ethernet provides vastly greater bandwidth than CAN, and there are many embedded applications where Ethernet is unquestionably the appropriate technology.
But bandwidth has a price.
An Ethernet implementation can require more capable hardware, more memory, larger software stacks, more complicated networking software, and greater overall system resources. Depending on the application, switches and additional network infrastructure may also be required.
CAN approaches the problem from the opposite direction.
The protocol deliberately provides comparatively modest bandwidth while putting arbitration, error detection, retransmission, and fault handling into the CAN hardware. The resulting software interface can remain remarkably small.
For a microcontroller exchanging short control and status messages with several other microcontrollers, that tradeoff can be extremely attractive.
So, in the right embedded application, CAN can effectively beat Ethernet—not in bandwidth, but in simplicity, resource requirements, deterministic message prioritization, implementation cost, and robustness.
That distinction matters.
In memory of Dr.-Ing. Werner Schulze, co-founder of esd electronics, a friend and colleague who once summarized the CAN-versus-Ethernet discussion for me in one wonderfully simple sentence:
“You don’t use a Ferrari to go grocery shopping.”
Werner’s point was not that Ethernet is somehow inferior to CAN. Quite the opposite: Ethernet offers vastly greater performance. His point was that engineering is about choosing the technology appropriate for the task.
For many embedded control applications, enormous bandwidth simply isn’t necessary. What matters more may be low hardware cost, modest memory requirements, minimal software overhead, predictable bus access, and robust error handling.
In other words, sometimes you don’t need the Ferrari.
CAN Is an Embedded Network
This is perhaps the most useful way to think about CAN throughout this book.
CAN is not a general-purpose computer network that happens to be used with microcontrollers.
It is a network technology designed around the requirements of embedded control.
It assumes that messages are relatively small. It assumes that multiple controllers need access to a common communication medium. It provides message prioritization. It detects communication errors in hardware. It automatically handles many failures and retransmissions. And it accomplishes all of this while requiring comparatively few hardware and software resources.
Those characteristics explain why CAN has remained relevant for decades despite enormous increases in processor performance and network bandwidth.
The question is therefore not:
“Why would I use CAN when Ethernet is so much faster?”
The better question is:
“How much communication does my embedded application actually need, and what will it cost me—in hardware, software, memory, complexity, and reliability—to provide it?”
For a remarkably large number of embedded systems, CAN remains an excellent answer.
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.