• Welcome
• Products
• Security
• Client Work
• Library
• Downloads

Selecting a CAN Controller, 2003

By Olaf Pfeiffer

There are some 22 or so chip manufacturers producing microcontrollers with on-chip CAN bus interfaces. Many differ substantially from each other - what are the selection criteria we can go by?

Introduction

After being around for 15 years, CAN (Controller Area Network) did not yet reach the peak of its lifetime. The number of CAN nodes sold and installed still rises year by year and currently exceeds the number of 200 million new nodes per year (figure for 2001). These sales figures are collected and published by the CiA, the CAN in Automation international users and manufacturers association that also organizes the yearly international CAN Conference. For information about the CiA and available technical documents see the web pages at www.can-cia.org.

Traditionally the CAN bus was primarily used in automotive applications. Today, CAN is one of the best choices for "embedded networking applications" that need to communicate between several embedded 8-bit and 16-bit microcontrollers. Biggest current growth sectors are "embedded machine control" applications: home appliances, industrial machines or other machinery that use multiple microcontrollers that need to communicate with each other. One of the latest examples in this arena is a high-end coffee machine that uses microcontrollers that are interconnected via CANopen.

A big advantage of the CAN bus compared to other network solutions is the price/performance ratio. Price wise, CAN is the most affordable network next to a regular serial channel. As a rule over thumb one can say that it costs about $3 to CAN-enable an existing microcontroller design. Replacing an 8-bit or 16-bit microcontroller with one that features a CAN interface costs about $1. An additional $1 is needed for the transceiver (line driver for twisted pair) and another $1 for connectors and additional PCB area.

The step "replacing a microcontroller with one that features a CAN interface" seems easy, as about 20 different semiconductor manufacturers produce one or multiple microcontrollers with one or multiple on-chip CAN interfaces. However, there are major differences in the CAN controllers available that can make a big difference when it comes to performance. The difference can very well be, that with one device the communication overhead entirely uses up all available MCU performance, whereas on another device the same communication task can be performed with a minimum of MCU execution time.

This article will point out some of the major differences between CAN controllers available and what the consequences are for the application. Due to the vast amount of different parts available, we cannot cover all controllers available. However we will focus on the most common available implementations and the most innovative enhancements seen today. For a complete listing of all CAN controllers, go to www.can-cia.org and check the product listings.

Required Performance

Before we get started, let's have a closer look at typical worst-case scenarios for CAN communication: The highest baud rate currently supported is 1Mbit. The longest possible message contains 8 data bytes. The shortest possible message (0 data bytes) takes about 50 bit times on the bus. At 1Mbit, 50 bit times correspond to 50 microseconds.

If the goal is that an application handles CAN interrupts in real-time, the microcontroller would need to "digest" an incoming message with 8 data bytes in less than 50 microseconds. Potentially this is the shortest time the next receive interrupt could occur.

Keep in mind that to leave enough MCU operating time for the real application (whatever is handled besides CAN communication), the "digesting" should take far less than 50 microseconds.

Experienced users of 8-bit microcontrollers will immediately see that such a worst-case scenario could be really challenging to some microcontrollers and could keep them busy with nothing else but CAN communication. However, it is seldom the case that a single node needs to receive and work on 100% of the messages on the bus. So in average, a node often only needs to listen to a certain percentage of the messages. While this helps to reduce the overall, average MCU operating time required for handling the CAN communication, work-a-rounds are still needed to handle bursts of back-to-back messages that an node might need to receive.

Fortunately, modern CAN interfaces have hardware filtering and buffering features that help with the task of ignoring unwanted communication and buffering back-to-back messages.

Hardware Filtering with Match and/or Mask

The functionality of hardware filters is very similar on many CAN devices. While receiving a CAN message, the identifier (and sometimes even the data) can be compared to a configured filter. Only if the incoming message matches the filter does the message get stored into a receive buffer. The major differences in filters are usually the width of the filter and if it is a match only filter or also allows a mask to be used.

The filter width specifies how many bits of an incoming CAN message can be processed. For a standard CAN message identifier at least 11-bits are required. For an extended CAN message identifier its 29-bits.

Where a match filter only allows you to do one exact match (for example exactly one identifier), a combination of match and mask allows for filtering on message groups (for example identifiers 0x100 to 0x11F). Usually a bit set in the mask register means that the corresponding bit in the CAN message is a "don't care" value for the acceptance filtering. If a bit is cleared, it MUST match the value in the match register.

Different CAN Implementations

Basic CAN

The original CAN interfaces available were later called "Basic" CAN interface. Basic CAN interfaces only offer a limited number of receive buffers and filters (typically 1 to 3). If a node using such a controller needs to listen to a number of different messages (different CAN message identifiers), the filters usually have to be set "wide open" causing an interrupt with every single message on the bus. Obviously, the microcontroller will get many CAN interrupts, as it has to check in software if a message can be ignored or needs to be worked on.

Full CAN

The next generation of CAN controllers was the so-called "Full-CAN" implementation. Full CAN controllers use a number of message objects (typically 15) with each being bi-directional (can be configured to either transmit or receive), each having its own transmit/receive buffer for one message and each having one filter match register. This allows setting a message object to only listen for exactly one message (one identifier).

As long as the total number of messages a node needs to listen to is smaller than the number of message objects available, these interfaces are very efficient. They will only cause an interrupt to the MCU if a "wanted" message was received.

However, this mechanism does not offer any protection from a back-to-back worst-case scenario. Each message object has a single buffer and a matching incoming message will override the buffers' contents, so potentially messages can get lost. As long as a buffer is configured for a single message identifier, this scenario is not too bad, as it is unlikely that the producer of that message produces them back-to-back. But as soon as any of the message objects is configured to receive multiple CAN identifiers - the microcontroller needs to be prepared that these could come in back-to-back. On a 1Mbit CAN network that means about 50 microseconds from receive interrupt occurrence to a potential overwrite of that message by the next incoming message.

FIFOs

The only way to get around the back-to-back message problem and the high performance and timing demands on the interrupt service routine is with a receive FIFO buffer (First In - First Out). A typical implementation features a number of filters that include both match and mask registers. Upon a filter match, the incoming message is moved into the FIFO buffer. An interrupt request to the MCU is made depending on configuration: either a certain fill-level is reached or a high priority filter received the last incoming message.

Even if such a FIFO can only hold 64 bytes it is still big enough to improve the back-to-back scenario mentioned earlier. If the FIFO is configured to cause an interrupt with every single incoming (matched) message, the MCU has at least 500 bit times until the FIFO will overflow. That is about 10 times more time available to the MCU than with Basic CAN or Full CAN implementations.

On the downside, messages in the FIFO cannot overtake each other. So if the FIFO already contains several messages and now an additional, but high priority message comes in - the MCU first needs to process all messages previously stored in the FIFO before it gets access to the high priority message. In a Full CAN interface it is up to the interrupt service routine in which order the message objects are checked and it would very well be possible that a higher priority message can "overtake" previously received lower priority messages.

Enhanced Full CAN With Receive FIFO

The latest developments do not have standardized names as chip manufacturers came up with their own customized improvements for the CAN interfaces. Several chip manufacturers now offer devices that combine the benefits of Full CAN and a FIFO.

The most powerful approach is a Full CAN implementation with a dedicated FIFO for each single message object. Although powerful, these are also the most complex controllers to configure, especially if each individual FIFO can be freely located in RAM and can be of individual lengths.

Another alternative is to be able to take a Full CAN implementation and be able to concatenate message objects to a FIFO. So instead of one message object only having one buffer, a FIFO can be formed "borrowing" the buffers of other message objects. Although fairly flexible, the disadvantage is obvious: with each buffer added to a FIFO, one message object is lost. So the value of this feature increases with a high number of message objects, but decreases if the number of message objects decreases, too.

Summary and Conclusions

Many CAN controllers offer additional features such as extended error reporting and diagnostic functions or auto-baud detection. For the scope of this article a complete feature comparison is impossible - so we concentrated on the number one feature essential to many CAN applications: receiving messages.

Before choosing a CAN interface for an application do a worst-case analysis. What is the fastest baud rate the node needs to support? How much of the network traffic does need to be worked on? How much additional network traffic is there and can it be completely eliminated by hardware filters? Which percentage of the MCU performance is needed for the CAN communication and which percentage required by the real application running on that MCU?

Some on-line calculators that help with worst-case CAN traffic calculations are available for free on the web pages of the Embedded Systems Academy: www.esacademy.com/faq/calc/.

When it comes to transmitting CAN messages, it should be mentioned that Full CAN style controllers are advantageous compared to CAN controllers that only feature a single transmit buffer. Having multiple, pre-configured transmit buffers simplifies transmitting re-occurring messages or sending messages from different tasks. Usually multiple transmit buffers can also be configured to support CAN's priority scheme - a higher priority message to be transmitted can "overtake" a lower priority message that was not yet transmitted.

In general, CAN controllers supporting a combination of Full CAN and receive FIFOs are the most desirable, although they are not always the easiest to master. In any case, with the help of this article you should now at least be able to recognize if a particular CAN interface jeopardizes your project because it would take too much of the MCU performance away from your real application.

Sections