Selecting a CAN Controller

By Olaf Pfeiffer

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

[  Introduction | Performance | Implementations | Conclusions ]

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.

[  Introduction | Performance | Implementations | Conclusions ]

ESAcademy, 2002

www.esacademy.com
info@esacademy.com