Protocols
CAN — Controller Area Network
A differential, multi-master, broadcast bus designed for noisy electrical environments — originally automotive, now everywhere from factory floors to elevators. Its defining trick isn't the wiring, it's arbitration: multiple nodes can start transmitting at once and the bus resolves who wins, bit by bit, without corrupting anyone's message.
- What it is
- A differential, multi-master bus where every node hears every frame, and priority is resolved electrically instead of by software.
- Mental model
- A meeting where everyone can speak at once, but the moment two people talk over each other, the one with something more urgent to say is the only one still heard.
- Key numbers
- 2 wires (CAN_H, CAN_L), up to 1 Mbit/s classical (much higher for CAN FD's data phase), 11 or 29-bit identifiers, 120 Ω termination at each bus end.
- Reach for it when
- Multiple nodes need to share one bus reliably in an electrically noisy environment, with guaranteed message priority.
Physical layer: dominant and recessive
CAN runs over a twisted differential pair, CAN_H and CAN_L. Every node can only drive the bus to one of two states:
- Dominant (logic 0)
- A node actively pulls CAN_H high and CAN_L low, widening the differential voltage. Any node driving dominant wins over one driving recessive — this is the physical fact arbitration is built on.
- Recessive (logic 1)
- A node simply stops driving; pull resistors bring the differential back near zero. If nobody drives dominant, the bus reads recessive.
Because dominant always overrides recessive when both happen at once, the bus behaves like a wired-AND: the resulting bus level is dominant if any node drives dominant, recessive only if every node is recessive.
Why 120 Ω, and why only at the two ends
The CAN_H/CAN_L twisted pair isn't just a wire at these signal speeds — it behaves as a transmission line with its own characteristic impedance, around 120 Ω for the cable CAN's spec calls for. A signal traveling down that line reflects part of its energy back whenever it hits anything that isn't that same impedance — an open, unterminated end, in particular. Those reflections superimpose on the real signal and, with CAN's fast edges, can corrupt bits. A resistor matched to the line's own impedance placed at a true end absorbs the traveling wave instead of bouncing it back — that's ordinary matched-termination theory, not a CAN-specific rule.
A node in the middle of the bus is a short stub tapping off the line, not an end — putting a 120 Ω resistor there does nothing to stop reflections at the real ends, and instead adds another 120 Ω in parallel with everything else. Five "terminated" nodes in parallel works out to roughly 24 Ω of total load, far below what a CAN transceiver is designed to drive, and it flattens the differential voltage swing enough that dominant and recessive may stop reading reliably at all.
Classical CAN tops out around 1 Mbit/s; see CAN FD for how newer controllers push that further.
Multi-master, broadcast, no addresses
Unlike I2C's addressed devices or SPI's per-device chip select, a CAN frame has no destination address at all. Every node on the bus receives every frame and decides for itself, based on the frame's identifier, whether to process it or ignore it (typically via a hardware acceptance filter so the CPU isn't interrupted for traffic it doesn't care about). Any node can start transmitting whenever the bus is idle — there's no single bus master.
Arbitration, bit by bit
If two nodes start transmitting at exactly the same time, CAN resolves the conflict without either message getting corrupted or needing a retry from scratch. While transmitting, every node also reads back the actual bus level. If a node sends recessive but reads back dominant, some other node is transmitting a dominant bit at that position — meaning that node's identifier is numerically lower, and this node has just lost arbitration. It immediately stops driving and switches to listening, and automatically retries once the bus goes idle again. Nothing is corrupted: the winning node's frame transmits exactly as if it had the bus to itself.
The practical consequence: lower numeric identifier = higher priority, and priority is enforced by the bus itself, not by software. This is what makes CAN genuinely real-time — the highest priority message pending anywhere on the bus always gets through first, deterministically.
Frame format
A standard (CAN 2.0A) data frame, 11-bit identifier:
| Field | Purpose |
|---|---|
| SOF | Start of Frame — a single dominant bit that marks the beginning; also what other nodes synchronize to. |
| Identifier | 11 bits (standard) or 29 bits (extended) — determines both priority (via arbitration) and meaning/content, not a destination address. |
| RTR | Remote Transmission Request — dominant for a normal data frame, recessive for a remote frame (a request asking another node to send data with that ID). |
| IDE / r0 | Identifier Extension bit (distinguishes standard vs. extended frames) plus a reserved bit. |
| DLC | Data Length Code — how many data bytes follow (0–8 in classical CAN). |
| Data | 0 to 8 bytes of payload. |
| CRC + delimiter | 15-bit checksum over the frame, catching transmission errors. |
| ACK slot + delimiter | The sender leaves this bit recessive; any other node that received the frame correctly overwrites it dominant — acknowledgement without naming who acknowledged. |
| EOF | 7 recessive bits marking the end of the frame. |
Extended (CAN 2.0B) frames use a 29-bit identifier (11 base bits + 18 extension bits) for a much larger ID space, at the cost of a slightly longer arbitration phase — everything else about arbitration and framing works the same way.
Bit stuffing
CAN encodes bits directly as bus voltage levels (NRZ) with no separate clock signal — receivers resynchronize on every edge they see. To guarantee edges keep appearing even during long runs of identical data, a transmitter automatically inserts one bit of the opposite polarity after every five consecutive identical bits (in most parts of the frame); receivers automatically remove it. This also gives error detection a freebie: six identical bits in a row where stuffing should have broken them up is itself a detectable stuff error.
Error handling and bus-off
Every node tracks a Transmit Error Counter and Receive Error Counter, incremented on detected errors (bit, stuff, CRC, form, or acknowledgement errors) and decremented on successful communication. Those counters drive three states:
| State | Behavior |
|---|---|
| Error-active | Normal operation. On detecting an error, the node broadcasts an active error flag (dominant bits) that destroys the current frame for everyone — forcing a clean retry rather than letting a corrupted frame silently propagate. |
| Error-passive | Entered once error counts pass a threshold. The node can still transmit and receive, but its error flags are now recessive — it can no longer forcibly interrupt other traffic, a deliberate throttle on a node that's already causing trouble. |
| Bus-off | Entered once error counts pass a second, higher threshold. The node electrically disconnects itself from the bus entirely and needs a reset/recovery sequence to rejoin — the bus's last line of defense against a single malfunctioning node jamming everyone else. |
CAN FD
CAN FD (Flexible Data-rate) extends classical CAN with two changes: payload grows from 8 bytes up to 64 bytes, and a Bit Rate Switch (BRS) lets the frame's data phase run at a much higher bit rate than arbitration phase (which stays slow enough for reliable arbitration across the whole bus). Arbitration itself works identically to classical CAN — the speed and payload gains only apply once a node has already won the bus. CAN FD controllers can usually still talk classical CAN, but classical-only controllers can't decode CAN FD frames on a shared bus, so mixing them needs care.
CAN vs. SPI vs. I2C vs. UART
| CAN | SPI | I2C | UART | |
|---|---|---|---|---|
| Topology | Multi-master bus, any number of nodes | Single controller, per-device CS | Multi-drop, addressed | Point-to-point |
| Addressing | None — content-based ID, broadcast to all | Physical (CS line) | In-band address | None needed |
| Priority handling | Built into the bus (arbitration) | None — controller decides | None | None |
| Typical range | Tens of meters, noisy environments | Short, on-board | Short, on-board | Short to moderate |
| Typical use | Automotive/industrial networks of many nodes | Fast on-board peripherals (flash, displays) | Low-speed on-board sensors | Simple point-to-point links, console access |
- Pros
- Deterministic priority via arbitration, built-in error detection and automatic retry, tolerates long noisy cable runs, and any number of nodes share two wires with no per-device pin cost.
- Cons
- Small payload (8 bytes classic CAN, still modest at 64 bytes for CAN FD), lower raw throughput than SPI, and it needs a dedicated CAN transceiver chip rather than just GPIO pins — real hardware cost SPI/I2C don't have.
- Reach for CAN when
- Multiple independent nodes genuinely need to share one bus reliably, over meaningful distance, with guaranteed message priority — an automotive or industrial network of several ECUs/controllers, not a single microcontroller talking to a handful of on-board sensors.
- Reach for something else when
- You're wiring one microcontroller to nearby chips on the same board — SPI for high throughput, I2C for pin-count-constrained low-speed sensors. CAN's arbitration and error handling solve a multi-node problem that doesn't exist yet on a single board with one controller.
Real-world applications
- Automotive ECUs — engine control, ABS, airbag, and body-control modules all share one or more CAN buses inside virtually every modern car.
- Industrial automation — CANopen (a higher-level protocol built on CAN) coordinates motor controllers, I/O modules, and PLCs on factory-floor equipment.
- Elevators and building systems — CAN's noise immunity and multi-node design fit long, electrically messy cable runs between floors.
- Agricultural and construction equipment — ISOBUS (also CAN-based) standardizes communication between tractors and attached implements from different manufacturers.
- Drones and robotics — CAN is increasingly used for motor controller and sensor networks where reliability matters more than raw bandwidth.
Gotchas
- Termination at every node (instead of exactly the two physical bus ends) is the single most common CAN wiring mistake — it under-terminates the bus and causes reflections that look like intermittent, hard-to-reproduce errors.
- A node stuck retransmitting a losing message over and over on a busy bus with many higher-priority nodes can genuinely starve — identifier assignment is a real design decision, not an afterthought.
- A silently bus-off node stops participating entirely with no frame ever indicating why — check error counters and bus-off state directly, not just "is data arriving."
- On Linux, CAN is exposed through SocketCAN — a network protocol family, not a character device like spidev or i2c-dev — see examples and Linux drivers.