| Version 6.0 (R14) Stateflow® and Stateflow® Coder™ Software Release Notes | |
This table summarizes what's new in V6.0 (R14):
| 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. | Fixed
Bugs See also Additional Bug Fixes | No |
New features and changes introduced in this version are:
You can optionally include Stateflow® action language comments in generated code for an embedded target or a custom target. When you do this, multibyte characters in Stateflow action language comments are preserved as multibyte characters in the generated code. This means that you can have comments in code with characters from non-English alphabets such as Japanese Kanji or Chinese Hanzi characters.
See Comment Symbols in the Stateflow and Stateflow® Coder™ User's Guide for more information on inserting comments into Stateflow action language and optionally into Stateflow generated code.
Configuring simulation and code generation targets for the Stateflow blocks in nonlibrary models has been integrated with Simulink® target configuration in the Configuration Parameters dialog. For library models, you still configure targets for Stateflow blocks as you did for previous versions of Stateflow software. This also applies to the configuration of Stateflow custom targets.
For more information on configuring targets, see Building Targets in the Stateflow and Stateflow Coder User's Guide.
Compatibility Considerations. As a result of this change, properties of the old Stateflow code generation target now map to the Simulink target configuration set. Note the following compatibility considerations:
You need to update existing API scripts that modify properties of Stateflow code generation targets.
Custom code settings are no longer copied from the simulation target to the code generation target for nonlibrary models.
Updating Scripts that Modify Code on Stateflow® Code Generation Targets. If you have existing M-file scripts that use the Stateflow programmatic API to set up custom-code settings on the Stateflow code generation target, you must modify these M-file scripts to use the Simulink target configuration set. The following example illustrates how the properties on the old code generation target object map to the new configuration set object.
Here is a sample old script modifying custom code properties of a code generation target (named rtw) in Release 13 and earlier:
rt = sfroot;
trgt_sfmachine = rt.find('-isa', 'Stateflow.Machine', '-and',
'Name', bdroot);
rtw_target = trgt_sfmachine.find('-isa', 'Stateflow.Target',
'-and', 'Name', 'rtw');
rtw_target.set('UserSources',foo.c');
rtw_target.set('CustomCode','#include "myhdr.h"');
rtw_target.set('UserIncludeDirs','./myincludedir');
rtw_target.set('UserLibraries','mylib.lib');
rtw_target.set('CustomInitializer','call_my_init_fcn();');
rtw_target.set('CustomTerminator','call_my_term_fcn();');
Use the following format for M-file scripts in Release 14 and beyond. Modify all appropriate scripts to use this updated convention.
configset = getActiveConfigSet(bdroot); set_param(configset,'CustomSource','foo.c'); set_param(configset,'CustomHeaderCode','#include "myhdr.h"'); set_param(configset,'CustomInclude','./myincludedir'); set_param(configset,'CustomLibrary','mylib.lib'); set_param(configset,'CustomInitializer','call_my_init_fcn();'); set_param(configset,'CustomTerminator','call_my_term_fcn();');
Copying Code Settings from the Simulation Target to the Code Generation Target. In prior versions of Stateflow software, creating a code generaton target copied custom code settings from the simulation target to the new code generation target. This is no longer true for nonlibrary models, which configure a code generation target in the Configuration Parameters dialog. However, for library models, you can create a code generation target that still copies the custom code settings of the Stateflow simulation target.
With the proper modifications, you can now include custom C++ code with Stateflow generated code. See Building Targets in the Stateflow and Stateflow Coder User's Guide.
The object descriptions entered in the property dialogs for charts, states, transitions, and graphical functions are now optionally propagated into generated code for embedded targets with a Real-Time Workshop® Embedded Coder™ software license. You can enable this option in the Configuration Parameters dialog as follows:
Under the Real-Time Workshop node, select the Comments node.
In the right properties pane, select Stateflow object descriptions.
All Stateflow code generation settings for Real-Time Workshop® code generation are now consolidated into the new Configuration Parameters dialog. This enables users to specify code generation settings for Simulink models and Stateflow charts in a single location.
In addition, custom code settings (code inclusion, user source files, and so on) are now supported by the Configuration Parameters dialog, although they can still be entered on the Real-Time Workshop target object. All custom code settings and Stateflow optimization settings from old models are grandfathered into the new Configuration Parameters dialog at load time.
Code generation consists of two phases. During the first phase, a TLC file is generated from every chart. These TLC files are converted into C code in the second phase. In R13SP1 and prior versions, Stateflow software regenerated these TLC files for charts even when they had not changed from a previous code generation session. In Release 14, the first phase of TLC generation is incremental so that the TLC file for a chart is regenerated only if there is a change in the chart since the last code generation session. This incremental TLC generation significantly improves the speed of Real-Time Workshop code generation for models with a large number of Stateflow charts.
The names of identifiers (variable names, structure names, field names in structures, function names) in the generated code are now uniformly managed for a common look and feel, and to prevent naming conflicts.
A Stateflow chart inherits the type and size for input and output data from the signals that connect to them in a Simulink model. This feature minimizes the double data entry that was previously required for defining Stateflow input and output data. To inherit input or output data type from their block connections in a Simulink model, enter Inherited for their Type property. To inherit input or output data size from their block connections in a Simulink model, enter -1 for their Size property.
See Inheriting Data Types from Simulink® Objects and Inheriting Input and Output Data Size from Simulink® Signals in the Stateflow and Stateflow Coder User's Guide for more detailed descriptions.
You can use expressions in the Size property for Stateflow data. Expressions can include numeric constants, arithmetic operators, Stateflow data of scope Parameter or Constant, and calls to the MATLAB® functions min, max, and size. See Sizing Stateflow® Data in the Stateflow and Stateflow Coder User's Guide for more details.
You can specify Stateflow constant read-only data that is initialized from the MATLAB workspace by specifying data with the scope Parameter. The MATLAB workspace can include Simulink parameters for masked subsystems that contain the Stateflow block or variables in the MATLAB base workspace. See Initializing Data from the MATLAB® Base Workspace in the Stateflow and Stateflow Coder User's Guide for more information.
In previous versions, the goal was to create data of type Constant and enable the Initialize From Workspace property. This action initialized the constant with the value of a variable of the same name in the MATLAB workspace, in this case, a Simulink parameter. This method had several limitations:
The Stateflow parameter name resolution did not honor the Simulink name resolution. If a parameter could not be resolved in the immediate mask workspace containing the chart, an error message appeared.
Library charts that contain the parameters could not participate in code reuse.
All of the preceding limitations are now fixed. Furthermore, all existing models that have constant data initialized from the workspace are automatically redefined with the new Parameter scope.
Compatibility Considerations. Existing API scripts looking for Constant data initialized from the workspace must be changed to look for data with the scope Parameter, as shown in the following example:
Before R14:
d0 = sfm.find('-isa','Stateflow.Data','-and',
'Scope','CONSTANT_DATA','-and','InitFromWorkspace',1);
After R14:
d0 =
sfm.find('-isa','Stateflow.Data','-and','Scope','Parameter');
You can no longer define temporary data at the chart level. Instead, an optimization in Stateflow generated code converts chart parented local data acting as temporary data to temporary data.
Compatibility Considerations. In existing models, temporary data defined for a chart is automatically converted to local data.
Stateflow fixed-point data now participates in autoscaling for fixed-point numbers in Simulink models. For a procedure on how to autoscale fixed-point data in Simulink models, see the topic Automatic Scaling in the Simulink® Fixed Point™ software documentation.
Compatibility Considerations. The Simulink model override of fixed-point numbers applies in Stateflow charts, with the following exceptions:
The fixed-point override does not apply for scaled doubles. If you specify this option for an override, an error results.
The fixed-point override is not supported for Stateflow library charts. Specifying fixed-point override for library charts results in a warning.
In Version 5.1.1 (R13SP1) and prior versions, data defined with the size of [1,3] was automatically converted to a nondirectional vector of size 3. In Version 6.0 (R14), the directionality is preserved.
Compatibility Considerations. If the vector data you define is a chart input or output, it is converted to a directional row vector to interface with the Simulink model. This data needs to be accessed as a two-dimensional matrix in Stateflow action language in state and transition labels, for example, as x[0][1].
You can now use the cast operator cast for all Stateflow data types except ml and fixed-point data. To make casting easier, you can also use a type operator that provides the type of an existing data you can use as an argument in cast operations.
The cast and type operators are documented in the Stateflow and Stateflow Coder User's Guide.
The Dirty property for a Chart object in the Stateflow API is writable. The Dirty property for the Machine object is still read-only (RO).
You can now use a special subset of the MATLAB programming language in the form of Embedded MATLAB™ functions. These functions give you the power of MATLAB data, function, and language features that are specially tailored to the tight memory and operating system requirements found in embedded target environments.
Embedded MATLAB functions provide the following functionality to users:
An editing environment for entering Embedded MATLAB function M-code
A subset of the MATLAB programming language that you can use in Embedded MATLAB functions. See Using the Embedded MATLAB™ Function Block in the Simulink software documentation.
Embedded MATLAB functions are callable from anywhere on the chart
Embedded MATLAB functions can call other Embedded MATLAB functions, including truth tables and graphical functions
Embedded MATLAB functions have access to all chart data (inputs, outputs, locals, and so on)
The new Embedded MATLAB Function block in the User Defined Functions library for a Simulink model uses the same underlying infrastructure as a Stateflow chart for simulation (through code-generation), debugging, and integration with Real-Time Workshop code generation software. This dependency has the following ramifications:
The simulation settings for the Stateflow simulation target (sfun) apply equally to all Stateflow charts and Embedded MATLAB blocks in the model. For example, turning debugging on/off would globally affect the charts as well as Embedded MATLAB Function blocks.
Some of the compile-time warnings and run-time errors from the Embedded MATLAB Function block mention the Stateflow chart as the source of the warning or error.
Optimization settings for an embedded target apply equally to Embedded MATLAB Function blocks. These optimization settings appear for the Optimization node in the Configuration Parameters dialog only when a Stateflow block or an Embedded MATLAB Function block is present in the model.
Selecting the Rebuild All button in the Embedded MATLAB Editor or in the Stateflow Editor regenerates the simulation code for all the Stateflow charts and all Embedded MATLAB Function blocks in the model.
In the Model Explorer, the icon for the library links of Embedded MATLAB Function blocks is identical to the icon used for Stateflow link charts.
In the Model Explorer, it is possible to copy data objects between Stateflow charts and Embedded MATLAB Function blocks.
See Using Embedded MATLAB™ Functions in the Stateflow and Stateflow Coder User's Guide.
Input and output data sizes for Stateflow graphical functions can now be vectors or two-dimensional matrices. The semantics of the input vector or matrix data are compliant with the MATLAB language semantics pass-by-value instead of pass-by reference for the C language.
You can log the values of Stateflow data and the activity of Stateflow states against sampling time during simulation. After simulation, you access the data with a set of object-oriented commands. See Logging Data Values and State Activity in the Stateflow and Stateflow Coder User's Guide for a detailed example.
You can now useSimulink floating scope blocks to monitor Stateflow data during simulation. Stateflow data and states now appear in the hierarchy of the Signal Selector dialog of a floating scope. Selecting them causes them to be displayed in the floating scope at simulation time.
See Using a Floating Scope to Monitor Data Values and State Activity in the Stateflow and Stateflow Coder User's Guide for an example.
The Stateflow Debugger Browse Data option is limited to displaying all the elements of a large matrix. The Stateflow Debugger now supports a command-line mode at the MATLAB command prompt. Now when a Stateflow breakpoint is reached, you can type simple expressions at the Stateflow command-line debugger in the MATLAB Command Window to display their value. For example, the following entries compute and display values for parts of the matrix in the MATLAB Command Window:
x(2,:) x(3,4)+3
For details on using the Command Line Debugger, see the Stateflow and Stateflow Coder User's Guide.
Box objects in Stateflow charts can now parent data. This is useful for encapsulating the design better by limiting the visibility of certain data to a given Box object and its hierarchy. For example, a Box object that parents data along with graphical functions that manipulate this data can be thought of as an implementation of a singleton class with data and methods.
The Model Explorer now listsStateflow objects in its hierarchy of Simulink model objects. In place of the old Stateflow Explorer tool, you can now use the Model Explorer to add and modify data and events to Stateflow objects. For complete details on using the Model Explorer with Stateflow objects, see the Stateflow and Stateflow Coder User's Guide.
For details on using the Model Explorer with Simulink models, see The Model Explorer in the Simulink software documentation.
A common modeling error in Stateflow charts is to create states with one of the following:
This can cause certain runtime state-inconsistency errors. For example, if a state has substates with no default transition, the state can be active, but no substates can.
Default transitions that are all conditional
In this case, if all default transition conditions evaluate to false at runtime, no state can become active.
Both of these cases are detected during code generation, and a warning to fix the model appears.
When you open models containing Stateflow charts that were developed in earlier versions, Stateflow software automatically upgrades the Stateflow machine to work in the current version. A warning message no longer appears, requiring that you save the model in the current version of Stateflow software.
Sizes specified for the third dimension or higher of an array that result in a trailing set of 1's are removed. Here are some examples.
Size Specified by User | Size Specified by Stateflow Software |
|---|---|
[2, 3, 1] | [2, 3] |
[3, 5, 1, 1, 1] | [3, 5] |
[3, 4, 1, 1, 2] | No change |
[4, 1] | No change |
Compatibility Considerations. For size specifications that use trailing 1's after the second dimension, you must change array indexing in state and transition actions accordingly. For example, if you specify the size of the array my_array as [4, 5, 1, 1, 1], you can no longer specify the element as my_array[2][3][0][0][0] in an action. Instead, specify the element as my_array[2][3].
The following bugs have also been fixed in V6.0. These bug fixes do not appear in Fixed Bugs on the MathWorks Web site.
If a Stateflow library chart was instanced more than once in a model, and if this chart had multiple function-call output events, sometimes the generated code did not compile.
Reenabling a disabled link to a subsystem copied from a library corrupted the model containing the linked subsystem. This always occurred if the library contained one or more link Stateflow charts or if a copy-and-paste (rather than a drag-and-drop) operation was used to create the library link, that is, if the subsystem was first copied from the library to the system clipboard (by typing Ctrl+C or selecting Copy from the Simulink Edit menu).
Executing the MATLAB command clear all or clear mex during simulation of a model with a Stateflow chart caused a segmentation violation.
Calling MATLAB functions from Stateflow charts by using either the MATLAB namespace operator ml or the function form ml() with an argument whose data type was not double caused erroneous results.
| Version 6.1 (R14SP1) Stateflow® and Stateflow® Coder™ Software | Version 5.1.1 (R13SP1) Stateflow® and Stateflow® Coder™ Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |