Bus – CAN 2.0B/CAN

Comparison of Core Technologies: CAN 2.0B and CAN FD

1. Overview: Definitions and Relationships

1. CAN 2.0B:

• This is the complete version of the Classic CAN protocol, released in 1991. It is fully compatible with earlier CAN 1.2 and CAN 2.0A specifications.

• Its most important feature is the simultaneous support for standard frames with 11-bit identifiers and extended frames with 29-bit identifiers.

• What we commonly refer to as “Classic CAN” or “Traditional CAN” usually refers to the CAN 2.0B protocol. Its maximum data length is 8 bytes, and the rate is typically ≤1Mbps.

CAN FD:

• FD stands for “Flexible Data Rate”, introduced by Bosch in 2011.

• It is an evolution of CAN 2.0B rather than a revolutionary replacement. It retains the core advantages of CAN 2.0B while primarily addressing the insufficient data throughput bottleneck.

• CAN FD is compatible with CAN 2.0B, and a CAN FD node can be configured to communicate in the classic CAN 2.0B mode.

Core Relationship: CAN FD is an enhanced protocol built on the foundation of CAN 2.0B. You can understand it as: all CAN FD frames are “special” extended frames of CAN 2.0B, sharing the same basic physical layer and arbitration mechanism, but CAN FD has made significant upgrades in the data segment.

2. Core Differences Comparison

The table below clearly lists the key differences between the two:

Feature/Aspect	CAN 2.0B	CAN FD
Frame Type	Standard Frame (11-bit ID), Extended Frame (29-bit ID)	FD Frame based on Extended Frame Format
Data Field Length	Fixed maximum of 8 bytes	Flexible, up to 64 bytes (0-8, 12, 16, 20, 24, 32, 48, 64)
Transmission Rate	Single Rate: The arbitration segment and data segment use the same baud rate (up to 1Mbps)	Dual Rate: – Arbitration Segment: Standard Rate (same as CAN 2.0B, ≤1Mbps)– Data Segment: Accelerated Rate (up to 5Mbps or even 10Mbps)
CRC Check	15-bit CRC	More robust CRC:– 17-bit CRC (data length ≤16 bytes)– 21-bit CRC (data length >16 bytes)
Control Field Structure	Includes: IDE, r0, DLC (4 bits)	New:– FDF: Indicates this is an FD frame– BRS: Bit Rate Switch– ESI: Error State Indicator
Protocol Efficiency	Lower. Transmitting large amounts of data requires segmentation, leading to high fixed overhead.	High. Single frame transmission of more data, lower proportion of fixed overhead, high bus utilization.
Design Goals	Transmission of control commands with high reliability and real-time performance.	High reliability, real-time performance, and larger data volume transmission.

3. In-Depth Analysis of Frame Structure

Understanding the frame structure is key to understanding the differences. The following diagram compares a CAN FD frame with bit rate switching enabled to an extended frame of CAN 2.0B:

Structure of CAN 2.0B Extended Frame:

text

[SOF][ Arbitration Field (11+18 bits) ][ Control Field ][ Data Field (0-8B) ][ CRC Field ][ ACK ][ EOF ] |<- - - - - - - - - - - Transmitted at Standard Baud Rate - - - - - - - - - - ->|

• Control Field: Contains <span>IDE=1</span> (indicating extended frame), <span>r0</span> (reserved bit), <span>DLC</span> (4 bits, 0-8).

Structure of CAN FD Frame:

text

[SOF][ Arbitration Field (11+18 bits) ][ Control Field ][ Data Field (0-64B) ][ CRC Field ][ ACK ][ EOF ] |<- - - - - - Transmitted at Standard Baud Rate - - - - ->|< - - - Transmitted at Data Baud Rate - - - ->|

Core Changes in CAN FD Control Field: Based on the inherited control field of CAN 2.0B extended frame, CAN FD redefines three key bits using the originally reserved bits:

1. FDF: FD Format Bit. Set to ‘1’ (recessive), indicating this is a CAN FD frame. Classic CAN nodes will report an error upon seeing this bit.

2. BRS: Bit Rate Switch Bit.

• If set to ‘1’ (recessive), it switches to a higher “data baud rate” starting from the data field.

• If set to ‘0’ (dominant), it uses the standard baud rate throughout (but can still enjoy a maximum data length of 64 bytes).

ESI: Error State Indicator Bit. Indicates the current error state of the sending node (active error/passive error).

4. Why is CAN FD Needed? – Addressing the Bottlenecks of CAN 2.0B

1. “8-byte” Limitation: In automotive and industrial applications, the data that needs to be transmitted is becoming increasingly complex (such as diagnostic information, configuration parameters, sensor data packets). Exceeding 8 bytes requires segmentation into multiple CAN 2.0B frames, significantly increasing:

• Bus Load Rate: Each frame has fixed header and footer overhead, and segmentation leads to exponentially increased overhead.

• Software Complexity: The sender needs to segment, while the receiver needs to reassemble, sort, and manage timeouts.

• Transmission Delay: Critical data may need to wait for previous frames to finish sending.

“1Mbps” Speed Limitation: At the traditional 1Mbps rate, an 8-byte data frame takes about 111μs to transmit. For applications requiring large data transmissions (such as ECU software flashing), this speed is too slow.

Solutions Offered by CAN FD:

• Transmission of 64 bytes of data: CAN FD only requires 1 frame.

• Transmission of 64 bytes of data: CAN 2.0B requires 8 frames. Even at the same baud rate, CAN FD is more efficient due to reduced fixed overhead. If a higher data segment baud rate is enabled, its throughput can increase by several times or even tenfold.

5. Compatibility and Applications

• Compatibility: A CAN FD network can include nodes that only support CAN 2.0B, but this will prevent the network from utilizing FD features. When an FD node sends a frame with the FDF bit, classic nodes will not recognize it and will generate an error frame, leading to communication failure. Therefore, a stable running FD network requires all nodes to support CAN FD.

Application Scenarios:

• CAN 2.0B: Body control (doors, windows, lights), simple sensor data, status messages, etc., where data volume is small but reliability is high. It still dominates in many applications today.

• CAN FD:

• Automotive: ADAS (Advanced Driver Assistance Systems), in-vehicle gateways, high-speed diagnostics, OTA (Over-the-Air) flashing, battery management systems (BMS) for new energy vehicles transmitting large amounts of cell data.

• Industrial: High-performance servo drives requiring the transmission of complex parameters, high-speed data exchange between PLCs.

• Any scenario requiring higher data throughput than Classic CAN.

Conclusion

CAN 2.0B is an extremely mature and reliable industrial standard that lays a solid foundation for distributed real-time control. Meanwhile, CAN FD is a precise and effective upgrade aimed at the higher data volume demands of modern applications, while inheriting its core essence (such as multi-master arbitration and robust error detection).

The choice principle is very simple:

• If your application primarily involves transmitting simple control commands and status information, and the single data does not exceed 8 bytes, CAN 2.0B is a completely sufficient and economical choice.

• If your application faces challenges of increasing data volume, high bus load, or requires faster transmission speeds (such as firmware upgrades), then CAN FD is the obvious upgrade direction, and it has become the mainstream choice for the next generation of embedded networks.