Selecting a CAN Controller, 2023 Update

By Olaf Pfeiffer

Update The original article was written in 2003, when CAN (Controller Area Network) interfaces were also still available in 8-bit microcontrollers and an efficient CAN core implementation was essential to the overall performance. It is time to give this an update as with the evolution of technology and the proliferation of microcontrollers, there's an ever-expanding range of options when it comes to selecting a CAN controller. With so many choices available, how do we make an informed decision?

Introduction

CAN has been a reliable communication protocol since the late 1980s. The adoption and use of CAN devices have surged, reflecting its reliability and robustness in various applications. With the introduction of CAN FD (supporting higher data bitrates and larger frames), the overall CAN lifetime has been further extended, as systems can grow, even if they now must communicate more data or add security protocols.

Though many semiconductor manufacturers offer microcontrollers with CAN or CAN FD interfaces, the performance and efficiency of the implementations vary significantly across devices. It's essential to understand these differences and their implications on the performance of the processes handling the CAN communication.

This article aims to highlight these distinctions and assist in making an informed choice.

Informed choices

Classical CAN or CAN FD?

Unfortunately, CAN FD is not fully backward compatible with classical CAN implementations. While a CAN FD controller can handle both classical and CAN FD communication, a pure classical CAN controller will produce error frames (as it does not recognize the FD frame) and disrupt communication when it encounters CAN FD frames. Therefore, you can only activate CAN FD communication when ALL active devices connected support it. Keep this in mind when making your choices.

CAN and Higher-Layer Protocol Processing – What Happens Where?

What all CAN controllers have in common is the build-in process of transmitting and receiving CAN frames, including error checking and re-transmission on error detection. In addition, all CAN controllers provide some filtering and buffering. Hardware filters in many CAN devices allow incoming CAN messages to be compared to a pre-configured filter, ensuring only relevant messages get stored in a receive buffer. The filter's width and its compatibility with match or mask functionalities are primary differentiators. However, the number of filters and buffers or how much memory is usable for buffering both incoming and outgoing frames can greatly differ between devices.

Typical CAN controller selection options are:

External, off-chip CAN or CAN FD controller Here, CAN or CAN FD is implemented in a separate chip and the communication to a host system occurs through another interface, such as a serial channel (SPI). In such a scenario, advanced filter and buffering functionalities are essential as otherwise, the connected host needs to deal with ALL CAN frames, which could be more than 10,000 per second!
Microcontroller with one or more on-chip CAN or CAN FD controllers This is the most common use case. Almost every chip manufacturer producing microcontrollers offers derivatives that have one or multiple CAN or CAN FD controllers. For new designs, we recommend selecting devices that provide CAN FD functionality. Even if not needed today, your hardware will be capable of using it in the future if necessary. For devices with a limited number of inputs and outputs like a temperature sensor, input or output switch, the number of buffers or size of buffer memory is not so important. However, if your device needs to communicate with many or all connected devices, then a higher number of buffers and large buffer sizes are favorable, and preferably buffers can be concatenated to a receive or transmit FIFO. Note that this opens up the potential for the “priority inversion” scenario. However, whether that is of importance for your application depends on many factors. For more details, see our article Balancing Speed and Priority: Crafting Embedded Networks for Diverse Real-Time Communication Demands.
External, off-chip Higher-Layer CAN controller A System on Module (SoM) like the CANopenIA coprocessor does not only provide a CAN or CAN FD interface: it also provides its own processor for handling higher communication layers such as CANopen, CANopen FD, or J1939. Towards the host system, it also provides a serial channel, like a regular UART.

The benefit of such a system is that the host processor connected does not need to deal with individual CAN frames, their reception, or even their transmittal. The main data exchanged between the host processor and the CAN coprocessor is application data – there is no overhead for handling segmented data or network management protocols.

Controller choices

What is Right for Me?

Go through this list to get closer to a decision as to which specific CAN controller to use:

Do I need CAN FD or do I want my hardware to be future-proof? If yes, select a CAN controller that is CAN FD capable.
Review the amount of data that you expect your node to transmit and receive. If your node is a simple sensor or actuator with a limited amount of digital and analog data communicated, consider a stand-alone solution (device or SoM implementing what you need, such as CANopenIA). Otherwise, your choices are “almost unlimited”, even a CAN controller with a limited number of filters and buffers will be usable.
Review the number of other CAN devices that your node needs to communicate with. If this is 8 or more, the number of filters/buffers of the CAN controller should preferably be 16, better 32 or even more.
Which Higher Layer Protocol will you be running? Most standardized higher-layer protocols like CANopen or J1939 require adequate resources in both processing time as well as code and additional buffer memory. Again, the size of the memory and buffers increases with the number of other nodes your node needs to communicate with. While for any 32-bit processor running at 40 or more MHz, the processing time should not be a relevant factor, the embedded code size requirements can be anywhere from 10 to 24kb and RAM requirements from 1k to 8k. While these numbers by themselves look small, for optimized embedded systems, you might need to carefully select an MCU derivative with enough resources for this – and everything else that needs to run on this MCU.
How can I reduce complexity while increasing security? Applications that combine many modern technologies and use a number of different communication channels tend to reach a complexity level where development, debug, and test times explode. Coprocessor solutions providing not only a CAN interface but also implementing a higher-layer protocol like CANopen or CANopen FD help to not only reduce the overall complexity by offloading the task of handling CANopen to an extra CANopen dedicated processor. Even without applying any specific security measures, such a solution already increases the overall security of the system. If your node gets compromised, it can still only produce the defined CANopen communication and could not be used for attacking other systems on the CANopen network. Vice versa, your node is automatically protected from the most common CAN hacks as your node does not directly participate in the CAN communication.

Summary and Conclusions

Apart from the features highlighted, many CAN controllers provide advanced functionalities like extended error reporting or auto-baud detection. However, when considering a CAN interface, the most vital aspect remains its ability to receive messages efficiently and possibly limiting the resources needed for processing them, thereby enhancing overall system performance.