Civil Engineering Reference
In-Depth Information
not inside the M_CAN. The M_CAN module is compliant with CAN protocol
2.0 A, B, and
ISO 11898-1
. Figure
3.1
shows its internal structure.
All functions specified in the CAN protocol, such as CAN protocol control-
ler state machines as well as the shift registers for transmission and reception, are
implemented in the CAN core. This protocol unit has been adopted from earlier
CAN modules and is part of a direct line of development that begins with the in-
troduction of the CAN protocol. The CAN core's interface signals are connected to
the rest of the M_CAN via a synchronization logic. This makes it possible to supply
the CAN core with a dedicated clock for CAN communication, whereas the rest of
the module is in the same clock domain as the host central processing unit (CPU).
For example, the CAN core might be operated with an 8 MHz crystal clock while
the CPU is supplied with a phase-locked loop (PLL) clock of significantly higher
frequency which—to limit noise emission—may also be modulated.
The Tx Handler controls the transmission of messages. The host CPU may
set transmission requests for several messages; transmit cancellation is also
supported. The Tx Handler then transfers the messages—according to the priority
of their identifiers—from the
Message RAM
to the CAN core's shift register. Up to
32 dedicated transmit buffers are available. They may—partially or completely—be
combined to operate as a transmit first-in-first-out (FIFO) or as a transmit queue.
Status information regarding the requested transmissions, including a 16-bit trans-
mit time stamp, may be logged into the optional Tx Event FIFO.
Dedicated receive buffers and up to two receive FIFOs may be configured for the
reception of messages, under the control of the Rx Handler. The Rx Handler per-
forms acceptance filtering and transfers received messages into the
Message RAM
.
The following filter types are available for the acceptance filtering:
• Range filter: Matches for identifiers in the range from start identifier to end iden-
tifier.
• Bit masking: Matches for a specific identifier while some identifier bits may be
masked.
• Dual filter: Matches for two specific identifiers.
• Dedicated Rx: Matches for the identifier of a dedicated receive buffer.
The filters can each be used as acceptance or as rejection filter; they also decide
where accepted messages are to be stored. In total, up to 128 filter elements may
be configured for
11-bit identifiers
and up to 64 for
29-bit identifiers
. This may be
combined with a global mask for
29-bit identifiers
, in support of J1939 applications.
The various filter options allow a targeted filtering of received messages ensuring
that only messages which are relevant for the particular node are stored in the
Mes-
sage RAM
; others are rejected. The reception time, a 16-bit time stamp, is optionally
stored with the message.
The M_CAN module combines both qualities of the “Full CAN” concept and of
the “Basic CAN” concept. Received messages are stored in dedicated receive buf-
fers as well as in FIFOs; no software acceptance filtering is needed. The transmit
messages may be—depending on the application—stored in dedicated transmit buf-
fers or managed in a transmit FIFO or in a dynamic transmit queue.
