| xPC Target | |
This block is used to extract CAN data frames and its input port is normally connected to an output port of a CAN Receive driver block. The block has one input port of data type double (a scalar) which represents the data frame entity from which the signals are extracted and leaving the block at its output ports. The number of output ports and the data type of each output port depends on the settings in the blocks dialog box.
The dialog box contains two controls (edit fields).
The first lets you define the bit patterns in a flexible way. The data type entered in the control has to be a MATLAB cell array vector. The number of elements in the cell array define the number of output ports shown by this block instance. The cell array elements have to be of type double array and define where the bits of the incoming double value (data frame) come to lie at what position in the output port values (data typed).
From a data type perspective (output ports) the block behave like a Simulink source block and therefore the data types of the output ports have to be defined in the second control (edit field). The data type entered in that control has to be a MATLAB cell array vector of the same length as the bit pattern cell array. The cell array elements have to be of type char and define the data type of the corresponding output port. The following values are supported:
The sample time of the block is inherited from the driving block. Therefore no explicit sample time has to be provided in the block's dialog box.
The functionality of the block is easiest explained by means of an example. We take the same example as used above to demonstrate the functionality of the bit-packing block. But in this case, the data frame is sent by an external CAN node and is received by the target application running on an xPC Target system. Therefore the bit-unpacking block has to be used in order to extract the various data fields out of the entire data frame. Because the bit pattern definition of the packing and unpacking block are symmetric, the bit pattern definition could look exactly the same. There is one simple optimization possible: We don't have to extract byte 2 (reserved area), because its content is known. The bit pattern edit field can therefore look as follows,
and the data type edit field as
This leads to the following Simulink model.
In many cases it makes sense to test the proper bit-packing and bit-unpacking operations in a Simulink model (simulation) before building the target application. Both blocks are working the same way either in Simulink or within the generated code. By combining the two models shown so far we get to a third one which can be used to simulate the behavior.
| | CAN Bit-Packing Block | Detecting Time-outs When Receiving CAN Messages | |
