|
|
|
| R2011b Documentation → xPC Target | |
Learn more about xPC Target |
|
| Contents | Index |
| On this page… |
|---|
This chapter describes the alternative First In First Out (FIFO) mode CAN drivers provided with the xPC Target blocks. The standard CAN drivers for the CAN boards from Softing GmbH (http://www.softing.com) program the CAN board firmware to run in Dynamic Object Buffer (DOB) mode. This mode is best suited for real-time environments where it is mandatory that the driver latency time is time deterministic. Running the firmware in Dynamic Object Buffer mode is always the best choice, except for the undesired side effect of high driver latency times.
Sending a CAN message — When sending a CAN message, the latency time is the time interval between the time accessing the board to provide all the information for the CAN message to be sent and the time the board returns the acknowledgment that the information has been received by the firmware. FIFO mode blocks send messages in the order that they are input to the block. They do not take into account the priority of the input.
Note Each CAN channel has two FIFOs, DPRAM and SRAM. The xPC Target FIFO block writes into the DPRAM FIFO. The Softing board transfers the messages from the DPRAM FIFO to the SRAM FIFO, from which the messages are transmitted onto the CAN bus. The DPRAM can buffer up to 31 messages; the SRAM can buffer up to 127 messages. This implies that while 127 messages can be buffered during congestion on the CAN bus, the 31 message limit of the DPRAM limits how many messages a model can write at one time. |
Receiving a CAN message — When receiving a CAN message, the latency time is the time interval between the time accessing the board to ask for current data (object data) of a certain CAN identifier and the time the board returns the actual data and other information about the CAN message.
Disadvantages of Dynamic Object Buffer mode — These latency times are mainly defined by the reaction time of the board firmware. In the case of the Softing boards, the latency time is the same for sending and receiving messages, with a fixed value of about 40 υs. If your xPC Target application has to send and receive a large number of CAN messages, the overall latency time can quickly become high and can make it impossible to run the application at the desired base sample time.
For example, assuming that a specific xPC Target application gets data from 12 CAN identifiers and transmits data by using eight CAN messages, the total number of CAN board read and write accesses adds up to 20. This results in a total CAN I/O latency time of
20*40 υs = 800 υs
With such an application, base sample times below 800 υs are impossible even if the dynamics of the corresponding Simulink model are simple and would only need 20 υs of computation time.
Advantages of Dynamic Object Buffer mode — However, even if the CAN I/O latency time in 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 means that the Dynamic Object Buffer mode is best suited for xPC Target applications that deal with only a small subset of all CAN messages going over the CAN network.
The xPC Target CAN blocks support the following message data types. If you have Softing ISA CAN boards, you can use only the double data type for messages. If you have Softing PCI and PC/104 CAN boards, you can use either CAN_MESSAGE or double data types for new messages.
CAN_MESSAGE — Structure that contains an array of eight unsigned 8-bit integers that contains the data. This structure also contains the ID, and the standard and extended ID range. CAN blocks can pass data of this type without requiring complicated bit packing and unpacking. This capability enables you to create simpler models. Use messages of this data type for new CAN application models. Consider updating existing CAN application models to use CAN_MESSAGE data types.
CAN_MESSAGE — Use CAN Pack blocks to pack individual signals into a CAN message for sending. Use CAN Unpack blocks to unpack individual signals from CAN messages,
You can construct a CAN_MESSAGE by using the CAN Pack. You can use this block to pass raw data packed elsewhere, by packing a data pattern manually. You can also use a CANDB file and select a predefined data pattern. If you have several CAN_MESSAGE messages, use a Mux block to combine them into a vector that you connect to a CAN FIFO send block.
Double — Double that represents 8 bytes of message in a signal. CAN blocks manipulate data of this type before passing it. Do not use this data type to create new CAN application models. The maximum size of the data frame of a CAN message is 8 bytes. This size is the same as the C data type double uses on PC-compatible systems. At the same time, the double data type is the default data type for Simulink signals. Represent the CAN data frame within a Simulink model with a scalar Simulink signal. You can represent the data frame even if the data frame has nothing in common with a double floating-point value. The xPC Target CAN library provides a Utility sublibrary that offers bit-packing and bit-unpacking blocks. Use these blocks to pack data types other than doubles into 64 bits (8 bytes or a double) as well as for the opposite operation. Simulink signals of data type double represent CAN data frames.
Updating Existing Models to Use CAN_MESSAGE Data Types. If you have Softing PCI and PC/104 CAN boards, you can update existing models to use CAN_MESSAGE data types. As a rule:
If your existing model contains CAN Bit-Packing and CAN Bit-Unpacking blocks, replace them with the CAN Pack and CAN Unpack blocks.
Open and reconfigure the CAN Send and Receive blocks to use CAN_MESSAGE data types.
Remove FIFO Mode CAN Message and CANDBC Translator blocks. Updated models no longer require the conversions that these blocks perform.
See the CAN Blocks Transition document for more information.
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 4 υs per CAN message and reading one event (CAN message) from the receive FIFO takes 17 υs. Both of these latency times are smaller than the 40 υs for 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 is filled with all CAN messages (identifiers) going over the CAN network, there can be a lot of data (CAN messages) that 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 that is 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 nondeterministic latency times.
You resolve the latency time issue in the xPC Target CAN FIFO drivers by defining a receive FIFO read depth that is a constant number during application execution. For example, if you assume a FIFO read depth of 5, each time the Read Receive FIFO driver block is executed at the block sample time, the driver code reads and returns five events (messages) from the receive FIFO. This is independent of how many events the FIFO currently contains. There can be only two messages received in the FIFO and the third to fifth read attempt might just return the "No new event" code. Nevertheless, because the FIFO read latency does not exceed 17 υs regardless of the event read out of the FIFO, the latency time becomes deterministic and is the Read FIFO Depth multiplied by 17 υs. 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 must be processed in the target application, the total latency can easily exceed the latency encountered with the Dynamic Object Buffer mode 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 again by another block instance (the event is no longer in the FIFO buffer). 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 controls the CAN acceptance filters of the CAN controller. The acceptance filter defines 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 only resolves the problem for a small subset of CAN network applications. See Acceptance Filters for more information on this.
Look again at the example of 12 messages to be received and eight 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
12*17 υs + 8*4 υs = 236 υs
This is a considerable smaller value than the 800 υs that results when you use Dynamic Object Buffer mode drivers.
For the next case, assume that there are 12 additional messages going regularly over the network that do not need to be processed by the target application. Additionally, assume that those messages cannot be filtered by the CAN controller acceptance filter. Then the total latency time increases to
12*17 υs +20*4 υs = 284 υs
There is no impact on the final result. That is 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.
FIFO mode drivers are especially suited for monitoring type applications, because FIFO mode can return additional information such as the bus state or the reception of error frames. Dynamic Object Buffer mode drivers do not allow querying such information.
This documentation only covers the differences between the Dynamic Object Buffer mode drivers (standard drivers), and the FIFO mode drivers introduced here. It assumes that you are familiar with the Dynamic Object Buffer mode drivers and have successfully run one of the loopback tests provided with the xPC Target product.
If you use FIFO mode drivers in your model, you must replace all Dynamic Object Buffer mode blocks (Setup, Send, Receive) with FIFO mode driver blocks. The CAN-AC2-xxx boards from Softing do not let you 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, you should not use the CAN-AC2 (ISA) for new projects. Instead use the CAN-AC2-PCI. Therefore, FIFO mode drivers are only provided for the CAN-AC2-PCI and the CAN-AC2-104 boards.
 | CAN I/O Support for FIFO | CAN FIFO Demonstrations |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
