| Version 4.2 (R14SP2) Real-Time Workshop® Embedded Coder™ Software Release Notes | |
This table summarizes what's new in Version 4.2 (R14SP2):
| 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
Model Explorer "Alias Override Naming Rule" Check Box Removed
Model Explorer Data Object Header File No Longer Generated If Header File Name Is Not Specified
File custom_user_type_registration.m No Longer Automatically Called During Code Generation
This release introduces support for generating C++ code. The primary use for this feature is to facilitate integration of generated code with legacy or custom user code written in C++. For detailed information about C++ code generation, see Choosing and Configuring a Compiler and Integrating Legacy and Custom Code in the Real-Time Workshop documentation.
The ERT VxWorks example target now includes full support for 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. With this release, you can generate code to support external mode communication between host (Simulink) and ERT VxWorks target systems. For more information, see Using External Mode with the ERT Target in the Real-Time Workshop Embedded Coder documentation.
Custom storage classes (CSCs) now can be used with ERT S-functions. This capability was disabled in Version 4.0, Release 14, and is reenabled in this release.
For more information, see Custom Storage Classes in the Real-Time Workshop Embedded Coder documentation.
Pre-model-compilation consistency checking has been added to detect and warn against conflicting combinations of ERT target configuration options. (Configuration options that are available for the ERT target are described in Mapping Application Requirements to Configuration Options in the Real-Time Workshop Embedded Coder documentation.)
Error messages now are issued for the following conflicts:
GRT compatible call interface (GRTInterface) is on and Support floating-point numbers (!PurelyIntegerCode) is off
MAT-file logging (MatFileLogging) is on and Support floating-point numbers (!PurelyIntegerCode) is off
Support non-finite numbers (SupportNonFinite) is off and MAT-file logging (MatFileLogging) is on
GRT compatible call interface (GRTInterface) is on and Single update/output function (CombineOutputUpdateFcns) is on
MAT-file logging (MatFileLogging) is on and Terminate function required (IncludeMdlTerminateFcn) is off
MAT-file logging (MatFileLogging) is on and Suppress error status in real-time model data structure (SuppressErrorStatus) is on
Warning messages now are issued for the following conflicts:
Support non-finite numbers (SupportNonFinite) is off and Support non-inlined s-functions (SupportNonInlinedSFcns) is on
Support non-finite numbers (SupportNonFinite) is on and Support floating-point numbers (!PurelyIntegerCode) is off
Support non-inlined S-functions (SupportNonInlinedSFcns) is on and Support floating-point numbers (!PurelyIntegerCode) is off
Before this release, the Model Explorer allowed you to select the Alias override naming rule option for an mpt data object. As explained in the Module Packaging Features document, this resulted in the name that you typed in the Alias field overriding the global naming rule for the selected data object. This only applied to mpt data objects, not to Simulink data objects.
This release removes the Alias overrides naming rule check box. Now, the override works the same way for mpt and for Simulink data objects: As explained in the documentation, if the Alias field is empty, the global naming rule (that you select on the Configuration Parameters dialog box) applies to all data objects. But if you do specify a name in the Alias field, this overrides the naming rule for that data object. There is no need for the check box.
Before this release, when you specified a Definition file name on the Model Explorer dialog box for a data object and did not specify a Header file name, the code generator generated a header file in which it declared the data object. The code generator used the same name for the header file (for example, data.h) as you specified for the definition file (for example, data.c).
With this release, when you specify a Definition file name and do not specify a Header file name, the code generator does not generate a header file. The code generator declares the data object according to the global naming rule. In this case, the code generator assumes that you do not want it to generate the header file.
This release restructures the Managing the Data Dictionary chapter in Module Packaging Features. The revised material explains how to create Simulink data objects using the Data Object Wizard, and compares this with creating mpt data objects.
Beginning with Real-Time Workshop Embedded Coder 4.2 (R14SP2), the file custom_user_type_registration.m, which you provide if you want to register user-defined data types, no longer is called automatically during code generation. Instead, after modifying and saving your custom_user_type_registration.m file, you must create the Simulink.AliasType objects corresponding to your user-defined data types before generating code. For a description of the R14SP2 and R14SP3 procedure for using custom_user_type_registration.m to register user-defined data types, see "Creating User Data Types" in the R14SP2 or R14SP3 Real-Time Workshop Embedded Coder Module Packaging Features document.
The following compatibility consideration applies if you are upgrading from V4.1 (R14SP1) to V4.2 (R14SP2), V4.2.1 (R14SP2+), or V4.3 (R14SP3). If you are upgrading to V4.4 (R2006a) from V4.1 or later, see the release notes for Version 4.4 (R2006a) Real-Time Workshop Embedded Coder Software .
If you modified and saved custom_user_type_registration.m in V4.1 (R14SP1), you must now create the Simulink.AliasType objects corresponding to your user-defined data types before generating code for your model. For example, you can:
Invoke the MATLAB function ec_create_type_obj to programmatically create all the required Simulink.AliasType objects
Create Simulink.AliasType objects one at a time by selecting Add > Simulink.AliasType in the Model Explorer
Create Simulink.AliasType objects one at a time by entering the MATLAB command userdatatype = Simulink.AliasType, where userdatatype is a user-defined data type registered in custom_user_type_registration.m
| Version 4.2.1 (R14SP2+) Real-Time Workshop Embedded Coder Software | Version 4.1 (R14SP1) Real-Time Workshop Embedded Coder Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |