CAN Background

CAN History

CAN (controller area network) is a serial bus protocol created in the mid-1980s by the German company Bosch. It is optimized for sending small amounts of data between multiple nodes. CAN is not a fast bus by today's standards, with a maximum data rate of only 1 Megabit per second. However, operating at low data rates makes CAN quite robust to noise and allows buses to span long distances.

CAN was originally designed for use in automobiles, but has also become popular in low-bandwidth industrial applications such as controlling assembly line machines.

Although Bosch's CAN specification does not define standard CAN voltages or connector interfaces, standards organizations have defined multiple physical standards. The most common CAN physical layer standard is ISO 11898-1, but others are also used.

CAN Theory of Operation

CAN allows multiple devices (referred to as "nodes") to connect to each other on a single bus, as shown in Figure 1. Unlike other protocols, such as I2C and SPI, CAN nodes do not have strict master/slave roles. Instead, each CAN node may operate as a transmitter or receiver at any time.

Figure 1: Multiple nodes on a CAN bus.

Rather than sending data to specific targets, data messages are broadcast to all nodes on the bus. Each receiver node decides for itself if the data is relevant by looking at the message frame's "identifier," which describes the content of the message. A message's identifier also represents the priority and allows for automatic arbitration when multiple nodes try to transmit at the same time.

A CAN bus can have two bit states: dominant or recessive. If one node sends a dominant bit and another sends a recessive bit, the result will be dominant (as shown in Table 1). Automatic arbitration is built in to the CAN protocol as all nodes must monitor the bus state during transmission and cease transmission if a dominant bit is seen when sending a recessive bit.

Table 1: CAN Bus state when two nodes are transmitting

	Dominant	Recessive
Dominant	Dominant	Dominant
Recessive	Dominant	Recessive

The CAN protocol specifies four fundamental frame types which nodes use to interact:

Data Frame - carries 0-8 bytes of data, along with an identifier and CRC check
Remote Frame - requests a data frame transmission with a certain identifier node
Error Frame - transmitted when an error is detected
Overload Frame - provides extra delay between data and remote frames

For more details on message frame formatting, please consult Bosch's CAN specification 2.0 and the other resources listed in Section 1.1.

Further physical layer details are undefined by CAN specification "so as to allow transmission medium and signal level implementations to be optimized for their application." Common physical layer implementations, such as the ISO 11898, use a balanced differential CAN bus. For more information about the Komodo interface's compatibilities, please refer to Section 2.

CAN Features and Benefits

CAN has many important features and benefits, including:

Multi-master - All nodes can transmit and receive messages.
Automatic prioritization of messages - Based on message identifier.
Automatic arbitration - Based on message identifier.
High reliability - Achieved through built-in error checking.
Robust - High performance, even in difficult electrical environments.
Configuration flexibility - Nodes can be added to and removed from the bus without modifying other nodes.
Many nodes can be connected on the same bus - CAN 2.0B defines identifiers as 29 bits, providing over 500,000 unique codes.
Buses can be very long - On the order of miles and kilometers.
Low cost

CAN Drawbacks

Here are a few drawbacks when using CAN:

Low-bandwidth - CAN supports a maximum data rate of 1 Mbps. This is not good for high-bandwidth applications.
Small data transfers - data frames can only carry 8 bytes, so CAN is not good for large data transfers.
Protocol overhead - The CAN protocol has a moderate amount of overhead (strict message formatting, CRC checking, bit-stuffing, etc.) and is more complicated than other protocols such as I2C and SPI.

CAN is well-suited for connecting many devices that have small amounts of data to share with each other at low data rates. Applications other than this, such as reading from a large memory device, would not use CAN.

CAN References

CAN Specification 2.0 - Bosch
Controller Area Network Wikipedia article - Wikipedia
Good introduction to CAN - Staffan Nilsson