This document describes major bug fixes in this release.
Click on a problem area listed below to read how it has been fixed.
Altering Execution Order in Subsystem Copies Caused Segmentation Violation
Block I/O Optimization
C++ Compatibility for Stateflow and Real-Time Workshop
Code for Logic Block with Single Input
Code Generation Failure for Relational Operator Block
Code Generation for Data Store Memory Blocks
Code Generation for Wide State Input Signals
Code Generation from a Block Whose Output Is Connected to a Subsystem Input
Data Store Read Block Generates Valid Code When Expression Folding Is Enabled
Discrete States in a For/While Subsystem Reset Correctly
Early Termination of Real-Time Workshop or Stateflow S-Function Builds Issue Fixed
Expression Folding and Selector Blocks
Generated Code for Switch Blocks with Wide Fixed-Point Inputs
Include System Hierarchy Numbers in Identifier Option
Look-Up Table 2-D Generated Incorrect Code for Repeated Zeros in Breakpoints
Missing Storage Type Qualifier in Generated Code for Data Store Memory Block
Multi-instanced Stateflow Library Charts Now Generate Correct Code
Multiport Switch Block Generates Correct Code for Wide Inputs
Name Conflicts Between Multiple Models for Constant Parameters
New -w TLC Command Line Flag to Conserve Memory During Lexical Analysis
No Name Clashing of Function-call Arguments of Reusable Subsystems and Global Identifiers
Non-reusable Functions for Subsystem Library Links No Longer Mangle Function Names Unnecessarily
Presetting RTWOption Values in a Custom System Target File
RTW TLC Clear Out Global TLC Variables After Use
Saturation Characteristics No Longer Required in rtw_info_hook M-files
Spaces in TLC Pathnames No Longer Abort Code Generation
Subsystem Functions with Incompatible Argument Types in Generated Code
Support for N-d (N > 2) Canonical Parameters
TLC Builtin Changes to Support Parameter Sharing with Simulink
TLC Compiler Memory Now Released After Code Generation
Tunable Parameters with "context-sensitive" Data Type
Unreachable Disable Function Code for Enabled Subsystems
In Version 5.x, when a subsystem was copied and block execution order was altered in the copy or the original, a segmentation fault could result during code generation. This problem, which was associated with subsystem code reuse, has been fixed.
In previous releases, there was an inefficiency where sometimes block outputs were incorrectly defined as global rather than local. The code ran slower than necessary, but there were no inaccuracies or noticeable flaws as a result. This did not occur every time; it was dependent on the previous state of an internal register. This issue is fixed, resulting in faster code in cases that were previously problematic.
C++ source files can now be included in Stateflow custom sources. These C++ source files can also be built by the Stateflow's RTW target. Please see the example "sf_cpp" for more details. In addition, you can now code S-functions in C++. See "sfundemos" and double-click "C++" for more details.
In Version 5.x, the code generated for a Logic block with a single
vectorized input could needlessly occupy a superfluous for
loop. This caused redundant (but still correct) computations. This problem
has been fixed.
In Version 5.x, code generation can fail under certain conditions for the Relational Operator and MinMax blocks when expression folding is enabled and input to the Relational Operator block comes from a MinMax block. This has been fixed.
In Version 5.0, some models that contained Data Store Memory blocks could generate code that would not compile. This problem has been fixed.
In certain block configurations, code generation and acceleration failed when wide state signals were emitted to a block. This could happen, for example, when an exported state port from an Integrator block fed into a Relay block. This was a regression in Version 5.0 and has been fixed.
Previously, an error occurred when expression folding was on and code was generated from a model that contained a block whose output was connected to a subsystem input. This problem only occurred for blocks that had expression folding switched off in their TLC file, as was the case for the Delay and Data Store Read blocks. This problem has been fixed.
In Real-Time Workshop, the Data Store Read block could generate invalid code when expression folding was enabled. This has been remedied, by disallowing expression folding for that block.
When a block with discrete states, such as a Unit Delay block, was placed in a For or While Iterator Subsytem, the Initial Conditions of the states were not being set when the subsystem was called, in code generated by Real-Time Workshop. This is fixed.
Previously, pressing CTRL-C during a Real-Time Workshop build or Stateflow S-function build rendered the status window inoperable. This is now fixed.
In Version 5.0, with Expression folding on, incorrect code could be generated for a Selector block. This has been fixed.
In Version 5.0, a bug caused Switch blocks that received wide input signals containing fixed-point data to compute the entire input vector for each element of output vector in the Real-Time Workshop generated code. The output was correctly computed, but assignments were made redundantly. This inefficiency has been eliminated, so that now the input vector is calculated only once.
In Version 5.0, the Include system hierarchy numbers in Identifier option in the General code appearance options pane was having no effect on code appearance. This has been fixed, so that when the option is checked, identifiers include system hierarchy numbers.
If the column breakpoints in a Look-Up Table 2-D block had repeated zeros, Real-Time Workshop would generate incorrect code in some circumstances. This has been corrected. A remaining limitation is that the number and position of zeros cannot change when breakpoints are tuned, or incorrect results will be obtained. To avoid this limitation, do not use repeated zeros in lookup tables when the number or position of zeros could change while the real-time code is running.
In Version 5.0, if RTW Storage Class for a Data Store Memory block was specified as non-Auto, and a non-empty Storage Type Qualifier (e.g., volatile) was entered into its block parameter dialog, the generated code would not contain the specified Storage Type Qualifier.
The problem has been fixed in Version 5.1. Now the generated code will contain the correct user input of Storage Class and Type Qualifier in all circumstances.
Starting Release 12.1, when a Stateflow library chart was instanced more than once in a model, and when that chart has multiple function-call output events, sometimes the generated code would not compile. One workaround, in Version 5.x of Real-Time Workshop, was to set theRTW System CodetoFunctionon the subsystem parameters dialog for each of the connected function-call subsystems. This problem has now been fixed and the workaround is no longer necessary.
In earlier releases, under certain conditions a Multiport switch with a scalar control port input and wide vector data inputs would cause code generation to fail. This is fixed.
When code generated from multiple models is integrated together, the names of the variables corresponding to constant parameters in the models can conflict. This problem has been fixed by putting constant parameters into a structure that is (by default) named uniquely for each model.
To save memory when the Target Language Compiler parses largemodel.rtwfiles, you can now redirect the lexical analysis phase to a text window. This feature is controlled by the-wflag on the TLC command line. Doing this prevents large files from being read into memory in one piece.By default, this windowing feature is on. You can turn windowing off (reverting to the old behavior) by passing
-w0(zero) to TLC. The-w1TLC command flag turns windowing on.
In Version 5.0, it was possible for the names of the function-call arguments of reusable subsystems to clash with one another, as well as with global identifiers. Real-Time Workshop now ensures the names of the arguments are unique with respect to one another and do not duplicate global identifiers.
Previously, a library-reference atomic subsystem with code generation options set to "Function" and "Use Subsystem Name" would use the reference name for all instances. This created symbol clashes that Real-Time Workshop would resolve via inconsistent name mangling, which created tracibility problems. Such subsystems now use their instance name.
In Version 5.0, if you attempted to preset the Common RTW options value from a system target file, sometimes errors resulted and sometimes nothing happened. This was a regression from Version 4.1 and has been fixed.
RTW TLC files now clear out relevant global TLC variables as they are done being used during the code generation phase. This reduces TLC memory usage which is helpful in reducing overall memory usage of the MATLAB process. This does not affect the C code that is generated from RTW.
Version 5.01 of Real-Time Workshop derives C-language implementation information for the current target from "hook files" (<target>_rtw_info_hook.m). In that release, it was necessary to specify information on saturation, as seen in the following code snippet:case 'cImplementation' % specify various C-language information value.ShiftRightIntArith = true; value.Float2IntSaturates = false; value.IntPlusIntSaturates = false; value.IntTimesIntSaturates = false;The Saturation information fields are no longer required. You can therefore simplify this code to:
case 'cImplementation' % specify various C-language information value.ShiftRightIntArith = true;For more information type
'edit example_rtw_info_hook.m'in MATLAB.
In Version 5.x, if a TLC directory's pathname includes a space, Real-Time
Workshop code generation can fail due to -I flags being
parsed incorrectly. This problem has been fixed.
Starting in Version 5.0, an inlined atomic subsystem within a reused atomic subsystem that received a discontinuous input signal could generate code with incompatible types in certain cases. This has been corrected in Version 5.1.
In Version 5.x, when Real-Time Workshop generated code for n-d canonical parameters (e.g., N-D Lookup blocks), only the first two dimensions of the parameter were used to calculate the size of the argument to a reusable function. In rare cases this could prevent such functions from being reusable. This has been fixed, so that all of the dimensions are now used to compute the size of the argument.
To support parameter sharing with Simulink, a new builtin (
ISSLPRMREF) has been added to TLC. It returns a Boolean value indicating whether its argument is a reference to a Simulink parameter or not. Using this function can save memory and time during code generation. Here is an example of its usage:%if !ISSLPRMREF(param.Value) %assign param.Value = CAST("Real", param.Value) %endifIn addition, the
GENERATE_FORMATTED_VALUEbuiltin has a new optional third argument, which is a Boolean that controls the expansion of parameters into text. If this argument is true, the parameter will be expanded to raw text before being written to disk.Note that this will use much more memory than the default (which is FALSE) and would only be needed if the parameter text needs to be processed for some reason before being written to disk.
Memory used by the TLC compiler is now released after code generation. Previously, it had maintained memory caches, which had the effect of reducing available memory after the build.
As part of our effort to unify our handling of floating-point and fixed- point modeling, the way in which parameter data types are handled has been modified:
- All tunable parameters with unspecified data type (i.e., data type is
double) will now be treated as 'context-sensitive'. That is, the data type used for these parameters will be determined by their usage in the model.- All tunable parameters that have a non-double data type will be declared using the specified data type, and a run-time type cast will be added in the generated code as necessary.
- All inlined parameters (not tunable) will be treated as 'context- sensitive' (no change).
Backwards Compatibility: It is possible that this change may create backwards compatibility problems, although we are not expecting these to be very frequent or significant.
The most likely problem case is where a tunable
doubleparameter is used in a number of different "contexts" throughout a model. This is not permitted and an error message will be issued. However, it is worth noting that if this case were supported it would always result in the downcasting of parameters; the recommended solution would be for users to specify the parameter's data type to be something other thandoublein these cases regardless of this change.
Starting with Version 5.0, Real-Time Workshop was generating unreachable disable function code for enabled subsystems in single-rate parents. This caused the output of the generated code not to match simulation results. The disable function code for such enabled subsystems is now reachable.
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |