Civil Engineering Reference
In-Depth Information
− Each message object can be part of a FIFO of any size. The only limitation
is the absolute amount of message objects. The message objects are part of
a double-chained list and the FIFO is done in the very same structure. The
double-chained lists can be changed during runtime.
− Each message object can be part of a GW, rerouting messages from one CAN
bus to another.
− The list/a part of list can be rerouted to another CAN node at any time.
− Up to 16 interrupt nodes can be assigned to interrupt sources within the
module.
The MultiCAN module can include up to 256 message objects and eight CAN
nodes. Depending on the implementation, the amount of CAN nodes and mes-
sage objects can be different from one controller to another. For example, a
XC878 included two CAN nodes and 32 message objects, a TC1167/TC1767 has
two CAN nodes and 64 message objects, the TC1797 has four CAN nodes and
128 message objects and most family members of the XC2000/XE166 family
are available with six CAN nodes and 256 message objects. All members of the
Audo MAX family do include the MultiCAN module. Like the TwinCAN mod-
ule, the module is split between node logic and message objects. Node logic and
the message objects are combined and made on module by the control logic. The
message objects can be freely assigned to any of the nodes. However, they are
not part of a static structure, which is controlling the message objects, but they
are part of a list structure. Therefore, it is possible to reassign message objects
during runtime, but also to have FIFOs of any size. Figure
3.12
shows a block
diagram of the module.
Like on TwinCAN, each message object has a local mask, giving the possibil-
ity to receive a group of message identifiers. The flexibility of the FIFO has been
increased by using the list structure within the module. Therefore, all message ob-
jects (against TwinCAN being limited) can be part of a FIFO, GW, or FIFO/GW
combination. The message objects can be scattered over the RAM and do not need
to be behind each other.
Figure
3.13
shows an example, with a FIFO consisting of message objects
5, 16, and number 3. Message object 5 is the source object. The source object
does not need to be part of the FIFO. Message object 3 is the end of the list and,
therefore, pointing to itself. The current position within the FIFO is shown by the
pointer CUR(rent). The terminology in Fig.
3.13
is identical to that in the User's
Manual.
With the help of the list structure, a GW can be built. In contrast to TwinCAN,
the number of the message object is no longer relevant to build such a GW.
As on TwinCAN, the FIFO and the GW feature may be combined to a GW/FIFO
feature. By using the list structure, it is possible to change the FIFO size during the
runtime to react flexibly on different busloads. For example, in case that a diagnosis
is activated, a different set of message identifiers becomes relevant and the software
is able to react to this change.
