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 Write External Code to Access Generated C API Code, 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

Parameter	Dependencies?	Dependency Details
Language standard	Yes	Available values depend on Language selection.
Code replacement library	Yes	Available values depend on product licensing and other parameters. For more information, see Code replacement library.
Shared code placement	No
Support: floating-point numbers (ERT system target files only)	No
Support: non-finite numbers	Yes (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)	Yes	Requires that you disable Remove error status field in real-time model data structure.
Support: non-inlined S-functions (ERT system target files only)	Yes	Requires that you enable Support floating-point numbers and Support non-finite numbers
Terminate function required (ERT system target files only)	Yes
Code interface packaging	Yes	Available values depend on Language selection.
Multi-instance code error diagnostic	Yes	Set Code interface packaging to `Reusable function` or `C++ class`
Pass root-level I/O as (ERT system target files only)	Yes	Set Code interface packaging to `Reusable function`
Use dynamic memory allocation for model initialization (ERT system target files only)	Yes	Set Code interface packaging to `Reusable function`
MAT-file logging	Yes	For 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 modifier	Yes	Enabled by MAT-file logging
Remove error status field in real-time model data structure (ERT system target files only)	Yes	Requires that you disable Support: continuous time.
Generate C API for: signals	No
Generate C API for: parameters	No
Generate C API for: states	No
Generate C API for: root-level I/O	No
ASAP2 interface	No
External mode	No
Transport layer	Yes	Enable External mode
MEX-file arguments	Yes	Enable External mode
Static memory allocation	Yes	Enable External mode
Static memory buffer size	Yes	Enable 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 only	Clear 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 Timer Representation and 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 MAT-file logging. Clear Remove error status field in real-time model data structure.
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` function	Code 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.