Switching between configuration sets changes the RTW auto-coder. This can be done one of two ways: right click on the configuration set in Simulink's Model Explorer and select Activate; or place one (or more) of the prtw_ConfigUsingRtwEc, prtw_ConfigUsingRtwRtmodel helper blocks in the model and double click the appropriate one.
The helper blocks perform a couple of actions which the Model Explorer won't.
The helper blocks will create an appropriate configuration set if one isn't available. This can be useful if a configuration set has been accidentally removed, or if more than one configuration set for the same auto-coder is required (perhaps to experiment with RTW options for that auto-coder).
The helper blocks will read the build list and populate the workspace with DDEs. This occurs because the EC auto-coder requires the workspace variables to have different types from the GRT auto-coders. See Section 4.3.5.2, “Using the EC auto-coder” for more.
Note that there is a prtw_Build helper block which starts a model build when double clicked.
Add a prtw_ConfigUsingRtwRtmodel block to the model and double click the block to select the GRT (RTMODEL) auto-coder.
There is little about this auto-coder and OpenECU which is configurable. Its worth noting that the data dictionary elements are available in the workspace using basic MATLAB types. The data dictionary elements can be used as any other MATLAB variable in scripts and general calculations.
Add a prtw_ConfigUsingRtwEc block to the model and double click the block to select the ERT (EC) auto-coder.
Like the other auto-coders, the data dictionary elements are used to populate the
workspace, but instead of using the basic MATLAB types, the workspace variables
use the custom storage class oe.Signal to represent named signal
lines between blocks, and oe.Parameter to represent block parameters
(either constants or calibrations). These variables cannot be used as other MATLAB
variables because these types contain many pieces of information.
To access the value for a parameter, use the expression [variable-name].Value.
There is no value for signals stored in MATLAB's workspace.
It can be useful to switch between the EC auto-coder and other auto-coders using the OpenECU utility blocks. When switching to a GRT auto-coder, the data dictionary is read into the workspace using MATLAB's basic types, and can be accessed like other MATLAB variables.
OpenECU uses Embedded Coder's Data Type Replacement feature to match the type of each C variable in the model to the same variable type used by the OpenECU library code.
| Simulink Type | OpenECU Type | Description |
|---|---|---|
| double | FREAL | Floating point type, 64-bits wide. Some OpenECU targets support 64-bit wide
floating point types and some don't. On those that do support 64-bit wide floats,
none have native support from the processor and require significant software
emulation support, slowing down the application. For that reason, OpenECU
implements Simulink 64-bit wide floating point type as a 32-bit floating point
type (which is what FREAL resolves to). |
| single | F32 | Floating point type, 32-bits wide. See the technical specification for the ECU regarding the implementation of floating point support. |
| int32 | S32 | Signed integer, 32-bits wide. |
| int16 | S16 | Signed integer, 16-bits wide. |
| int8 | S8 | Signed integer, 8-bits wide. |
| uint32 | U32 | Unsigned integer, 32-bits wide. |
| uint16 | U16 | Unsigned integer, 16-bits wide. |
| uint8 | U8 | Unsigned integer, 8-bits wide. |
| boolean | BOOL | Boolean type, at least 1-bit wide, typically 8-bits wide. |
| int | INT | Signed integer, at least 16-bits wide. |
| uint | UINT | Unsigned integer, at least 16-bits wide. |
This ensures that the model code and library code match when linked together, and can also help when checking code compliance against various coding standards (e.g., with MISRA-C, Guidelines for the use of the C language in critical systems).
OpenECU uses Embedded Coder's Templates feature to provide a consistent structure to each source code file generated by Embedded Coder. To that end, OpenECU provides templates stored in a sub-directory to the Embedded Coder template makefile for OpenECU.
If alternative templates are required then modify the configuration set for Embedded Coder to point to alternative files. But note that each time the OpenECU Embedded Coder configuration set is created, the templates will need to be modified again.
The model can be broken into source files using subsystems. Functionality contained in a subsystem, which has a Real-Time Workshop system code set to Function, can specify the file into which the functionality of the subsystem is auto-coded.
OpenECU uses Embedded Coder's Data Placement feature to provide a mechanism to place declarations and definitions of C variables in specific files.
By default, declarations and definitions are placed in globals.h
and globals.c, but these settings can be overridden by changing the
name in the configuration set. But note that each time the OpenECU Embedded Coder
configuration set is created, the data placement files will need to be modified again.
Variables can also be placed in specific files by specifying the file to use in the
data dictionary, under the decl and defn
columns. See Table 4.2, “Data dictionary columns” for more.