Computer Solutions Ltd
Whats New | Advanced Search
Downloads | Exchange Rates

Celebrating 36 years
supplying all your Embedded Development Tool needs

                      CAN and CAN-FD    a brief tutorial

  Our CAN Tutorial

The CAN bus (Controller Area Networking) was defined in the late 1980 by Bosch, initially for use in automotive applications (CAN 2.0).  It has been found to be very useful in a wide variety of distributed industrial systems.  A 2014 enhancement to the spec (CAN FD) improves throughput.  CAN has the following characteristics:

  • Uses a single terminated twisted pair cable
  • Is multi master
  • Maximum Signal frequency used is 1 Mbit/sec (CAN 2.0) , 15 Mbits/sec (CAN FD)
  • Length depends on the bit rate typical values encountered in the field for CAN 2.0 are
1 Mbit/s      40 m
500 kbit/s  110 m
250 kbit/s  240 m
125 kbit/s  500 m
50 kbit/s    1.3 km
20 kbit/s    3.3 km
10 kbit/s    6.6 km
5 kbit/s     130 km

(See below for CAN FD performance)

  • Has high reliability with extensive error checking
  • Typical maximum data rate achievable is 320 KBites/sec for CAN 2.0 and  3.7 MBits/sec for CAN FD
  • Maximum latency of high priority message <120 µsec at 1Mbit/sec

CAN is unusual in that the entities on the network, called nodes, are not given specific addresses.  Instead, it is the messages themselves that have an identifier which also determines the messages' priority. Nodes then depending on their function transmit specific messages and look for specific message. For this reason there is no theoretical limit to the number of nodes although in practice it is ~64.  Note that no two nodes can transmit the same message ID as this violates the priority rules.

Three specifications are in use:

  • 2.0A sometimes known as Basic or Standard CAN with 11 bit message identifiers which was originally specified to  operated at a maximum frequency of 250Kbit/sec and is  ISO11519.
  • 2.0B known as Full CAN or extended frame CAN with 29 bit message identifier which can be used at up to 1Mbit/sec and is  ISO 11898.
  • CAN FD  increases the max data throughput to ~ 3.7 Mbits/sec. It does this by retaining much of the 2.0 packet structure (which it is compatible with) but using one reserved bit to indicate that the data part of the packet is using the new standard. Once an FD enabled device or interface detects this it can do two things..... Transmits/receives the data part at a secondary frequency of up to 12 Mbits/sec (v 1Mbits/sec for CAN 2.0) and also it allows the data part of the package to consist of up to 64 bytes (v 8 bytes for CAN 2.0). For more details see CAN FD
    Performance depends on the quality of the cable but at the latest plug fest most FD units operated successfully at 10 Mbits/sec over 10 Meters. Typically detected (and so recoverable) error frames go up from 1 in a million at 5 Mhz  over 10 Meters to 1 in a thousand above 10 Mhz
    NOTE a weakness in the error checking of the original specification of CAN FD was found. This is corrected by the 2015 version of the spec. Controllers conforming to this new specification are described as ISO-CAN FD.  The correction is referred to as "bit stuffing enhancements".  All Peaks FD products can be switched between ISO-CAN FD and NON-ISO-CAN FD allowing them to be used with earlier prototype systems.

Nuts and Bolts

From the systems and design viewpoint the detailed management of sending and receiving CAN messages will normally be done by dedicated hardware, on or off chip, (e.g. SJA1000) but an overview of these functions will be useful in order to design, setup and manage a CAN system.

Signal Characteristics

CAN may be implemented over a number of physical media so long as the drivers are open-collector and each node can hear itself and others while transmitting (this is necessary for its message priority and error handling mechanisms).  The most common media is a twisted pair 5v differential signal which will allow operations in high noise environments and with the right drivers will work even if one of the wires is open circuit. A number of transceiver chips are available the most popular probably being the Philips 82C251 as well as the TJA1040.

When running Full CAN (ISO 11898-2) and CAN FD at its higher speeds it is necessary to terminate the bus at both ends with 120 Ohms.  The resistors are not only there to prevent reflections but also to unload the open collector transceiver drivers. We recommend that you terminate the bus correctly in all circumstances.


Message formats

....... In the following description CAN 2.0 refers to BASIC and FULL CAN  and   CAN FD  refers to the 2015 ISO-FD extension of the CAN spec

The CAN protocol uses a modified version of the Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) technique used on Ethernet.  Should two messages determine that they are both trying to send at the same time then instead of both backing off and re-trying later as is done with Ethernet, in the CAN scheme, the transmitters detect which message has the highest priority and only the lower priority message gets delayed.  This means that a high priority message is sure of getting through. -- this is a simplified description as the controller takes care of the detail which is only of interest to those designing controllers (who should consult the spec).

The basic structure of the message is the same for both CAN 2.0 and CAN FD.........



CAN 2.0 Data Frames

These are the normal message frames used to carry data in the  CAN 2.0 spec.

For CAN 2.0 all bits are sent at the speed setting for the bus - max 1MBits/sec. They contain the following fields......

Start of frame   (SOF)

Message Identifier  (MID)     the Lower the value the Higher the priority of the message
                 its length is either 11 or 29 bits long depending on the standard being used (Basic or Fast).

Remote Transmission Request (RTR) = 0  ----- see "Remote Frames" para below for non zero value

Control field  (CONTROL)  This specifies

                EDL that this is a CAN 2.0 or FD transaction (see below for FD Data Frames details)

                 DLC this specifies the number of bytes of data to follow (0-8 for 2.0)

Data Field (DATA) length 0 to 8 bytes for CAN 2.0

CRC field  containing a fifteen bit cyclic redundancy check code

Acknowledge field  (ACK)   an empty slot which will be filled by every node that receives the frame
                 it does NOT say that the node you intended the data for got it, just that at least one node on the
                 whole network got it.

End of Frame   (EOF)

The way in which message collision is avoided is that each node as it transmits its MID looks on the bus to see what everyone else is seeing.  If it is in conflict with a higher priority message identifier (one with a lower number) then the higher priority messages bit will hold the signal down (a zero bit is said to be dominant) and the lower priority node will stop transmitting. 

If you are writing diagnostic code and wish to not "exist" on the network as a node, just to spy on what is happening, then you will need to ensure that the interface you use can be set to a mode where it does not automatically set the ACK bit.  The Peak interfaces and their Explorer diagnostic package can be set into such a mode.


CAN 2.0 Remote Frames

These are frames that are used to request that a particular message be put on the network - of course a node somewhere on the network has to be set up to recognise the request, get the data and put out a Message frame. This mechanism was designed for used in polled networks.  The fields are ....

Start of frame   (SOF)

Message Identifier  (MID)  either 11 or 29 bits long depending on the chosen mode.

Remote Transmission Request (RTR)  = 1

Control field  (CONTROL)  this specifies the number of bytes of data expected to be returned (0-8).

CRC field  containing a fifteen bit cyclic redundancy check code.

Acknowledge field  (ACK)   an empty slot which will be filled by every node that receives the frame
                  it does NOT say that the node you intended the data for got it, just that at least one node on the whole network got it.

End of Frame   (EOF)


CAN FD Data Frames

These are the message frames used to carry data in the FD mode.  They contain the following fields


Start of frame   (SOF)

Message Identifier  (MID)     the Lower the value the Higher the priority of the message
                                             its length is either 11 or 29 bits long.

Control field  (CONTROL)  This specifies

                EDL  that this is a FD transaction (see below for FD Data Frames details)

                BRS bit rate switch 0=no change in bit rate for the data phase.

                                                 1= change to the nominated higher bit rate --- the data  phase
                                                                      starts immediately at the sampling point of BRS
                                                                      and continues to the end of the CRC

                DLC this specifies the number of bytes of data to follow (either 0-8, 12, 16, 20, 24, 32, 48 or 64 )

                Parts of the control field following BRS  ( DLC  the length, the data and the CRC)  can be sent at a higher bit rate
                than the message identifier, with the data being sent at a maximum of 12 Mbits/sec.

    Data Field (DATA)    length as defined by DLC

    CRC field  containing a seventeen bit  (for DLC 0-16) or twenty one bit (for DLC 20-64) cyclic redundancy check code

Acknowledge field  (ACK)   an empty slot which will be filled by every node that receives the frame
                 it does NOT say that the node you intended the data for got it, just that at least one node on the
                 whole network got it.

End of Frame   (EOF)


Error checking

CAN is a very reliable system with multiple error checks ( below is the CAN 2.0 the CAN FD is more complex

Stuffing error  -  a transmitting node inserts a high after five consecutive low bits (and a low after five consecutive high). A receiving node that detects violation will flag a bit stuffing error.

Bit error  -  A transmitting node always reads back the message as it is sending. If it detects a different bit value on the bus than the one it sent, and the bit is not part of the arbitration field or in the acknowledgement field, an error is detected.

Checksum error - each receiving node checks CAN messages for checksum errors (different rules apply for CAN 2.0 and CAN FD).

Frame error - There are certain predefined bit values that must be transmitted at certain points within any CAN Message Frame. If a receiver detects an invalid bit in one of these positions a Form Error (sometimes also known as a Format Error) will be flagged.

Acknowledgement Error - If a transmitter determines that a message has not been ACKnowledged then an ACK Error is flagged.



By defining only the physical and data link levels of the OSI communications model the CAN specification has become the basis for a wide number of industry and manufacture specific variants (and the source of much confusion as all the users will tell you they are using CAN).  If you are trying to clarify a CAN systems status the first thing to find out is the transceivers in use - the most common "normal 5v" CAN uses the Philips 82C251 or the TJA1040.

TJA 1054 is  a low power, low speed  physical layer that is mostly used in automotive applications. It employs the PCA82C252, TJA1053 or TJA1054 transceivers.

AU5790 also known as "Single Wire CAN" is  a low power, low speed  physical layer that is used in automotive applications and an increasing number of industrial applications. It employs the AU5790 transceiver. 

DeviceNet - Developed for use in industrial process control it is based on the standard Full CAN - ISO 11898-2 5v bus. However DeviceNet rigorously defines the physical interconnect, has a more restrictive transceiver specification, 11 bit identifiers only, allows 125, 250 and 500KBaud operation only and regulates the message content in order to more easily support interoperability of different manufacturers units. 

CANopen - Also designed with control applications in mind, it is a software standard based on the standard Full CAN - ISO 11898-2 5v bus 2.0B. It limits the number of nodes to 127 and allocates them IDs. Profiles (standardise the meaning and layout of data in messages for particular industry specific instruments such as A/D converters and motor drive controllers) are specified for each type of device by CiA to simplify using similar units from different manufacturers.  Some standard network commands are defined that allow modules to be automatically identified and allocated a node ID.  The spec also defines a way to handle synchronised data reads and writes as well as providing a standard way in which large blocks of data can be read and written.  We can supply CANopen diagnostic and network management software, Embedded drivers and I/O modules. 

TTCAN - Time Triggered CAN  - The Time-Triggered Protocol has nodes reporting in predefined time windows that have to be planned and synchronised but which then ensure that an overload on the bus is not possible even in a worst case situation.

J1939 - A whole family of industry specific standards (agriculture, marine, truck & bus etc)  are built on the basic communication services of the J1939 protocol specification ( itself based on Full CAN - ISO 11898-2) with industry-specific documents defining the particular combination of layers for that industry. PEAK provide a full database of J1939 mnemonics with their J1939 option for PCAN-Explorer

B10011S is the Transceiver used in a very restricted version of CAN (ISO 11992-1) that has only two nodes normally a truck and its trailer - not to be confused with.......

FMS is a message protocol subset of J1939 defined for the Bus and Truck/Trailer market. For a software packages that knows the meaning of all the FMS messages and can test/emulate and display them in a meaningful way see our FMS Toolkit.

MilCAN  -  is defined for use in military land vehicles where a deterministic protocol is require. It sets up some rules for use and a software layer on top of a conventional CAN network. A Pseudo Hardware Sync is created by one node "the SyncMaster" that sends Sync CAN Frames with a "sync slot number".
MilCAN A uses 29 bit Identifiers. It allows both periodic and event driven data to be transmitted via the bus.
MilCAN B uses 11 bit identifiers. It allows only periodic data to be transmitted via the bus

Additional software Protocols  -  All supported by PEAK with APIs are....
The PCAN-CCP API is a programming interface for the communication between Windows applications (Masters) and electronic control units (Slave ECUs). The API is based on the CAN Calibration Protocol (CCP) by ASAM and is mainly deployed for development in the automotive area.

The Extended Calibration Protocol (XCP) is a further development of CCP, but not compatible with it. XCP supports multiple transmission mediums. The corresponding programming interface by PEAK-System is called PCAN-XCP API which uses the CAN bus as transmission medium analogous to the PCAN-CCP API.

In addition to complete the alphabet soup there are    PCAN-ISO-TP API (ISO 15765-2),   PCAN-UDS API (ISO 14229-1)   and the PCAN-OBD-2 API  (ISO 15765-4),


 Standard  Common Name Baud Rate  Max nodes Max Length Adapter for
PCAN interfaces
ISO 11783 ISOBUS 250 KBit/s  30 40m None required
ISO 11898-2  High speed-CAN max. 1 MBit/s 110  6500 m None required
ISO 11898-2  2015 CAN FD max.12 MBit/s 110  10 m None required for FD interfaces
ISO 11898-3  Fault Tolerant CAN max. 125 KBit/s  32  500 m PCAN TJA1054
ISO 11992 Truck/Trailer CAN max. 125 KBit/s

2  (Point to Point)

40 m PCAN-BD10011S
ISO 15765 Diagnostics On CAN max 1 MBit/s 110   PCAN-OBD connector

SAE J1939

J1939 250 KBit/s 30 ECUs 40m J1939 option to PCAN-Explorer
SAE J2284   max. 1 MBit/s  110   None required

SAE J2411

Single Wire CAN 33,3 KBit/s

83,3KBit/s in HSMode

32   PCAN-AU5790



Local Interconnect Network (LIN) is simpler than CAN and is often used in automotive "body functions"  - eg windows, where performance is not critical but cost is. CAN is then often used to integrate the operation of multiple LIN sub networks.  LIN is a single master,  multiple slave system that uses a 12V single wire physical layer and a UART/SDI  with master driven self synchronisation.  It is capable of running at data rates of up to 20Kbits per second over a maximum distance of 40 Meters. We can supply a USB to LIN interface and a LIN to CAN gateway which simplify developing LIN and mixed CAN/LIN systems.

Interface between CAN and PCs

We can supply a number of different interfaces to allow a PC to talk to CAN.  The most popular is the PCAN-USB interface but we also have the many form factors of PCI including PC/104 and PCMCIA as well as ISA and RS232.  See our range. 

CAN FD is supported to the latest standard by single and dual ported interfaces as well as 1/2/4 channel PCIe cards.

These are then all supported by extensive ......


Embedded CAN chip manufacturers will provide examples of how to drive their chips, usually written in assembler or C.  PC software to drive the USB, PCI or other interfaces to CAN is also supplied by the interface manufacturer.  Peak provide both low level drivers for Windows and a free API for their interfaces to allow CAN and LIN to be driven from a range of application languages on the PC. Also available are CAN analyser packages from the free, simple, but powerful PCAN-View to the sophisticated PCAN-Explorer which provides data plotting with strip charts, user defined message names and data conversions for ease of analysis as well as extensive macro and script support for data collection and control.  Add-in packages include J1939 support,  a GUI interface that can be used for both display and control and a replay facility for Simulation.  A specific software package is available to cover the FMS Bus and Truck standard so that it can be easily used by engineers not familiar with CAN.

LabView, Linux, QNX, VxWorks, MAC OS X and  MathWorks are all supported.

A Windows standard API has been developed for communicating between C code on PCs and CAN - its called RP1210 and a driver for it is available for the PCAN range of interfaces so that they can be used with applications supporting that standard.

CAN-Open is necessarily more complex but we can supply both PC based CANopen diagnostic and network management software and embedded drivers.


Further reading

Staffan Nilssons excellent introduction to CAN

Bosch started CAN and include many useful links on their site

CAN in Automation (CiA) is the CAN trade association

Kvaser have a good CAN description area with details of available embedded interface chips


For a .pdf copy of this tutorial plus information on CAN interfaces and free software  Download  5.8 Mbytes.


COMSOL have a wide range of CAN FD, CAN and LIN interfaces, CAN I/O units and Data Acquisition systems available with supporting software.




If you have found this tutorial useful you might also be interested in our tutorials on
 Embedded TCP/IP and USB or in tutorials on a range of microprocessor and microcontroller families.

  If so you can find them at Embedded Tutorials


Home Shop Products Supported Chips Information Zone Contact Site Map
Computer Solutions Ltd
1a New Haw Road, Addlestone, Surrey KT15 2BZ, England
Telephone: +44 (0) 1932 829460      Fax: +44 (0) 1932 840603
Email:      Web:
Copyright © 2015 Computer Solutions Ltd