Hardware Reference
In-Depth Information
Application layer
Supervisor
CAN layers
Acceptance filtering
Overload notification
Recovery management
Data link
LLC sublayer
Data encapsulation/decapsulation
Frame coding (stuffing/destuffing)
Medium access management
Error detection
Error signaling
Acknowledgement
Serialization/deserialization
MAC sublayer
Fault
confinement
Bit encoding/decoding
Bit timing
Synchronization
Physical
Bus failure
management
Driver/receiver characteristics
Figure 13.1
■
CAN layers
M
ESSAGE
-B
ASED
C
OMMUNICATION
CAN is a message-based protocol rather than an address-based protocol. Embedded in each
message is an
identifier
. This identifier allows messages to arbitrate the use of the CAN bus
and also allows each node to decide whether to work on the message. The value of the identi-
fier is used as the priority of the message. The lower the value, the higher the priority. Each
node in the CAN system uses one or more filters to compare the identifier of the incoming
message. Once the identifier passes the filter, the message will be worked on by the node. The
CAN protocol also provides the mechanism for a node to request data transmission from an-
other node. Since an address is not used in the CAN system, there is no need to reconfigure the
system whenever a node is added to or deleted from a system. This capability allows the system
to perform node-to-node or multicast communications.
E
RROR
D
ETECTION
AND
F
AULT
C
ONFINEMENT
The CAN protocol requires each sending node to monitor the CAN bus to find out if the
bus value and the transmitted bit value are identical. For every message, cyclic redundancy
check is calculated and the checksum is appended to the message. CAN is an asynchronous
protocol and hence clock information is embedded in the message rather than transmitted as
a separate signal. A message with long sequence of identical bits could cause a synchroniza-
tion problem. To resolve this problem, the CAN protocol requires the physical layer to use bit
Search WWH ::
Custom Search