Embedded Coder Dictionary
Create code definitions to control code generation for model data and functions
Open the Embedded Coder Dictionary
To open an Embedded Coder Dictionary, in a model window, on the C Code tab, select Code Interface > Embedded Coder Dictionary. The Embedded Coder Dictionary window displays the code interface configuration that is stored in the dictionary.
To open the Embedded Coder Dictionary in a Simulink® data dictionary, in the Model Explorer Model Hierarchy pane:
Under the dictionary node, select the Embedded Coder node.
If you do not see the node, right-click the dictionary node and select Show Empty Sections.
In the Dialog pane (the right pane), click Open Embedded Coder Dictionary.
Examples
Create and Verify Storage Class
In a model, create a storage class that aggregates internal model data, including block states, into a structure whose characteristics you can control. Then, verify the storage class by generating code from the model.
Open the example model
rtwdemo_roll
.rtwdemo_roll
If the model does not open in the Embedded Coder app, open the app and click the C Code tab.
On the C Code tab, select Code Interface > Embedded Coder Dictionary. The Embedded Coder Dictionary window displays code generation definitions that are stored in the model file.
On the left pane, click Storage Class. In the Storage Classes section, click Create.
Select the new storage class that appears at the bottom of the list,
StorageClass1
. In the pane on the right, set the property values listed in this table.Property Value Name InternalStruct
Header File internalData_$R.h
Definition File internalData_$R.c
Storage Type Structured
Structure Properties > Type Name internalData_T_$M
Structure Properties > Instance Name internalData_$M
After making your changes, in the bottom pane, verify that the pseudocode preview reflects what you expect.
Return to the model editor. To open the Interface editor, below the canvas, double-click Code Mappings. On the Data Defaults tab, expand the Signals section. Select the Signals, states, and internal data row and set Storage Class to
InternalStruct
.In the Configuration Parameters dialog box, on the Code Generation > Code Placement pane, set File packaging format to
Modular
.Generate code.
In the Simulink Editor Code view, open and inspect the file
internalData_rtwdemo_roll.h
. The file defines the structure typeinternalData_T_
, whose fields represent block states in the model./* Storage class 'InternalStruct', for system '<Root>' */ typedef struct { real32_T FixPtUnitDelay1_DSTATE; /* '<S7>/FixPt Unit Delay1' */ real32_T Integrator_DSTATE; /* '<S1>/Integrator' */ int8_T Integrator_PrevResetState; /* '<S1>/Integrator' */ } internalData_T_;
The file also declares a global structure variable named
internalData_
./* Storage class 'InternalStruct' */ extern internalData_T_ internalData_;
Open and inspect the file
internalData_rtwdemo_roll.c
. The file allocates memory forinternalData_
./* Storage class 'InternalStruct' */ internalData_T_ internalData_;
Create Function Customization Template
With a function template, you can specify a rule that governs the names of generated entry-point functions. This technique helps save time and maintenance effort in a model that has many entry-point functions, such as an export-function model or a multirate, multitasking model.
This example shows how to create a function template that specifies the naming
rule func_$N_$R
. $N
is the base name of each
generated function and $R
is the name of the Simulink model.
Open the example model
rtwdemo_mrmtbb
.Update the block diagram. This multitasking model has two execution rates, so the generated code includes two corresponding entry-point functions.
In the model, set model configuration parameter System target file to
ert.tlc
. To use a function customization template, you must use an ERT-based system target file.In the Simulink Editor, open the Embedded Coder app and open the Embedded Coder Dictionary.
In the Embedded Coder Dictionary, on the Function Customization Template tab, click Create.
For the new function template, set these properties:
Name to
myFunctions
.Function Name to
func_$N_$R
.
After making your changes, verify that the pseudocode preview reflects what you expect.
In the model window, open the Code Mappings editor. On the Function Defaults tab, for the Initialize/Terminate and Execution rows, set Function Customization Template to
myFunctions
.Generate code.
In the Code view, open and inspect the file
rtwdemo_mrmtbb.c
. The file defines the two execution functions,func_step0_rtwdemo_mrmtbb
andfunc_step1_rtwdemo_mrmtbb
, whose names conform to the rule that you specified in the function template.
For an example that shows how to create a memory section, see Control Data and Function Placement in Memory by Inserting Pragmas.
Create Storage Class for Use with Statically and Dynamically Initialized Data
This example shows how to create a storage class that places global variable definitions and declarations in files whose names depend on the model name. You create two copies of the storage class so that you can use one copy with parameter data (the data category Model parameters) and one copy with other data.
Typically, the generated code initializes parameter data statically, outside any function, and initializes other data dynamically, in the model initialization function. When you create a storage class by using the Custom Storage Class Designer or an Embedded Coder Dictionary, you set the Data Initialization property to specify the initialization mechanism.
In an Embedded Coder Dictionary, for each storage class, you must select
Static
or Dynamic
initialization. Consider creating one copy of the storage class for parameter data
(Static
) and one copy for other data
(Dynamic
).
Open example model
rtwdemo_roll
.If the C Code tab is not open, open the Embedded Coder app and click the C Code tab.
Select Code Interface > Embedded Coder Dictionary
On the left pane, click Storage Class. In the Storage Classes section, click Create.
For the new storage class, set these properties:
Name to
SigsStates
Header File to
$R_my_data.h
Definition File to
$R_my_data.c
Data Initialization to
Dynamic
After making your changes, verify that the pseudocode preview reflects what you expect.
Place your cursor over the row for the storage class SigsStates and click Duplicate code definition. A new storage class,
SigsStates_copy
, appears.For the new storage class, set these properties:
Name to
Params
Data Initialization to
Static
Verify that the pseudocode preview reflects what you expect.
In the model, open the Code Mappings editor. Below the model canvas, double-click Code Mappings - Component Interface.
On the Data Defaults tab, for the Parameters > Model Parameters row, in the Storage Class column, select
Params
.For the Signals > Signals, states, and internal data row, set Storage Class to
SigsStates
.Configure some parameter data elements in the model so that optimizations do not eliminate those elements from the generated code. On the Modeling tab, click Design > Model Workspace.
In the Model Explorer, on the center pane, select the three rows that correspond to the variables
dispGain
,intGain
, andrateGain
in the model workspace.Right-click one of the rows and click
Convert to parameter object
. The Model Data Editor converts the workspace variables toSimulink.Parameter
objects.In the row for the parameter
dispGain
, in the Storage Class column, click Configure. The model window highlights the row for thedispGain
parameter in the Code Mappings editor.For each variable, in the Storage Class column, select
Model default: Params
, which means that they acquire the default storage class that you specified for Model parameters.In the Configuration Parameters dialog box, on the Code Generation > Code Placement pane, set File packaging format to
Modular
.Generate code.
In the Code view, open and inspect the files
rtwdemo_roll_my_data.c
andrtwdemo_roll_my_data.h
. These files define and declare global variables that correspond to the parameter objects and some block states, such as the state of the Integrator block in theBasicRollMode
subsystem./* Storage class 'SigsStates' */ real32_T rtFixPtUnitDelay1_DSTATE; real32_T rtIntegrator_DSTATE; int8_T rtIntegrator_PrevResetState; /* Storage class 'Params' */ real32_T dispGain = 0.75F; real32_T intGain = 0.5F; real32_T rateGain = 2.0F;
Refer to Code Generation Definitions in a Package
You can configure an Embedded Coder Dictionary to refer to code generation
definitions that you store in a package (see Create Code Definitions for External Data Objects). Those
definitions then appear available for selection in the Code Mappings editor. In this
example, you configure the Embedded Coder Dictionary in
rtwdemo_roll
to refer to definitions stored in the built-in
example package ECoderDemos
.
Open the Embedded Coder Dictionary for
rtwdemo_roll
. For instructions, see Create and Verify Storage Class.In the Embedded Coder Dictionary window, on the Memory tab, click Manage Packages.
In the Manage Packages dialog box, click Refresh. Wait until more options appear in the Select package drop-down list.
Set Select package to
ECoderDemos
and click Load.In the Embedded Coder Dictionary window, on the Storage Classes tab, the table shows the storage classes defined in the
ECoderDemos
package. Now, inrtwdemo_roll
, you can select these storage classes in the Code Mappings editor on the Data Defaults tab.To unload the package, in the Manage Packages dialog box, select the package in the Select package drop-down list and click Unload.
For an example that shows how to share code generation definitions between models by using data dictionaries, see Share Code Interface Configuration Between Models.
For an example that shows how to configure default code mappings in a shared Embedded Coder Dictionary, see Configure Default Code Mapping in a Shared Dictionary.
Related Examples
- Define Service Interfaces, Storage Classes, Memory Sections, and Function Templates for Software Architecture
- Deploy Code Generation Definitions
- Generate Code to Conform to Software Architecture by Sharing and Copying Default Settings Between Models
- Flexible Storage Class for Different Model Hierarchy Contexts
Parameters
These properties appear in the right pane in the Embedded Coder Dictionary window.
Storage ClassesName
— Name of storage class
StorageClass1
(default) | text
Name of the storage class. The name must be unique among the storage classes in the dictionary.
For lists of built-in and example storage classes that Simulink provides, see Choose Storage Class for Controlling Data Representation in Generated Code.
Description
— Purpose and functionality of storage class
text
Custom text that you can use to describe the purpose and functionality of the storage class.
Data Source
— Location of storage class definition
text
This property is read-only.
The location of the storage class definition.
Built-in
— Provided by Simulink.Model name — Defined in a Simulink model.
Dictionary name — Defined in a Simulink data dictionary (see What Is a Data Dictionary?).
Package name — Defined in the Simulink package or in a custom package (see Create Storage Classes by Using the Custom Storage Class Designer).
Data Access
— Specification to access the data
Direct
(default) | Function
| Pointer
Specification to access data associated with the model. Access the data
directly (Direct
), through customizable
get
and set
functions
(Function
), or by using a pointer
(Pointer
). For more information, see Access Data Through Functions by Using Storage Classes in Embedded Coder Dictionary.
Dependencies
Setting this property to
Pointer
:Sets the
PreserveDimensions
property tofalse
. To preserve dimensions of multidimensional arrays in the generated code, setDataAccess
toDirect
orFunction
.
Setting this property to
Function
orPointer
:Sets
DataScope
toImported
.Means that you cannot specify multi-instance properties.
In addition, setting this property to Function
enables these properties:
AccessMode
AllowedAccess
GetFunctionName
SetFunctionName
Data Scope
— Specification to generate data definition
Exported
(default) | Imported
Specification that the generated code define the data
(Exported
) or import (Imported
)
the data definition from external code. Built-in storage classes and storage
classes in packages such as Simulink can use other scope options, such as
File
.
Dependencies
Setting this property to
Imported
:Disables Definition File. To include your external source code file in the build process, use model configuration parameters. For an example, see Configure Data Interface.
Means that you cannot set Header File to
$N.h
, though you can use the$N
token.
To set this property to
Exported
, you must use one of the tokens$N
or$R
in the value of Header File.
Header File
— Name of header file that declares data
$N.h
(default) | text
Name of the header file that declares the data, specified as a name or naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Name of associated data element |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
If you set Data Scope to
Exported
, you must use one of the tokens$R
or$N
in the value of this property.If you set Data Scope to
Imported
, you cannot set the value of this property to$N.h
, but you can use the$N
token.
Definition File
— Name of source file that defines data
$N.c
(default) | text
Name of the source file that defines the data, specified as a name or naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Name of associated data element |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
Setting Data Scope to
Imported
disables Definition
File. To include your external source code file in the
build process, use model configuration parameters. For an example, see
Configure Data Interface.
Access Mode
— Specification to access data through functions
Value
(default) | Pointer
Specification for the storage class to access data associated with the
model through functions by using Value
or
Pointer
. For more information, see Access Data Through Functions by Using Storage Classes in Embedded Coder Dictionary.
Dependencies
This property is enabled only when you set Data
Access to Function
.
Allowed Access
— Specification to allow access to data through functions
Read/Write
(default) | Read Only
| Write Only
Specification for the storage class to allow read and write
(Read/Write
), read-only (Read
Only
), or write-only (Write Only
) access to the
data.
Dependencies
This property is enabled only when you set Data
Access to Function
.
Name of Getter
— Name of the get
function that fetches the associated data
get_$N$M
(default) | text
Name of the get
function that fetches the associated
data, specified as a name or naming rule. A naming rule includes a
combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$N | Name of associated data element (required) |
$R | Name of root model |
$M | Mangle text that ensures uniqueness |
$U | User token text. See Identifier Format Control. |
Dependencies
This property is enabled only when you set Data
Access to Function
.
Name of Setter
— Name of the set
function that modifies the associated data
set_$N$M
(default) | text
Name of the set
function that fetches the modifies
data, specified as a name or naming rule. A naming rule includes a
combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$N | Name of associated data element (required) |
$R | Name of root model |
$M | Mangle text that ensures uniqueness |
$U | User token text. See Identifier Format Control. |
Dependencies
This property is enabled only when you set Data
Access to Function
.
Use different property settings for single-instance and multi-instance data
— Specification to assign separate storage settings
off
(default) | on
Specification for the storage class to use either the storage settings that you specify in the Single-instance storage section or the storage settings that you specify in the Multi-instance storage section. When you apply the storage class to a data item, the Embedded Coder Dictionary determines if it is a single-instance storage class or a multi-instance storage class by the type of data and by the context of the model within the model reference hierarchy.
Dependencies
Selecting this property enables the sections Single-instance storage and Multi-instance storage. The properties Storage Type, Type Name, and Instance Name appear in both the Single-instance storage and Multi-instance storage sections.
Storage Type
— Specification to aggregate data into a structure
Unstructured
(default) | Structured
Specification to aggregate the data that uses the storage class into a
structure in the generated code. Each data element appears in the code as a
field of the structure. To create a structure, use
Structured
.
Dependencies
Setting this property to Structured
enables
Type Name and Instance
Name.
Type Name
— Name of structure type
$R$N$G$M
(default) | text
Name of the structure type in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as
step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting Storage Type to
Structured
enables this property.
Instance Name
— Name of structure variable
$N$G$M
(default) | text
Name of the structure variable in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as
step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting Storage Type to
Structured
enables this property.
Data Initialization
— How to initialize data
Auto
(default) |
Dynamic
| Static
|
None
Specification that the generated code initialize the data.
Auto
— The generated code statically initializes parameter data and dynamically initializes signal and state data.Dynamic
— The generated code initializes the data as part of the model initialization entry-point function.Static
— The generated code initializes the data in the same statement that defines and allocates memory for the data. The assignment statement appears at the top of a.c
or.cpp
source file, outside of a function.None
— The generated code does not initialize the data.
Dependencies
If you select Const, you cannot set this property to
Dynamic
.Setting this property to
Dynamic
disables Const.
Memory Section
— Location in memory to allocate data
None
(default) | existing memory section
Location in memory to allocate data, specified as a memory section that exists in the Embedded Coder Dictionary on the Memory Sections tab. For information about memory sections, see Control Data and Function Placement in Memory by Inserting Pragmas.
Preserve array dimensions
— Specification to preserve dimensions of multidimensional arrays
off
(default) | on
Specification for the storage class to preserve dimensions of multidimensional arrays in the generated code. For more information, see Preserve Dimensions of Multidimensional Arrays in Generated Code.
Const
— Specification to apply const
qualifier
off
(default) | on
Specification to apply the const
qualifier to the
data.
Dependencies
If you select this property, you cannot set Data Initialization to
Dynamic
.Setting Data Initialization to
Dynamic
disables this property.
Volatile
— Specification to apply volatile
qualifier
off
(default) | on
Specification to apply the volatile
qualifier to the
data.
Other Qualifier
— Specification to apply a custom qualifier
text
Specification to apply a custom qualifier to the data. For example, some
memory architectures support qualifiers far
and
huge
.
Do not use this property to apply the keyword static
.
Instead, use the built-in storage class FileScope
, which
you cannot apply with the Code Mappings editor. See Choose Storage Class for Controlling Data Representation in Generated Code.
Parameters
— Whether to allow usage with model parameters
off
(default) | on
Specification indicating whether to allow usage of the storage class with model parameters.
Dependencies
Setting Data Initialization to
Static
enables this property.Setting Data Initialization to
Dynamic
disables this property.To set the value of this property, set Data Initialization to
None
.
Signals
— Whether to allow usage with model signals
on
(default) | off
Specification indicating whether to allow usage of the storage class with model signals.
Dependencies
Setting Data Initialization to
Dynamic
enables this property.Setting Data Initialization to
Static
disables this property.To set the value of this property, set Data Initialization to
None
.
Name
— Name of function template
FunctionTemplate1
(default) | text
Name of the template. The name must be unique among the function templates in the dictionary. Embedded Coder provides the built-in templates listed in this table.
Template | Description |
---|---|
ModelFunction | In the Code Mappings editor, use for entry-point functions for initialization, execution, termination, and reset (see Configure Default Code Generation for Functions) |
UtilityFunction | In the Code Mappings editor, use for shared utility functions (see Configure Default Code Generation for Functions) |
Description
— Purpose and functionality of function template
text
Custom text that you can use to describe the purpose and functionality of the function template.
Data Source
— Location of function template definition
text
This property is read-only.
The location of the function template definition.
Model name — Defined in a Simulink model.
Dictionary name — Defined in a Simulink data dictionary (see What Is a Data Dictionary?).
Function Naming Rule
— Names of generated functions
$R$N
(default) | text
Names of the functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as
step |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$C | For shared utility functions, a checksum inserted to avoid name collisions |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Memory Section
— Location in memory to allocate function
None
(default) | existing memory section
Location in memory to allocate function, specified as a memory section that exists in the Embedded Coder Dictionary on the Memory Sections tab. For information about memory sections, see Control Data and Function Placement in Memory by Inserting Pragmas.
Name
— Name of memory section
text
Name of the memory section. The name must be unique among the memory sections in the dictionary. Embedded Coder provides the built-in memory sections listed in this table.
Memory Section | Description |
---|---|
MemConst | Apply the storage type qualifier const
to the data. |
MemVolatile | Apply the storage type qualifier
volatile to the data. |
MemConstVolatile | Apply the storage type qualifiers
const and volatile
to the data. |
Description
— Purpose and functionality of memory section
text
Custom text that you can use to describe the purpose and functionality of the memory section.
Data Source
— Location of memory section definition
text
This property is read-only.
The location of the memory section definition.
Model name — Defined in a Simulink model.
Dictionary name — Defined in a Simulink data dictionary (see What Is a Data Dictionary?).
Package name — Defined in the Simulink package or in a custom package (see Create Code Definitions for External Data Objects).
Comment
— Comment to insert in the generated code
text
Code comment that the code generator includes with the pragmas or other decorations that you specify with Pre Statement and Post Statement.
Pre Statement
— Code to insert before data or function code
text
Code, such as pragmas, to insert before the definitions and declarations of the data or functions that are in the memory section.
You can use the token $R
to represent the name of the
model that uses the memory section.
When you set Statements Surround to Each
variable
, you can use the token $N
to
represent the name of each variable or function that uses the memory
section.
Post Statement
— Code to insert after data or function code
text
Code, such as pragmas, to insert after the definitions and declarations of the data or functions that are in the memory section.
You can use the token $R
to represent the name of the
model that uses the memory section.
When you set Statements Surround to Each
variable
, you can use the token $N
to
represent the name of each variable or function that uses the memory
section.
Statements Surround
— Specification to wrap data and functions separately or in a group
Each variable
(default) | Group of variables
Specification to insert code statements (Pre Statement and Post Statement):
Around each variable and function that uses the memory section. Select
Each variable
.Once, around the entire memory section. The generated code aggregates the variable and function definitions into a contiguous code block and surrounds the block with the statements. Select
Group of variables
.
Name
— Name of receiver service
text
Name of the receiver service. Embedded Coder provides the example services listed in this table.
Receiver Service | Description |
---|---|
ReceiverExample1 | Favor memory optimization over data freshness. The service reads data from another function before the function starts executing. |
ReceiverExample2 | Favor data freshness over memory optimization. The service reads data from another function immediately during execution. |
ReceiverExample3 | Maximize performance of component code or if mutual exclusion is inherent in component model design. The platform service reads data from generated function code directly by using memory that platform services manage for the target execution environment. |
Data Communication Method
— How receiver data transmission is handled
Outside Execution
(default) | During Execution
| Direct Access
How receiver data transmission is handled between the target platform service and the run-time environment, specified as one of these options:
Outside Execution
— Read data from another function before the function starts executing. Use this option to favor memory optimization over data freshness.During Execution
— Read data from another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.Direct Access
— Read data from generated function code directly by using memory that platform services manage. Use this option to maximize performance of component code or if mutual exclusion is inherent in component model design.
Function Naming Rule
— Names of generated receiver functions
text
Names of the receiver functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$N | Element name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted to avoid name collisions |
Dependencies
To specify a function naming rule, you must set Data
Communication Method to Outside
Execution
or During Execution
.
Storage Class
— Storage class definition
text
Storage class definition, specified as one of the definitions in the Storage Class section of the dictionary.
Dependencies
To specify a storage class receiver services, you must set
Data Communication Method to Direct
Access
.
Name
— Name of sender service
text
Name of the sender service. Embedded Coder provides the example services listed in this table.
Sender Service | Description |
---|---|
SenderExample1 | Favor data freshness over memory optimization. The platform service reads data from another function immediately during execution. |
SenderExample2 | Favor memory optimization over data freshness. The service sends data to another function after the function executes. |
SenderExample3 | Maximize performance of component code or if mutual exclusion is inherent in component model design. The platform service reads data from generated function code directly by using memory that platform services manage for the target execution environment. |
Data Communication Method
— How sender data transmission is handled
Outside Execution
(default) | During Execution
| Direct Access
How sender data transmission is handled between the task and the run-time environment, specified as one of these options:
Outside Execution
— Send data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.During Execution
— Send data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.Direct Access
— Send data to generated function code directly by using memory that platform services manage. Use this option to maximize performance of component code or if mutual exclusion is inherent in component model design.
Function Naming Rule for Value
— Names of generated sender functions
text
Names of the sender functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$N | Element name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted to avoid name collisions |
Dependencies
To specify a function naming rule, you must set Data
Communication Method to Outside
Execution
or During Execution
.
Function Naming Rule for Value by Reference
— Names of generated sender functions that use reference
text
Names of the sender functions that send a value by reference in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
To specify a function naming rule, the definition must be a data
sender service and you must set Data Communication
Method to Outside Execution
or
During Execution
.
Storage Class
— Storage class definition
text
Storage class definition, specified as one of the definitions in the Storage Class section of the dictionary.
Dependencies
To specify a storage class receiver services, you must set
Data Communication Method to Direct
Access
.
Name
— Name of data transfer service
text
Name of the data transfer service. Embedded Coder provides the example services listed in this table.
Data Transfer Service | Description |
---|---|
DataTransferExample1 | Favor data freshness over memory optimization. The platform service reads data from another function immediately during execution. |
DataTransferExample2 | Favor memory optimization over data freshness. The service receives and sends data from another function outside of function execution. |
Data Communication Method
— How data transmission is handled
Outside Execution
(default) | During Execution
How data transmission is handled between the task and the run-time environment, specified as one of these options:
Outside Execution
— Communicate data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.During Execution
— Communicate data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.
Receiver Function Naming Rule
— Names of generated receiver functions
text
Names of the receiver functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Element name |
$X | Current callable function |
$M | Name-mangling text inserted to avoid name collisions |
Sender Function Naming Rule
— Names of generated sender functions
text
Names of the sender functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Element name |
$X | Current callable function |
$M | Name-mangling text inserted to avoid name collisions |
Name
— Name of timer service
text
Name of the timer service. Embedded Coder provides the example service listed in this table.
Timer Service | Description |
---|---|
TimerServiceExample1 | The timer service executes outside of function execution. |
Data Communication Method
— How data transmission is handled
Outside Execution
(default) | During Execution
How data transmission is handled between the task and the run-time environment, specified as one of these options:
Outside Execution
— Communicate data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.During Execution
— Communicate data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.
Function Clock Tick Function Naming Rule
— Clock tick function naming rule
text
Names of the clock tick functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$G | Service name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
If you create multiple timer services, use the
$G
token.If you set Data Communication Method to
Outside Execution
, use the$X
token.
Name
— Name of parameter tuning service
text
Name of the parameter tuning service. Embedded Coder provides the example service listed in this table.
Parameter Tuning Service | Description |
---|---|
ParameterTuningExample1 | Service for tuning parameters. |
Storage Class
— Storage class definition
text
Storage class definition, specified as one of the definitions in the Storage Class section of the dictionary.
Name
— Name of parameter argument tuning service
text
Name of the parameter argument tuning service. Embedded Coder provides the example service listed in this table.
Parameter Argument Tuning Service | Description |
---|---|
ParameterArgumentTuningExample1 | Service for tuning parameter arguments. |
Storage Class
— Storage class definition
text
Storage class definition, specified as one of the definitions in the Storage Class section of the dictionary.
Name
— Name of measurement service
text
Name of the measurement service. Embedded Coder provides the example service listed in this table.
Measurement Service | Description |
---|---|
MeasurementExample1 | Service for measuring signals. |
Storage Class
— Storage class definition
text
Storage class definition, specified as one of the definitions in the Storage Class section of the dictionary.
Limitations
A storage class or function customization template that you create in an Embedded Coder Dictionary cannot use a memory section that you load from a package (as described in Refer to Code Generation Definitions in a Package). Use a memory section defined in the Embedded Coder Dictionary.
A storage class that you create in an Embedded Coder Dictionary that has
Function
data access is not supported for the storage class of a data store, parameter argument tuning interface, or measurement interface.You cannot create code generation definitions in a
.mdl
model file.
For additional limitations for code generation definitions in the Embedded Coder
Dictionary of a data dictionary (.sldd
file), see Deploy Code Generation Definitions.