Specifications

Introduction
5-3
Advantages of Dynamic Object Buffer mode - However, even if the CAN I/O
latency time in the Dynamic Object Buffer mode is high, the benefit of this
mode is that the latency time stays constant almost independent of the traffic
volume on the CAN network. This leads to the conclusion that the Dynamic
Object Buffer mode is best suited for xPC Target applications which only have
to deal with a smaller subset of all CAN messages going over the CAN network.
FIFO Mode drivers for CAN boards from Softing
The CAN boards from Softing support another mode called First In First Out
(FIFO) mode. In this mode the Dynamic Object Buffer mode abstraction layer
in the firmware is missing and the firmware plays the role of a slim interface
between the receive and transmit FIFOs and the drivers in the application
code. Because of this slimmer interface, the I/O latency times are considerably
smaller. Writing to the transmit FIFO takes 4us per CAN message and reading
one event (CAN message) from the receive FIFO takes 17us. Both of these
latency times are smaller than the 40us for the Dynamic Object Buffer mode.
While writing to the transmit FIFO is efficient, this is not the case for reading
from the receive FIFO. Because the receive FIFO gets filled with all CAN
messages (identifiers) going over the CAN network, there may be a lot of data
(CAN messages) which have to be read out of the FIFO even if their data is not
used in the target application. Because of the FIFO structure, all events
(messages) have to be read until the message is returned which has to be
propagated to the target application. The driver code for reading the receive
FIFO is principally a while loop and this can add the problem of
non-deterministic latency times.
The latency time issue in the xPC Target CAN FIFO drivers is resolved by
defining a receive FIFO read depth which is a constant number during
application execution. For example, if we assume a FIFO read depth of 5, each
time the Read Receive FIFO driver block gets executed at the block sample
time, the driver code reads and returns 5 events (messages) from the receive
FIFO. This is independent of how may events the FIFO currently contains.
There may be only two messages received in the FIFO and the third to fifth
read attempt may just return the “No new event” code. But nevertheless,
because the FIFO read latency does not exceed 17us independent of the event
read out of the FIFO, the latency time gets deterministic and is the Read FIFO
Depth multiplied by 17us. But again, the driver block returns all new events
and therefore all CAN messages going over the network. If only a small subset
of the CAN messages received has to be processed in the target application, the