Control Placement of Global Data Definitions and Declarations in Generated Files
The generated code can create standard, global structure variables whose fields represent the signal, state, and parameter data in a model. With storage classes, you can configure data to appear in the code as separate global variables or custom global structures. For information about the standard data structures, see How Generated Code Stores Internal Signal, State, and Parameter Data and How Generated Code Exchanges Data with an Environment. For information about storage classes, see Choose Storage Class for Controlling Data Representation in Generated Code.
You can control the file placement of the variable definitions and declarations. Use the information in the table.
|Goal||Details and Techniques|
|Generate a variable that external code can use|
Apply a storage class with exported data scope, such as
Alternatively, to place the declaration in a file whose name you can specify, choose one of these techniques:
See Exchange Data Between External Calling Code and Generated Code.
|Generate code that uses a variable defined by external code|
Apply a storage class with imported data scope, such as
Alternatively, if you do
not have an external declaration header file or do not want the generated code to
include a header file, apply the storage class
See Exchange Data Between External Calling Code and Generated Code.
Depending on the setting of Configuration Parameters > File packaging format, generated files such as
|Combine multiple files into a single file|
|Separate data definitions from function definitions|
By default, the generated file that defines the entry-point functions for a model or subsystem also defines the data for that model or subsystem. When you frequently make changes to data, especially initial values for tunable parameters, the changing source code files can impede verification and make change management more difficult. To separate the data from the functions:
|Isolate data definitions in separate files for component-based, team-oriented model development|
See Organize Data to Support Component-Based, Team-Oriented Model Development.
|Aggregate definitions of variant control parameters (|
As described in Generate Preprocessor Conditionals for Variant Systems, a variant control parameter is a parameter
object such as
Organize Data to Support Component-Based, Team-Oriented Model Development
Depending on your model configuration, data definitions can appear aggregated in large generated files. In a system of components (subsystems or referenced models), you can separate and organize the data definitions into manageable, meaningful files based on the component hierarchy.
Establish ownership of global data by placing the data definitions with the code generated for specific components
When you divide a system into components by using referenced models and atomic subsystems, by default, global data is typically defined by the code generated for the top component in the hierarchy. Global data includes parameters, signals, and states to which you apply storage classes (see C Code Generation Configuration for Model Interface Elements).
Instead, you can place global data definitions with other components in the hierarchy. For an example involving referenced models, see Establish Data Ownership in a Model Hierarchy.
For an atomic subsystem, place the standard data structures for the subsystem with the subsystem code
By default, the standard data structures for an atomic subsystem appear as substructures of the data structures for the entire model.
To generate separate data structures for a subsystem, select the Function with separate data parameter in the subsystem block. Then, the subsystem data appear in separate structure variables that the subsystem code defines. See Generate Modular Function Code for Nonvirtual Subsystems.
Specify Default Placement
When you create data in a model by adding blocks and signal lines, by default, the data
definitions appear in
. To specify a
different default placement, use these tools and parameters:
The model configuration parameter File packaging format. The setting that you choose determines whether the code generator places the standard structures that store tunable and constant parameter data in
. See File packaging format.
The Code Mappings editor. For each category of model data, you can specify a default storage class, which controls file placement. For example, apply the storage class
ExportToFileto a data category and, in the Property Inspector, use the DefinitionFile, HeaderFile, and Owner properties to control file placement.
The model configuration parameters Data definition and Data declaration. These configuration parameters specify the default file placement for data items that you apply storage classes to.
These configuration parameters do not affect data items that you apply these storage classes to:
In the Embedded Coder® Dictionary, the Header File value for unsupported storage classes is empty. You cannot specify default file placement for unsupported storage classes.
If you apply a storage class that explicitly specifies definition and declaration files for a data element, those specifications override the Data definition and Data declaration configuration parameters.
For more information, see Data definition and Data declaration.
The subsystem block parameter Function with separate data. When you select this parameter, the standard structures that store the subsystem data, such as the DWork structure, appear as separate structure variables. By default, the variable definitions appear in the source file that defines the subsystem execution function. See Generate Modular Function Code for Nonvirtual Subsystems.
Override Default Placement for Individual Data Items
For an individual data item, to override the default file placement, use the Code
Mappings editor to apply a storage class directly. For example, to make a data item appear
in the generated code as a global variable, apply the storage class
ExportToFile. Then, use the Definition file and
Header file properties to control file placement. To apply storage
classes directly, see Organize Parameter Data into a Structure by Using Struct Storage Class.
Prevent Name Clashes by Configuring Data Item as
To apply the C keyword
static to a global variable, which can help
you avoid name clashes by limiting the scope of the variable name to the file that defines
the variable, choose one of these techniques:
Apply the built-in storage class
FileScope. For more information, see Choose Storage Class for Controlling Data Representation in Generated Code.
FileScopedoes not satisfy your requirements, create your own storage class by using the Custom Storage Class Designer. In the Designer, set Data scope to
File, the data element appears in the code as a
Auto, the code generator first attempts to represent the data element with a local variable in a function. If this attempt fails, the code generator uses a
For an example that shows how to create your own storage class by using the Designer, see Create and Apply a Storage Class.
You cannot apply
static to the standard data structures such as the
static data, you can configure the generated code to
include an interface such as an
a2l (ASAP2) file. For more information,
see Export ASAP2 File for Data Measurement and Calibration.
To place the data in a specific memory location by including pragmas or other decorations in
the generated code, create your own memory section and storage class. See Control Data and Function Placement in Memory by Inserting Pragmas.
Code Generation Impact of Storage Location for Parameter Objects
You can create a parameter object (such as
Simulink.Parameter) in the
base workspace, a model workspace, or a data dictionary. However, when you apply a storage
class to the object, the location of the object can impact the file placement of the
corresponding data definition in the generated code. See Code Generation Impact of Storage Location for Parameter Objects.
#include Syntax for Data Header Files
To control the file placement of a data item, such as a signal line or block state, in the generated code, you can apply a storage class to the data item (see Organize Parameter Data into a Structure by Using Struct Storage Class). You then use the Header file property to specify the generated or external header file that contains the declaration of the data.
To reduce maintenance effort and data entry, when you specify Header
file, you can omit delimiters (
<>) and use only the file name. You can then
control the default delimiters that the generated code uses for the corresponding
#include directives. To use angle brackets by default,
set Configuration Parameters > Code Generation > Code Placement > #include file delimiters to
- Exchange Data Between External C/C++ Code and Simulink Model or Generated Code
- Simulink Modeling Components
- Manage File Packaging of Generated Code Modules
- How Generated Code Exchanges Data with an Environment
- How Generated Code Stores Internal Signal, State, and Parameter Data
- C Code Generation Configuration for Model Interface Elements