History:
CAN or Controller Area Network or CAN-bus is an ISO standard
computer network protocol and bus standard, designed for
microcontrollers and devices to communicate with each other
without a host computer. Designed earlier for industrial
networking but recently more adopted to automotive applications,
CAN have gained widespread popularity for embedded control
in the areas like industrial automation, automotives, mobile
machines, medical, military and other harsh environment
network applications.
Development of the CAN-bus started originally in 1983 at
Robert Bosch GmbH. The protocol was officially released
in 1986. and the first CAN controller chips, produced by
Intel and Philips, introduced in the market in the year
of 1987.
Introduction:
The CAN is a "broadcast" type of bus. That means
there is no explicit address in the messages. All the nodes
in the network are able to pick-up or receive all transmissions.
There is no way to send a message to just a specific node.
To be more specific, the messages transmitted from any node
on a CAN bus does not contain addresses of either the transmitting
node, or of any intended receiving node. Instead, an identifier
that is unique throughout the network is used to label the
content of the message. Each message carries a numeric value,
which controls its priority on the bus, and may also serve
as an identification of the contents of the message. And
each of the receiving nodes performs an acceptance test
or provides local filtering on the identifier to determine
whether the message, and thus its content, is relevant to
that particular node or not, so that each node may react
only on the intended messages. If the message is relevant,
it will be processed; otherwise it is ignored.
How do they communicate?
If the bus is free, any node may begin to transmit. But
what will happen in situations where two or more nodes attempt
to transmit message (to the CAN bus) at the same time. The
identifier field, which is unique throughout the network
helps to determine the priority of the message. A "non-destructive
arbitration technique" is used to accomplish this,
to ensure that the messages are sent in order of priority
and that no messages are lost. The lower the numerical value
of the identifier, the higher the priority. That means the
message with identifier having more dominant bits (i.e.
bit 0) will overwrite other nodes' less dominant identifier
so that eventually (after the arbitration on the ID) only
the dominant message remains and is received by all nodes.
As stated earlier, CAN do not use address-based format for
communication, instead uses a message-based data format.
Here the information is transferred from one location to
another by sending a group of bytes at one time (depending
on the order of priority). This makes CAN ideally suited
in applications requiring a large number of short messages
(e.g.: transmission of temperature and rpm information).
by more than one location and system-wide data consistency
is mandatory. (The traditional networks such as USB or Ethernet
are used to send large blocks of data, point-to-point from
node A to node B under the supervision of a central bus
master).
Let us now try to understand how these nodes are interconnected
physically, by pointing out some examples. A modern automobile
system will have many electronic control units for various
subsystems (fig1-a). Typically the biggest processor will
be the engine control unit (or the host processor). The
CAN standard even facilitates the subsystem to control actuators
or receive signals from sensors. A CAN message never reaches
these devices directly, but instead a host-processor and
a CAN Controller (with a CAN transciever) is needed between
these devices and the bus. (In some cases, the network need
not have a controller node; each node can easily be connected
to the main bus directly.)
The CAN Controller stores received bits (one by one) from
the bus until an entire message block is available, that
can then be fetched by the host processor (usually after
the CAN Controller has triggered an interrupt). The Can
transciever adapts signal levels from the bus, to levels
that the CAN Controller expects and also provides a protective
circuitry for the CAN Controller. The host-processor decides
what the received messages mean, and which messages it wants
to transmit itself.
Fig 1-a
It is likely that the more rapidly changing parameters need
to be transmitted more frequently and, therefore, must be
given a higher priority. How this high-priority is achieved?
As we know, the priority of a CAN message is determined
by the numerical value of its identifier. The numerical
value of each message identifier (and thus the priority
of the message) is assigned during the initial phase of
system design. To determine the priority of messages (while
communication), CAN uses the established method known as
CSMA/CD with the enhanced capability of non-destructive
bit-wise arbitration to provide collision resolution and
to exploit the maximum available capacity of the bus. "Carrier
Sense" describes the fact that a transmitter listens
for a carrier wave before trying to send. That is, it tries
to detect the presence of an encoded signal from another
station before attempting to transmit. If a carrier is sensed,
the node waits for the transmission in progress to finish
before initiating its own transmission. "Multiple Access"
describes the fact that multiple nodes send and receive
on the same medium. All other nodes using the medium generally
receive transmissions by one node. "Collision Detection"
(CD) means that collisions are resolved through a bit-wise
arbitration, based on a preprogrammed priority of each message
in the identifier field of a message.
Fig 1-b
Let us now try to understand how the term "priority"
becomes more important in the network. Each node can have
one or more function. Different nodes may transmit messages
at different times (Depends how the system is configured)
based on the function(s) of each node. For example:
1) Only when a system failure (communication failure) occurs.
2) Continually, such as when it is monitoring the temperature.
3) A node may take action or transmit a message only when
instructed by another node, such as when a fan controller
is instructed to turn a fan on when the temperature-monitoring
node has detected an elevated temperature.
Note:
When one node transmits the message, sometimes many nodes
may accept the message and act on it (which is not a usual
case). For example, a temperature-sensing node may send
out temperature data that are accepted & acted on only
by a temperature display node. But if the temperature sensor
detects an over-temperature situation, then many nodes might
act on the information.
CAN use "Non Return to Zero" (NRZ) encoding (with
"bit-stuffing") for data communication on a "differential
two wire bus". The two-wire bus is usually a twisted
pair (shielded or unshielded). Flat pair (telephone type)
cable also performs well but generates more noise itself,
and may be more susceptible to external sources of noise.
Main Features:
a) A two-wire, half duplex, high-speed network system mainly
suited for high-speed applications using "short messages".
(The message is transmitted serially onto the bus, one bit
after another in a specified format).
b) The CAN bus offers a high-speed communication rate up
to 1 M bits / sec, for up to 40 feet, thus facilitating
real-time control. (Increasing the distance may decrease
the bit-rate).
c) With the message-based format and the error-containment
followed, it's possible to add nodes to the bus without
reprogramming the other nodes to recognize the addition
or changing the existing hardware. This can be done even
while the system is in operation. The new node will start
receiving messages from the network immediately. This is
called "hot-plugging"
d) Another useful feature built into the CAN protocol is
the ability of a node to request information from other
nodes. This is called a remote transmit request, or RTR.
e) The use of NRZ encoding ensures compact messages with
a minimum number of transitions and high resilience to external
disturbance.
f) CAN protocol can link up to 2032 devices (assuming one
node with one identifier) on a single network. But accounting
to the practical limitations of the hardware (transceivers),
it may only link up to 110 nodes on a single network.
g) Has an extensive and unique error checking mechanisms.
h) Has High immunity to Electromagnetic Interference. Has
the ability to self-diagnose & repair data errors.
i) Non-destructive bit-wise arbitration provides bus allocation
on the basis of need, and delivers efficiency benefits that
can not be gained from either fixed time schedule allocation
(e.g. Token ring) or destructive bus allocation (e.g. Ethernet.)
j) Fault confinement is a major advantage of CAN. Faulty
nodes are automatically dropped from the bus. This helps
to prevent any single node from bringing the entire network
down, and thus ensures that bandwidth is always available
for critical message transmission.
k) The use of differential signaling (a method of transmitting
information electrically by means of two complementary signals
sent on two separate wires) gives resistance to EMI &
tolerance of ground offsets.
l) CAN is able to operate in extremely harsh environments.
Communication can still continue (but with reduced signal
to noise ratio) even if:
1. Either of the two wires in the bus is broken
2. Either wire is shorted to ground
3. Either wire is shorted to power supply.
CAN protocol Layers & message Frames:
Like any network applications, Can also follows layered
approach to the system implementation. It conforms to the
Open Systems Interconnection (OSI) model that is defined
in terms of layers. The ISO 11898 (For CAN) architecture
defines the lowest two layers of the seven layers OSI/ISO
model as the data-link layer and physical layer. The rest
of the layers (called Higher Layers) are left to be implemented
by the system software developers (used to adapt and optimize
the protocol on multiple media like twisted pair. Single
wire, optical, RF or IR). The Higher Level Protocols (HLP)
is used to implement the upper five layers of the OSI in
CAN.
CAN use a specific message frame format for receiving
and transmitting the data. The two types of frame format
available are:
a) Standard CAN protocol or Base frame format
b) Extended Can or Extended frame format
The following figure (Fig 2) illustrates the standard CAN
frame format, which consists of seven different bit-fields.
a) A Start of Frame (SOF) field - indicates the beginning
of a message frame.
b) An Arbitration field, containing a message identifier
and the Remote Transmission Request (RTR) bit. The RTR bit
is used to discriminate between a transmitted Data Frame
and a request for data from a remote node.
c) A Control Field containing six bits in which two reserved
bits (r0 and r1) and a four bit Data Length Code (DLC).
The DLC indicates the number of bytes in the Data Field
that follows.
d) A Data Field, containing from zero to eight bytes.
e) The CRC field, containing a fifteen-bit cyclic redundancy
check-code and a recessive delimiter bit.
f) The Acknowledge field, consisting of two bits. The first
one is a Slot bit which is transmitted as recessive, but
is subsequently over written by dominant bits transmitted
from any node that successfully receives the transmitted
message. The second bit is a recessive delimiter bit.
g) The End of Frame field, consisting of seven recessive
bits.
An Intermission field consisting of three recessive bits
is then added after the EOF field. Then the bus is recognized
to be free.
(Fig 2)
The Extended Frame format provides the Arbitration field
with two identifier bit fields. The first (the base ID)
is eleven (11) bits long and the second field (the ID extension)
is eighteen (18) bits long, to give a total length of twenty
nine (29) bits. The distinction between the two formats
is made using an Identifier Extension (IDE) bit. A Substitute
Remote Request (SRR) bit is also included in the Arbitration
Field.
Error detection & correction:
This mechanism is used for detecting errors in messages
appearing on the CAN bus, so that the transmitter can retransmit
message. The CAN protocol defines five different ways of
detecting errors. Two of these works at the bit level, and
the other three at the message level.
1. Bit Monitoring.
2. Bit Stuffing.
3. Frame Check.
4. Acknowledgement Check.
5. Cyclic Redundancy Check
1. Each transmitter on the CAN bus monitors (i.e. reads
back) the transmitted signal level. If the signal level
read differs from the one transmitted, a Bit Error is signaled.
Note that no bit error is raised during the arbitration
process.
2. When five consecutive bits of the same level have been
transmitted by a node, it will add a sixth bit of the opposite
level to the outgoing bit stream. The receivers will remove
this extra bit. This is done to avoid excessive DC components
on the bus, but it also gives the receivers an extra opportunity
to detect errors: if more than five consecutive bits of
the same level occurs on the bus, a Stuff Error is signaled.
3. Some parts of the CAN message have a fixed format, i.e.
the standard defines exactly what levels must occur and
when. (Those parts are the CRC Delimiter, ACK Delimiter,
End of Frame, and also the Intermission). If a CAN controller
detects an invalid value in one of these fixed fields, a
Frame Error is signaled.
4. All nodes on the bus that correctly receives a message
(regardless of their being "interested" of its
contents or not) are expected to send a dominant level in
the so-called Acknowledgement Slot in the message. The transmitter
will transmit a recessive level here. If the transmitter
can't detect a dominant level in the ACK slot, an Acknowledgement
Error is signaled.
5. Each message features a 15-bit Cyclic Redundancy Checksum
and any node that detects a different CRC in the message
than what it has calculated itself will produce a CRC Error.
Error confinement:
Error confinement is a technique, which is unique to CAN
and provides a method for discriminating between temporary
errors and permanent failures in the communication network.
Temporary errors may be caused by, spurious external conditions,
voltage spikes, etc. Permanent failures are likely to be
caused by bad connections, faulty cables, defective transmitters
or receivers, or long lasting external disturbances.
Let us now try to understand how this works.
Each node along the bus will be having two error counters
namely the transmit error counter (TEC) and the receive
error counter (REC), which are used to be incremented and/or
decremented in accordance with the error detected. If a
transmitting node detects a fault, then it will increments
its TEC faster than the listening nodes increments its REC
because there is a good chance that it is the transmitter
who is at fault.
A node usually operates in a state known as "Error
Active" mode. In this condition a node is fully functional
and both the error count registers contain counts of less
than 127. When any one of the two error counters raises
above 127, the node will enter a state known as "Error
Passive". That means, it will not actively destroy
the bus traffic when it detects an error. The node which
is in error passive mode can still transmit and receive
messages but are restricted in relation to how they flag
any errors that they may detect. When the Transmit Error
Counter rises above 255, the node will enter the Bus Off
state, which means that the node doesn't participate in
the bus traffic at all. But the communications between the
other nodes can continue unhindered.
To be more specific, an "Error Active" node will
transmit "Active Error Flags" when it detects
errors, an "Error Passive" node will transmit
"Passive Error Flags" when it detects errors and
a node, which is in "Bus Off" state will not transmit
"anything" on the bus at all. The transmit errors
give 8 error points, and receive errors give 1 error point.
Correctly transmitted and/or received messages cause the
counter(s) to decrease. The other nodes will detect the
error caused by the Error Flag (if they haven't already
detected the original error) and take appropriate action,
i.e. discard the current message.
Confused? Let us try to get slightly simplified.
Let's assume that whenever node-A (for example) on a bus
tries to transmit a message, it fails (for whatever reason).
Each time this happens, it increases its Transmit Error
Counter by 8 and transmits an Active Error Flag. Then it
will attempt to retransmit the message and suppose the same
thing happens again. When the Transmit Error Counter rises
above 127 (i.e. after 16 attempts), node A goes Error Passive.
It will now transmit passive error flags on the bus. A Passive
Error Flag comprises 6 recessive bits, and will not destroy
other bus traffic - so the other nodes will not hear the
node-A complaining about bus errors. However, A continues
to increase its TEC. When it rises above 255, node-A finally
stops and goes to "Bus Off" state.
What does the other nodes think about node A? - For every
active error flag that A transmitted, the other nodes will
increase their Receive Error Counters by 1. By the time
that A goes Bus Off, the other nodes will have a count in
their Receive Error Counters that is well below the limit
for Error Passive, i.e. 127. This count will decrease by
one for every correctly received message. However, node
A will stay bus off. Most CAN controllers will provide status
bits and corresponding interrupts for two states: "Error
Warning" (for one or both error counters are above
96) and "Bus Off".
Bit Timing and Synchronization:
The time for each bit in a CAN message frame is made up
of four non-overlapping time segments as shown below.
The following points may be relevant as far as the "bit
timing" is concerned.
1. Synchronization segment is used to synchronize the nodes
on the bus. And it will always be of one quantum long.
2. One time quanta (which is also known as the system clock
period) is the period of the local oscillator, multiplied
by the value in the Baud Rate Pre-scaler (BRP) register
in the CAN controller.
3. A bit edge is expected to take place during this synchronization
segment when the data changes on the bus.
4. Propagation segment is used to compensate for physical
delay times within the network bus lines. And is programmable
from one to eight time quanta long.
5. Phase-segment1 is a buffer segment that can be lengthened
during resynchronization to compensate for oscillator drift
and positive phase differences between the oscillators of
the transmitting and receiving nodes. And is also programmable
from one to eight time quanta long.
6. Phase-segment2 can be shortened during resynchronization
to compensate for negative phase errors and oscillator drift.
And is the maximum of Phase-segment1 combined with the Information
Processing Time.
7. The Sample point will always be at the end of Phase-seg1.
It is the time at which the bus level is read and interpreted
as the value of the current bit.
8. The Information Processing Time is less than or equal
to 2 time quanta.
This bit time is programmable at each node on a CAN Bus.
But be aware that all nodes on a single CAN bus must have
the same bit time regardless of transmitting or receiving.
The bit time is a function of the period of the oscillator
local to each node, the value that is user-programmed into
BRP register in the controller at each node, and the programmed
number of time quanta per bit.
How do they synchronize:
Suppose a node receives a data frame. Then it is necessary
for the receiver to synchronize with the transmitter to
have proper communication. But we don't have any explicit
clock signal that a CAN system can use as a timing reference.
Instead, we use two mechanisms to maintain synchronization,
which is explained below.
Hard synchronization:
It occurs at the Start-of-Frame or at the transition of
the start bit. The bit time is restarted from that edge.
Resynchronization:
To compensate for oscillator drift, and phase differences
between transmitter and receiver oscillators, additional
synchronization is needed. The resynchronization for the
subsequent bits in any received frame occurs when a bit
edge doesn't occur within the Synchronization Segment in
a message. The resynchronization is automatically invoked
and one of the Phase Segments are shortened or lengthened
with an amount that depends on the phase error in the signal.
The maximum amount that can be used is determined by a user-programmable
number of time quanta known as the Synchronization Jump
Width parameter (SJW).
Higher Layer Protocols:
Higher layer protocol (HLP) is required to manage the communication
within a system. The term HLP is derived from the OSI model
and its seven layers. But the CAN protocol just specifies
how small packets of data may be transported from one point
to another safely using a shared communications medium.
It does not contain anything on the topics such as flow
control, transportation of data larger than CAN fit in an
8-byte message, node addresses, establishment of communication,
etc. The HLP gives solution for these topics.
Higher layer protocols are used in order to
1. Standardize startup procedures including bit rate setting
2. Distribute addresses among participating nodes or kinds
of messages
3. Determine the layout of the messages
4. Provide routines for error handling on system level
Different Higher Layer Protocols
There are many higher layer protocols for the CAN bus. Some
of the most commonly used ones are given below.
1. Can Kingdom
2. CAN open
3. CCP/XCP
4. Device Net
5. J1939
6. OSEK
7. SDS
Note:
Lot of recently released microcontrollers from Freescale,
Renesas, Microchip, NEC, Fujitsu, Infineon, and Atmel and
many such leading MCU vendors are integrated with CAN interface.
Next
Module - 10(LIN interface)
Previous
Module - 8(RS 232 basics)
\ABOUT THIS COURSE:
Totally EEHerald plan to bring 12 modules. You can
be assured of completing basic course in Embedded Systems
after studying and practicing exercises in all the modules.
We will give priority to programming and serial communications
(SPI, USB, CAN etc..) part. To receive a copy of total course
syllabus, please email to us.
This free tutorials on embedded systems is prepared
by embedded professionals with more than10 years of industrial
experience, however we want your feedback on this course
content; please email your questions, suggestions and comments
to editor@eeherald.com. Your questions on present modules
will be answered in the revised modules. We may change the
course content based on the majority of your requests and
feedbacks.
Please let your friends know about this course, we request
you to email this link to your friends and colleagues who
are interested in embedded system.
