| Version 5.0 (R13) Real-Time Workshop® Software Release Notes | |
This table summarizes what's new in V5.0 (R13):
| 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 | No |
New features and changes introduced in this version are organized by these topics:
Generate HTML Report Option Available for Additional Targets
Efficiency of Code Generated for GRT and GRT-Malloc Targets Improved
The Real-Time Workshop® product supports Version 5.6 of the Borland® C compiler.
In addition, V5.0 (R13) reinstates support for Borland Version 5.2 "out-of-the-box" for all targets, except when Real-Time Workshop generates importing S-functions. In such instances, designate the build directory where the S-function may be found via the make_rtw parameter USER_INCLUDES. For example, suppose you had generated S-function target code for model modelA.mdl in build directory D:\modelA_sfcn_rtw and were using that S-function in model modelB.mdl. In modelB.mdl, the Make command field of your Target configuration category should define USER_INCLUDES as follows:
make_rtw "USER_INCLUDES=-ID:\modelA_sfcn_rtw"
Template makefiles have been updated to include linking against sys/lcc/lib.
Comments Not Generated for Reduced Blocks When "Show eliminated statements" Is Off
Identifier Construction for Generated Code Has Been Simplified
GUI Control over Behavior of Assertion Blocks in Generated Code
To make selecting diagnostics easier, the Diagnostics entries on the Simulation Parameters dialog box have been reorganized according to functionality, and alphabetically within each group, as shown in the next figure.
The Show eliminated statements option (in the Real-Time Workshop General code generation options category) is now off by default. As long as it remains off, the Real-Time Workshop software no longer generates comments referring to blocks that have been removed from the model via block reduction optimization.
Compatibility Considerations. If you want the Real-Time Workshop software to generate comments for blocks that are removed due for block reduction optimization, select the Show eliminated statements option.
A new section has been added to the Real-Time Workshop pane of the Simulation Parameters dialog box, named General code appearance options. The new section groups four new code formatting options to two existing options. The General code appearance appear as shown in the next figure.
The four new options are
| Option | Description |
|---|---|
| Maximum identifier length | Allows you to limit the number of characters in function, type definition, and variable names. The default is 31 characters, but the Real-Time Workshop software imposes no upper limit. |
| Include data type acronym in identifier | Prepends acronyms such as i32 (for long integers) to signal and work vector identifiers to make code more readable. The default is not to include data type acronyms in identifiers. |
| Include system hierarchy number in identifiers | Adds prefixes s#_, where # is a unique integer subsystem index, to identifiers declared in that subsystem. This enhances traceability of code, for example via the hilite_system<`S#'> command. The default is not to include a system hierarchy index in identifiers. |
| Prefix model name to global identifiers | Prefixes subsystem function names with the name of the model (model_). The model name is also prefixed to the names of functions and data structures at the model level, when appropriate to the code format. This is useful when you need to compile and link code from two or more models into a single executable, as it avoids potential name clashes. This option is on by default. |
| Generate scalar inline parameters as: | Controls the code style for inlined parameters. You can set this option to literals or macros. When constant parameters are inlined and declared not tunable, the following code generation options are available:
The default is to generate scalar inline parameters as literals. Note: S-functions can mark a run-time parameter as being constant to guarantee that it never ends up in the rtP data structure. Use ssSetConstRunTimeParamInfo in the S-function to register a constant runtime parameter. |
| Generate comments | An existing global option moved from the General code generation options (cont) category to this one. As in the prior release, by default Generate comments is on. |
The methods the Real-Time Workshop software uses to construct identifiers for variables and functions have been enhanced to make identifiers more understandable and more customizable. As a result of these enhancements
Changes to sections of the model do not cause identifiers elsewhere to change.
Reused function input arguments now derive their name from the inport block.
Subsystem function names can be prefixed by the model name to prevent link errors due to name conflicts.
You can specify a maximum identifier length (can be > 31 characters).
A new option exists to include a data type acronym in identifiers.
Use of _a, _b, ... postfixes to identifiers to prevent name clashes has been dramatically reduced.
The Advanced pane of the Simulation Parameters dialog box provides a new Model Verification block control popup menu you can use to specify whether model verification blocks such as Assert, Check Static Gap, and related range check blocks will be enabled, not enabled, or default to their local settings. This popup menu has the same effect on Real-Time Workshop generated code as it does on simulation behavior, and also may be customized.
For Assertion blocks that are not disabled, the generated code for a model includes one of the following statements at appropriate locations, depending on the block's input signal type (Boolean, real, or integer, respectively).
utAssert(input_signal); utAssert(input_signal != 0.0); utAssert(input_signal != 0);
By default utAssert is a non-option in generated code. For assertions to abort execution you must enable them by including a parameter in the make_rtw command. Specify the Make command field on the Target configuration category pane as follows:
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® calls back to itself to execute assertion blocks instead of using generated code. Thus a user-defined callback is still called when assertions fail.
Prior versions required you to specify the -da Target Language Compiler command switch for TLC %assert directives to be evaluated. Now you can more conveniently trigger %assert code by selecting the Enable TLC Assertions check box on the TLC debugging section of the Real-Time Workshop dialog. The default state is for asserts not to be evaluated. You can also control assertion handling from the MATLAB® command window. To set or unset assertion handling, use the following command. The option is off by default.
set_param(model, 'TLCAssertion', 'on|off')
To see the current setting, use the command
get_param(model, 'TLCAssertion')
Hook Files Required for Communicating Target-specific Word Characteristics
Code Generation Unified for Real-Time Workshop® and Stateflow® Products
The Real-Time Workshop software V5.0 (R13) introduces the ability to reuse code generated for nonvirtual subsystems. In prior releases, the Real-Time Workshop software generated a separate block of code for each nonvirtual subsystem. In some circumstances — for example, when you use a library block multiple times in the same fashion — it is now 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 build process must pass in appropriate data elements (as function arguments) for each caller of a reused subsystem. Code generated by the Real-Time Workshop software V5.0 (R13) enables such arguments for functions generated for nonvirtual subsystems.
You enable code reuse through the Subsystem parameters dialog when both Treat as atomic unit and Reusable function from the RTW system code pull-down menu are selected, as illustrated in the next figure.
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 the Real-Time Workshop build process to revert to another RTW system code option even though you specify Reusable function or Auto. When you specify Reusable function and reuse is not possible, the result is a function without arguments. When you specify Auto and reuse is not possible, the Real-Time Workshop build process inlines the subsystem's code (or in special cases, creates 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 Generating 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:
The chart (or subsystem containing the chart) must be a library block (see Working with Block Libraries in the Simulink documentation).
Data in the chart must not be initialized from workspace. The data property Initialize from workspace should be off.
The chart must not output a function call.
See Nonvirtual Subsystem Code Generation in the Real Time Workshop documentation for more details.
Compatibility Considerations. The Real-Time Workshop software V5.0 (R13) alters aspects of generated code to support code reuse for nonvirtual subsystems. As explained above, you have the ability to select or override this feature, as well as to specify function and file names from the graphical user interface.
The packaging of generated code into.c and.h files has been simplified. The following table summarizes the structure of source code generated by the Real-Time Workshop software. All code modules described are written to the build directory.
Note The Real-Time Workshop® Embedded Coder™ file packaging differs slightly (but significantly) from the file packaging described here. See Code Modules in the Real-Time Workshop Embedded Coder User's Guide for more information. |
File | Description |
|---|---|
model.c | Contains entry points for all code implementing the model algorithm (MdlStart, MdlOutputs, MdlUpdate, MdlInitializeSizes, MdlInitializeSampleTimes). Also contains model registration code. |
model_private.h | Contains local defines and local data that are required by the model and subsystems. This file is included by subsystem.c files in the model. You do not need to include model_private.h when interfacing handwritten code to a model. |
model.h | 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 (model_rtM) via access macros. model.h is included by subsystem.c files in the model. If you are interfacing your handwritten code to generated code for one or more models, you should include model.h for each model to which you want to interface. |
model_data.c (conditional) | model_data.c is conditionally generated. It contains the declarations for the parameters data structure and the constant block I/O data structure. If these data structures are not used in the model, model_data.c is not generated. Note that these structures are declared extern in model.h. |
model_types.h | 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. model_types.h is included by all subsystem.h files in the model. |
rtmodel.h | Contains #include directives required by static main program modules such as grt_main.c and grt_malloc_main.c. Since these modules are not created at code generation time, they include rt_model.h to access model-specific data structures and entry points. If you create your own main program module, take care to include rtmodel.h. |
model_pt.c (optional) | Provides data structures that enable a running program to access model parameters without use of external mode. |
model_bio.c (optional) | Provides data structures that enable your code to access block outputs. |
Compatibility Considerations. If you have interfaced handwritten code to code generated by previous releases of the Real-Time Workshop software, you might need to remove dependencies on header files that are no longer generated. Use #includemodel.h directives, and remove #include directives that refer to any of the following:
| Old Filename | New Filenames |
|---|---|
| model_common.h | model_types.h and model_private.h |
| model_export.h | model.h |
| model_prm.h | model_data.c |
| model_reg.h | model.c |
In previous releases, the files required for deploying an S-function block that you generated using the S-function target were the following:
For S-function inclusion in other models for simulation, the binary MEX-file object subsys_sf.mexext, where subsys is the subsystem name and mexext is a platform-dependent MEX-file extension. (For example, SourceSubsys_sf.dll.)
For S-function inclusion in other models for code generation, subsys_sf.c (the stub file), subsys_sf.mexext, and subdirectory subsys_sfcn_rtw with at least the following files:
subsys_sf.c
subsys_sf.h
subsys_sf_common.h
subsys_sf_export.h
subsys_sf_prm.h
subsys_sf_reg.h
subsys_sid.h
Beginning in the Real-Time Workshop software V5.0 (R13) , due to the packaging improvements described in Packaging of Generated Code Files Simplified, different files are required for deploying your S-function block. For details, see Required Files for S-Function Deployment.
Compatibility Considerations. To deploy your S-function blocks for inclusion in models created in R13 or a later release, you should regenerate the S-function blocks using the same release that created the models, and deploy the S-function blocks using the files described in Required Files for S-Function Deployment.
The GRT, GRT-Malloc, ERT, and Tornado targets now use the rtModel data structure to store information about the root model.
Compatibility Considerations. In prior releases, the information about the root models was stored in the data structure SimStruct. Since the SimStruct data structure was also used by noninlined S-functions, it contained a number of S-function fields that were not needed to represent root model information. The new rtModel structure is lightweight and eliminates the 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), and so on. 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.
If you have previously customized GRT, GRT-Malloc, or Tornado targets, upgrade each customized target to use the rtModel instead of SimStruct.
To upgrade a target to use the rtModel instead of the SimStruct:
Include rtmodel.h instead of simstruc.h at the top.
Since the rtModel data structure has a type that includes the model name, you need to include the following lines at the top of the file:
#define EXPAND_CONCAT(name1,name2) name1 ## name2
#define CONCAT(name1,name2) EXPAND_CONCAT(name1,name2)
#define RT_MODEL CONCAT(MODEL,_rtModel)
Change the extern declaration for the function that creates and initializes the SimStruct to be:
extern RT_MODEL *MODEL(void);
Change the definitions of rt_CreateIntegrationData and rt_UpdateContinuousStates to be as shown in the Release 13 version of grt_main.c (or grt_malloc_main.c).
Change all function prototypes to have the argument 'RT_MODEL' instead of the argument 'SimStruct'.
Change the names of the following functions such that they use the prefix rt_Sim instead of rt_ and then change the arguments you pass into them.
| rt_GetNextSampleHit |
| rt_UpdateDiscreteTaskSampleHits |
| rt_UpdateContinuousStates |
| rt_UpdateDiscreteEvents |
| rt_UpdateDiscreteTaskTime |
| rt_InitTimingEngine |
See grt_main.c (or grt_malloc_main.c) for the list of arguments that need to be passed into each function.
Modify macros that refer to the SimStruct to now refer to the rtModel. Examples of these modifications include changing
ssGetErrorStatus to rtmGetErrorStatus
ssGetSampleTime to rtmGetSampleTime
ssGetSampleHitPtr to rtmGetSampleHitPtr
ssGetStopRequested to rtmGetStopRequested
ssGetTFinal to rtmGetTFinal
ssGetT to rtmGetT
In addition to the changes to the main C files, change the target TLC file and the template make files.
In your template make file, define the symbol USE_RTMODEL. See one of the GRT or GRT-Malloc template makefiles for an example.
In your target TLC file, add the following global variable assignment:
%assign GenRTModel = TLC_TRUE
You must now supply a target hook file (M-file) to specify target hardware characteristics, such as word sizes and overflow behavior.
Compatibility Considerations. To communicate details about target hardware characteristics, you must now 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, you must name the file grt_rtw_info_hook.m, and the file needs to be on the MATLAB path. If the hook file is not provided, the Real-Time Workshop software uses default values based on the host's characteristics, 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.
The Real-Time Workshop build process now generates code for models that include Stateflow charts in a single set of output files.
Compatibility Considerations. In earlier releases, the Real-Time Workshop build process wrote code generated from Stateflow charts to source code files distinct from the source code files (such as model.c, model.h, etc.) generated from the rest of a model.
Now, by default, the Stateflow software no longer generates any separate files from the Real-Time Workshop software. 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 build process 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 the names of the functions and the code files generated.
This release introduces an optimization called conditional input branch execution, which speeds simulation and execution of code generated from the model.
Compatibility Considerations. 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 the Real-Time Workshop software execute only the code needed to compute the control input and the selected data input. To explore this feature, see the demo rtwdemo_condinput .
S-Function API Extended to Permit Users to Define DWork Properties
Lookup Table Blocks Use New Run-Time Library for Smaller Code
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 multirate 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.
For more information on the use of the Rate Transition block with the Real-Time Workshop product, see Sample Rate Transitions in the Real-Time Workshop documentation. For a detailed description of the new block, see Rate Transition in the Simulink reference documentation.
The S-Function API has been extended to permit specification of an Real-Time Workshop identifier, storage class, and type qualifier for each DWork that an S-Function creates. The extensions consist of the following macros:
| ssGetDWorkRTWIdentifier(S,idx) |
| ssSetDWorkRTWIdentifier(S,idx,val) |
| ssGetDWorkRTWStorageClass(S,idx) |
| ssSetDWorkRTWStorageClass(S,idx,val) |
| ssGetDWorkRTWTypeQualifier(S,idx) |
| ssSetDWorkRTWTypeQualifier(S,idx,val) |
As is the case with data store memory or discrete block states, the Real-Time Workshop identifier may resolve against a Simulink.Signal object. An example has been added to sfundemos, in the miscellaneous category.
Lookup Table (2-D), Lookup Table (3-D), PreLook-Up Using Index Search, and Interpolation using PreLook-Up blocks now generate code that targets one of the many new specific, optimized lookup table operations in the Real-Time Workshop runtime library. This results in dramatically smaller code size. The library lookup functions themselves incorporate more enhancements to the actual lookup algorithms for speed improvements for most option settings, especially for linear interpolations.
Relay blocks can now handle frame-based input signals. Each row in a frame-based input signal is a separate set of samples in frames and each column represents a different signal channel. The block parameters should be scalars or row vectors whose length is equal to the number of signal channels. The block does not allow continuous frame-based input signals.
Code generation for models containing the Transport Delay and Variable Transport Delay is now require less space.
You can now control how Data Store Memory blocks in your model are stored and represented in the generated code, by assigning storage classes and type qualifiers. You do this in almost exactly the same way you assign storage classes and type qualifiers for block states. You can also associate a Data Store Memory block with a signal object, and control code generation for the block through the signal object.
See Storage Classes for Data Store Memory Blocks in the Real-Time Workshop documentation for more information.
Executables generated for the Rapid Simulation (RSim) target are now able to use any Simulink solver, including variable-step solvers. To use this feature, the target system must be able to check out a Simulink license when running the generated RSim executable.
For details, see Licensing Protocols for Simulink® Solvers in RSim Executables.
You can maintain backwards compatibility (that is, fixed-step solvers only, with no need to check out a Simulink license) by selecting Use RTW fixed step solver from the Solver Selection popup menu on the Rapid Simulation code generation options dialog. The default solver option is Auto, which will use the Simulink solver module only when the model requires it.
Support for Rapid Simulation (RSim) target
The RSim target now includes full support for all features of Simulink external mode. External mode lets you use your Simulink block diagram as a front end for a target program that runs on external hardware or in a separate process on your host computer, and allows you to tune parameters and view or log signals as the target program executes.
Support for ERT target
The Real-Time Workshop Embedded Coder software now includes full support for all features of Simulink external mode. External mode lets you use your Simulink block diagram as a front end for a target program that runs on external hardware or in a separate process on your host computer, and allows you to tune parameters and view or log signals as the target program executes.
Support for uploading signals of all storage classes
Signals from all storage classes, including custom, can now be uploaded in external mode, as long as signals or parameters have addresses defined. For example, data stored as bit fields or #defines cannot be uploaded, but few other restrictions exist.
Simulink data objects include several new string properties that you can exploit for customizing code generation. These properties are
Simulink.Data.Description Simulink.Data.DocUnits RTWInfo.Alias
In this release, the Simulink engine and Target Language Compiler do not use these properties. The properties are included in the model.rtw file and are reserved for future use. RTWInfo.Alias defines the identifier to be used in place of the parent data object (parameter, signal, or state) in the code. The engine checks that the alias is uniquely used by only that object.
In this release, a number of changes have been made to model.rtw.
If your applications depend on parsing model.rtw files using customized TLC scripts, 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.
In earlier releases, the Generate HTML report option was available only for the Real-Time Workshop Embedded Coder product. In the current release, the report is available for all targets (except the S-Function target and Rapid Simulation target).
The Generate HTML report option is located in the General code generation options category of the Real-Time Workshop page of the Simulation Parameters dialog box, as shown in the next figure.
The option is on by default. An abbreviated report is generated if you do not have the Real-Time Workshop Embedded Coder product installed.
Substantial changes have been made to the GRT and GRT-Malloc targets to improve the efficiency of generated code.
If you have customized either type of target, you should make changes to your modified files to ensure that your target works properly with V5.0 (R13) of the Real-Time Workshop software.
You should begin with the versions of the target files included in this release, and introduce all of your existing customizations to them. If you are unable to follow this upgrade path, then perform all steps outlined in Most Targets Use rtModel Instead of Root SimStruct and Logging Code Moved to the Real-Time Workshop® Library.
All the support functions used for logging data have been moved from rtwlog.c to the Real-Time Workshop library.
If you have customized a GRT or GRT-Malloc Target, make the following changes to ensure compatibility with the new logging functions:
Remove rtwlog.c from all of your template make files.
In your target's main C file (which was derived from grt_main.c or grt_malloc_main.c), include rt_logging.h instead of rtwlog.h.
In your target's main C file (which was derived from grt_main.c or grt_malloc_main.c), you need to change the calls to the logging related functions because the prototypes of these functions have changed. See grt_main.c (or grt_malloc_main.c) for the list of arguments that needs to be passed into each function.
The Custom Code blocks have been moved to 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.
SPRINTF built-in function added
A C-like sprintf formatting function has been added to the Target Language Compiler, which returns a TLC string encoded with data from a variable number of arguments.
$assign str = SPRINTF(format,var,...) formats the data in variable var (and in any additional variable arguments) under control of the specified format string, and returns a string variable containing the values. The function operates like C library sprintf(), except that output is the return value rather than contained in an argument to sprintf.
BlockInstanceData function no longer available
%filescope directive added
A new directive, %filescope, is now available for limiting scopes of variables to the files in which they are defined. All variables defined after the appearance of %filescope in a file have this property; otherwise, they default to global variables.
Global variables :: operator available
Use of the :: operator to access global variables is now allowed in TLC files. Variables defined on the command line and records read from model.rtw files remain global variables. Nested include files cannot access variables local to the file that included them.
S-function TLC files should no longer use the BlockInstanceData function. All data used by a block should be declared using data type work vectors (DWork).
The expression folding API is documented and available for you to use, particularly for writing inlined S-functions. In addition, expanded capabilities are available that support the TLC user control variable (ucv) in %roll directives, and enable expression folding for blocks such as Selector. See Writing S-Functions That Support Expression Folding in the Real-Time Workshop documentation for details.
The Real-Time Workshop® User's Guide has been significantly updated and reorganized.
Information pertaining to data structures and subsystems has been updated and made more accessible.
New features and GUI changes have been documented
A new Real-Time Workshop® Getting Started Guide is available. This document explains basic Real-Time Workshop concepts, organizes tutorial material for easier access, and cross-references more detailed explanations in the User's Guide.
The Target Language Compiler documentation has been significantly updated and reorganized. A revised collection of tutorial examples provides new users with a more grounded introduction to TLC syntax. Documentation on the TLC Function Library and contents of model.rtw files has also been updated.
ImportedExtern and ImportedExternPointer Storage Class Data No Longer Initialized
External Mode Properly Handles Systems with no Uploadable Blocks
Nondefault Ports Now Usable for External Mode on Tornado Platform
Initialize Block Outputs Even If No Block Output Has Storage Class Auto
Code Is Generated Without Errors for Single Precision Data Type Block Outputs
Custom Storage Classes Ignored When Unlicensed for the Real-Time Workshop® Embedded Coder™ Product
Discrete Integrator Block with Rolled Reset No Longer Errors Out
Stateflow® I/O with ImportedExternPointer Storage Class Now Handled Correctly
Parameters for S-Function Target Lookup Blocks May Now Be Made Tunable
PreLookup Index Search Block Now Handles Discontiguous Wide Input
Expression Folding Behavior for Action Subsystems Stabilized
Subsystem Filenames Now Completely Checked for Illegal Characters
Sine Wave and Pulse Generator Blocks No Longer Needlessly Use Absolute Time
Report Error when Code Generation Requested for Models with Algebraic Loops
The Real-Time Workshop build process now reverts to its previous behavior of not initializing data whose storage class is ImportedExtern or ImportedExternPointer. Such initialization is the external code's responsibility.
Connecting to systems with no blocks that can be uploaded in external mode used to fail and cause Simulink to act as though a simulation was running when none was. The only way to exit the model was to exit MATLAB. Connecting to these systems now will display a warning in the MATLAB command window and then run normally.
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.
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 are initialized.
In cases where a reused block outputs entry is the first single-precision data type block output in the full list of block outputs in the model, the Real-Time Workshop software now operates without reporting errors. See the Simulink Release Notes for related single-precision block enhancements.
The Real-Time Workshop build process 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. You should update your custom code formats to use the (S)LibAddToCommonIncludes() functions instead of LibCacheIncludes(), which has been deprecated.
If a user loads a model that uses custom storage classes, and the user is not licensed for the Real-Time Workshop Embedded Coder product, 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 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.
Simulink® Accelerator™ and Real-Time Workshop products 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 been fixed.
The Simulink Accelerator software now generates code for variable-step solver models that contain a rate limiter block inside an atomic subsystem.
Simulink Accelerator and Real-Time Workshop products no longer generate a Fatal Error for Multiport Switch when expression folding is enabled.
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.
The first two problems also affected the Simulink Accelerator software.
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.
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.
The PreLookup 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.
Code generation no longer aborts for atomic subsystems configured with SimViewingDevice=on.
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.
When a model contains an action subsystem (that is, 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.
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 model's dirty status does not change during code generation.
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.
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.
All blocks contained in an action subsystem must have the same rate unless some are continuous and some are fixed in minor step ("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.
This is also a fix for the Simulink Accelerator software.
The Real-Time Workshop software does not support models containing algebraic loops. V4.1 (R12.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.
The V4.0 (R12) Real-Time Workshop platform limitation for the HP and IBM® platforms still applies to V5.0 (R13). On the HP and IBM platforms, the Real-Time Workshop software opens the V3.0 (R11) 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.
| Version 5.0.1 (R13+) Real-Time Workshop® Software | Version 4.1 (R12.1) Real-Time Workshop® Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |