The CAN (Controller Area Network) protocol is a serial-based digital communication protocol originally developed by BOSCH. It was initially developed for use in the automotive industry. It makes use of priority-based message arbitration. The voltage is not part of the standard, and operating voltages of 5V or 12V are common.
A alternative communications protocol used in similar applications is the LIN protocol.
Bit Rate And Transmission Distances
The following equation can be used as a rule-of-thumb to calculate the maximum transmission speed for distances larger than 50m.
$$ BR\times L\leq 60 $$
\(BR\) = bit rate (in Mbit/s)
\(L\) = length (in m)
A table of common distances/transmission rates is shown below:
The CAN network uses priority-based message arbitration. The drivers to the CAN line(s) are open-drain. This means that if a node writes a 0 (dominant), it will over-write a 1 (recessive). This is also called a “wired AND” configuration.
The CAN bus uses NRZ encoding.
Any sequential sequence of 5 bits of the same type requires the transmitter to insert a bit of the opposite polarity. Consequentially, the receiver has to remove this bit from the incoming data stream.
Dominant bits are logic level 0, while recessive bits are logic level 1.
Packet Field Acronyms
RTR bit: The Remote Transit Request bit differentiates between data and remote frames. In data frames, this bit is dominant and in remote frames this bit is recessive.
SRR bit: The Substitute Remote Request bit is transmitted in extended frames at the position of the RTR bit in standard frames. It is always recessive.
IDE bit: The Identifier Extension bit distinguishes between standard and extended frames. In standard frames this bit is dominant, in extended frames this bit is recessive.
There are two different message lengths supported by the CAN protocol.
- CAM Base Frame (CAN2.0A)
- CAM Extended Frame (CAN2.0B)
There are 5 different types of errors:
- Bit Error: The transmitter monitors the bus level as it sends bits. If the level is not the same as what it is transmitting, a bit error occurs. Physical layer error.
- Stuff Error: If 6 or more consecutive bits of the same type are found. Physical layer error.
- Format Error: Data-link layer error.
- CRC Error: When the computed CRC does not match the one received in the message packet. Data-link layer error.
- Acknowledge (ACK) Error. Data-link layer error.
CAN Controller IP
Most popular FPGA vendors provide pre-licensed (you don’t have to pay anything to use it!) CAN controller IP cores for use within their FPGAs.
Xilinx provides the CAN 2.0B and CAN-FD Controller IP core which is compatible with the Ultrascale, Zynq-7000, 7-series, 6-series and other Xilinx FPGAs.
ISO 11898 is a widely followed basic CAN standard, defining parts of the physical and data link layers. There are many different versions of this standard:
- ISO 11898-1:2015 – Specifies data-link layer and physical signalling
- ISO 11898-2:2003 – Specifies the high-speed transmission (up to 1Mbit/s) medium access unit (MAU). This has been revised by ISO 11898-2:2016.
- ISO 11898-2:2016 – Specifies the high-speed physical media attachment (HS-PMA) component for the CAN bus.
- ISO 11898-3:2006 – Specifies low-speed, fault tolerant CAN bus information transfer between road vehicles.
Related to ISO 11898 is ISO 16845, which details test suites and test requirements for checking CAN bus/controller conformance to the specs.
CANopen was developed for embedded devices in automation systems . It defines the OSI network layers that the basic CAN standards leaves unspecified, which includes the network layer and above.
A communication protocol for ships which is based on the CAN standard.
PeliCAN is a CAN controller “mode” named by NXP with the arrival of their SJA1000 stand-alone CAN controller ICs, which were a successor to the PCA82C200 CAN controller ICs (BasicCAN). PeliCAN supports all of the frame types defined by CAN 2.0B.
PeliCAN mode extensions include:
- Error counters
- Error interrupt
- Single-shot transmission (no re-transmission)
- Listen only mode
- Hot pluggin support
- Acceptance filter extension
- Self reception support (can receive messages sent by self)
Uses a shielded twisted pair. Used in trucks, agricultural and industrial equipment.
The CAN protocol and CAN FD protocol are protected with IP rights by Bosch. Any CAN IP modules for a FPGA or ASIC (including self-developed ones!!!), or fixed hardware CAN IP peripherals for microcontrollers must be licensed.
USB to CAN Adapters
Many USB to CAN adapters use a serial DB-9 connector for the CAN side.
One example is the PCAN-USB, which support Windows and Linux.
SocketCAN is a set of open-source CAN drivers and a networking stack for the Linux kernel.
SocketCAN creates a new protocol family called
PF_CAN. You can then communicate with the CAN bus with a socket, in the same way you would for the internet protocol (IP).
CAN support was added to the Linux kernel in version 2.6.25.
More information on SocketCAN, including information and code examples on how to send and receive CAN data from the terminal using SocketCAN, see the Using SocketCAN In Linux page.
Atmel T89C51CC01 Microcontroller. 8-bit 8051 architecture, with CAN interface. Supports bootloading from the CAN protocol
The Freescale MC9SO8D range of microcontrollers have built-in support for both CAN and LIN communication protocols. The CAN peripheral block is called an MSCAN.