Site Information

 Loading... Please wait...

The Quest for Programmable Embedded Systems with Multiple CAN/CAN-FD Ports

Posted by Wilfried Voss on

CAN Bus Development

I regularly receive inquiries about programmable systems that support more than two CAN interfaces—either Classical CAN, CAN FD, or a combination of both. Most requests center around four ports, though some applications require even more. To be transparent from the outset: available solutions in this space are limited.

While platforms like Arduino and Raspberry Pi offer the ability to stack shields or HATs—making it theoretically possible to add multiple CAN ports—these setups come with significant constraints. Most boards only support one or two hardware chip-select lines for SPI communication, and these are often hard-wired, making it difficult to address multiple devices individually. Furthermore, while stacking expansion boards offers design flexibility, the resulting mechanical height can be problematic in space-constrained applications.

There are two primary reasons why systems with more than two CAN ports are hard to find:

  1. Economic feasibility – The demand for multi-port CAN systems is relatively low, making it difficult to justify the development and production of such niche hardware.

  2. Technical complexity – Handling multiple CAN or CAN FD channels at high baud rates and busloads requires considerable processing power and highly optimized software to ensure no data is lost. Developing such software is no small task.

That said, there are definitely real-world applications where additional CAN ports are not just helpful, but necessary. The few available solutions often involve compromises, and while they may work, they rarely offer the kind of engineering elegance or reliability professionals expect.

In the sections that follow, I’ll introduce some of the multi-CAN products currently available on our website. I’ll also outline a conceptual design for a more advanced embedded system offering up to seven CAN ports. This setup includes one Classical CAN interface and six additional ports that can be configured in different combinations: three Classical CAN and three CAN FD, six Classical CAN, or six CAN FD. From a cost-efficiency perspective, the most flexible configuration would be one Classical CAN and six CAN FD ports, as CAN FD controllers can typically be configured to operate in Classical CAN mode.

For those interested in existing solutions, we do carry a selection of two-port CAN shields and HATs for both Arduino and Raspberry Pi platforms, which you can explore here on our website.

Arduino Due Board with Dual CAN Bus Interface

Arduino-Based ECU Development Board With Dual CAN Bus InterfaceIn its basic configuration, the Arduino Due features two on-chip CAN controllers, making it a practical platform for developing CAN Bus and SAE J1939 applications. When combined with a dual CAN transceiver interface, the Due can be used to prototype or deploy embedded solutions that require two independent CAN channels.

By integrating the Arduino Due with a suitable dual CAN interface board, an OBD-II or SAE J1939 cable, and available open-source software libraries, users can implement a functional, Arduino-based dual CAN Bus system with minimal setup.

The platform is compatible with the extensive Arduino ecosystem, including software sketches and hardware expansion shields, enabling flexible development for CAN Bus, OBD-II, or SAE J1939 projects. Additionally, the board supports a wide input voltage range from 7 to 32 VDC, allowing it to operate in both automotive and industrial environments. More information...

As shown in the image, it is possible to expand the setup by adding a standard CAN shield, resulting in a total of three independent CAN ports. However, it's important to note that this configuration supports only Classical CAN. As of this writing, CAN FD-compatible shields for Arduino are not commercially available.

Teensy Boards with Triple CAN/CAN FD Ports

Teensy 4.1 Triple CAN Bus Board with 240x240 LCD and EthernetTo clarify upfront: while the Teensy series supports up to three CAN ports, it does not offer triple CAN FD capability. Instead, it provides a mix of Classical CAN and CAN FD interfaces.

For more detailed information, refer to the Teensy Triple-CAN modules. A representative example is the Teensy 4.1 Triple CAN Bus Board with 240x240 LCD and Ethernet, which combines a broad set of hardware features. This module includes two Classical CAN ports and one CAN FD port, along with an Ethernet interface, SD card slot, and a 240x240 pixel LCD display.

The board is compatible with the Arduino IDE and is supported by a variety of programming examples to help accelerate development.

ESP32 System with up to Seven CAN Ports

ESP32 CAN STarter KitI am currently working on an ESP32-based application titled Mastering Classical CAN and CAN FD Gateways. This project focuses on CAN Bus development using the ESP32 processor and includes a comprehensive collection of technical insights relevant to building robust gateway solutions.

During the writing process, I discovered that the ESP32 is capable of supporting up to six external CAN controllers in addition to its internal SJA1000-compatible controller. These external controllers can be either the MCP2515 for Classical CAN or the MCP2518FD for CAN FD. Each controller communicates via SPI, and the ESP32 provides two SPI interfaces, and it can manage up to three devices per SPI port.

In a previous customer project, we implemented a system that utilized two MCP2515 controllers and an SD card interface, distributed across the ESP32’s SPI ports. The software developed for that project is still available and only requires minor modifications to suit this new application. For prototyping, I have gathered several CAN FD breakout boards, an ESP32 DevKitC module, breadboards, and wiring materials.

The ESP32 DevKitC will serve as the platform for the initial proof of concept. However, I am considering transitioning to the ESP32-S3 variant later in the project, as it supports native USB and allows for higher data throughput when interfacing with a PC.

I will provide updates on this development in a future post. If you're interested in the project or have any questions, feel free to reach out.