What Is CAN Bus?

Detailed Explanation

Bosch developed CAN in the 1980s to replace the heavy point-to-point wiring looms between automotive ECUs. Rather than running a dedicated wire from every module to every other module, CAN lets any number of nodes share two wires and communicate asynchronously, with the bus itself arbitrating conflicts. That design has since been adopted in industrial automation, medical devices, and any application where multiple embedded nodes need a robust, electrically noisy-tolerant shared bus.

Physical layer: differential signalling

CAN_H and CAN_L are driven differentially. A dominant bit (logic 0) drives CAN_H to approximately 3.5 V and CAN_L to approximately 1.5 V — a differential of around 2 V. A recessive bit (logic 1) lets both lines float to approximately 2.5 V (zero differential). A receiver uses only the differential voltage, so common-mode noise affecting both lines equally is rejected. This is the core reason CAN works reliably in electrically noisy automotive and industrial environments where UART or SPI would fail.

The bus requires 120 Ω termination at both physical ends to absorb reflections. Missing termination is the single most common CAN bring-up mistake — the bus often appears to work at low bit rates with short cables but fails intermittently in deployed hardware.

Frame format and bit-level arbitration

CAN messages are identified by a numeric ID (11-bit in base frame format, 29-bit in extended format) rather than a device address. Every node sees every frame; hardware acceptance filters in the CAN controller decide which IDs to pass to the software.

When two nodes transmit simultaneously, non-destructive bitwise arbitration resolves the conflict: each transmitter monitors the bus while transmitting. Dominant overwrites recessive; if a node transmits a recessive bit but detects a dominant bit on the bus, it backs off immediately. The node with the lowest numeric ID always wins — lower ID = higher priority. The losing node automatically retries when the bus is next idle.

Error detection and fault confinement

CAN uses five complementary error detection mechanisms: CRC check, frame check, acknowledgement check, bit monitoring, and bit stuffing. Every node tracks transmit and receive error counts. A node that accumulates too many errors transitions from error-active (can flag errors) to error-passive (cannot assert error flags) to bus-off (disconnects from the bus entirely). This fault confinement prevents a broken node from disrupting all communication on the bus.

CAN FD

CAN FD (Flexible Data-Rate, ISO 11898-1 2015) extends CAN in two ways: the payload increases from 8 bytes to up to 64 bytes, and the data phase switches to a higher bit rate (typically 2–8 Mbit/s) while the arbitration phase remains at the standard rate. CAN FD requires CAN FD-capable transceivers and controllers throughout — a single classic CAN 2.0 node on a CAN FD bus will generate errors.

Practical Examples

An automotive body control module network runs CAN at 500 kbit/s. The engine ECU transmits speed, throttle position, and fault codes on specific IDs; the ABS module transmits wheel speeds; the dashboard module listens for the IDs it needs to display gauges. No node addresses any other node directly — each node publishes data by ID and each receiver configures its hardware filter to accept only the IDs it requires.

In an industrial servo drive network, a motion controller node transmits torque setpoints to 8 drives every 1 ms over a 1 Mbit/s CAN bus. The deterministic priority arbitration and sub-millisecond round-trip response make CAN preferable to RS-485 here, where Modbus RTU's polling overhead would consume too much of the available bus cycle time.

Design Considerations

• Transceiver selection: match the transceiver supply voltage to the MCU IO voltage. The TJA1050 and MCP2551 require 5 V supply and may not be tolerant of 3.3 V logic from the MCU without a level shifter. The SN65HVD230 and MCP2562 support 3.3 V operation directly.
• Termination: 120 Ω at both bus ends only — not at intermediate nodes. A star topology with multiple stubs degrades signal quality significantly at bit rates above 250 kbit/s. Use a daisy-chain topology wherever possible.
• Bit timing: the bit time is divided into time quanta; the sample point position (typically 75–87.5%) must be set correctly in the CAN controller. Incorrect bit timing produces communication errors that are difficult to diagnose without an oscilloscope or protocol analyser.
• CAN vs RS-485: RS-485 is simpler and lower-cost for multi-drop point-to-point communication, but requires a polling master (like Modbus RTU) and provides no bus arbitration or built-in error confinement. Choose CAN when you need multi-master arbitration, deterministic message priority, or compatibility with automotive/industrial standards like CANopen or J1939.
• Zeus Design develops CAN bus firmware including controller configuration, message scheduling, and error-handling strategies for STM32 and other embedded platforms. Zeus Design's embedded firmware team handles hardware-software integration for CAN-based products.

Common Mistakes

• Missing or misplaced termination resistors — CAN needs exactly two 120 Ω resistors at the physical ends of the bus stub. Placing them at intermediate nodes, or omitting them entirely, creates reflections that cause errors at moderate and high bit rates.
• Incorrect bit timing configuration — the sample point position and prescaler must be calculated for the MCU clock and target bit rate. Many CAN controller HALs provide bit timing calculation tools; always verify the resulting register values against the CAN specification.
• Forgetting hardware acceptance filters — without filters configured, every frame on the bus generates a receive interrupt. At high bus utilisation, this can starve the MCU of processing time. Configure filters to accept only the message IDs the node actually needs.
• Using CAN 2.0 IDs above 0x600 in J1939 — J1939 reserves specific ID ranges for network management. Using arbitrary extended IDs in a J1939 network causes protocol conflicts.