An Introduction to CAN Bus

2023-08-28 | By Maker.io Staff

The Controller Area Network, typically abbreviated to CAN or CAN Bus, is a serial, message-based communication protocol with the ability to connect numerous devices to exchange data on a single network. Despite its age, CAN is still among the most popular communication protocols. It’s used in various applications across multiple industries, including automotive, manufacturing, and other industrial applications, such as elevator controllers. Read on to discover how the nearly 40-year-old protocol functions and gain insight into its benefits and drawbacks.

How Does CAN Bus Work?

CAN uses two wires for communication, CAN High (CANH) and Can Low (CANL), which form a differential pair to provide enhanced immunity against noise and to increase the reliability of data transfer. A differential pair comprises two electrical conductors that carry complementary signals. Additionally, the voltage of one wire is the inverse of the other. When transmitting a logical zero in CAN, the voltage on CANH is lower than on CANL. Conversely, when sending a logical one, CANH carries a higher voltage than CANL. The voltage difference represents the transmission of data bits.

An Introduction to CAN Bus This figure illustrates how the voltages on the CANH and CANL lines correlate when transmitting bits.

The two wires in CAN are usually positioned close to each other and are designed to have equal impedance, ensuring balanced signal transmission and integrity. For example, two wires twisted together will form a single strand of larger wire. By utilizing this approach, CAN achieves robust data transmission on the physical protocol layer, even in electrically noisy environments like a car ignition system, which can generate significant electromagnetic interference. The design helps minimize data errors and ensures accurate message transmission.

Understanding CAN Bus Messages

Similar to the popular I2C protocol, CAN is message-based, meaning that two nodes in the same network can communicate and exchange messages without establishing a dedicated connection. For this approach to function, each message transmitted on the network must contain the required information used to identify the receiver, importance, content, data, and error-correction measures.

An Introduction to CAN Bus An example of several devices connected to the same CAN bus. Image source: TI datasheet https://www.ti.com/lit/an/sloa101b/sloa101b.pdf

Each message, commonly referred to as a frame, transmits on a CAN Bus network consisting of a predetermined set of bits that individually encode specific parts of the message. CAN describes four types of messages: data, remote, error, and overload frames. Regardless of the message type, each frame begins with a start-of-frame (SOF) bit that indicates the start of each new message.

Data Frames in CAN

The data frame is the sole message used to transmit data between nodes, and it exists in two formats. The base format uses 11 identifier bits, while the extended frame format accommodates 29 ID bits. These unique identifiers represent the message priority based on a non-destructive, bitwise arbitration scheme. When a node sends a frame with a higher priority, messages with a lower priority are temporarily halted until the bus is free.

The RTR (Remote Transmission Request) bit, following the ID, indicates whether a message is a data frame (RTR = 0) or a remote request frame (RTR = 1). Subsequently, the identifier extension bit (IDE) distinguishes between base and extended format messages. In base data frames, this bit is not set. The following bit (r0) is reserved and must be set to zero.

Following these control bits, the data length code consists of four bits that determine the quantity of message bits transmitted in the frame. Next, zero to eight bytes of actual data follow.

Data transmission frames end with additional control bits. Initially, there are 15 CRC bits and a single CRC delimiter, which must always be set. Following that are two ACK bits. The transmitters set the first bit, while any receiver can signal acknowledgment by unsetting this bit. The second ACK bit is always set to one, and the message ends with seven end-of-frame (EOF) bits and three inter-frame-spacing (IFS) bits, all of which must be set.

An Introduction to CAN Bus This image depicts a base data frame in CAN. Note that it omits the stuff bits to better illustrate the logical blocks within the message frame.

Finally, the protocol inserts so-called stuff bits between the actual frame bits to maintain synchronization. This is necessary because the protocol uses sequences of more than five same-valued bits to signal the end of a message. To prevent five data or ID bits from triggering this sequence, the protocol inserts additional stuff bits. All bits before the CRC delimiter bit in the frame are subject to bit stuffing.

Differences Between Base and Extended Data Frames

In CAN, the composition of bits differs slightly between the base and extended data frames. Namely, the SRR bit replaces the RTR bit, with the additional eighteen ID bits following the original IDE bit. The RTR bit then follows the second set of ID bits, while a new, supplementary reserved bit (r1) separates the RTR and r0 bits:

An Introduction to CAN Bus This image shows the differences between the base and extended data frames in CAN. It, too, omits the stuff bits.

Remote, Error, and Overload Frames in CAN

While CAN predominantly relies on nodes to autonomously send out data, communication can also happen on request. For this purpose, a node can send out a remote frame to request data. In this type of message, the RTR bit is set, the data bytes are omitted, and the DLC bits denote the length of the requested data, not the number of sent bits.

Error frames are special messages that don’t follow the rules discussed so far. A node can send out this special type of frame when it detects an error in one of the previously transmitted messages, causing all other nodes on the network to also send out an error message. The original sender then re-transmits the previously incorrect message. Counters within the CAN controllers ensure that this loop does not continue endlessly.

Finally, a node can send out an overload frame if it’s still processing previous messages, thus effectively causing an added delay between messages.

Summary

CAN is a well-established communication message-based protocol that uses two wires for communication. By utilizing this approach, CAN achieves robust data transmission on the physical protocol layer, even in electrically noisy environments like cars. Similar to messages in I2C, each frame in CAN must contain all information necessary to decode a message.

The CAN protocol knows four types of frames, namely data, remote, error, and overload frames, with data frames having two different variations. In summary, data frames consist of control bits, 11 or 29 ID bits, and up to eight bytes of actual data. To further increase robustness against faults, each data frame comes with fifteen CRC bits.

Nodes can utilize remote frames to request data from other communication partners, error frames to signal faults, and overload frames to insert an additional delay between messages. The CAN protocol also mandates the insertion of additional stuff bits in every data frame. These bits are added in every fifth position before the CRC delimiter bit in the frame, and the CAN controllers in each of the receiving nodes take care of removing them before decoding the message.

You can find a subset of our most popular products supporting CAN protocol to get you started with your next project here: Maker CAN Products