| Real-Time Workshop® Embedded Coder™ | |
The Browse button in the Target Selection subpane of the Real-Time Workshop > General pane lets you select an ERT target with the System Target File Browser. See Choosing and Configuring Your Target in the Real-Time Workshop® documentation for a general discussion of target selection.
To make it easier for you to generate code that is optimized for your target hardware, the code generator provides three variants of the ERT target that
Automatically configure parameters that are optimized for fixed-point code generation
Automatically configure parameters that are optimized for floating-point code generation
Applies default parameter settings
The discussion throughout this chapter assumes use of the default ERT target.
These targets are based on a common system target file, ert.tlc. They are displayed in the System Target File Browser as shown in the figure below.
The optimized ERT target variants are discussed in detail in Generating Efficient Code with Optimized ERT Targets.
You can implement a custom auto-configuring target, using the same mechanism used by the optimized ERT target variants. Auto-Configuring Models for Code Generation discusses the auto-configuration mechanism and utilities used by the optimized ERT target variants.
You can use the ert_shrlib.tlc target to generate a host-based shared library from your Simulink® model. Selecting this target allows you to generate a shared library version of your model code that is appropriate for your host platform, either a Microsoft® Windows® dynamic link library (.dll) file or a UNIX®[1] shared object (.so) file. This feature can be used to package your source code securely for easy distribution and shared use. For more information, see Creating and Using Host-Based Shared Libraries.
Real-Time Workshop® Embedded Coder™ software extends the HTML code generation report that gets generated when you select the Create code generation report parameter. When you select this parameter for an ERT target, the parameters Code-to-model and Model-to-code appear. If you select these additional parameters, the HTML report includes hyperlinks from the code to the generating blocks in the model and right-clicking on the blocks in the model brings you to the code for that block. You can use these links to verify traceability of the generated code to the model.
For very large models (containing over 1000 blocks) generation of the hyperlinks can be time consuming. Therefore, if you do not have a need for traceability or after verifying the traceability of you generated code, consider disabling the parameter to speed up code generation.
For more information, see Code-to-model and Model-to-code in the Real-Time Workshop reference documentation.
You can customize the comments in the generated code for ERT targets by setting or clearing several parameters on the Real-Time Workshop > Comments pane. These options let you enable or suppress generation of descriptive information in comments for blocks and other objects in the model.
| To... | Select... |
|---|---|
| Include the text specified in the Description field of a block's Block Properties dialog box as comments in the code generated for each block | Simulink block descriptions. |
| Add a comment that includes the blockname at the start of the code for each block | Simulink block descriptions |
| Include the text specified in the Description field of a Simulink data object (such as a signal, parameter, data type, or bus) in the Simulink Model Explorer as comments in the code generated for each object | Simulink data object descriptions. |
| Include comments just above signals and parameter identifiers in the generated code as specified in an M-code or TLC function. | Custom comments (MPT objects only). |
| Include the text specified in the Description field of the Properties dialog box for a Stateflow® object as comments just above the code generated for each object | Stateflow object descriptions. |
| Include requirements assigned to Simulink blocks in the generated code comments (for more information, see Including Requirements with Generated Code in the Simulink® Verification and Validation™ documentation) | Requirements in block comments. |
When you select Simulink block descriptions,
The description text for blocks and Stateflow objects and block names generated as comments can include international (non-US-ASCII) characters. (For details on international character support, see Support for International (Non-US-ASCII) Characters in the Real-Time Workshop documentation.)
For virtual blocks or blocks that have been removed due to block reduction, no comments are generated.
For more information, see Real-Time Workshop Pane: Comments in the Real-Time Workshop reference documentation.
Several parameters are available for customizing generated symbols.
| To... | Specify... |
|---|---|
| Define a macro string that specifies whether, and in what order, certain substrings are included within generated identifiers for global variables, global types, field names of global types, subsystem methods, local temporary variables, local block output variables, and constant macros | The macro string with the Identifier format control parameter (for details on how to specify formats, see Specifying Identifier Formats and for limitations, see Identifier Format Control Parameters Limitations). |
| Specify the minimum number of characters the code generator uses for mangled symbols | Specify an integer value for the Minimum mangle length (for details, see Name Mangling). |
| Specify the maximum number of characters the code generator can use for function, typedef, and variable names (default 31) | Specify an integer value for the Maximum identifier length. If you expect your model to generate lengthy identifiers (due to use of long signal or parameter names, for example), or you find that identifiers are being mangled more than expected, you should increase the value of this parameter. |
| Control whether scalar inlined parameter values are expressed in generated code as literal values or macros | The value Literals or Macros for the Generate scalar inlined parameters as parameter .
|
For more information, see Real-Time Workshop Pane: Symbols in the Real-Time Workshop reference documentation.
| To Define Rules that Change the Names of a Model's... | Specify a Naming Rule with the ... |
|---|---|
| Signals | Signal naming parameter |
| Parameters | Parameter naming parameter |
| Parameters that have a storage class of Define | #define naming parameter |
For more information on these parameters, see Specifying Simulink® Data Object Naming Rules in the Real-Time Workshop Embedded Coder Module Packaging Features document.
The Identifier format control parameters let you customize generated identifiers by entering a macro string that specifies whether, and in what order, certain substrings are included within generated identifiers. For example, you can specify that the root model name be inserted into each identifier.
The macro string can include
Tokens of the form $X, where X is a single character. Valid tokens are listed in Identifier Format Tokens. You can use or omit tokens as you want, with the exception of the $M token, which is required (see Name Mangling) and subject to the use and ordering restrictions noted in Identifier Format Control Parameter Values.
Any valid C or C++ language identifier characters (a-z, A-Z, _ , 0-9).
The build process generates each identifier by expanding tokens (in the order listed in Identifier Format Tokens) and inserting the resultant strings into the identifier. Character strings between tokens are simply inserted directly into the identifier. Contiguous token expansions are separated by the underscore (_) character.
Identifier Format Tokens
| Token | Description |
|---|---|
| $M | Insert name mangling string if required to avoid naming collisions (see Name Mangling). Note: This token is required. |
| $F | Insert method name (for example, _Update for update method). This token is available only for subsystem methods. |
| $N | Insert name of object (block, signal or signal object, state, parameter or parameter object) for which identifier is being generated. |
| $R | Insert root model name into identifier, replacing any unsupported characters with the underscore (_) character. Note that when using model referencing, this token is required in addition to $M (see Model Referencing Considerations). Note: This token replaces the Prefix model name to global identifiers option used in previous releases. |
| $H | Insert tag indicating system hierarchy level. For root-level blocks, the tag is the string root_. For blocks at the subsystem level, the tag is of the form sN_, where N is a unique system number assigned by the Simulink software. This token is available only for subsystem methods and field names of global types. Note: This token replaces the Include System Hierarchy Number in Identifiers option used in previous releases. |
| $A | Insert data type acronym (for example, i32 for long integers) to signal and work vector identifiers. This token is available only for local block output variables and field names of global types. Note: This token replaces the Include data type acronym in identifier option used in previous releases. |
Identifier Format Control Parameter Values lists the default macro string, the supported tokens, and the applicable restrictions for each Identifier format control parameter.
Identifier Format Control Parameter Values
| Parameter | Default Value | Supported Tokens | Restrictions |
|---|---|---|---|
| Global variables | $R$N$M | $R, $N, $M | $F, $H, and $A are disallowed. |
| Global types | $N$R$M | $N, $R, $M | $F, $H, and $A are disallowed. |
| Field name of global types | $N$M | $N, $M, $H, $A | $R and $F are disallowed. |
| Subsystem methods | $R$N$M$F | $R, $N, $M, $F, $H | $F and $H are empty for Stateflow functions; $A is disallowed. |
| Local temporary variables | $N$M | $N, $M, $R | $F, $H, and $A are disallowed. |
| Local block output variables | rtb_$N$M | $N, $M, $A | $R, $F, and $H are disallowed. |
| Constant macros | $R$N$M | $R, $N, $M | $F, $H, and $A are disallowed. |
Non-ERT based targets (such as the GRT target) implicitly use a default $R$N$M specification. This specifies identifiers consisting of the root model name, followed by the name of the generating object (signal, parameter, state, and so on), followed by a name mangling string (see Name Mangling).
For limitations that apply to Identifier format control parameters, see Identifier Format Control Parameters Limitations.
In identifier generation, a circumstance that would cause generation of two or more identical identifiers is called a name collision. Name collisions are never permissible. When a potential name collision exists, unique name mangling strings are generated and inserted into each of the potentially conflicting identifiers. Each name mangling string is guaranteed to be unique for each generated identifier.
The position of the $M token in the Identifier format control parameter specification determines the position of the name mangling string in the generated identifiers. For example, if the specification $R$N$M is used, the name mangling string is appended (if required) to the end of the identifier.
The Minimum mangle length parameter specifies the minimum number of characters used when a name mangling string is generated. The default is 1 character. As described below, the actual length of the generated string may be longer than this minimum.
An important aspect of model based design is the ability to generate identifiers that can easily be traced back to the corresponding entities within the model. To ensure traceability, it is important to make sure that incremental revisions to a model have minimal impact on the identifier names that appear in generated code. There are two ways of achieving this:
When conflicts cannot be avoided (as may be the case in models that use libraries or model reference), name mangling ensures traceability. The position of the name mangling string is specified by the placement of the $M token in the Identifier format control parameter specification. Mangle characters consist of lower case characters (a-z) and numerics (0-9), which are chosen with a checksum that is unique to each object. How Name Mangling Strings Are Computed describes how this checksum is computed for different types of objects.
How Name Mangling Strings Are Computed
| Object Type | Source of Mangling String |
|---|---|
Block diagram | Name of block diagram |
Simulink block | Full path name of block |
Simulink parameter | Full name of parameter owner (that is, model or block) and parameter name |
Simulink signal | Signal name, full name of source block, and port number |
Stateflow objects | Complete path to Stateflow block and Stateflow computed name (unique within chart) |
The length of the name mangling string is specified by the Minimum mangle length parameter. The default value is 1, but this automatically increases during code generation as a function of the number of collisions.
To minimize disturbance to the generated code during development, specify a larger Minimum mangle length. A Minimum mangle length of 4 is a conservative and safe value. A value of 4 allows for over 1.5 million collisions for a particular identifier before the mangle length is increased.
Note that the length of generated identifiers is limited by the Maximum identifier length parameter. When a name collision exists, the $M token is always expanded to the minimum number of characters required to avoid the collision. Other tokens and character strings are expanded in the order listed in Identifier Format Tokens. If the Maximum identifier length is not large enough to accommodate full expansions of the other tokens, partial expansions are used. To avoid this outcome, it is good practice to
Avoid name collisions in general. One way to do this is to avoid using default block names (for example, Gain1, Gain2...) when there are many blocks of the same type in the model.
Where possible, increase the Maximum identifier length to accommodate the length of the identifiers you expect to generate.
Set the Minimum mangle length parameter to reserve at least three characters for the name mangling string. The length of the name mangling string increases as the number of name collisions increases.
Note that an existing name mangling string increases (or decreases) in length if changes to model create more (or fewer) collisions. If the length of the name mangling string increases, additional characters are appended to the existing string. For example, 'xyz' might change to 'xyzQ'. In the inverse case (fewer collisions) 'xyz' would change to 'xy'.
Within a model that uses model referencing, there can be no collisions between the names of the constituent models. When generating code from a model that uses model referencing:
The $R token must be included in the Identifier format control parameter specifications (in addition to the $M token).
The Maximum identifier length must be large enough to accommodate full expansions of the $R and $M tokens. A code generation error occurs if Maximum identifier length is not large enough.
When a name conflict occurs between an identifier within the scope of a higher-level model and an identifier within the scope of a referenced model, the identifier from the referenced model is preserved. Name mangling is performed on the identifier from the higher-level model.
There are some exceptions to the identifier formatting conventions described above:
Type name generation: The above name mangling conventions do not apply to type names (that is, typedef statements) generated for global data types. If the $R token is included in the Identifier format control parameter specification, the model name is included in the typedef. The Maximum identifier length parameter is not respected when generating type definitions.
Non-Auto storage classes: The Identifier format control parameter specification does not affect objects (such as signals and parameters) that have a storage class other than Auto (such as ImportedExtern or ExportedGlobal).
The following limitations apply to the Identifier format control parameters:
The following auto-generated identifiers currently do not fully comply with the setting of the Maximum identifier length parameter on the Real-Time Workshop/Symbols pane of the Configuration Parameters dialog box.
Model methods
The applicable format string is $R$F, and the longest $F is _derivatives, which is 12 characters long. The model name can be up to 19 characters without exceeding the default Maximum identifier length of 31.
Local functions generated by S-functions or by add-on products, such as the Signal Processing Blockset™ product, that rely on S-functions
Local variables generated by S-functions or by add-on products, such as the Signal Processing Blockset product, that rely on S-functions
DWork identifiers generated by S-functions in referenced models
Fixed-point shared utility macros or shared utility functions
Simulink rtm macros
Most are within the default Maximum identifier length of 31, but some exceed the limit. Examples are RTMSpecAccsGetStopRequestedValStoredAsPtr, RTMSpecAccsGetErrorStatusPointer, and RTMSpecAccsGetErrorStatusPointerPointer.
Define protection guard macros
Header file guards, such as _RTW_HEADER_$(filename)_h_, which can exceed the default Maximum identifier length of 31 given a filename such as $R_private.h.
Include file guards, such as _$R_COMMON_INCLUDES_.
Typedef guards, such as _CSCI_$R_CHARTSTRUCT_.
In some situations, the following identifiers potentially can conflict with others.
Model methods
Local functions generated by S-functions or by add-on products, such as Signal Processing Blockset product, that rely on S-functions
Local variables generated by S-functions or by add-on products, such as Signal Processing Blockset product, that rely on S-functions
Fixed-point shared utility macros or shared utility functions
Include header guard macros
The following external identifiers that are unknown to the Simulink software might conflict with auto-generated identifiers.
Identifiers defined in custom code
Identifiers defined in custom header files
Identifiers introduced through a non-ANSI®[2] C standard library
Identifiers defined by custom TLC code
Identifiers generated for simulation targets may exceed the Maximum identifier length. Simulation targets include the model reference simulation target, the accelerated simulation target, the RSim target, and the S-function target.
In addition to the interface parameters available for GRT targets, you can configure the following for ERT targets:
By default, ERT targets support code generation for integer, floating-point, non-finite, and complex numbers.
For more information, see Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation.
Certain blocks require the value of absolute time (that is, the time from the start of program execution to the present time) , elapsed time (for example, the time elapsed between two trigger events), or continuous time. Depending on the blocks used, you might need to adjust 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 the Timing Services chapter of the Real-Time Workshop documentation. If you do not select this parameter and the model includes block that use 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 Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation.
To generate code for non-inlined S-functions in a model, select Support non-inlined S-functions. The generation of non-inlined S-functions requires floating-point and non-finite numbers. Thus, when you select Support non-inlined S-functions, the ERT target automatically selects Support floating-point numbers and Support non-finite numbers.
When you select Support non-finite numbers, the build process generates an error if the model includes a C-MEX S-function that does not have a corresponding TLC implementation (for inlining code generation).
Note that 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, deselect Support non-inlined S-functions.
For more information, see Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation.
For ERT targets, you can configure how a model's 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 GRT target (grt_main.c or .cpp) | Select GRT compatible call interface and MAT-file logging . In addition, deselect Suppress error status in real-time model data structure. GRT compatible call interface provides a quick way to use ERT target features with a GRT-based custom target by generating wrapper function calls that interface to the ERT target's Embedded-C formatted 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 Single output/update function is enabled (the default). See Model Blocks and Direct Feedthrough for details. |
| 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 Configuring a Model for Code Reuse for details. |
| Statically allocate model data structures and access them directly in the model code | Deselect Generate reusable code. The generated code is not reusable or reentrant. See Model Entry Points 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 need to log or monitor error messages | Select Suppress error status in real-time model data structure. Selecting this parameter can also cause the rtModel structure to be omitted completely 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 might exhibit unexpected behavior. For example, if you select the option in one model but not in another, the error status might not be registered by the integrated application. Do not select this parameter if you select the MAT-file logging option. The two options are incompatible. |
| Launch the Model Interface dialog box (see Model Interface Dialog Box) preview and modify the model's model_step function prototype | Click Configure Step Function. Based on the Function specification value you select for your model_step function (supported values include Default model-step function and Model specific C prototype), you can preview and modify the function prototype. Once you validate and apply your changes, you can generate code based on your function prototype modifications. For more information about using the Configure Step Function button and the Model Interface dialog box, see Controlling model_step Function Prototypes. |
For more information, see Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation.
For ERT targets, you can configure how a model reuses code using the Generate reusable code parameter.
Pass root-level I/O as 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) | Generate reusable code 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 | Generate reusable code and Pass root-level I/O as > Structure reference |
In some cases, selecting Generate reusable code can generate code that compiles but is not reentrant. For example, if any signal, DWork structure, or parameter data has a storage class other than Auto, global data structures are generated. To handle such cases, use the Reusable code error diagnostic parameter to choose the severity levels for diagnostics
In some cases, the Real-Time Workshop Embedded Coder software is unable to generate valid and compilable code. For example, if the model contains any of the following, the code generated would be 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 Real-Time Workshop Pane: Interface in the Real-Time Workshop reference documentation.
You can control the following style aspects in generated code:
Level of parenthesization
Whether operand order is preserved in expressions
Whether conditions are preserved in if statements
For example, C code contains some syntactically required parentheses, and can contain additional parentheses that change semantics by overriding default operator precedence. C code can also contain optional parentheses that have no functional significance, but serve only to increase the readability of the code. Optional C parentheses vary between two stylistic extremes:
Include the minimum parentheses required by C syntax and any precedence overrides, so that C precedence rules specify all semantics unless overridden by parentheses.
Include the maximum parentheses that can exist without duplication, so that C precedence rules become irrelevant: parentheses alone completely specify all semantics.
Understanding code with minimum parentheses can require correctly applying nonobvious precedence rules, but maximum parentheses can hinder code reading by belaboring obvious precedence rules. Various parenthesization standards exist that specify one or the other extreme, or define an intermediate style that can be useful to human code readers.
You control the code style options by setting parameters on the Real-Time Workshop > Code Style pane. For details on the parameters, see Real-Time Workshop Pane: Code Style in the Real-Time Workshop Embedded Coder reference documentation.
Code and data templates provide a way to customize generated code.
| To... | Enter or Select... |
|---|---|
| Specify a template that defines the top-level organization and formatting of generated source code (.c or .cpp) files | Enter a code generation template (CGT) file for the Source file (*.c) template parameter. . |
| Specify a template that defines the top-level organization and formatting of generated header (.h) files | Enter a CGT file for the Header file
(*.h) template parameter. This can be the same template
file that you specify for Source file (.c) template,
in which case identical banners are generated in source and header
files. The default template is matlabroot /toolbox/rtw/targets/ecoder/ert_code_template.cgt. |
| Specify a template that organizes generated code into sections (such as includes, typedefs, functions, and more) | Enter a custom file processing (CFP) template file for the File customization template parameter. . A CFP template can emit code, directives, or comments into each section as required. See Custom File Processing for detailed information. |
| Generate a model-specific example main program module | Select Generate an example main program. See Generating the Main Program Module for more information. |
Template files that you specify must be located on the MATLAB® path.
For more detail, see the Module Packaging Features document. See also Generating Custom File Banners for a simple example of how a code template can be applied to generate customized comment sections in generated code files.
| To... | Select or Enter... |
|---|---|
| Specify whether data is to be defined in the generated source file or in a single separate header file | Select Auto, Data defined in source file, or Data defined in single separate source file for the Data definition parameter. |
| Specify whether data is to be declared in the generated source file or in a single separate header file | Select Auto, Data defined in source file, or Data defined in single separate source file for the Data declaration parameter. |
| Specify the #include file delimiter to be used in generated files that contain the #include preprocessor directive for mpt data objects | Select Auto, Data defined in source file, or Data defined in single separate source file for the #include file delimiter parameter. |
| Name the generated module using the same name as the model or a user-specified name | Select Not specified, Same as model, or User specified for the Module naming parameter. |
| Control whether signal data objects are to be declared as global data in the generated code | Enter an integer value for the Signal display level parameter. |
| Declare a parameter data object as tunable global data in the generated code | Enter an integer value for the Parameter tune level parameter. |
For details data placement, see the Module Packaging Features document.
You can replace built-in data type names with user-defined replacement data type names in the generated code for a model.
To configure replacement data types,
Click Replace data type names in the generated code. A Data type names table appears. The table lists each Simulink built-in data type name with its corresponding Real-Time Workshop data type name.
Selectively fill in fields in the third column with your replacement data types. Each replacement data type should be the name of a Simulink.AliasType object that exists in the base workspace. Replacements may be specified or not for each individual built-in type.
For each replacement data type you enter, the BaseType property of the associated Simulink.AliasType object must be consistent with the built-in data type it replaces.
For double, single, int32, int16, int8, uint32, uint16, uint8, and boolean, the replacement data type's BaseType must match the built-in data type.
For int, uint, and char, the replacement data type's size must match the size displayed for int or char on the Hardware Implementation pane of the Configuration Parameters dialog box.
An error occurs if a replacement data type specification is inconsistent. For more information, see Replacing Built-In Data Type Names in Generated Code in the Module Packaging Features document.
You can configure a model such that the generated code includes comments and pragmas for
Data defined in custom storage classes
Internal data not defined in custom storage classes
Model-level functions
Atomic subsystem functions with or without separate data
| To... | Select... |
|---|---|
| Specify the package that contains memory sections that you want to apply | The name of a package for Package. Click Refresh package list to refresh the list of available packages in your configuration. |
| Apply memory sections to initialize/start and terminate functions | A value for Initialize/Terminate. |
| Apply memory sections to step, run-time initialization, derivative, enable, and disable functions | A value for Execution. |
| Apply memory sections to constant parameters, constant, block I/O, or zero representation | A value for Constants. |
| Apply memory sections to root inputs or outputs | A value for Inputs/Outputs. |
| Apply memory sections to block I/O, Dwork vectors, run-time models, zero-crossings | A value for Internal data. |
| Apply memory sections to parameters | A value for Parameters. |
The interface checks whether the specified package is on the MATLAB path and that the selected memory sections are in the package. The results of this validation appear in the field Validation results.
For details on using memory sections, see Memory Sections.
| To... | Select or Specify... |
|---|---|
| Control whether parameter data for reusable subsystems is generated in a separate header file for each subsystem or in a single parameter data structure | Select Hierarchical or NonHierarchical for Parameter structure. |
| Generate initialization code for root-level inports and outports with a value of zero | Select Remove root level I/O zero initialization. |
| Generate additional code to set float and double storage explicitly to value 0.0 | Select Use memset to initialize floats and doubles to 0.0 When you set this parameter, the memset function
clears internal storage (regardless of type) to the integer bit pattern 0 (that
is, all bits are off). The additional code generated when the option
is off, is slightly less efficient. If the representation of floating-point zero used by your compiler and target CPU is identical to the integer bit pattern 0, you can gain efficiency by setting this parameter. |
| Suppress the generation of code that initializes internal work structures (for example, block states and block outputs) to zero | Select Remove internal state zero initialization. |
| Generate run-time initialization code for a block that has states only if the block is in a system that can reset its states, such as an enabled subsystem | Select Optimize initialization code for model reference This results in more efficient code, but requires that you not refer to the model from a Model block that resides in a system that resets its states. Such nesting results in an error. Turn this option off only if your application requires you refer to the model from Model blocks in systems that can reset their states. |
| Remove code that ensures that execution of the generated code produces the same results as simulation when out-of-range conversions occur | Select Remove code from floating-point to integer conversions that wraps out-of-range values. This reduces the size and increases the speed of the generated code at the cost of potentially producing results that do not match simulation in the case of out-of-range values. |
| Suppress generation of code that guards against fixed-point division by zero | Select Remove code that protects against division arithmetic exceptions. When you select this parameter, simulation results and results from generated code may no longer be in bit-for-bit agreement. |
| To minimize the amount of memory allocated for absolute and elapsed time counters | Specify an integer value for Application lifespan (days) For more information on the allocation and operation of absolute and elapsed timers, see Timing Services, Using Timers in Asynchronous Tasks, and Controlling Memory Allocation for Time Counters in the Real-Time Workshop documentation. |
[1] UNIX is a registered trademark of The Open Group in the United States and other countries.
[2] ANSI is a registered trademark of the American National Standards Institute, Inc.
| Mapping Application Requirements to Configuration Options | Tips for Optimizing the Generated Code | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |