By default, when you use data type objects, such as Simulink.AliasType
and
Simulink.Bus
, and custom enumerations to specify data types for
signals and block parameters, the code generated from the model defines the types (for
example, with typedef
statements). To ease integration of the
generated code with other existing code and to modularize the generated code, you can
control the file placement of the type definitions by adjusting the properties of the
objects and the enumerations.
To control the file placement of a custom type definition in generated code, set
the DataScope
and HeaderFile
properties of the
data type object according to the table. Similarly, for an enumeration that you
define in a MATLAB® file, set the return arguments of the
getDataScope
and getHeaderFile
methods.
is the name of
the custom data type.typename
is the name of
a header file.filename
is the name of the
model.model
Goal | Specify DataScope as | Specify HeaderFile as |
---|---|---|
Export type definition to
| Auto | Empty |
Import type definition from a header file that you create,
| Auto or Imported | (if
necessary, include a .h
extension) |
Export type definition to a generated header file,
| Exported | or
|
Export type definition to a generated header file,
| Exported | Empty |
When you import a data type definition (for example, by setting
DataScope
to Imported
), the generated
model code creates an #include
directive for your header file in
place of a type definition. You supply the header file that contains the
definition.
If you use data type replacement to replace a built-in Simulink® data type with your own data type in generated code
(see Model Configuration Parameters: Code Generation Data Type Replacement), typedef
statements and #include
directives appear in
rtwtypes.h
instead of
.model
_types.h
When a Simulink.AliasType
or
Simulink.NumericType
object participates in
data type replacements, you cannot set the
DataScope
property of the object to
Exported
. Therefore, if you want the code
generator to generate the corresponding typedef
statement, you cannot control the file placement of the statement.
However, you can set DataScope
to
Imported
, which means that you can configure
the code to reuse the typedef
statement that your
external code provides.
As a workaround, instead of using the data type object as a data type replacement, use the object to set the data types of individual data items in a model. To configure many data items, you can use the Model Data Editor and take advantage of data type propagation and inheritance. For more information, see Control Names of Primitive Data Types.
You can use a Simulink.AliasType
object with numerically
complex data (i
). In this case, if you configure the
generated code to import the type definition from your external code (for
example, by setting the DataScope
property to
Imported
), your code must provide two complementary
typedef
statements.
Suppose your external header file myAliasTypes.h
defines
the data type IAT_int32
as an alias of a 32-bit integer. The
file must define two types: IAT_int32
and
cIAT_int32
:
#ifndef myAliasTypes_H_ #define myAliasTypes_H_ #include "rtwtypes.h" typedef int32_T IAT_int32; typedef cint32_T cIAT_int32; #endif
You do not need to create two Simulink.AliasType
objects. In
this example, you create one object, IAT_int32
. The generated
code then creates complex data (variables) by using both
IAT_int32
and cIAT_int32
.
When you export one or more data type definitions to a generated header file, the
file contains a file-level macro guard of the form
RTW_HEADER_
. filename
_h
Suppose that you use several Simulink.AliasType
objects:
mySingleAlias
, myDoubleAlias
, and
myIntAlias
with these properties:
DataScope
set to Exported
HeaderFile
set to myTypes.h
When you generate code, the guarded file myTypes.h
contains the
typedef
statements:
#ifndef RTW_HEADER_myTypes_h_ #define RTW_HEADER_myTypes_h_ #include "rtwtypes.h" typedef real_T myDoubleAlias; typedef real32_T mySingleAlias; typedef int16_T myIntAlias; #endif
When you export data type definitions to
, the file contains a
macro guard of the form
model
_types.h_DEFINED_TYPEDEF_FOR_
for each typename
_typedef
statement. Suppose that you use a
Simulink.AliasType
object mySingleAlias
with these properties:
DataScope
set to Auto
HeaderFile
not specified
When you generate code, the file
contains the guarded
model
_types.htypedef
statement:
#ifndef _DEFINED_TYPEDEF_FOR_mySingleAlias_ #define _DEFINED_TYPEDEF_FOR_mySingleAlias_ typedef real32_T mySingleAlias; #endif
Simulink.AliasType
| Simulink.Bus
| Simulink.NumericType