Version 4.4 (R2006a) Real-Time Workshop Embedded Coder Software :: Real-Time Workshop Embedded Coder Release Notes (Real-Time Workshop® Embedded Coder™)

Learn more about Real-Time Workshop Embedded Coder

Version 4.4 (R2006a) Real-Time Workshop Embedded Coder Software

This table summarizes what's new in Version 4.4 (R2006a):

New Features and Changes	Version Compatibility Considerations	Fixed Bugs and Known Problems	Related Documentation at Web Site
Yes Details below	Yes—Details labeled as Compatibility Considerations, below. See also Summary.	Bug Reports Includes fixes	No

New features and changes introduced in this version are

Nonvirtual Subsystem Option for Generating Modular Function Code

This release provides a new subsystem option, Function with separate data, that allows you to generate modular function code for nonvirtual subsystems, including atomic subsystems and conditionally executed subsystems.

In previous releases, the generated code for a nonvirtual subsystem did not separate a subsystem's internal data from the data of its parent Simulink model. This could make it difficult to trace and test the code, particularly for nonreusable subsystems. Also, in large models containing nonvirtual subsystems, data structures could become large and potentially difficult to compile.

In this release, the Subsystem Parameters dialog box option Function with separate data allows you to generate subsystem function code in which the internal data for a nonvirtual subsystem is separated from its parent model and owned by the subsystem. As a result, the generated code for the subsystem is easier to trace and test. The data separation also tends to reduce the size of data structures throughout the model.

Note Selecting the Function with separate data option for a nonvirtual subsystem has no semantic effect on the parent Simulink model.

To be able to use this option,

Your Simulink model must use an ERT-based system target file (requires a license for Real-Time Workshop Embedded Coder).
Your subsystem must be configured to be atomic or conditionally executed (for more information, see Systems and Subsystems in the Simulink documentation).
Your subsystem must use the Function setting for the Real-Time Workshop system code parameter.

To configure your subsystem for generating modular function code, you invoke the Subsystem Parameters dialog box and make a series of selections to display and enable the Function with separate data option. For details, see Nonvirtual Subsystem Modular Function Code Generation in the Real-Time Workshop Embedded Coder documentation. For limitations that apply, see Nonvirtual Subsystem Modular Function Code Limitations in the Real-Time Workshop Embedded Coder documentation.

For more information about generating code for atomic subsystems, see the sections Creating Subsystems and Generating Code and Executables from Subsystems in the Real-Time Workshop documentation.

Exporting Function-Call Subsystems

This release adds new code generation capabilities for Simulink function-call subsystems. You can use these new capabilities to

Automatically generate code for
- A function-call subsystem that contains only blocks that support code generation
- A virtual subsystem that contains only such subsystems and a few other types of blocks
Optionally generate an ERT S-function wrapper for the generated code

For detailed descriptions of the new exporting capabilities, see Exporting Function-Call Subsystems in the Real-Time Workshop Embedded Coder documentation. For limitations that apply, see Function-Call Subsystems Export Limitations in the Real-Time Workshop Embedded Coder documentation.

Identifier Format Control Parameters for Code Generation

This release adds several Identifier format control parameters that provide you finer control over the naming rules for identifiers created in generated code.

In previous releases, the Symbol format parameter on the Real-Time Workshop/Symbols pane of the Configuration Parameters dialog box allowed you to specify one macro string that affected naming for a range of symbol types. In this release, several Identifier format control parameters allow you to exercise format control individually for

Global variable names
Global type names
Field names of global types
Subsystem method names
Local temporary variable names
Local block output variable names
Constant macro names

To be able to use the new Identifier format control parameters, your Simulink model must use an ERT-based system target file (requires a license for Real-Time Workshop Embedded Coder).

For a description of the new Identifier format control parameters and their use, see Customizing Generated Identifiers and its subsection Specifying Identifier Formats in the Real-Time Workshop Embedded Coder documentation. For limitations that apply, see Identifier Format Control Parameters Limitations in the Real-Time Workshop Embedded Coder documentation. For upgrade and compatibility considerations, see Compatibility Considerations.

Compatibility Considerations

The following considerations for identifier format control apply when upgrading a Simulink model from an earlier release to this release:

Some identifiers that were allowed to exceed the Maximum identifier length (on the Real-Time Workshop/Symbols pane of the Configuration Parameters dialog box) in earlier releases are mangled in this release to conform to the maximum length. The types of identifiers that potentially are affected are Simulink global variables, Simulink global types, local variables, subsystem methods, and Simulink constant macros. The mangling is most likely to occur in models with long names.
To preserve the identifiers, you can increase the Maximum identifier length.
By default, Simulink constant macro names are generated in a different format in this release than in earlier releases.
To restore the earlier identifier format for Simulink constant macro names, you can specify the macro string rtcP$N$M for the Constant macros parameter on the Real-Time Workshop/Symbols pane. However, this setting causes Stateflow constant macros to be generated differently than in earlier releases.
In earlier releases, symbols exported by referenced models were prefixed with the full model name to avoid name collisions between sibling models with similar long names. In this release, the Maximum identifier length is enforced for these exported identifiers, increasing the likelihood of a collision between truncated model names that did not occur in earlier releases.
In this release, the software provides a warning when the current Maximum identifier length cannot accommodate the full model name in the exported identifiers. This warning indicates a potential name collision between sibling models.
To avoid name clashes in models that use model referencing, do one of the following:
- Increase the Maximum identifier length for top and referenced models until the warning disappears. In this case, uniqueness of model names ensures that the exported identifier names do not clash.
- Define a unique identifier naming scheme for each model. For example, you might define the Identifier format control string m1$R$N$M for the first model, m2$R$N$M for the second model, and so forth. In this case, uniqueness of Identifier format control strings ensures that the exported identifier names do not clash.

New and Changed Memory Section Capabilities

This release provides new and changed memory section capabilities in Real-Time Workshop Embedded Coder. In previous releases, memory sections could be applied only to data objects defined in custom storage classes, and memory section pragmas could surround only a contiguous block of all data objects in that section. This release adds enhancements that

Provide an improved user interface for defining memory sections, including a new Memory Sections pane in the Configuration Parameters dialog box.
Support memory sections for
- Model-level functions
- Model-level internal data
- Subsystem functions
- Subsystem internal data
Allow pragmas to be applied separately to each function or data definition. The text of each pragma can contain the name of the definition to which it applies.

For detailed descriptions of the new memory section capabilities, see Configuring Memory Sections and the Inserting Comments and Pragmas in Generated Code chapter in the Real-Time Workshop Embedded Coder documentation.

New sl_customization API for Registering Real-Time Workshop Build Process Hooks

This release introduces an API, exercised through the Simulink customization file sl_customization.m, that allows you to register installation-specific hook functions to be invoked during the Real-Time Workshop build process.

The hook functions that you register through sl_customization.m complement System Target File (STF) hooks (described in Customizing the Target Build Process with the STF_make_rtw Hook File) and post-code generation commands (described in Customizing Post Code Generation Build Processing).

The following figure shows the relationship between installation-level hooks and the other available mechanisms for customizing the build process.

For details on the use of sl_customization.m to register build hook functions, see Customizing the Target Build Process with sl_customization.m in the Real-Time Workshop Embedded Coder documentation. For more information on the Simulink customization file sl_customization.m, see Customizing the Simulink User Interface in the Simulink documentation.

New sl_customization API for Customizing Data Objects

This release introduces an API, exercised through the Simulink customization file sl_customization.m, that allows you to register Simulink data object customizations, including

User data types
mpt user object types
Data Object Wizard (DOW) user packages

This new registration mechanism replaces earlier mechanisms involving the files custom_user_type_registration.m (for creating user data types) and custom_user_object_type_info.m (for registering mpt user object types). A script is provided to convert existing instances of custom_user_type_registration.m and custom_user_object_type_info.m to sl_customization.m (see Compatibility Considerations).

For details on the use of sl_customization.m to customize Simulink data objects, see the following sections in the Real-Time Workshop Embedded Coder documentation:

For more information on the Simulink customization file sl_customization.m, see Customizing the Simulink User Interface in the Simulink documentation.

Compatibility Considerations

In R2006a, data object customization mechanisms involving the files custom_user_type_registration.m and custom_user_object_type_info.m have been replaced by APIs exercised through the Simulink customization file sl_customization.m. The older files and the mechanisms associated with them no longer have any effect.

If you have instances of custom_user_type_registration.m and custom_user_object_type_info.m that contain data object customizations that you want to preserve, you must convert the customizations to the new mechanism. You can use the MATLAB command convert_custom_registration to generate a corresponding sl_customization.m file.

When convert_custom_registration executes, it searches for custom_user_type_registration.m and custom_user_object_type_info.m on the MATLAB path, obtains custom registration information from the files, and generates sl_customization.m in the current work directory. If no custom registration information is found, sl_customization.m is not generated.

When you invoke convert_custom_registration, you optionally can provide an argument of 0, to specify that any existing sl_customization.m in the current work directory should be overwritten, or 1, to specify that any existing sl_customization.m in the current work directory should be renamed to sl_customization_old.m. The default action is to overwrite the existing file, if any. For example:

>> convert_custom_registration(1)  % Generate sl_customization.m without overwriting

mpt Signal Object Enhancements

Prior to R2006a, you could initialize a signal if you defined it as an mpt signal object. With the introduction of initial value support for Simulink signal objects, the support for signal object initialization for the two object types has merged. Initialization of mpt signal objects is semantically the same as it has been in previous releases. However, the merge has resulted in the following enhancements:

You can initialize mpt signal objects for simulation and code generation. Prior to R2006a, you could initialize them for code generation only.
Consistency checks are done to ensure that initial values you set match corresponding block parameters that specify initial conditions or values. Prior to R2006a, consistency checks were not performed.
You can initialize signals that have an exported storage class. Prior to R2006a, you could initialize signals with an mpt.Signal class only.
The Source of initial values option on the Data Placement pane of the Configuration Parameters dialog box is no longer needed. Although the option is visible, the setting has no effect.
If you try to initialize an mpt signal object that represents a constant sample time, Simulink now ignores the initial value and generates a warning. Prior to R2006a, you could initialize such an mpt signal object without being notified of the error.

Note The code generated for mpt signal object initialization might vary slightly from code generated in previous releases.

For more information about the new initial value support for Simulink signal objects, see Using Signal Objects to Initialize Signals and Discrete States in the Simulink documentation and Using Signal Objects to Initialize Signals and Discrete States in the Real-Time Workshop documentation. For details on mpt data objects, see Creating Simulink and mpt Data Objects in the Real-Time Workshop Embedded Coder documentation. For information on options for controlling how signals in a model are stored and represented in generated code, see Signal Considerations in the Real-Time Workshop documentation.

New IncludeERTFirstTime Model Configuration Parameter

V4.4 (R2006a) Real-Time Workshop Embedded Coder introduces a new model configuration parameter, IncludeERTFirstTime. This parameter specifies whether Real-Time Workshop Embedded Coder is to include the firstTime argument in the model_initialize function generated for the model. By default, the parameter is set to on to include the argument.

Note The setting for IncludeERTFirstTime must be consistent throughout a model reference hierarchy.

New ERTFirstTimeCompliant Target Configuration Parameter

V4.4 (R2006a) Real-Time Workshop Embedded Coder introduces a new target configuration parameter, ERTFirstTimeCompliant. This parameter indicates whether a target supports the ability to use the IncludeERTFirstTime model configuration parameter to control inclusion of the firstTime argument in the model's model_initialize function. You set this parameter in the SelectCallback function.

By default, the parameter is set to off for custom and non-ERT targets, and on for the ERT target. (The ERT target has been enhanced to support conditional inclusion of firstTime in the model_initialize function.)

For more information about how to configure a custom embedded target to support firstTime argument control, see Supporting firstTime Argument Control in the Real-Time Workshop Embedded Coder documentation.

firstTime Argument to model_initialize Function

In a future release, Real-Time Workshop Embedded Coder will no longer use the firstTime argument in a model's generated model_initialize function. For more information about this change, use the form at http://www.mathworks.com/contact_TS.html to contact The MathWorks Technical Support.

Data Object Wizard Script for Labeling Root I/O Signals Based on Inport/Outport Names

This release includes a Data Object Wizard script, propagate_rootio_signal_names, that labels a Simulink model's unlabeled root I/O signals based on the corresponding root Inport/Outport names. Signals that are already labeled are not affected.

The script takes the name of a Simulink model in the current working directory as an input argument. It returns

1 if it completed without error
0 and an error message if it failed to complete due to an error
-1 and an error message if it completed but found a naming inconsistency

The script locates unlabeled signals connected with root I/O ports in the specified model. Each unlabeled signal will be labeled using its port name, provided that the port name is a valid C identifier, is not a C keyword, and does not conflict with other signal and parameter names in the model. If the specified model is not already open, the script opens the model for viewing. You can examine the modifications and decide whether to save the model with the changes.

For a simple demonstration of this functionality, launch rtwdemo_counter and save the model to your current working directory as rtwdemo_counter_test. You can then run the propagate_rootio_signal_names script on the saved model using either of the following MATLAB commands:

propagate_rootio_signal_names('rtwdemo_counter_test')

[status,errMsg] =  propagate_rootio_signal_names('rtwdemo_counter_test')

In the resulting display of rtwdemo_counter_test, signal labels will have been added to the model diagram. You can relaunch the original rtwdemo_counter and visually compare rtwdemo_counter with rtwdemo_counter_test.

MISRA C Compliance Enhanced for Multiport Switch Block Code

R2006a improves the MISRA C compliance of generated code by generating a default switch case statement for the Multiport Switch block. For a description of this block, see Multiport Switch in the Simulink Reference.