| Version 6.4 (R2006a) Real-Time Workshop® Software Release Notes | |
This table summarizes what's new in V6.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 at Web site | No |
New features and changes introduced in this version are
New Mechanism for Customizing Post Code Generation Build Processing
New Model Configuration Option for Suppressing Makefile Generation
New RSim Target Option for Feeding Inport Blocks with MAT-File Data
Multiport Switch Block Enhanced to Generate Default Switch Case Statement
Support for Simulink Parameter Object Data Type Enhancements
Support for New Simplest Rounding Mode for Fixed-Point Simulink Blocks
V6.4 (R2006a) Real-Time Workshop introduces an application program interface (API) for populating and managing all build information associated with a given model in a single source. This feature
Provides a mechanism for defining build information for tool chains that do not use make files
Makes it easier to customize and maintain a model's build information
The API includes methods for adding, managing, and retrieving:
Compiler flags
Preprocessor identifier definitions
Link flags
Include files and paths
Source files and paths
Libraries
The API also includes methods for updating file paths, extensions, and separators.
For information on how to use the API, see the demo rtwdemo_buildInfo and Customizing Post Code Generation Build Processing in the Real-Time Workshop documentation. For descriptions of the API methods, see Function Reference and Functions — Alphabetical List.
Starting with V6.4 (R2006a), you can customize the Real-Time Workshop build process to evaluate a post code generation command after generating and writing the model's code to disk and before generating a makefile. A post code generation command is a user-defined M-file that typically calls functions to get data from or add data to the model's build information object.
This feature is useful for applications that need to control various aspects of the build process after code generation. For example, this is necessary when you develop your own target, or you want to apply an analysis tool to the generated code before continuing with the build process.
To use this feature, you program the command as a script or function and then define the command with the new PostCodeGenCommand model configuration parameter.
For more information, see the demo rtwdemo_buildInfo and Customizing Post Code Generation Build Processing in the Real-Time Workshop documentation.
V6.4 (R2006a) adds a new option to the Real-Time Workshop pane of the Configuration Parameters dialog box and a corresponding model configuration parameter, GenerateMakefile, which you can use to suppress makefile generation during the build process. For example, you might do this to integrate tools into the build process that are not driven by makefiles.
This option controls whether the Real-Time Workshop build process generates a makefile and is selected by default. If you clear the check box in the graphical user interface or set the parameter to off, the Real-Time Workshop build process does not generate a makefile for the model. When you suppress makefile generation, you must specify any post code generation processing, including compilation and linking, as a command you program and define, using the feature described in New Mechanism for Customizing Post Code Generation Build Processing.
For more information, see Customizing Post Code Generation Build Processing.
The RSim target is enhanced with a new -i command line option that allows you to feed an Inport block with input data during simulation from a single MAT-file or you can change the MAT-file from one simulation to the next. The format requirements of the MAT-file data are flexible in that it can be a single time/data matrix, a single structure, or multiple structures.
For details on how to set up a MAT-file for use with an Inport block and specify signal data for an Inport block, see the demo rtwdemo_rsim_i and Creating a MAT-File for an Inport Block and Specifying Signal Data File for an Inport Block in the Real-Time Workshop documentation.
In releases prior to the V6.4 (R2006a), Real-Time Workshop software optimized code generated for a Switch block such that the code for blocks connected to the data input ports executed conditionally. This optimization was limited to Switch blocks with a control port receiving scalar signals. V6.4 (R2006a) enhances Real-Time Workshop software to generate code that performs conditional branch execution whether the Switch block's control port signal is a scalar value, a vector, or a matrix.
For a description of the Switch block, see Switch in the Simulink Reference.
In V6.4 (R2006a), the Real-Time Workshop build process is enhanced to generate a default switch case statement for the Mulitport Switch block. For a description of this block, see Multiport Switch in the Simulink Reference.
The V6.4 (R2006a) Real-Time Workshop software adds support for C++ code generation for Signal Processing Blockset™ and Video and Image Processing Blockset™ products.
Microsoft Visual C and Microsoft Visual C++, GNU® C/C++, Watcom C/C++ and Borland® C/C++ compilers have been fully tested with the V6.4 (R2006a) Real-Time Workshop software and are fully supported on 32-bit Windows and 32/64-bit Linux® platforms. However, V6.4 (R2006a) provides Beta C++ support only for the Intel® C/C++ compiler, which has not yet been fully evaluated for C++ compatibility with MathWorks products.
The Real-Time Workshop software provides Beta support for C++ code generation for all blockset products. C++ code generation for other blockset products has not yet been fully evaluated.
The Real-Time Workshop software does not support C++ code generation for the following:
| Embedded Target for Infineon® C166® Microcontrollers |
| Embedded Target for Motorola® MPC555 |
| Embedded Target for Motorola HC12 |
| Embedded Target for OSEK/VDX® |
| Embedded Target for TI's C2000™ DSP |
| Embedded Target for TI's C6000™ DSP |
| SimDriveline™ |
| SimMechanics™ |
| SimPowerSystems™ |
| xPC Target™ |
When using the model reference feature, the language of the code generated for the top model and any referenced models must match. For example, if you generate C++ code for the top model, the generated code for all referenced models must also be C++ code.
The following Real-Time Workshop Embedded Coder dialog box fields currently do not accept the .cpp extension. However, a .cpp file will be generated if you specify a filename without an extension in these fields, with C++ selected as the target language for your generated code.
Data definition filename field on the Data Placement pane of the Configuration Parameters dialog box
Definition file field for an mpt data object in the Model Explorer
These restrictions on specifying .cpp will be removed in a future release.
V6.4 (R2006a) introduces the ability to initialize Simulink signal objects with user-defined values for simulation and code generation. Data initialization increases application reliability and is a requirement of safety critical applications. Initializing signals for both simulation and code generation can expedite transitions between phases of Model-Based Design.
For details on using this feature, see the demo rtwdemo_sigobj_iv, 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.
In general, if a submodel uses workspace variables and the variables change, the Real-Time Workshop build process rebuilds the submodel. This behavior also occurs if the initial value for a signal object that corresponds to a signal initialized from outside the model, such as a global data store or root input port, changes.
To work around this behavior, specify the signal object's initial value as a tunable parameter. For example:
S = Simulink.Signal; S.InitialValue = 'K'; K = Simulink.Parameter; K.Value = 4; K.RTWInfo.StorageClass = 'ExportedGlobal';
You can then use the tunable parameter to change the signal's initial value without triggering a subsystem build.
As or Version 6.4 (R2006a), to avoid name clashes in models that use model referencing, do one of the following:
Increase the maximum identifier length setting for top and referenced models until the following warning disappears:
"Warning: Insufficient space for computing symbol names in model ...",
In this case, uniqueness of model names ensures that the names do not clash.
If you have a Real-Time Workshop Embedded Coder license, you can define a unique symbol naming scheme for each model. For example, you might define 'm1$R$N$M' for the first model, 'm2$R$N$M' for the second model, and so forth. The uniqueness of the naming scheme prevents name clashing.
The V6.4 (R2006a) Real-Time Workshop software supports the following Simulink parameter object data type enhancements discussed in Data Type Property of Parameter Objects Now Settable and Range-Checking for Parameter and Signal Object Values in the Simulink Release Notes.
Support for fixed-point data types
Ability to specify the data type attribute independently of the object's value attribute
For a discussion on the code generation aspects of this enhancement, see the demo rtwdemo_paramdt and Generated Code for Parameter Data Types in the Real-Time Workshop documentation.
The V6.4 (R2006a) Real-Time Workshop software supports the new Simplest rounding mode that is available for the Round integer calculations toward parameter of some fixed-point Simulink blocks. This rounding mode attempts to reduce or eliminate the need for extra rounding code in generated code. The Simplest rounding mode is currently available for the following blocks:
For more information, see Rounding in the Simulink® Fixed Point™ documentation.
In earlier releases, the identifier generated for a data item representing previous zero-crossing signal states (type PrevZCSigStates_model) was named inconsistently. Depending on your target configuration, the identifier could be generated as model_PrevZCSigState or model_PrevZC. In V6.4 (R2006a), the identifier is generated as model_PrevZCSigState across all configurations. For example, the following would appear in generated C code for a model named mydemo (for which zero-crossing data is relevant):
/* Previous zero-crossings (trigger) states */ PrevZCSigStates_mydemo mydemo_PrevZCSigState;
Starting in V6.4 (R2006a), the Real-Time Workshop software represents data type information in the file model.rtw in a more compact format. This new format omits the fields ComplexSignal, DataTypeIdx , Dimensions, and Width from where they occurred in the following records.
| Record | Record Type | Fields Removed |
|---|---|---|
| BlockOutputs | Block output ports | ComplexSignal DataTypeIdx Width |
| Dworks | Block Dworks | ComplexSignal Width |
| ExternalInputs | External inputs | ComplexSignal DataTypeIdx Width |
| ExternalOutputs | External outputs | Width |
| ModelParameters | Model parameters | ComplexSignal DataTypeIdx Dimensions Width |
The following topics discuss
In support of the new file format, V6.4 (R2006a) adds the following new Target Language Compiler (TLC) library functions for gaining access to the ComplexSignal, DataTypeIdx, Dimensions, and Width fields for a given record. You can use the new functions with the new and old file formats.
| Function | Description |
|---|---|
| LibGetRecordIsComplex(rec) | Returns the value 1 if the specified record is complex, and 0 otherwise. |
| LibGetRecordDataTypeId(rec) | Returns the data type identifier of the specified record as a an integer. |
| LibGetRecordDimensions(rec) | Returns the dimensions of the specified record as a vector of integers. |
| LibGetRecordWidth(rec) | Returns the width of the specified record as an integer. |
The Target Language Compiler (TLC) includes library functions for retrieving data from fields of the model.rtw file. If your application retrieves data from model.rtw directly, that is, without using the documented TLC library functions, the application will be incompatible and will produce incorrect results. In such cases, reprogram your application to use the documented TLC library functions to retrieve data from model.rtw.
The following table lists the fields now omitted from model.rtw and the TLC library functions you can use to gain access to the fields for various types of records.
| Field | Record Type | TLC Functions |
|---|---|---|
| ComplexSignal | Block input port | LibBlockInputSignalIsComplex LibGetRecordIsComplex |
| Block output port | LibBlockOutputSignalIsComplex LibGetRecordIsComplex | |
| Block parameter | LibBlockParameterIsComplex LibGetRecordIsComplex | |
| Block Dwork | LibBlockDWorkIsComplex LibGetRecordIsComplex (Both functions return 1 or 0, which map to the old values 'yes' and 'no', respectively.) | |
| DataTypeIdx | Block input port | LibBlockInputSignalDataTypeId LibGetRecordDataTypeId |
| Block output port | LibBlockOutputSignalDataTypeId LibGetRecordDataTypeId | |
| Block parameter | LibBlockParameterDataTypeId LibGetRecordDataTypeId | |
| Block Dwork | LibBlockDWorkDataTypeId LibGetRecordDataTypeId | |
| Dimensions | Block input port | LibBlockInputSignalDimensions LibGetRecordDimensions |
| Block output port | LibBlockOutputSignalDimensions LibGetRecordDimensions | |
| Block parameter | LibBlockParameterDimensions LibGetRecordDimensions | |
| Width | Block input port | LibBlockInputSignalWidth LibGetRecordWidth |
| Block output port | LibBlockOutputSignalWidth LibGetRecordWidth | |
| Block parameter | LibBlockParameterWidth LibGetRecordWidth | |
| Block Dwork | LibBlockDWorkWidth LibGetRecordWidth |
For descriptions of the new functions LibGetRecordIsComplex, LibGetRecordDataTypeId, LibGetRecordDimensions, and LibGetRecordWidth, see New Target Language Compiler Library Functions That Support the New File Format. For descriptions of other functions listed in the preceding table, see TLC Function Library Reference in the Real-Time Workshop Target Language Compiler documentation.
TLC files in the directory matlabroot/rtw/c/tlc have changed.
You should not customize TLC files in this directory even though the capability exists to do so. Such TLC customizations might not be applied during the code generation process and can lead to unpredictable results.
Customizations to the files in matlabroot/rtw/c/tlc are not compatible across releases. If you have customized TLC files that reside in that directory, you must reapply your customizations when you upgrade.
New demos are
| Demo... | Shows How You Can... |
|---|---|
| rtwdemo_buildInfo | Customize post code generation build processing by using the new build information API and new post code generation command |
| rtwdemo_paramdt | Control the data type of tunable parameters in code that the Real-Time Workshop software generates |
| rtwdemo_rsim_i | Use the new -i RSim target option to feed Inport blocks with MAT-file data |
| rtwdemo_sigobj_iv | Initialize Simulink signal objects with the new Simulink signal object initialization feature |
The following demos have been enhanced:
New reference documentation — Real-Time Workshop Reference
New tables that summarize dependencies of optimization and interface model configuration parameters
Running Rapid Simulations — reorganized to reflect workflow
| Version 6.4.1 (R2006a+) Real-Time Workshop Software | Version 6.3 (R14SP3) Real-Time Workshop Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |