Version 4.0 (R14) Real-Time Workshop® Embedded Coder™ Software Release Notes

Version 4.0 (R14) Real-Time Workshop Embedded Coder Software

This table summarizes what's new in Version 4.0 (R14):

New features and changes introduced in this version are

• Expanded Documentation Collection

• New ERT Target Options User Interface

• GRT and ERT Target Unification

• Support for Continuous Time Blocks

• Support for Continuous Solvers

• Support for Noninlined S-Functions

• Module Packaging Features

• ASAP2 File Generation Changes

• Code Generation with User-Defined Data Types

• Enhanced Custom Storage Classes

• More Efficient Multi-Rate Multitasking Code Generation

• More Efficient Task Scheduling for RTOS Targets

• New Callbacks Defined for System Target Files

• New Option to Control Template Makefile Output Display

• Demo Updates

• Upgrading from R13SP1+ or R13SP2

• Generating R13SP1+ or R13SP2 Code From ERT-Based Simulink Models Created In R14 or Later

Expanded Documentation Collection

The Real-Time Workshop Embedded Coder documentation collection has been expanded and includes following documents:

New ERT Target Options User Interface

You can configure ERT target code generation options in the new Simulink Model Explorer and Configuration Parameters dialog box. Before working with the ERT target in this new environment, you should become familiar with

• Configuration sets and how to view and edit them in Model Explorer and the Configuration Parameters dialog box. See Using Simulink for details.

• The general Real-Time Workshop code generation options and use of the System Target File Browser. See the Real-Time Workshop documentation for details.

Some panes of the new Configuration Parameters dialog box (for example, the Templates and Interface panes) contain only ERT-specific options. Others, such as the Real-Time Workshop pane, display a combination of general Real-Time Workshop options and ERT target options.

Note    If you have developed a custom target based on the ERT target (or any other Real-Time Workshop target) see Defining and Displaying Custom Target Options for a discussion of compatibility issues that may affect the appearance and operation of your target.

The following table summarizes new and revised ERT target code generation options.

Note    The Symbol format option supports all functions previously implemented by the Prefix model name to global identifiers, Include system Hierarchy Number in Identifiers, and Include data type acronym in identifier options in a more compact form. The Symbol format option replaces all these options. However, existing models will continue to generate code that respects the settings of the previous options.

Detailed descriptions of options specific to the ERT target are provided in:

• The Code Generation Options and Optimizations chapter of the Real-Time Workshop Embedded Coder documentation.

• The Module Packaging Features document.

GRT and ERT Target Unification

Release 14 introduced Generic Real-Time (GRT) and Embedded Real-Time (ERT) target unification enhancements. The enhancements include the following changes to the underlying technology for Real-Time Workshop and Real-Time Workshop Embedded Coder.

• Both products use a common format for backend generated code.

• The feature list common to both products is expanded.

• Some features and efficiencies formerly exclusive to the ERT target are now available to the GRT target. Conversely, the ERT target now supports some features that were previously available only with the GRT target.

• Conversion from GRT-based targets to ERT-based targets is greatly simplified.

See the Version 6.0 (R14) Real-Time Workshop Release Notes for a high-level overview and comparison of feature enhancements and compatibility issues that result from target unification in Real-Time Workshop 6.0 and Real-Time Workshop Embedded Coder 4.0.

Support for Continuous Time Blocks

The ERT target now supports code generation for continuous time blocks. If you select the Support continuous time option in the Interface subpane under Real-Time Workshop on the Configuration Parameters dialog box, you can use any such blocks in your models, without restriction.

Note that use of certain continuous time blocks is not recommended for production code generation for embedded systems. The Simulink Block Data Type Support table summarizes characteristics of blocks in the Simulink and Fixed-Point block libraries, including whether or not they are recommended for use in production code generation. To view this table, execute the following MATLAB command:

showblockdatatypetable

Then, refer to the "Recommended for Production Code?" column of the table.

Support for Continuous Solvers

The ERT target now supports continuous solvers. You can select any solver from the Solver menu on the Solver pane of the Configuration Parameters dialog box. However, note that the solver Type must be fixed-step for use with the ERT target, as in previous releases.

Note    Custom targets must be modified to support continuous time. The required modifications are described in Supporting Continuous Time in Custom Targets.

Support for Noninlined S-Functions

In previous releases, the ERT target required that all S-functions in a model be inlined with a corresponding TLC file for code generation. This restriction has been removed. Models can now include noninlined S-functions.

To enable support for noninlined S-functions, select the Support non-inlined S-functions option in the Interface subpane under Real-Time Workshop on the Configuration Parameters dialog box.

Note that inlining S-functions is often advantageous in production code generation, for example in implementing device drivers. See Tradeoffs in Device Driver Development in the Developing Embedded Targets document for a discussion of the pros and cons.

Module Packaging Features

Module Packaging Features (MPF) are a major subcomponent of the Real-Time Workshop Embedded Coder. These features enable teams of engineers to apply the Real-Time Workshop Embedded Coder for generating ANSI/ISO production code and executables for large-scale, multimodel control system applications.

The Module Packaging Features document describes these features in detail. This note summarizes the capabilities of MPF.

Introduction

With MPF, you can

• Package the generated code into the desired number of .c and .h files.

• Control the internal organization of each of the generated files. For example, for readability, your company may have software standards that define where to place comments and sections of code within files.

• Control whether or not the generated files contain definitions for a model's global identifiers. If such definitions exist, you determine the files in which the code generator places them. Also, you can specify the generated files where the code generator places global data (extern) declarations.

In addition to meeting the preceding packaging needs, you can use MPF to

• Register user-defined data types.

• Customize comments.

• Locate variables in target memory where desired.

You implement these features with available dialogs, user-definable templates, and M-scripts.

MPF Feature Summary

This section summarizes the module packaging features introduced in Real-Time Workshop Embedded Coder Version 4.0. MPF allows you to

• Select or define MPF template files. You can generate the desired .c and .h files and organize them the way you want. Also, these templates include template symbols whose locations in a template file determine where comments and code is located in the individual generated files.

• Manage the code generation data dictionary. This allows

  • Registering user-defined data types

  • Importing data objects into the code generation data dictionary from a .mat file of a previous Simulink session or from an external data dictionary (such as an Excel file)

  • Adding Simulink data objects using the Data Object Wizard

  • Changing the alphabetical case and spellings that identifier names have in the generated code

• Select additional miscellaneous and advanced options. These include

  • Instructing the code generator to use the angle-bracket delimiter (for multiple data objects), instead of the double-quotation delimiter.

  • Selecting the source that initializes each of the model's signals in the generated code.

  • Adding a selected data object's property values as a comment in a generated file above that data object's identifier.

  • Adding a comment to the model using the Simulink DocBlock so that this comment appears in the generated file where desired.

• Manage file placement of data declarations. You can determine whether or not the generated files contain defining declarations for a model's global identifiers. If defining declarations exist, you can determine the files in which the code generator places them. Also, you can determine the files where the code generator places global data reference (extern) declarations.

ASAP2 File Generation Changes

ASAP2 file generation is now available to all Real-Time Workshop targets. The documentation for this feature has been relocated to Generating an ASAP2 File in the Real-Time Workshop documentation.

Code Generation with User-Defined Data Types

Real-Time Workshop Embedded Coder now supports user-defined data type objects in code generation. Supported objects include objects of the following classes:

• Simulink.NumericType

• Simulink.StructType

• Simulink.Bus

• Simulink.Aliastype

In code generation, you can use user-defined data type objects to map your own data type definitions to Simulink built-in data types, and to generate #include directives specifying your own header files, containing your data type definitions.

See the Advanced Code Generation Techniques chapter of the Real-Time Workshop Embedded Coder documentation for details.

Enhanced Custom Storage Classes

The Real-Time Workshop Embedded Coder has extended the built-in storage classes provided by Real-Time Workshop. The Real-Time Workshop Embedded Coder now includes:

• A set of custom storage classes (CSCs). CSCs are designed to be useful in code generation for embedded systems development. The new enhanced and expanded CSC functionality has been incorporated into the Simulink.Signal and Simulink.Parameter classes. This simplifies code generation with CSCs, since you can use familiar signal and parameter objects for this purpose.

• The new Custom Storage Class Designer (cscdesigner) tool. The Custom Storage Class Designer lets you define additional CSCs that are tailored to your code generation requirements. The Custom Storage Class Designer provides a graphical user interface that lets you implement CSCs quickly and easily. You can use your CSCs in code generation immediately, without any TLC or other programming.

CSCs give you extended control over the constructs required to represent data in an embedded algorithm. For example, you can use CSCs to

• Define structures for storage of parameter or signal data.

• Conserve memory by storing Boolean data in bit fields.

• Integrate generated code with legacy software whose interfaces cannot be modified.

• Generate data structures and definitions that comply with your organization's software engineering guidelines for safety-critical code.

See the Custom Storage Classes chapter of the Real-Time Workshop Embedded Coder User's Guide for a detailed description of CSCs and the Custom Storage Class Designer.

Compatibility with Previous CSCs

In prior releases, CSCs were implemented via special Simulink.CustomSignal and Simulink.CustomParameter classes. We recommend that you consider replacing Simulink.CustomSignal and Simulink.CustomParameter objects in your models with equivalent Simulink.Signal and Simulink.Parameter objects.

Minor changes have been made in the Simulink.CustomSignal and Simulink.CustomParameter classes. See Custom Storage Class Compatibility Issues for information on these changes.

More Efficient Multi-Rate Multitasking Code Generation

Real-Time Workshop Embedded Coder now generates significantly faster code for multirate multitasking models.

For multirate multitasking models, Real-Time Workshop Embedded Coder uses a strategy called rate grouping. Rate grouping generates separate model_step functions for the base rate task and each subrate task in the model. The function naming convention for these functions is

model_stepN

where N is a task identifier. For example, for a model named my_model that has three rates, the following functions are generated:

void my_model_step0 (void);
void my_model_step1 (void);
void my_model_step2 (void);

Each model_stepN function executes all blocks sharing tid N; in other words, all block code that executes within task N is grouped into the associated model_stepN function.

For other cases, Real-Time Workshop Embedded Coder generates a single model_step function. This model_step function uses the same scheduling technique (called rate guarding) as in previous versions of the product. When rate guarding is used, a task identifier is passed in to the model_step function.

To take advantage of rate grouping for existing multirate multitasking models, you must regenerate code, including the main program, ert_main.c.

See the Data Structures, Code Modules, and Program Execution chapter of the Real-Time Workshop Embedded Coder documentation for a complete discussion of rate grouping.

More Efficient Task Scheduling for RTOS Targets

Using a new rtmStepTask macro, targets that employ the task management mechanisms of an RTOS can eliminate certain redundant scheduling calls during the execution of tasks in a multirate, multitasking model, thereby improving performance of the generated code.

The redundant scheduling calls are still generated by default for backward compatibility. However, you can suppress them by adding the following TLC variable definition to your system target file before the %include "codegenentry.tlc" statement:

%assign SuppressSetEventsForThisBaseRateFcn = 1

For more details on this feature, see Optimizing Task Scheduling for Multirate Multitasking Models on RTOS Targets in the Real-Time Workshop Embedded Coder documentation.

New Callbacks Defined for System Target Files

The Release 14 API for system target file callbacks provides three new callback functions for use in system target files. Unlike rtwoptions callbacks, these functions are associated with the target, not with its individual options. The callbacks are installed as fields in the rtwgensettings structure of the system target file. The callbacks, summarized in the next table, are fully described in the System Target Files chapter of Developing Embedded Targets.

Note    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 the Supporting Optional Features chapter of Developing Embedded Targets.

New Option to Control Template Makefile Output Display

A new template makefile option lets you control whether or not template makefile output is displayed during the build process. To enable makefile output display at all times (regardless of the setting of the Verbose build option in the Real-Time Workshop Debugging pane) add the following macro to your template makefile:

VERBOSE_BUILD_OFF_TREATMENT = PRINT_OUTPUT_ALWAYS

When you configure your template makefile this way, the Verbose build option controls the display of other build process output (such as TLC messages), but template makefile output is always displayed.

You should add this macro in the template makefile section that includes other macros, such as BUILD_SUCCESS.

Demo Updates

This release includes a major update and reorganization of the Real-Time Workshop and Real-Time Workshop Embedded Coder demo collection. If you are reading this document online in the MATLAB Help browser, you can open the demo suite by clicking this link: rtwdemos.

Alternatively, you can access the demo suite by typing the name of the demo library at the MATLAB command prompt:

rtwdemos

Upgrading from R13SP1+ or R13SP2

This section discusses the following issues pertaining to upgrades from Real-Time Workshop Embedded Coder V3.2 (R13SP1+) or V3.2.1 (R13SP2) to V4.0 (R14):

• TMF File Update Required for Use with Release 14 or Higher If Supporting ERT S-Function Generation

• Custom Storage Class Compatibility Issues

• Defining and Displaying Custom Target Options

• Supporting Model Referencing in Custom Targets

• Supporting Continuous Time in Custom Targets

• rtwtypes.h Replaces tmwtypes.h

• Updating Customized Static Main Program Modules

• Integer Code Only Option Replaced

• Rate Grouping Compatibility Issues

• Real-Time Object Structure Obsoleted by Real-Time Model Structure

• rtmIsSampleHit and rtmIsSpecialSampleHit Macros Obsolete

• RTWInfo Properties Assignment Warning Message

TMF File Update Required for Use with Release 14 or Higher If Supporting ERT S-Function Generation

To use a Release 13 based TMF that supports ERT S-function generation with Release 14 or higher, you must update the TMF to include the following definitions:

LIBFIXPT=$(MATLAB_ROOT)\extern\lib\win32\microsoft\msvc50\libfixedpoint.lib
LIBS = $(LIBS) $(LIBFIXPT)

For example:

1. Search for an if statement similar to the following:

   !if $(B_ERTSFCN) == 1
   ERT_SFUN     = ..\$(MODEL)_sf.$(MEXEXT)
   ERT_SFUN_SRC = $(MODEL)_sf.c
   MEX          = $(MATLAB_BIN)\mex
   !endif

   The lines of code in the if statement may vary slightly depending on the make utility you are using.

2. Add the LIBFIXPT and LIBS definitions between the MEX definition and the !endif as follows:

   !if $(B_ERTSFCN) == 1
   ERT_SFUN     = ..\$(MODEL)_sf.$(MEXEXT)
   ERT_SFUN_SRC = $(MODEL)_sf.c
   MEX          = $(MATLAB_BIN)\mex
   LIBFIXPT =$(MATLAB_ROOT)\extern\lib\win32\microsoft\msvc50\libfixedpoint.lib
   LIBS     = $(LIBS) $(LIBFIXPT)
   !endif

For more examples, see the supplied Real-Time Workshop TMFs.

Custom Storage Class Compatibility Issues

Prior to 4.0, custom storage classes were implemented with special Simulink.CustomSignal and Simulink.CustomParameter classes.

In 4.0 and higher, the full functionality of the Simulink.CustomSignal and Simulink.CustomParameter classes is included in the Simulink.Signal and Simulink.Parameter classes. Consider replacing Simulink.CustomSignal and Simulink.CustomParameter objects in your models with equivalent Simulink.Signal and Simulink.Parameter objects.

If you prefer, you can continue to use the Simulink.CustomSignal and Simulink.CustomParameter classes in the current release. However, note that the following changes have been implemented in these classes:

• The Internal storage class has been removed from the enumerated values of the RTWInfo.CustomStorageClass property. Internal storage class is no longer supported.

• For the ExportToFile and ImportFromFile storage classes, the RTWInfo.CustomAttributes.FileName and RTWInfo.CustomAttributes.IncludeDelimeter properties have been combined into a single property, RTWInfo.CustomAttributes.HeaderFile. When specifying a header file, include both the filename and the required delimiter as you want them to appear in generated code, as in the following example:

  myobj.RTWInfo.CustomAttributes.HeaderFile = '<myheader.h>';

• Prior to 4.0, you created user-defined CSCs by designing custom packages that included the CSC definitions (as described in the cscdesignintro tutorial demo). This technique for creating CSCs is obsolete. For a description of the current procedure, which is much simpler, see Creating Packages with CSC Definitions in the "Custom Storage Classes" chapter of the Real-Time Workshop Embedded Coder documentation.

  If you designed your own custom packages containing CSCs prior to 4.0, The MathWorks strongly recommends that you convert them to 4.0 CSCs. The conversion procedure is described in Converting Older Packages to Use CSC Registration Files in the "Custom Storage Classes" chapter of the Real-Time Workshop Embedded Coder documentation.

Defining and Displaying Custom Target Options

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 and Configuration Parameters dialogs to present target options to end users. If you choose not to, a mechanism for using the old-style Simulation Parameters dialog box is available for backwards compatibility.

The System Target Files chapter of Developing Embedded Targets discusses compatibility issues and solutions related to the definition and display of target-specific options for custom targets.

• Callback compatibility: If the rtwoptions array in your custom system target file contains callbacks, you must convert your callbacks to use the callback compatibility API provided in this release. See Using rtwoptions Callbacks in Release 14 or Later in the "System Target Files" chapter of Developing Embedded Targets.

• Target options inheritance: If your custom target is derived from another target and inherits options, you need change your system target file to use a new inheritance mechanism. See Target Options Inheritance in Release 14 or Later in the "System Target Files" chapter of Developing Embedded Targets.

• Display of target options: Your target options are displayed differently, and you might want to reorganize them. See Target Options Display in Release 14 or Later in the "System Target Files" chapter of Developing Embedded Targets for information on how custom target options are displayed.

Supporting Model Referencing in Custom Targets

Existing custom targets require a number of modifications for code generation compatibility with the model reference features introduced in Release 14. The Supporting Optional Features chapter of Developing Embedded Targets provides the information you need to adapt your target to support model referencing. Most of the guidelines concern required modifications to the system target file and template makefile.

The list below summarizes general requirements and issues for model reference compatibility that are discussed in the Supporting Optional Features chapter:

• A model reference compatible target must be derived from the ERT or GRT targets.

• Your system target file must declare model reference compatibility.

• Your template makefile must define a number of makefile tokens, variables and rules specifically for model referencing support.

• To support model reference builds, your template makefile must support use of the shared utilities directory.

• 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.

For general information about model referencing, see the Real-Time Workshop documentation.

Supporting Continuous Time in Custom Targets

As of Release 14, the ERT target supports continuous time. If you want your custom ERT-based target to take advantage of this feature, you must update your template makefile (TMF) and the static main program module (for example, mytarget_main.c) for your target.

Template Makefile Modifications.   Add the NCSTATES token expansion after the NUMST token expansion, as follows:

NUMST = |>NUMST<|
NCSTATES = |>NCSTATES<|

In addition, add NCSTATES to the CPP_REQ_DEFINES macro, as in the following example:

CPP_REQ_DEFINES = -DMODEL=$(MODEL) -DNUMST=$(NUMST) -DNCSTATES=$(NCSTATES) \
-DMAT_FILE=$(MAT_FILE)
-DINTEGER_CODE=$(INTEGER_CODE) \
-DONESTEPFCN=$(ONESTEPFCN) -DTERMFCN=$(TERMFCN) \
-DHAVESTDIO
-DMULTI_INSTANCE_CODE=$(MULTI_INSTANCE_CODE) \
-DADD_MDL_NAME_TO_GLOBALS=$(ADD_MDL_NAME_TO_GLOBALS)

Modifications to Main Program Module.   The main program module defines a static main function that manages task scheduling for all supported tasking modes of single- and multiple-rate models. NUMST (the number of sample times in the model) determines whether the main function calls multirate or single-rate code.

However, when the model has continuous time, it is incorrect to rely on NUMST directly.

When the model has continuous time and the flag TID01EQ is true, both continuous time and the fastest discrete time are treated as one rate in generated code. The code associated with the fastest discrete rate is guarded by a major time step check. When the model has only two rates, and TID01EQ is true, the generated code has a single-rate call interface.

To support models that have continuous time, update the static main module to take TID01EQ into account, as follows:

1. Before NUMST is referenced in the file, add the following code:

   #if defined(TID01EQ) && TID01EQ == 1 && NCSTATES == 0
   #define DISC_NUMST (NUMST - 1) 
   #else 
   #define DISC_NUMST NUMST 
   #endif

2. Replace all instances of NUMST in the file by DISC_NUMST.

rtwtypes.h Replaces tmwtypes.h

The ERT target now generates an optimized rtwtypes.h header file, which includes only the necessary definitions required by the target. Most generated code modules require these definitions. This header file replaces the static tmwtypes.h header file. Note that non-ERT targets still use the tmwtypes.h header file.

Updating Customized Static Main Program Modules

If you are upgrading and your application uses a customized version of the static main program module ert_main.c, open the module and make the following changes:

1. Search for RT_MDL. This search brings you to the "Required defines" section.

2. Replace

   #define RT_MDL               CONCAT(MODEL,_rt0)

   with

   #define RT_MDL               CONCAT(MODEL,_M)

3. Search for tmwtypes.h. This search brings you to the "Includes" section.

4. Add the following include statement.

   #include "rtwtypes.h"

5. Delete the following include statements.

   #include "tmwtypes.h"
   #include "simstruc_types.h"

6. Just below the #include section, add the following preprocessor conditional code, which determines whether to set up multitasking mode. Previously, this code resided in simstruc_types.h.

   /*========================* 
    * Setup for multitasking * 
    *========================*/
   #if defined(MT)
   # if MT == 0
   #  undef MT
   # else
   #  define MULTITASKING 1
   # endif
   #endif

For more information about ert_main.c, see Static Main Program Module in the Real-Time Workshop Embedded Coder documentation.

The MathWorks recommends that you generate a target-specific main program module rather than use a customized version of the static module, ert_main.c. For details, see Generating the Main Program Module and Custom File Processing in the Real-Time Workshop Embedded Coder documentation.

Integer Code Only Option Replaced

The Support floating-point numbers option replaces, and inverts the logic of, the Integer code only option that was supported in previous releases. To generate pure integer code in new models, deselect the Support floating-point numbers option.

Note that for compatibility, models that were configured for Integer code only prior to Release 14 are automatically configured with Support floating-point numbers deselected, and generate pure integer code.

Rate Grouping Compatibility Issues

To take full advantage of the efficiency of rate grouping:

• Your multirate inlined S-functions must be upgraded to be fully rate grouping compliant. Existing S-functions continue to operate correctly without change, but we strongly recommend that you upgrade your TLC S-function implementations. See Rate Grouping Compliance and Compatibility Issues in the "Data Structures and Program Execution" chapter of the Real-Time Workshop Embedded Coder documentation.

• If you have previously generated and modified ert_main.c (as is typical of many ERT-based custom targets) take care to preserve your modifications and make equivalent changes to the regenerated ert_main.c. After you have done so, set the TLC variable RateBasedStepFcn to 1, as described in Rate Grouping and the Static Main Program in the "Data Structures and Program Execution" chapter of the Real-Time Workshop Embedded Coder documentation.

Real-Time Object Structure Obsoleted by Real-Time Model Structure

In MATLAB Release 13, the real-time model (model_M) data structure replaced the real-time object (model_rtO) data structure. However, use of use of the older structure was still supported for backward compatibility.

Real-Time Workshop Embedded Coder 4.0 requires use of the real-time model data structure. If you have developed a custom target that references model_rtO (for example, in a customizedert_main.c module) you must replace them with references to model_M.

See the Data Structures, Code Modules, and Program Execution chapter of the Real-Time Workshop Embedded Coder documentation for further information about the real-time model data structure.

rtmIsSampleHit and rtmIsSpecialSampleHit Macros Obsolete

The following macros are now obsolete and should not be used with the ERT target:

• rtmIsSampleHit

• rtmIsSpecialSampleHit

This does not cause a problem unless you have coded these macros directly into your TLC files. The recommended practice is to use the following TLC library functions:

• %<LibIsSFcnSampleHit(tid)>

• %<LibIsSFcnSpecialSampleHit(tid)>

If you have used these functions, they operate transparently.

RTWInfo Properties Assignment Warning Message

This note describes a minor change in behavior when the RTWInfo properties of a data object are assigned incorrectly.

You can assign a custom storage class to a data object either by using Simulink Model Explorer, or by setting the RTWInfo properties via MATLAB commands. (See also the Custom Storage Classes chapter in the Real-Time Workshop Embedded Coder documentation.) If you use MATLAB commands to assign a custom storage class, you must set both the RTWInfo.CustomStorageClass and RTWInfo.StorageClass fields. Make sure that the RTWInfo.StorageClass property is set to 'Custom', as in the following example.

aa = Simulink.Signal;
aa.RTWInfo.StorageClass = 'Custom';
aa.RTWInfo.CustomStorageClass = 'Struct';
aa.RTWInfo.CustomAttributes.StructName = 'mySignals';

If the RTWInfo.StorageClass is not set correctly as shown above, the assigned custom storage class (RTWInfo.CustomStorageClass) are ignored during code generation. In such cases, a warning is displayed at the time RTWInfo.CustomStorageClass is assigned, for example

foo = Simulink.Signal
foo.RTWInfo.CustomStorageClass = 'Struct'

Warning: The 'CustomStorageClass' property of RTWInfo will have 
no effect unless the 'StorageClass' property is set to 'Custom'.

Previously, the warning was displayed at the time RTWInfo.StorageClass was assigned.

Generating R13SP1+ or R13SP2 Code From ERT-Based Simulink Models Created In R14 or Later

Due to a design change made in V4.0 (R14) Real-Time Workshop Embedded Coder, a Real-Time Workshop error occurs when generating R13SP1+ or R13SP2 code from an ERT-based Simulink model created in R14 or later.

If you use R14 or later to save an ERT-based Simulink model into R13SP1 format (using Simulink File > Save As > Save as type), and then try to generate code for the model under R13SP1+ or R13SP2, the following error is displayed:

Error executing build command: Error using ==> make_rtw 
Error using ==> tlc_c 
Error using ==> tlc_c (InvokeTLC) 
Error:  Real-Time Workshop Error: Unable to locate ERT header file banner template:
ert_code_template.cgt.

To work around this problem in R13SP1+ or R13SP2, download and install a replacement version of the file matlabroot/rtw/c/tlc/mw/setuplib.tlc, as follows:

1. Go to the directory matlabroot/rtw/c/tlc/mw and rename the file setuplib.tlc to setuplib.tlc.old.

2. Click the appropriate link below to download a replacement version of setuplib.tlc. Place the file in the same directory as the file you renamed.

   • setuplib_sp2.tlc

   • setuplib_sp1plus.tlc

   Note   If you are not logged in to your MathWorks Account when you click the link, you will prompted to log in or create an account. If you are reading the PDF or hard copy documentation, go to the MATLAB Help browser or The MathWorks web documentation to use the link.

3. Rename the downloaded file to setuplib.tlc.

Version 4.1 (R14SP1) Real-Time Workshop Embedded Coder Software

Version 3.2.1 (R13SP2) Real-Time Workshop Embedded Coder Software