Missing Examples Intended to Describe Combining Multiple Models
Two example models for the section called Combining Multiple Models in the Targeting Real-Time Systems chapter of the documentation were inadvertently not distributed in Release 12.1. These models, fuelsys1.mdl and mcolon.mdl, have been superseded by models in the multimallocdemo.mdl demo, and the documentation has been correspondingly updated.
Setting Environment Variable to Run Rapid Simulation Target Executables on Solaris
To run RSIM executables outside of MATLAB on the Solaris platform, you need to modify your LD_LIBRARY_PATH environment variable to include bin/sol2 directory where MATLAB is installed. For example, if you have installed MATLAB under /usr/local/MATLAB then you need to add /usr/local/MATLAB/bin/sol2 to your environment variable.
Limitation Affecting Rolling Regions of Noncontiguous Signals
This note describes a limitation affecting discontiguous signals that have regions that have a width greater than or equal to the Loop rolling threshold. (This parameter is set in the General code generation options category of the Real-Time Workshop pane.) Such signal regions are called rolling regions. If a rolling region of a discontiguous signal has storage class
ImportedExternPointer, all other rolling regions of the signal must also have storage class ImportedExternPointer. Otherwise, a code
generation error is displayed. If this error occurs, try increasing the Loop

rolling threshold.

Code Generation Failure in Nested Directories Under Windows 98
This note describes a limitation affecting both the Simulink Accelerator and Real-Time Workshop, under Windows 98. The problem is due to a limitation of Windows 98. If the present working directory (pwd) is a folder nested in 7 or more levels, Real-Time Workshop (or Simulink Accelerator) cannot generate code. The workaround is to connect to a higher-level (less deeply nested) directory before initiating the build process.
Turn the New Wrap Lines Option Off
The MATLAB Command Window has a new Wrap lines option. Real-Time Workshop frequently displays very long message lines as a build progresses. This can cause some display problems. Therefore, when using Real-Time Workshop, you should turn the Wrap lines option off using the Preferences setting. For more information on this issue, see the Technical Support Solution 29082 from the MathWorks Web page.
Filename Option in Nonvirtual Subsystem Code Generation
To set options for nonvirtual subsystem code generation, you use the subsystems Block Parameters dialog. The operation of the Auto option
of the RTW file name options menu in the Block Parameters dialog has changed since the printed version of the Real-Time Workshop Users Guide went to press. In the online version of the Real-Time Workshop Users Guide, we have corrected the description of this option. See the Nonvirtual Subsystem Code Generation section of the online guide. We repeat the corrected description here:

Auto: The Real-Time Workshop does not generate a separate file for the
subsystem. Code generated from the subsystem is generated within the code module generated from the subsystems parent system. If the subsystems parent is the model itself, code generated from the subsystem is generated within model.c.
DSP Support Documentation Error
The Real-Time Workshop Users Guide section DSP Processor Support on p. 14-107 contains obsolete information, and should instead read as follows: DSP targets may use registers with sizes other than 32 bits and vary in their saturation and overflow behavior. These characteristics are specified by target-specific hookfiles, which are provided for all targets supplied by The MathWorks. Users may create their own hookfiles for custom targets. The contents and naming of hook files are described in "Targeting Real-Time Systems: Components of a Custom Target Configuration: Control Files: Hook Files for Communicating Target-specific Word Characteristics" on page 14-7 of the Real-Time Workshop User's Guide. The %assign DSP32=1 command to the system target makefile and the -DDSP32=1 command to the template makefile that formerly handled DSP targets have been deprecated and no longer have any effect.
New Features. 2-2 Major Bug Fixes. 2-3

New Features

The following new feature is provided in Version 5.1.1 of Real-Time Workshop.
New -dr Command Line Switch in TLC Detects Cyclic Record Creation
The -dr command line option enables the Target Language Compiler to detect at run time when cyclic records are created and to produce a diagnostic message. Cyclic records are problematic because they cause memory leaks in TLC. A cyclic record is one which ends up pointing to itself. They only can be constructed manually, as in the following example:
%createrecord x { } %createrecord y { } %% create an empty record x %% create an empty record y
%addtorecord x field y %% add a field to x which points to y %addtorecord y field x %% add a field to y which points to x
At this point, a cyclic record exists, i.e. x.field.field == x As this feature significantly slows Target Language Compiler performance, it is off by default.
Real-Time Workshop 5.1.1 includes important bug fixes made since Version 5.1. If you are viewing these Release Notes in PDF form, please refer to the HTML form of the Release Notes, using either the Help browser or the MathWorks Web site and use the link provided. If you are upgrading from a release earlier than Version 5.1, then you should also see Major Bug Fixes on page 2-3 of the Real-Time Workshop 5.1 Release Notes.
If you are upgrading from a release earlier than Version 5.0.1, then you should also see New Features on page 4-2 of the Real-Time Workshop 5.0.1 Release Notes.
Real-Time Workshop 5.1 includes important bug fixes made since Version 5.0. If you are viewing these Release Notes in PDF form, please refer to the HTML form of the Release Notes, using either the Help browser or the MathWorks Web site and use the link provided. If you are upgrading from a release earlier than Version 5.0.1, then you should also see Major Bug Fixes on page 4-4 of the Real-Time Workshop 5.0.1 Release Notes.

#if 0 /* Skip this size verification because of preprocessor limitation */ #if ( LONG_MAX != (0x7FFFFFFFFFFFFFFFL) ) #error Code was generated for compiler with different sized longs. #endif #endif
PreprocMaxBitsUint: Specify limitations of the target C preprocessor to do math with unsigned integers. This is just like PreprocMaxBitsSint except that it pertains to unsigned integer operations such as
#if ( ULONG_MAX != (0xFFFFFFFFFFFFFFFFUL) )
If you are not certain about the proper settings for your target, type rtwtargetsettings in MATLAB for more details.
Hookfiles for Customizing Make Commands
Custom targets may require a target-specific hook file to generate an appropriate make command when a non-default compiler is used. Such M-files should be located on the MATLAB path and be named <target>_wrap_make_cmd_hook.m, e.g. MPC555pil_wrap_make_cmd_hook.m for the MPC555 PIL target. When such a file exists, and returns an appropriate make command, Real-Time Workshop will override its default (e.g., LCC) batch file wrapping code. For an example make command hook file, see matlabroot/toolbox/rtw/rtw/wrap_make_cmd.m. Note that such hook files are distinct from the target-specific hook files that are used to describe hardware characteristics (see above).
Real-Time Workshop 5.0.1 includes several important bug fixes made since Version 5.0. If you are viewing these Release Notes in PDF form, please refer to the HTML form of the Release Notes, using either the Help browser or the MathWorks Web site and use the link provided. If you are upgrading from a release earlier than Release 13, then you should also see Major Bug Fixes on page 5-24 of the Real-Time Workshop 5.0 Release Notes.
Release Summary. 5-2 New Features and Enhancements. 5-6 Major Bug Fixes. 5-24 Platform Limitations for HP and IBM Upgrading from an Earlier Release. 5-31. 5-32

Release Summary

Real-Time Workshop 5.0 includes many new features, numerous improvements in the quality of generated code, as well as enhancements to existing features. This section summarizes new features and enhancements added in the Real-Time Workshop 5.0 since the Real-Time Workshop 4.1 release.
New Features and Enhancements
Code Generation Infrastructure Enhancements
Code for Nonvirtual Subsystems Is Now Reusable on page 5-6 Packaging of Generated Code Files Simplified on page 5-8 Most Targets Use rtModel Instead of Root SimStruct on page 5-10 Hook Files for Communicating Target-specific Word Characteristics on page 5-10 Code Generation Unified for Real-Time Workshop and Stateflow on page 5-11 Conditional Input Branch Execution Optimization on page 5-11

make_rtw OPTS='-DDOASSERTS'
If you want triggered assertions to not abort execution and instead to print out the assertion statement, use the following make_rtw variant:
make_rtw OPTS='-DDOASSERTS -DPRINT_ASSERTS'
Finally, when running a model in accelerator mode, Simulink will call back to itself to execute assertion blocks instead of using generated code. Thus user-defined callback will still be called when assertions fail.
GUI Control Over TLC %assert Directive Evaluation
Prior versions required specifying the -da Target Language Compiler command switch in order for TLC %assert directives to be evaluated. Now users can more conveniently trigger %assert code by checking the Enable TLC Assertions box on the TLC debugging section of the Real-Time Workshop dialog page. The default state is for asserts not to be evaluated. You can also control assertion handling from the MATLAB command window:
set_param(model, 'TLCAssertion', 'on|off') to set or unset. Default

is Off.

get_param(model, 'TLCAssertion') to see the current setting.
New Rate Transition Block
In previous releases, Zero-Order Hold and Unit Delay blocks were required to handle problems of data integrity and deterministic data transfer between blocks having different sample rates. The new Rate Transition block lets you handle sample rate transitions in multi-rate applications with greater ease and flexibility than the Zero-Order Hold and Unit Delay blocks. The Rate Transition block handles both types of rate transitions (fast to slow, and slow to fast). When inserted between two blocks of differing sample rates, the Rate Transition block detects the two rates and automatically configures its input and output sample rates for the appropriate type of transition.
The Rate Transition block supports the following modes of operation: Protected/Deterministic: By default, the Rate Transition block operates exactly like a Zero-Order Hold (for fast to slow transitions) or a Unit Delay (for slow to fast transitions), and can replace these blocks in existing models without any change in model performance. (There is one exception: in a transition between a continuous block and a discrete block, a Zero-Order Hold must be used.) In its default mode of operation, the Rate Transition block guarantees the integrity of data transfers and guarantees that data transfers are deterministic. Protected/Non-Deterministic: In this mode, data integrity is protected by double-buffering data transferred between rates. The blocks downstream from the Rate Transition block always use the latest available data from the block that drives the Rate Transition block. Maximum latency is less than or equal to 1 sample period of the faster task. The drawbacks of this mode are its non-deterministic timing and its use of extra memory buffers. The advantage of this mode is its low latency. Unprotected/Non-Deterministic: This mode is the least safe, and is not recommended for mission-critical applications. The latency of this mode is the same as for Protected/Non-Deterministic mode, but memory requirements are reduced since there is no double-buffering. For further information on the use of the Rate Transition block with the Real-Time Workshop, see Models With Multiple Sample Rates in the Real-Time Workshop Users Guide. For information on the use of the Rate Transition block GUI and its use in simulation, see Using Simulink.

Nondefault Ports Now Usable for External Mode on Tornado Platform
In the prior release a bug prevented the use of any but the default port to connect to a Tornado (VxWorks) target via external mode. The problem has been fixed and that configuration now works as documented.
Initialize Block Outputs Even If No Block Output Has Storage Class Auto
Previously, block outputs were initialized only if at least one block output had storage class auto. Now even if there are no auto Block I/O entries, exported globals and custom signals will be initialized.
Code Is Generated Without Errors for Single Precision Datatype Block Outputs
In cases where a reused block outputs entry is the first single-precision datatype block output in the full list of block outputs in the model, Real-Time Workshop now operates without reporting errors. See the Simulink Release Notes for related single-precision block enhancements.
Duplicate #include Statements No Longer Generated
Real-Time Workshop now creates a unique list of C header files before emitting #include statements in the model.h file (formerly placed in model_common.h). For backwards compatibility, the old text buffering method for includes is still available for use, but can cause multiple includes in the generated code. We urge you to update your custom code formats to use the (S)LibAddToCommonIncludes() functions instead of LibCacheIncludes(), which has been deprecated.
Custom Storage Classes Ignored When Unlicensed for Embedded Coder
If a user loads a model that uses custom storage classes, and the user is not licensed for Embedded Coder, the custom storage class is ignored (storage class reverts to auto) and a warning is produced. Previously, this situation would have generated an error.
Erroneous Sample Time Warning Messages No Longer Issued
Erroneous warnings regarding sample times not being in the sample time table for models that contain a variable sample time block and a fixed step solver are no longer issued during model compilation.
Discrete Integrator Block with Rolled Reset No Longer Errors Out
Simulink Accelerator / Real-Time Workshop used to error out if they had a Discrete Integrator block configured in 'ForwardEuler', non-level external reset, and the reset signal was a 'rolled' signal (having a width greater than 5). This has beeen fixed.
Rate Limiter Block Code Generation Limitation Removed
Simulink Accelerator will now generate code for variable step solver models that contain a rate limiter block inside an atomic subsystem.
Multiport Switch with Expression Folding Limitation Removed
Simulink Accelerator and Real-Time Workshop no longer generate a Fatal Error for Multiport Switch when expression folding is enabled.

Pulse Generator Code Generation Failures Rectified
Several problems with code generation for the pulse generator block have been eliminated: If the block type is PulseGenerator instead of Discrete PulseGenerator, code can now be generated. The scalar expansion for the delay variable is now correct. The start function for the Time-based mode in a variable step solver now can generate code. Note: The first two problems also affected the Simulink Accelerator.
Stateflow I/O with ImportedExternPointer Storage Class Now Handled Correctly
Stateflow input pointers for signals of ImportedExternPointer storage class are now correctly initialized, and no longer error out for charts producing output signals that are nonscalar and of ImportedExternPointer storage class.
Parameters for S-Function Target Lookup Blocks May Now Be Made Tunable
The S-Function target code will now compile for models having lookup and Lookup Table (2-D) blocks when parameters for those blocks are tunable.
PreLook-up Index Search Block Now Handles Discontiguous Wide Input
The PreLook-up Index Search block formerly only generated code for signals from the first roll region of discontiguous wide inputs, such as from a Max block. This has been fixed.
SimViewingDevice Subsystem No Longer Fails to Generate Code
Code generation no longer aborts for atomic subsystems configured with SimViewingDevice=on.
Accelerator Now Works with GCC Compiler on UNIX
The previous version of the Accelerator did not work when the user selected the gcc compiler with mex -setup. The Accelerator now supports using the gcc compiler on UNIX systems.
Expression Folding Behavior for Action Subsystems Stabilized
When a model contains an action subsystem (e.g., a for-loop or while-iterator subsystem) and expression folding is enabled, invalid or
inefficient code sometimes was generated for the model. This problem has been fixed.
Dirty Flag No Longer Set During Code Generation
In previous releases a model would be marked as dirty during the code generation process and the status would be restored when the process was finished. With this release the models dirty status does not change during code generation.
Subsystem Filenames Now Completely Checked for Illegal Characters
In previous releases it was possible to specify a subsystem filename that contained illegal (non-alphanumeric) characters, if the name was long enough and the invalid characters were toward the end of the string. In this release this bug has been fixed, and the entire character string is now validated.
Sine Wave and Pulse Generator Blocks No Longer Needlessly Use Absolute Time
Previously, code generated for the Sine Wave and Pulse Generator blocks accessed absolute time when the blocks were configured as sample based. This access is not necessary and its overhead has been removed from the generated code.

Generated Code for Action Subsystems Now Correctly Guards Execution of Fixed in Minor Time Step Blocks
All blocks contained in an action subsystem must have the same rate unless some are continuous and some are fixed in minor step (a.k.a. zoh continuous). If there are both continuous and fixed in minor step blocks then the generated code needs to guard the code for the fixed in minor time step blocks to protect it from being executed in minor time steps.
These guards were not being generated causing some models to have wrong answers and consistency failures. This problem has been fixed and the guards are now generated.
Note This is also a fix for the Simulink Accelerator.
Report Error when Code Generation Requested for Models with Algebraic Loops
Real-Time Workshop does not support models containing algebraic loops. Version 4.1 contained a bug that enabled some models having algebraic loops to generate code which could compute incorrect answers. The models affected were those containing no algebraic loops in their root level but having algebraic loops in one or more subsystems. This bug has been fixed, and now building these models will always cause an error to be reported.
Platform Limitations for HP and IBM
Note The Release 12.0 platform limitation for Real-Time Workshop for the HP and IBM platforms still apply to Release 13. That limitation is described below.
On the HP and IBM platforms, the Real-Time Workshop opens the Release 11 Tunable Parameters dialog box in place of the Model Parameter Configuration dialog box. Although they differ in appearance, both dialogs present the same information and support the same functionality.
This section describes the upgrade issues involved in moving from Real-Time Workshop 4.1 to Version 5.0. If you are upgrading from a version earlier than 4.1, then you should see Upgrading from an Earlier Release on page 6-15 in the Real-Time Workshop 4.1 Release Notes.
Replacing Obsolete Header File #includes
Generated code is packaged into fewer files in this release (see Packaging of Generated Code Files Simplified on page 5-8). If you have interfaced code to code generated by previous releases of Real-Time Workshop, you may need to remove dependencies on header files that are no longer generated (such as model_common.h, model_export.h, model_prm.h, and model_reg.h) and add #include model.h directives.
Custom Code Blocks Moved from Simulink Library
The Custom Code blocks have been removed in Real-Time Workshop version 5.0 (R13). These blocks are now located in a new library, named custcode.mdl (type custcode to access them). Because custom code blocks are linked to this new library, backward compatibility is assured.

Updating Custom TLC Code

In this release, a number of changes have been made to model.rtw files. If your applications depend on parsing model.rtw files using customized TLC scripts, please read model.rtw Changes Between Real-Time Workshop 5.0 and 4.1 in Appendix A of the Target Language Compiler documentation, which describes the structure and contents of compiled models.

tlc -dc <options>

By using the -dc build option in the System target file field of the Real-Time Workshop page. For further information, see Debugging TLC in the Target Language Compiler Reference Guide.
model.rtw File Format Changes
The format of the model.rtw file has changed. See TLC Compatibility Issues on page 6-16.
Cleanup of Block I/O Connection Handling in TLC
The handling of signal connections in rtw/c/tlc/blkiolib.tlc and rtw/ada/ tlc/blkiolib.tlc was reworked. See the discussion of LibBlockInputSignal in TLC Function Library Reference in the Target Language Compiler Reference Guide.

Literal String Support

If a string constant is prefixed by the L format specifier, then no escape character processing is performed on that string. This is useful for specifying PC style path or directory names, as in this example.
%addincludepath L"C:\mytlc"
New TLC Library Functions
The following functions have been added to the TLC Function Library: LibBlockInputSignalConnected LibBlockInputSignalLocalSampleTimeIndex LibBlockInputSignalOffsetTime LibBlockInputSignalSampleTime LibBlockInputSignalSampleTimeIndex LibBlockOutputSignalOffsetTime LibBlockOutputSignalSampleTime LibBlockOutputSignalSampleTimeIndex LibBlockMatrixParameterBaseAddr LibBlockParameterBaseAddr LibBlockNonSampledZC See TLC Function Library Reference in the Target Language Compiler Reference Guide for information on these functions.

TLC Bug Fixes

Fixed a bug where local variables of calling functions were sometimes incorrectly visible to called functions. The ISINF, ISNAN, and ISFINITE functions now work for complex values. The %filescope directive now works as documented.
Zero indexing on complex numbers is now supported. In prior releases, the Target Language Compiler allowed 0 indexing for integer and real values, but not for complex values. This restriction has been removed in the Target Language Compiler 4.1, as shown in the following example.
%assign a = 1.0 + 3.0i %assign b = a[0] %% zero index now allowed
Fixed a crash that occurred if ROLL_ITERATIONS was called outside of a %roll construct. ROLL_ITERATIONS returns NULL if called outside of a %roll construct. TLC now allows use of any path separator character independent of operating system. You can use either \ or / as a path separator character on Unix or Windows). Fixed a bug in the compare for equality operation. 0.0 now compares equal to -0.0.

Bug Fixes

The Real-Time Workshop 4.1 includes the bug fixes described in this section. See also TLC Bug Fixes on page 6-9 for bug fixes specific to the Target Language Compiler.
Block Reduction Crash Fixed
A problem that crashed MATLAB due to a segmentation fault during the block reduction process has been fixed. This problem occurred only if the Block Reduction option was on, and if a Scope block was connected to a block that was removed due to block reduction.
Build Subsystem Gives Better Error Message for Function Call Subsystems
The Build Subsystem feature does not currently support triggered function-call subsystems. The Real-Time Workshop now gives a a more informative error message when a Build Subsystem is attempted with a triggered function-call subsystem.
Check Consistency of Parameter Storage Class and Type Qualifier
The Real-Time Workshop now checks for consistency of parameter storage class and type qualifier when a parameter is specified by both the Model Parameter Configuration dialog box and a referenced Simulink data object.
Code Optimization for Unsigned Saturation and DeadZone Blocks
When the lower limit of a Saturation or DeadZone block is a zero and is nontunable, and the data type is unsigned, the comparison against the lower limit is omitted from the code. Similarly, if the upper or lower limit of the Saturation block is nontunable and nonfinite, the comparison against the infinite limit is omitted.
Correct Code Generation of Fixed-Point Blockset Blocks in DSP Blockset Models
A code generation bug involving some DSP Blockset blocks (see list below) was fixed. When these blocks were driven by a block from the Fixed-Point Blockset, generated code would write outside array memory bounds. The following DSP Blockset blocks generated incorrect code: Delay Line Frame Status Conversion Matrix Multiply Multiport Selector Pad Submatrix Window Function Zero Pad
Correct Compilation with Green Hills and DDI Compilers

Compilation errors for files associated with matrix inversion in the matlabroot/rtw/c/libsrc directory were fixed. These errors occurred with the Green Hills and DDI compilers.
Fixed Build Error with Models Having Names Identical to Windows NT Commands
This fix prevents an error that occurred when building models having names identical to Windows NT internal commands. Examples would be models named verify or path. Such model names are now allowed.
Fixed Error Copying Custom Code Blocks
An error in the Custom Code block Copyfcn callback was fixed. The problem caused an error when copying a custom code block within a model.
Fixed Error in commonmaplib.tlc
A typo in rev 1.17 of commonmap.tlc was fixed. This typo caused an error during code generation, when using the grt_malloc target with External mode selected.
Fixed Name Clashes with Run-Time Library Functions
The Real-Time Workshop now uses the macros rt_min and rt_max to avoid clashing with run-time library min and max functions.
Improved Handling of Sample Times
The sample time handling for the S-function and ERT targets has been improved to use the compiled sample time instead of the user specified sample time on the input port blocks.
Look-Up Table (n-D) Code Generation Bug Fix
The Real-Time Workshop now generates correct code for Look-Up Table (n-D) blocks having 5 or more dimensions with different dimension sizes.
Parenthesize Negative Numerics in Fcn Block Expressions
Fcn block expressions in the generated code failed to compile in the case of a unary operator preceding a workspace variable with a negative value, such as the expression
Such expressions are now enclosed in parentheses, as in

(-v) * u

Removed Unnecessary Warnings and Declarations from Generated Code
Several unnecessary warnings and declarations in the generated code have been removed. These include: In functions where the tid argument is not referenced, the declaration

(void)tid

is no longer generated. (The tid argument is required because the function API is predefined.) Warnings involving const casts were suppressed in some of the rtw/c/libsrc modules.
Retain.rtw File Option Now Works in Accelerator Mode
In previous releases, the Retain.rtw file option (on the TLC Debugging Options page of the Simulation Parameters dialog box) was ignored if Simulink was in Accelerator mode. Now, you can retain the model.rtw file during a build, regardless of the simulation mode.

Build Directory

The Real-Time Workshop 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 build directory name, model_target_rtw, derives from the name of the source model and the chosen target. See Directories Used in the Build Process in the Real-Time Workshop Users Guide for details.
Note If you have created custom targets for the Real-Time Workshop under Release 11, you must update your custom system target files and template makefiles to create and utilize the build directory. See Updating Release 11 Custom Targets on page 7-12.
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 page of the Simulation Parameters dialog box. See Advanced Options Page for full details. Block reduction: When the Block reduction option is 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 multiple block parameters refer to storage locations that are separately defined but structurally identical, you can use this option to save memory.
Signal storage reuse: This option replaces the (Enable/Disable) Optimized block I/O storage option of previous releases. Signal storage reuse is functionally identical to the older feature. Turning Signal storage reuse on is equivalent to enabling Optimized block I/O storage. See the chapter Optimizing the Model for Code Generation in the Real-Time Workshop Users Guide for further information on code optimization.
Subsystem Based Code Generation
The Real-Time Workshop 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 Users Guide for details.
Nonvirtual Subsystem Code Generation
The Real-Time Workshop 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 subsystems Block Parameters dialog. Nonvirtual subsystem code generation is a more general and flexible method of controlling the number and size of generated files than the Function management code generation options (File splitting and Function splitting) used in previous releases. The Function management code generation options have been replaced by nonvirtual subsystem code generation. See Nonvirtual Subsystem Code Generation in the Real-Time Workshop Users Guide for details.

In bringing Target Language Compiler files from Release 11 to Release 12, the following changes may affect your TLC code base: Nested evaluations are no longer supported. Expressions such as
%<LibBlockParameterValue(%<myVariable>,"", "", "")>
are no longer supported. You will have to 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 Ref } Record2 Val Ref } { 2 Record2 { 3 Record1
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)

EXISTS( %<var> )

Latest Features in Real-Time Workshop

March 2010

Demo Download
The demos presented in this document can be found in the shipping version of the product or at www.mathworks.com/support/solutions/en/data/1BWO86Z.
Maximum Stack Size Allowance Specification
Fully control maximum stack size allocation with a single option; generate better code (next slide) Works seamlessly across Simulink, Stateflow, and Embedded MATLAB functions Supports stack size control for a full model reference hierarchy Backward compatible with MaxStackSize TLC setting
Demo: >> set_param(model, MaxStackSize, 1000)
Stack Overflow Analysis and Protection Improvement
Stack overflow analysis results in more efficient code and better accuracy for large signals
Unnecessary global variables for large signals are optimized away Reduces RAM and ROM Improves execution speed
Extra global memory Demo: >> stack_overflow
void stack_overflow_step(void) { int32_T i; for (i = 0; i < 513; i++) { B.Gain2[i] = 2.0 * U.In1[i]; Y.Out1[i] = 3.0 * B.Gain2[i]; B.Gain2[i] = 4.0 * B.Gain2[i]; Y.Out2[i] = B.Gain2[i]; } }
void stack_overflow_step(void) { int32_T i; real_T rtb_Gain_0; for (i = 0; i < 513; i++) { rtb_Gain_0 = 2.0 * U.In1[i]; Y.Out1[i] = 3.0 * rtb_Gain_0; Y.Out2[i] = 4.0 * rtb_Gain_0; } }

R2009b

R2010a
C++ Code Interface in Embedded MATLAB

Integrating C++ code

Generate C++ code that can interface with legacy C++ files Select C++ code generation target Include custom C++ files in the compilation process
Demo: >> cpp_intrf_script
Create Libraries with Multiple Entry-Point Functions in Embedded MATLAB
Share code between functions using static libraries with multiple entry-point functions Persistent and global data can be used internally to communicate between different library functions.
Compiling multiple entry-point MATLAB files

subeg is shared

Demo: >> cpp_lib_script
Global Data in Embedded MATLAB
Access and share global data between Simulink and Embedded MATLAB using Data Store Memory blocks Reduce input/output ports used only for sharing data between Simulink and Embedded MATLAB Migrate legacy MATLAB code using global data to Embedded MATLAB
Global data used in Embedded MATLAB function Global data initialized for emlcoder
Demo: >> eml_global_data_script
Optimization for Bus Assignment Usage Pattern
Bus elements are efficiently propagated using popular modeling patterns
Optimizes away redundant copies when using a series of Bus assignments blocks with the Switch block Reduces RAM and ROM Improves execution speed
See next slide for generated code
Demo: >> bus_assign_switch
rtb_end_d = rtU.In2.a.end; rtb_data_bytes_p = rtU.In2.a.data_bytes; for (i = 0; i < 8; i++) { rtb_p_data_o[i] = rtU.In2.a.p_data[i]; } rtY.Out1.start = rtU.In2.start; rtY.Out1.end = rtU.In2.end; rtY.Out1.a.start = rtb_start_d; rtY.Out1.a.end = rtb_end_d; rtY.Out1.a.data_bytes = rtb_data_bytes_p; for (rtb_start_d = 0; rtb_start_d < 8; rtb_start_d++) { rtY.Out1.a.p_data[rtb_start_d] = rtb_p_data_o[rtb_start_d]; }

Extra memory and copies

rtY.Out1.start = rtU.In2.start; rtY.Out1.end = rtU.In2.end; rtY.Out1.a.start = rtb_start_d; rtY.Out1.a.end = rtU.In2.a.end; rtY.Out1.a.data_bytes = rtU.In2.a.data_bytes; for (rtb_start_d = 0; rtb_start_d < 8; rtb_start_d++) { rtY.Out1.a.p_data[rtb_start_d] = rtU.In2.a.p_data[rtb_start_d]; }

Optimization for Enabled Subsystem Usage Pattern
Generate concise if-then-else statement using a popular modeling pattern
Optimizes away redundant if conditions generated from Enabled Subsystem and Merge block modeling patterns when possible Reduces RAM and ROM Improves execution speed
if (U.In1) { B.Merge = 2.0 * U.In2 * 2.0 * 2.0; } if (!U.In1) { B.Merge = 3.0 * U.In2 * 3.0; } Y.Out1 = B.Merge; if (U.In1) { Y.Out1 = 2.0 * U.In2 * 2.0 * 2.0; } else { Y.Out1 = 3.0 * U.In2 * 3.0; }
Demo: >> enabled_subsystem_pattern
Data Copy Elimination During Matrix Assignment
Reduce memory for matrix assignments
Optimizes matrix assignments using matrix indexing in the form of for-loops Reduces RAM and ROM Enables other optimizations that improve execution speed
Demo: >> data_copy_elim_matrix
int16_T rtb_Abs1[100]; Extra uint32_T tmp; Memory int16_T tmp_0; int32_T i; for (i = 0; i < 100; i++) { rtb_Abs1[i] = (int16_T)(rtP.Gain1_Gain[i] * rtP.Constant1_Value); if (rtb_Abs1[i] < 0) { tmp = (uint32_T)(-rtb_Abs1[i]); if (tmp > 32767U) { tmp_0 = MAX_int16_T; Extra } else { Copies tmp_0 = (int16_T)tmp; } rtY.Out2[i] = tmp_0; } rtY.Out2[i] = rtb_Abs1[i]; } }
int32_T i; int16_T rtb_Abs; Variable Name Preserved for (i = 0; i < 100; i++) { rtb_Abs = (int16_T)(rtP.Gain1_Gain[i] * rtP.Constant1_Value); if (rtb_Abs < 0) { rtY.Out2[i] = (int16_T)(-rtb_Abs); } else { rtY.Out2[i] = rtb_Abs; } } 12
Guidance on Choosing Solutions for External Code Integration
Choose solutions that best meet application needs
Use a flow diagram to determine the type of integration that applies Use flow diagrams and related tables to identify and apply optimal solutions based on application characterization and requirements
See Real-Time Workshop > Users Guide > Integrating External Code With Generated C and C++ Code > About External Code Integration 13
Information on How to Customize Targets Available with Real-Time Workshop
Access information previously available only with Real-Time Workshop Embedded Coder to learn how to:
Generate executable code for a specific CPU, using a specific development environment Support I/O devices on the target hardware Configure the build process for a development environment
See Real-Time Workshop > Users Guide > Preparing Models for Code Generation > Customizing Targets