|Real-Time Workshop Release Notes|
New Features and Enhancements
This section introduces the new features and enhancements added in the Real-Time Workshop 5.0 since the Real-Time Workshop 4.1. A number of enhancements to Simulink that can impact code generation are also described.
For information about Real-Time Workshop features that are incorporated from recent releases, see the Real-Time Workshop 4.1 Release Notes and the Real-Time Workshop 4.0 Release Notes documentation.
|Note For information about closely related products that extend the Real-Time Workshop, see the Release Notes sections about the Real-Time Workshop Embedded Coder and the xPC Target.|
Code Generation Infrastructure Enhancements
Code for Nonvirtual Subsystems Is Now Reusable
Real-Time Workshop 5.0 alters certain aspects of generated code to implement the capability to reuse code for nonvirtual subsystems. You have the ability to select or override this feature, as well as to specify function and file names from the Real-time Workshop GUI.
In prior releases, each nonvirtual subsystem in a model generated a separate block of code. In some circumstances--for example, when a library block is used multiple times in the same fashion--it is possible to generate a single shared function for the block and call that function multiple times. Consolidating code in this fashion can significantly improve the size and efficiency of generated code.
To implement code reuse, the Real-Time Workshop must pass in appropriate data elements (as function arguments) for each caller of a reused subsystem. Code generated by Real-Time Workshop 5.0 enables such arguments for functions generated for nonvirtual subsystems.
You enable code reuse through the Subsystem parameters dialog box when both Treat as atomic unit and
Reusable function from the RTW system code pull-down menu are selected, as illustrated below.
Reusable code will also be generated, when feasible, when you set RTW system code to
Auto. Then, if only one instance of the subsystem exists, it will be inlined; otherwise a reusable function will be generated if other characteristics of the model allow this.
Certain conditions may make it impossible to reuse code, causing Real-Time Workshop to revert to another RTW system code option even though you specify
Reusable function or
Reusable function is specified and reuse is not possible, the result will be a function without arguments. When
Auto is specified and reuse is not possible, the result will be to inline the subsystem's code (or in special cases, create a function without arguments). Diagnostics are available in the HTML code generation report (if enabled; see "Generate HTML Report Option Available for Additional Targets") to help identify the reasons why reuse is not occurring in particular instances. In addition to providing these exception diagnostics, the HTML report's Subsystems section also maps each noninlined subsystem in the model to functions or reused functions in the generated code.
Requirements for Generation of Reusable Code from Stateflow Charts. To generate reusable code from a Stateflow chart, or from a subsystem containing a Stateflow chart, all of the following conditions must be met:
See Nonvirtual Subsystem Code Generation in the Real Time Workshop documentation for further details.
Packaging of Generated Code Files Simplified
The packaging of generated code into
.h files has changed. The following table summarizes the structure of source code generated by the Real-Time Workshop. All code modules described are written to the build directory.
|Note The file packaging of the Real-Time Workshop Embedded Coder differs slightly (but significantly) from the file packaging described here. See the "Data Structures and Code Modules" section in the Real-Time Workshop Embedded Coder User's Guide for further information.|
||Contains entry points for all code implementing the model algorithm (
||Contains local defines and local data that are required by the model and subsystems. This file is included by
||Defines model data structures and a public interface to the model entry points and data structures. Also provides an interface to the real-time model data structure (
If you are interfacing your hand-written code to generated code for one or more models, you should include
||Provides forward declarations for the real-time model data structure and the parameters data structure. These may be needed by function declarations of reusable functions.
||Provides data structures that enable a running program to access model parameters without use of external mode. To learn how to generate and use the
||Provides data structures that enable your code to access block outputs. To learn how to generate and use the
If you have interfaced hand-written code to code generated by previous releases of the Real-Time Workshop, you may need to remove dependencies on header files that are no longer generated. Use
.h directives, and remove
#include directives referencing any of the following:
Most Targets Use rtModel Instead of Root SimStruct
The GRT, GRT-Malloc, ERT, and Tornado targets now use the rtModel data structure to store information about the root model. In prior releases, this information was stored in the SimStruct data structure. Since the SimStruct data structure was also used by non-inlined S-functions, it contained a number of S-function-specific fields that were not needed to represent root model information. The new
rtModel is a lightweight data structure that eliminates these unused fields in representing the root model. Fields in the rtModel capture model-wide information pertaining to timing, solvers, logging, model data (such as block I/O, and DWork, parameters), etc. To generate code for the ERT target, the rtModel data structure is further pruned to contain only those fields that are relevant to the model under consideration.
|Note If you have previously customized GRT, GRT-Malloc, or Tornado targets, you should upgrade each customized target to use the rtModel instead of the SimStruct. You can find guidelines for this upgrade path in Upgrading Customized GRT and GRT-Malloc Targets to Work with Release 13.|
Hook Files for Communicating Target-specific Word Characteristics
In order to communicate details about target hardware characteristics, such as word lengths and overflow behavior, you now need to supply an M-file named
<target>_rtw_info_hook.m. Each system target file needs to implement a hook file. For GRT (
grt.tlc), for example, the file must be named
grt_rtw_info_hook.m, and needs to be on the MATLAB path. If the hookfile is not provided, default values based on the host's characteristics will be used, which may not be appropriate. For an example, see
toolbox/rtw/rtwdemos/example_rtw_info_hook.m. In addition, note that the TLC directive
%assign DSP = 1 no longer has any effect. You need to provide a hook file instead.
Code Generation Unified for Real-Time Workshop and Stateflow
In earlier releases, code generated from Stateflow charts in a model was written to source code files distinct from the source code files (such as
.h, etc.) generated from the rest of the model.
Now, by default, Stateflow no longer generates any separate files from the Real-Time Workshop. In addition, Stateflow generated code is seamlessly integrated with other generated code. For example, all Stateflow initialization code is now inlined.
You can override the default and instruct the Real-Time Workshop to generate separate functions, within separate code files, for a Stateflow chart. To do this, use the RTW system code options in the Block parameters dialog of the Stateflow chart (see Nonvirtual Subsystem Code Generation in the Real-Time Workshop documentation). You can control both the names of the functions and of the code files generated.
Conditional Input Branch Execution Optimization
This release introduces a new optimization called conditional input branch execution, speeding simulation and execution of code generated from the model. Previously, when simulating models containing Switch or Multiport Switch blocks, Simulink executed all blocks required to compute all inputs to each switch at each time step. In this release, Simulink, by default, executes only the blocks required to compute the control input and the data input selected by the control input at each time step. Likewise, standalone applications generated from the model by Real-Time Workshop execute only the code needed to compute the control input and the selected data input. To explore this feature, look at the coninputexec demo.
|Real-Time Workshop 5.0 Release Notes||Code Generation Configuration Features|