| xPC Target | |
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 total latency may easily exceed the latency encountered when using the Dynamic Object Buffer mode driver scheme for the same application. There is another restriction specific to the FIFO mode concept. Using more than one Read Receive FIFO block in a Simulink model is not recommended, because a new event (message) read by one block instance cannot be read out again by another block instance (the event is no longer in the FIFO).Therefore the entire CAN receive part has to be concentrated in one Read Receive FIFO block in your model. For the write transmit FIFO side, this restriction does not apply. Here you can use as many instances as you want.
The Setup block for the CAN FIFO mode allows controlling the CAN acceptance filters of the CAN controller. The acceptance filter allows defining a range of CAN messages not to be forwarded to the receive FIFO. Filtering out unwanted CAN messages can drastically reduce the read receive FIFO latency time because the unwanted messages do not reach the receive FIFO. Unfortunately, the acceptance filter process uses binary evaluation, which does not allow filtering messages below and above a certain decimal range. Therefore the use of the acceptance filter does only resolve the problem for a small subset of CAN network applications. See Acceptance Filters for more information on this.
Lets look again at our example of 12 messages to be received and 8 messages to be transmitted. If those 20 messages with their specific identifiers are the only messages going over the CAN network (100% usage ratio) the total latency time is
This is a considerable smaller value than the 800us, which result when using the Dynamic Object Buffer mode drivers.
For the next case we assume that there are 12 additional messages going regularly over the network which have not to be processed by the target application. Additionally, we assume that those messages cannot be filtered out by the CAN controller acceptance filter. Then the total latency time increases to
There is no impact to the final result. That's the trade-off. Therefore the FIFO mode drivers are best suited for either CAN network monitoring applications or low latency CAN applications where the ratio between the number of messages to be processed and the number of total messages going over the network is high.
Especially for monitor type of applications the FIFO mode drivers are well suited, because the FIFO mode can return additional information like the bus state or the reception of error frames. The Dynamic Object Buffer mode drivers do not allow querying such information.
This documentation only covers the differences between the Dynamic Object Buffer mode drivers (which are the standard drivers), and the FIFO mode drivers introduced here. It is assumed that you are familiar with the Dynamic Object Buffer mode drivers and have successfully run one of the loop-back tests provided with xPC Target.
If you use the FIFO mode drivers in your model, you have to replace all Dynamic Object Buffer mode blocks (Setup, Send, Receive) by FIFO mode driver blocks. The CAN-AC2-xxx boards from Softing do not allow to run the two CAN ports in different modes. Therefore the mode has to be same for both ports, but you can use more than one CAN board and run the boards in different modes just by selecting the correct I/O driver blocks.
As mentioned in the standard CAN chapter we do not recommend using the CAN-AC2 (ISA) for any new projects. Instead use the CAN-AC2-PCI. As a consequence FIFO mode drivers are only provided for the CAN-AC2-PCI and the CAN-AC2-104 boards.
| | Introduction | CAN FIFO Driver Blocks for the CAN-AC2-PCI with Philips SJA1000 CAN-Controller | |