Main Content

Configure STF-Related Code Generation Parameters

Many model configuration parameters for code generation are specific to GRT, ERT, or ERT-based system target files.

Specify Generated Code Interfaces

Use interface model configuration parameters to control which libraries to use when generating code, whether to include support for an API in generated code, and other interface options.

To...Select or Enter...
Specify the language standard that the code generator uses when generating code.

Select C89/C90 (ANSI), C99 (ISO), or C++03 (ISO) for the Language standard parameter.

Selecting C89/C90 (ANSI) provides the ANSI®a C set of library functions. For example, selecting C89/C90 (ANSI) results in generated code that calls sin() whether the input argument is double precision or single precision. However, if you select C99 (ISO), the generated code calls the function sinf() when the input argument is single precision. If your compiler supports the ISO®b C math extensions, selecting the ISO C library can result in more efficient code.

For more information, see Language standard.

The options for this parameter have dependencies. See Interface Dependencies.

Specify an application-specific library that the code generator uses when generating code.

If you generate application-specific C or C++ code for math functions or operations, select a value for Code replacement library. Otherwise, specify None.

For more information about code replacement libraries, see Choose a Code Replacement Library and Code replacement library.

The options for this parameter have dependencies. See Interface Dependencies.

Direct where the code generator places fixed-point and other utility code.

Select Auto or Shared location for Shared code placement. The shared location directs code for utilities to be placed within the slprj folder in your working folder, which is used for building referenced models. If you select Auto,

  • When the model contains Model blocks, places utility code within the slprj/target/_sharedutils folder.

  • When the model does not contain Model blocks, places utility code in the build folder (generally, in model.c or model.cpp).

Specify text to be added to the variable names used when logging data to MAT-files and to distinguish logging data from code generation and simulation applications.

Enter a prefix or suffix, such as rt_ or _rt, for the MAT-file variable name modifier parameter. The code generator prefixes or appends the text to the variable names for system outputs, states, and simulation time specified in the Data Import/Export pane. See Log Program Execution Results for information on MAT-file data logging.

Specify data exchange APIs to be included in generated code.

Select one or more C API options, the ASAP2 interface option, or the External mode option. When you select External mode, other options appear. The data exchange APIs are independent, and you can select combinations of these APIs. For example, you could choose C API and external mode.

For more information on working with these interfaces, see Exchange Data Between Generated and External Code Using C API, Export ASAP2 File for Data Measurement and Calibration, and External Mode Simulations for Parameter Tuning, Signal Monitoring, and Code Execution Profiling.

The options for this parameter have dependencies. See Interface Dependencies.

a ANSI is a registered trademark of the American National Standards Institute, Inc.

b ISO is a registered trademark of the International Organization for Standardization.

Note

Before setting Language standard or Code replacement library, verify that your compiler supports the library you want to use. If you select a parameter value that your toolchain does not support, compiler errors can occur. For example, if you select the language standard C99 (ISO) and your compiler does not support the ISO C math extensions, compile-time errors could occur.

When the Embedded Coder® product is installed on your system, the Code Generation > Interface pane expands to include several additional options. For descriptions of Code Generation > Interface pane parameters, see Model Configuration Parameters: Code Generation Interface.

Several interface parameters have dependencies on settings of other parameters. The following table summarizes the dependencies.

Interface Dependencies

ParameterDependencies?Dependency Details
Language standardYesAvailable values depend on Language selection.
Code replacement libraryYesAvailable values depend on product licensing and other parameters. For more information, see Code replacement library.
Shared code placementNo 
Support: floating-point numbers (ERT system target files only)No 
Support: non-finite numbersYes (ERT)
No (GRT)
For ERT system target files, enabled by Support floating-point numbers
Support: complex numbers (ERT system target files only)No 
Support: absolute time (ERT system target files only)No 
Support: continuous time (ERT system target files only)YesRequires that you disable Remove error status field in real-time model data structure.
Support: non-inlined S-functions (ERT system target files only)YesRequires that you enable Support floating-point numbers and Support non-finite numbers
Classic call interfaceYesRequires that you disable Single output/update function. For ERT system target files, requires that you enable Support floating-point numbers.
Single output/update functionYesDisable for Classic call interface
Terminate function required (ERT system target files only)Yes 
Code interface packagingYesAvailable values depend on Language selection.
Multi-instance code error diagnosticYesSet Code interface packaging to Reusable function or C++ class
Pass root-level I/O as (ERT system target files only)YesSet Code interface packaging to Reusable function
Use dynamic memory allocation for model initialization (ERT system target files only)YesSet Code interface packaging to Reusable function
MAT-file logging YesFor GRT system target files, requires that you enable Support non-finite numbers; for ERT system target files, requires that you enable Support floating-point numbers, Support non-finite numbers, and Terminate function required
MAT-file file variable name modifierYesEnabled by MAT-file logging
Remove error status field in real-time model data structure (ERT system target files only)YesRequires that you disable Support: continuous time.
Generate C API for: signalsNo 
Generate C API for: parametersNo 
Generate C API for: statesNo 
Generate C API for: root-level I/ONo 
ASAP2 interfaceNo 
External modeNo 
Transport layer YesEnable External mode
MEX-file argumentsYesEnable External mode
Static memory allocationYesEnable External mode
Static memory buffer sizeYesEnable Static memory allocation

Configure Numeric Data Support

By default, ERT system target files support code generation for integer, floating-point, nonfinite, and complex numbers.

To Generate Code That Supports...Do...
Integer data onlyClear Support floating-point numbers. If noninteger data or expressions are encountered during code generation, an error message reports the offending blocks and parameters.
Floating-point data

Select Support floating-point numbers.

Nonfinite values (for example, NaN, Inf)

Select Support floating-point numbers and Support non-finite numbers.

Complex data

Select Support complex numbers.

For more information, see Model Configuration Parameters: Code Generation Interface.

Configure Time Value Support

Certain blocks require the value of absolute time, elapsed time, or continuous time. Absolute time is the time from the start of program execution to the present time. Elapsed time is the time elapsed between two trigger events. Depending on the blocks used, your model could require adjustment of the configuration settings for supported time values.

To...Select...
Generate code that creates and maintains integer counters for blocks that use absolute or elapsed time values (default).

Support absolute time. For further information on the allocation and operation of absolute and elapsed timers, see Absolute and Elapsed Time Computation. If you do not select this parameter and the model includes a block that uses absolute or elapsed time values, the build process generates an error.

Generate code for blocks that rely on continuous time.

Support continuous time. If you do not select this parameter and the model includes continuous-time blocks, the build process generates an error.

For more information, see Model Configuration Parameters: Code Generation Interface.

Configure Noninlined S-Function Support

To generate code for noninlined S-Functions in a model, select Support noninlined S-functions. The generation of noninlined S-functions requires floating-point and nonfinite numbers. Thus, when you select Support non-inlined S-functions, the ERT system target file selects Support floating-point numbers and Support non-finite numbers.

When you select Support non-finite numbers and the model includes a C MEX S-function that does not have a corresponding TLC implementation (for inlining code generation), the build process generates an error.

Inlining S-functions is highly advantageous in production code generation, for example in implementing device drivers. To enforce the use of inlined S-functions for code generation, clear Support non-inlined S-functions.

When generating code for a model that contains noninlined S-functions with an ERT system target file, there can be a mismatch between the simulation and code generation results when either of the following is true:

  • Model configuration parameter GenCodeOnly is set to off.

  • Model configuration parameter ProdEqTarget is set to off.

To avoid such a mismatch, set ProdEqTarget to on or set GenCodeOnly to on.

Configure Model Function Generation and Argument Passing

For ERT system target files, you can configure model for how functions are generated and how arguments are passed to the functions.

To...Do...
Generate model function calls that are compatible with the main program module of the pre-R2012a GRT system target file (grt_main.c or .cpp).

Select Classic call interface and MAT-file logging. In addition, clearing Remove error status field in real-time model data structure. Classic call interface provides a quick way to use code generated in R2012a or higher with a pre-R2012a GRT-based custom system target file by generating wrapper function calls that interface to the generated code.

Reduce overhead and use more local variables by combining the output and update functions in a single model_step function.

Select Single output/update function

Errors or unexpected behavior can occur if a Model block is part of a cycle and the model configuration enables Single output/update function (the default). For more information about direct feed through, see Algebraic Loop Concepts.

Generate a model_terminate function for a model not designed to run indefinitely.

Select Terminate function required. For more information, see the description of model_terminate.

Generate reusable, reentrant code from a model or subsystem.

Select Generate reusable code. See Configure Code Reuse Support for details.

Statically allocate model data structures and access them directly in the model code.

Clear Generate reusable code. The generated code is not reusable or reentrant. See Configure Generated C Function Interface for Model Entry-Point Functions for information on the calling interface generated for model functions in this case.

Suppress the generation of an error status field in the real-time model data structure, rtModel, for example, if you do not require to log or monitor error messages.

Select Remove error status field in real-time model data structure. Selecting this parameter can also cause the code generator to omit the rtModel structure from the generated code.

When generating code for multiple integrated models, set this parameter the same for all of the models. Otherwise, the integrated application could exhibit unexpected behavior. For example, if you select the option in one model but not in another, it is possible that the integrated application could not register the error status.

Do not select this parameter if you select the MAT-file logging option. The two options are incompatible.

Open the Configure C Step Function Interface dialog box and modify the model_step function prototype.

In the Code Mapping Editor, on the Entry-Point Functions tab, click in the Function Name column for the base-rate step function. Click the three vertical dots that appear. Then click Configure Prototype. Unless a function prototype was previously configured, the dialog box opens showing a preview of the step function interface without arguments (void-void). The dialog box also shows the current function name. If arguments have previously been configured for the model, the dialog box displays the current settings. You can change the name and argument settings for the step function. For more information, see Configure Name and Arguments for Individual Step Functions.

For more information, see Model Configuration Parameters: Code Generation Interface.

Configure Code Reuse Support

For GRT, ERT, GRT-based, and ERT-based system target files, you can configure how a model reuses code by setting the Code interface packaging configuration parameter value to Reusable function.

The Pass root-level I/O as configuration parameter provides options that control how model inputs and outputs at the root level of the model are passed to the model_step function.

To...Select...
Pass each root-level model input and output argument to the model_step function individually (the default)Code interface packaging > Reusable function and Pass root-level I/O as > Individual arguments.
Pack root-level input arguments and root-level output arguments into separate structures that are then passed to the model_step functionCode interface packaging > Reusable function and Pass root-level I/O as > Structure reference.

Pack root-level input arguments and root-level output arguments into the model data structure to support reentrant multi-instance code from a model for ERT system target file

Code interface packaging > Reusable function and Pass root-level I/O as > Part of model data structure.

If using the Code interface packaging > Reusable function selection, consider using the Use dynamic memory allocation for model initialization option to control whether an allocation function is generated. This option applies for ERT system target files.

Sometimes, selecting Code interface packaging as Reusable function can generate code that compiles but is not reentrant. For example, if a signal, DWork structure, or parameter data has a storage class other than Auto, global data structures are generated. To handle such cases, use the Multi-instance code error diagnostic parameter to choose the severity levels for diagnostics.

Sometimes, the code generator is unable to generate valid and compilable code. For example, if the model contains one of the following, the generated code is invalid.

  • An S-function that is not code-reuse compliant

  • A subsystem triggered by a wide function-call trigger

In these cases, the build terminates after reporting the problem.

For more information, see Generate Reentrant Code from Top Models and Model Configuration Parameters: Code Generation Interface.

Related Topics