“If you can dream it, you CAN do it.”
– Walt Disney (emphasis added)
Introducing the CAN Bus
In previous Learn Blog articles, we’ve looked at several point-to-point serial protocols (RS485, RS422, RS232) and also compared the SPI and the I2C serial buses. Today we’ll hop on board yet another serial bus, the CAN bus.
Of course, it’s almost as much fun coming up with puns about the CAN acronym as it was playing with a tin-can telephone when we were kids. Remember those? You take two tin cans, punch holes in the bottom, stretch a string tightly between them, and voilà! You have a can-to-can network!
On a more serious note, we’re here to tell you about something incredibly useful and far more modern. The acronym actually stands for Controller Area Network, but even knowing what it stands for doesn’t tell us much about it.
Let’s take a look at the history of this protocol in order to find out more.
CAN Bus History
The CAN bus was originally conceived of and optimized for transportation applications.
Toward the end of the 20th century, existing automotive electronics used complex, point to point analog wiring. As sensors, devices, and subsystems proliferated, the complexity and sheer weight of wiring became unmanageable.
This led to a perceived need for a way to simplify interconnections and standardize automotive electronic devices. A bus and a protocol—fast enough to do the job, but more robust than existing networks, and able to function in electrically noisy environments—was desperately needed.
The development of this technology began in 1983 at Robert Bosch GmbH. The results were released at an SAE conference in 1986. Semiconductor manufacturers began designing and producing compatible chips, and—starting in the early 1990s—automobile manufacturers began to use CAN technology in their vehicles.
Since then, the publication of CAN standards (see the ISO 11898-n series) and the use of the CAN bus for vehicle onboard diagnostics and other purposes has exploded worldwide. This protocol has also made its way into many industrial and medical applications. It is even being applied in building automation, elevators, and in more exotic applications like drones and prosthetic limbs.
Some CAN Bus Basics
The CAN bus boasts many subtleties and complexities, so in this article, we will be introducing it at a general, simplified level. Our goal is to give you the flavor of CAN, not necessarily a detailed explanation of how it works (although we will reveal some important details).
Even so, because it is standardized and device and system manufacturers have already done a lot of the “heavy lifting” for you, you should (as an IoT implementer) be able to jump off from here and begin using it, if that is your goal. Why should that be your goal? Let’s take a peek at some…
Benefits
The CAN bus has some really neat properties that make it very different, and in some ways more useful, than SPI and I2C. But what makes it a good choice for use in the rigorous environments common to transportation and industrial settings?
- Low node and system cost
- Central monitoring and control are possible, though not required
- Robust — resistant to electrical and electromagnetic noise
- Efficient, thanks to support for priority without interruptions
- Flexible — all nodes receive all traffic, enabling cooperative systems
These general benefits of the CAN technology make it attractive and have led to its widespread use. Costs are reduced because of design standardization, mass production, and fewer interconnects. Systems with central controllers and monitors are possible because of how the protocol works. The CAN electrical definition protects against noise, and its protocol design offers noise detection and remediation. Designers can use the inherent CAN protocol to ensure that time-dependent events are handled without losing track of lower priority functions. Additionally, each node in the network has the flexibility to use or ignore any network data.
Let’s take a look at some of the details of exactly how CAN works in order to provide us with all these benefits.
Some Gritty Details
A Simplified Pictorial Overview
To help orient you to what’s coming up, here’s a simplified visual of a CAN bus network.
This sketch illustrates a ‘classical’ high-speed CAN bus with seven nodes. Although not explicitly specified by the standards, the maximum number of nodes in a practical implementation is dependent on the bus and stub lengths, data rates, and the quality of the cabling and connectors in the physical layer.
Digital Data
CAN, of course, uses digital data to eliminate the long runs of analog circuitry that were typical in earlier automotive system designs. The bus makes this digitized data universally available to every node in the network, to be used as needed.
Twisted Pair
No, we’re not talking about a heavy metal rock group…
But, as far as physical layers go, networks don’t get much simpler than this.
A twisted pair (as used in this scenario) is actually two signal wires, CANH (‘H’ for High) and CANL (‘L’ for Low), twisted around each other, and attached to every node in the network. Although the ISO 11898-2 standard doesn’t explicitly require a twisted pair, using it is good practice and makes the network more reliable.
In addition to those two wires, each node needs power and ground. However, because vehicles typically use their metal chassis as a ground connection and often already have a power bus in place, nodes typically tap into power and ground at convenient local points. Of course, nodes also need to connect to whatever sensors, computers, and other devices they may be serving.
Electrically-Based Noise Immunity
CAN uses quasi-differential signaling on its two bus conductors. This simply means that when a node is transmitting a ‘zero’ on the bus, it drives a (nominally) five-volt potential between CANL and CANH, with CANH at the positive voltage level. This is called the dominant bus state. When a node is sending a ‘one’ (or simply listening), termination resistors on the bus are allowed to return CANH and CANL to the same low level. This is called the recessive bus state.
Note carefully that this is logically “upside down.” The dominant level—i.e., the presence of a voltage between CANH and CANL—signifies a LOGICAL ZERO (0). Likewise, the recessive level—i.e., the absence of voltage being driven on the bus—signifies a LOGICAL ONE (1). Fortunately, details at this level are all handled by the microcontrollers and hardware, so we don’t have to consciously fuss over them (other than when we’re trying to understand how CAN works).
Use The Right Terminator!
When designing a CAN bus system, be sure that you employ the right kind of terminator.
To facilitate that, we are pleased to provide you with this informative illustration.
The most common, ‘Classical’ high-speed CAN bus (ISO 11898-2) uses only two 120 ohm termination resistors—one at each end of the bus—and operates at 1 Mbit/second.
A second version—low speed, fault-tolerant CAN (ISO 11898-3)—has a termination resistor at each node, and operates at speeds up to 125 Kbps. Unfortunately, determining values for those terminators is a more involved process. It’s described in painful detail on Pages 4-10 through 4-12 of, for example, National Instrument’s NI-CAN Hardware and Software Manual.
Shifting Gears: A Third Transmission Speed!
The newest CAN bus on the block is called CAN FD. Just beginning to come on the scene during the third decade of the 21st century, it boasts speeds of up to 8 Mbit/second, as well as larger data packets (64 bytes vs. 8 bytes) than its predecessors.
Asynchronous, Peer-Level, Multi-Master Conversations
Any node on the bus can initiate communication at any time. Because of this, any node can become the bus master, because all nodes operate as peers.
You might think of this as somewhat akin to having a conversation at a cocktail party. You (a node) are standing among some number of other party-goers (other nodes), listening to the conversation. When you have something useful or important to say, you’re free to chime in.
Maybe you’re responding to something someone else said. Maybe you have some new thoughts of your own to contribute to the conversation. Or, maybe, you’re in the mood to simply listen to and enjoy what everyone else is saying, filing it away in your memory for future reference.
What you are doing quite naturally at the party is following an accepted protocol that enables the conversation to progress very easily, even in a noisy room.
Talking in CAN: The Frame
This might be a good time to describe a CAN bus message frame.
When there’s a lull in the party conversation, and you have a tidbit of juicy gossip that you’re dying to share, you simply start talking. It’s just too good to hold back, so out with it!
The CAN equivalent of a lull in the conversation is when no node is talking. The bus is idle, i.e., CANH and CANL are at the same recessive voltage level for a long time. You could think of this silence as an endless stream of ‘1’s on the bus.
You probably don’t speak CAN…
But, if you did, during that lull in the conversation, you might say something like this:
Frame Fields
You’d begin your ‘CANdid’ comment by suddenly “breaking the silence.” It makes perfect sense, then, that the SOF (Start of Frame) would be a single dominant, or ‘0’ bit, to begin the frame. The cocktail party equivalent might be for you to cough loudly to get everyone’s attention…
Now, everybody is listening. But who the heck are you, anyway? Better identify yourself.
“Hi! Can I introduce myself? I’m Canby Canfield from Canton, Canada.”
The CAN-ID both identifies and prioritizes the node that is “talking” on the bus.
After a few bits for housekeeping (RTR and Control), you finally get to the meat of the conversation—up to sixty-four bits of Data payload.
“Can you believe the scandal? I hear that Candace contracted candida!”
You’ve said your piece. Now, anyone who happens to care about Candace can chime in with their own comment. And don’t worry, we’ll get to the CRC, ACK, and EOF fields in a minute…
By the way—at both the bit-timing level and the field level, CAN frames can actually be even more complicated than this (we told you this was complicated, right?). They might include some fancy (but essential) footwork design details like bit-stuffing, error frames, remote frames, overload frames, intermission, and inter-frame spacing.
Does all this complexity make you feel like canning the whole thing? Once again, thank goodness, most of those hairy details are handled for you by the hardware and microcode of the CAN node transceiver.
But what if it’s really noisy at the party? And how does the CAN bus handle errors?
Protocol-Based Noise Immunity
Continuing the cocktail party metaphor, if it’s noisy and you hear only part of the scuttlebutt, you can simply ask, “Would you please repeat that? I missed the good stuff!”
Similarly, the CAN bus message format includes an ACK (Acknowledgement) field as well as a CRC (Cyclic Redundancy Check) field to facilitate message retries. These fields, together with higher-level system protocols, ensure that errors are detected, and important information is not lost.
However, sometimes two people start talking at once. You know how to handle that at a party. However, what if two or more nodes start “talking” at the same time in a system? Do their outputs just collide on the bus?
The answer is, of course not! That would be ridiculous. When a collision occurs on the bus, in order for it to continue working seamlessly, two things have to happen at once: synchronization and arbitration.
Synchronization
Synchronization actually happens constantly, whenever one node listens to another on the network. All nodes are—more or less—running at the same speed. However, there is no central master-clock. This means that at the bit-timing level, every node has to listen to and synchronize with the bit-timing of any node that is transmitting.
Nodes do this by taking careful notice of transitions between the low voltage, recessive bus level, and the high, dominant bus level. They then adjust their own internal bit-timing to match that of the transmitting node. By doing this at every low-to-high transition, each node is able to maintain its synchronization with the node currently transmitting. Maintaining synchronization is another important reason for bit-stuffing.
Arbitration: Who’s The Boss?
When two party-goers start talking at once, because both are also listening, one typically yields and allows the other to continue. Similarly, on the bus, if two nodes begin transmitting a message at the same time, one will yield to the other. Here’s how:
Every node on the CAN bus is assigned a Node ID that uniquely identifies that particular node on the network. The Node ID also sets the node’s priority level. The lower the ID number, the higher its network priority.
This design convention, combined with the fact that the dominant level represents logical zero, enables nodes to easily determine who wins access to transmit on the network. Let’s look at a simplified example of how this works. For the sake of simplicity, we’re assuming Node IDs are only three bits long, and we aren’t showing every detail of the frame.
First of all, all nodes are listening to the network all the time. This means that each node already knows if another node is in the middle of sending a network message frame. But how can it be sure if the node in question has just been reset?
Even if a node has just been reset or hot-plugged into an active bus right in the middle of another node’s frame transmission, the CAN protocol saves the day. By relying on the frame definition, the node can distinguish between the EOF (End Of Frame) or a longer duration ‘bus idle’ condition. It does this by noting that the bus has been in the recessive state for at least eleven bit-times (i.e., the sum of CAN EOF and CAN Interframe Spacing).
When Does it Matter?
The only time arbitration becomes necessary is when two or more nodes randomly happen to begin a transmission at the same time. In this diagram, Node 1 (binary 001) and Node 2 (binary 010) start transmitting at the same time:
Here’s what happens next:
Both nodes contending for the bus are, simultaneously, listening to the bus. This means they both see/hear each other’s dominant SOF bit, and both immediately begin synchronizing with one another. But each doesn’t (yet) know whether or not it is the highest priority. Next, they both transmit ‘0’s, the same first bit of their respective IDs. Both “hear” ‘0’s. But at the next bit, Node 1 transmits a ‘0’, while Node 2 transmits a ‘1’. Because the zero is dominant, that is what goes out on the bus. When Node 2 “hears” a ‘0’ instead of the ‘1’ it transmitted, it knows it has lost the arbitration, and it immediately stops transmitting (but it continues to listen, in case it needs to act on the message that Node 1 is sending).
When Node IDs are assigned so that the most important, most often used nodes have the highest priorities, the CAN network bandwidth is utilized most efficiently.
Topology and Bus Length
CAN network topology is not constrained. Just like people standing around at a cocktail party, nodes can be anywhere in relation to one another, as long as they are connected to the same two wires. Practically speaking, however, the fewer nodes branching off in all directions and the shorter the bus, the less reflections occur, and the faster the system can run.
Remarkably, the CAN bus can, in industrial settings, extend for an amazing 500 meters if transmission speed is constrained to 125 kbps, and even farther at lower data rates. But as the saying goes, “the devil is in the details.”
The CiA (no, not that CIA, this one—the ‘CAN in Automation’ international users’ and manufacturers’ group) offers these recommendations for total bus and aggregate stub lengths. If you’re designing a complete CAN bus system, you will no doubt want to take specific topology and bus length details into account as described, for example, in this application note.
So, Is CAN A Good Candidate for You?
What does it all mean? In this article, we’ve really just scratched the surface of what a CAN bus network is and what it can do for you. Be sure to check the references and resources below if you want to expand your knowledge of this interesting protocol.
If you’re creating devices for use in a vehicle, or in any noisy commercial environment, the CAN bus may be just your cup of tea. You can find a huge variety of ready-to-rock CAN network devices off the shelf, as well as microcontroller chipsets that you can design into your own CAN network node devices.
If you want to remotely connect to existing CAN networks, NetBurner has exactly what you need to get started; check out the product links below.
Maybe it’s time to jump in feet first and start experimenting. Sometimes, as the saying goes, “The proof of the pudding is in the eating.” Why not give CAN a try, and see for yourself?
CAN we help you? You bet we CAN!
Many NetBurner products support the CAN bus with the development kit. Here’s a list for your convenience:
Put NetBurner Support On Speed Dial
Our mission here at NetBurner is to help with your development efforts. If you have any thoughts or remaining curiosity about CAN, or if we can answer a question for you about any of our products, please let us know in the comments below, or drop us a note by email at [email protected].
Some NetBurner CAN Resources
- NetBurner Support for the J1939 Standard — J1939 Solutions
- NetBurner Support for CANopen — CANopen Solutions
- Runtime Library Documentation — https://www.netburner.com/download/runtime-libraries/
Other CAN Resources
- CSS Electronics — CAN BUS Explained – A Simple Intro (2020)
- Wikipedia — CAN Bus
- ISO — International Organization for Standardization
- Analog Devices—Controller Area Network (CAN) Implementation Guide
- National Instruments — Controller Area Network (CAN) Overview
- Microchip AN228 — A CAN Physical Layer Discussion
- CiA (CAN in Automation) — CiA Website
- Worcester Polytechnic Institute — Encoding and Physical Study of the CAN BUS Sensor Network
Glossary
- CAN — Controller Area Network
- I2C — A board and system-level serial bus
- OBD — On-Board Diagnostics
- ISO — International Organization for Standardization
- ECU — Electronic Control Unit, i.e. a node on the CAN bus
- Node — An individual participant in a CAN network
- CANH — The CAN network conductor that is actively driven to a HIGH voltage level
- CANL — The undriven CAN network conductor that remains at a LOW voltage level
- Dominant — A high (Logical 0) differential level between CANH and CANL
- Recessive — A low (Logical 1) differential level between CANH and CANL
- Terminating resistor — The component used to bring the CAN bus back to a recessive level
- Protocol — A set of rules that define sequences, timing, and format of data traffic on a network
- Arbitration — The process by which one node at a time gains control of the CAN bus
- Bit Stuffing — Adding extra bits in order to maintain synchronization
- Field — A defined portion of a CAN message frame
- Frame — One complete CAN message composed of multiple fields
- SOF — Start Of Frame
- CAN-ID — Field containing the unique CAN node identifier, including its priority
- RTR — Remote Transmission Request field (See “Remote Frame”)
- Control — Field containing other subtle and at times confusing CAN bus details
- Data — The most important CAN message field
- CRC — A Cyclic Redundancy Check checksum
- ACK — Any and all nodes respond with a dominant bit if they have received a good message
- EOF — End Of Frame, consisting of eight dominant bits
2 thoughts on “The CAN Protocol: Of Course We CAN… Can You?”
Thanks, I really like the article – the right technical depth for me and conversational and witty.
Robert
That was really well written and in-depth article. Great job whoever wrote it. Hope to see more new articles