Code Definition and Mapping Limitations and Considerations
If a data element in a model is unnamed (for example, a signal has no label or a state has no name), you must specify a code identifier for the data element when configuring it for C code generation. Set the code identifier by specifying a value for the storage class property Identifier.
You cannot use code mappings to configure MATLAB® variables that are used as block parameters. Convert the variables to
Simulink.Parameterobjects in the model workspace. The resulting data objects appear in the Code Mappings editor as model parameters.
Use code mappings to configure only one discrete state per block in a model.
To map these data categories to a storage class defined in an Embedded Coder Dictionary, you must set the storage class property Data Initialization to
Signals, states, and internal data
Shared local data stores
You cannot map data categories External parameters and Global data stores. For referenced models you cannot map data categories Inports and Outports to structured storage classes that are defined in an Embedded Coder Dictionary.
You cannot map categories of data to:
Predefined structure-based storage classes,
Package storage classes of type
Otherthat you create by using the Custom Storage Class Designer
If you configure a model to use a code replacement library that includes a data alignment specification, you cannot configure default code mappings that involve storage classes defined in the Embedded Coder Dictionary for that model. For more information, see Data Alignment for Code Replacement.
If a model contains a tunable, nonfinite parameter, for example, with a value of
The code generator does not apply a specified default parameter mapping. The parameter appears as a field in the default parameter data structure
rtP(see Real-Time Model Data Structure).
You cannot map an individual element to a storage class defined in an Embedded Coder Dictionary. If you do, the code generator returns an error. Choose one of these workarounds:
For the individual nonfinite parameter, set the storage class to a value other than
Model default, as described in Configure Parameters for C Code Generation.
If only one block uses the variable or object, instead of using the variable or object, specify the nonfinite value directly in the model, in the block parameter.
Default Code Mapping Constraints
Map parameter categories to storage classes that are defined with the Data Initialization property set to
If a model includes a reusable subsystem (a subsystem that has the block parameter Function packaging set to
Reusable function) that contains a shared local data store, map the category Shared local data stores to a storage class that is defined in the Embedded Coder Dictionary for that model. For more information, see Generate Reentrant Code from Subsystems.
For top and referenced models configured for multi-instance use, map data categories to storage classes that have the Storage Type property set to
Structured. See Generate Reentrant Code from Top Models and Generate Reentrant Code from Simulink Function Blocks.
Default code mappings for categories External parameters and Global data stores must be the same for models throughout the model reference hierarchy.
When a model is configured for compact file packaging, you cannot map a data category to a storage class defined with the Data Scope property set to
Exportedand the Header File property set to a naming rule other than
When evaluating storage class settings for variant control variables, the code generator ignores default code mappings. For more information, see Represent Subsystem and Variant Models in Generated Code.
Unresolved Code Definitions
If someone removes the definition for a storage class, function customization
template, or memory section from the Embedded Coder Dictionary associated with a model,
the Code Mappings editor identifies the definition as
example, this figure shows that the function customization template for execution
entry-point functions was removed from the dictionary associated with the model.
To fix the unresolved code definition, do one of the following:
Select a different definition in the Storage Classes, Function Customization Templates, or Memory Sections column.
If you have Embedded Coder®, replace or add a definition to the Embedded Coder Dictionary. Then, update the mapping.
Consult with someone, such as the system architect for your project, about adding a definition to the Embedded Coder Dictionary. Then, update the mapping.
Model Editing Operations and Individual Data Element Code Mappings
While editing a model in the context of a coder app, you should be aware of the relationship between Simulink® model editing tools, such as copy and undo, and code mappings. In the context of a coder app, when you perform copy-and-paste or cut-and-paste editing operations within a model, the coder app preserves the code mappings for individual data elements. For example, within a model, if you copy and paste the source block of a signal that is configured with a specific storage class, the pasted version of the signal port retains the same storage class.
While you can use undo and redo operations for editing actions on model data elements,
they are unavailable while configuring code mappings. For example, if you delete a state
block, and then click Undo, the block reappears in the model canvas
and the code configuration for the state reappears in the code mappings. In the Code
Mappings editor, if you change the storage class setting for a state from
Model default, and then click
Undo, the storage class does not revert to
Auto. In this case, the change pertains to the code mapping, not
to the model data element.
Storage Classes and Reentrant, Multi-Instance Models and Components
The code that you generate from a model or component (referenced model or subsystem)
is multi-instance code if it allows your application to maintain
multiple independent instances of the component during execution. For example, you can
generate reentrant, multi-instance code from an entire model by setting the model
configuration parameter Code interface packaging to
Reusable function. For general information about
multi-instance models and components, see Model Composition and Reuse.
Under some circumstances, applying storage classes can:
Prevent you from generating multi-instance code.
Cause some data elements to appear in the generated code as singletons, which means that each instance of the model or component directly accesses the same shared, global data, creating dependencies between the instances.
To avoid errors and unexpected generation of single-instance code and singleton data, observe the guidelines and limitations below.
Directly Applied Storage Classes
When you apply a storage class directly to a data element (see C Data Code Interface Configuration for Model Interface Elements):
To generate multi-instance code, you must apply the storage class only to parameter objects, global data stores, shared local data stores, and root-level I/O.
The storage class yields only singleton data.
Storage Classes Applied by Default
When you apply a default storage class (see C Data Code Interface Configuration for Model Interface Elements):
For these data categories, you can generate only singleton data:
Global data stores
Shared local data stores
For Internal data, you can generate only instance-specific data, which means each instance of the model or component operates on a separate copy of the data. For this category, you must use the example storage class
SignalStruct, which appears after preparing a model for code generation with the Quick Start tool. Alternatively, you can create and use your own structured storage class by using an Embedded Coder Dictionary.
For more information, see What Is Reentrant Code? and Choose Storage Class for Controlling Data Representation in Generated Code.
Copy Code Mappings When Converting Subsystems to Referenced Models
You can copy code mappings when you convert a subsystem to a referenced model.