For many years, my preferred platform for embedded CAN Bus development has been the Arduino Due.
There were good reasons for that choice. The Due is based on the Atmel SAM3X8E ARM Cortex-M3 processor and, more importantly for my applications, provides two integrated CAN controllers. Combined with suitable CAN transceivers, it makes an excellent platform for applications such as CAN gateways, protocol converters, data loggers, SAE J1939 nodes, and network simulation.
I also like the Arduino development environment. I have worked with numerous embedded development systems over the years, but for quickly developing and testing CAN applications, the Arduino IDE remains one of the most comfortable environments I have used.
The Arduino Due dual-CAN development board that I have used for these projects takes advantage of both CAN controllers and provides two complete CAN interfaces. That is still a significant advantage, particularly when developing gateways or applications that need to communicate with two independent Classical CAN networks.
However, CAN Bus technology has moved on.
CAN FD Changed My Hardware Requirements
With CAN FD becoming increasingly relevant, I needed a development platform that could work with both generations of CAN technology.
The Arduino Due remains perfectly suitable for Classical CAN, but it does not provide native CAN FD capability. Adding an external CAN FD controller is certainly possible, but at some point it makes more sense to start with a platform designed around the requirements of newer applications.
That brought me to the ESP32-S3.
The ESP32-S3 board with Classical CAN and CAN FD combines an ESP32-S3-WROOM-1-N8R8 module with two different CAN technologies on one development board: the ESP32-S3’s integrated Classical CAN controller and an external Microchip MCP2518FD CAN FD controller.
For my purposes, that combination is particularly attractive because I can develop applications that need to interact with existing Classical CAN networks while also experimenting with or implementing CAN FD.
And I can continue using the Arduino IDE.
Classical CAN and CAN FD on One ESP32-S3 Board
The ESP32-S3 itself provides the controller used for the Classical CAN interface. Espressif refers to this peripheral as TWAI, or Two-Wire Automotive Interface. From an application perspective, it provides the CAN functionality needed for conventional Classical CAN communication.
CAN FD requires a different solution. On this board, it is provided by a Microchip MCP2518FD external CAN FD controller connected to the ESP32-S3 through SPI. Both interfaces include the required high-speed CAN transceivers, so they can be connected directly to their respective CAN networks.
This creates an interesting development architecture:
ESP32-S3 → Classical CAN
ESP32-S3 → SPI → MCP2518FD → CAN FD
That arrangement also makes the board useful for more than simply experimenting with CAN FD. An ESP32-S3 application can receive messages from a Classical CAN network, process them, and communicate information through the CAN FD interface—or perform the reverse operation.
In other words, the hardware provides the foundation for developing CAN-to-CAN-FD gateways and protocol converters in addition to standalone CAN nodes.
A Significant Step Up in Processing Resources
Moving from the Arduino Due to the ESP32-S3 also represents a substantial increase in available processing and memory resources.
The board uses an ESP32-S3 dual-core 32-bit LX7 processor running at up to 240 MHz and provides 8 MB of flash memory and 8 MB of PSRAM.
For comparison, the Arduino Due’s SAM3X8E runs at 84 MHz with 512 KB of flash and 96 KB of SRAM.
Raw processor speed is not the reason I selected the ESP32-S3—the Due has always provided sufficient performance for many CAN and SAE J1939 applications—but the additional resources become useful as applications grow more sophisticated.
Larger receive buffers, message databases, logging, protocol translation, web interfaces, wireless communications, and other functions are considerably easier to accommodate when memory is not an immediate constraint.
Wi-Fi and Bluetooth Come Along for the Ride
Another advantage of the ESP32 architecture is something that has little to do with CAN itself: wireless communication is already part of the processor.
The board supports 802.11 b/g/n Wi-Fi as well as Bluetooth 5, Bluetooth Low Energy, and Bluetooth mesh.
That opens up some interesting possibilities.
A CAN node no longer has to communicate only through CAN. It can acquire information from a CAN or CAN FD network and make selected data available through Wi-Fi or Bluetooth. It can potentially act as a wireless CAN gateway, telemetry device, diagnostic interface, or bridge between an embedded CAN network and an IP-based system.
This is one of the areas where I see the ESP32 family becoming particularly useful for modern embedded CAN development.
Designed for More Than Bench Experiments
Another feature I appreciate is the board’s power arrangement.
Rather than requiring a regulated 5 V supply for every experiment, the board accepts approximately 7 to 24 VDC through its onboard switching power supply and includes reverse-polarity protection. That makes it much easier to integrate into automotive, mobile, and industrial test environments.
There is also USB-C connectivity using the ESP32-S3’s native USB OTG capability. Unlike many older ESP32 boards, an additional USB-to-UART converter is not required for programming and serial communication.
An I²C expansion port is available for additional sensors and peripherals, and an RGB LED provides a convenient status indicator.
These may seem like secondary features, but they matter when a development board moves from a desk experiment into an actual prototype.
The Arduino IDE Remains Part of the Equation
For me, this is an important point.
Changing from the Arduino Due to the ESP32-S3 does not mean abandoning the development environment I have used successfully for years.
I can continue developing in the Arduino IDE.
What changes is the CAN driver layer.
The Due, ESP32-S3 Classical CAN controller, and MCP2518FD are different pieces of hardware and therefore require different driver software. Applications must account for those differences. Nevertheless, the overall Arduino programming model remains familiar.
That makes the transition considerably easier than moving to an entirely different embedded development ecosystem.
It also supports something I consider important in embedded development: concentrating on the application rather than spending unnecessary time fighting the development tools.
Does This Replace the Arduino Due?
Not necessarily.
I still consider the Arduino Due a very useful CAN development platform. Its two integrated CAN controllers are an important feature, and for projects involving two Classical CAN networks, it remains an excellent choice.
The ESP32-S3 board addresses a different requirement.
My CAN projects increasingly need to accommodate both Classical CAN and CAN FD. For that type of development, having one Classical CAN interface and one CAN FD interface on the same board makes considerably more sense.
The additional processing power, large memory, Wi-Fi, Bluetooth, native USB, and wide-range power input are welcome bonuses.
More importantly, I can make that transition while continuing to work within the Arduino IDE.
For me, the progression is therefore not really Arduino Due versus ESP32-S3.
It is an evolution of the development platform alongside the evolution of CAN itself.
The Arduino Due continues to serve Classical CAN very well. For projects that need to take the next step into CAN FD while maintaining compatibility with existing CAN networks, the ESP32-S3 combined with the MCP2518FD provides a practical path forward.
And that is where I expect a good portion of my future embedded CAN development work to take place.