Comparing CAN, CAN-FD, and CAN-XL

Comparing CAN, CAN-FD, and CAN-XL

Intro

CAN, or Controller Area Network, is a popular communication standard in the automotive industry that has come a long way since its inception back in the 1980s. It has since made its way into elevators, 3D printers, medical equipment, and so much more. Devices communicating via CAN are typically connected in a bus topology, and each device should include its own termination resistor to prevent signal reflections. To give you a better understanding of CAN we will be comparing the three main varieties you are likely to encounter. 

Book a Call with Dojo Five Embedded Experts

Structure

While CAN message structure can vary slightly between versions, below you will see an example Standard CAN message to help you follow along in our comparison. In any CAN message you will see an arbitration field first, this is used to avoid collisions on the bus. When multiple CAN devices want to send messages, they will each send a CAN frame with the arbitration bits first, and the device with the highest priority will “win”, with the other devices waiting until the bus is free and trying again. Next, you will find the control field which may include details about CAN type and Data size. Lastly, you will have your data and some kind of error checking and acknowledgement.

CAN Message Structure

Source: https://en.wikipedia.org/wiki/CAN_bus#Frames_&_message_structure

CAN (2.0)

In general when people refer to standard or classical CAN, they are talking about CAN (2.0). CAN (2.0) comes in two types, CAN_A, and CAN_B. CAN_A (Standard) uses 11 bit identifier fields, whereas CAN_B (Extended) uses 29 bit identifiers. It should be noted that Standard CAN devices can generally talk to Extended CAN devices, but Extended CAN devices may not be able to communicate with Standard CAN devices as the longer identifier field will be truncated and likely be mishandled. This variety is capable of up to 1Mbps and may send up to 8 bytes of data per message. 

CAN-FD (Flexible Data-Rate)

CAN-FD, which is built on top of a typical CAN network, enables the use of flexible data rates for transfers between FD devices. It maintains backwards compatibility with Standard CAN by maintaining the same frame format but with the addition of a new control field to indicate CAN 2.0 or CAN-FD for a given message. It greatly improves both speed and payload sizes by allowing for up to 8Mbps under ideal conditions, and 64 bytes of data per message. It’s important to be aware that while CAN-FD can support higher data rates (up to 8Mbps), this is only during data transfers. Arbitration is still done at 1Mbps or less. 

CAN-XL (Extended-Length Can)

CAN-XL greatly improves on both transfer speeds as well as data lengths while still allowing for backwards compatibility. Additionally, CAN-XL introduces Ethernet tunnelling (the ability to encapsulate and transmit ethernet frames) making it simple to go from CAN to TCP/IP and back. Support for transfer speeds of up to 20 Mbps and payload sizes up to 2048 bytes per message are also a welcome improvement to CAN communications. One important note about CAN-XL, like CAN-FD, is that it still uses data rates as low as 125kbps during arbitration. Therefore to get the most out of CAN-XL, it is recommended to send larger packets rather than multiple small packets to get the highest average data throughput. 

Comparison Table

TypeMax Data LengthArbitration RatesBaud RatesRelease Year
CAN (2.0)8 bytes40Kbps-1Mbps40Kbps-1Mbps1991
CAN-FD64 bytes40Kbps-1Mbps40Kbps – 8Mbps2012
CAN-XL2048 bytes125Kbps-1Mbps125Kbps – 20Mbps2024

Which version should I use?

Since support for CAN-XL is limited to some pre-production or small sample run MCUs it may currently be down to just CAN 2.0 or CAN-FD. Now if you really need the extra speed or packet size, it will likely be worth the wait for XL. Otherwise CAN-FD would be a good option today. While CAN 2.0 is one of the most widely used versions, auto makers are slowly moving away and adopting FD more and more. Also, remember FD is backwards compatible, so today,  unless you need the least expensive option CAN-FD would be our pick. 

If you are still undecided and in need of help, we would love to lend a hand!  

Discover why Dojo Five EmbedOps is the embedded enterprise choice for build tool and test management.

Sign up to receive a free account to the EmbedOps platform and start building with confidence..

  • Connect a repo
  • Use Dev Containers with your Continuous Integration (CI) provider
  • Analyze memory usage
  • Integrate and visualize static analysis results
  • Perform Hardware-in-the-Loop (HIL) tests
  • Install the Command Line Interface for a developer-friendly experience

Subscribe to our Monthly Newsletter

Subscribe to our monthly newsletter for development insights delivered straight to your inbox.

Interested in learning more?

Best-in-class embedded firmware content, resources and best practices

Laptop with some code on screen

I want to write my first embedded program. Where do I start?

The boom in the Internet of Things (IoT) commercial devices and hobbyist platforms like the Raspberry Pi and Arduino have created a lot of options, offering inexpensive platforms with easy to use development tools for creating embedded projects. You have a lot of options to choose from. An embedded development platform is typically a microcontroller chip mounted on a circuit board designed to show off its features. There are typically two types out there: there are inexpensive versions, sometimes called

Read More »
Medical device monitoring vitals

IEC-62304 Medical Device Software – Software Life Cycle Processes Primer – Part 1

IEC-62304 Software Lifecycle requires a lot of self-reflection to scrutinize and document your development processes. There is an endless pursuit of perfection when it comes to heavily regulated industries. How can you guarantee something will have zero defects? That’s a pretty hefty task. The regulatory approach for the medical device industry is process control. The concept essentially states that if you document how every step must be completed, and provide checks to show every step has been completed properly, you

Read More »
Operating room filled with medical devices

IEC-62304 Medical Device Software – Software Life Cycle Processes Primer – Part II

Part I provides some background to IEC-62304. Part II provides a slightly more in-depth look at some of the specifics. The IEC 62304 Medical Device Software – Software Lifecycle Processes looks into your development processes for creating and maintaining your software. The standard is available for purchase here. So what activities does the standard look at? Here are some of the major topics. For any given topic, there will be a lot more specifics. This will look at a few

Read More »