Control File Placement of Custom Data Types

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.

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 the getDataScope 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.

GoalSpecify DataScope asSpecify HeaderFile as
Export type definition to model_types.hAutoEmpty
Import type definition from a header file that you create, filenameAuto or Importedfilename (if necessary, include a .h extension)
Export type definition to a generated header file, filename.hExportedfilename or filename.h
Export type definition to a generated header file, typename.hExportedEmpty

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. 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, but a>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 in rtwtypes.h instead of model_types.h.

  • When you use a Simulink.AliasType or Simulink.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 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 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 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.

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 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 model_types.h, the file contains a macro guard of the form _DEFINED_TYPEDEF_FOR_typename_ for each 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 model_types.h contains the guarded typedef statement:

#ifndef _DEFINED_TYPEDEF_FOR_mySingleAlias_
#define _DEFINED_TYPEDEF_FOR_mySingleAlias_

typedef real32_T mySingleAlias;

#endif

See Also

| |

Topics