| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → Real-Time Workshop Embedded Coder |
| Contents | Index |
| Learn more about Real-Time Workshop Embedded Coder |
This table summarizes what's new in Version 5.3 (R2009a):
| 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 | Bug
Reports Includes fixes | No |
New features and changes introduced in this version are
Ability to Specify Custom Storage Classes as Signal Properties
Target Function Libraries Allow Remapping of Operator Outputs to Implementation Function Inputs
Right-Click Builds No Longer Generate Unused Functions in Production Code
Simplify Array Indexing in Generated Code Using New Configuration Parameter
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:
Efficiency (ERT-based targets)
Safety precaution (ERT-based targets)
Traceability (ERT-based targets)
Debugging (GRT- or ERT-based targets)
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.
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.
Processor-in-the-loop (PIL) Model block simulation mode now supports tunable parameters and serial communication between host and target.
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.
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.
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.
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:
Select C++ (Encapsulated) as the Language setting for referenced models in a model reference hierarchy, and configure custom C++ encapsulation interfaces for those models.
Mix C++ encapsulation and C code interface styles within a model reference hierarchy. (The demo model rtwdemo_cppencap includes a referenced model that uses the C code interface style, compiled with a C++ compiler, while the other models in the same hierarchy use C++ encapsulation interfaces.)
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:
The void-void step method style of C++ encapsulation interface is not supported for referenced models. You must use the I/O arguments step method style.
In cases for which a referenced model cannot have a combined output/update function, you cannot use a C++ encapsulation interface. Those cases include:
The model has multiple sample times.
The model has a continuous sample time.
The model is saving states.
For more information about using C++ encapsulation, see Controlling Generation of Encapsulated C++ Model Interfaces in the Real-Time Workshop Embedded Coder documentation.
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 (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.
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);
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.
emlc now supports:
Integer-only code generation
Option to turn off nonfinite support
You can now turn off nonfinite support if you do not need it. Turning off nonfinite support results in leaner generated code.
Custom naming of identifiers
You can now specify the identifier format for:
Global variables
Global types
Local functions
Local temporary variables
Constant macros
For more information, see Real-Time Workshop Dialog Box for Embedded MATLAB Coder in the Real-Time Workshop reference.
Starting in R2009a, two optimized ERT-based targets are no longer available:
ert.tlc — Real-Time Workshop Embedded Coder (auto configures for optimized fixed-point code)
ert.tlc — Real-Time Workshop Embedded Coder (auto configures for optimized floating-point code)
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.
Prior to R2009a, if all of the following conditions existed, Real-Time Workshop Embedded Coder generated unused functions in production code:
The subsystem includes a block that has an enable or disable method, or the subsystem itself has an enable or disable method. An example is an Enabled Subsystem block with the Enable block States when enabling parameter set to reset.
You right-clicked the subsystem block and did one of the following:
Selected the Tools > Real-Time Workshop > Build Subsystem submenu option, and the root model is configured for an ERT target.
Selected the Tools > Real-Time Workshop > Generate S-function submenu option and the Use Embedded Coder option on the Generate S-function for Subsystem dialog box.
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.
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.
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.
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.
In R2009a, code generation is enhanced to:
Suppress overflow protection code if the build process determines that the range for block operations is sufficiently restricted. This enhancement improves memory usage and execution speed.
Identify inputs and outputs of function-call subsystems as well as Simulink functions in Stateflow charts that do not need to use global memory. This capability reduces global memory usage and increases execution speed. Merge blocks with initialization value have been updated in R2009a to use this enhancement.
Reduce global data copies in the generated code when the output port of a reusable subsystem connects to a Vector Concatenate block.
Eliminate unnecessary data copies in the generated code for a SinCos block with outputs to global storage. This capability improves execution speed and reduces RAM usage.
Identify similar loops and combine them into a single loop iteration, thereby improving the execution speed of the generated code and reducing RAM usage.
Eliminate unnecessary data copies at the output ports for the Selector and Assignment blocks. This capability generates less code and reduces RAM usage.
The code efficiency improvement is not applied if:
The Selector block connects to more than one block.
The input signal of the Assignment block connects to at least one other block.
In R2009a, you can more easily read and use the code generation report:
In the Generated Source files list in the left pane, the source file name is highlighted to indicate the file displayed in the right pane.
The destination of the hyperlink in the right pane when navigating hyperlinks to functions, variables, and data types in the generated source files is highlighted.
For more information, see Generating Reports for Code Reviews and Traceability Analysis.
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:
Indentation now is used to designate a functionally-related group of demos. Indentation no longer identifies demos for which the Real-Time Workshop Embedded Coder software is required.
If a demo requires Real-Time Workshop Embedded Coder software, the demo naming or text identifies the requirement.
The following demo has been added in R2009a:
| Demo... | Shows How You Can... |
|---|---|
| rtwdemo_usingrtwec | Generate 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_cppencap | Extends C++ encapsulation to a model reference hierarchy. |
| rtwdemo_cscpredef | Illustrates the use of embedded signal objects. |
| rtwdemo_pil | Shows how to use tunable parameters during a processor-in-the-loop simulation. |
| rtwdemo_rtiostream | Includes configuring for serial communication. |
![]() | Version 5.4 (R2009b) Real-Time Workshop Embedded Coder Software | Version 5.2 (R2008b) Real-Time Workshop Embedded Coder Software | ![]() |

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 |