Version 7.2 (R2008b) Real-Time Workshop Software :: Real-Time Workshop Release Notes (Real-Time Workshop®)

Version 7.2 (R2008b) Real-Time Workshop Software

This table summarizes what's new in V7.2 (R2008b):

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

Support for Enumerated Data Types in Generated C Code

Real-Time Workshop software now supports enumerated data types in code generated for Simulink models and Stateflow^® charts. For details, see:

Using Enumerated Data in the Simulink documentation

Using Enumerated Data in Stateflow Charts

Enumerated Data Type Considerations

Support for Simulink Legacy Code Tool Enhancement

The Real-Time Workshop software supports the new Legacy Code Tool S-function options field, singleCPPMexFile. When set (1), this option

Requires you to generate and manage an inlined S-function as only one file (.cpp) instead of two (.c and .tlc)
Maintains model code style — level of parentheses usage and preservation of operand order in expressions and condition expressions in if statements—as specified by model configuration parameters

When you choose not to use this option, code generated by the Legacy Code Tool does not reflect code style configuration settings and requires you to manage C MEX and TLC files.

For more information, see

Integrating Existing C Functions into Simulink Models with the Legacy Code Tool in the Writing S-Functions documentation
Automating the Generation of Files for Fully Inlined S-Functions Using Legacy Code Tool in the Real-Time Workshop documentation
legacy_code function reference page

Compatibility Considerations

If you upgrade from an earlier release, you can continue to use S-functions generated from the Legacy Code Tool available in earlier releases. You can continue to compile the S-function source code and you can continue to use the compiled output from an earlier release without recompiling the code.
If you set the new singleCPPMexFile options field to true (1) when creating an S-function, you cannot use that S-function, in source or compiled form, with versions of Simulink earlier than Version 7.2 (R2008b).

emlc Support for Fixed-Point Data Types Greater Than 32 Bits (Up to 128 Bits)

emlc now supports fixed-point word lengths up to 128 bits for C code production. This increase in maximum precision to 128 bits supports generating efficient code for targets with nonstandard word sizes.

File Structure of C Code Generated by emlc Now Matches M-File Structure

In previous releases emlc generated code in a single C file, no matter how many source M files were compiled. Now, the generated C file structure matches the original M-file structure. emlc generates one C file for every M file for which a separate top-level function is generated. This association makes it easier to correlate the generated C code with the compiled M-code. For more information, see Partitioning Generated Files in the Real-Time Workshop documentation.

emlc Uses Same Trigonometric Functions as MATLAB

emlc now uses the same library as MATLAB for implementing trigonometric operations in MEX function targets. In previous releases, emlc used the C compiler implementation of trigonometric functions, sometimes producing different results from MATLAB. Now, results are consistent with MATLAB and independent of compiler choice.

Improperly-Scaled Fixed-Point Relational Operators Now Match MATLAB Results

When evaluating relational operators, emlc computes a common type that encompasses both input operands. In previous releases, if the common type required more than 32 bits, code generated by emlc may have given different answers from MATLAB. Now, the answers are consistent.

Compatibility Consideration

Some relational operators generate multi-word code even if one of the fixed-point operands is not a multi-word value. To work around this issue, cast both operands to the same fixed-point type (using the same scaling method and properties).

emlc Now Prevents Default fimath Mismatches for MEX Functions

MEX functions generated with emlc use the default fimath value in effect at compile time. If you do not specify a default fimath value explicitly using the -F option, emlc uses the MATLAB default fimath value. If your MEX function uses the MATLAB default fimath, emlmex generates an error if the compile-time value does not match the runtime value.

Ability to Optimize Code for Vector Assignments by Replacing for-Loops with memcpy

This release provides two new model parameters, Use memcpy for vector assignment and Memcpy threshold (bytes), which allow you to optimize Real-Time Workshop generated code for vector assignments by replacing for-loops with memcpy function calls. The new parameters appear on the Optimization pane of the Configuration Parameters dialog box, immediately under the Loop unrolling threshold parameter.

The memcpy function can be more efficient than for-loop controlled element assignment for large data sets. Where memcpy offers improved execution speed, you can use the new model options to specify that generated code should use memcpy when assigning a vector signal.

Selecting the Use memcpy for vector assignment option enables the associated parameter Memcpy threshold (bytes), which allows you to specify the array size in bytes at or above which memcpy should replace for-loops in the generated code for vector assignments. For more information, see Use memcpy for vector assignment and Memcpy threshold (bytes) in the Simulink Graphical User Interface documentation.

Rate Transition Support Enhanced for Signal Line Branching and Direct Connections Between Asynchronous Rates

Branching Supported on Output Port of Asynchronous Rate Transition Block

In previous releases, if a signal branched in order to drive multiple asynchronous subsystems, each branch of the signal required a separate Rate Transition block. In this release, you can place a single Rate Transition block on the signal line ahead of the branch, and then branch on the Rate Transition block output signal line. Eliminating the need for multiple Rate Transition blocks simplifies the model diagram and can improve code efficiency.

Asynchronous Subsystems Can Directly Connect When Rate Transition Protection Not Required

In previous releases, Rate Transition blocks were required at each port of an asynchronous subsystem, even when rate transition protection was not required. Generally, rate transition protection is not required when the sample times for a signal's source and destination blocks have the same priority.

In this release, Rate Transition blocks can be omitted where rate transition protection is unnecessary, allowing direct connection between asynchronous subsystems. Specifically,

Two asynchronous function-call subsystems with the same priority now can be directly connected
An asynchronous function-call subsystem can have a direct feedback loop with no Rate Transition block in the loop

Eliminating Rate Transition blocks where rate transition protection is not required simplifies the model diagram and can improve code efficiency.

Generated Code Includes Standard C Static Files (stddef.h and stdlib.h) Only When Necessary

In previous releases, code generated by the Real-Time Workshop software always included the stddef.h header file, and for Stateflow content, the stdlib.h header file, regardless of the specific needs of the application or the target environment. In this release, generated code does not automatically include stddef.h or stdlib.h unless your model contains a utility function that requires it.

MISRA C Code Initialization Enhancements

Previously, the Real-Time Workshop build process occasionally generated initialization code that was not compliant with MISRA C^® standards. In R2008b, using the Use memset to initialize floats and doubles to 0.0 optimization generates initialization code that is always MISRA C compliant, resulting in safer, more efficient code. For details, see Use memset to initialize floats and doubles to 0.0 in the Simulink documentation.

Compatibility Considerations

For models you created previously that have the Use memset to initialize floats and doubles to 0.0 check box cleared, if you rebuild using R2008b Real-Time Workshop software, the generated code size might increase. To generate smaller code, select the Use memset to initialize floats and doubles to 0.0 check box. The Check optimization settings Model Advisor check is available to help you determine if the current setting of the parameter is correct.
If your hardware does not represent numerical zero for floating-point data as bit pattern 0 (all bits 0), you must clear the Use memset to initialize floats and doubles to 0.0 check box.
The Use memset to initialize floats and doubles to 0.0 check box is selected by default for new models.

Ability to Register Keywords to Avoid Conflicts with External Code

Previously, external environments could use keywords that the Real-Time Workshop code generation process created in the generated code, resulting in clashes between the external environment and the generated code. In R2008b, you can register the set of keywords that the code generation process should not use, facilitating code integration where outside functions and global variables are unknown in the Simulink model.

The Reserved names parameter is located on the Real-Time Workshop > Symbols pane in the Configuration Parameters dialog box. For more information, see Real-Time Workshop Pane: Symbols in the Real-Time Workshop Reference and in the Real-Time Workshop User's Guide.

Use Same Custom Code Settings for Model Simulation and Real-Time Workshop Code Generation

Previously, for models that contained Embedded MATLAB Function blocks, Stateflow charts, or Truth Table blocks, custom code settings for simulation and Real-Time Workshop code generation were entered separately. In R2008b, you can choose to use the same custom code settings in both cases to avoid entering information twice.

The Use the same custom code settings as Simulation Target parameter is located on the Real-Time Workshop > Custom Code pane in the Configuration Parameters dialog box. For more information, see Real-Time Workshop Pane: Custom Code in the Real-Time Workshop Reference and Preparing Models for Code Generation in the Real-Time Workshop User's Guide.

Configure Unique Custom Code Settings for Library Models in the Configuration Parameters Dialog Box

In general, library models use custom code settings of the parent model during the Real-Time Workshop build process. However, libraries that contain Embedded MATLAB Function blocks, Stateflow charts, or Truth Table blocks can use custom code settings unique from the parent model. These libraries can have their own set of Real-Time Workshop configuration parameters separate from the parameters of the parent model. Select Tools > Open RTW Target in the Embedded MATLAB Editor or Stateflow Editor for your library model.

For information about custom code parameters, see Real-Time Workshop Pane: Custom Code in the Real-Time Workshop Reference and Preparing Models for Code Generation in the Real-Time Workshop User's Guide.

Compatibility Considerations

Previously, you could configure custom code for a Stateflow library model on the Custom Code pane in the RTW Target dialog box. In R2008b, these custom code parameters are migrated to the Configuration Parameters dialog box. Therefore, if you have scripts that use the Stateflow API to configure the Target object (rtw) for library models, you must update your scripts to use the get_param and set_param commands instead.

For details, see Library Models: Mapping of GUI Options from the RTW Target Dialog Box to the Configuration Parameters Dialog Box and Updating Scripts That Set Options Programmatically for Simulation and Embeddable Code Generation in the Stateflow and Stateflow^® Coder™ Release Notes.

Flexible Configuration Options for Referenced Models in TLC-Based Custom Targets

In R2008b, you can specify that a configuration option for a TLC-based custom target need not have the same value in a referenced model that it has in the parent model. By default, the values must be the same in both models. For information about overriding this default, see Controlling Configuration Option Value Agreement in the Real-Time Workshop Embedded Coder documentation.

Optimize Floating-Point to Integer Data Type Conversions Using New Configuration Parameter

R2008b introduces a new configuration parameter to remove code that maps NaN values to integer zero, increasing efficiency of generated code for floating-point to integer or fixed-point data type conversions. See Remove code from floating-point to integer conversions with saturation that maps NaN to zero in the Simulink documentation for more information.

New and Enhanced Demos

The following demo has been added:

Demo...	Shows How You Can...
`rtwdemo_rtiostream`	Implement a communication channel to enable exchange of data between different processes (for example, for host/target communication during Processor-in-the-Loop or External Mode simulation).

Version 7.3 (R2009a) Real-Time Workshop Software

Version 7.1.1 (R2008a+) Real-Time Workshop Software

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit