| Version 7.0 (R2007b) Real-Time Workshop® Software Release Notes | |
This table summarizes what's new in V7.0 (R2007b):
| 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
New emlc Command-Line Function for Generating C Code from Embedded MATLAB
Code Generation from Embedded MATLAB Algorithms That Span Multiple M-Files
Enhanced Auto-Insertion of Asynchronous Rate Transition Blocks
Redundant Buffers Removed Between Asynchronous Rates with Same Priority
Enhanced Efficiency in Generated Code of Iterator-Selector-Assignment Patterns
Code Optimizations for Concatenate, Conjugate, Dot Product, and Transpose Blocks
Static File Dependencies Reduced for Improved Integration and Builds
Support for Selecting and Viewing a Target Function Library (TFL)
Real-Time Workshop Reserved Keywords Listed in Documentation
Template Makefile MAKECMD Path Change for gmake on Microsoft Windows
Embedded MATLAB introduces a new function, Embedded MATLAB Coder (emlc), that generates C code from M-code that is compliant with the Embedded MATLAB language subset. The generated C code can be packaged as an executable, library, or MEX function. For more information, see Working with Embedded MATLAB Coder in the Real-Time Workshop documentation.
You can now generate embeddable code for external M-functions from Embedded MATLAB. This feature allows you to call external functions from multiple locations in an M-file or model and include these functions in the generated code.
In previous releases, Embedded MATLAB did not compile external M-functions, but instead dispatched them to MATLAB for execution (after warning). Now, the default behavior is to compile and generate code for external M-functions called from Embedded MATLAB. If you do not want Embedded MATLAB to compile external M-functions, you must explicitly declare them to be extrinsic, as described in Calling MATLAB Functions in the Embedded MATLAB documentation.
When running Simulink models in external mode, you can now animate states and view Stateflow test points in floating scopes and signal viewers. For more information on Stateflow animation, see Animating Stateflow Charts in the Stateflow documentation.
In previous releases, Rate Transition blocks were required to be inserted at each port of an asynchronous function call subsystem, even when unnecessary. This release provides improved auto-insertion of Rate Transition blocks for asynchronous subsystems.
In previous releases, Rate Transition blocks between asynchronous rates with the same priority introduced superfluous buffers. This release removes the redundant buffers and allows direct signal connection between asynchronous rates with the same priority.
In previous releases, users controlled compiler optimizations for building generated code by editing compiler flags into template makefiles (TMFs) or by supplying compiler flags to the Real-Time Workshop make command.
This release adds a Compiler optimization level parameter that allows users more flexible and generalized control over the compiler optimization level for building generated code. For example, you can use this parameter to trade off compilation time against run time for your model code without having to supply compiler-specific flags to other levels of the Real-Time Workshop build process.
The Compiler optimization level parameter appears in the Build process subpane of the Real-Time Workshop pane of the Configuration Parameters dialog box, as shown below:
The available values for the Compiler optimization level parameter are
Optimizations off (faster builds)
Optimizations on (faster runs)
Custom — Optimize based on user-specified compiler optimization flags
The default setting is Optimizations off (faster builds) (see Compatibility Considerations).
Selecting the value Custom enables the Custom compiler optimization flags field, in which you can enter custom compiler optimization flags (for example, -O2).
For more information about the Compiler optimization level parameter and its values, see Controlling Compiler Optimization Level and Specifying Custom Optimization Settings in the Real-Time Workshop User's Guide and Compiler optimization level and Custom compiler optimization flags in the Real-Time Workshop reference documentation.
This release also provides:
Compiler optimization level control for Simulink simulation (see the Optimization pane of the Configuration Parameters dialog box)
Command-line parameters RTWCompilerOptimization and RTWCustomCompilerOptimizations for controlling compiler optimization level from M-code
For Real-Time Workshop Embedded Coder product users, target configuration parameter CompOptLevelCompliant, which allows custom embedded targets to declare whether they support compiler optimization level control
The default setting of the new Compiler optimization level parameter introduces a performance-related compatibility consideration. When building and running your model code with the default setting, you may notice shorter compilation times, but longer execution times, compared to previous releases. The degree of difference can depend on model characteristics such as model (code) size and number of time steps taken.
Note If you specified custom compiler optimization flags for your model using OPT_OPTS, your existing optimization settings are honored and your model behavior should not change. |
In previous releases, the compiler optimization level for building Real-Time Workshop generated code was controlled for each target by compiler flags supplied in TMFs or through other Real-Time Workshop build process mechanisms. The effective compiler optimization level setting varied from target to target.
In this release, the compiler optimization level can be controlled through the Compiler optimization level parameter in the Configuration Parameters dialog box, which by default is set to the value Optimizations off (faster builds). This setting trades off code execution speed for faster code compilation.
To change the compiler optimization level for code generated from your model, change the value of the Compiler optimization level parameter to Optimizations on (faster runs) or Custom.
In previous releases, hardware listings on the Hardware Implementation pane of the Configuration Parameters dialog box did not follow a consistent convention based on device vendor and type. This release introduces a two-step hardware selection process based on device vendor and device type parameters on the Hardware Implementation pane. To select a device in either the Embedded hardware subpane or the Emulation hardware subpane,
Select a value from the Device vendor list. Your selection of vendor will determine the available device values in the Device type list.
Select a value from the Device type list. Your selection will populate the device characteristics fields on the Hardware Implementation pane appropriately.
For more information about selecting code generation target hardware, see Describing the Emulation and Embedded Targets in the Real-Time Workshop documentation and Device vendor and Device type in the Simulink reference documentation.
New features of the Iterator-Selector-Assignment pattern reduce the global and stack data sizes and improve the code structure and execution speed.
Previously, a global variable was used to pass information from a Width block outside of a For Iterator subsystem into the subsystem. In R2007b, a Width block can be directly connected to a For Iterator block and embedded in a For Iterator subsystem. In this configuration, the output of the Width block is a local variable.
In the code generated for the For Iterator block, the for loop initialization assignment occurs before entering the loop, avoiding an extra if condition in the generated code.
the Real-Time Workshopbuild process uses a new technique to handle matrix data, resulting in generating shorter, better performing code for the Concatenate, Conjugate, Dot Product, and Transpose blocks.
Previously, temporary buffers were created to carry concatenated signals. In R2007b, the Real-Time Workshop build process eliminates unnecessary temporary buffers and writes the concatenated signal to the downstream global buffer directly, reducing the stack size and improving code execution speed.
Previously, the Real-Time Workshop build process generated the negative expression:
expr * (-1)
In R2007b, the Real-Time Workshop build process generates a simpler expression to provide a solution that is closer to hand code.
-expr
Expression folding is enhanced to reduce the size of code and improve code execution speed. In R2007a, the expression folding code generation process created temporary variables, as shown in bold in the following example:
real_T rtb_Merge[12];
int32_T i;
for (i = 0; i < 12; i++) {
if (folding_U.In3 > 0.0) {
rtb_Merge[i] = 2.0 * In1[i];
} else {
rtb_Merge[i] = 3.0 * In2[i];
}
folding_Y.Out1[i] = rtb_Merge[i];
}
In R2007b, temporary variable are no longer present in the generated code and the global buffer is directly written to, as shown in bold in the following example:
int32_T i;
for (i = 0; i < 12; i++) {
if (folding_U.In3 > 0.0) {
folding_Y.Out1[i] = 2.0 * In1[i];
} else {
folding_Y.Out1[i] = 3.0 * In2[i];
}
}
the Real-Time Workshop software provides additional source files and functions for use in building your code in the matlabroot/rtw/c/libsrc directory. During code generation, these files are added to the build process. Continuing reductions of static file dependencies that began in R2007a, this release removes additional source files from the libsrc directory. Instead, these functions and files are generated only when needed. This reduces the number of additional source files required to compile and build the code, which improves compile time and can simplify code integration and verification.
In this release, the Real-Time Workshop Embedded Coder software introduces the Target Function Library (TFL) API for mapping math functions and operators to target-specific code. the Real-Time Workshop software supports the abilities to
Select an existing math library to use with your model. To select a math library, go to the Interface pane of the Configuration Parameters dialog box and select an appropriate value from the Target function library drop-down list.
View the content of target function library tables that were created using the Real-Time Workshop Embedded Coder software. To bring up the TFL Viewer with all available math libraries listed, issue the MATLAB command RTW.viewTfl.
For more information, see Selecting and Viewing Target Function Libraries.
The complete list of Real-Time Workshop reserved keywords is available at Reserved Keywords in the Real-Time Workshop documentation.
Real-Time Workshop keywords are reserved for use internal to the Real-Time Workshop software or C programming, and should not be used in your model as identifiers or function names. If your model uses these keywords, you should modify your model to use words that are not reserved. If your model contains any reserved keywords, the Real-Time Workshop build does not complete and an error message is displayed.
The ADD_MDL_NAME_TO_GLOBALS token is no longer available for use in template makefiles.
If you have the ADD_MDL_NAME_TO_GLOBALS token in your template makefile, the code generation make process issues an error. Remove the ADD_MDL_NAME_TO_GLOBALS token from all template makefiles.
Previously, the Real-Time Workshop software issued a warning when generating code for models with nonzero start time when the selected target did not support nonzero start time, and the generated code might not have operated correctly. In R2007b, when the Real-Time Workshop build process encounters this condition, the build does not complete and an error message is displayed.
For a list of targets that support nonzero start time, see Targets Supporting Nonzero Start Time in the Real-Time Workshop User's Guide.
Previously, the Real-Time Workshop build process generated correct code for absolute-time independent models without error. In R2007b, before generating code, set the model start time to zero for no change in functionality of the generated code.
In R2007b, the following TLC custom code library functions behave differently:
LibSystemOutputCustomCode
LibSystemUpdateCustomCode
LibSystemInitializeCustomCode
LibSystemDerivativeCustomCode
LibSystemEnableCustomCode
LibSystemDisableCustomCode
Previously, the Real-Time Workshop build process generated correct code for TLC custom code library functions without error. In R2007b, the Real-Time Workshop build process requires all calls to TLC custom code functions to be declared in the top-level S-function .tlc file, otherwise the custom code function is ignored. If your top-level S-function indirectly calls a TLC custom code function, you must include the white space delimited TLC custom code function call as a TLC comment in the top-level S-function. For example, if your top-level S-function file calls another file that calls LibSystemOutputCustomCode, you must include the comment %%LibSystemOutputCustomCode() in the top-level S-function .tlc file. the Real-Time Workshop build process generates an error when it detects that a S-function indirectly calls TLC custom code functions without the required comment.
LibSystemOutputCustomCode and LibSystemUpdateCustomCode behave differently in rate-grouped and non-rate-grouped code generation modes when called from a block output or update function. The system's output and update custom code is no longer duplicated if it has been registered by a block in the output or update function in a rate-grouped multirate system. The custom code is executed for all rates in rate-grouped single-tasking modes, and is executed once in non-rate-grouped multitasking modes. The old behavior is preserved if the block registers the custom code for the parent system's output or update function in TLC block functions other than output and update, for example BlockInstanceSetup. This ensures the custom code block library works the same as in previous releases. The behavior of the Real-Time Workshop custom code block library remains unchanged.
In R2007b, Windows template makefiles (TMFs) that use gmake (*_lcc.tmf) specify a different path to make than in previous releases.
If you have customized a Windows TMF that uses gmake, update your TMF for the path change by removing \rtw from the MAKECMD line. For example, change
MAKECMD = "%MATLAB%\rtw\bin\win32\gmake"
to
MAKECMD = "%MATLAB%\bin\win32\gmake"
The following demo has been added:
| Demo... | Shows How You Can... |
|---|---|
| rtwdemo_emlcbasicdemo | Use Embedded MATLAB Coder (emlc) to generate embeddable C code from M-code, compile, run and view the generated C code, and display the results. |
| Version 7.0.1 (R2007b+) Real-Time Workshop Software | Version 6.6.1 (R2007a+) Real-Time Workshop Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |