Introduction
Last updated
Last updated
This guide explains the CAN Bus module features and functions.
Important:
All documents and any examples they contain are provided as-is and are subject to change without notice. Except to the extent prohibited by law, Libelium makes no express or implied representation or warranty of any kind with regard to the documents, and specifically disclaims the implied warranties and conditions of merchantability and fitness for a particular purpose.
The information on Libelium's websites has been included in good faith for general informational purposes only. It should not be relied upon for any specific purpose and no representation or warranty is given as to its accuracy or completeness.
This guide describes all features of the CAN Bus module which has been mainly designed to perform vehicle diagnostics in real time. This module also allows the interconnection of different devices to work with this communications protocol for applications such as industrial networks, home automation, etc.
The CAN Bus (Controller Area Network) is a vehicle bus standard designed to allow micro-controllers and devices to communicate with each other within a vehicle without a host computer. CAN is a multi-master broadcast serial bus standard for connecting electronic control units (ECUs). Each node is able to send and receive messages, but not simultaneously. A message consists primarily of an ID (identifier), which represents the priority of the message. A CAN message that is transmitted with highest priority will succeed and the node transmitting the lower priority message will sense this and back off and wait.
The information is transmitted by two twisted wires that connect all system modules. It is transmitted by voltage difference between the two levels. The high voltage value represents 1 and low 0. Its combination forms an appropriate message.
The CAN Bus standard is a high-level protocol which offers various benefits compared to other simple wired protocols. For example, all the devices can send information whenever they want (if the bus is not busy) without the need of a master. CAN Bus offers addressing, acknolowledge, retry services. Besides, the protocol sets a standard frame that can be adapted in a flexible way. Last, it is easy to reach several hundreds of metres.
This list includes some of the most common uses of the standard:
Automotive applications
Home automation
Industrial networking
Factory automation
Marine electronics
Medical equipment
Military uses
A CAN network can be configured to work with two different message (or "frame") formats:
The standard or base frame format (or CAN 2.0 A)
The extended frame format (or CAN 2.0 B)
The only difference between the two formats is that the "CAN base frame" supports a length of 11 bits for the identifier, and the "CAN extended frame" supports a length of 29 bits for the identifier, made up of the 11-bit identifier ("base identifier") and an 18-bit extension ("identifier extension"). The distinction between CAN standard frame format and CAN extended frame format is made by using the IDE bit, which is transmitted as dominant in case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame.
CAN standard has four frame types:
Data frame: a frame containing node data for transmission
Remote frame: a frame requesting the transmission of a specific identifier
Error frame: a frame transmitted by any node detecting an error
Overload frame: a frame to inject a delay between data and/or remote frame
Data frame
The data frame is the only frame for actual data transmission. There are two message formats:
Standard frame format: with 11 identifier bits
Extended frame format: with 29 identifier bits
The CAN standard requires the implementation must accept the base frame format and may accept the extended frame format, but must tolerate the extended frame format.
Standard frame format
Field name
Length (bits)
Purpose
Start-of-frame
1
Denotes the start of frame transmission
Identifier
11
A (unique) identifier for the data which also represent the message priority
Remote transmission request (RTR)
1
Dominant (0) (see Remote Frame below)
Identifier extension bit (IDE)
1
Must be dominant (0). Optional.
Reserved bit (r0)
1
Reserved bit (it must be set to dominant (0), but accepted as either dominant or recessive)
Data length code (DLC)*
4
Number of bytes of data (0–8 bytes)
Data field
0–64 (0-8 bytes)
Data to be transmitted (length in bytes dictated by DLC field)
CRC
15
Cyclic Redundancy Check
CRC delimiter
1
Must be recessive (1)
ACK slot
1
Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter
1
Must be recessive (1)
End-of-frame (EOF)
7
Must be recessive (1)
Extended frame format
Field name
Length (bits)
Purpose
Start-of-frame
1
Denotes the start of frame transmission
Identifier A
11
First part of the (unique) identifier for the data which also represents the message priority
Substitute remote request (SRR)
1
Must be recessive (1). Optional.
Identifier extension bit (IDE)
1
Must be recessive (1). Optional.
Identifier B
18
Second part of the (unique) identifier for the data which also represents the message priority
Remote transmission request (RTR)
1
Must be dominant (0)
Reserved bits (r0, r1)
2
Reserved bits (it must be set dominant (0), but accepted as either dominant or recessive)
Data length code (DLC)*
4
Number of bytes of data (0–8 bytes)
Data field
0–8 bytes
Data to be transmitted (length dictated by DLC field)
CRC
15
Cyclic redundancy check
CRC delimiter
1
Must be recessive (1)
ACK slot
1
Transmitter sends recessive (1) and any receiver can assert a dominant (0)
ACK delimiter
1
Must be recessive (1)
End-of-frame (EOF)
7
Must be recessive (1)
The two identifier fields (A & B) combine to form a 29-bit identifier.
*It is physically possible for a value between 9--15 to be transmitted in the 4-bit DLC, although the data is still limited to eight bytes. Certain controllers allow the transmission and/or reception of a DLC greater than eight, but the actual data length is always limited to eight bytes.
Error frame
The error frame consists of two different fields:
The first field is given by the superposition of ERROR FLAGS (6--12 dominant/recessive bits) contributed from different stations.
The following second field is the ERROR DELIMITER (8 recessive bits).
There are two types of error flags:
Active Error Flag: six dominant bits, transmitted by a node detecting an error on the network that is in error state "error active".
Passive Error Flag: Six recessive bits, transmitted by a node detecting an active error frame on the network that is in error state "error passive".
Overload frame
The overload frame contains the two bit fields Overload Flag and Overload Delimiter. There are two kinds of overload conditions that can lead to the transmission of an overload flag:
The internal conditions of a receiver, which requires a delay of the next data frame or remote frame.
Detection of a dominant bit during intermission.
The start of an overload frame due to case 1 is only allowed to be started at the first bit time of an expected intermission, whereas overload frames due to case 2 start one bit after detecting the dominant bit. Overload Flag consists of six dominant bits. The overall form corresponds to that of the active error flag. The overload flag's form destroys the fixed form of the intermission field. As a consequence, all other stations also detect an overload condition and on their part start transmission of an overload flag. Overload Delimiter consists of eight recessive bits. The overload delimiter is of the same form as the error delimiter.
Interframe spacing
Data frames and remote frames, are separated from preceding frames, by a bit field called interframe space. Overload frames and error frames are not preceded by an interframe space and multiple overload frames are not separated by an interframe space. Interframe space contains the bit fields intermission and bus idle and, for error passive stations, which have been transmitter of the previous message, suspend transmission. Interframe space consists of at least three consecutive recessive (1) bits.
Bit stuffing
In CAN frames, a bit of opposite polarity is inserted after five consecutive bits of the same polarity. This practice is called bit stuffing, and is due to the non-return to zero (NRZ) coding adopted. The stuffed data frames are destuffed by the receiver. Since bit stuffing is used, six consecutive bits of the same type (111111 or 000000) are considered an error. Bit stuffing implies that sent data frames could be larger than one would expect by simply enumerating the bits shown in the tables above.
In order to work with the module, we not need to worry about error or overload frames, the frame parameters or as the frame is generated; because this is handled by the hardware (CAN-controller).