Main Content

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 rtwdemo_configinterface. You can configure code mappings by using the Code Mappings Editor 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:

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 rtwdemo_configinterface are:

  • Use project type definition MYTYPE defined in rtwdemo_configinterface_data.m.

  • Declare a variable for outport Out1 in generated external header file exOutSys.h and define the variable in source definition file exOutSys.c. The data written to Out1 is the output of code generated for the Switch block.

  • The variable representing the outport in the generated code must be named output1. That name is the variable name that the external code interface uses to access the output data.

For this example, configure the outport in rtwdemo_configinterface 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 or uses a shared Embedded Coder Dictionary.

The example model rtwdemo_configinterface includes one root-level outport. This example shows how to use the Code Mappings Editor 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. Name the generated default external header file exOutSys.h and the generated definition file exOutSys.c.

  1. Open example model rtwdemo_configinterface. Save a copy of the model to a writable location.

    Simulink model to use for learning how to configure outports for code generation.

  2. Open the Embedded Coder app.

  3. In the C Code tab, select Code Interface > Default Code Mappings.

  4. In the Code Mappings editor, under Inports and Outports, select category Outports. Set the default storage class to ExportToFile.

  5. In the Property Inspector, set Header File to exOutSys.h and Definition File to exOutSys.c.

    Code Mappings editor with Data Defaults tab selected, Inports and Outports tree node expanded, and storage class for Outports set to ExportToFile. Property Inspector with HeaderFile property set to exOutSys.h and DefinitionFile property set to exOutSys.c.

  6. 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 rtwdemo_configinterface. In the preceding example, you set the default storage class for outports to ExportToFile. A requirement specifies that outport Out1 write output data to a global variable declared and defined in generated header and definition files accessible to external code.

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.

  1. If you have not already done so, complete the steps in Configure Default Code Generation Settings for Root-Level Outports.

  2. 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 ExportToFile.

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

  3. 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: ExportToFile.

    Code Mappings editor with Outports tab selected, outport Out1 selected, and storage class being set to Model default: ExportToFile.

    The storage class for the selected outport changes to Model default: ExportToFile.

  4. 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. In the Property Inspector, set the Identifier property to output.

  5. Save the model.

  6. Generate and view the code. For example, in the file rtwdemo_configinterface.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 rtwdemo_configinterface.

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.

  1. Open the example model.

    open_system('rtwdemo_configinterface')
    
  2. Create object cm by calling function coder.mapping.api.get. The object stores the code generation configuration for data elements and functions in model rtwdemo_configinterface.

    cm = coder.mapping.api.get('rtwdemo_configinterface');
  3. 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 ExportToFile

    • Property name HeaderFile that has property value exOutSys.h and property name DefinitionFile that has property value exOutSys.c, the names for the generated files that declare and define the output data

    setDataDefault(cm,'Outports','StorageClass','ExportToFile','HeaderFile','exOutSys.h',...
    'DefinitionFile','exOutSys.c')
  4. Verify your default configuration for outports. Issue three calls to getDataDefault that specify the object returned by coder.mapping.api.get and category Outports.

    • In the first call, specify the third argument as property StorageClass.

    • In the second call, for the third argument, specify HeaderFile.

    • In the third call, for the third argument, specify DefinitionFile.

    getDataDefault(cm,'Outports','StorageClass')
    
    ans =
    
        'ExportToFile'
    
    getDataDefault(cm,'Outports','HeaderFile')
    
    ans =
    
        'exOutSys.h'
    
    getDataDefault(cm,'Outports','DefinitionFile')
    
    ans =
    
        'exOutSys.c'
    
  5. 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');
    
  6. 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'
    
  7. Save the model.

  8. Generate and view the code. For example, in the file rtwdemo_configinterface.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.

RequirementsStorage Class
Enable optimizations, potentially generating more efficient code.Auto (Individual mappings only)
For data elements that cannot be optimized, represent data as a field of a standard data structure.Default (Default mapping only)
Prevent optimizations from eliminating storage for a data element and use the default mapping for the data element category.Model Default (Individual mappings only) , Dictionary Default (Individual mappings only)
Generate a structure that stores Boolean data in named bitfields.Bitfield (Individual mappings only)
Generate a global variable definition and declaration that has the volatile type qualifier.Volatile (See Const, Volatile, and ConstVolatile)
Generate a global variable definition and declaration.ExportedGlobal
Generate a global variable definition and declaration to a specified file.ExportToFile
Generate code that interacts with data by calling your custom accessor functions.GetSet
Generate code that reads from and writes to a global variable or global variable pointer defined by your external code.ImportedExtern, ImportedExternPointer
Generate code that reads from and writes to a global variable defined by your external header file.ImportFromFile
Generate variables that are local to functions.Localizable
Generate a global structure that has a name, which you can specify.Struct (Individual mappings only)

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 Storage Classes, Memory Sections, and Function Templates for Software Architecture.

For an individual outport, use the Identifier storage class property to configure a name for the variable representing the outport in the generated code. With Embedded Coder, depending on the storage class that you choose, you can also configure these properties.

PropertyDescriptionStorage Classes
DefinitionFileSource definition file that contains definitions for global data, which is read by the outport and external codeExportToFile and Volatile
GetFunctionOutport appears in the generated code as a call to a specified get functionGetSet
HeaderFileName of generated source header file that contains declarations for global data, which is written by the outport and external codeExportToFile, GetSet, ImportFromFile, and Volatile
Memory Section (default outport configuration only)Memory section that contains data written by the outportDefault
OwnerCode generator places the definition for outports in the code generated for one of multiple models in a model hierarchy that share definitions. You must select the model configuration parameter Use owner from data object for data definition placement. See Control Placement of Global Data Definitions and Declarations in Generated Files.ExportToFile and Volatile
PreserveDimensionsCode generator preserves dimensions of outport data that is represented in generated code as a multidimensional array. You must set model configuration parameter Array layout to Row-major. See Preserve Dimensions of Multidimensional Arrays in Generated Code.ExportToFile, ImportFromFile, Localizable, and Volatile
SetFunctionOutport appears in the generated code as a call to a specified set function.GetSet
StructNameName for a structure in the generated code for outport.BitField and Struct

See Also

|

Related Topics