Manage Replacement of Simulink Data Types in Generated Code
You can use the Data type replacement configuration parameter to control the replacement of Simulink® data types in generated code:
If you set the parameter to
Use C data types with fixed-width integers
, the generated code uses data types from the C99 language standard, which includes definitions fromstdint.h
andstdbool.h
. See C99 Data Types in Generated Code.The generated code does not include the rtwtypes.h header file. The file
rtwtypes.h
is generated in some cases because it might be needed by static source code located undermatlabroot
. Additionally, if you use custom code that requires Simulink Coder™ data type definitions, you can force the generation ofrtwtypes.h
by selecting the Coder typedefs compatibility check box.If you set the parameter to
Use coder typedefs
, the code generator creates the header filertwtypes.h
and generates data types that are based on the C89 language standard. Thertwtypes.h
file defines the data types throughtypedef
statements that build on C primitive types, for example,float
andshort
. If you also select the Specify custom data type names check box, you can specify replacement names for the Simulink Coder data types. See Control Names of Simulink Coder Primitive Data Types.
By default, the generated code aggregates signal, block parameter, and state data into structures (see How Generated Code Exchanges Data with an Environment and How Generated Code Stores Internal Signal, State, and Parameter Data). You can specify a naming rule for the structure types. You can also place data items into separate custom structures and specify names for the custom structure types. See Control Names of Structure Types.
Use the naming control to:
Conform to coding standards. For an example, see Replace and Rename Simulink Coder Data Types to Conform to Coding Standards.
Integrate the generated code with your external code. For an example, see Exchange Structured and Enumerated Data Between Generated and External Code.
Make the generated code more readable and meaningful.
You can also reuse data type definitions in generated code, for example,
typedef
statements from external code. See Generate Code That Reuses Data Types From External Code.
C99 Data Types in Generated Code
When the Data type replacement configuration parameter is set
to Use C data types with fixed-width integers
, the code
generator replaces Simulink data types with C99 data types as shown in this table.
Simulink Name | Code Generation Name |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You cannot specify replacements for the generated data type names.
Control Names of Simulink Coder Primitive Data Types
To rename a Simulink
Coder primitive data type such as int8_T
, create a
Simulink.AliasType
object whose name matches the type name that
you want the generated code to use. For example, to create a type named
myType
, at the command prompt, enter:
myType = Simulink.AliasType;
Set the BaseType
property to the name of the Simulink data type that corresponds to the target Simulink
Coder data type. For example, if the target type is
int8_T
, specify int8
. To identify the
Simulink data type, use the information in the table.
Simulink Coder Type Name | Corresponding Simulink Type Name |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For configuring data type replacement throughout an entire model (Configuration Parameters > Code Generation > Data Type Replacement), you can alternatively use one of these types:
|
|
|
|
|
|
|
|
|
|
|
* n
must be 8, 16, 32, or 64.
Note
The boolean_T
BaseType
must promote to a signed
int
.
For example, to replace the type name uint8_T
with
myType
, set the BaseType
property of the
Simulink.AliasType
object to 'int8'
.
myType.BaseType = 'int8';
Then, use one or both of these techniques to apply the type to data items in a model:
Configure data type replacements. Throughout the code that you generate from a model, you can replace a Simulink Coder data type name with the name of the
Simulink.AliasType
object. You configure data type replacements through model configuration parameters (Configuration Parameters > Code Generation > Data Type Replacement.For an example that shows how to use data type replacement, see Replace and Rename Simulink Coder Data Types to Conform to Coding Standards.
Use the name of the
Simulink.AliasType
object to specify the data type of an individual signal, that is, a block output, or block parameter. By default, due to data type propagation and inheritance (see Data Type Inheritance Rules), the signals, states, and parameters of other downstream blocks typically inherit the same data type. Optionally, you can configure data items in upstream blocks to inherit the type (Inherit: Inherit via back propagation
) or stop the propagation at an arbitrary block by specifying a noninherited data type setting.To specify a data type for an individual data item, use the Model Data Editor (on the Modeling tab, click Model Data Editor). You can use the name of the same
Simulink.AliasType
object to specify the data types of multiple data items.For an example that shows how to use a
Simulink.AliasType
object directly in a model, see Create Data Type Alias in the Generated Code.
Control Names of Primitive Types | Technique |
---|---|
Change the name of a primitive type that the generated code
uses to define variables by default (for example,
int8_T ). |
Configure a data type replacement for an entire model. To replace a default Simulink
Coder data type name with the corresponding
Simulink type name, for example, to replace
To share data type replacements throughout a model reference hierarchy, use referenced configuration sets (see Share a Configuration Across Referenced Models). |
Configure the generated code to define a particular data item, such as a variable, by using a specific, meaningful type name. |
In the model, locate the data item that corresponds to the
variable. For example, trace from the code generation report
to the model. Use the name of the
If necessary, to
prevent other data items in upstream and downstream blocks
from using the same type name, configure those items to use
a data type setting that is not inherited. By default, most
signals use the inherited type |
Use the same type name for multiple signals and other data items in a data path, which is a series of connected blocks. | In the model, use the name of a
Usually, no matter where on the data path you specify the type, downstream data items inherit the type. You can configure upstream data items to inherit the type, too. Consider specifying the type in a block that you do not expect to remove or change frequently. |
Configure the generated code to replace an
implementation-dependent type, such as char_T
or boolean_T , and another type of equivalent
bit length with a single type name that you specify. | Use the name of the Simulink.AliasType
object to configure multiple data type replacements
simultaneously. See Replace Implementation-Dependent Types with the Same Type Name. |
Use Simulink Data Type Names Instead of Simulink Coder Data Type Names
For consistency between the data type names that you see in a model and in the
generated code, you can configure data type replacements so the code uses
Simulink type names instead of Simulink
Coder names. For each Simulink
Coder type that you want to rename, use the Simulink data type name to specify the replacement name. You do not need to
create Simulink.AliasType
objects.
To replace boolean_T
, int_T
, or
uint_T
, use the information in the table.
Simulink Coder Type Name | Replacement Names to Use |
---|---|
|
One of these names:
|
|
|
|
|
|
|
* Replace n
with the number of bits displayed in Configuration Parameters > Hardware Implementation for either Number of bits: int or
Number of bits: char. Use the
appropriate number of bits for the data type
that you want to replace.
You cannot use this technique to replace real_T
with
double
or real32_T
with
single
.
Replace Implementation-Dependent Types with the Same Type Name
Some Simulink
Coder type names map to C primitives that are implementation-dependent.
For example, the Simulink
Coder type int_T
maps to the C type
int
, whose bit length depends on the native integer size
of your target hardware. Other implementation-dependent types include
boolean_T
, char_T
, and
uint_T
.
For more readable, simpler code, you can use the same type name to replace
multiple Simulink
Coder types of the same size. For example, if the native integer size of
your hardware is 32 bits, you can replace int_T
and
int32_T
with the same type name, say,
myInt
.
Configure your target hardware settings in Configuration Parameters > Hardware Implementation.
Create a
Simulink.AliasType
object namedmyInt
. In this case, becauseint_T
andint32_T
represent a 32-bit signed integer, setBaseType
toint32
.myInt = Simulink.AliasType('int32')
Configure the same data type replacement for
int32_T
andint_T
.
Note
Many-to-one data type replacement does not support the
char
(char_T
) built-in data type.
Use char
only in one-to-one data type
replacements.
Many-to-one data type replacement is not supported for Simulink Coder data types of different sizes.
Define Abstract Numeric Types and Rename Types
This model shows user-defined types, consisting of numeric and alias types. Numeric types allow you to define abstract numeric types, which is particularly useful for fixed-point types. Alias types allow you to rename types, which allows you create a relationship for types.
Explore Example Model
Open the example model and configure it to show the generated names of blocks.
load_system('UserDefinedDataTypes') set_param('UserDefinedDataTypes','HideAutomaticNames','off') open_system('UserDefinedDataTypes')
Key Features of User-Defined Types
Displayed and propagated on signal lines
Used to parameterize a model by type (e.g., In1 specifies its Output data type as
ENG_SPEED
)Types with a common ancestor can be mixed, whereby the common ancestor is propagated (e.g., output of Sum1)
Intrinsically supported by the Simulink Model Explorer
Include an optional header file attribute that is ideal for importing legacy types (ignored for GRT targets)
Types used in the generated code (ignored for GRT targets)
Instructions
Inspect the user-defined types in the Model Explorer by double-clicking the first yellow button below.
Inspect the replacement data type mapping by double-clicking the second yellow button below.
Compile the diagram to display the types in this model (Debug > Update Model > Update Model or Ctrl+D).
Generate code with the blue button below and inspect model files to see how user-defined types appear in the generated code.
Modify the attributes of
ENG_SPEED
andENG_SPEED_OFFSET
and repeat steps 1-4.
Notes
User-defined types are a feature of Simulink that facilitate parameterization of the data types in a model. Embedded Coder preserves alias data type names (e.g.,
ENG_SPEED
) in the generated code, whereas Simulink Coder implements user-defined types as their base type (e.g.,real32_T
).Embedded Coder also enables you to replace the built-in data types with user-defined data types in the generated code.
Control Names of Structure Types
To control the names of the standard structures that Simulink
Coder creates by default to store data
(
for parameter data,
for example), use Configuration Parameters > Code Generation > Identifiers > Global types to specify a naming rule. For more information, see Identifier Format Control.model
_P
When you use nonvirtual buses and parameter structures to aggregate signals and
block parameters into a custom structure in the generated code, control the name of
the structure type by creating a Simulink.Bus
object. For more
information, see Organize Data into Structures in Generated Code.
Generate Code That Reuses Data Types From External Code
To generate code that reuses a data type definition from your external C code,
specify the data scope of the corresponding data type object or enumeration in
Simulink as Imported
. With this setting, the generated code
includes (#include
) the definition from your code. For more
information about controlling the file placement of a custom data type, see Control File Placement of Custom Data Types.
Instead of creating individual data type objects and enumerated types, and then
configuring them, consider creating the objects and types by using the
Simulink.importExternalCTypes
function. By default, the
function configures the new objects and types so that the generated code imports
(reuses) the type definitions from your code. You can then use the objects and types
to set data types in a model and to configure data type replacements. For more
information, see Simulink.importExternalCTypes
and Exchange Structured and Enumerated Data Between Generated and External Code.
Create Data Type Alias in the Generated Code
This example shows how to configure the generated code to use a data type name (typedef
) that you specify.
Export Type Definition
When you integrate code generated from a model with code from other sources, your model code can create an exported typedef
statement. Therefore, all of the integrated code can use the type. This example shows how to export the definition of a data type to a generated header file.
Create a Simulink.AliasType
object named mySingleAlias
that acts as an alias for the built-in data type single
.
mySingleAlias = Simulink.AliasType('single');
Configure the object to export its definition to a header file called myHdrFile.h
.
mySingleAlias.DataScope = 'Exported'; mySingleAlias.HeaderFile = 'myHdrFile.h';
Open the model rtwdemo_configinterface
.
open_system('rtwdemo_configinterface')
Configure the model to show the generated names of blocks.
set_param('rtwdemo_configinterface','HideAutomaticNames','off')
On the Modeling tab, click Model Data Editor.
In the model, select the Inport block labeled In1
.
Use the Data Type column to set the data type to mySingleAlias
.
set_param('rtwdemo_configinterface/In1','OutDataTypeStr','mySingleAlias')
Configure In1
to use default storage.
In the C Code tab, select Code Interface > Default Code Mappings.
In the Code Mappings editor, under Inports and Outports, select category Inports. Set the default storage class to Default
.
On the Inports tab, set Storage Class to Model default
.
cm = coder.mapping.api.get('rtwdemo_configinterface'); setDataDefault(cm,'Inports','StorageClass','Default'); setInport(cm,'In1','StorageClass','Model default');
Generate code from the model.
slbuild('rtwdemo_configinterface')
### Starting build procedure for: rtwdemo_configinterface ### Successful completion of code generation for: rtwdemo_configinterface Build Summary Top model targets built: Model Action Rebuild Reason ============================================================================================ rtwdemo_configinterface Code generated. Code generation information file does not exist. 1 of 1 models built (0 models already up to date) Build duration: 0h 0m 8.5824s
In the code generation report, view the file rtwdemo_configinterface_types.h
. The code creates a #include
directive for the generated file myHdrFile.h
.
file = fullfile('rtwdemo_configinterface_ert_rtw','rtwdemo_configinterface_types.h'); rtwdemodbtype(file,'#include "myHdrFile.h"',... '#include "myHdrFile.h"',1,1)
#include "myHdrFile.h"
View the file myHdrFile.h
. The code uses the identifier mySingleAlias
as an alias for the data type real32_T
. By default, generated code represents the Simulink data type single
by using the identifier real32_T
.
The code also provides a macro guard of the form RTW_HEADER_filename_h_
. When you export a data type definition to integrate generated code with code from other sources, you can use macro guards of this form to prevent unintentional identifier clashes.
file = fullfile('slprj','ert','_sharedutils','myHdrFile.h'); rtwdemodbtype(file,'#ifndef RTW_HEADER_myHdrFile_h_',... ' * File trailer for generated code.',1,0)
#ifndef RTW_HEADER_myHdrFile_h_ #define RTW_HEADER_myHdrFile_h_ #include "rtwtypes.h" typedef real32_T mySingleAlias; typedef creal32_T cmySingleAlias; #endif /* RTW_HEADER_myHdrFile_h_ */ /*
View the file rtwdemo_configinterface.h
. The code uses the data type alias mySingleAlias
to define the structure field input1
, which corresponds to the Inport block labeled In1
.
file = fullfile('rtwdemo_configinterface_ert_rtw','rtwdemo_configinterface.h'); rtwdemodbtype(file,... '/* External inputs (root inport signals with default storage) */',... '} ExtU_rtwdemo_configinterface_T;',1,1)
/* External inputs (root inport signals with default storage) */ typedef struct { mySingleAlias input1; /* '<Root>/In1' */ MYTYPE input2; /* '<Root>/In2' */ MYTYPE input3; /* '<Root>/In3' */ MYTYPE input4; /* '<Root>/In4' */ } ExtU_rtwdemo_configinterface_T;
Import Type Definition
When you integrate code generated from a model with code from other sources, to avoid redundant typedef
statements, you can import a data type definition from the external code. This example shows how to import your own definition of a data type from a header file that you create.
Use a text editor to create a header file to import. Name the file ex_myImportedHdrFile.h
. Place it in your working folder. Copy the following code into the file.
#ifndef HEADER_myImportedHdrFile_h_ #define HEADER_myImportedHdrFile_h_ typedef float myTypeAlias; #endif
The code uses the identifier myTypeAlias
to create an alias for the data type float
. The code also uses a macro guard of the form HEADER_filename_h
. When you import a data type definition to integrate generated code with code from other sources, you can use macro guards of this form to prevent unintentional identifier clashes.
At the command prompt, create a Simulink.AliasType
object named myTypeAlias
that creates an alias for the built-in type single
. The Simulink data type single
corresponds to the C data type float
.
myTypeAlias = Simulink.AliasType('single')
myTypeAlias = AliasType with properties: Description: '' DataScope: 'Auto' HeaderFile: '' BaseType: 'single'
Configure the object so that generated code imports the type definition from the header file ex_myImportedHdrFile.h
.
myTypeAlias.DataScope = 'Imported'; myTypeAlias.HeaderFile = 'ex_myImportedHdrFile.h';
Open the model rtwdemo_configinterface
.
open_system('rtwdemo_configinterface')
On the Modeling tab, click Model Data Editor.
In the model, select the Inport block labeled In1
.
Use the Data Type column to set the data type to myTypeAlias
.
set_param('rtwdemo_configinterface/In1','OutDataTypeStr','myTypeAlias')
Generate code from the model.
slbuild('rtwdemo_configinterface')
### Starting build procedure for: rtwdemo_configinterface ### Successful completion of code generation for: rtwdemo_configinterface Build Summary Top model targets built: Model Action Rebuild Reason =========================================================================== rtwdemo_configinterface Code generated. Generated code was out of date. 1 of 1 models built (0 models already up to date) Build duration: 0h 0m 7.5863s
In the code generation report, view the file rtwdemo_configinterface_types.h
. The code creates a #include
directive for your header file ex_myImportedHdrFile.h
.
file = fullfile('rtwdemo_configinterface_ert_rtw','rtwdemo_configinterface_types.h'); rtwdemodbtype(file,'#include "ex_myImportedHdrFile.h',... '/* Forward declaration for rtModel */',1,0)
#include "ex_myImportedHdrFile.h" #include "MYTYPE.h" #ifndef DEFINED_TYPEDEF_FOR_Table1_Type_ #define DEFINED_TYPEDEF_FOR_Table1_Type_ typedef struct { MYTYPE BP[11]; MYTYPE Table[11]; } Table1_Type; #endif #ifndef DEFINED_TYPEDEF_FOR_Table2_Type_ #define DEFINED_TYPEDEF_FOR_Table2_Type_ typedef struct { MYTYPE BP1[3]; MYTYPE BP2[3]; MYTYPE Table[9]; } Table2_Type; #endif #endif /* RTW_HEADER_rtwdemo_configinterface_types_h_ */ /* * File trailer for generated code. * * [EOF] */
View the file rtwdemo_configinterface.h
. The code uses the data type alias myTypeAlias
to define the structure field input1
, which corresponds to the Inport block labeled In1
.
file = fullfile('rtwdemo_configinterface_ert_rtw','rtwdemo_configinterface.h'); rtwdemodbtype(file,... '/* External inputs (root inport signals with default storage) */',... '} ExtU_rtwdemo_configinterface_T;',1,1)
/* External inputs (root inport signals with default storage) */ typedef struct { myTypeAlias input1; /* '<Root>/In1' */ MYTYPE input2; /* '<Root>/In2' */ MYTYPE input3; /* '<Root>/In3' */ MYTYPE input4; /* '<Root>/In4' */ } ExtU_rtwdemo_configinterface_T;
Display Base Data Types and Aliases on Model Diagram
When you display signal data types on the model diagram, you can choose to display aliases (such as myTypeAlias
) and base data types (such as int16
). To display aliases, on the Debug tab, select Information Overlays > Alias Data Types. To display the base types, select Information Overlays > Base Data Types. For more information, see Port Data Types.
Create a Named Fixed-Point Data Type in the Generated Code
This example shows how to create and name a fixed-point data type in generated code. You can use the name of the type to specify parameter and signal data types throughout a model and in generated code.
The example model rtwdemo_fixpt1
uses fixed-point data types. So that you can more easily see the fixed-point data type in the generated code, in this example, you create a Simulink.Parameter
object that appears in the code as a global variable.
Create a Simulink.AliasType
object that defines a fixed-point data type. Name the object myFixType
. The generated code uses the name of the object as a data type.
myFixType = Simulink.AliasType('fixdt(1,16,4)');
Open the model rtwdemo_fixpt1
.
open_system('rtwdemo_fixpt1')
Configure the model to show the generated names of the blocks.
set_param('rtwdemo_fixpt1','HideAutomaticNames','off')
On the Modeling tab, click Model Data Editor.
In the Model Data Editor, select the Parameters tab.
In the model, select the Gain block.
In the Model Data Editor, for the row that represents the Gain parameter of the Gain block, in the Value column, specify myParam
.
Click the action button (with three vertical dots) next to the parameter value. Select Create.
In the Create New Data dialog box, set Value
to Simulink.Parameter(8)
. In this example, for more easily readable code, you set the parameter value to 8 instead of -3.2. Click Create. A Simulink.Parameter
object named myParam
appears in the base workspace. The object stores the real-world value 8
, which the Gain block uses for the value of the Gain parameter.
In the Simulink.Parameter property dialog box, set Storage class to ExportedGlobal
. Click OK. With this setting, myParam
appears in the generated code as a separate global variable.
In the Model Data Editor, use the Data Type column to set the data type of the Gain parameter of the Gain block to myFixType
.
On the Signals tab, use the Data Type column to set the data type of the Gain block output to myFixType
.
Use the Data Type column to set the data type of the Conversion
block output to myFixType
.
Alternatively, you can use these commands at the command prompt to configure the blocks and create the object:
set_param('rtwdemo_fixpt1/Gain','Gain','myParam','OutDataTypeStr','myFixType',... 'ParamDataTypeStr','myFixType') myParam = Simulink.Parameter(8); myParam.StorageClass = 'ExportedGlobal'; set_param('rtwdemo_fixpt1/Conversion','OutDataTypeStr','myFixType')
In the model, set Configuration Parameters > Code Generation > System target file to ert.tlc
. With this setting, the code generator honors data type aliases such as myFixType
.
set_param('rtwdemo_fixpt1','SystemTargetFile','ert.tlc')
Select the configuration parameter Generate code only.
set_param('rtwdemo_fixpt1','GenCodeOnly','on')
Generate code from the model.
slbuild('rtwdemo_fixpt1')
### Starting build procedure for: rtwdemo_fixpt1 ### Successful completion of code generation for: rtwdemo_fixpt1 Build Summary Top model targets built: Model Action Rebuild Reason =================================================================================== rtwdemo_fixpt1 Code generated. Code generation information file does not exist. 1 of 1 models built (0 models already up to date) Build duration: 0h 0m 11.166s
In the code generation report, view the file rtwdemo_fixpt1_types.h
. The code defines the type myFixType
based on an integer type of the specified word length (16).
file = fullfile('rtwdemo_fixpt1_ert_rtw','rtwdemo_fixpt1_types.h'); rtwdemodbtype(file,'#ifndef DEFINED_TYPEDEF_FOR_myFixType_',... '/* Forward declaration for rtModel */',1,0)
#ifndef DEFINED_TYPEDEF_FOR_myFixType_ #define DEFINED_TYPEDEF_FOR_myFixType_ typedef int16_T myFixType; typedef cint16_T cmyFixType; #endif
View the file rtwdemo_fixpt1.c
. The code uses the type myFixType
, which is an alias of the integer type int16
, to define the variable myParam
.
file = fullfile('rtwdemo_fixpt1_ert_rtw','rtwdemo_fixpt1.c'); rtwdemodbtype(file,'myFixType myParam = 128;','myFixType myParam = 128;',1,1)
myFixType myParam = 128; /* Variable: myParam
The stored integer value 128
of myParam
is not the same as the real-world value 8
because of the scaling that the fixed-point data type myFixType
specifies. For more information, see Scaling (Fixed-Point Designer) in the Fixed-Point Designer documentation.
The line of code that represents the Gain block applies a right bit shift corresponding to the fraction length specified by myFixType
.
rtwdemodbtype(file,... 'rtwdemo_fixpt1_Y.Out1 = (myFixType)((myParam * rtb_Conversion) >> 4);',... 'rtwdemo_fixpt1_Y.Out1 = (myFixType)((myParam * rtb_Conversion) >> 4);',1,1)
rtwdemo_fixpt1_Y.Out1 = (myFixType)((myParam * rtb_Conversion) >> 4);
Rename Data Type Object
To rename a data type object such as Simulink.AliasType
or
Simulink.Bus
after you create it (for example, to rename an
alias when coding standards change or when you encounter a naming conflict), you can
allow Simulink to rename the object and correct
all of the references to the object that appear in
a model or models. In the Model Explorer, right-click the variable and select
Rename All. For more information, see Rename Variables.
Display Signal Data Types on Block Diagram
For readability, you can display signal data types directly on a block diagram. When you use custom names for primitive data types, you can choose to display the custom name (the alias), the underlying primitive, or both. See Port Data Types.
Data Type Replacement Limitations
You cannot configure the generated code to use these custom C data types:
Array types
Pointer types
const
orvolatile
types
You cannot configure the generated code to use generic C primitive types such as
int
andshort
.
When you set Data type replacement to Use C data
types with fixed-width integers
, these limitations apply:
The Specify custom data type names configuration parameter is not supported.
Word size values for production integer data types must include the values 8, 16, and 32 bits and each value can only be 8, 16, 32, or 64 bits. If
ProdEqTarget
is set to'off'
, the same requirement applies to test hardware integer data types.You cannot generate AUTOSAR code.
You cannot run external mode simulations that use TCP/IP or serial communication. Run external mode simulations that use XCP communication.
You cannot generate code for third-party hardware workflows that use Embedded Coder® support packages.
In generated C++ code, statements that include the header files
stdint.h
andstdbool.h
violate MISRA™ C++:2008 rule 18-0-1.If the model includes Simscape™ blocks, some of the generated source files might contain
#include "rtwtypes.h"
. Generated code from Simscape blocks is not intended for production deployment. The build process can compile the generated code because the code generator creates artwtypes.h
file for continuous-time models.
When you set Data type replacement to Use coder
typedefs
and select the Specify custom data type
names configuration parameter, these limitations apply:
Data type replacement does not support multiple levels of mapping. Each replacement data type name maps directly to one or more built-in data types.
Data type replacement is not supported for simulation target code generation for referenced models.
If you select the Classic call interface configuration parameter for your model, data type replacement is not supported.
Code generation performs data type replacements while generating
.c
,.cpp
, and.h
files. Code generation places these files in build folders (including top and referenced model build folders) and in the_sharedutils
folder. Exceptions are as follows:rtwtypes.h
multiword_types.h
model_reference_types.h
builtin_typeid_types.h
model_sf.c
or.cpp
(ERT S-function wrapper)model_dt.h
(C header file supporting external mode)model_capi.c
or.cpp
model_capi.h
Data type replacement is not supported for complex data types.
Many-to-one data type replacement is not supported for the
char
data type. Attempting to usechar
as part of a many-to-one mapping to a custom data type represents a violation of the MISRA C™ specification. For example, if you mapchar
(char_T
) and eitherint8
(int8_T
) oruint8
(uint8_T
) to the same replacement type, the result is a MISRA C violation. If you try to generate C++ code, the code generator makes invalid implicit type casts, resulting in compile-time errors. Usechar
only in one-to-one data type replacements.Many-to-one data type replacement is not supported for Simulink Coder data types of different sizes. For more information, see Replace Implementation-Dependent Types with the Same Type Name.
For ERT S-functions, replace the
boolean
data type with only an 8-bit integer,int8
, oruint8
.Set the
DataScope
property of aSimulink.AliasType
object toAuto
(default) orImported
.