create code definitions to control code generation for model data and functions

description

the embedded coder dictionary is a file that you use to store and control the code interface configuration. in the interface configuration, you create custom code interface definitions that define how the generated code interacts with the target platform software on which you deploy the code. by applying the configuration to models, you and your users can generate code that conforms to a specific software architecture by default. for example, you can create your own storage class, which you and your users can apply by default to a category of model data, such as root-level inputs, or to individual data elements, such as parameters.

a dictionary contains only one of these types of interface configurations:

data interface configuration — the code generator creates a program intended to run on the target device. the generated code uses the data interfaces that you define.
service interface configuration — the code generator creates an algorithm that you intend to deploy within a larger application. the platform middleware calls the algorithm code and provides the services for the target device. the generated code calls the services according to your definitions in the service interface configuration. to create a service interface configuration, you must use an embedded coder dictionary that is stored in a simulink data dictionary.

in the interface configuration you can create these types of code interface definitions:

storage classes, which control the code generated for model data.
function customization templates, which control naming of model entry-point functions, such as model_step. the templates also apply memory sections to the entry-point functions.
memory sections, which control the placement of data and functions in memory. the generated code includes custom decorations, such as pragmas, whose syntax you specify.
services, which control how the generated code calls services provided by the target platform software such as data transfer and timer services. service definitions are available only in the service interface configuration.

for general information about creating code generation definitions, see .

the embedded coder^® dictionary has a pane for each type of code definition. use the right pane to configure properties for each definition. to verify results as you configure properties, use the pseudocode preview.

you can apply the definitions that you create in the dictionary to model elements by using the code mappings editor (see ). to create storage classes and memory sections that you can use outside of the code mappings editor, use the custom storage class designer (see ).

open the embedded coder dictionary

to open an embedded coder dictionary, in a model window, open the embedded coder app by opening the apps gallery and clicking embedded coder. 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:
1. 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.
2. 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 model rollaxisautopilot by typing this command:
```
openexample('rollaxisautopilot');
```
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_rollaxisautopilot.h. the file defines the structure type internaldata_t_, whose fields represent block states in the model.

/* storage class 'internalstruct', for system '' */
typedef struct {
  real32_t fixptunitdelay1_dstate;     /* '/fixpt unit delay1' */
  real32_t integrator_dstate;          /* '/integrator' */
  int8_t integrator_prevresetstate;    /* '/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_rollaxisautopilot.c. the file allocates memory for internaldata_.
```
/* 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 and func_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 .

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).

create storage class

open the model rollaxisautopilot by typing this command:
```
openexample('rollaxisautopilot');
```
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.

apply storage class and generate code

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, and rategain in the model workspace.
right-click one of the rows and click convert to parameter object. the model data editor converts the workspace variables to simulink.parameter objects.
in the row for the parameter dispgain, in the storage class column, click configure. the model window highlights the row for the dispgain 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 rollaxisautopilot_my_data.c and rollaxisautopilot_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 the basicrollmode 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 ). those definitions then appear available for selection in the code mappings editor. in this example, you configure the embedded coder dictionary in rollaxisautopilot to refer to definitions stored in the built-in example package ecoderdemos.

open the embedded coder dictionary for rollaxisautopilot. 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, in rollaxisautopilot, 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 .

for an example that shows how to configure default code mappings in a shared embedded coder dictionary, see .

related examples

parameters

these properties appear in the right pane in the embedded coder dictionary window.

storage classes

`name` — 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 .

`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 parameter 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 ).
package name — defined in the simulink package or in a custom package (see ).

`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 .

dependencies

setting this property to pointer:
- sets the preservedimensions property to false. to preserve dimensions of multidimensional arrays in the generated code, set dataaccess to direct or function.
setting this property to function or pointer:
- sets datascope to imported.
- 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 .
- 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

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

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 .

`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 .

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 .

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 .

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
`$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
`$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 .

`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 .

`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 .

`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.

function customization templates

`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 )
`utilityfunction`	in the code mappings editor, use for shared utility functions (see )

`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 parameter 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 ).

`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
`$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 .

memory sections

`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 parameter 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 ).
package name — defined in the simulink package or in a custom package (see ).

`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.

receiver service interfaces

`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`	use this option to 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
`$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.

sender service interfaces

`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`	use this option to 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
`$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

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.

data transfer service interfaces

`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

timer services

`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

dependencies

if you create multiple timer services, use the $g token.
if you set data communication method to outside execution, use the $x token.

parameter tuning interfaces

`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.

parameter argument tuning interfaces

`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.

measurement service interfaces

`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 .

version history

introduced in r2018a

r2022b: create service interface configuration definition with service interfaces

when you create a shared coder dictionary in an sldd file, you create either a data interface configuration or a service interface configuration definition in the dictionary:

service interface configuration — create service interface definitions that describe the interfaces of the services that the platform middleware provides. the generated code uses the service interface definitions to generate calls to the services. you can define these new service interfaces:
- initialize and terminate functions
- periodic and aperiodic functions including model step functions
- receiver service interfaces
- sender service interfaces
- data transfer service interfaces
- timer service interfaces
- parameter tuning service interfaces
- parameter argument tuning service interfaces
- measurement service interfaces
- subcomponent functions
- shared utility functions
in the service interface configuration, you can still define storage classes and memory sections and apply them to service interface definitions.
data interface configuration — the generated code uses the data and function interfaces that you define.

existing embedded coder dictionaries contain a data interface configuration with the code definitions.

r2022b: dictionary refreshes when you load model from earlier release

package-based code definitions have changed. if your embedded coder dictionary refers to code definitions that you store in a package, the dictionary refreshes when you load a model from an earlier release. to prevent the dictionary refresh, resave the model, or the simulink data dictionary that contains the embedded coder dictionary, in the current release.

r2021b: pointer data access for storage classes

when you create an unstructured storage class, you can configure the storage class to use pointer data access. set data scope to imported and set data access to pointer.

r2021a: automatic data initialization for storage classes

for new storage classes, the default data initialization setting is now auto. with this setting, you can apply the same storage class to signals, states, and parameters. the generated code statically initializes parameter data and dynamically initializes signal and state data.

previously, the options for the data initialization setting were limited to dynamic, static, and none.

r2020a: `$r` token for memory sections

you can now use the $r token in the pre statement and post statement for a memory section. $r expands to the model name. previously, you could use only the $n token for memory sections. $n expands to the name of the data element or function.

r2019a: preserve array dimensions in storage classes

to preserve the dimensions of array data that uses a storage class, select the preserve array dimensions property for the storage class.

r2019a: `get` and `set` data access for storage classes

you can now define a storage class for root-level inports, root-level outports, and local parameters so that they can be accessed by customizable get and set functions. set the new data access property to function. you can also configure these new properties:

access mode — whether the access functions return data by value or by pointer
allowed access — whether to allow read and write access, read-only access, or write-only access to the data
name of getter — naming rules for the get functions
name of setter — naming rules for the set functions

r2019a: storage classes with different settings for single-instance and multi-instance data

you can now create storage classes that use different settings for single-instance and multi-instance data. select the new property use different property settings for single-instance and multi-instance data. for single-instance data, you can specify the storage type and structure properties. you can separately specify the structure properties for multi-instance data.

when you apply the storage class to a data item, the embedded coder dictionary implements either the single-instance settings or the multi-instance settings depending on the type of data and the context of the model within the model reference hierarchy.

r2019a: load multiple packages in one dictionary

you can now load and refer to code definitions from multiple packages in one dictionary.

r2019a: use code definitions from local and shared embedded coder dictionaries

when a shared embedded coder dictionary is attached to the model, the model can use the code definitions from both the shared dictionary and the local embedded coder dictionary of the model. the local embedded coder dictionary of the model displays the shared definitions as read-only.

r2018b: restrict mapping of storage classes to parameters or signals

specify whether users can map a storage class to parameters, signals, or parameters and signals. to allow users to map a storage class to each category, select one or both of the new properties parameters and signals.

r2018b: select default definitions in shared embedded coder definitions

for a shared embedded coder dictionary, which is saved in an sldd file, you can select the default code definition for each category of data or functions.

r2018b: pseudocode preview for code definitions

when you create a code definition in the embedded coder dictionary, you can view a pseudocode preview of the code that will generate for the function or data item that uses the code definition.

create code definitions to control code generation for model data and functions -凯发k8网页登录

description

more

open the embedded coder dictionary

examples

create and verify storage class

create function customization template

create storage class for use with statically and dynamically initialized data

refer to code generation definitions in a package

related examples

parameters

name — name of storage class storageclass1 (default) | text

description — purpose and functionality of storage class text

data source — location of storage class definition text

data access — specification to access the data direct (default) | function | pointer

dependencies

data scope — specification to generate data definition exported (default) | imported

dependencies

header file — name of header file that declares data $n.h (default) | text

dependencies

definition file — name of source file that defines data $n.c (default) | text

dependencies

access mode — specification to access data through functions value (default) | pointer

dependencies

allowed access — specification to allow access to data through functions read/write (default) | read only | write only

dependencies

name of getter — name of the get function that fetches the associated data get_$n$m (default) | text

dependencies

name of setter — name of the set function that modifies the associated data set_$n$m (default) | text

dependencies

use different property settings for single-instance and multi-instance data — specification to assign separate storage settings off (default) | on

dependencies

storage type — specification to aggregate data into a structure unstructured (default) | structured

dependencies

type name — name of structure type $r$n$g$m (default) | text

dependencies

instance name — name of structure variable $n$g$m (default) | text

dependencies

data initialization — how to initialize data auto (default) | dynamic | static | none

dependencies

memory section — location in memory to allocate data none (default) | existing memory section

preserve array dimensions — specification to preserve dimensions of multidimensional arrays off (default) | on

const — specification to apply const qualifier off (default) | on

dependencies

volatile — specification to apply volatile qualifier off (default) | on

other qualifier — specification to apply a custom qualifier text

parameters — whether to allow usage with model parameters off (default) | on

dependencies

signals — whether to allow usage with model signals on (default) | off

dependencies

name — name of function template functiontemplate1 (default) | text

description — purpose and functionality of function template text

data source — location of function template definition text

function naming rule — names of generated functions $r$n (default) | text

memory section — location in memory to allocate function none (default) | existing memory section

name — name of memory section text

description — purpose and functionality of memory section text

data source — location of memory section definition text

comment — comment to insert in the generated code text

pre statement — code to insert before data or function code text

post statement — code to insert after data or function code text

statements surround — specification to wrap data and functions separately or in a group each variable (default) | group of variables

name — name of receiver service text

data communication method — how receiver data transmission is handled outside execution (default) | during execution | direct access

function naming rule — names of generated receiver functions text

dependencies

storage class — storage class definition text

dependencies

name — name of sender service text

data communication method — how sender data transmission is handled outside execution (default) | during execution | direct access

function naming rule for value — names of generated sender functions text

dependencies

function naming rule for value by reference — names of generated sender functions that use reference text

dependencies

storage class — storage class definition text

dependencies

name — name of data transfer service text

data communication method — how data transmission is handled outside execution (default) | during execution

receiver function naming rule — names of generated receiver functions text

sender function naming rule — names of generated sender functions text

`name` — name of storage class
`storageclass1` (default) | text

`description` — purpose and functionality of storage class
text

`data source` — location of storage class definition
text

`data access` — specification to access the data
`direct` (default) | `function` | `pointer`

`data scope` — specification to generate data definition
`exported` (default) | `imported`

`header file` — name of header file that declares data
`$n.h` (default) | text

`definition file` — name of source file that defines data
`$n.c` (default) | text

`access mode` — specification to access data through functions
`value` (default) | `pointer`

`allowed access` — specification to allow access to data through functions
`read/write` (default) | `read only` | `write only`

`name of getter` — name of the `get` function that fetches the associated data
`get_$n$m` (default) | text

`name of setter` — name of the `set` function that modifies the associated data
`set_$n$m` (default) | text

`use different property settings for single-instance and multi-instance data` — specification to assign separate storage settings
`off` (default) | `on`

`storage type` — specification to aggregate data into a structure
`unstructured` (default) | `structured`

`type name` — name of structure type
`$r$n$g$m` (default) | text

`instance name` — name of structure variable
`$n$g$m` (default) | text

`data initialization` — how to initialize data
`auto` (default) | `dynamic` | `static` | `none`

`memory section` — location in memory to allocate data
`none` (default) | existing memory section

`preserve array dimensions` — specification to preserve dimensions of multidimensional arrays
`off` (default) | `on`

`const` — specification to apply `const` qualifier
`off` (default) | `on`

`volatile` — specification to apply `volatile` qualifier
`off` (default) | `on`

`other qualifier` — specification to apply a custom qualifier
text

`parameters` — whether to allow usage with model parameters
`off` (default) | `on`

`signals` — whether to allow usage with model signals
`on` (default) | `off`

`name` — name of function template
`functiontemplate1` (default) | text

`description` — purpose and functionality of function template
text

`data source` — location of function template definition
text

`function naming rule` — names of generated functions
`$r$n` (default) | text

`memory section` — location in memory to allocate function
`none` (default) | existing memory section

`name` — name of memory section
text

`description` — purpose and functionality of memory section
text

`data source` — location of memory section definition
text

`comment` — comment to insert in the generated code
text

`pre statement` — code to insert before data or function code
text

`post statement` — code to insert after data or function code
text

`statements surround` — specification to wrap data and functions separately or in a group
`each variable` (default) | `group of variables`

`name` — name of receiver service
text

`data communication method` — how receiver data transmission is handled
`outside execution` (default) | `during execution` | `direct access`

`function naming rule` — names of generated receiver functions
text

`storage class` — storage class definition
text

`name` — name of sender service
text

`data communication method` — how sender data transmission is handled
`outside execution` (default) | `during execution` | `direct access`

`function naming rule for value` — names of generated sender functions
text

`function naming rule for value by reference` — names of generated sender functions that use reference
text

`storage class` — storage class definition
text

`name` — name of data transfer service
text

`data communication method` — how data transmission is handled
`outside execution` (default) | `during execution`

`receiver function naming rule` — names of generated receiver functions
text

`sender function naming rule` — names of generated sender functions
text

`name` — name of timer service
text

`data communication method` — how data transmission is handled
`outside execution` (default) | `during execution`

`function clock tick function naming rule` — clock tick function naming rule
text

`name` — name of parameter tuning service
text

`storage class` — storage class definition
text

`name` — name of parameter argument tuning service
text

`storage class` — storage class definition
text

`name` — name of measurement service
text

`storage class` — storage class definition
text

r2020a: `$r` token for memory sections

r2019a: `get` and `set` data access for storage classes