Version 4.0 (R12) Real-Time Workshop Software :: Real-Time Workshop Release Notes (Real-Time Workshop®)

Version 4.0 (R12) Real-Time Workshop Software

This table summarizes what's new in V4.0 (R12):

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.	No bug fixes	No

New features and changes introduced in this version are

New Real-Time Workshop Embedded Coder Product

Real-Time Workshop Embedded Coder software is a new add-on product that replaces and enhances the Embedded Real-Time (ERT) target.

See the Real-Time Workshop Embedded Coder documentation for details.

Compatibility Considerations

The new Real-Time Workshop Embedded Coder product is 100% compatible with the ERT target. In addition to supporting all previous functions of the ERT target, the new Real-Time Workshop Embedded Coder product includes many enhancements.

Support for Simulink Data Objects

The Real-Time Workshop software supports Simulink data objects. Simulink provides the built-in Simulink.Parameter and Simulink.Signal classes for use with the Real-Time Workshop software. Using these classes, you can create parameter and signal objects and assign storage classes and storage type qualifiers to the objects. These properties control how the generated code represents signals and parameters. You can extend the Simulink.Parameter and Simulink.Signal classes to include user-defined properties.

See Simulink Data Object Considerations in the Real-Time Workshop documentation for details.

Support for ASAP2 Data Files

ASAP2 is a data definition standard proposed by the Association for Standardization of Automation and Measuring Systems (ASAM). This standard is used for data measurement, calibration, and diagnostic systems.

The Real-Time Workshop software now lets you export an ASAP2 file containing information about your model during the code generation process. See Generating an ASAP2 File in the Real-Time Workshop documentation for details.

Enhanced Real-Time Workshop Configuration Pane

The Real-Time Workshop pane of the Simulation Parameters dialog box has been reorganized and made easier to use. See Preparing Models for Code Generation in the Real-Time Workshop documentation for details.

Other User Interface Enhancements

The Tools menu of the Simulink model window contains a new Real-Time Workshop submenu with shortcuts to frequently used features.
You can now select a target configuration from the System Target File Browser by double-clicking on the desired entry in the target list.

See the Real-Time Workshop documentation for details.

Compatibility Considerations

The double-click mechanism for selecting a target configuration from the System Target File Browser does not replace the previous selection method. You can still select a target entry and then click OK.

Support for New Simulink Advanced Options Pane

An Advanced pane options pane has been added to the Simulation Parameters dialog box. The Advanced pane contains

New code generation options
Options formerly located in the Diagnostics pane
Options formerly located in the Real-Time Workshop pane

Compatibility Considerations

Simulation Parameters dialog box options formerly located in the Diagnostics and Real-Time Workshop panes have been relocated to the new Advanced pane.

Model Parameter Configuration Dialog Box

The Model Parameter Configuration dialog box extends and replaces the Tunable Parameters dialog box. The Model Parameter Configuration dialog box enables you to

Declare individual parameters to be tunable
Control the generated storage declarations for each parameter

See Parameter Considerations in the Real-Time Workshop documentation for details.

Compatibility Considerations

You must now use the Model Parameter Configuration dialog box instead of the Tunable Parameters dialog box to declare tunable parameters.

Support for Tunable Expressions

A tunable expression is an expression that contains one or more tunable parameters. Tunable expressions are now supported during simulation and in generated code.

Tunable expressions are allowed in masked subsystems. You can use tunable parameter names or tunable expressions in a masked subsystem dialog box. When referenced in lower-level subsystems, such parameters remain tunable.

See Tunable Expressions in the Real-Time Workshop documentation for a detailed discussion on using tunable parameters in expressions.

S-Function Target Enhancements

S-function target enhancements include:

Support for variable-step solvers
Supports for tunable parameters
New Generate S-function menu option on the Simulink Tools menu that lets you automatically generate an S-function from a subsystem

The S-function target is now documented in Creating Component Object Libraries and Enhancing Simulation Performance in the Real-Time Workshop documentation.

External Mode Enhancements

New features have been added to external mode:

Signal Viewing Subsystems have been implemented to let you encapsulate processing and viewing of signals received from the target system. Signal Viewing Subsystems run only on the host, generating no code in the target system. This is useful in situations where you want to process or condition signals before viewing or logging them, but you do not want to perform these tasks on the target system. See Signal Viewing Subsystems in the Real-Time Workshop documentation for details.
The external mode communications application program interface (API) is now documented. If you want to implement external mode communications via your own low-level protocol, see in the Real-Time Workshop documentation.
The External Signal & Triggering dialog box has been enhanced as indicated in the compatibility considerations listed below.
As indicated in the compatibility considerations listed below, several additional features now support external mode.

Compatibility Considerations

Previously, you could use only Scope blocks in external mode to receive and view signals uploaded from the target program. The following features now support external mode:

The default operation of the External Signal & Triggering dialog box has been changed to make monitoring a target program simpler. See External Signal Uploading and Triggering in the Real-Time Workshop documentation for details.
Previously, you could use only Scope blocks to receive and view signals uploaded from a target program. The following features now support external mode
- Dials & Gauges Blockset
- Display blocks
- To Workspace blocks
- Signal Viewing Subsystems
- S-functions
  See External Mode Compatible Blocks and Subsystems in the Real-Time Workshop documentation for details.

Build Directory

The Real-Time Workshop build process now creates a build directory within your working directory. The build directory stores generated source code and other files created during the build process. The Real-Time Workshop software derives the build directory name, model_target_rtw, from the name of the source model and the chosen target.

See Directories Used During the Build Process in the Real-Time Workshop documentation for details.

Compatibility Considerations

If you have created custom targets for the Real-Time Workshop software under Release 11, you must update your custom system target files and template makefiles to create and utilize the build directory. See matlabroot/rtw/c/grt for examples.

To update a Release 11 target:

Add the following to your system target file.

/%
BEGIN_RTW_OPTIONS
.
.
.
rtwgensettings.BuildDirSuffix = '_grt_rtw';
END_RTW_OPTIONS 
%/

Add ".." to the INCLUDES rule in your template makefile. The following example is from grt_lcc.tmf.
```
INCLUDES = -I. -I.. $(MATLAB_INCLUDES) $(USER_INCLUDES)
```
The first -I. gets files from the build directory, and the second -I.. gets files (e.g., user written S-functions) from the current working directory.
Conceptually, think of the current directory and the build directory as the same (as it was in Release 11). The current working directory contains items like user written S-functions. The reason ".." must be added to the INCLUDES rule is that make is invoked in the build directory (i.e., the current directory was temporarily moved).

Place the generated executable in your current working directory. The following example is from grt_lcc.tmf.

PROGRAM = ../$(MODEL).exe
$(PROGRAM) : $(OBJS) $(RTWLIB)
	$(LD) $(LDFLAGS) -o $@ $(LINK_OBJS) $(RTWLIB) $(LIBS)

Code Optimization Features

This section describes new or modified code generation options that are designed to help you optimize your generated code. The options described are located on the Advanced pane of the Simulation Parameters dialog box.

Block reduction: When selected, Simulink collapses certain groups of blocks into a single, more efficient block, or removes them entirely. This results in faster model execution during simulation and in generated code.
Parameter pooling: When selected, Simulink optimizes memory usage when multiple block parameters refer to storage locations that are separately defined but structurally identical.
Signal storage reuse: Replaces the (Enable/Disable) Optimized block I/O storage option. See the compatibility considerations below for details.

See Optimizing Generated Code in the Real-Time Workshop documentation for more information on code optimization.

Compatibility Considerations

The Signal storage reuse option replaces the (Enable/Disable) Optimized block I/O storage option of previous releases. Signal storage reuse is functionally identical to the older option. Turning Signal storage reuse on is equivalent to enabling Optimized block I/O storage.

Subsystem Code Generation

The Real-Time Workshop software now generates code and builds an executable from any subsystem within a model. The build process uses the code generation and build parameters of the root model. See Generating Code and Executables from Subsystems in the Real-Time Workshop documentation for details.

Nonvirtual Subsystem Code Generation

The Real-Time Workshop software now lets you generate code modules at the subsystem level. This feature applies only to nonvirtual subsystems. With nonvirtual subsystem code generation, you control how many files are generated, as well as the file and function names. To set options for nonvirtual subsystem code generation, you use the subsystem's Block Parameters dialog box.

See Creating Subsystems in the Real-Time Workshop documentation for details.

Compatibility Considerations

Nonvirtual subsystem code generation replaces the Function management code generation options available in previous releases. Nonvirtual subsystem code generation is a more general and flexible mechanism for controlling the number and size of generated files than the Function management code generation options, File splitting and Function splitting.

Standard Filename Extensions for Generated Files

The Real-Time Workshop software now generates source code and header files that have standard filename extensions —.c and .h.

Compatibility Considerations

In previous releases, the Real-Time Workshop software gave some generated files special filename extensions, such as .prm or .reg. As of this release, the Real-Time Workshop software generates source code and header files that have standard filename extensions. The file naming conventions for the following generated files have changed:

File	Old Filename	New Filename
Model registration file	`model.reg`	`model_reg.h`
Model parameter file	`model.prm`	`model_prm.h`
`BlockIOSignals` structure file	`model.bio`	`model_bio.c`
`ParameterTuning` file	`model.pt`	`model_pt.c`
External mode data type transition file	`model.dt`	`model_dt.c`

If your application code uses #include statements to include the Real-Time Workshop software generated files (such as model.prm), you may need to modify these statements. See Files Created During Build Process in the Real-Time Workshop documentation.

hilite_system and Code Tracing

The Real-Time Workshop software uses a new command, hilite_system, to write system/block identification tags in the generated code. The tags are designed to help you identify the block, in your source model, that generated a given line of code.

For more information on identification tags and code tracing, see Tracing Generated Code.

Compatibility Considerations

In previous releases, the Real-Time Workshop software used the locate_system command to trace a tag back to the generating block. The Real-Time Workshop software now uses the new hilite_system command to trace identification tags instead of locate_system. Starting with this release, use the hilite_system command to trace a tag back to the generating block.

Generation of Parameter Comments

The Force generation of parameter comments option in the General code generation optionssection of the Real-Time Workshop pane of the Simulink Parameters dialog box controls the generation of comments in the model parameter structure (rtP) declaration in model_prm.h. This lets you reduce the size of the generated file for models with a large number of parameters.

Borland 5.4 Compiler Support

The Real-Time Workshop software now supports Version 5.4 of the Borland C/C++ compiler.

Enhanced Makefile Include Path Rules

Two new rules and macros have been added to Real-Time Workshop template makefiles. These rules let you add source and include directories to makefiles generated by the Real-Time Workshop software without having to modify the template makefiles themselves. This feature is useful if you need to include your code when building S-functions.

Column-Major Matrix Ordering

The Real-Time Workshop software now uses column-major ordering for two-dimensional signal and parameter data instead of row-major ordering.

Compatibility Considerations

In previous releases, the Real-Time Workshop software used row-major ordering for two-dimensional signal and parameter data. The Real-Time Workshop software now uses column-major ordering.

If your hand-written code interfaces to such signals or parameters via ExportedGlobal, ImportedExtern, or ImportedExternPointer declarations, review any code that relies on row-major ordering, and make appropriate revisions.

S-Function Target MEX-Files Must Be Rebuilt

Compatibility Considerations

S-function MEX-files generated by the S-function target under V3.0 (R11) are not compatible with V4.0 (R12). The incompatibilities are due to new features, such as parameter pooling.

If you have built S-function MEX-files with the S-function target under V3.0 (R11), you must rebuild them. See Creating Component Object Libraries and Enhancing Simulation Performance in the Real-Time Workshop documentation for more information.

Target Language Compiler Enhancements

The Target Language Compiler has been enhanced as follows:

TLC file parsed before execution
The Target Language Compiler now completes parsing of the TLC file just before execution. This aids development because syntax errors are caught the first time the TLC file is run instead of the first time the offending line is reached.
Speed enhanced
The Target Language Compiler features speed improvements throughout the software. In particular, the speed of block parameter generation has been enhanced.
Build directory created and used
The Target Language Compiler now creates and uses a build directory. The build directory is in the current directory and prevents generated code from clashing with other files generated for other targets, and keeps your model directories maintenance to a minimum.
Profiler added
A new profiler has been added to the Target Language Compiler to help you find performance problems in TLC code.
model.rtw changes
This release contains a new format and changes to the model.rtw file and the size of the file has been reduced.
Block parameter aliases added
Aliases have been added for block parameters in the model.rtw file.
Text expansion improved
TLC contains new, flexible methods for text expansion from within strings.
Column-major ordering used
Two-dimensional signal and parameter data now use column-major ordering.
Record handling improved
TLC now utilizes new record data handling.
Language semantics changed
- Improved EXISTS behavior.
- New TLC primitives for record handling.
- Functions can return records.
- Records can be printed.
- Records can be empty.
- Record aliases are available.
- Records can be expanded with %<>.
- Built-in functions cannot be undefined via %undef.
- Short circuit evaluation for Boolean operators, %if-%elseif-%endif, and ?: expressions are handled properly
- Conversions of values to and from MATLAB.
- Enhanced conversion rules for FEVAL. You can now pass records and structs to FEVAL.
- Relational operators can be used with nonfinite values.
- Loop control variables are local to loop bodies.
Built-in functions added
The following built-in functions have been added to the language:
FIELDNAMES
GENERATE_FORMATTED_VALUE
GETFIELD
ISALIAS
ISEMPTY
ISEQUAL
ISFIELD
REMOVEFIELD
SETFIELD
Built-in values added
The following built-in values have been added to the language:
INTMAX
INTMIN
TLC_FALSE
TLC_TRUE
UINTMAX
Support for inlined code added
Support has been added for two-dimensional signals in inlined code.

Compatibility Considerations

If you are upgrading from Release 11 to Release 12, the following changes may affect your TLC code:

Nested evaluations are no longer supported. Expressions such as the following are no longer supported:
```
%<LibBlockParameterValue(%<myVariable>,"", "", "")>
```
You must convert these expressions into equivalent non-nested expressions.
Aliases are no longer automatically created for Parameter blocks while reading in the Real-Time Workshop files.
You cannot change the contents of a "Default" record after it has been created. In the previous TLC, you could change a "Default" record and see the change in all the records that inherited from that default record.
The %codeblock and %endcodeblock constructs are no longer supported.
%defines and macro constructs are no longer supported.
Use of line continuation characters (... and \) are not allowed inside of strings. Also, to place a double quote (") character inside a string, you must use \". Previously, the Target Language Compiler allowed you to use """ to get a double quote in a string.
Semantics have been formalized to %include files in different contexts (e.g., from generate files, inside of %with blocks, etc.) %include statements are now treated as if they were read in from the global scope.
The previous the Target Language Compiler had the ability to split function definitions (and other directives) across include file boundaries (e.g., you could start a %function in one file and %include a file that had the %endfunction). This no longer works.

Nested functions are no longer allowed. For example,

%function foo ()
  %function bar ()
  %endfunction
%endfunction

Built-in functions cannot be undefined via %undef. It is possible to undefine built in values, but this practice is not encouraged.

Recursive records are no longer allowed. For example,

Record1			{
  Val 			2
  Ref			Record2
}
Record2			{
  Val			3
  Ref			Record1
}

Record declaration syntax has changed. The following code fragments illustrate the differences between declaring a record recVar in previous versions of the Target Language Compiler and the current release.
- Previous versions:
```
%assign recVarAlias = recVar { ...
	field1		value1 ...
	field2		value2 ...
	...
	fieldN		valueN ...
}
```
- Current version:
```
%createrecord recVar { ...
	field1		value1 ...
	field2		value2 ...
	...
	fieldN		valueN ...
}
```
Semantics of the EXISTS function have changed. In the previous release of TLC, EXISTS(var) would check if the variable represented by the string value in var existed. In the current release of TLC, EXISTS(var) checks to see if var exists or not.
To emulate the behavior of EXISTS in the previous release, replace
```
EXISTS(var) 
```
with
```
EXISTS("%<var>")
```

Version 4.1 (R12.1) Real-Time Workshop Software

Compatibility Summary for Real-Time Workshop Software

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit