Control File Placement of Custom Data Types - MATLAB & Simulink (original) (raw)

Main Content

By default, when you use data type objects, such as Simulink.AliasType andSimulink.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.

Data Scope and Header File

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 thegetDataScope and getHeaderFile methods.

_`typename`_ is the name of the custom data type.
_`filename`_ is the name of a header file.
_`model`_ is the name of the model.

Goal	Specify DataScope as	Specify HeaderFile as
Export type definition to_model__types.h	Auto	Empty
Import type definition from a header file that you create,filename	Auto or Imported	filename (if necessary, include a .h extension)
Export type definition to a generated header file,filename.h	Exported	filename or_filename_.h
Export type definition to a generated header file,typename.h	Exported	Empty

When you import a data type definition (for example, by settingDataScope 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. To avoid linker errors, you must add include guards, such as #pragma once, to the beginning of an imported header file.

Note

When you set the HeaderFile property, these characters are not supported:

These characters are supported ONLY when used as a leading or trailing delimiter:

" — For example, "abc.h" is supported, but ab"c.h is not.
< and > — For example,<abc.h> is supported, buta>bc.h is not.

Considerations for Data Type Replacement

If you use the Specify custom data type names configuration parameter to replace a built-in Simulink® Coder™ 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 inrtwtypes.h instead of_`model`__types.h.
When you use a Simulink.AliasType orSimulink.NumericType object in data type replacement, you cannot set the DataScope property of the object to Exported. Therefore, if you want the code generator to generate the correspondingtypedef statement, you cannot control the file placement of the statement. However, you can setDataScope to Imported, which means that you can configure the code to reuse thetypedef 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 Specify Custom Names Using Data Replacement Type Pane.

Import Definition of Numerically Complex Data Type

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 toImported), your code must provide two complementarytypedef 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 andcIAT_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 bothIAT_int32 and cIAT_int32.

Macro Guards

When you export one or more data type definitions to a generated header file, the file contains a file-level macro guard of the formRTW_HEADER_ _`filename`__h.

Suppose that you use several Simulink.AliasType objects:mySingleAlias, myDoubleAlias, andmyIntAlias with these properties:

DataScope set to Exported
HeaderFile set to myTypes.h

When you generate code, the guarded file myTypes.h contains thetypedef 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_`model`__types.h, the file contains a macro guard of the form_DEFINED_TYPEDEF_FOR_ _`typename`__ for each typedef statement. Suppose that you use aSimulink.AliasType object mySingleAlias with these properties:

DataScope set to Auto
HeaderFile not specified

When you generate code, the file_`model`__types.h contains the guardedtypedef statement:

#ifndef DEFINED_TYPEDEF_FOR_mySingleAlias #define DEFINED_TYPEDEF_FOR_mySingleAlias

typedef real32_T mySingleAlias;

#endif

Control File Placement of Custom Data Types - MATLAB & Simulink (original) (raw)

Data Scope and Header File

Considerations for Data Type Replacement

Import Definition of Numerically Complex Data Type

Macro Guards

See Also

Topics