| Version 6.0 (R14) Real-Time Workshop® Software Release Notes | |
This table summarizes what's new in V6.0 (R14):
| 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:
Support for New Simulink® Model Referencing (Model Block) Feature
Underscores No Longer Replace Spaces in Identifiers for Multi-Word Block Names
Global Data Structure Identifiers for Targets Now Incorporate Model Name
Custom Storage Classes Can No Longer Be Used with GRT Targets
In V6.0 (R14), the Real-Time Workshop® product supports Tornado Version 2.x, which targets VxWorks 5.x.
This release of the Simulink® product features a new user interface for simulation and code generation, called Model Explorer, which replaces the Simulation Parameters dialog. When you select Model Explorer from the Tools menu, the Model Explorer opens in a new window containing three panes:
The Model Explorer features three resizable, scrolling panes:
Model Hierarchy pane
Contents pane
Dialog pane
For more information on the Model Explorer, see The Model Explorer in the Simulink documentation.
You can also control configurations with the standalone Configuration Parameters dialog. To activate this interface, a model must be open. You can summon this interface in any of three equivalent ways:
Choose Configuration Parameters from the Simulation menu.
Choose Real-Time Workshop -> Options from the Tools menu.
Type Ctrl+E.
The Configuration Parameters dialog with the Optimization pane selected is shown in the next figure.
For details on configuration parameters for code generation, see Choosing and Configuring Your Target,Adjusting Simulation Configuration Parameters for Code Generation, and Configuring Real-Time Workshop® Code Generation Parameters in the Real-Time Workshop documentation.
You can now browse files generated by the Real-Time Workshop, Real-Time Workshop® Embedded Coder™, and other products directly in the Model Explorer. This capability supplements HTML code generation reporting, which was available in earlier releases.
When you generate code, or open a model that has generated code for its current target configuration in your working directory, the Model Hierarchy pane of Model Explorer contains a node named Code for model. Under that node are other nodes, typically called Top Model and Shared Code.
When you click Top Model, the Contents of pane lists source code files in the build directory of each model that is currently open. The next figure shows code for the vdp model.
In this example, the file ./vdp_grt_rtw/vdp.c is being viewed. To view any file in the Contents of pane, click it once.
The views in the dialog pane are read-only. The code listings in that pane contain hyperlinks to functions and macros in the generated code. A hyperlink for the file being viewed sits above it. Clicking it opens that file in a text editing window where you can modify its contents. This is not something you typically do with generated source code, but in the event you have placed custom code files in the build directory, you can edit them as well in this fashion.
If an open model contains Model blocks, and if generated code for any of these models exists in the current slprj directory, nodes for the referenced models appear in the Model Hierarchy pane one level below the node for the top model. Such referenced models do not need to be open for you to browse and read their generated source files.
The node directly underneath the Top Model node is named Shared Code. It collects files in the appropriate ./slprj/target/_sharedutils subdirectory, containing shared fixed-point utility code, if any exists.
The structure and contents of slprj directories are described in Project Directory Structure for Model Reference Targets in the Real-Time Workshop documentation.
The Model Advisor (formerly called Model Assistant) is a tool that helps you configure any model to optimally achieve code generation objectives. Using it, you can quickly configure a model for code generation, and identify aspects of your model that impede production deployment or limit code efficiency. Clicking the icon labeled Advice on model in the Model Hierarchy pane launches the Model Advisor. This node is directly below the Code for model node, as the preceding figure shows. Clicking the Advice node causes the dialog pane to be labeled Model Advisor, and to contain a link, Start model advisor. When you click that link, Model Advisor opens a separate HTML window with a set of button and check box controls.
Another way to invoke Model Advisor is to type the following command in the MATLAB® Command Window, specifying the name of model.
ModelAdvisor('model')If the model (assumed to be on the MATLAB path) is not currently open, the Model Advisor opens it.
The following figure shows a Model Advisor report:
See Using the Model Advisor in the Real-Time Workshop documentation for more information.
The Real-Time Workshop software now includes support for the Intel® compiler (Version 7.1 for Microsoft® Windows®). The Intel compiler requires Microsoft Visual C and Microsoft® Visual C++® Version 6.0 or higher to be installed.
The new Model block in the Simulink library allows one model to include another model as if it were a block. This feature, called model reference, works by generating code for included models that the parent model executes from a binary library file. In this release, Model reference works on all UNIX® and Linux® platforms (using the gcc compiler), and on Microsoft Windows PC platforms (using the lcc and Visual C++ compilers).
We call models that include Model blocks top models. Model referencing uses incremental loading. When you open a top model, any models to which it refers are not loaded into memory until they are needed or you open them.
Note To take advantage of incremental model loading, models called from Model blocks must be saved at least once with Simulink V6.0 (R14). Top and referenced models must have Inline parameters set on. |
When running simulations, models are included in other models by generating code for them in a project directory and creating a static library file called a simulation target (sometimes referred to as a SIM target). When the Real-Time Workshop build process generates code for referenced models, it follows a parallel process to create whatever target (for example, GRT) you have specified (sometimes generically referred to as Real-Time Workshop targets). The Real-Time Workshop build process also stores the generated code in the project directory, although generated code for parent models is stored (as in previous releases) in a build directory at the same level as the model reference project directory.
In addition to incremental loading, the model referencing mechanism employs incremental code generation. This is accomplished by comparing the date, and optionally, the structure of model files of referenced models with those for their generated code to determine whether it is necessary to regenerate model reference targets. You can also force or prevent code generation via the diagnostic setting for Rebuild options on the Model Referencing pane of the Configuration Parameters dialog.
You can learn more about how Model blocks work and generate code by running the following demos:
mdlref_basic — General demonstration of using Model blocks
mdlref_paramargs — Passing parameters to referenced models
mdlref_bus — Using bus objects to communicate signals to referenced models
mdlref_conversion — Automatically converting atomic subsystems in models to models called with Model blocks.
For more information on generating code for referenced models, including using mdlref_conversion, see Generating Code for Model Referencing and Generating Code for a Referenced Model in the Real-Time Workshop documentation.
If you want to adapt a custom target for code generation compatibility with the model reference features, you need to modify the target's system target file (STF) and template makefile (TMF).
A model reference compatible target must be derived from the ERT or GRT targets.
When generating code from a model that references another model, both the top-level model and the referenced models must be configured for the same code generation target.
Note that the External mode option is not supported in model reference Real-Time Workshop target builds. If the user has selected this option, it is ignored during code generation.
To support model reference builds, your TMF must support use of the shared utilities directory, as described in Shared Utilities Directory and the Build Process.
System Target File Modifications. Your STF must implement a SelectCallback function (see New SelectCallback Function for System Target Files). Your SelectCallback function must declare model reference compatibility by setting the ModelReferenceCompliant flag.
The callback is executed if the function is installed in the SelectCallback field of the rtwgensettings structure in your STF. The following code installs the SelectCallback function:
rtwgensettings.SelectCallback = ['custom_open_callback_handler(hDlg, hSrc)'];
Your callback should set the ModelReferenceCompliant flag as follows.
slConfigUISetVal(hDlg, hSrc, 'ModelReferenceCompliant', 'on'); slConfigUISetEnabled(hDlg, hSrc, 'ModelReferenceCompliant', false);
Template Makefile Modifications. In addition to the TMF modifications described in Shared Utilities Directory and the Build Process, you must modify your TMF variables and rules. See Provide Model Referencing Support in the Real-Time Workshop Embedded Coder documentation for instructions.
New C-API for Accessing Model Block Outputs and Parameter Data
Back-Propagating Auto, Test-pointed Signal Labels Through Subsystem Output Ports
Declaring Wide Signals, States, and Parameters as ImportedExternPointer
New Options for Controlling Resolution of Signal Objects for Named Signals and States
CustomStorageClass and StorageClass Properties Initialized Differently
C-API is a target-based Real-Time Workshop feature that provides access to global block outputs and global parameters in the generated code. Using the C-API, you can build target applications that log signals, monitor signals and tune parameters while the generated code executes.
In previous releases, to access model parameters via the C-API, a model-specific parameter mapping file, model_pt.c was generated. Similarly, to access the BlockSignals, model_bio.c is generated. The new C-API improves the efficiency and capability of the interface while reducing its code size. In addition, the new API supports:
Referenced models
Fixed-point data
Complex data
Reusable code
The new interface eliminates redundant fields and also improves consistency between signal and parameter structures. For example, previously the data name was char_T* for signals but was uint_T for parameters.
The C-API provides a smaller memory footprint. This is achieved by mapping information common to signals and parameters in smaller structures. An index into the structure map is provided in the actual signal or parameter structure. This allows the sharing of data across signals and parameters.
When you select the C-API feature and generate code, the Real-Time Workshop build process generates two additional files, model_capi.c and model_capi.h, where model is the name of the model. The Real-Time Workshop build process places the two C-API files in the build directory, based on settings in the Configuration Parameters dialog box. The model_capi.c file contains information about global block signals and global parameters defined in the generated code. The model_capi.h file is an interface header file between the model source code and the generated C-API. You can use the information in these C-API files to create your application. The next figure illustrates generated files.
For details on how to use the C-API, see Data Exchange APIs in the Real-Time Workshop documentation.
Compatibility Considerations. The old C-API is still available, but at some point will be eliminated. The following table compares the files in the two versions:
C-API Files | New C-API Files | Old C-API Files |
|---|---|---|
Data structure interface | Unified interface for signals and parameters: /rtw/c/src/rtw_capi.h | Signals Interface: /rtw/c/src/bio_sig.h Parameters Interface: /rtw/c/src/pt_info.h |
RTModel C API Interface | /rtw/c/src/rtw_modelmap.h | /rtw/c/src/mdl_info.h |
TLC files | /rtw/c/tlc/mw/capi.tlc | /rtw/c/tlc/mw/biosig.tlc /rtw/c/tlc/mw/ptinfo.tlc |
The file rtw_modelmap.h defines structures for mapping data from the rtModel structure. The file rtw_capi.h provides macros for accessing the rtModel.
Note Because the data structures used for the different APIs can conflict, you can generate either C-API or external mode interface code, but not both at once. The same holds true for ASAP2 interface code, a third data exchange option available for ERT and GRT targets. |
If a signal exiting an output port of a subsystem has a storage class other than auto, The Real-Time Workshop software internally propagates the label on that signal backwards into the subsystem so that the code generated for the subsystem uses that signal label, which is defined outside the subsystem.
Compatibility Considerations. Before this release, signal labels were not back-propagated when the signal's storage class was auto and it also was test-pointed. Signal labels are now also back-propagated the if the signal is test-pointed.
If your model declares the storage class of a signal, state, or parameter as ImportedExternPointer, your code must define an appropriate pointer variable.
Compatibility Considerations. In V6.0 (R14), whenever a signal state or parameter is wide, you must define the variable as a pointer to an array. In previous versions, an array of pointers was assumed. Here are the changes:
Width | Previous Versions | V6.0 (R14) |
|---|---|---|
scalar | double *x1 | double *x1 |
wide | double *x2[] | double *x2 |
The legacy code could define and initialize data as follows:
double x1_data; double *x1 = &x1_data; double x2_data[10]; double *x2 = x2_data;
This change enables wide data declared as ImportedExternPointer to occupy contiguous memory locations, making this storage class useful in more contexts than previously possible.
In past releases, you could not assign a storage class to the output of a Bus Creator block. If you select the block's new parameter Output as structure, the output of the block can be assigned a storage class. This enables bus signals to occupy contiguous memory. When you select this parameter, you must specify a Simulink Bus object. You can make and modify bus objects (class Simulink.Bus) using the Bus Editor. Type buseditor in the MATLAB Command Window. An example Bus Creator dialog for a block that outputs a three-element structure is shown in the next figure.
For details on working with bus and other Simulink data objects, see the Working with Data in the Simulink documentation.
In prior releases, The Real-Time Workshop build process attempted to resolve all signal objects in a model. Checking all named signals and states was inefficient, complicated error checking, and now has the potential to cause problems for incremental code generation for referenced models. To address these concerns, the current release provides following enhancements:
Ports and blocks with discrete state now have a setting to indicate whether or not the port/block requires that a signal label be resolved.
Models have a parameter to control signal resolution. This option is located on the Diagnostics/Data Integrity pane of the Configuration Parameters dialog box.
A utility function, disableautosignalresolution, is available for converting existing models (that depended on implicit signal label resolution) to the new, more efficient approach.
In V6.0 (R14), the Real-Time Workshop product merges functionality of custom storage classes into the standard Simulink.Parameter and Simulink.Signal classes.
Compatibility Consideration. When you instantiate the Simulink.CustomParameter and Simulink.CustomSignal classes, the CustomStorageClass and StorageClass properties do not get initialized the same way they did in V5.0 (R13).
In V5.0 (R13), the properties were initialized as:
CustomStorageClass = 'BitField' (1st item on the list) StorageClass = 'Custom'
Starting in V6.0 (R14), the properties are initialized as:
CustomStorageClass = 'Default' (1st item on the list) StorageClass = 'Auto' (custom storage class is ignored)
External Mode Changes May Impact Customized Makefiles and Static Main files
Serial Transport Mechanism for External Mode on Microsoft® Windows®
Upgrading Custom Transport Layers for External Mode to Single-Channel Architecture
New Static Memory Allocation Option for External Mode Code Generation
The grt, ert, grt_malloc, rsim, rtwin, and tornado targets support external mode. For each of these targets, the template makefiles and the system target files have been changed. In addition, the main() files for each target have also been modified (although ert may have a dynamic main, which is not affected).
Compatibility Considerations. If you have customized any of these static files or their makefiles, merge your version with those in the current release if you intend to support external mode.
The file matlabroot/rtw/ext_mode/common/ext_main.c has also changed slightly. In function ExtCommMain, the line
ES = (ExternalSim *)plhs
was changed to
ES = (ExternalSim *)plhs[0]
For xPC, the same change was made in function mexFunction in the file matlabroot/toolbox/rtw/targets/xpc/internal/xpc/src/ext_main.c.
If you created your own custom ext_main.c file, you need to merge this change to be compatible with the corresponding change to Simulink.
It is now possible to use Floating Scope blocks in external mode. A new section in the External Mode pane, Floating scope, contains the following new options:
Enable data uploading
Functions as an "arm trigger" button for floating scopes. When the target is disconnected, it controls whether or not to "arm when connect" the floating scopes. When already connected, it acts as a toggle button to arm/cancel trigger.
Duration
Specifies the duration for floating scopes. By default it is set to auto, which picks up the value specified in the signal and triggering GUI (which by default is 1000).
The behavior of wired Scope blocks is unchanged.
The Real-Time Workshop product now provides code to implement both the client and server side using serial as well as TCP/IP protocols. You can use the socket-based external mode implementation provided by the Real-Time Workshop software with the generated code, provided that your target system supports TCP/IP. Otherwise, use or customize the serial transport layer option provided.
This design makes it possible for different targets to use different transport layers. The GRT, GRT malloc, ERT, RSim, and xPC targets support host/target communication via TCP/IP and RS232 (serial) and TCP/IP communication. Serial transport is implemented only for Windows 32-bit architectures.
For details on how to use the serial transport mechanism for external mode, see Using the Serial Implementation.
In earlier releases, external mode had separate logical channels for messages and data. In the TCP/IP example source files, these channels were implemented as separate sockets. Now there is only one logical channel (socket), which handles both data and messages (both of which are now called packets).
Compatibility Considerations. Most users will not notice this change. If, however, you have created your own custom transport layer for external mode, you must modify it for the single-channel architecture. Here is a summary of the changes that you may need to make:
On the target side (see example files in matlabroot/rtw/c/src/):
Rename the function ExtWaitForStartMsgFromHost() to ExtWaitForStartPktFromHost().
Replace the functions ExtSetHostData() and ExtSetHostMsg() with ExtSetHostPkt().
Rename the function ExtGetHostMsg() to ExtGetHostPkt().
On the host side (see example files in matlabroot/rtw/ext_mode):
Replace the functions ExtTargetDataPending() and ExtTargetMsgPending() with ExtTargetPktPending().
Replace the functions ExtGetTargetData() and ExtGetTargetMsg() with ExtGetTargetPkt().
Rename the function ExtSetTargetMsg() to ExtSetTargetPkt().
For complete instructions, see Creating an External Mode Communication Channel in the Real-Time Workshop documentation.
You can now generate code for external mode such that it uses only static memory allocation ("malloc-free" code). The Static memory allocation check box on the GRT and ERT target configuration component, enables this feature and activates an edit field in which you can specify the size of the static memory buffer used by external mode. The default value is 1,000,000 bytes.
Should you enter too small a value for your application, external mode issues an out-of-memory error when it tries to allocate more memory than you are allowed. In such cases, increase the value of Static memory buffer size and regenerate the code. Determine how much memory you need to make available, enable verbose mode on the target (by including OPTS="-DVERBOSE" on the make command line). As it executes, external mode displays the amount of memory it tries to allocate and the amount of memory available to it each time it attempts an allocation. Should an allocation fail, you can use this console log to adjust the value specified for Static memory buffer size.
For more information on this new option, see External Mode Interface Options in the Real-Time Workshop documentation.
Preventing User Source Code from Being Deleted from Build Directories
Hook Files Describing Hardware Characteristics No Longer Supported
In prior releases, the Real-Time Workshop build process sometimes failed to find S-function source files during a build, even if they were on the MATLAB path, thus aborting the build with an error. This happened because there were no rules dynamically added to the generated makefile for handling the directories in which the S-function MEX-files were located.
Now, the Real-Time Workshop build process adds an include path to the generated makefiles whenever it finds a file named s-function-name.h in the same directory as the S-function MEX-file. This directory must be on the MATLAB path.
Similarly, the Real-Time Workshop build process adds a rule for the directory when it finds a file s-function-name.c (or .cpp) in the same directory as the S-function MEX-file.
This enhancement eliminates the need to copy the S-function source file into the MATLAB current directory or to create an rtwmakecfg.m file in the S-function's directory.
The Custom Code Block library has been reinstated into the Real-Time Workshop library. The library has been simplified. You can use the blocks in subsystems as in top-level models (with minor exceptions). Custom Code blocks enable you to add your own code fragments to specific functions in the Real-Time Workshop generated source code and header files. You can include the user code in Real-Time Workshop target code generated for referenced models (via Model blocks).
Note that custom code that you include in a configuration set is ignored when building Accelerator, S-function, and model reference simulation targets.
It is now possible to incorporate user C++ files into both Real-Time Workshop and Stateflow® builds. The Real-Time Workshop build process itself does not generate C++ code; it simply enables them to be called and incorporated into an executable. For examples of how to use this capability, see the following demos:
sf_cpp.mdl — accessible through Stateflow Demos in the Help Browser.
sfcndemo_cppcount.mdl — (in the sfundemos demo suite, accessible from Help Browser under Simulink > Features > S-Function example.)
In V5.0 (R13), the behavior of the Real-Time Workshop product regarding handling of user source files in the build directory changed. Previously, any .c or .h files that you placed in the build directory were not deleted when you rebuilt targets. Now all foreign source files are deleted by default, but you can preserve them by following the guidelines given below.
If you put a .c or .h source file in a build directory, and you want to prevent the Real-Time Workshop build process from deleting it during the TLC code generation process, insert the string target specific file in the first line of the .c or .h file. For example,
/* COMPANY-NAME target specific file * * This file is created for use with the * COMPANY-NAME target. * It is used for ... */ ...
Make sure target specific file is spelled correctly, and occupies the first line of the source file.
Compatibility Considerations. In addition, flagging user files in this manner prevents post-processing them to indent them along with generated source files. Auto-indenting occurred in previous releases to build directory files with names having the pattern model_*.c (where * could be any string). The indenting is harmless, but can cause differences to be detected by source control software that might trigger unnecessary updates.
Target configurations can expressly specify which floating-point math library to use when generating code. The Real-Time Workshop build process uses a switchyard called the Target Function Library (TFL) to designate compiler-specific versions of math functions. The mappings created in the TFL allow C runtime library support that is specific to a compiler.
The Real-Time Workshop build process provides three different TFLs:
ansi_tfl_tmw.mat — The ANSI-C library (default)
iso_tfl_tmw.mat — Extensions for ISO-C/C99
gnu_tfl_tmw.mat — Extensions for GNU
You choose among them by setting the Target floating point math environment option on the Real-Time Workshop/Interface pane of the Configuration Parameters dialog box. This enables you to specify different runtime libraries for different configuration sets within a given model.
Selecting ANSI-C provides the ANSI-C set of library functions. For example, selecting ANSI-C would result in generated code that calls sin() whether the input argument is double precision or single precision. However, if you select ISO-C, the generated code calls the function sinf(), which is single-precision. If your compiler supports the ISO-C math extensions, selecting the ISO-C library can result in more efficient code.
The Real-Time Workshop product now provides a menu that includes more than 20 target processors for the purpose of identifying hardware characteristics, such as word lengths. In the previous release, this information was stored in user-supplied hook files, which are no longer supported.
Compatibility Considerations. When you open a preexisting model that has not been saved using the current version of Simulink, and select the Hardware Implementation pane of the Configuration Parameters dialog box, the following set of controls appears:
All but one of the parameters below the Device type menu are grayed out. This is because these characteristics have been preset for the default target (32-bit Generic), as well as for several dozen known target processors that you can select from that menu.
The Real-Time Workshop build process only reads existing hook files when a model created by the V5.0 (R13) Real-Time Workshop software is built for the first time in V6.0 (R14) without your having first specified characteristics of the Current code generation execution hardware device on the Hardware Implementation pane. If you build a model in this underspecified state, the Real-Time Workshop software scans the current directory, then the MATLAB path, for an existing hook file with the name target_rtw_info_hook.m. If the file is found, its instructions override the defaults in that section. You can subsequently specify any characteristic freely. If at any point prior to building the target code you specify Current code generation execution hardware device, the Real-Time Workshop build process ignores hook files , as hardware characteristics are now configured.
When you open a preexisting (before V6.0) model, the Hardware Implementationpane displays a Configure current execution hardware device button. This button disappears after you press it once. When code is generated (Ctrl+B) for the target the model specifies,
If the target has a hook file, and the Configure current execution hardware device button has not yet been pressed,
The hook file is executed and configures the fields specifying current code generation execution hardware device.
A warning is issued to the user that the hook file was used.
The Configure current execution hardware device button on the Hardware configuration dialog box is permanently removed for that model (assuming that you save the model).
If the target has a hook file and the Configure current execution hardware device button has been pressed (removing it),
Code is generated for the target using the hardware characteristics for the current code generation execution hardware device (which can default to those of the final embedded hardware device).
The hook file for the target is ignored, and is from now on.
A warning is issued that a hook file exists but was not used.
If the target has no hook file, no message to that effect is issued, and the current code generation execution hardware device, if left unspecified, defaults to MATLAB host computer for target device information. A message is displayed during code generation to indicate this default.
This second group of Hardware Implementation pane controls governs how hardware characteristics are handled in generated code. They do not appear unless the Real-Time Workshop product is installed. Their appearance varies depending on whether hardware configuration characteristics were previously specified for the model or not. If they were not, you see a button (as illustrated in the first of the two preceding figures) labeled Configure current execution hardware device. This button never again appears for this model once code has been generated and the model has been saved.
When you click the Configure current execution hardware device button, it is replaced by a check box labeled None. This box is selected by default, as shown in the following figure.
If you deselect this box, controls appear for that section that are identical to the controls for the Embedded Hardware section above, as shown in the next figure. In this figure, the TI-C6000 processor is selected.
The Application lifespan (days) field on the Optimization pane of the Configuration Parameters dialog box lets you specify how long an application, which contains blocks that depend on elapsed time, should be able to execute before timer overflow. Specifying it determines the word size used by timers in the generated code, and can lower RAM usage.
Application lifespan, when combined with the step size of each task, determinates data type of integer absolute time for each task, as follows:
If your model does not require absolute time, this option affects neither simulation nor the generated code.
If your model requires absolute time, this option optimizes the word size used for storing integer absolute time in generated code. This ensures that timers will not overflow within the lifespan you specify. If you set Application lifespan (days) to Inf, two uint32 words are used.
If your model contains fixed-point blocks that require absolute time, this option affects both simulation and generated code.
Using 64 bits to store timing data enables models with a step size of 0.001 microsecond (10E-09 seconds) to run for more than 500 years, which would rarely be required. To run a model with a step size of one millisecond (0.001 seconds) for one day would require a 32-bit timer (but it could continue running for 49 days).
Application lifespan was an ERT-only option in prior releases.
The Rapid Simulation (RSim) Real-Time Workshop target now has a timeout execution option, -L n. Use this option to enable the RSim executable to abort if it is taking excessive time. This can happen, for example, in some models when zero crossings are frequent and minor step size is small.
For more information and an example, see Setting a Clock Time Limit for a Rapid Simulation in the Real-Time Workshop documentation.
A new VxWorks block library (vxlib1) allows you to model and generate code for asynchronous event handling, including servicing of hardware generated interrupts, maintenance of timers, asynchronous read and write operations, and spawning of asynchronous tasks under a real-time operating system (RTOS).
Although the blocks in the library target a particular RTOS (VxWorks Tornado), full source code and documentation are provided so that you can develop blocks supporting asynchronous event handling for your target RTOS.
The new VxWorks block library supports a superset of the functions of the older Interrupt Templates library. The new library is easier to use, since special Asynchronous Read and Write blocks are no longer required to handle rate transitions.
For descriptions of the VxWorks library blocks and information on gaining access to the library, seeAsynchronous Support in the Real-Time Workshop documentation.
Compatibility Considerations. The older Interrupt Templates library (vxlib) is obsolete. It is provided only to allow models created prior to the Real-Time Workshop product V6.0 (R14) to continue to operate. If you have models that use vxlib blocks, The MathWorks™ recommends that you change them to use vxlib1 blocks.
The Rate Transition block has been updated to automatically detect whether transitions must be slow-to-fast or fast-to-slow, and act appropriately. Accordingly, the Block Parameters dialog box for the block has been modified to include only the following four options:
Ensure data integrity during transfer
Ensure deterministic data transfer
Outport sample time
Initial condition
For more information, see Sample Rate Transitions in the Real-Time Workshop documentation.
Compatibility Consideration. Simulink automatically updates all Rate Transition blocks in a model with this enhancement when you save the model in V6 (R14).
When you set up a model to use a fixed-step solver for multitasking, Simulink now automatically inserts Rate Transition blocks between periodic tasks that run at different rates and transfer data. This feature does not apply to transitions to or from non-periodic (asynchronous) tasks. You can control whether Simulink inserts Rate Transition blocks automatically with the Automatically handle data transfers between tasks check box on the Solver pane of the Configuration Parameters dialog box.
Simulink configures the blocks that it inserts automatically to ensure both data integrity and deterministic data transfer. As mentioned above, this feature applies to multitasking models only. Rate Transition blocks that Simulink inserts automatically do not appear on the model's block diagram. Nevertheless, they are implemented as semaphores or double buffers, depending on the constraints being observed, and affect simulation and code generation.
For more details, see Automatic Rate Transition in the Real-Time Workshop documentation.
Certain blocks require the value of either absolute time (that is, the time from the start of program execution to the present time) or elapsed time (for example, the time elapsed between two trigger events). The Real-Time Workshop product now provides more efficient time computation services to blocks that request absolute or elapsed time. These timer services are available to all targets that support the real-time model (rtModel) data structure. Improvements in the implementation of absolute and elapsed timers include
Timers are implemented as unsigned integers in generated code.
In multirate models, at most one timer is allocated per rate, on an as-needed basis. If no blocks executing at a given rate require a timer, no timer is allocated to that rate. This minimizes memory allocated for timers and significantly reduces overhead involved in maintaining timers.
Allocation of elapsed time counters for use of blocks within triggered subsystems is minimized, further reducing memory usage and overhead.
S-function and TLC APIs let you access timers for use in your S-functions, in both simulation and code generation.
For more information see Timing Services in the Real-Time Workshop documentation.
New efficiencies in code generation no longer require code generated for single-tasking models to test for sample hits in the base rate task. The code fragment below is an example of such a test in prior versions.
if (rtmIsSampleHit(S,0,tid)) { ...
}Since the base rate task always has a sample hit, such tests are not needed. Elimination of this test improves the runtime performance of the generated code.
An important goal for both the Real-Time Workshop and Real-Time Workshop Embedded Coder products in V6.0 (R14) has been target unification. Target unification includes enhancements to the underlying technology and features of both products, such that:
Both products use a common backend generated code format. This enhancement, termed code format unification, has a number of implications (see Code Format Unification).
The set of features common to both products is expanded. Some features and efficiencies formerly exclusive to the Real-Time Workshop Embedded Coder product and the Embedded Real-Time (ERT) target are now generally available via the Generic Real-Time (GRT) target. Conversely, the Real-Time Workshop Embedded Coder software now supports some features that were previously available only via the GRT target (for example, support of continuous-time blocks and noninlined S-functions).
In general, the GRT and ERT targets have many more common features, but the ERT target offers additional controls for common features.
Conversion from GRT-based targets to ERT-based targets is simplified.
The ERT and GRT targets are fully backward-compatible with existing applications.
The following topics provide a high-level overview and comparison of feature enhancements and compatibility issues that result from target unification in the Real-Time Workshop product V6.0 (R14) and the Real-Time Workshop Embedded Coder product V4.0 (R14).
Before discussing code format unification, it is necessary to review the distinction between a target and a code format.
A target (such as the ERT target) is an environment for generating and building code intended for execution on a certain hardware or operating system platform. A target is defined at the top level by a system target file, which in turn invokes other target-specific files.
A code format (such as Embedded-C or RealTime) is one property of a target. The code format controls decisions made at several points in the code generation process. These include whether and how certain data structures are generated (for example, SimStruct or rtModel), whether or not static or dynamic memory allocation code is generated, and the calling interface used for generated model functions. In general, the Embedded-C code format is more efficient than the RealTime code format. Embedded-C code format provides more compact data structures, a simpler calling interface, and static memory allocation. These characteristics make the Embedded-C code format the preferred choice for production code generation.
In prior releases, only the ERT target and targets derived from the ERT target used the Embedded-C code format. Non-ERT targets used other code formats (for example, RealTime or RealTimeMalloc).
In V6.0 (R14, the GRT target uses the Embedded-C code format for backend code generation. This includes generation of both algorithmic model code and supervisory timing and task scheduling code. The GRT target (and derived targets) generates a RealTime code format wrapper around the Embedded-C code. This wrapper provides a calling interface that is backward-compatible with existing GRT-based custom targets. The wrapper calls are compatible with the main program module of the GRT target (grt_main.c). This use of wrapper calls incurs some calling overhead; the pure Embedded-C calling interface generated by the ERT target is more highly optimized.
The calling interface generated by the ERT target is described in Data Structures, Code Modules, and Program Execution of the Real-Time Workshop Embedded Coder documentation. The calling interface generated by the GRT target is described in Program Architecture of the Real-Time Workshop documentation.
Since the GRT target now uses the Embedded-C code format for backend code generation, many Embedded-C optimizations are available to all Real-Time Workshop product users. In general, the GRT and ERT targets have many more common features, but the ERT target offers additional controls for common features. The availability of features is now determined by licensing, rather than being tied to code format.
Code format unification simplifies the conversion of GRT-based custom targets to ERT-based targets. See Compatibility Considerations for GRT-Based Targets for a description of target conversion issues.
If you have developed a GRT-based custom target, it is simple to make your target ERT-compatible. By doing so, you can take advantage of many efficiencies.
There are several approaches to ERT compatibility:
If your installation does not include a Real-Time Workshop Embedded Coder license, you can convert a GRT-based target as described in Converting Your Target to Use rtModel. This enables your custom target to support all current GRT features, including backend Embedded-C code generation.
You can create an ERT-based target, but continue to use your customized version of grt_main.c module. To do this, you can configure the ERT target to generate a GRT-compatible calling interface, as described in Generating GRT Wrapper Code from the ERT Target. This lets your target support all ERT features without changing your GRT-based runtime interface. This approach requires that your installation include a Real-Time Workshop Embedded Coder license.
If your installation includes a Real-Time Workshop Embedded Coder license, you can reimplement your custom target as a completely ERT-based target, including use of an ERT generated main program. This approach lets your target support all ERT features, without the overhead caused by wrapper calls.
Note If you intend to use custom storage classes (CSCs) with a custom target, you must use an ERT target. See Custom Storage Classes in the Real-Time Workshop Embedded Coder documentation for information on CSCs. |
For details on how GRT targets are made call-compatible with previous versions of the Real-Time Workshop product, see The Real-Time Model Data Structure in the Real-Time Workshop documentation.
Converting Your Target to Use rtModel. The real-time model data structure (rtModel) encapsulates model-specific information in a much more compact form than the SimStruct. Many ERT-related efficiencies depend on generation of rtModel rather than SimStruct, including:
Integer absolute and elapsed timing services
Independent timers for asynchronous tasks
Generation of improved C-API code for signal and parameter monitoring
To take advantage of such efficiencies, you must update your GRT-based target to use the rtModel, unless you already did so for V5.0 (R13). The conversion requires changes to your system target file, template makefile, and main program module.
To use rtModel instead of SimStruct, make the following changes to the system target file and template makefile:
In the system target file, add the following global variable assignment:
%assign GenRTModel = TLC_TRUE
In the template makefile, define the symbol USE_RTMODEL. See one of the GRT template makefiles for an example.
Make the following changes to your main program module (that is, your customized version of grt_main.c):
Include rtmodel.h instead of simstruc.h.
Since the rtModel data structure has a type that includes the model name, define the following macros at the top of main program 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:
extern RT_MODEL *MODEL(void);
Change the definitions of rt_CreateIntegrationData and rt_UpdateContinuousStates to be as shown in the Release 14 version of grt_main.c.
Change all function prototypes to have the argument 'RT_MODEL' instead of the argument 'SimStruct'.
The prototypes for the functions rt_GetNextSampleHit, rt_UpdateDiscreteTaskSampleHits, rt_UpdateContinuousStates, rt_UpdateDiscreteEvents, rt_UpdateDiscreteTaskTime, and rt_InitTimingEngine have changed. Change their names to use the prefix rt_Sim instead of rt_ and then change the arguments you pass into them.
See the V6.0 (R14) version of grt_main.c for the list of arguments passed into each function.
Modify all macros that refer to SimStruct to now refer to rtModel. SimStruct macros begin with the prefix ss, whereas rtModel macros begin with the prefix rtm. For example, change ssGetErrorStatus to rtmGetErrorStatus.
Generating GRT Wrapper Code from the ERT Target. The Real-Time Workshop Embedded Coder software supports the GRT compatible call interface option. When you select this option, the Real-Time Workshop Embedded Coder build process generates model function calls that are compatible with the main program module of the GRT target (grt_main.c). These calls act as wrappers that interface to ERT (Embedded-C format) generated code.
This option provides a quick way to use ERT target features with a GRT-based custom target that has a main program module based on grt_main.c.
See Code Generation Options and Optimizations in the Real-Time Workshop Embedded Coder documentation for detailed information on the GRT compatible call interface option.
The approach you should take to achieve ERT compatibility depends on the features required by your custom target. The following table will help you decide whether or not you require Real-Time Workshop Embedded Coder licensed features.
For detailed information about these features, see the Real-Time Workshop and Real-Time Workshop Embedded Coder documentation.
Feature | Real-Time Workshop License | Real-Time Workshop Embedded Coder License |
|---|---|---|
rtModel data structure | Full rtModel struct generated. | rtModel is optimized for the model. Suppression of error status field, data logging fields, and in the struct is optional. |
Custom storage classes (CSCs) | Code generation ignores CSCs; objects assigned a CSC default to Auto storage class. | Code generation with CSCs supported. |
HTML code generation report | Basic HTML code generation report. | Enhanced report with additional detail and hyperlinks to the model. |
Symbol formatting | Symbols (for signals, parameters etc.) are generated in accordance with hard coded default. | Detailed control over generated symbols. |
User-defined maximum identifier length for generated symbols | Supported | Supported |
Generation of terminate function | Always generated. | Option to suppress terminate function. |
Combined output/update function | Separate output/update functions are generated. | Option to generate combined output/update function. |
Optimized data initialization | Not available. | Options to suppress generation of unnecessary initialization code for zero-valued memory, I/O ports, etc. |
Comments generation | Basic options to include or suppress comment generation. | Options to include Simulink block descriptions, Stateflow object descriptions, and Simulink data object descriptions in comments. |
Module Packaging Features (MPF) | Not supported. | Extensive code customization features. See the Real-Time Workshop Embedded Coder documentation. |
Target-optimized data types header file | Requires full tmwtypes.h header file. | Generates optimized rtwtypes.h header file, including only the necessary definitions required by the target. |
User-defined types | User defined types default to base types in code generation. | User defined data type aliases are supported in code generation. |
Simplified call interface | Non-ERT targets default to GRT interface. | ERT and ERT-based targets generate simplified interface. |
Rate grouping | Not supported | Supported |
Auto-generation of main program module | Not supported; static main program module provided. | Automated and customizable generation of main program module supported. Static main program also available. |
MAT-file logging | No option to suppress MAT-file logging data structures. | Option to suppress MAT-file logging data structures. |
Reusable (multi-instance) code generation with static memory allocation | Not supported. | Option to generate reusable code. |
Software constraint options | Support for floating point, complex, and non-finite numbers always enabled. | Options to enable or disable support for floating point, complex, and non-finite number. |
Application life span | User-specified; determines most efficient word size for integer timers. Defaults to inf. | User-specified; determines most efficient word size for integer timers. |
Software-in-the-loop (SIL) testing | Model reference simulation target can be used for SIL testing. | Additional SIL testing support via auto-generation of Simulink S-Function block. |
ANSI-C code generation | Supported | Supported |
ISO-C code generation | Supported | Supported |
GNU-C code generation | Supported | Supported |
Generate scalar inlined parameters | Not supported | Supported |
MAT-file variable name modifier | Supported | Supported |
Data exchange: C-API, External Mode, ASAP2 | Supported | Supported |
This note discusses changes in the way that symbols are generated for
Signals and parameters that have Auto storage class
Subsystem function names that are not user-defined
All Stateflow names
The following Real-Time Workshop model configuration options, all related to formatting generated symbols, have been removed from the Configuration Parameters dialog box and replaced with a default symbol formatting specification.
Prefix model name to global identifiers
Include System Hierarchy Number in Identifiers
Include data type acronym in identifier
The components of a generated symbol now include the root model name, followed by the name of the generating object (signal, parameter, state, and so on), followed by a unique name mangling string that is generated (if required) to resolve potential conflicts with other generated symbols.
The length of generated symbols is limited by the Maximum identifier length parameter specified on the Real-Time Workshop>Symbols pane of the Configuration Parameters dialog. The default length is 31 characters. When there is a potential name collision between two symbols, the Real-Time Workshop software generates a name mangling string. The string has the minimum number of characters required to avoid the collision. The Real-Time Workshop build process then inserts the other symbol components. If the Maximum identifier length is not large enough to accommodate full expansions of the other components, they are truncated.
Compatibility Considerations. To avoid truncation that can result from the new default symbol formatting specification, it is good practice to
Avoid name collisions in general. One way to do this is to avoid using default block names (for example, Gain1, Gain2...) when there are many blocks of the same type in the model. Also, whenever possible, make subsystems atomic and reusable.
Where possible, increase the Maximum identifier length to accommodate the length of the symbols you expect to generate.
Within a model that uses model referencing, there can be no collisions between the names of the constituent models. When generating code from a model that uses model referencing, the Maximum identifier length must be large enough to accommodate full the root model name and the name mangling string (if any). A code generation error occurs if Maximum identifier length is not large enough.
When a name conflict occurs between a symbol within the scope of a higher-level model and a symbol within the scope of a referenced model, the symbol from the referenced model is preserved. Name mangling is performed on the symbol from the higher-level model.
The Real-Time Workshop Embedded Coder software provides a Symbol format field that lets you control the formatting of generated symbols in much greater detail. See Code Generation Options and Optimizations in the Real-Time Workshop Embedded Coder documentation for more information.
Prior to V6.0 (R14), the Real-Time Workshop product replaced each space in a multi-word block name with an underscore (_). For example, Actuator Model would be Actuator_Model. Starting in V6.0, the spaces in such names are removed rather than replaced. For example, the identifier for Actuator Model is generated as ActuatorModel.
Global data structures, such as rtB, rtP and rtY have new identifiers in ERT and GRT generated code. For GRT, these names now include the model name followed by _B, _P, _Y, and so on. (ERT targets provide you with flexible naming options as explained in Symbol Formatting Options Replaced). The construction of identifiers was changed to prevent name clashes when code for models containing Model blocks is generated and linked.
If you are interfacing external code to any Simulink global data, you might need to use the GRT compatible calling interface for ERT-based targets (see Generating GRT Wrapper Code from the ERT Target for more information). The GRT interface enables you to access global data using the old-style identifiers via a set of macros that map old-style to new-style identifiers. See Backwards Compatibility of Code Formats in the Real-Time Workshop documentation for details.
A new function, getActiveConfigSet, provides safe access to option settings stored in the active configuration set. The function returns an object through which you can access properties of the model's active configuration set. The following example shows how to call getActiveConfigSet to turn the ERT option Single output/update function off.
cs = getActiveConfigSet(model); set_param(cs, 'CombineOutputUpdateFcns', 'off');
Compatibility Considerations. In prior releases, it was possible to access code generation options and other model parameters stored in the rtwOptions data structure directly, by using get_param and set_param calls. In the following code excerpt, for example, the value of the ERT Single output/update function option is changed from on to off.
options = get_param(model, 'RTWOptions'); strrep(options, 'CombineOutputUpdateFcns=1', 'CombineOutputUpdateFcns=0'); set_param(model, 'RTWOptions', options);
If you have written code that accesses the rtwOptions structure directly, as in the above example, you should update your code to use getActiveConfigSet instead. Due to changes in underlying data structures, code that accesses rtwOptions directly, as above, will no longer work correctly.
An alternative and more flexible method for automatic configuration of model options is available to Real-Time Workshop Embedded Coder users. See Auto-Configuring Models for Code Generation in the Real-Time Workshop Embedded Coder documentation for more information.
In V6.0 (R14) Simulink models store model-wide parameters and target-specific data in configuration sets. Every configuration set contains a component that defines the structure of a particular target and the current values of target options. Some of this information is loaded from a system target file when you select a target using the System Target File Browser. You can configure models to generate alternative target code by copying and modifying old or adding new configuration sets and browsing to select a new target. Subsequently, you can interactively select an active configuration from among these sets (only one configuration set can be active at a given time).
The Real-Time Workshop product has added a new function, switchTarget, to support configuration sets and enable you to automate target selection from scripts. Arguments that you pass to the function include a handle to the model's active configuration set and a string that specifies a system target file.
For more information, see Selecting a System Target File Programmatically in the Real-Time Workshop documentation.
When you open a preexisting model that has not been saved using V6.0 (R14) of Simulink, and select Hardware in the Configuration Parameters dialog box, the following set of controls appears:
All but one of the parameters below the Device type menu are grayed out. This is because these characteristics have been preset for the default target (32-bit Generic), as well as for several dozen known target processors that you can select from that menu.
In the event that none of the choices listed in the Device Type drop-down menu is appropriate for your intended hardware target, you can select Custom, and then set values for the hardware characteristics. Selecting any other option disables them. The hardware characteristics that you can specify are
Number of bits — Text fields that specify the number of bits used to represent types char, short, int, and long. The values specified should be consistent with the word sizes as defined in the compiler's limits.h header file.
Byte ordering — Specifies whether the target hardware uses Big Endian (most significant byte first) or Little Endian (least significant byte first) byte ordering. If left as Unspecified, the Real-Time Workshop build process generates code to determine the endianness of the target; this is the least efficient option.
Shift right on a signed integer as arithmetic shift — ANSI® C leaves the behavior of right shifts on negative integers as implementation dependent. Use this control to specify how the Real-Time Workshop software implements right shifts on signed integers in generated code.
The option is selected by default. If your C or C++ compiler handles right shifts as arithmetic shifts, this is the preferred setting.
When the option is selected, the Real-Time Workshop software generates simple efficient code whenever the Simulink model performs arithmetic shifts on signed integers.
When the option is cleared, the Real-Time Workshop software generates fully portable but less efficient code to implement right arithmetic shifts.
For release 14, extensive improvements and revisions have been made in the appearance and layout of code generation options and other target-specific options for Real-Time Workshop targets. If you have developed a custom target, you should take advantage of the Model Explorer to present target options to end users.
Compatibility Considerations. To take advantage of the Model Explorer for presenting target options, you must modify your custom system target file. If you do not want to make the changes, a mechanism for using the old-style Simulation Parameters dialog is available for backwards compatibility.
The following figure shows an example of what users would see if you do not upgrade and the Embedded Target for Motorola® HC12 target is selected.
Instead of one Real-Time Workshop>Target tab, this dialog has four: ERT Code Generation options 1 through 3, External mode options, and Code Warrior options (not all are visible in the figure). Targets that have not been updated to use configuration sets will display similar dialogs. In addition, there is a Launch old simprm dialog button at the bottom of the dialog. Targets that use the Simulation Parameters dialog to handle callbacks will work without updating for Model Explorer only if the user uses this button and then builds from the Simulation Parameters dialog. Note that configuration set dialogs can issue callbacks but handle them differently than did the Simulation Parameters dialog.
See the Real-Time Workshop® Embedded Coder™ Release Notes for details.
The V6.0 (R14) API for system target file callbacks provides a new SelectCallback function for use in system target files. This function is associated with the target rather than with any of its individual options. If you implement a SelectCallback function for the target, it is triggered once, when the user selects the target via the System Target File Browser.
For details on using the selectCallback function, see Supporting Model Referencing in the Real-Time Workshop Embedded Coder documentation.
Compatibility Considerations. If you have developed a custom target and you want it to be compatible with model referencing, you must implement a SelectCallback function to declare model reference compatibility. See Compatibility Considerations for Custom Targets in the Real-Time Workshop documentation for an example.
The shared utilities directory (slprj/target/_sharedutils) typically stores generated utility code that is common between a top-level model and the models it references. You can also force the build process to use a shared utilities directory for a standalone model. See Project Directory Structure for Model Reference Targets in the Real-Time Workshop documentation for details.
If you want your target to support compilation of code generated in the shared utilities directory, several updates to your template makefile (TMF) are required. Note that support for the shared utilities directory is a necessary, but not sufficient, condition for supporting Model Reference builds. See Compatibility Considerations for Custom Targets to learn about additional updates that are needed for supporting model reference builds.
The exact syntax of the changes can vary due to differences in the make utility and compiler/archive tools used by your target. The examples below are based on the GNU make utility. You can find the following updated TMF examples for GNU and Microsoft Visual C make utilities in the GRT and ERT target directories:
GRT: matlabroot/rtw/c/grt/
grt_lcc.tmf
grt_vc.tmf
grt_unix.tmf
ERT: matlabroot/rtw/c/ert/
ert_lcc.tmf
ert_vc.tmf
ert_unix.tmf
Use the GRT or ERT examples as a guide to the location, within the TMF, of the changes and additions described below.
Note The ERT-based TMFs contain extra code to handle generation of ERT S-functions and Model Reference simulation targets. Your target does not need to handle these cases. |
Make the following changes to your TMF to support the shared utilities directory:
Add the following make variables and tokens to be expanded when the makefile is generated:
SHARED_SRC = |>SHARED_SRC<| SHARED_SRC_DIR = |>SHARED_SRC_DIR<| SHARED_BIN_DIR = |>SHARED_BIN_DIR<| SHARED_LIB = |>SHARED_LIB<|
SHARED_SRC specifies the shared utilities directory location and the source files in it. A typical expansion in a makefile is
SHARED_SRC = ../slprj/ert/_sharedutils/*.c
SHARED_LIB specifies the library file built from the shared source files, as in the following expansion.
SHARED_LIB = ../slprj/ert/_sharedutils/rtwshared.lib
SHARED_SRC_DIR and SHARED_BIN_DIR allow specification of separate directories for shared source files and the library compiled from the source files. In the current release, all TMFs actually use the same path, as in the following expansions.
SHARED_SRC_DIR = ../slprj/ert/_sharedutils SHARED_BIN_DIR = ../slprj/ert/_sharedutils
Set the SHARED_INCLUDES variable according to whether shared utilities are in use. Then append it to the overall INCLUDES variable.
SHARED_INCLUDES =
ifneq ($(SHARED_SRC_DIR),)
SHARED_INCLUDES = -I$(SHARED_SRC_DIR)
endif
INCLUDES = -I. $(MATLAB_INCLUDES) $(ADD_INCLUDES) \
$(USER_INCLUDES) $(SHARED_INCLUDES)Update the SHARED_SRC variable to list all shared files explicitly.
SHARED_SRC := $(wildcard $(SHARED_SRC))
Create a SHARED_OBJS variable based on SHARED_SRC.
SHARED_OBJS = $(addsuffix .o, $(basename $(SHARED_SRC)))
Create an OPTS (options) variable for compilation of shared utilities.
SHARED_OUTPUT_OPTS = -o $@
Provide a rule to compile the shared utility source files.
$(SHARED_OBJS) : $(SHARED_BIN_DIR)/%.o : $(SHARED_SRC_DIR)/%.c $(CC) -c $(CFLAGS) $(SHARED_OUTPUT_OPTS) $<
Provide a rule to create a library of the shared utilities. The following example is Unix-based.
$(SHARED_LIB) : $(SHARED_OBJS) @echo "### Creating $@ " ar r $@ $(SHARED_OBJS) @echo "### Created $@ "
Add SHARED_LIB to the rule that creates the final executable.
$(PROGRAM) : $(OBJS) $(LIBS) $(SHARED_LIB) $(LD) $(LDFLAGS) -o $@ $(LINK_OBJS) $(LIBS) $(SHARED_LIB) $(SYSLIBS) @echo "### Created executable: $(MODEL)"
Remove any explicit reference to rt_nonfinite.c from your TMF. For example. change
ADD_SRCS = $(RTWLOG) rt_nonfinite.c
to
ADD_SRCS = $(RTWLOG)
Tornado 2.2.1 installs standard header files in an include directory under the target compiler target directory. For example, if you are targeting the Motorola 68k processor for VxWorks with the GCC 2.96 compiler, Tornado installs the header files at the following location:
WIND_BASE/host/WIND_HOST_TYPE/lib/gcc-lib/m68k-wrs-vxworks /gcc-2.96/include
If you are using a version of Tornado lower than 2.2.1, leave the macro commented out.
To use Tornado 2.2.1 or higher with the Tornado (VxWorks) Real-Time Target, tornado.tlc, you must enable a macro in template makefile tornado.tmf as follows:
Uncomment the macro TORNADO_TARGET_COMPILER_INCLUDES and set it to the include directory that contains the Tornado standard header files.
Given the path shown above, you would set the macro as follows:
TORNADO_TARGET_COMPILER_INCLUDES = $(WIND_BASE)/host/$(WIND_HOST_TYPE)/lib/gcc-lib/m68k-wrs-v xworks/gcc-2.96/include
Although this example shows the macro definition wrapped, you should include it on a single line.
In prior releases, it was possible to use custom storage classes with the GRT target if a Real-Time Workshop Embedded Coder license was available. In V6.0 (R14), you can no longer use custom storage classes when you generate code for GRT-based targets.
For information on how GRT and ERT targets now compare, see Global Data Structure Identifiers for Targets Now Incorporate Model Name. See Code Generation Options and Optimizations in the Real-Time Workshop Embedded Coder documentation for detailed information on the GRT compatible call interface option.
If you have a Real-Time Workshop Embedded Coder license and want to build a model that uses custom storage classes with the GRT target, you should instead use ERT Target, and enable the GRT compatible call interface option. This option appears on theReal-Time Workshop>Interfacepane of the Configuration Parameters dialog box. When you use this option, the Real-Time Workshop Embedded Coder software generates GRT-compatible code that can include custom storage classes.
ISSLPRMREF TLC Built-In Supports Parameter Sharing with Simulink®
New Argument for TLC GENERATE_FORMATTED_VALUE Built-In Function
Accessing the Number of Sample Times from TLC for Custom Targets
TLCFILES Built-In Now Returns Full Path to Model File Rather Than Relative Path
To support parameter sharing with Simulink, a new built-in function (ISSLPRMREF) has been added to the Target Language Compiler. It returns a Boolean value indicating whether its argument is a reference to a Simulink parameter or not. Using this function can save memory and time during code generation. Here is an example:
%if !ISSLPRMREF(param.Value)
%assign param.Value = CAST("Real", param.Value)
%endifThe GENERATE_FORMATTED_VALUE built-in function has a new optional third argument. The syntax for the function is now
GENERATE_FORMATTED_VALUE(expr, string, expand)
The third argument is a Boolean, which when TRUE, causes expr to be expanded into raw text before being output. expand=TRUE uses much more memory than the default (FALSE). Set expand=TRUE only if the parameter text needs to be processed for some reason before being written to disk.
In previous release, you could directly access an undocumented TLC variable, NumSampleTimes, which held the number of periodic (synchronous) sample times. In the current release, the variable that holds the number of periodic sample times is called NumSynchronousSampleTimes. In addition, there are two new variables, NumAsynchronousSampleTimes and NumVariableSampleTimes. The total number of sample times in a model is given by:
NumSampleTimes = NumSynchronousSampleTimes + NumAsynchronousSampleTimes + NumVariableSampleTimes
Compatibility Considerations. Do not use NumSampleTimes. Instead, call TLC library functions, as follows:
LibNumDiscreteSampleTimes() to access NumSynchronousSampleTimes
LibNumAsynchronousSampleTimes() to access NumAsynchronousSampleTimes
A change in TLC invocation now specifies a full path to model files rather than a relative path.
Compatibility Considerations. This change creates backwards incompatibility in some custom targets.
When migrating V5.0 (R13) custom targets to V6.0 (R14) , check for and adjust usage of the TLC function TLCFILES to determine context, such as the path to the model file, as necessary.
Real-Time Workshop® Getting Started Guide has been fully updated and includes a new tutorial on generating code for referenced models.
Real-Time Workshop® User's Guide is updated, and includes most of the information on new features described in this chapter.
Real-Time Workshop® Target Language Compiler has been updated. This document no longer includes an appendix describing all the records that might be encountered in a model.rtw file.
| Version 6.1 (R14SP1) Real-Time Workshop® Software | Version 5.2 (R13SP2) Real-Time Workshop® Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |