Products & Services Solutions Academia Support User Community Company

Learn more about Real-Time Workshop Embedded Coder   

Version 5.3 (R2009a) Real-Time Workshop Embedded Coder Software

This table summarizes what's new in Version 5.3 (R2009a):

New Features and ChangesVersion Compatibility ConsiderationsFixed Bugs and Known ProblemsRelated Documentation at Web Site
Yes
Details below
Yes—Details labeled as Compatibility Considerations, below. See also SummaryBug Reports
Includes fixes
No

New features and changes introduced in this version are

Ability to Specify Code Generation Objectives

Previously, setting up your model for code generation was difficult due to the complexity of options and settings available. In R2009a, you can specify high-level code generation objectives and run Model Advisor checks to identify changes to model constructs and settings that improve the generated code.

The high-level code generation objectives available in R2009a are:

After specifying your code generation objectives, you can run Model Advisor checks before generating code to identify suggested changes to your model and make the changes using the Model Advisor interface. The generated code includes comments identifying which high-level objectives you specified, and the results of the Model Advisor run at the time of code generation.

The new rtwdemo_usingrtwec demo shows you how you can specify code generation objectives.

For details, see Mapping Application Objectives to Model Configuration Parameters. For limitations that apply, see Limitations on Code Generation Objectives.

Ability to Specify Custom Storage Classes as Signal Properties

In previous releases, applying a custom storage class to a signal required creating a Simulink.Signal object in the base workspace, specifying the custom storage class and its custom attributes in the object, and resolving the signal to the object in some way.

A signal object that specifies a custom storage class can be applied to at most one signal. This restriction can cause a proliferation of base workspace signal objects that apply the same custom storage class to multiple signals. In addition, base workspace signal objects cannot be saved with a model; they must be saved in a separate file and loaded whenever the model is loaded.

To overcome these disadvantages, R2009a allows you to apply a custom storage class to a signal by specifying the storage class in the Signal Properties dialog box that defines the signal. This technique creates an embedded signal object that is associated with the port where the signal originates and does not appear in any workspace. See Applying CSCs to Parameters and Signals for details.

PIL Enhancements

Processor-in-the-loop (PIL) Model block simulation mode now supports tunable parameters and serial communication between host and target.

Tunable Parameters

For information see Tunable Parameters and PIL in the Real-Time Workshop Embedded Coder documentation.

The demo rtwdemo_pil has been enhanced to demonstrate the use of tunable parameters during a PIL simulation.

Serial Communication

For information see Communications rtiostream API in the Real-Time Workshop Embedded Coder documentation.

The demo rtwdemo_rtiostream has been enhanced to include configuring for serial communication.

PIL Block Behavior with Goto/From Blocks

Currently, it is possible but not recommended to use Goto/From blocks for I/O data that crosses the boundary of the PIL block component. For virtual (nonatomic) subsystems, the right-click PIL build transforms boundary-crossing Goto blocks into outports and From blocks into inports. The resulting PIL block has extra I/O ports and you must rework the model to connect it.

Starting in the next release this behavior will change and you will see an error if your PIL component includes any Goto/From blocks that cross the boundary of the PIL component.

For more information on PIL support, see PIL Simulation Support and Limitations in the Real-Time Workshop Embedded Coder documentation.

C++ Encapsulation Interface Support for Referenced Models

R2008b introduced the ability to generate a C++ class interface to model code, in which required model data is encapsulated into C++ class attributes and model entry point functions are encapsulated into C++ class methods. However, in a model reference hierarchy, you could generate a C++ encapsulation interface only for the top model. If you built a model containing a Model block whose referenced model had C++ (Encapsulated) selected as the Language setting, the build reported an error.

Beginning in R2009a, you can use C++ encapsulation interfaces throughout a model reference hierarchy. You can now:

The demo model rtwdemo_cppencap has been enhanced to include a model reference hierarchy that illustrates the use of C++ encapsulation interfaces at multiple levels of the hierarchy.

In addition to the limitations that apply to any model build involving C++ encapsulation (C++ Encapsulation Interface Control Limitations), the following limitations apply to building a referenced model that is configured to generate a C++ encapsulation interface:

For more information about using C++ encapsulation, see Controlling Generation of Encapsulated C++ Model Interfaces in the Real-Time Workshop Embedded Coder documentation.

Type Cast Applied to Mismatched const Type Qualifiers When Using Reference Models with Function Prototype Control or C++ Encapsulation Interfaces

When you control C function prototypes or C++ encapsulation interfaces in models that use model referencing, if the const type qualifier for the root input argument of the referenced model's step function interface is set to none, and the const qualifier for the source signal in the referenced model's parent is set to a value other than none, Real-Time Workshop software honors the referenced model's interface specification by generating a type cast that discards the const type qualifier from the source signal. To override this behavior, add an appropriate const type qualifier to the referenced model.

Target Function Libraries Allow Remapping of Operator Outputs to Implementation Function Inputs

Target function libraries (TFLs) now allow remapping of operator outputs to implementation function inputs. This capability can help satisfy an established coding pattern or convention in an application environment, perhaps a code environment to which generated code is being relocated.

For example, for a sum operation, the build process might generate code similar to the following:

rtY.Out1 = u8_add_u8_u8(rtU.In1, rtU.In2);

R2009a allows you to remap the output to any position in the implementation function argument list. For example, remapping the output to the first input generates code similar to the following:

uint8_T rtb_Add8;

u8_add_u8_u8(&rtb_Add8, rtU.In1, rtU.In2);
rtY.Out1 = rtb_Add8;

For more information, see Remapping Operator Outputs to Implementation Function Input Positions in the Real-Time Workshop Embedded Coder documentation.

Target Function Library Parameter AcceptExprInput Controls Code Representation of Expression Inputs in Replacement Results

The target function library (TFL) functions setTflCFunctionEntryParameters and setTflCOperationEntryParameters have added an AcceptExprInput parameter for controlling the code representation of expression inputs in function or operator replacements. The AcceptExprInput parameter allows you to control whether an expression input to your TFL implementation function is integrated directly into the generated function call or assigned to a temporary variable. If the value of AcceptExprInput is true, expression inputs are integrated into the generated code in a form similar to the following:

rtY.Out1 = u8_add_u8_u8(u8_add_u8_u8(rtU.In1, rtU.In2), rtU.In3);

Beginning in R2009a, you can override that behavior by setting AcceptExprInput to false, which generates a temporary variable for the expression input, as follows:

uint8_T tempVar;

tempVar = u8_add_u8_u8(rtU.In1, rtU.In2);
rtY.Out1 = u8_add_u8_u8(tempVar, rtU.In3);

AUTOSAR Enhancements

Support is provided for AUTOSAR schema version 3.0, which is now the default.

For information, see Generating Code That Complies with AUTOSAR Standards in the Real-Time Workshop Embedded Coder User's Guide documentation.

Enhanced emlc Support for Embedded Real-Time (ERT) Targets

emlc now supports:

For more information, see Real-Time Workshop Dialog Box for Embedded MATLAB Coder in the Real-Time Workshop reference.

Optimized ERT-Based Targets Deprecated

Starting in R2009a, two optimized ERT-based targets are no longer available:

Compatibility Considerations

If you selected either of these targets for your model in previous releases, the target remains available for that model. For new models, use the code generation objectives parameters to configure your model for fixed-point or floating-point code. For more information, see Ability to Specify Code Generation Objectives.

Right-Click Builds No Longer Generate Unused Functions in Production Code

Prior to R2009a, if all of the following conditions existed, Real-Time Workshop Embedded Coder generated unused functions in production code:

In a production code environment, the enable and disable methods in your generated model.c file are dead code. The methods are called by the ERT S-function wrapper only if the generated S-function resides in a conditionally executed subsystem that has an enable or disable method.

Starting with R2009a, the code generator no longer generates the enable and disable methods in model.c, eliminating the dead code.

Compatibility Considerations

If you place an S-function generated under the preceding conditions in a conditionally executed subsystem that requires the enable or disable method, the S-function block reports a runtime error message similar to the following:

The model is attempting to invoke the enable method of the 
S-function block block-name for model-name, yet the code 
generated for the model does not include an enable method.

Pass Reusable Subsystem Outputs as Individual Arguments in Generated Code Using New Configuration Parameter

R2009a introduces a new configuration parameter to pass reusable subsystem outputs as individual arguments to reduce global RAM usage and data copy operations. See Pass reusable subsystem outputs as in the Simulink documentation for more information.

Simplify Array Indexing in Generated Code Using New Configuration Parameter

R2009a introduces a new configuration parameter to remove costly multiply operations when accessing arrays in a loop in the generated code. See Simplify array indexing in the Simulink documentation for more information.

Generated Code Enhancements

In R2009a, code generation is enhanced to:

Code Generation Report Improvement

In R2009a, you can more easily read and use the code generation report:

For more information, see Generating Reports for Code Reviews and Traceability Analysis.

New and Enhanced Demos

Beginning with R2009a, the Real-Time Workshop Demos in the Help contents uses a new format to display Real-Time Workshop and Real-Time Workshop Embedded Coder demos. The differences include:

The following demo has been added in R2009a:

Demo...Shows How You Can...
rtwdemo_usingrtwecGenerate C code for embedded systems requiring production code efficiency and quality. You select a Real-Time Workshop Embedded Coder target for a model, quickly configure options based on your code generation objectives, generate code, and view the resulting files.

The following demos have been enhanced in R2009a:

Demo...Now...
rtwdemo_cppencapExtends C++ encapsulation to a model reference hierarchy.
rtwdemo_cscpredefIllustrates the use of embedded signal objects.
rtwdemo_pilShows how to use tunable parameters during a processor-in-the-loop simulation.
rtwdemo_rtiostreamIncludes configuring for serial communication.

  


Related Products & Applications

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

 © 1984-2009- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS