Hardware Reference
In-Depth Information
else if (tb
55
1)
CAN1TFLG
5
TXE1;
// mark buffer 1 ready for transmission
else
CAN1TFLG
5
TXE2;
// mark buffer 2 ready for transmission
}
▲
This example can be extended to construct a distributed sensor system. There are applica-
tions that need to monitor temperature, pressure, humidity, and any other parameter in a small
area that can be spanned by a CAN network. The purpose might be to monitor these environmen-
tal parameters and take appropriate actions in case abnormal values appear. In this type of appli-
cation, each CAN node sends out the environmental parameters periodically to the CAN bus. A
controlling CAN node keeps track of values sent from each node and does some processing. If the
controlling CAN node discovers any abnormal situation, it may remind the operator to take ap-
propriate action. To make sure each CAN node works normally, the controlling CAN node may
set a counter for each distributed node. If any CAN node did not send in environmental param-
eters within the time-out period, it will remind the operator to take some corrective actions.
To make the CAN network more fault-tolerant, the designer may consider adding the second
CAN bus to each node. The multiple CAN modules of many HCS12 devices serve this purpose well.
The CAN bus specification was initially proposed as a data communication protocol for
automotive applications. However, it can also fulfill the data communication needs of a wide
range of applications, from high-speed networks to low-cost multiplexed wiring.
The CAN protocol has gone through several revisions. The latest revision is 2.0A/B. The
CAN 2.0A uses standard identifiers whereas the CAN 2.0B specification accepts extended iden-
tifiers. The HCS12 MSCAN module supports the CAN 2.0A and 2.0B specifications.
The CAN protocol supports four types of messages:
data
frame, remote frame, error frame
,
and
overload frame
. Users need to transfer only data frames and remote frames. The other two
types of frames are only used by the CAN controller to control data transmission and reception.
Data frames are used to carry normal data; remote frames are used to request other nodes to
send messages with the same identifier as in the remote frame.
The CAN protocol allows all nodes on the bus to transmit simultaneously. When there
are multiple transmitters on the bus, they arbitrate, and the CAN node transmitting a mes-
sage with the highest priority wins. The simultaneous transmissions of multiple nodes will
not cause any damage to the CAN bus. CAN data frames are acknowledged in-frame; that is, a
receiving node sets a bit only in the acknowledge field of the incoming frame. There is no need
to send a separate acknowledge frame.
The CAN bus has two states:
dominant
and
recessive
. The dominant state represents logic 0,
and the recessive state represents logic 1 for most CAN implementations. When one node drives
the dominant voltage to the bus while other nodes drive the recessive level to the bus, the resul-
tant CAN bus state will be the dominant state.
Synchronization is a critical issue in the CAN bus. Each bit time is divided into four seg-
ments:
sync_seg, prop_seg, phase_seg1,
and
phase_seg2
. The sync_seg segment signals the start
of a bit time. The sample point is between phase_seg1 and phase_seg2. At the beginning of each
frame, every node performs a hard synchronization to align its sync_seg segment of its current
Search WWH ::
Custom Search