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 is an ingenious communication technology, but part of its strength comes from what it does not attempt to do.
CAN provides highly reliable transmission, nondestructive bus arbitration, extensive error detection, automatic retransmission, and mechanisms for removing persistently faulty nodes from the network. At the same time, it leaves many functions that developers may expect from a network protocol entirely to the application.
Some of these characteristics are easily overlooked, even by engineers who have worked with CAN for years.
CAN Does Not Have Node IDs
Neither Classical CAN nor CAN FD provides native node IDs.
A CAN data frame does not contain a source address identifying the node that transmitted it, nor does it contain a destination address identifying the node that should receive it.
Instead, CAN uses a CAN Message ID.
The basic principle is simple: A node transmitting a message does not know—or even care—where that message goes. All nodes connected to the network see the same data frame and determine whether they are interested in it, usually through the CAN controller’s acceptance filters.
The reverse is equally important. A node receiving a CAN message does not inherently know which physical node transmitted it. It receives a CAN Message ID and the associated data.
At first, this may sound restrictive. In practice, it is one of CAN’s strengths.
The CAN controller does not need to maintain addresses, routing information, connections, or information about the other devices on the network. A node simply publishes information onto the bus, and interested nodes receive it.
The simpler, the better.
If an application requires node addresses, source identification, destination addresses, network management, or similar functionality, those features must be implemented by the application or by a higher-layer protocol.
CANopen, SAE J1939, and NMEA 2000 are examples of protocols that add such functionality on top of CAN. The important distinction is that these are features of the higher-layer protocol, not CAN itself.
