A quick guide to tune your CAN interface-I

Since it was introduced in the 1980s, the controller-area network (CAN) has evolved tremendously. Its extended capabilities have led to its wide adoption across applications, from automotive to industrial machine and factory automation. With this growth, complexity of implementation has also increased on two levels:

• CAN controller design has gone from a basic controller to a full CAN controller and, in some cases, an extended full CAN controller.

• CAN software stacks vary, from an automotive communication stack to CANOpen and DeviceNet.

Given that CAN is only a single component within the automotive system, developers need to be able to implement it with as few challenges as possible so they can focus on system-level functionality rather than struggle with peripheral configuration. This article will explore the CAN interface and discuss different ways of implementing, configuring, and tuning interfaces that simplify design.

A little CAN history
CAN was first introduced by Robert Bosch GmbH to address the growing complexity of vehicle functions and networks. In the early days of embedded systems development, modules contained a single microcontroller unit (MCU) performing a single or multiple simple functions, such as reading a sensor level via an analog-to-digital converter (ADC) and controlling a DC motor, as shown in Figure 1. As these functions became more complex, designers adopted distributed module architecture, implementing functions in two or more MCUs on the same printed circuit board and using I²C (inter-integrated circuit) or System Packet Interface (SPI) protocols to communicate between these functions. Continuing with the DC motor example, a complex module would have the main MCU performing all system functions, diagnostics, and fail-safe, while another MCU handles a brushless DC (BLDC) motor control function. This was made possible with the wide availability of general purpose MCUs at a low cost.

In today's vehicles, as functions become distributed within a vehicle rather than a module, the need for a high fault tolerance, inter-module communication protocol led to the design and introduction of CAN in the automotive market.

By the mid-1990s, CAN had seen wider adoption beyond automotive applications, venturing into industrial controls with the introduction of DeviceNet and CANOpen protocols.

With this traction in the market, many MCU suppliers have integrated a CAN controller as an integrated peripheral to address these markets. Although at a high level, CAN might seem similar in function to I²C or SPI, allowing communication between two nodes, CAN's communication is fundamentally different at the controller level, offering the services listed:

• CAN communication is message based, not address based.

• A CAN node can send or request a message on the bus.

• CAN provides complex error handling.

• Up to five corrupted bits in a row can be detected with CRC-15 protection.

Being message based versus address based, a node on the CAN bus could own multiple messages for transmission. For example, a brake module might have a message containing vehicle-speed information, a message containing sensor information from wheel-speed sensors, and a message containing the diagnostics information, the latter having the highest transmit priority.

At first look, one might think that with all those message priorities and message ID decoding in a node, CAN would create a high load on the CPU, preventing additional more complex functions from being integrated. This issue is addressed by different types of CAN controllers also shows in Figure

• Basic CAN controller: A basic CAN controller povides very basic filtering implemented in the CAN controller hardware, with reduced message handling, leading to a high CPU load. In a basic CAN controller, the CPU would receive multiple interrupts from the CAN controller in order to receive, acknowledge, and parse a message, and from the application side, decide whether or not a response should be transmitted based on the ID of the received message. Basic CAN controllers should only be used in low baud-rate and low message-count communications, allowing the CPU to handle additional noncommunication tasks.

• Full CAN controller: A full CAN controller provides an extensive implementation of message filtering, as well as message parsing in the hardware, thus releasing the CPU from the task of having to respond to every received message. Full CAN controllers can be configured to interrupt the CPU with only those messages whose identifiers have been setup as acceptance filters in the controller. Full CAN controllers are also setup with multiple message objects referred to as mailboxes, which can store specific message information such as ID and data bytes received for the CPU to retrieve. The CPU, in this case, would retrieve the message any time but must complete the task prior to receiving an update of that same message and overwriting the current content of the mailbox. This scenario is resolved in the final type of CAN controllers.

• Extended full CAN controller: The extended full CAN controller provides an additional level of hardware-implemented functionality by using a hardware FIFO (first in, first out) for received messages. Such an implementation allows more than one instance of the same message to be stored before the CPU is interrupted, therefore preventing any information loss for high-frequency messages, or even allowing the CPU to focus on the main module function for a longer period of time.

It's also important to note that DeviceNet extends the filtering criteria beyond the ID field to the first two bytes of data, making a full or extended full CAN controller a must for implementing such a protocol.