White Papers > Testing TargetLink Models and C Code with Reactis

Download: PDF  


3  Working with TargetLink-Generated Code in Reactis for C

dSPACE TargetLink’s main purpose is generating native C code from models. Reactis can analyze those models to create comprehensive test suites. Reactis for C (a separate product) can take the test suite generated for the model and run it directly on the final C code, as part of a comprehensive back-to-back testing process.

3.1  Generating the TargetLink C Code

To generate suitable C code for testing using Reactis for C, do the following:

  1. Make sure the TargetLink model runs successfully in Model-In-the-Loop (MIL) mode in TargetLink.
  2. Make sure the TargetLink model runs successfully in Software-In-the-Loop (SIL) mode. This confirms that the code can be generated from the model, and that any supporting C files have been located, and that a linkable construct has been built.
  3. Select the option “Do not log anything” in the Simulation Frame Options window of the TargetLink main dialog.
  4. Select the option “Clean Code” in the Code and Logging Section of the TargetLink main dialog.

3.2  Comparing Behavior of Generated Code to Model

Since Reactis generates a test suite from the model that is the same format as used by Reactis for C, it is very easy to compare the C code behavior against the original model from which it was generated. In describing the comparison method, assume the following:

  • A.mdl is a TargetLink model
  • Reactis Tester is used to generate test suite TS.rst from A.mdl
  • B is the TargetLink-generated C application generated from A.mdl

The following steps let you run the test suite TS.rst (generated from A.mdl) on the generated C code B using Reactis for C. Any output differences will be flagged.

  1. Create a Reactis Build file (.rsm file) that lists the C source files used by B. This process is described in Section 3.3.
  2. Create a new harness, stored in a harness library (.rsh file), that specifies the entry function of the C code along with the inputs and outputs of the unit under test. For more information, please consult the Reactis for C documentation.
  3. Start Reactis for C Simulator.
  4. Load and run TS.rst. Any differences in behavior will be flagged. The executing C code can be easily examined in the Simulator environment.

3.3  Creating Reactis for C Build files for TargetLink-Generated C Code

Reactis for C offers white-box testing of the C code generated from the TargetLink model. This section describes how to create a Reactis Build file (RSM file) for TargetLink-generated C code. Doing so enables the white-box analysis of TargetLink-generated code in Reactis for C.

An RSM file includes the following information:

  • The C source files generated from the model
  • The location of RSM files for any additional libraries referenced from the C code.
  • The search path for finding header files during preprocessing
  • Any macro definitions required to compile the C code

The RSM file for code generated from one of the TargetLink fuelsys demo models is shown in Figure 5.

No libraries are used by this model. If you require libraries you would need to define RSM files for those libraries and list them in the "Libraries" tab of the RSM file.

Screenshots of Reactis Build File Editor.
Figure 5: RSM file tabs for C code generated in TargetLink 4.0.

Some other information to be aware of when creating RSM files includes the following:

  • Depending on the version of TargetLink used, the generated code is usually present in the “TLProj” directory.

3.4  Supporting TargetLink fixed-point code generation in Reactis for C

Reactis for C also supports TargetLink code generation for fixed-point applications. Reactis uses the native C files that implement the fixed point math functions, and builds them into a separate library, as described below.

Note: To make the compilation of the dSPACE fixed-point function files efficient, perform the following: In Reactis under Edit -> General, make sure the ’Create and use cache files for C code (files with extension MWI)’ option is checked.

The dsfxp.rsm library is built from C files located in directory:


In your rsm file dialog is a tab titled ’Libraries’; select it. Click the ’Add’ button in that section to create your library rsm file. For simplicity, you may want to create the dsfxp.rsm in the same directory as the source C files, so navigate to that directory.

Screenshots showing settings for fixed-point library
Figure 6: The RSM file tabs for the TargetLink fixed-point library

Select ALL the C files from this directory, then add them to the “Source Files” section. Add the appropriate paths to the “Include Search Path” section and create the entries in the “Defines” section as seen in Figure 6. Because the source files named in dsfxp are part of a standard library, there is no need to track code coverage within it. To do so, change the “Coverage Tracking” selection in the General tab of the rsm dialog to "Off".

3.5  Reactis support for TargetLink Custom Code Feature

TargetLink supports the insertion of user-supplied C code into the Simulink simulation environment. This may be useful if:

  • Blocks that are not supported by TargetLink have to be implemented.
  • Well-tested custom functions or algorithms need to be called from within the Simulink environment.

With the TargetLink “Custom Code Block”, you can insert parts of your own code directly, and have these sections ultimately appear in the TargetLink-generated code. This block is one of the TargetLink simulation blocks found in the “tllib” library.

Because these blocks implement S-Function-wrapped C code, they can be executed in Reactis, and even debugged using the Reactis for C Plugin. An example block from the model, “Custom Blocks” (provided in the TargetLink demo directory ) is shown in Figure 7.

Screenshot of Custom Code block.
Figure 7: Example model using the “Custom Code” block.

The file listed in the File name dialog, “table_code.c” is not actually a C file but a template file that TargetLink uses to provide a location for user insertion of both fixed- and floating-point code snippets. In the dialog of the “table_code.c” block, note the “Use production code for floating-point simulation” checkbox. This box should be checked if the user desires to build and execute fixed-point code. Otherwise it should be un-checked.

Because of the many ways the custom code block can be configured, it is the responsibility of the user to know which defines should be added, and which source files should be included. Please see the TargetLink documentation for more information on editing, compiling, and building the C code associated with this feature. For this example, an rsm file in shown in Figure 8.

Screenshots showing various settings
Figure 8: RSM file tabs for custom code library