Configure Root-Level Outport Blocks for C Code Generation

To use code that you generate from a model, you call generated entry-point functions. The calling environment and generated functions exchange input and output data, for example, as global variables or function arguments. Root-level Outport blocks (outports) constitute the output data of the interface. To integrate and deploy the generated code into larger applications, you can customize how the code generator produces the interface code, including how output data is declared and handled. Customizations can:

Minimize the modifications that you make to existing code.
Generate stable interfaces that do not change or minimally change when you make changes to your model.
Generate code that exchanges data more efficiently (for example, by using pointers and pass-by-reference arguments for nonscalar data).

For code generation, examples show how to customize the outport interface for the model ConfigurationRapidPrototypingInterface. You can configure code mappings by using the Code Mappings Editor – C or code mappings API (coder.mapping.api.CodeMapping).

Choose Customization Options for Outport Interface

By default, root-level outports in a model appear in generated code as fields of a global data structure named model_ExtY. Based on your code interface requirements, decide whether to customize generation of outport data. If you do not configure customizations, the code generator determines whether to eliminate or change the representation of outports in generated code for optimization purposes. If you configure customizations, decide:

Whether to set up a default configuration
If a model includes a significant number (for example, more than 10) of root-level outports, it is more efficient to configure the outports with a default setting, and override that setting for special cases. If the model includes a few outports that have unique source, naming, or placement requirements, consider configuring the outports individually.
How to declare and handle outport data in the generated interface
- As separate global variables
- To write output data to global variables defined in external code
- For referenced model outports, as global variables (void-void)
- As calls to access functions. Requires Embedded Coder^®
- As entry-point function arguments. Requires Embedded Coder
For more information about these options, see Control Data and Function Interface in Generated Code.

Other considerations include whether to:

Name outports in the generated code by using Outport block labels that appear in the model or by using unique code identifiers.
Include the volatile type qualifier in global variable definitions and declarations. Requires Embedded Coder. See Protect Global Data with const and volatile Type Qualifiers (Embedded Coder).
Write data from a specific area of memory. Requires Embedded Coder. See Control Data and Function Placement in Memory by Inserting Pragmas (Embedded Coder).

For a list of lists interface requirements that are relevant to outports with corresponding storage classes and storage class properties, see Choose Storage Class for Controlling Data Representation in Generated Code.

Outport interface requirements for example model ConfigurationRapidPrototypingInterface are:

Write data for root-level outport Out1 to an external header file. The data written with Out1 is the output of code generated for the Switch block.
The variable representing the outport in the generated code must be named output.

For this example, configure the outport in ConfigurationRapidPrototypingInterface to meet these code generation requirements.

Configure Default Code Generation Settings for Root-Level Outports

A default code generation setting for root-level outports can reduce the effort of preparing a model for code generation, especially if a model has a significant number of outports. Choose configuration settings once, and the code generator applies those settings to outports across the model. Simulink^® stores the default configuration as part of the model.

Consider configuring default code generation settings for model outports if your model uses multiple root-level outports that do not have unique requirements.

The example model ConfigurationRapidPrototypingInterface includes one root-level outport. This example shows how to use the Code Mappings Editor – C to configure default settings for root-level outports. Specify that the code generator declare and define variables to represent root outports in generated external header and definition files.

Open example model ConfigurationRapidPrototypingInterface. Save a copy of the model to a writable location.
Open the Simulink Coder app.
In the C Code tab, select Code Interface > Default Code Mappings.
In the Code Mappings editor, under Inports and Outports, select category Outports. Set the default storage class to ExportedGlobal.
Save the model.

Configure Code Generation Settings for Individual Root-Level Outports

You can configure individual root-level outports for code generation. For example, if a model has two root-level outports that have unique code generation requirements, configure the outports individually. Or, if you configure default settings for outports, configure individual outports to use the default settings or unique settings.

If your model meets at least one of these criteria, consider configuring code generation settings for outports individually:

Uses multiple outports that have unique requirements.
Uses few outports.
Has a default configuration for outports and you need to override the configuration for some specific outports.

This example shows how to use the Code Mappings editor to apply the default code generation configuration for outports in model ConfigurationRapidPrototypingInterface. In the preceding example, you set the default storage class for outports to ExportedGlobal.

The example also shows how to configure an identifier that the code generator uses for naming the outport in the generated code. You can specify code generation identifiers, for example for integration, without modifying the model design.

If you have not already done so, complete the steps in Configure Default Code Generation Settings for Root-Level Outports.
In the Code Mappings editor, click the Outports tab. The editor lists the names of Outport blocks and bus elements that are in the model. If a port resolves to a signal object, a resolve-to-signal-object icon appears to the right of the element name. The storage class for the outport in the example model is set to Auto, which means that the code generator might eliminate or change the representation of relevant code for optimization purposes. If optimizations are not possible, the code generator applies the model default configuration. For this example, the model default configuration specifies storage class ExportedGlobal.
- To avoid optimizations and force the code generator to use the default configuration, set the storage class to Model default.
- To override the default configuration, specify the storage class that meets the code generation requirements for that outport.
Configure the code generator to apply the default storage class setting to outport Out1. Select the row for the outport. Set the storage class to Model default: ExportedGlobal.
The storage class for the selected outport changes to Model default: ExportedGlobal.
Configure the code identifier for the outport so that the interface argument name in the generated code matches the interface name used by the external code. In the Code Mappings editor, select the row for the outport. Click the icon and set the Identifier property to output.
Save the model.
Generate and view the code. For example, in the file ConfigurationRapidPrototypingInterface.c, find where variable output is used in the step entry-point function.
```
if (mode) {
    output = (real_T)mp_K1 * dout_Table1;
  } else {
    output = dstate_X;
  }
```

Configure Code Generation Settings for Root-Level Outports Programmatically

To automate configuration of root-level outports for code generation, use the programming interface for code mappings. For example, when creating custom block libraries or part of an application test environment, use the programming interface to automate data configuration.

This example shows how to use the programming interface to configure default settings for root-level outports for model ConfigurationRapidPrototypingInterface. The root-level outport writes output to a separate global variable.

Configure code an identifier for the outport so that global variable name in the generated code matches the variable name in the external code interface.

Open the example model.

openExample("ConfigurationRapidPrototypingInterface")

Create object cm by calling function coder.mapping.api.get. The object stores the code generation configuration for data elements in model ConfigurationRapidPrototypingInterface.
```
cm = coder.mapping.api.get("ConfigurationRapidPrototypingInterface");
```
Configure default settings for outports by calling function setDataDefault. For the arguments, specify these values.
- The object returned by coder.mapping.api.get
- Outports for the default category
- Property name StorageClass that has property value ExportedGlobal
```
setDataDefault(cm,"Outports","StorageClass","ExportedGlobal")
```
Verify your default configuration for outports. Issue a call to getDataDefault that specifies the object returned by coder.mapping.api.get, category Outports, and StorageClass.
```
getDataDefault(cm,"Outports","StorageClass")
```
```
ans =

    'ExportedGlobal'
```
Apply the default outport configuration for outport Out1.
By default, Simulink sets the storage class for individual outports to Auto. When the storage class is Auto, the code generator:
- Determines whether to eliminate the data from the generated code for optimization purposes.
- If retaining the data, determines how to efficiently represent the data in the generated code, taking into account default configuration settings.
To control the configuration for an outport, call function setOutport.
Issue a call to setOutport that specifies:
- Object returned by coder.mapping.api.get
- Outport block name Out1
- Default storage class previously set for the outport by using property StorageClass and property value Model default
- Property Identifier and property value output
```
setOutport(cm,"Out1","StorageClass","Model default","Identifier","output");
```
Verify your configuration changes by calling function getOutport. Specify the object returned by coder.mapping.api.get, name of the outport block, and property StorageClass or Identifier.
```
getOutport(cm,"Out1","StorageClass")

ans =

    'Model default'

getOutport(cm,"Out1","Identifier")

ans =

    'output'
```
Save the model.
Generate and view the code. For example, in the file ConfigurationRapidPrototypingInterface.c, find where variable output is used in the step entry-point function.
```
if (mode) {
    output = (real_T)mp_K1 * dout_Table1;
  } else {
    output = dstate_X;
  }
```

Choose Storage Class and Storage Class Properties for Root-Level Outports

Depending on your code generation requirements, choose from these storage classes to configure code generation for root-level outports.

Requirements	Storage Class for Default Mappings	Storage Class for Individual Mappings
Enable optimizations, potentially generating more efficient code.		Auto
For data elements that cannot be optimized, represent data as a field of a standard data structure.	Default
Prevent optimizations from eliminating storage for a data element and use the default mapping for the data element category.		Model Default
Generate a global variable definition and declaration.	ExportedGlobal	ExportedGlobal
Generate code that reads from and writes to a global variable or global variable pointer defined by your external code.	ImportedExtern, ImportedExternPointer	ImportedExtern, ImportedExternPointer

The list of available storage classes might include other project-specific storage classes defined in an Embedded Coder Dictionary. If you have special requirements that are not met by the listed storage classes and you have Embedded Coder software, you can define a storage class. See Define Service Interfaces, Storage Classes, Memory Sections, and Function Templates for Software Architecture (Embedded Coder).

For an individual outport, use the Identifier storage class property to configure a name for the variable representing the outport in the generated code. If you leave the Identifier property blank, the code generator uses the Signal name parameter of the Outport block. If this parameter is empty, the code generator uses the name of the Outport block.