One of the motivations behind developing the CANFDuino is the new standard for CAN bus being adopted by the automotive industry: CANFD (flexible data rate). This new standard is already being used in production vehicles and will undoubtedly find its way into other use cases throughout multiple industries, much like its predecessors. So for week one’s update, I thought this would be an appropriate topic to tackle.
CAN bus, or Controller Area Network, was developed as a robust means for embedded systems (microcontrollers) to talk to one another. CAN bus is largely synonymous with automotive systems as being one of the primary communication backbones used to broadcast information from electronic control units (ECU’s), sensors, and instrumentation systems in a vehicle. CAN has also seen wide adoption in the automation industry and the transportation industry with multiple open and private communication protocols having been developed using CAN bus as the hardware layer (Examples: CANOpen, OBD2, GMLAN, ARINC-825, etc).
CAN Flexible Data Rate (CANFD) is an evolution of very popular CAN 2.0b standard, first introduced in 2011-2012 with widespread adoption in production vehicles starting in 2019. CANFD allows for a relatively similar and even backward compatible design of the communication network, still implementing a two-wire, multi-drop network and 120 ohm terminations. However, two major improvements were introduced:
The "Flexible Data Rate" in CANFD refers to the ability of a transmitting node to dynamically change the data rate, enabling the two improvements above. This implementation also allows for a bus to consist of nodes that use classical CAN (2.0b) and CANFD.
|Baud Rate||Up to 1Mbps||Up to 5Mbps|
|Message Size||Up to 8 bytes||Up to 64 bytes|
|ID size||11 or 29bit||11 or 29bit|
|Number of Wires||3 CANH,CANL,GND||3 CANH,CANL,GND|
CANFD was actually designed to be somewhat backwards compatible with CAN, meaning CAN and CANFD packets are designed to co-exist on the same bus. This is enabled by on-the-fly bit-rate switching (BRS flag) in the format of the CANFD frame, which indicates the baud rate of the latter part of the packet is going to be boosted to accommodate a larger payload message. More specifically, CANFD nodes are able to normally transmit plain old lower-speed smaller CAN packets or larger high-speed CANFD packets. However, the receiving nodes need to be compatible with CANFD messages. The primary driver for having dual-baud rates and not transmitting at high-speed all of the time is bus congestion limited by bandwidth and number of nodes on the system. There are also cases where classical CAN nodes are able to co-exist on a CANFD bus, however they may need to be switched off or reset after high-speed CANFD messages are sent between nodes.
Given the simple changes in the new standard, and the abstraction of low-level coding in open-source software, writing code for the CANFD in the Arduino IDE is pretty simple. There are really only two differences:
* Note that the CAN controller is either native to the microcontroller or an external peripheral such as an SPI chip
Below are a few simple example code snippets:
cCAN_CANFD CanPort0(0, _500K, _500K, MCAN_MODE_CAN);cCAN_CANFD CanPort1(1, _500K, _500K, MCAN_MODE_CAN);
cCAN_CANFD CanPort0(0, _1M, _5M, MCAN_MODE_EXT_LEN_DUAL_RATE);cCAN_CANFD CanPort1(1, _1M, _5M, MCAN_MODE_EXT_LEN_DUAL_RATE);
//set TX frame to 0x100 tx1.id = 0x100; tx1.len = 64; tx1.data = 0xFE; tx1.data = 0x88;
To get going with CAN or CANFD you will need an open-source microcontroller platform such as the CANFDuino, the Arduino IDE for writing code, and a few examples to get you oriented.