Control Data Type Names in Generated Code

By default, the generated code uses Simulink® Coder™ data type aliases to define scalar and array variables. For example, the Simulink Coder type real32_T corresponds to the Simulink type single. The code defines these types through typedef statements that build on C primitive types such as float and short. You can configure the code to use custom type names instead.

The code also 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) by default. You can specify a naming rule for these structure types. You can also place data items into separate custom structures whose type names you can control.

Control these type names to help you to:

For custom types, you can also specify that the generated code reuse type definitions, for example, typedef statements, from your external code.

For information about data type names that you cannot control and about custom data types that the generated code does not support, see Limitations.

To inform the code generator about the bit length of generic C types such as int and short for your target hardware, use Hardware Implementation configuration parameters. See Configure Run-Time Environment Options.

Control Names of 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 NameCorresponding Simulink Type Name

real_T

double

real32_T

single

int32_T

int32

int16_T

int16

int8_T

int8

uint32_T

uint32

uint16_T

uint16

uint8_T

uint8

boolean_T

boolean

For configuring data type replacement throughout an entire model (Configuration Parameters > Code Generation > Data Type Replacement), you can alternatively use one of these types:

  • uint8

  • int8

  • intn*

int_T

intn*

uint_T

uintn*

char_T

intn*

uint64_T

uint64

int64_T

int64

* 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 rename.

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 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 TypesTechnique
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 int8_T with int8, you do not need to create a Simulink.AliasType object. See Use Simulink Data Type Names Instead of Simulink Coder Data Type Names.

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 Simulink.AliasType object to set the data type of the item.

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 Inherit: Inherit via internal rule.

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 Simulink.AliasType object to set the data type of one of the signals in the path, for example, a root-level Inport block or a Constant block. For example, if the path begins with an Inport block at the root level of the model, you can specify the type in that block. By default, due to data type propagation, the data items in the other blocks typically inherit the same type.

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 NameReplacement Names to Use

boolean_T

One of these names:

  • boolean

  • uint8

  • int8

  • intn*

int_T

intn*

uint_T

uintn*

char_T

intn*

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

  1. Configure your target hardware settings in Configuration Parameters > Hardware Implementation.

  2. Create a Simulink.AliasType object named myInt. In this case, because int_T and int32_T represent a 32-bit signed integer, set BaseType to int32.

    myInt = Simulink.AliasType('int32')

  3. Configure the same data type replacement for int32_T and int_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('rtwdemo_udt')
set_param('rtwdemo_udt','HideAutomaticNames','off')
open_system('rtwdemo_udt')

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

  1. Inspect the user-defined types in the Model Explorer by double-clicking the first yellow button below.

  2. Inspect the replacement data type mapping by double-clicking the second yellow button below.

  3. Compile the diagram to display the types in this model (Debug > Update Model > Update Model or Ctrl+D).

  4. Generate code with the blue button below and inspect model files to see how user-defined types appear in the generated code.

  5. Modify the attributes of ENG_SPEED and ENG_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 (model_P for parameter data, for example), use Configuration Parameters > Code Generation > Identifiers > Global types to specify a naming rule. For more information, see Customize Generated Identifiers.

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.

rtwbuild('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 13.445s

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.

rtwbuild('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 14.015s

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"

/* Model Code Variants */
#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.

rtwbuild('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 17.493s

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.

Limitations

  • You cannot configure the generated code to use these custom C data types:

    • Array types

    • Pointer types

    • const or volatile types

  • You cannot configure the generated code to use generic C primitive types such as int and short.

Data Type Replacement Limitations

When you select the model configuration parameter Replace data type names in the generated code on the Code Generation > Data Type Replacement pane of the Configuration Parameters dialog box, 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 use char 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 map char (char_T) and either int8 (int8_T) or uint8 (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. 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. 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, or uint8.

  • Set the DataScope property of a Simulink.AliasType object to Auto (default) or Imported.

Related Topics