Real-Time Workshop®

For Use with Simulink ®

Getting Started
Version 6

How to Contact The MathWorks:
www.mathworks.com
comp.soft-sys.matlab

Web
Newsgroup

info@mathworks.com

Technical support
Product enhancement suggestions
Bug reports
Documentation error reports
Order status, license renewals, passcodes
Sales, pricing, and general information

508-647-7000

Phone

508-647-7001

Fax

The MathWorks, Inc.
3 Apple Hill Drive
Natick, MA 01760-2098

Mail

support@mathworks.com
suggest@mathworks.com
bugs@mathworks.com
doc@mathworks.com
service@mathworks.com

For contact information about worldwide offices, see the MathWorks Web site.
Getting Started with Real-Time Workshop
 COPYRIGHT 2002-2004 by The MathWorks, Inc.
The software described in this document is furnished under a license agreement. The software may be usedor copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by,for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial
computer software or commercial computer software documentation as such terms are used or defined in
FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of thisAgreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and Documentation by thefederal government (or other entity acquiring for or through the federal government) and shall supersede any
conflicting contractual terms or conditions. If this License fails to meet the government's needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Documentation, unused, to The MathWorks, Inc.
MATLAB, Simulink, Stateflow, Handle Graphics, and Real-Time Workshop are registered trademarks, andTargetBox is a trademark of The MathWorks, Inc.
Other product or brand names are trademarks or registered trademarks of their respective holders.

Printing History: July 2002
June 2004

First printing
Second printing

New for Version 5 (Release 13)
Updated for Version 6.0 (Release 14)

Contents
What Is Real-Time Workshop?

1
Introducing Real-Time Workshop . . . . . . . . . . . . . . . . . . . . . .
Components and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capabilities and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accelerating Your Development Process . . . . . . . . . . . . . . . . . .

1-2
1-2
1-3
1-6

Installing Real-Time Workshop . . . . . . . . . . . . . . . . . . . . . . .
Third-Party Compiler Installation on Windows . . . . . . . . . . .
Supported Compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiler Optimization Settings . . . . . . . . . . . . . . . . . . . . . . . .

1-11
1-12
1-14
1-15

Real-Time Workshop Demos . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Help and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Printing the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
For Further Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-17
1-17
1-18
1-18
1-18

Building an Application

2
Real-Time Workshop Workflow . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Mapping Application Requirements to Configuration Options 2-4
Setting Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Running the Model Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Generating Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Building an Executable Program Image . . . . . . . . . . . . . . . . . 2-10
Verifying the Generated Results . . . . . . . . . . . . . . . . . . . . . . . 2-11
Save the Model Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Automatic Program Building . . . . . . . . . . . . . . . . . . . . . . . . . 2-13i

The Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Model Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Customized Makefile Generation . . . . . . . . . . . . . . . . . . . . . . . 2-18
Executable Program Generation . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Files and Directories Created by the Build Process . . . . . . . . . 2-22

Working with Real-Time Workshop

3
Basic Real-Time Workshop Concepts . . . . . . . . . . . . . . . . . . . 3-2
Target and Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Available Target Configurations . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Code Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
The Generic Real-Time Target . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Target Language Compiler Files . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Template Makefiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
The Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Model Parameters and Code Generation . . . . . . . . . . . . . . . . . . 3-6
Quick Start Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Tutorial 1: Building a Generic Real-Time Program . . . . . . . . . . 3-9
Tutorial 2: Data Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
Tutorial 3: Code Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
Tutorial 4: A First Look at Generated Code . . . . . . . . . . . . . . . 3-30
Tutorial 5: Working with External Mode Using GRT . . . . . . . 3-39
Tutorial 6: Generating Code for a Referenced Model . . . . . . . . 3-51

Glossaryii

Contents

Indexiii

iv

Contents

1
What Is Real-TimeWorkshop?
This guide begins with a high-level overview of Real-Time Workshop®, describing its purpose, its
component parts, its major features, and the ways in which it leverages the modeling power ofSimulink® for developing real-time applications on a variety of platforms. You will also find here
helpful information about installing Real-Time Workshop, including discussions of related products
from The MathWorks and compilers from third parties, as well as pointers to demos and online andprintable documentation. The chapter is laid out as follows:
Introducing Real-Time Workshop (p. 1-2) What it is, and what it can do for you
Installing Real-Time Workshop (p. 1-11)

Information on supported compilers

Real-Time Workshop Demos (p. 1-16)

Demonstrations you can summon that illustrate code
generation capabilities

Help and Documentation (p. 1-17)

Locating and using online and printed help documents

1 What Is Real-Time Workshop?

Introducing Real-Time Workshop
Real-Time Workshop® is an extension of capabilities of Simulink® and
MATLAB® that automatically generates, packages and compiles source codefrom Simulink models to create real-time software applications on a variety ofsystems. By providing a code generation environment for rapid prototyping
and deployment, Real-Time Workshop is the foundation for production code
generation capabilities. Along with other tools and components from The
MathWorks, Real-Time Workshop provides• Automatic code generation tailored for a variety of target platforms• A rapid and direct path from system design to implementation• Seamless integration with MATLAB and Simulink• A simple graphical user interface• An open architecture and extensible make process

Components and Features
The principal components and features of Real-Time Workshop are• Simulink Code Generator — Automatically generates C code from yourSimulink model.
• Make Process — The Real-Time Workshop user-extensible make processlets you customize compilation and linking of generated code for your own
production or rapid prototyping target.
• Simulink External Mode — External mode enables communication
between Simulink and a model executing on a real-time test environment, orin another process on the same machine. External mode lets you perform
real-time parameter tuning, data logging, and viewing using Simulink as afront end.
• Targeting Support — Using the targets bundled with Real-Time Workshop,
you can build systems for real-time and prototyping environments. The
generic real-time and other bundled targets provide a framework fordeveloping customized rapid prototyping or production target environments.
In addition to the bundled targets, the optional Real-Time Windows Target
and the xPC Target let you turn almost any PC into a rapid prototyping
target, or a small to medium volume production target. To supplement corecapabilities, the optional Real-Time Workshop Embedded Coder and

1-2

Introducing Real-Time Workshop

embedded target products extend and tailor Real-Time Workshop code to run
in a growing suite of microprocessor environments.
• Rapid Simulations — Using Simulink Accelerator, the S-Function Target,or the Rapid Simulation Target, you can accelerate your simulations by 5 to20 times on average. Executables built with these targets bypass normal
Simulink interpretive simulation mode. Code generated by Simulink
Accelerator, S-Function Target, and Rapid Simulation Target is highly
optimized to execute only the algorithms used in your specific model. In
addition, the code generator applies many optimizations, such as eliminating
ones and zeros in computations for filter blocks.
• Large-Scale Modeling — Support for multilevel modeling (termed “model
referencing”) in Simulink is mirrored in Real-Time Workshop, which lets you
generate code incrementally for a hierarchy of independent component
models, as they evolve.

Capabilities and Benefits
Specific capabilities and benefits of Real-Time Workshop include• Code generation for Simulink models- Generates optimized, customizable code. There are several styles ofgenerated code, which can be classified as either embedded (production
phase) or rapid prototyping.
- Supports all Simulink features, including 8-, 16-, and 32-bit integers andfloating-point double and single data types.
- Fixed-point capabilities allow for scaling of integer words ranging from 2
to 128 bits. Code generation is limited by the implementation of char,short, int, and long in embedded C compiler environments (usually 8, 16,
and 32 bits, respectively). You can choose hardware characteristics formore than 20 preconfigured target processors by name or create your own
custom processor definition- Generated code is processor independent. The generated code represents
your model exactly. A separate run-time interface is used to execute thiscode. Real-Time Workshop provides several example run-time interfaces,
as well as production run-time interfaces.
- Supports single- or multitasking operating system environments, as wellas “bare-board” (no operating system) environments.

1-3

1 What Is Real-Time Workshop?

- The flexible scripting capabilities of the Target Language Compiler enable
you to fully customize generated code.
- Efficient code for S-functions (user-created blocks) can be crafted using
Target Language Compiler instructions (called TLC scripts) andautomatically integrated with generated code.
• Extensive model-based debugging support- External mode enables you to examine what the generated code is doingby uploading data from your target to the graphical display elements inyour model. There is no need to use a conventional source-level debugger
to look at your generated code.
- External mode also enables you to tune the generated code via yourSimulink model. When you change a parametric value of a block in yourmodel, the new value is passed down to the generated code, running on
your target, and the corresponding target memory location is updated.
Again, there is no need to use an embedded compiler debugger to perform
this type of operation. Your model is your debugger user interface.
• Integration with Simulink- Code verification. You can generate code for your model and create astand-alone executable that exercises the generated code and produces a
MAT-file containing the execution results.
- Generated code contains system and block identification tags to help you
identify the block, in your source model, that generated a given line ofcode. The MATLAB command hilite_system recognizes these tags andhighlights the corresponding blocks in your model.
- Support for Simulink data objects lets you define how your signals andblock parameters interface to the external world.
• Integration with Stateflow®
- Code generation. Seamless code generation support for models that
contain Stateflow charts.
- Full support for Stateflow Coder features.
• Rapid simulations- Real-Time Workshop supports several ways to speed up your simulations
by creating optimized, model-specific executables.

1-4

Introducing Real-Time Workshop• Target support- Turnkey solutions for rapid prototyping substantially reduce design
cycles, allowing for fast turnaround of design iterations.
- Bundled rapid prototyping example targets provide working code you can
modify and use quickly.
- The optional Real-Time Windows and xPC targets for PC-based hardware
from The MathWorks enable you to turn a PC with fast, high-quality,
low-cost hardware into a rapid prototyping system.
- Real-Time Workshop Embedded Coder, an add-on product, provides
extensive support for tailoring generated code to special requirements ofembedded hardware, software environments, data formats, and toolchain
protocols.
- The MathWorks offers a growing set of embedded target code generation
products for embedded processors, such as the Embedded Target for
Infineon C166 Microcontrollers, the Embedded Target for Motorola HC12,
and the Embedded Target for Motorola MPC555, which via turnkey
hardware support extend the benefits of Real-Time Workshop andReal-Time Workshop Embedded Coder into production environments.
- Supports a variety of third-party hardware and tools, with extensible
device driver support.
• Extensible make process- Allows for easy integration with any embedded compiler and linker.
- Provides for easy linkage with your hand-written supervisory or
supporting code.
The Real-Time Workshop Embedded Coder, mentioned above, provides• Customizable, portable, and readable C code that is designed to be placed ina production embedded environment.
• More compact and efficient code, especially for multitasking applications.
• Software-in-the-loop. With the Real-Time Workshop Embedded Coder, you
can generate code for your embedded application and bring it back into
Simulink for verification via simulation.
• Web-viewable code generation report, which describes in detail code
modules, traces the generated code back to blocks in the model, analyzes thegenerated code, and helps to identify code generation optimizations relevant
to your program.

1-5

1 What Is Real-Time Workshop?

• Annotation of the generated code using the Description block property.
• Control over naming and storage class for parameter and signal data, plus
fully customizable custom storage class definitions and code generation
methods.
• Signal logging options and external parameter tuning, enabling easyinterfacing of the generated code in your real-time system.

Accelerating Your Development Process
The MathWorks gives you the ability to simplify and accelerate most phases ofsoftware development, and at the same time to eliminate repetitive anderror-prone tasks, including some design document preparation. These tools
lend themselves particularly well to the spiral design process shown below,
should you choose to use it.

1-6

Introducing Real-Time Workshop

System-Level
DesignDetailed
DesignProblem/Task
Formulation

FINISHSTART

Softwareand Hardware
Implementation

Production and
Manufacturing
Testing
DesignVerification
via Testing

SPECIFICATIONVERIFICATIONDESIGNINTEGRATIONSOFTWARE IMPLEMENTATION

Spiral Design Process

When you work with tools from The MathWorks, your model represents yourunderstanding of your system. This understanding is passed from one phase ofmodeling to the next, reducing the need to backtrack. In the event that rework
is necessary in a previous phase, it is easier to step back one or more phases,
because the same model and tools are used throughout.
A spiral design process allows quick iterations between phases, enablingengineers to focus on design work. To do this cost-effectively, they need to use
tools that make it easy to move from one phase to another. For example, in amatter of minutes a control system engineer or a signal processing engineer

1-7

1 What Is Real-Time Workshop?

can verify that an algorithm works on a real-world rapid prototyping system.
The spiral process lends itself naturally to parallelism in the overall
development process. You can provide early working models to validation andproduction groups, involving them in your system development process fromthe start. Once unit models are prototyped, tested, and ready, they can bepackaged into larger assemblies using Model blocks (the Simulink model
referencing facility). This helps to compress overall development time while
increasing quality.
Simulink facilitates the first three phases described in the above figure. You
can build applications from built-in blocks from the Simulink and Stateflow
libraries, incorporate specialized blocks from the Aerospace, Communications,
Signal Processing, and other MathWorks blocksets, and develop your own
blocks by writing S-functions.
Real-Time Workshop (optionally extended by the Real-Time Workshop
Embedded Coder, the Real-Time Windows Target, and the xPC Target)
completes the spiral process. It closes the rapid protoyping loop, by generating
and optimizing code for given tasks and production environments.
The figure below illustrates where products from The MathWorks, including
Real-Time Workshop, help you in your development process.

1-8

Introducing Real-Time Workshop

Interactive modeling and simulation

High-speed simulation

Simulink
Stateflow
Blocksets

Accelerator,
S-function Targets

Interactive design

MATLAB
and
Toolboxes

Real-Time
Workshop

DesignCycle

Embedded
Coder

Deployed system
Embedded Target(custom or standard)

System testing and tuning
Embedded Target(custom or standard)

Software integration
Embedded Target

g
in
est
tt
ni
et
eu
rg
ar
Ta
ftw
ed
So
dd
be
Em

Customer-definedmonitoring andparameter tuning,storage classes

Bat
ch d
esig
n ve
Rap
rific
id S
atio
imu
n
Tar
lati
on
g
e
t
Sy
st
em
R
de
a
T pi
a r d ve l o
pm
ge P
ts ro
e
( r to t n ttea yl-t pi esting
im n ge)(custom or standard)

Roles of MathWorks Products in Software Development

Early in the design process, you use MATLAB and Simulink to help you
formulate your objectives, problems, and constraints to create your initialdesign. Real-Time Workshop helps with this process by enabling high-speed
simulations via Simulink Accelerator and model referencing to componentize
and speed up models.
After you have a functional model, you might need to tune your model’s
parameters. You can do this quickly using the Real-Time Workshop Rapid
Simulation Target for Monte-Carlo and other batch-oriented simulations(varying coefficients over many simulations).
Once you have tuned your model, you can move into system development
testing by exercising your model on a rapid prototyping system, such as the1-9

1 What Is Real-Time Workshop?

Real-Time Windows Target or the xPC Target. With a rapid prototyping target,
you connect your model to your physical system. This lets you locate design
flaws and modeling errors quickly.
After you have created your prototype system and have verified its outputs, you
can use Real-Time Workshop Embedded Coder to deploy generated code on
your custom target. The signal monitoring and parameter tuning capabilities
enable you to easily integrate the embedded code into a production
environment equipped with debugging and upgrade capabilities. See theReal-Time Workshop Embedded Coder documentation for an overview of thisprocess. First, however, see “Real-Time Workshop Workflow” on page 2-2 for aprocess view of using Real-Time Workshop.

1-10

Installing Real-Time Workshop

Installing Real-Time Workshop
Your platform-specific MATLAB installation documentation provides all theinformation you need to install Real-Time Workshop.
Prior to installing Real-Time Workshop, you must obtain a License File or
Personal License Password from The MathWorks. The License File or Personal
License Password (PLP) identifies the products you are permitted to installand use.
If you choose to customize your install, as the process proceeds, it displays adialog similar to the one below, letting you indicate which products to install.
Note that in the installer product window, you can only select for installation
MATLAB products for which you are licensed.
Simulink, Real-Time Workshop, and Real-Time Workshop Embedded Codereach have product prerequisites for proper installation and execution detailed
in the following table.

Licensed
Product

Prerequisite
Products

Additional Information

Simulink

MATLAB 7(Release 14)

Allows installation of Simulink.

Real-Time
WorkshopSimulink 6(Release 14)

Requires Borland C, LCC, Visual
C/C++, or Watcom C compiler tocreate MATLAB MEX-files or otherexecutables on your platform.

Real-Time
Workshop
Embedded
Coder

Real-Time
Workshop 6

If you experience installation difficulties and have Web access, connect to the
MathWorks home page (http://www.mathworks.com). Use the resources foundon the Installation, License Changes, and Passwords page at
http://www.mathworks.com/support/install/ to help you through theprocess.

1-11

1 What Is Real-Time Workshop?

Third-Party Compiler Installation on Windows
Most Real-Time Workshop targets create an executable that runs on yourworkstation. When creating the executable, Real-Time Workshop must be able
to access an appropriate compiler. The following sections describe how to
configure your system so that Real-Time Workshop can access your compiler.

BorlandMake sure that your Borland environment variable is defined and correctly
points to the directory in which your Borland compiler resides. To check this,type
set BORLAND

at the DOS prompt. The return from this includes the selected directory.
If the BORLAND environment variable is not defined, you must define it to point
to where you installed your Borland compiler. On Microsoft Windows 95 or 98,
add
set BORLAND=<path to your compiler>

to your autoexec.bat file.
On Microsoft Windows NT or 2000, in the control panel select System, click the
Advanced tab, select Environment, and define BORLAND to be the path to yourcompiler.

Intel
Real Time Workshop includes support for the Intel compiler (version 7.1 forMicrosoft Windows). The Intel compiler requires Microsoft Visual C/C++
version 6.0 or newer. However, only version 6.0 has been verified to work with
Real-Time Workshop in conjunction with the Intel compiler.
To use the Intel compiler when compiling Real-Time Workshop generated code,use mex –setup and select the Intel compiler.
To manually set up the Intel compiler,• Copy $(MATLAB)\bin\win32\mexopts\intelc71opts.bat to mexopts.bat inyour preferences directory (prefdir).
• Edit the new mexopts.bat and replace %MSVCDir% with the root directory of
your Microsoft Visual C/C++ version 6.0 installation.

1-12

Installing Real-Time Workshop• Replace %INTELC71% with the root directory of the Intel Compiler
installation.

LCC
The freeware LCC C compiler is shipped with MATLAB, and is installed withthe product. If you want to use LCC to build programs generated by Real-TimeWorkshop, use the version that is currently shipped with the product.
Information about LCC is available at
http://www.cs.virginia.edu/~lcc-win32/.

Microsoft Visual C/C++
Use the MATLAB commandmex -setup

to define the environment for Visual C/C++ Versions 5, 6, and 7.1
On Windows platforms, S-function targets and Model reference simulation
targets are generated as DLL files via the MATLAB mex command. The
compiler support for these targets is thus limited to that which mex provides.

WatcomNote The Watcom C compiler is no longer available from the manufacturer.
Development of this compiler has been taken over by the Open Watcom
organization (http://www.openwatcom.org), which, as of this printing, has
released a binary patch update (11.0c) for existing Watcom C/C++ and Fortrancustomers. Real-Time Workshop continues to ship with Watcom-related target
configurations. However, this policy may be subject to change in the future.

Make sure that your Watcom environment variable is defined and correctly
points to the directory in which your Watcom compiler resides. To check this,type
set WATCOM

at the DOS prompt. The return from this includes the selected directory.

1-13

1 What Is Real-Time Workshop?

If the WATCOM environment variable is not defined, you must define it to point
to where you installed your Watcom compiler. On Microsoft Windows 95 or 98,
add
set BORLAND=<path to your compiler>

to your autoexec.bat file.
On Microsoft Windows NT or 2000, in the control panel select System, click on
the Advanced tab, select Environment, and define WATCOM to be the path toyour compiler.

Out-of-Environment Error Message
If you receive out-of-environment space error messages, right-click your mouseon the program that is causing the problem (for example, dosprmpt orautoexec.bat) and choose Properties. From there choose Memory. Set theInitial Environment to the maximum allowed and click Apply. This should
increase the amount of environment space available.

Supported Compilers
On Windows. Real-Time Workshop has been tested with these compilers on

Windows.
Compiler

Versions

Borland5.2, 5.3, 5.4, 5.5, 5.6

Intel

7.1

LCC

Use the version of LCC shippedwith MATLAB.

Microsoft Visual C/C++

5.0, 6.0, 7.0

Watcom

10.6, 11.0 (see “Watcom” above)

Typically you must make modifications to your setup when a new version ofyour compiler is released. See the MathWorks home page,
http://www.mathworks.com, for up-to-date information on newer compilers.

1-14Installing Real-Time Workshop

On UNIX. On UNIX, the Real-Time Workshop build process uses the default
compiler. The cc compiler is the default on all platforms except SunOS, where
gcc is the default.

For further information, see Technical Note 1601, “What Compilers are
Supported?” at
http://www.mathworks.com/support/tech-notes/1600/1601.shtml.

Compiler Optimization Settings
In some very rare instances, due to compiler defects, compiler optimizations
applied to Real-Time Workshop generated code can cause the executable
program to produce incorrect results, even though the code itself is correct.
Real-Time Workshop uses the default optimization level for each supported
compiler. You can usually work around problems caused by compiler
optimizations by lowering the optimization level of the compiler, or turning off
optimizations. Refer to your compiler's documentation for information on how
to do this.

1-15

1 What Is Real-Time Workshop?

Real-Time Workshop Demos
A good way to familiarize yourself with Real-Time Workshop is by browsing
through its suite of demos, running the ones of interest, and then inspectingcode generated from these demo models. The demos illustrate many (but notall) Real-Time Workshop features.
To access the current set of demos for Real-Time Workshop, click the link below
or typertwdemosat the MATLAB prompt. You can also find Real-Time Workshop demos bynavigating to Real-Time Workshop, (found under Simulink) in the Demospane of the Help Navigator, and clicking the Feature Tour example.
Note that many of the Real-Time Workshop demos illustrate features of
Real-Time Workshop Embedded Coder, and are thus set up to generate code for
the ERT target. Should MATLAB find no license for Real-Time Workshop
Embedded Coder on your system, you can still run the demos, but all code
generated will default to the GRT target.

1-16

Help and Documentation

Help and Documentation
Real-Time Workshop software is shipped with this Getting Started guide.
Users of this book should be familiar with
• Using Simulink and Stateflow to create models/machines as block diagrams,
running such simulations in Simulink, and interpreting output in the
MATLAB workspace• High-level programming language concepts applied to real-time systems
While you do not need to program in C or other programming languages tocreate, test, and deploy real-time systems using Real-Time Workshop,
successful emulation and deployment of real-time systems involves working
familiarity with parameters and design constraints. The Real-Time Workshop
documentation assumes you have a basic understanding of real-time system
concepts, terminology, and environments. The documentation is available in
the following locations:• Online at http://www.mathworks.com• Through the MATLAB Help browser• As PDF documents that you can view online or print
This section includes the following topics:• “Online Documentation” on page 1-17—Where to find Help online (HTMLdocuments)• “Printing the Documentation” on page 1-18—Printable versions (PDF
documents)• “For Further Information” on page 1-18—A guide to major help topics

Online Documentation
Access to the online information for Real-Time Workshop is through MATLAB
or from the MathWorks Web site at http://www.mathworks.com/support/.
Click on the Documentation link.
To access the documentation with the MATLAB Help browser, use thefollowing procedure:

1-17

1 What Is Real-Time Workshop?

1 In the MATLAB window, click Desktop -> Help, Help -> Full productfamily help, or click the ? icon on the toolbar.

The Help browser window opens.
2 In the left pane, click the Real-Time Workshop book icon.

The Help browser displays the Real-Time Workshop Roadmap page in theright pane. Click on any link there, or click on the “+” sign to the left of thebook icon in the left pane to reveal the table of contents. When you do so, the“+” changes to a “-”, which hides the topics under it when you click on it.

Printing the Documentation
Real-Time Workshop ships with this printed manual. You can also download it
along with two other manuals as PDF files from the Real-Time Workshop Web
page at The MathWorks Web site:
http://www.mathworks.com/access/helpdesk/help/toolbox/rtw/rtw.shtml• Getting Started with Real-Time Workshop (rtw_gs.pdf)• Real-Time Workshop User’s Guide (rtw_ug.pdf)• Target Language Compiler Reference Guide(targetlanguagecompiler.pdf)• Real-Time Workshop Release Notes (rn.pdf)
The last two publications are not distributed in printed form. You are welcome
to print the PDF versions. When preparing to print, be aware that each manual
has more than 500 pages.

Related Products
The MathWorks provides other products that are especially relevant to thekinds of tasks you can perform with Real-Time Workshop, including manycustom targets. For information about them, visit the MathWorks Web Site.

For Further Information
The Real-Time Workshop User’s Guide documents, in detail, the capabilities of
Real-Time Workshop. For a topical overview of its contents, see “How Do I...”in the Real-Time Workshop User’s Guide documentation.

1-18

Help and Documentation

You can customize output from Real-Time Workshop at the block, target, andmakefile levels. For advanced uses, you may have to prepare or modify Target
Language Compiler files, as explained in the Target Language Compiler
documentation.

1-19

1 What Is Real-Time Workshop?

1-20

2
Building an Application
This chapter expands the high-level discussion of code generation and the build process given in
Chapter 1, “What Is Real-Time Workshop?.” It provides a foundation of understanding for tutorial
exercises in Chapter 3, “Working with Real-Time Workshop.”
Real-Time Workshop Workflow (p. 2-2)

Explains the typical workflow for applying Real-TimeWorkshop to the application development process

Automatic Program Building (p. 2-13)

Describes the flow of control for code generation

The Build Process (p. 2-15)

Describes the sequence of events that take place when
you click the Build button, including the files that theTarget Language Compiler uses and creates

2 Building an Application

Real-Time Workshop Workflow
The typical workflow for applying Real-Time Workshop to the application
development process involves the following steps:
1 Map your application requirements to available configuration options.
2 Adjust configuration options, as necessary.
3 Run the Model Advisor Tool.
4 If necessary, tune configuration options based on the Model Advisor report.
5 Generate code for your model.
6 Repeat steps 2 to 6 if necessary.
7 Build an executable program image.
8 Verify that the generated program produces results that are equivalent tothose of your model simulation.
9 Save the configuration and alternative ones with the model.

The following figure shows these steps in a flow diagram. Sections following
the figure discuss the steps in more detail.

2-2

Real-Time Workshop Workflow

Map Application Requirements
to Configuration Options

Adjust Configuration Settings

Run Model Advisor

Configuration
Requires
Tuning?

Yes

No
Generate CodeNo

Code OK?
Yes

Generate Code and Build
Executable Program

Verify Executable Program

No
Results Match
Simulation?
Yes
Name and save theConfiguration Set
Done

2-3

2 Building an Application

Mapping Application Requirements to
Configuration Options
The first step to applying Real-Time Workshop to the application
development process is to consider how your application requirements,
particularly with respect to debugging, traceability, efficiency, and safety,
map to code generation options available through the Simulink
Configuration Parameters dialog. The following screen display shows the
Real-Time Workshop pane of the Configuration Parameters dialog.

Parameters that you set in the various panes of the Configuration
Parameters dialog affect the behavior of a model in simulation and the code
generated for the model. Real-Time Workshop automatically adjusts which
configuration parameters are available and their default settings based onyour target selection. For example, the preceding dialog display shows default
settings for the Generic Real-Time (GRT) target. However, you should getfamiliar with the various parameters and be prepared to adjust settings to
optimize a configuration for your application.
As you review the parameters, consider questions such as the following:• What settings will help you debug your application?

2-4

Real-Time Workshop Workflow• What is the highest priority for your application — traceability, efficiency,
extra safety precaution, or some other criteria?
• What is the second highest priority?
• Can the priority at the start of the project differ from the priority required
for the end result? What tradeoffs can be made?
Once you have answered these questions, review the following table, whichsummarizes the impact of each configuration option on debugging,traceability, efficiency, and safety considerations, and indicates the default(“factory”) configuration settings for the Generic Real-Time (GRT) target. For
additional details, click the links in the Configuration Parameters column.

Note If you use a Real-Time Workshop Embedded Coder target, a specificembedded target, a Stateflow target, or fixed point blocks, you need toconsider the mapping of many other configuration parameters. For details,
see the Real-Time Workshop Embedded Coder documentation and any otherdocumentation specific to your target environment.

Mapping of Application Requirements to Configuration Parameters
Configuration
Parameter

DebuggingTraceability

Efficiency

SafetyPrecaution

Factory
Default

Stop time

No impact

No impact

No impact

No impact

10.

Type

No impact

No impact

No impact

No impact

Variable-step

Load from workspace

N/A

N/A

N/A

N/A

Clear

Save to workspace

Maybe

Maybe

Clear

No impact

Set

Save options

Maybe

Maybe

No impact

No impact

Set

SolverData Import/Export

2-5

2 Building an Application

Mapping of Application Requirements to Configuration Parameters (Continued)
Configuration
Parameter

DebuggingTraceability

Efficiency

SafetyPrecaution

Factory
Default

Block reduction
optimization

Clear

Clear

Set

No impact

Set

Implement logic
signals as Boolean
data (vs. double)

No impact

No impact

Set

No impact

Set

Inline parameters

Clear

Set

Set

No impact

Clear

Conditional input
branch execution

No impact

Set

Set

No impact

Set

Signal storage reuse

Clear

Clear

Set

No impact

Set

Application lifespan(days)

No impact

No impact

Finite value

Inf

Inf

Enable local block
outputs

Clear

No impact

Set

No impact

Set

Ignore integer
downcasts in foldexpressions

Clear

No impact

Set

Clear

Clear

Eliminatesuperfluous
temporary variables(Expression folding)Clear

No impact

Set

No impact

Set

Loop unrolling
thresholdNo impact

No impact>0

No impact

5

Reuse block outputs

Clear

Clear

Set

No impact

Set

Inline invariant
signals

Clear

Clear

Set

No impact

Set

Optimization

2-6

Real-Time Workshop Workflow

Mapping of Application Requirements to Configuration Parameters (Continued)
Configuration
Parameter

DebuggingTraceability

Efficiency

SafetyPrecaution

Factory
Default

No impact

No impact

Targetspecific

No impact

8, 16,
32, 32Set

Set

No impact

No impact

Clear

Hardware Implementation
Number of bits

Real-Time Workshop
Generate HTML
reportReal-Time Workshop: Comments
Include comments

Set

Set

No impact

No impact

Set

Simulink blockcomments

Set

Set

No impact

No impact

Set

Show eliminatedstatements

Set

Set

No impact

No impact

Clear

Verbose comments
for Simulink Global
storage class

Set

Set

No impact

No impact

Clear

>30

No impact

No impact

31

No impact

No impact

Set

Set

No impact

Set

No impact

ANSI-C

Real-Time Workshop: Symbols
Maximum identifier
lengthSet

Real-Time Workshop: Debug
Verbose builds

Set

Real-Time Workshop: Interface
Target floating point
math environment

No impact

2-7

2 Building an Application

Mapping of Application Requirements to Configuration Parameters (Continued)
Configuration
Parameter

DebuggingTraceability

Efficiency

SafetyPrecaution

Factory
Default

Utility function
generation

SharedSharedSharedNo impact

Auto*

MAT-file variablename modifier

No impact

No impact

No impact

No impactrt_* Backward compatibility with previous release.

Setting Configuration Options
Once you have mapped your application requirements to appropriate
configuration options settings, adjust the option settings accordingly. Using
the Default column in the table in “Mapping Application Requirements to
Configuration Options” on page 2-4, identify the configuration options youneed to modify. Then, open the Configuration Parameters dialog or Model
Explorer and make the necessary adjustments.
Tutorials in Chapter 3, “Working with Real-Time Workshop” guide you
through exercises that modify configuration option settings. For details on
the configuration options that pertain to code generation, see “CodeGeneration and the Build Process” in the Real-Time Workshop User’s Guide
documentation.

Running the Model Advisor
Before you generate code, it is good practice to run the Model Advisor. Basedon a list of options you select, this tool analyzes your model and its parametersettings, and generates a report that lists findings with advice on how tocorrect and improve the model and its configuration.
One way of starting the Model Advisor is to select Tools–>Model Advisor inyour model window. A new window appears listing specific diagnostics you
can selectively enable or disable. Some examples of the diagnostics follow:• Identify blocks that generate expensive saturation and rounding code
• Check optimization settings• Identify questionable software environment specifications

2-8

Real-Time Workshop Workflow

Although you can use the Model Advisor to improve model simulation, it isparticularly useful for identifying aspects of your model that limit code
efficiency or impede deployment of production code. The following figure
shows part of a sample Model Advisor report.

For more information on using the Model Advisor, see “Using the Model
Advisor” of the Real-Time Workshop User’s Guide documentation.

Generating CodeAfter fine tuning your model and its parameter settings, you are ready togenerate code. Typically, the first time through the process of applying
Real-Time Workshop for an application, you want to generate code without
going on to compile and link it into an executable program. Some reasons fordoing this include the following:

2-9

2 Building an Application• You want to inspect the generated code. Is Real-Time Workshop generating
what you expect?
• You need to integrate custom handwritten code.
• You want to experiment with configuration option settings.
You specify code generation only by selecting the Generate code only option
available on the Real-Time Workshop pane of the Configuration
Parameters dialog (thus changing the label of the Build button to Generatecode). Real-Time Workshop responds to clicking this button by analyzing theblock diagram that represents your model, generating C code, and placing theresulting files in a build directory within your current working directory.
After generating the code, inspect it. Is it what you expected? If not,determine what model and configuration changes you need to make, rerun
the Model Advisor, and regenerate the code. When you are satisfied with thegenerated code, build an executable program image, as explained in “Building
an Executable Program Image” on page 2-10.
For a more detailed discussion of the code generation process, see “Automatic
Program Building” on page 2-13 and “The Build Process” on page 2-15.For
details on the Generate code only option, see “Generate Code Only” in the
Real-Time Workshop User’s Guide documentation.

Building an Executable Program Image
When you are satisfied with the code Real-Time Workshop generates for yourmodel, build an executable image. If it is currently selected, you need to clear
the Generate code only option on the Real-Time Workshop pane of theConfiguration Parameters dialog. This changes the label of the Generate
code button back to Build. One way of initiating a build is to click the Build
button. Real-Time Workshop responds by
1 Generating the C code as explained in “Generating Code” on page 2-9.
2 Creating a customized makefile based on a template makefile for yourtarget of choice and placing the makefile in the build directory.
3 Instructing your system’s make utility to use the generated makefile tocompile the generated source code, link object files and libraries, andgenerate an executable program file called model or model.exe. The
executable image resides in your working directory.

2-10

Real-Time Workshop Workflow

For a more detailed discussion of the build process, see “Automatic Program
Building” on page 2-13 and “The Build Process” on page 2-15.

Verifying the Generated Results
Once you have an executable image, run the image and compare the results
to the results of your model’s simulation. You can do this by
1 Logging output data produced by simulation runs.
2 Logging output data produced by executable program runs.
3 Comparing the results of the simulation and executable program runs.

Does the output match? Are you able to explain any differences? Do you needto eliminate any differences? At this point, it may be necessary to revisit andpossibly fine-tune your block and configuration parameter settings.
For an example, see “Tutorial 3: Code Verification” on page 3–25.

Save the Model Configuration
When you close a model, you should save it to preserve your configuration
settings (unless you regard your recent changes as dispensable). If you would
like to maintain several alternative configurations for a model (e.g., GRT and
Rapid Simulation targets, Inline Parameters on/off, different solvers, etc.),
you can set up a configuration set for each set of configuration parametersand give it am identifying name. You can do this easily in Model Explorer. To
name and save a configuration,
1 Open Model Explorer while your model is still open, by selecting Model

Explorer from the View menu.
2 In the Model Hierarchy pane, click the + sign preceding the model nameto reveal its components.
3 Click the Configuration (active) node under the model name.

The Configuration Parameters pane appears on the far right.
4 In the Configuration Parameters pane, type a name you wish to give thecurrent configuration in the Name field.

2-11

2 Building an Application

5 Click Apply.

The name of the active configuration in the Model Hierarchy panechanges to the name you typed.
6 Save the model.

Adding and Copying Configuration Sets
You might want to save the model with more than one configuration so thatyou can instantly reconfigure it at a later time. To do this, you need to copy
the active configuration set to a new one, or add a new one, then modify andname the new configuration, as follows:
1 Open Model Explorer while your model is still open, by selecting Model

Explorer from the View menu.
2 In the Model Hierarchy pane, click the + sign preceding the model nameto reveal its components.
3 To add a new configuration set, while the model is selected in the Model

Hierarchy pane, select Configuration Set from the Add menu or click theyellow gear icon on the toolbar.
A new configuration set named Configuration appears in the Model
Hierarchy pane.
4 To copy an existing configuration set, right-click its name in the Model

Hierarchy pane and drag it to the + sign in front of the model name.

A new configuration set with a numeral (e.g., 1) appended to its nameappears lower in the Model Hierarchy pane.
5 Rename the new configuration to be more specific by selecting it andrepeating step 4 above.
6 Make the new configuration the active one by right-clicking it in the Model

Hierarchy pane and selecting Activate from the pop-up context menu.

The content of the Is Active field in the right pane changes from no to yes.
7 Save the model.

2-12Automatic Program Building

Automatic Program Building
Real-Time Workshop builds programs automatically for real-time
applications in a variety of host environments. Using the make utility,
Real-Time Workshop controls how it compiles and links the generated sourcecode.
The following figure illustrates the complete process. The shaded box
highlights portions of the process that Real-Time Workshop executes.

Simulink
Model
User-developed model andtemplate makefile

Automated build processYour
Template
Makefile

Configuration
Set parameterssystem.tmf

Generate
Code

Generate
Makefile

Model
Model
Code
Code
model.c

CustomMakefilecmodel.hhmodel_private.h...modelmake_rtw.m

model.mk

make –f mk
make -f model.mk
Executable C program

Programmodel.exe

2-13

2 Building an Application

A high-level M-file command controls the Real-Time Workshop build process.
By default, Real-Time Workshop issues the command make_rtw withappropriate options for most targets. You can customize this command byediting the contents of the Make command field in the Build process sectionof the Real-Time Workshop pane of the Configuration Parameters dialog.
Do not issue the make_rtw command from the MATLAB Command Window.
Use of that command in the Command Window is unpredictable and depends
on conditions such as whether the model is stand-alone, you have multiple
models open, a different make command has been specified, or the model
contains Model blocks.
Although the command may work for a stand-alone model, use of the
make_rtw command at the command line can be error-prone. For example, if
you have multiple models open, you need to make sure gcs is the model you

want to build. Also, some target environments supply a Make command in
the Configuration Parameters dialog that is not make_rtw. Finally, models
containing Model blocks do not build properly using make_rtw.
To build (or generate code for) a model as currently configured from the
MATLAB Command Window, use one of the following rtwbuild commands.
rtwbuild modelname
rtwbuild('modelname')

2-14

The Build Process

The Build Process
Real-Time Workshop generates C code only or generates the C code andproduces an executable image, depending on the level of processing you
choose. By default, a Build button appears on the Real-Time Workshop paneof the Configuration Parameters dialog. This button completes the entire
build process and an executable image results. If you select the Generate
code only check box to the left of the button, the button label changes toGenerate code.
When you click the Build or Generate code button, Real-Time Workshop
completes the following process.

Note If Real-Time Workshop detects code generation constraints for yourmodel, Real-Time Workshop issues warning or error messages.

1 Model Compilation. Real-Time Workshop analyzes your block diagram(and any models referenced by Model blocks) and compiles an intermediate
hierarchical representation in a file called model.rtw.
2 Code Generation. The Target Language Compiler reads model.rtw,

translates it to C code, and places the C file in a build directory within yourworking directory.
When you click Generate code, processing stops here.
3 Customized Makefile Generation. Real-Time Workshop constructs a

makefile from the appropriate target makefile template, and writes it in
the build directory.
4 Executable Program Generation. Your system’s make utility reads the

makefile to compile source code, link object files and libraries, andgenerate an executable image (called model or model.exe). The makefile
places the executable image in your working directory.
If you select Generate HTML report on the Real-Time Workshop pane,a MATLAB browser window displays a report when the build is done. The
report files occupy a directory called /html within the build directory. The

2-15

2 Building an Application

report contents vary depending on the target, but all reports featureclickable links to generated source files. The following display shows anexample of an HTML code generation report for a generic real-time (GRT)
target.

For more information, see “Generate HTML Report” in the Real-TimeWorkshop User’s Guide documentation. You can also view an HTML reportin Model Explorer. See the last part of “Tutorial 6: Generating Code for a
Referenced Model” on page 3-51 for details.
Details about each of the four steps in the process follow.

Model Compilation
The build process begins with Simulink compiling the block diagram. During
this stage, Simulink• Evaluates simulation and block parameters• Propagates signal widths and sample times• Determines the execution order of blocks within the model

2-16

The Build Process• Computes work vector sizes, such as those used by S-functions. (For more
information about work vectors, refer to the Simulink Writing S-Functions
documentation.)
When Simulink completes this processing, Real-Time Workshop reads yourmodel file (model.mdl) and compiles an intermediate representation of themodel. This intermediate description is stored, in a language-independent
format, in the ASCII file model.rtw. The model.rtw file is the input to thenext stage of the build process.
model.rtw files are similar in format to Simulink model (.mdl) files, but are
only used for automated code generation. For a general description of themodel.rtw file format, see “model.rtw File Contents” in the Target Language
Compiler (TLC) documentation.

Code Generation
During code generation, Real-Time Workshop uses the TLC and a supporting
TLC function library to transform the intermediate model description stored
in model.rtw into target-specific code.
The target language compiled by the TLC is an interpreted programming
language designed to convert a model description to code. The TLC executes
a TLC program comprising several target files (.tlc scripts). The TLC scripts
specify how to generate code from the model, using the model.rtw file as
input.
The TLC
1 Reads the model.rtw file.
2 Compiles and executes commands in a system target file.

The system target file is the entry point or main file. You select it fromthose available on the MATLAB path with the System target file browser
or you can type the name of any such file on your system prior to building.
3 Compiles and executes commands in block target files.

For each block in a Simulink model, there is a block target file thatspecifies how to translate that block into target-specific code.

2-17

2 Building an Application

Note Real-Time Workshop executes all user-written S-function target files,
but optionally executes block target files for Simulink blocks.

4 Writes a source code version of the Simulink block diagram.

Customized Makefile Generation
After generating the code, Real-Time Workshop generates a customized
makefile, model.mk. The generated makefile instructs the make system utility
to compile and link source code generated from the model, as well as any
required harness program, libraries, or user-provided modules.
Real-Time Workshop creates model.mk from a system template makefile,system.tmf (where system stands for the selected target name). The system
template makefile is designed for your target environment. You have theoption of modifying the template makefile to specify compilers, compiler
options, and additional information used during the creation of theexecutable.
Real-Time Workshop creates the model.mk file by copying the contents ofsystem.tmf and expanding lexical tokens (symbolic names) that describe
your model’s configuration.
Real-Time Workshop provides many system template makefiles, configured
for specific target environments and development systems. “The System
Target File Browser” in the Real-Time Workshop User’s Guide
documentation lists all template makefiles that are bundled with Real-TimeWorkshop.
You can fully customize your build process by modifying an existing template
makefile or providing your own template makefile.

Executable Program Generation
The following figure shows how Real-Time Workshop controls automatic
program building:

2-18

The Build Process

Click Build
Buttonmodel.c

Simulink
Model

Generate
Code

Template
Makefile

Generate
Makefile

CreateExecutable?

model.hmodel_private.h

CustomMakefilemodel.mk

No

Yes
Invokemake

Stop
During the final stage of processing, Real-Time Workshop invokes thegenerated make file, model.mk, which in turn compiles and links thegenerated code. To avoid unnecessary recompilation of C files, the make utility
performs date checking on the dependencies between the object and C files;
only out-of-date source files are compiled. Optionally, the make file candownload the resulting executable image to your target hardware.

2-19

2 Building an Application

This stage is optional, as illustrated by the control logic in the preceding
figure. You might choose to omit this stage, for example, if you are targetingan embedded microcontroller or a digital signal processing (DSP) board.
To omit this stage of processing, select the Generate code only option on the
Real-Time Workshop pane of the Configuration Parameters dialog. You
can then cross-compile your code and download it to your target hardware.
“Making an Executable” in the Real-Time Workshop User’s Guide
documentation discusses the options that control whether or not the build
creates an executable image.

2-20

The Build Process

Click Build
Buttonmodel.c

Simulink
Model

Generate
Code

Template
Makefile

Generate
Makefile

CreateExecutable?

model.hmodel_private.h

CustomMakefilemodel.mk

No

Yes
Invokemake

Stop

How Automatic Program Building Is Controlled

2-21

2 Building an Application

Files and Directories Created by the Build Process
The following sections discuss• “Files Created During Build Process” on page 2-22
• “Directories Used During the Build Process” on page 2-26

Files Created During Build ProcessThis section lists model.* files created during the code generation and build
process for the GRT and GRT malloc targets when used with stand-alone
models. Additional directories and files are created to support shared utilities
and model references (see “Building Subsystems and Working with
Referenced Models” in the Real-Time Workshop User’s Guide
documentation).
Real-Time Workshop derives many of the files from the model.mdl file you
create with Simulink. You can think of the model.mdl file as a very high-level
programming language source file.

Note Files generated by the Real-Time Workshop Embedded Coder are
packaged slightly differently. Depending on model architectures and code
generation options, Real-Time Workshop might generate other files.

Below is a directory listing for the F14 demo model, which is configured for
the GRT target.
F14_GRT_RTW\| f14.mk| rtw_proj.tmw| f14.bat| f14_targ_data_map.m| rtwtypes.h| f14_types.h| f14.h| f14.c| f14_private.h| rtmodel.h| f14_data.c| rt_nonfinite.h

2-22

The Build Process| rt_nonfinite.c| modelsources.txt| f14_dt.h|+---tlc| This directory contains TLC files generated during the build| process. These files are used to create the generated C source| and header files.
¦+---html| This directory contains generated HTML files used for the Code| Generation report.

Summary descriptions of the principle generated files follow:• model.rtw
An ASCII file, representing the “compiled model,” generated by the
Real-Time Workshop build process. This file is analogous to the object filecreated from a high-level language source program. By default, Real-TimeWorkshop deletes this file when the build process is complete. However,you can choose to retain the file for inspection.
• model.cC source code that corresponds to model.mdl and is generated by the Target
Language Compiler. This file contains- Include files model.h and model_private.h- All data except data placed in model_data.c- GRT wrapper functions MdlStart, MdlOutputs, MdlUpdate,
MdlInitializeSizes, MdlInitializeSampleTimes- Model registration code
- Algorithm code
• model.hDefines model data structures and a public interface to the model entry
points and data structures. Also provides an interface to the real-timemodel data structure (model_rtM) via accessor macros. model.h is included
by subsystem .c files in the model. It includes- Exported Simulink data symbols

2-23

2 Building an Application- Exported Stateflow machine parented data
- Model data structures, including rtM- Model entry point functions• model_private.h
Contains local define constants and local data required by the model andsubsystems. This file is included by the generated source files in the model.
You do not need to include model_private.h when interfacing
hand-written code to a model. It contains- Imported Simulink data symbols- Imported Stateflow machine parented data
- Stateflow entry points- Real-Time Workshop details (various macros, enums, and so forth thatare private to the code)• model_types.h
Provides forward declarations for the real-time model data structure andthe parameters data structure. These might be needed by function
declarations of reusable functions. model_types.h is included by all thegenerated header files in the model.
• model_data.c
A conditionally generated C source code file containing declarations for theparameters data structure and the constant block I/O data structure. If
these data structures are not used in the model, model_data.c is not
generated. Note that these structures are declared extern in model.h.
When present, this file contains- Constant block I/O parameters- Include files model.h and model_private.h- Constant parameters• subsystem.c
C source code for each noninlined nonvirtual subsystem or copy thereof
when the subsystem is configured to place code in a separate file.
• subsystem.h
Header file containing exported symbols for noninlined nonvirtualsubsystems. Analogous to model.h.

2-24

The Build Process• model.exe (on PC) or model (on UNIX), generated in current directory, notin build directory
Executable program file created under control of the make utility by yourdevelopment system (unless you have explicitly specified that Real-TimeWorkshop generate code only and skip the rest of the build process.
• model.mk
Customized makefile generated by the Real-Time Workshop build process.
This file builds an executable program file.
• rtmodel.hContains #include directives required by static main program modules
such as grt_main.c and grt_malloc_main.c. Since these modules are notcreated at code generation time, they include rt_model.h to accessmodel-specific data structures and entry points. If you create your own
main program module, take care to include rtmodel.h• rtwtypes.h
For GRT targets, a header file that includes tmwtypes.h andsimstruc_types.h. For Real-Time Workshop Embedded Coder ERT
targets, rtwtypes.h is optimized (pruned to reduce its size) based on build
settings and directly includes the defines, enumerations, and so on,contained in tmwtypes.h and simstruc_types.h.
• rt_nonfinite.c
C source file that declares and initializes global nonfinite values for inf,
minus inf and nan. Nonfinite comparison functions are also provided.
• rt_nonfinite.h
C header file that defines extern references to nonfinite variables andfunctions.
• rtw_proj.tmw
File generated by Real-Time Workshop for use by the make utility todetermine when to rebuild objects when the name of the current Real-TimeWorkshop project changes.
Optional files:• model_targ_data_map.m
M-file used by External Mode to initialize the external mode connection.

2-25

2 Building an Application• model_dt.h
C header file used for supporting External Mode. Declares structures that
contain data type and data type transition information for generated model
data structures.
• model_capi.h
An interface header file between the model source code and the generated
C-API. See “C-API for Interfacing with Signals and Parameters” in the
Real-Time Workshop User’s Guide documentation for more information.
• model_capi.c
C source file that contains data structures that describe the model’s signals
and parameters without using external mode. See “C-API for Interfacingwith Signals and Parameters” in the Real-Time Workshop User’s Guide
documentation for more information.
In addition, when you select the Generate HTML report option, Real-TimeWorkshop generates a set of .html files (one for each source file plus amodel_contents.html index file) in the /html subdirectory within your build
directory.
The above source files have dependency relationships, and there are
additional file dependencies which you may need to take into account. These
are described in “Generated Source Files and File Dependencies” in the
Real-Time Workshop User’s Guide documentation.

Directories Used During the Build Process
Real-Time Workshop places output files in three directories during the build
process:• The working directory
If you choose to generate an executable program file, Real-Time Workshop
writes the file model.exe (on PC) or model (on UNIX) to your working
directory.
• The build directory—model_target_rtw
A subdirectory within your working directory. The build directory name ismodel_target_rtw, where model is the name of the source model andtarget is the selected target type (for example, grt for the generic real-timetarget). The build directory stores generated source code and all other files
created during the build process (except the executable program file).

2-26

The Build Process• Project directory—slprj
A subdirectory within your working directory. When models referenced via
Model blocks are built for simulation or Real-Time Workshop code
generation, files are placed in slprj. The Real-Time Workshop Embedded
Coder has an option that places generated shared code in slprj without theuse of Model Reference. Subdirectories in slprj provide separate places for
simulation code, some Real-Time Workshop code, utility code shared
between models, and other files. Of particular importance to Real-TimeWorkshop users are- Model reference RTW target files
slprj/target/modelName/- MAT files used during code generation of Model Reference RTW target
and stand-alone code generationslprj/target/modelName/tmwinternal- Shared (fixed-point) utilities
slprj/target/_sharedutils
See “Working with Project Directories” on page 3-62 for additional
information on organizing your files with respect to project directories.
The build directory always contains the generated code modules model.c,model.h, and the generated makefile model.mk.
Depending on the target, code generation, and build options you select, thebuild directory might also include• model.rtw• Object files (.obj or .o)• Code modules generated from subsystems• HTML summary reports of files generated (in the /html subdirectory)• TLC profiler report files• Block I/O and parameter tuning information file (model_capi.c)• C-API code for parameters and signals• Real-Time Workshop project (model.tmw) files
For additional information about using project directories, see “Project
Directory Structure for Model Reference Targets” and “Supporting the2-27

2 Building an Application

Shared Utilities Directory in the Build Process” in the Real-Time Workshop
User’s Guide documentation.

2-28

The Build Process

2-29

2 Building an Application

2-30

3
Working with Real-TimeWorkshopThis chapter provides an overview of the ideas and technology behind Real-Time Workshop, andhands-on exercises to help you to get started generating code as quickly as possible. It includes thefollowing topics:
Basic Real-Time Workshop Concepts(p. 3-2)

Terms and definitions, such as host, target, code format,
makefile, and more, used in the documentation

Quick Start Tutorials (p. 3-7)

Hands-on exercises that demonstrate essential featuresof Real-Time Workshop

To get the maximum benefit from this chapter and subsequent ones, we recommend that you study
and work all the tutorials, in the order presented.

3 Working with Real-Time Workshop

Basic Real-Time Workshop Concepts
Even if you have experience in building real-time systems, you may find it
helpful to review the following descriptions to be sure of understanding thenomenclature that Real Time Workshop documentation uses. A more
extensive list of terms may be found in the Glossary.
The process of generating source code from Simulink models is shown in thefollowing diagram. The terms and concepts involved are described below.

Simulink
model.mdl

Real-Time Workshop

Real-Time Workshop Build
TLC program:model.rtw• System target file
• Block target files• Inlined S-function
target files

TargetLanguageCompiler• Target Language
Compiler function
library
Run-time interface
support files

model.cMakemodel.exe

Real-Time Workshop Code Generation Process

3-2

model.mk

Basic Real-Time Workshop Concepts

Target and Host
A target is an environment—hardware or operating system—on which yourgenerated code will run. The process of specifying this environment is called
targeting.
The process of generating target-specific code is controlled by a system target
file, a template makefile, and a make command. To select a desired target, you
can specify these items individually, or you can choose from a wide variety ofready-to-run configurations.
The host is the system you use to run MATLAB, Simulink, and Real-TimeWorkshop. Using the build tools on the host, you create code and an
executable that runs on your target system.

Available Target Configurations
Real-Time Workshop supports many target environments. These include
ready-to-run configurations and third-party targets. You can also develop
your own custom target.
For a complete list of bundled targets, with their associated system target
files and template makefiles, see “Available Targets” and “The System Target
File Browser” of the Real-Time Workshop User’s Guide documentation.

Code Formats
A code format specifies a software architecture, one that is often oriented to
optimizing code generation for specific applications.
When you choose a target configuration, you implicitly choose a code format.
Most targets built into Real-Time Workshop use the embedded C format. The
embedded C code format is a compact format designed for production code
generation. Its small code size, use of static memory, and simple callstructure make it optimal for embedded applications.
Some targets use the real-time code format. This format, less compact but
more flexible, is optimal for rapid prototyping applications. The GRT target,
which used real-time code format previously to Version 6, now uses embedded
C code format with a real-time format-compatible calling interface.
For a complete discussion of available code formats, see “Generated CodeFormats” of the Real-Time Workshop User’s Guide documentation.

3-3

3 Working with Real-Time Workshop

The Generic Real-Time Target
Real-Time Workshop provides a generic real-time development target. The
GRT target provides an environment for simulating fixed-step models insingle or multitasking mode. A program generated with the GRT target runs
your model, in simulated time, as a stand-alone program on your workstation.
The target supports external mode, allowing your application to compute
outputs and send them back to Simulink for you to view.
The GRT target allows you to perform code verification by logging system
outputs, states, and simulation time to a data file. The data file can then beloaded into the MATLAB workspace for analysis or comparison with theoutput of the original model.
The GRT target also provides a starting point for targeting custom hardware.
You can modify the GRT harness program, grt_main.c, to execute code
generated from your model at interrupt level under control of a real-timeclock.

Target Language Compiler Files
Real-Time Workshop generates source code for models and blocks throughthe Target Language Compiler, which reads script files (or TLC files) thatspecify the format and content of output source files. Two types of TLC files
are used:• A system target file, which describes how to generate code for a chosentarget, is the entry point for the TLC program that creates the executable.
• Block target files define how the code looks for each of the Simulink blocks
in your model.
System and block target files have the extension .tlc. By convention, asystem target file has a name corresponding to your target. For example,
grt.tlc is the system target file for the GRT target.
If you need to incorporate legacy code or maximize the efficiency of code formodels containing S-functions, you will need to prepare your own TLC files toaugment code generation for such models. These and other advanced uses of
TLC scripts are explained in the Target Language Compiler Reference Guide.

3-4

Basic Real-Time Workshop Concepts

Template Makefiles
Real-Time Workshop uses template makefiles to build an executable from thegenerated code.
The Real-Time Workshop build process creates a makefile from the template
makefile. Each line from the template makefile is copied into the makefile;tokens encountered during this process are expanded into the makefile.
The name of the makefile created by the build process is model.mk (wheremodel is the name of the Simulink model). The model.mk file is passed to a
make utility, which compiles and links an executable from a set of files.
By convention, a template makefile has an extension of .tmf and a namecorresponding to your target and compiler. For example, grt_vc.tmf is the
template makefile for building a generic real-time program under Visual
C/C++.
You specify system target files and template makefiles using the Real-TimeWorkshop pane of the Configuration Parameters dialog, either by typing
their filenames or choosing them with the Target File Browser. “Tutorial 1:
Building a Generic Real-Time Program” on page 3-9 introduces theseinterfaces. See “Target, Documentation, and Build Options” in the Real-TimeWorkshop User’s Guide for additional documentation.

The Build Process
A high-level M-file command controls the Real-Time Workshop build process.
The default command, used with most targets, is make_rtw. When you initiate
a build, Real-Time Workshop invokes make_rtw. The make_rtw command, inturn, invokes the Target Language Compiler and utilities such as make. The
build process consists of the following stages:
1 First, make_rtw compiles the block diagram and generates a model

description file, model.rtw.
2 Next, make_rtw invokes the Target Language Compiler to generatetarget-specific code, processing model.rtw as specified by the selected
system target file.
3 Next, make_rtw creates a makefile, model.mk, from the selected template

makefile.

3-5

3 Working with Real-Time Workshop

4 Finally, make is invoked. make compiles and links a program from thegenerated code, as instructed in the generated makefile.
“Automatic Program Building” on page 2-13 gives an overview of the build
process. “Simulation Parameters and Code Generation” in the Real-TimeWorkshop User’s Guide documentation expands on how model data affects
code generation.

Model Parameters and Code Generation
The simulation parameters of your model directly affect code generation andprogram building. For example, if your model is configured to stop execution
after 60 seconds, the program generated from your model will also run for 60
seconds.
Before you generate code and build an executable, you must verify that you
have set the model parameters correctly in the Configuration Parameters
dialog. See “Simulation Parameters and Code Generation” in the Real-TimeWorkshop User’s Guide documentation for more information. Real-Timeworkshop will refuse to generate code and issue diagnostics when certain
parameters (such as solver type) are set inappropriately. However, whenother parameters (such as hardware characteristics) have inappropriate
values, code generated by Real-Time Workshop can yield incorrect results.
Real-Time Workshop imposes certain requirements and restrictions on themodel from which code is generated. Some of these, for example the use ofvariable-step solvers, are target-specific.
The following sections in the Real-Time Workshop User’s Guide
documentation may help you understand restrictions on code generation that
may apply:• “Choosing a Code Format for Your Application” compares features that
Real-Time Workshop supports for different targets.
• “Parameters: Storage, Interfacing, and Tuning” describes how Real-TimeWorkshop structures parameter data.
• “C-API for Interfacing with Signals and Parameters” provides moreadvanced information on how to access parameter data in generated code.

3-6

Quick Start Tutorials

Quick Start Tutorials
This section provides hands-on experience with the code generation, program
building, data logging, code verification, and external mode capabilities of
Real-Time Workshop.
Shows how to generate C code from a“Tutorial 1: Building a
Generic Real-Time Program” Simulink demo model and build an executable
programon page 3-9“Tutorial 2: Data Logging”
on page 3-19

Explains how to modify the demonstration
program to save data in a MATLAB MAT-filefor plotting“Tutorial 3: Code
Verification” on page 3-25

Demonstrates how to verify a generated
program by comparing its output to that of
the original model under simulation“Tutorial 4: A First Look atGenerated Code” onpage 3-30

Examines code generated for a very simple
model, illustrating the effects of some of theReal-Time Workshop code generation options“Tutorial 5: Working with
External Mode Using GRT”
on page 3–39

Acquaints you with the basics of using
external mode on a single computer, anddemonstrates the value of external mode to
rapid prototyping“Tutorial 6: Generating Code Introduces generating code for models
for a Referenced Model” on referenced with Model blocks, and using
page 3-51
Model Explorer to browse code files
These tutorials assume basic familiarity with MATLAB and Simulink. You
should also read Chapter 2, “Building an Application” before proceeding.
The procedures for building, running, and testing your programs are almost
identical in UNIX and PC environments. The discussion notes differenceswhere applicable.
Make sure that a MATLAB compatible C compiler is installed on your systembefore proceeding with these tutorials. See “Supported Compilers” in the
Real-Time Workshop User’s Guide documentation and “Supported

3-7

3 Working with Real-Time Workshop

Compilers” on page 1-14 for more information on supported compilers andcompiler installation.

The f14 Demonstration Model
Tutorials 1 through 3 use a demonstration Simulink model, f14.mdl, fromthe matlabroot/toolbox/simulink/simdemos/aerospace directory. (Bydefault, this directory is on your MATLAB path; matlabroot is the location of
MATLAB on your system.) f14 is a model of a flight controller for thelongitudinal motion of a Grumman Aerospace F-14 aircraft. Activate the F-14
model by typing f14 at the MATLAB prompt. The diagram below displays the
top level of this model.

The model simulates the pilot’s stick input with a square wave having afrequency of 0.5 (radians per second) and an amplitude of ± 1. The system
outputs are the aircraft angle of attack and the G forces experienced by thepilot. The input and output signals are visually monitored by Scope blocks.

3-8Quick Start Tutorials

Tutorial 1: Building a Generic Real-Time ProgramThis tutorial walks through the process of generating C code and building an
executable program from the demonstration model. The resultant
stand-alone program runs on your workstation, independent of externaltiming and events.

Working and Build Directories
It is convenient to work with a local copy of the f14 model, stored in its own
directory, f14example. This discussion assumes that the f14example
directory resides on drive d:. Set up your working directory as follows:
1 Create the directory from the MATLAB command line by typing!mkdir d:\f14example (on PC)or!mkdir ~/f14example (on UNIX)
2 Make f14example your working directory (drive d: used as example).

cd d:/f14example
3 Open the f14 model.

f14

The model appears in the Simulink window.
4 From the File menu, choose Save As. You need to navigate to or to specify

your working directory. Save a copy of the f14 model as
d:/f14example/f14rtw.mdl.

During code generation, Real-Time Workshop creates a build directory withinyour working directory. The build directory name is model_target_rtw,
derived from the name of the source model and the chosen target. The build
directory stores generated source code and other files created during the build
process. You examine the build directory contents at the end of this tutorial.

3-93 Working with Real-Time Workshop

Note When a model contains Model blocks (which enable one Simulink
model to include others), special project directories are created in yourworking directory to organize code for referenced models. Project directories
exist alongside of Real-Time Workshop build directories, and are always
named /slprj. “Tutorial 6: Generating Code for a Referenced Model” onpage 3-51 describes navigating project directory structures in Model
Explorer.

Setting Program Parameters
To generate code correctly from the f14rtw model, you must change some ofthe simulation parameters. In particular, note that generic real-time (GRT)and most other targets require that the model specify a fixed-step solver.

Note Real-Time Workshop can generate code for models using variable-stepsolvers for Rapid Simulation (rsim) and S-function targets only. A Simulink
license is checked out when rsim targets execute. See “Licensing Protocols
for Simulink Solvers in Executables” in the Real-Time Workshop User’s
Guide documentation for details.

To set parameters, use the Configuration Parameters dialog as follows:
1 From the Simulation menu, choose Configuration Parameters. The

Configuration Parameters dialog opens.
2 Click the Solver tab and enter the following parameter values on the

Solver pane in their respective edit fields and pop-up menus:
Start Time: 0.0
Stop Time: 60
Solver options: set Type to Fixed-step. Select the ode5
(Dormand-Prince) solver algorithm.
Fixed step size: 0.05

3-10

Quick Start Tutorials

Mode: SingleTasking

The Solver pane with the modified parameter settings is shown below.
Note the tan background color of the controls you just changed; use thisvisual feedback to double-check that what you set is what you intended.
When you apply your changes, the background color reverts to white.

Note There are several ways in which can access simulation and code
generation parameters. The views of Configuration Parameters dialogs
shown in these tutorials are those you obtain from expanding theConfiguration node in the Contents pane of Model Explorer, and thenright-clicking on a subnode (such as Solver) and selecting Properties fromthe pop-up menu. The same dialogs appear in the Configuration
Parameters dialog box and the Model Explorer dialog pane.

3 Click Apply to register your changes.
4 Save the model. Simulation parameters persist with the model, for use in

future sessions.

3-11

3 Working with Real-Time Workshop

Selecting the Target Configuration
Note The steps in this section do not require you to make changes. They areincluded to help you familiarize yourself with the Real-Time Workshop userinterface. As you step through the dialogs, place the mouse pointer on any
item of interest to see a tooltip describing its function.

To specify the desired target configuration, you choose a system target file, atemplate makefile, and a make command.
In these exercises (and in most applications), you do not need to specify theseparameters individually. Here, you use the ready-to-run generic real-timetarget (GRT) configuration. The GRT target is designed to build a stand-alone
executable program that runs on your workstation.
To select the GRT target via the Configuration Parameters dialog,
1 Click the Real-Time Workshop configuration set node. The Real-TimeWorkshop dialog activates.
2 The Real-Time Workshop dialog has several tabs. Select General toactivate the pane that controls target selection.
3 Click the Browse button next to the RTW system target file field. This

opens the System Target File Browser, illustrated below. The browser
displays a list of all currently available target configurations. When you
select a target configuration, Real-Time Workshop automatically chooses
the appropriate system target file, template makefile, and make command.

3-12

Quick Start Tutorials

4 From the list of available configurations, select Generic Real-Time

Target (as shown above) and then click OK.

Note The System Target File Browser lists all system target files found on
the MATLAB path. Some of these may require additional licensed products(for example, Real-Time Workshop Embedded Coder) in order to use them.

The Real-Time Workshop pane displays the correct system target file(grt.tlc), template makefile (grt_default_tmf), and make command(make_rtw), as shown below:

3-13

3 Working with Real-Time Workshop

5 Select the Debug tab of the Real-Time Workshop dialog. The options

displayed here control build verbosity and debugging support, and arecommon to all target configurations. Make sure that all options are set totheir defaults, as shown below.

3-14Quick Start Tutorials

6 Select the Symbols tab of the Real-Time Workshop dialog. The options on

this pane control the look and feel of generated code; there is only one for
the GRT target, Maximum identifier length (the number of charactersallowed in variable and other symbol names). The default for this option is31, as shown below.

3-15

3 Working with Real-Time Workshop

7 Select the Comments tab of the Real-Time Workshop dialog. The options

displayed here control the types of comments included in generated code.
The default is to include only block-level comments, as shown below.

3-16Quick Start Tutorials

8 Make sure that the Generate code only option is not selected, and savethe model.

Building and Running the Program
The Real-Time Workshop build process generates C code from the model, andthen compiles and links the generated program to create an executable
image. To build and run the program,
1 Click the Build button in the Configuration Parameters dialog to start

the build process.
2 A number of messages concerning code generation and compilation appear

in the MATLAB Command Window. The initial messages are### Starting Real-Time Workshop build procedure for model:
f14rtw### Generating code into build directory: D:\Work\f14rtw_grt_rtw

3-17

3 Working with Real-Time Workshop

The content of many of the succeeding messages depends on your compiler
and operating system. The final message is### Successful completion of Real-Time Workshop build procedure
for model: f14rtw
3 The working directory now contains an executable, f14rtw.exe (on PC) or

f14rtw (on UNIX). In addition, a build directory, f14rtw_grt_rtw, hasbeen created in your working directory.
To observe the contents of the working directory after the build, type thedir command from the Command Window.
dir
.
..

f14rtw.exe
f14rtw.mdl

f14rtw_grt_rtw
slprj

4 To run the executable from the Command Window, type!f14rtw

The “!” character passes the command that follows it to the operating
system, which runs the stand-alone f14rtw program.
The program produces one line of output in the Command Window:**starting the model**No data is output.
5 Finally, to see the files created in the build directory, typedir f14rtw_grt_rtw

Contents of the Build Directory
The build process creates a build directory and names it model_target_rtw,
concatenating the name of the source model and the chosen target. In thisexample, the build directory is named f14rtw_grt_rtw.

3-18

Quick Start Tutorials

f14rtw_grt_rtw contains these generated source files:
f14rtw.cStand-alone C code that implements the model

f14rtw_data.c

Initial parameter values used by the model

rt_nonfinite.c

Function to initialize nonfinite types (Inf, NaN and-Inf)

f14rtw.h

An include header file containing definitions ofparameter and state variables

f14rtw_types.h

Forward declarations of data types used in the code

f14rtw_private.h

Header file containing common include definitions

rt_nonfinite.hImported declarations for nonfinite types

rtwtypes.h

Static include file for Simulink simstruct data types;
some embedded targets tailor this file to reduce
overhead, but GRT does not

rtmodel.h

Master header file for including generated code in thestatic main program (its name never changes, and it
simply includes f14rtw.h)

f14rtw.mk

Makefile generated from a template for the GRT
targetThe build directory also contains other files used in the build process, such as
the object (.obj) files, a batch control file (f14rtw.bat), and a marker file(rtw_proj.tmw).

Tutorial 2: Data Logging
The Real-Time Workshop MAT-file data logging facility enables a generated
program to save system states, outputs, and simulation time at each model
execution time step. The data is written to a MAT-file, named (by default)
model.mat, where model is the name of your model. In this tutorial, data
generated by the model f14rtw.mdl is logged to the file f14rtw.mat. Refer to“Tutorial 1: Building a Generic Real-Time Program” on page 3-9 for
instructions on setting up f14rtw.mdl in a working directory if you have notdone so already.

3-19

3 Working with Real-Time Workshop

To configure data logging, you use the Data Import/Export pane of theConfiguration Parameters dialog. The process is the same as configuring a
Simulink model to save output to the MATLAB workspace. In addition,
however, for each workspace return variable you define and enable,
Real-Time Workshop defines a parallel MAT-file variable. For example, if you
save simulation time to the variable tout, your generated program logs thesame data to a variable named rt_tout. You can change the prefix rt_ to a
suffix (_rt), or eliminate it entirely. You do this from the Interface tab of theReal-Time Workshop configuration dialog.

Note Simulink enables you to log signal data from anywhere in a model via
the Log signal data option in the Signal Properties dialog (accessed via
context menu by right-clicking on signal lines). Real-Time Workshop does
not incorporate this method of signal logging in generated code. To log
signals in generated code, you must either use the Data Import/Export
options described below or include To File or To Workspace blocks in yourmodel.

In this tutorial, you modify the f14rtw model such that the generated
program saves the simulation time and system outputs to the file
f14rtw.mat. Then you load the data into the MATLAB workspace and plot
simulation time against one of the outputs.

Part 1: Data Logging During Simulation
To use the data logging feature,
1 With the model f14rtw open, select Configuration Parameters from theSimulation menu (or type Ctrl+E).
2 Select the Data Import/Export tab of the Configuration Parameters

dialog. Its Save to workspace section lets you specify which outport datais to be saved to the workspace and what variable names to use for it.
3 Select the Time option. This tells Simulink to save time step data during

simulation as a variable named tout. You can enter a different name todistinguish different simulation runs (for example using different step
sizes), but allow the name to default for this exercise. Selecting Time

3-20

Quick Start Tutorials

enables Real-Time Workshop to generate code that logs the simulation
time to the MAT-file with a related name, as you will see below.
4 Select the Output option. This tells Simulink to save time step data during

simulation as a variable named yout. Selecting Output enables Real-TimeWorkshop to generate code that logs the root Output blocks (Angle of
Attack and Pilot G Force) to the MAT-file with a related name, as you willsee below.
Note The sort order of the yout array is based on the port number of the
Outport blocks, starting with 1. Angle of Attack and Pilot G Force are logged
to yout(:,1) and yout(:,2), respectively.

5 If any other options are enabled, clear them. Set Decimation to 1 andFormat to Array. The figure below shows how the dialog appears.

6 Click Apply to register your changes.
7 Open the Pilot G Force Scope block, and run the model by clicking on theStart button in the model’s toolbar. The resulting G Force scope display isshown below.

3-21

3 Working with Real-Time Workshop

8 Verify that the simulation time and outputs have been saved to theworkspace.
whos *out
Name
tout
yout

Size

Bytes

Class

601x1
601x2

4808
9616

double arraydouble array

Grand total is 1803 elements using 14424 bytes
9 Verify that Pilot G Force was correctly logged by plotting simulation time

versus that variable.
plot(tout,yout(:,2))

The resulting plot is shown below.

3-22Quick Start Tutorials

Part 2: Data Logging from Generated CodeIn the second part of the exercise, you build and run a Real-Time Workshop
executable of the f14rtw model which outputs a MAT-file containing thevariables that you logged in part 1. Even if you have already generated codefor the F14rtw model, code for it must be regenerated because you havechanged the model by enabling data logging. The steps below explain this.
Real-Time Workshop modifies identifiers for variables logged by Simulink inorder to avoid overwriting workspace data from simulation runs. You control
these modifications from the Configuration Parameters dialog:
1 From the Configuration Parameters dialog, choose the Real-TimeWorkshop configuration node and select its Interface tab.
2 In the Symbol section of the dialog, set the MAT-file variable namemodifier pop-up menu to _rt. This will add the suffix _rt to each variable
that you selected to be logged in part 1 of this exercise (tout, yout).
3 Deselect the Generate code only check box, if it is currently selected. The

dialog appears as below.

3-23

3 Working with Real-Time Workshop

4 Click Apply to register your changes.
5 Generate code and build an executable: Click the Build button, type

Ctrl+B, or select Build Model... from the Real-Time Workshop sub-menuof the Tools menu in the model window.
6 When the build concludes, run the executable with the command!f14rtw
7 The program now produces two message lines, indicating that the

MAT-file has been written.
** starting the model **** created f14rtw.mat **8 Load the MAT-file data created by the executable and look at theworkspace variables from simulation and the generated program:load f14rtw.mat
whos tout* yout*
Name
Size
tout
tout_rtyout
yout_rt

601x1
601x1
601x2
601x2

Bytes

Class

4808
4808
9616
9616

double arraydouble arraydouble arraydouble array

Grand total is 3606 elements using 28848 bytes

Note that all arrays have the same number of elements.
9 Observe that the variables tout_rt (time) and yout_rt (G Force and Angleof Attack) have been loaded from the file. Plot G Force as a function of time.
plot(tout_rt,yout_rt(:,2))This plot is identical to the plot you produced in step 9 of the first part ofthis exercise.

3-24

Quick Start Tutorials

Tutorial 3: Code Verification
In this tutorial, you verify the answers computed by code generated from thef14rtw model by comparing its outputs to the model outputs. You do this bycapturing data from runs of the Simulink model and the generated programand comparing their respective values.

Note To obtain a valid comparison between outputs of the model and thegenerated program, make sure that you have selected the same integration
scheme (fixed-step, ode5 (Dormand-Prince)) and the same step size (0.05)
for both the Simulink run and the Real-Time Workshop build process. Also,
make sure that the model is configured to save simulation time, as in
Tutorial 2.

Logging Signals via Scope Blocks
This example uses Scope blocks (rather than Outport blocks) to log both input
and output data. The f14rtw model should be configured as it was at the endof the previous exercise, “Tutorial 2: Data Logging” on page 3-19.
To configure the Scope blocks to log data,
1 Before proceeding with this tutorial, clear the workspace and reload themodel so that the proper workspace variables are declared and initialized:
clear
f14rtw
2 Open the Stick Input Scope block and click the Parameters button on the

toolbar of the Scope window. The Stick Input parameters dialog opens.
3 Select the Data History tab of the Scope Properties dialog.
4 Select the Save data to workspace option and enter the name of thevariable (Stick_input) that is to receive the scope data. The dialog
appears as shown below.

3-25

3 Working with Real-Time Workshop

The Stick Input signal to the scope block is logged to the array
Stick_input during simulation. The generated code logs the same signal
data to the MAT-file variable Stick_input_rt during a run of theexecutable program.
5 Click the Apply button.
6 Configure the Pilot G Force and Angle of Attack Scope blocks similarly,

using the variable names Pilot_G_force and Angle_of_attack.
7 Save the model.

Logging Simulation Data
The next step is to run the simulation and log the signal data from the Scope
blocks:1 Open the Stick Input, Pilot G Force, and Angle of Attack Scope blocks.
2 Run the model. The Scope blocks are displayed.

3-26

Quick Start Tutorials

3 Use the whos command to observe that the array variables Stick_input,

Pilot_G_force, and Angle_of_attack have been saved to the workspace.
4 Plot one or more of the logged variables against simulation time. For

example,plot(tout, Stick_input(:,2))

Logging Data from the Generated Program
Since you have modified the model, you must rebuild and run the f14rtw
executable in order to obtain a valid data file:
1 Set the variable name modifier to be used by Real-Time Workshop. From

the Configuration Parameters dialog, choose the Real-Time Workshop
configuration node and select its Interface tab.
2 In the Symbols section of the dialog, set the MAT-file variable namemodifier pop-up menu to rt_. This prefixes rt_ to each variable that you
selected to be logged in part 1 of this exercise.
3 Click Apply.
4 Generate code and build an executable: Click the Build button, type

Ctrl+B, or select Build Model from the Real-Time Workshop submenu of
the Tools menu in the model window. Status messages in the console
window track the build process.
5 When the build finishes, run the stand-alone program from MATLAB.

3-27

3 Working with Real-Time Workshop!f14rtw
The executing program writes the following messages to the console.
** starting the model **** created f14rtw.mat **6 Load the data file f14rtw.mat and observe the workspace variables.

load f14rtw
whos rt*Name
rt_Angle_of_attack
rt_Pilot_G_force
rt_Stick_input
rt_tout
rt_yout

Size

Bytes Class

601x2
601x2
601x2
601x1
601x2

9616
9616
9616
4808
9616

double arraydouble arraydouble arraydouble arraydouble array

Grand total is 5409 elements using 43272 bytes
7 Use MATLAB to plot three workspace variables created by the executing

program as a function of time.
figure('Name','Stick_input')plot(rt_tout,rt_Stick_input(:,2))
figure('Name','Pilot_G_force')
plot(rt_tout,rt_Pilot_G_force(:,2))
figure('Name','Angle_of_attack')plot(rt_tout,rt_Angle_of_attack(:,2))3-28

Quick Start Tutorials

Comparing Numerical Results of the Simulationand the Generated ProgramYour Simulink simulations and the generated code should produce nearly
identical output.
You have now obtained data from a Simulink run of the model, and from arun of the program generated from the model. It is a simple matter tocompare the f14rtw model output to the results achieved by Real-TimeWorkshop.
Comparing Angle_of_attack (simulation output) to rt_Angle_of_attack(generated program output) produces
max(abs(rt_Angle_of_attack-Angle_of_attack))
ans =
1.0e-015 *00.3331Comparing Pilot_G_force (simulation output) to rt_Pilot_G_force(generated program output) produces
max(abs(rt_Pilot_G_force-Pilot_G_force))
1.0e-013 *00.6395Overall agreement is within 10-13. The means of residuals are an order ofmagnitude smaller. This slight error can be caused by many factors, including• Different compiler optimizations• Statement ordering• Run-time libraries
For example, a function call such as sin(2.0) might return a slightly
different value, depending on which C library you are using.
For the same reasons, your comparison results might not be identical to thoseabove.

3-29

3 Working with Real-Time Workshop

Tutorial 4: A First Look at Generated CodeIn this tutorial, you examine code generated from a simple model to observe
the effects of some of the many code optimization features available inReal-Time Workshop.

Note You can view the code generated from this example using the
MATLAB editor. You can also view the code in the MATLAB Help browser if
you enable the Create HTML report option before generating code. See thefollowing section, “HTML Code Generation Reports” on page 3-37, for an
introduction to using the HTML report feature.

The source model, example.mdl, is shown below.

Setting Up the ModelFirst, create the model from Simulink library blocks, and set up basic
Simulink and Real-Time Workshop parameters as follows:
1 Create a directory, example_codegen, and make it your working directory:!mkdir example_codegen
cd example_codegen
2 Create a new model and save it as example.mdl.
3 Add Sine Wave, Gain, and Out1 blocks to your model and connect them asshown in the preceding diagram. Label the signals as shown.
4 From the Simulation menu, choose Configuration Parameters. The

Configuration Parameters dialog opens.

3-30

Quick Start Tutorials

5 Click the Solver tab and enter the following parameter values on the

Solver pane:
Solver options: set Type to Fixed-step. Select the ode5
(Dormand-Prince) solver algorithm.

Leave the other Solver pane parameters set to their default values.
6 Click Apply.
7 Click the Data Import/Export tab and make sure all check boxes arecleared.
8 Click Apply if you made any changes to the pane.
9 Click the Real-Time Workshop node in the Contents pane. Select theGenerate code only option at the bottom. This option causes Real-TimeWorkshop to generate code without invoking make to compile and link thecode. This is convenient for this exercise, as it focuses on the generated
source code. Note that the caption on the Build button changes toGenerate code.
Also, make sure that the default generic real-time (GRT) target is selected(System target file is grt.tlc).
10 Click Apply.
11 Save the model.

Generating Code Without Buffer Optimization
When the block I/O optimization feature is enabled, Real-Time Workshop
uses local storage for block outputs wherever possible. In this exercise, youdisable this option to see what the nonoptimized generated code looks like:1 Select the Optimization pane of the Configuration Parameters dialog.

Deselect the Signal storage reuse option, as shown below.

3-31

3 Working with Real-Time Workshop

2 Click Apply.
3 Click the Real-Time Workshop node and click the Generate code button.
4 Because the Generate code only option was selected, Real-TimeWorkshop does not invoke your make utility. The code generation process
ends with this set of messages:### Writing header file example_types.h.
### Writing header file example.h### Writing source file example.c### Writing header file example_private.h### Writing header file rtmodel.h.
### Writing source file example_data.c### Writing header file rt_nonfinite.h### Writing source file rt_nonfinite.c### TLC code generation complete.
### Creating project marker file: rtw_proj.tmw### Creating example.mk from N:\matlab\rtw\c\grt\grt_lcc.tmf### Successful completion of Real-Time Workshop build procedure
for model: example

3-32

Quick Start Tutorials

5 The generated code is in the build directory, example_grt_rtw. The file

example_grt_rtw\example.c contains the output computation for themodel. Open this file into the MATLAB editor:
edit example_grt_rtw\example.c
6 In example.c, find the function example_output near the top of the file.

The generated C code consists of procedures that implement the algorithms
defined by your Simulink block diagram. The execution engine calls theprocedures in proper succession as time moves forward. The modules that
implement the execution engine and other capabilities are referred tocollectively as the run-time interface modules. See the Real-Time Workshop
User’s Guide documentation for a complete discussion of how Real-TimeWorkshop interfaces and executes application, system-dependent, andsystem-independent modules, in each of the two styles of generated code.
In code generated for example, the generated example_output function
implements the actual algorithm for multiplying a sine wave by a gain. The
example_output function computes the model’s block outputs. The
run-time interface must call example_output at every time step.
With buffer optimizations turned off, example_output assigns uniquebuffers to each block output. These buffers (rtB.sin_out, rtB.gain_out)
are members of a global block I/O data structure, called in this code
example_B. and declared as follows:
BlockIO_example example_B;

The data type BlockIO_example is defined in example.h as follows:
typedef struct _BlockIO_example {real_T sin_out;
real_T gain_out;} BlockIO_example;

The output code (without comments) accesses fields of this global structure,
as is shown below:
static void example_output(int_T tid){
example_B.sin_out = example_P.SineWave_Amp *sin(example_P.SineWave_Freq * example_M->Timing.t[0] +3-33

3 Working with Real-Time Workshop

example_P.SineWave_Phase) + example_P.SineWave_Bias;
example_B.gain_out = example_B.sin_out * example_P.Gain_Gain;
example_Y.Out1 = example_B.gain_out;}
7 In GRT targets such as this, the function example_output is called by awrapper function, MdlOutputs. In example.c, find the function MdlOutputs
near the end. It looks like this:void MdlOutputs(int_T tid) {example_output(tid);}

Note In previous releases, MdlOutputs was the actual output function forcode generated by all GRT-configured models. It is now implemented as awrapper function to provide greater compatibility among different target
configurations.

In the steps below, you turn buffer optimizations on and observe how these
optimizations improve the code.

Generating Code with Buffer Optimization
Enable signal buffer optimizations and regenerate the code as follows:
1 Click the Optimization tab of the Configuration Parameters dialog.

Select the Signal storage reuse option.
2 Note that three controls become enabled in the Code generation section

below the check box, Enable local block outputs, Reuse block outputs
and Eliminate superfluous temporary variables (Expression folding).
Make sure that the first two options are selected, and Eliminate
superfluous temporary variables (Expression folding) is not selected,
as shown below.

3-34Quick Start Tutorials

You will observe the effects of expression folding later in this tutorial. Not
performing expression folding allows you to see the effects of the block
output optimizations.
3 Click Apply to apply the new settings.
4 Click Generate Code, or type Ctrl+B in the model window to generate

code again.
As before, Real-Time Workshop generates code in the example_grt_rtw
directory. Note that the previously generated code is overwritten.
5 Edit example_grt_rtw/example.c and examine the function

example_output.

With buffer optimizations enabled, the code in example_output reuses
temporary buffers with local scope, rtb_sin_out and rtb_gain_out, rather
than assigning global buffers to each input and output.
static void example_output(int_T tid){
real_T rtb_sin_out;
real_T rtb_gain_out;
rtb_sin_out = example_P.SineWave_Amp *3-35

3 Working with Real-Time Workshop

sin(example_P.SineWave_Freq * example_M->Timing.t[0] +example_P.SineWave_Phase) + example_P.SineWave_Bias;
rtb_gain_out = rtb_sin_out * example_P.Gain_Gain;
example_Y.Out1 = rtb_gain_out;}

This code is more efficient in terms of memory usage. The efficiency
improvement gained by enabling Enable local block outputs and Reuse
block outputs would be more significant in a large model with many signals.

A Further Optimization: Expression Folding
As a final optimization, you turn on expression folding, a code optimization
technique that minimizes the computation of intermediate results and theuse of temporary buffers or variables.
Enable expression folding and regenerate the code as follows:
1 On the Optimization pane of the Configuration Parameters dialog,

select the Eliminate superfluous temporary variables (Expression
folding) option.

2 Make sure that Signal storage reuse is still selected, as shown above.
3 Click Apply.

3-36

Quick Start Tutorials

4 Click the Generate code button.
5 As before, Real-Time Workshop generates code in the example_grt_rtw

directory.
6 Edit example_grt_rtw/example.c and examine the function

example_output.

In the previous examples, the Gain block computation was computed in a
separate code statement and the result was stored in a temporary location
before the final output computation.
With Eliminate superfluous temporary variables (Expression folding)selected, there is a subtle but significant difference in the generated code: thegain computation is incorporated (or “folded”) directly into the Outportcomputation, eliminating the temporary location and separate code
statement. This computation is on the last line of the example_output
function.
static void example_output(int_T tid){
real_T rtb_sin_out;
rtb_sin_out = example_P.SineWave_Amp *sin(example_P.SineWave_Freq * example_M->Timing.t[0] +example_P.SineWave_Phase) + example_P.SineWave_Bias;
example_Y.Out1 = rtb_sin_out * example_P.Gain_Gain;}

In many cases, expression folding can incorporate entire model computations
into a single, highly optimized line of code. Expression folding is turned on bydefault. Using this option will improve the efficiency of generated code.

HTML Code Generation Reports
When the Generate HTML report option under the Real-Time Workshop
General tab is selected, a navigable summary of source files is produced
when the model is built (see figure below).

3-37

3 Working with Real-Time Workshop

Enabling this option causes Real-Time Workshop to produce an HTML file foreach generated source file, plus a summary and an index file, in a directory
named /html within the build directory. If the Launch report after code
generation completes option (which is enabled by selecting GenerateHTML report) is also selected, the HTML summary and index are
automatically loaded into a new browser window and displayed.
In the HTML report, you can click links in the report to inspect source andinclude files, and view relevant documentation. In these reports,• Global variable instances are hyperlinked to their definitions, and• Block header comments in source files are hyperlinked back to the model;
clicking one of these causes the block that generated that section of code to
be highlighted (this feature requires Real-Time Workshop Embedded
Coder).
An HTML report for the example.mdl GRT target is shown below.

One useful feature of HTML reports is the link on the Summary page
identifying Configuration Settings at the Time of Code Generation. Clicking
this opens a read-only Configuration Parameters dialog box through which

3-38

Quick Start Tutorials

you can navigate to identify the settings of every option in place at the timethat the HTML report was generated.
You can refer to HTML reports at any time. To review an existing HTML
report after you have closed its window, use any HTML browser to open thefile html/model_codgen_rpt.html within your build directory.

Note The contents of HTML reports for different target types vary, andreports for models with subsystems feature additional information. You canalso view HTML-formatted files and text files for generated code and model
reference targets within Model Explorer. See See “Tutorial 6: Generating
Code for a Referenced Model” on page 3-51 for more information.

For further information on configuring and optimizing generated code,
consult these sections of the Real-Time Workshop User’s Guide
documentation:• “Code Generation and the Build Process” contains overviews of controlling
optimizations and other code generation options.
• “Optimizing the Model for Code Generation” for additional details on signal
reuse, expression folding, and other code optimization techniques.
• “Program Architecture” for details on the structure and execution ofmodel.c files.

Tutorial 5: Working with External Mode Using GRTThis section provides step-by-step instructions for getting started withexternal mode, a very useful environment for rapid prototyping. The tutorialconsists of four parts, each of which depends on completion of the preceding
ones, in order. The four parts correspond to the steps that you would follow insimulating, building, and tuning an actual real-time application:• Part 1: Setting Up the Model• Part 2: Building the Target Executable• Part 3: Running the External Mode Target Program• Part 4: Tuning Parameters

3-39

3 Working with Real-Time Workshop

The example presented uses the generic real-time target, and does not
require any hardware other than the computer on which you run Simulink
and Real-Time Workshop. The generated executable in this example runs on
the host computer under a separate process from MATLAB and Simulink.
The procedures for building, running, and testing your programs are almost
identical in UNIX and PC environments. The discussion notes differenceswhere applicable.
For a more thorough description of external mode, including a discussion of
all the options available, see “Using the External Mode User Interface” in the
Real-Time Workshop User’s Guide documentation.

Part 1: Setting Up the ModelIn this part of the tutorial, you create a simple model, ext_example, and a
directory called ext_mode_example to store the model and the generated
executable:
1 Create the directory from the MATLAB command line by typing

mkdir ext_mode_example
2 Make ext_mode_example your working directory:

cd ext_mode_example
3 Create a model in Simulink with a Sine Wave block for the input signal,

two Gain blocks in parallel, and two Scope blocks. The model is shown
below. Be sure to label the Gain and Scope blocks as shown, so that
subsequent steps will be clear to you.

3-40

Quick Start Tutorials

4 Define and assign two variables A and B in the MATLAB workspace asfollows:
A = 2; B = 3;
5 Open Gain block A and set its Gain parameter to the variable A as shown

below.

6 Similarly, open Gain block B and set its Gain parameter to the variable B.

When the target program is built and connected to Simulink in externalmode, you can download new gain values to the executing target programby assigning new values to workspace variables A and B, or by editing thevalues in the block parameter dialogs. You explore this in “Part 4: Tuning
Parameters” on page 3-50 of this tutorial.
7 Verify correct operation of the model. Open the Scope blocks and run themodel. When A = 2 and B = 3, the output looks like this.

3-41

3 Working with Real-Time Workshop

8 From the File menu, choose Save As. Save the model as ext_example.mdl.

Part 2: Building the Target Executable
In this section, you set up the model and code generation parameters required
for an external mode compatible target program. Then you generate code andbuild the target executable:
1 Open the Configuration Parameters dialog from the Simulation menu.

Click the Solver tab, set the Solver options Type to Fixed-step, andselect the discrete (no continuous states) solver algorithm. Set Fixed
step size to 0.01. Leave the other parameters at their default values. The
dialog appears below; note that after you click Apply, the controls youchanged will again have a white background color.

3-42Quick Start Tutorials

2 Click the Data Import/Export tab, and clear the Time and Output checkboxes. In this exercise, data is not logged to the workspace or to a MAT-file.
3 Click the Optimization tab. Make sure that the Inline parameters option(under the Code generation - parameters pane) is not selected. Althoughexternal mode supports inlined parameters, you will not explore this in
this exercise.
4 Click the Real-Time Workshop configuration node in the Select column.

By default, the generic real-time (GRT) target is selected. Below theReal-Time Workshop node (which you might need to double-click if it is
not expanded), select the Interface node.
5 In the Interface pane, select External Mode from the Interface menu in

the Data exchange section. This enables generation of external mode
support code and reveals two more sections of controls: Host/Target
interface and Memory management.
6 Set the Transport layer menu in the Host/Target interface section to

tcpip. The dialog now appears as follows.

3-43

3 Working with Real-Time Workshop

External mode supports communication via TCP/IP, serial, and custom
transport protocols. The MEX-file name field specifies the name of a
MEX-file that implements host and target communications on the hostside. The default for TCP/IP is ext_comm, a MEX-file provided by
Real-Time Workshop. You can override this default by supplying
appropriate files. See “Creating an External Mode Communication
Channel” in the Real-Time Workshop User’s Guide documentation for
details if you need to support other transport layers.
The MEX-file arguments field lets you specify arguments, such as a
TCP/IP server port number, to be passed to the external interface program.
Note that these arguments are specific to the external interface you areusing. For information on setting these arguments, see “MEX-File
Optional Arguments for TCP/IP Transport” and “MEX-File Optional
Arguments for Serial Transport” in the Real-Time Workshop User’s Guide
documentation.
This exercise uses the default arguments. Leave the MEX-file arguments
field blank.

3-44Quick Start Tutorials

7 Click Apply to save the Interface settings.
8 Save the model.
9 In the Real-Time Workshop pane, click Build to generate code and create

the target program. The content of subsequent messages depends on yourcompiler and operating system.The final message is### Successful completion of Real-Time Workshop build procedure
for model: ext_example

In the next section, you will run the ext_example executable and use
Simulink as an interactive front end to the running target program.

Part 3: Running the External Mode Target Program
The target executable, ext_example, is now in your working directory. In thissection, you run the target program and establish communication between
Simulink and the target.
The Signal & Triggering dialog (accessed via the External Mode Control
Panel) displays a list of all the blocks in your model that support external
mode signal monitoring and logging. The dialog also lets you configure thesignals that are viewed and how they are acquired and displayed. You can use
it to reconfigure signals while the target program runs.
In this exercise you observe and use the default settings of the External
Signal & Triggering dialog.
1 From the Tools menu of the block diagram, select External Mode Control

Panel, which lets you configure signal monitoring and data archiving. It

also lets you connect to the target program and start and stop execution of
the model code.

3-45

3 Working with Real-Time Workshop

The top three buttons are for use after the target program has started. The
two lower buttons open separate dialogs:- The Signal & triggering button opens the External Signal &Triggering dialog, which configures which signals are viewed and how
signals are acquired.
- The Data archiving button opens the External Data Archiving dialog.
Data archiving lets you save data sets generated by the target programfor future analysis. This example does not use data archiving. See “DataArchiving” in the Real-Time Workshop User’s Guide documentation for
more information.
2 In the External Mode Control Panel, click the Signal & triggering

button.
3 The External Signal & Triggering dialog opens. The default

configuration of the External Signal & Triggering dialog is designed toensure that all signals are selected for monitoring. The default
configuration also ensures that signal monitoring will begin as soon as thehost and target programs have connected. The figure below shows thedefault configuration for ext_example.

3-46Quick Start Tutorials

4 Make sure that the External Signal & Triggering dialog is set to thedefaults as shown:- Select all check box is selected. All signals in the Signal selection list
are marked with an X in the Block column.
- Trigger Source: manual- Trigger Mode: normal- Duration: 1000
- Delay: 0- Arm when connect to target: selected

3-47

3 Working with Real-Time Workshop

Click Close, and then close the External Mode Control Panel.
For information on the options mentioned above, see “External Signal
Uploading and Triggering” in the Real-Time Workshop User’s Guide
documentation.
5 To run the target program, you must open a command prompt window (onUNIX systems, an Xterm window). At the command prompt, change to the
ext_mode_example directory that you created in step 1. The target
program is in this directory.
cd ext_mode_example

Next, type the following command
extmode_example -tf inf -w

and press Return.

Note On Windows platforms, you can also use the “bang” command (!) in
the MATLAB console (note that the trailing ampersand is required):!extmode_example -tf inf -w &The target program begins execution. Note that the target program is in a
wait state, so there is no activity in the command prompt window.
The -tf switch overrides the stop time set for the model in Simulink. The
inf value directs the model to run indefinitely. The model code will run
until the target program receives a stop message from Simulink.
The -w switch instructs the target program to enter a wait state until it
receives a Start real-time code message from the host. This switch is
required if you want to view data from time step 0 of the target program
execution, or if you want to modify parameters before the target program
begins execution of model code.

3-48

Quick Start Tutorials

6 Open Scope blocks A and B. At this point, no signals are visible on thescopes. When you connect Simulink to the target program and begin model
execution, the signals generated by the target program will be visible on
the scope displays.
7 The model itself must be in external mode before communication between

the model and the target program can begin. To enable external mode,
select External from the simulation mode pull-down menu located on theright side of the toolbar of the Simulink window. Alternatively, you canselect External from the Simulation menu.
8 Reopen the External Mode Control Panel and click Connect. Thisinitiates a handshake between Simulink and the target program. When
Simulink and the target are connected, the Start real-time code button
becomes enabled, and the label of the Connect button changes to
Disconnect.
9 Click the Start real-time code button. The outputs of Gain blocks A and

B are displayed on the two scopes in your model. With A = 2 and B = 3,
the output looks like this.

Having established communication between Simulink and the running target
program, you can tune block parameters in Simulink and observe the effects
the parameter changes have on the target program. You do this in the next
section.

3-49

3 Working with Real-Time Workshop

Part 4: Tuning Parameters
You can change the gain factor of either Gain block by assigning a new value
to the variables A or B in the MATLAB workspace. When you change blockparameter values in the workspace during a simulation, you must explicitly
update the block diagram with these changes. When the block diagram is
updated, the new values are downloaded to the target program. To tune thevariables A and B,
1 In the MATLAB Command Window, assign new values to both variables,for example:
A = 0.5;B = 3.5;
2 Activate the extmode_example model window. Select Update Diagramfrom the Edit menu, or press the Ctrl+D keys. As soon as Simulink has
updated the block parameters, the new gain values are downloaded to thetarget program, and the effect of the gain change becomes visible on thescopes.
You can also enter gain values directly into the Gain blocks. To do this,
3 Open the block dialog for Gain block A or B in the model.
4 Enter a new numerical value for the gain and click Apply. As soon as you

click Apply, the new value is downloaded to the target program and theeffect of the gain change becomes visible on the scope.
Similarly, you can change the frequency, amplitude, or phase of the sine
wave signal by opening the block dialog for the Sine Wave block andentering a new numerical value in the appropriate field.
Note, however, that you cannot change the sample time of the Sine Wave
block. Block sample times are part of the structural definition of the modeland are part of the generated code. Therefore, if you want to change a block
sample time, you must stop the external mode simulation, reset the block’s
sample time, and rebuild the executable.
5 To simultaneously disconnect host/target communication and end

execution of the target program, pull down the Simulation menu andselect Stop real-time code. You can also do this from the External ModeControl Panel.

3-50

Quick Start Tutorials

Tutorial 6: Generating Code for a Referenced
Model
The Model block, introduced in Version 6 of Simulink, enables an existing
Simulink model to be used as a block in another model. When a model
contains one or more Model blocks, we call it a top model. Models represented
by model blocks are called referenced models in that context.
Model blocks are particularly useful for large-scale modeling applications.
They work by generating code and creating a binary file for each referenced
model, then executing the binary during simulation. Real-Time Workshop
generates code for referenced models in a slightly different way than for top
models and stand-alone models, and generates different code than Simulink
does when it simulates them. Follow this tutorial to learn how Simulink andReal-Time Workshop handle model blocks.
In this exercise you create a subsystem in an existing model, convert it to amodel, call it from the top model via a Model block, and generate code for bothmodels. You accomplish much of this automatically with a demo function
called sl_convert_to_model_reference. You also explore the generated codeand the project directory using the Model Explorer.

Part 1: Create and Configure A Subsystem Within the vdp ModelIn the first part of this exercise, you define a subsystem for the vdp demo
model, set configuration parameters for the model and use thesl_convert_to_model_reference function to convert it into two new models— the top model (vdptop) and a referenced model containing the subsystem
you created (vdpsub):1 In MATLAB, create a new working directory wherever you want to workand cd into it:
mkdir tutorial6
cd tutorial6
2 Open the vdp demo model:

vdp
3 Drag a box around the three blocks on the left to select them, as shown

below.

3-51

3 Working with Real-Time Workshop

4 Right-click any of the three highlighted blocks and select Create

Subsystem from the pop-up context menu. You can also select Create
Subsystem from the Edit menu or type Ctrl+G instead of right-clicking.
5 If the new Subsystem block is not where you want it, move it to a preferred

location. Rename the block vdpmult.
6 Right-click the vdpmult block and select SubSystem Parameters.

A Block Parameters dialog appears.
7 In the Block Parameters dialog, select the Treat as atomic unit checkbox, click Apply, as shown below, and then click OK to dismiss the dialog.

3-52

Quick Start Tutorials

The border of the vdpmult subsystem thickens to indicate that it is now
atomic. An atomic subsystem executes as a unit rather than having its
blocks executed at different stages during simulation. This makes it
possible to abstract subsystems as stand-alone models and as functions ingenerated code.
The block diagram now looks like this.

3-53

3 Working with Real-Time Workshop

8 Open the Configuration Parameters dialog from the Simulation menu orby typing Ctrl+E.
The next four steps bypass certain model reference error checks, tominimize the number of times code must be generated later on.
9 In the Select pane, select Solver. In the Dialog pane, change the Solver

Type to Fixed-step and click Apply. Fixed-step solvers must be used
when generating code, although referenced models can use different
solvers than top models.
10 In the Select pane, click Optimization, and then select Inline

parameters.
11 In the Select pane, click Data Integrity (under Diagnostics). Change thediagnostic setting for Signal resolution control to Use local settings,
and click Apply.
12 In the Select pane, select the top-level Model Referencing node (not the

one underneath Real-Time Workshop). Change the setting for Rebuild
options to If any changes in known dependencies detected, and click
Apply.
13 Click OK to close the Configuration Parameters dialog.
14 Choose File->Save as, and navigate to your working directory. Save themodel as vdptop there, and then close it.

Part 2: Convert the Model to Use Model Reference
In this portion of the exercise, you transform the vdptop model into two newmodels: a top-level model and a referenced model for the vdpmult subsystem.
You do this using an M-function provided as a demo. You can run the demo
by typingmdlref_conversionscript

The function that converts models with subsystems to new models is named
sl_convert_to_model_reference. To learn how this function is used, you
can type
help sl_convert_to_model_reference

3-54Quick Start Tutorials

In this exercise you only supply the first two calling arguments (a model
name and a target directory) and no return arguments:
1 Run the conversion utility by typing at the MATLAB prompt

sl_convert_to_model_reference('vdptop','.')

This converts the vdptop model and places the resulting files in the current
directory. The converter prints a number of progress messages to theconsole, and when successful, terminates withans =1

Note that the model being converted need not be open. The files in yourworking directory now consist of the following.
vdptop.mdl

The modified vdp model you saved

vdptop_converted.mdl

Top-level model created by the M-function that
contains a Model block where the vdpmult
subsystem was

vdpmult.mdl

Model created for the vdpmult subsystem

vdpmult_msf.dll

Static library file (on Windows) that executes
when the vdptop model calls what wasformerly the vdpmult subsystem/slprjProject directory for generated model referencecode

2 Type vdptop_converted to open the converted top-level model. Open the

Scope if it is not visible, and click Start or choose Start from theSimulation menu. The model calls the vdpmult_msf simulation target tosimulate. The model and its output look like this.

3-55

3 Working with Real-Time Workshop

Code for model reference simulation targets is placed in the slprj/sim
subdirectory. Generated code for GRT, ERT, and other Real-TimeWorkshop targets is placed in slprj subdirectories named for thosetargets. You will inspect some model reference code later in this exercise.
For more information on project directories, see “Working with Project
Directories” on page 3–62.

Part 3: Generate Model Reference Code for a GRT Target
The sl_convert_to_model_reference M-function took care of creating themodel and the simulation target files for the vdpmult subsystem. In this partof the exercise, you generate code for that model and the vdptop model, andrun the executable you create:
1 Verify that you are still working in the tutorial6 directory.
2 If the model vdptop_converted is not open, open it. Make sure it is theactive window.
3 Choose Configuration Parameters from the Simulation menu or type

Ctrl+E.

The Configuration Parameters dialog for vdptop_converted opens.
4 Select Data Import/Export. Select Time: and Output: in the Save toworkspace section, then click Apply. The dialog looks like this.

3-56

Quick Start Tutorials

This instructs the vdptop_converted model (and later its executable) to
log time and output data to MAT-files for each time step.
5 Generate GRT code (the default) and an executable for the top model andthe referenced model. To start the build process, do one of the following:- Select the Real-Time Workshop configuration parameter pane and click
Build,- Choose Real-Time Workshop->Build Model from the Model’s Tools
menu, or- Type Ctrl+B.
After Real-Time Workshop generates and compiles code. The current
directory now contains two new files:
vdptop_converted.exe

The executable created by Real-TimeWorkshop/vdptop_converted_grt_rtw

The Real-Time Workshop build
directory, containing generated codefor the top model

Real-Time Workshop also generated GRT code for the referenced model,
and placed it in the slprj directory.

3-57

3 Working with Real-Time Workshop

6 Use the Model Explorer to inspect the newly created build directory,

vdptop_converted_grt_rtw, in your current directory. Choose Model

Explorer from the View menu.
7 In Model Explorer’s Model Hierarchy pane, expand the node for the

vdptop_converted model.
8 Click the plus sign in front of the node named Code for vdptop_converted

to expand the node.
9 Click the Top Model node that appears directly under the Code for

vdptop_converted node.

A list of generated code files for vdptop_converted appears in theContents pane. The files consist of
vdptop_converted.c
vdptop_converted_data.c
rtmodel.h
vdptop_converted_types.h
vdptop_converted.h
vdptop_converted_private.h
vdptop_converted.mk

You can browse code in any of these files by selecting a file of interest in
the Contents pane. The code for the file you select appears in the Dialog
pane, to the right. The picture below illustrates viewing code for
vdptop_converted.c.

3-58Quick Start Tutorials

To view a model’s generated code in Model Explorer, the model must be
open. To open a file in a text editor, click a filename, and then click thehyperlink that appears in the gray area at the top of the Dialog pane.
10 Examine code for vdpmult.mdl. In the Model Hierarchy pane of Model

Explorer, right-click the Model block icon labeled vdpmult (vdpmult) andselect Open Model 'vdpmult' from the menu that appears.
The block diagram for vdpmult opens in a separate window, and a newnode named vdpmult appears in the Model Hierarchy pane. The model
looks like this.

3-59

3 Working with Real-Time Workshop

11 A Model Explorer node named Code for vdpmult also appears under thenode Code for vdptop_converted. Expand this node by clicking its plus
sign, and then select vdpmult below it. Model Explorer now shows the files
for the referenced model (which are in the /slprj/grt directory).

12 Click vdpmult.c in the Contents pane to view the model’s output andinitialization functions in the Dialog pane. Here is the code for the vdpmult
output function.

3-60

Quick Start Tutorials/* Output and update for referenced model: 'vdpmult'*/
void mr_vdpmult(const real_T *rtu_0, const real_T *rtu_1,
real_T *rty_0, RT_MODEL_vdpmult *vdpmult_M){/* local block i/o variables *//* Gain: '<Root>/Mu' incorporates:* Fcn: '<Root>/Fcn'* Product: '<Root>/Product'*/(*rty_0) = (1.0 - (*rtu_0) * (*rtu_0)) * (*rtu_1);/* Update absolute time for base rate */if(!(++vdpmult_M->Timing.clockTick0))++vdpmult_M->Timing.clockTickH0;}

Note the function’s prefix, mr_; this indicates that it comes from areferenced model, which also uses inlined parameters. Here is generated
GRT code for the vdpmult subsystem in the vdptop model; the RTW
system code property has been set to Reusable function.
/* Output and update for atomic system: '<Root>/vdpmult' */void vdptop_vdpmult(real_T rtu_In1, real_T rtu_In2,
rtB_vdptop_vdpmult *localB){/* local block i/o variables *//* Gain: '<S1>/Mu' incorporates:* Fcn: '<S1>/Fcn'* Product: '<S1>/Product'*/
localB->Mu = (1.0 - rtu_In1 * rtu_In1) * rtu_In2;}

The reusable function is prefixed with the model name. You can modify theconstruction of such identifiers when using ERT and ERT-derived targets.

3-61

3 Working with Real-Time Workshop

Working with Project Directories
When you view generated code in Model Explorer, the files listed in theContents pane can exist either in a build directory or a project directory.
Model reference project directories (always rooted under slprj), like build
directories, are created in your current working directory, and this implies
certain constraints on when and where model reference targets are built, andhow they are accessed.
The models referenced by Model blocks can be stored anywhere. A given top
model can include models stored on different file systems and directories. The
same is not true for the simulation targets derived from these models; undermost circumstances, all models referenced by a given top model must be set
up to simulate and generate model reference target code in a single project
directory. The top and referenced models can exist anywhere on your path,but the project directory is assumed to exist in your current directory.
This means that, if you reference the same model from several top models,each stored in a different directory, you must either• Always work in the same directory and be sure that the models are on yourpath
• Allow separate project directories, simulation targets, and Real-TimeWorkshop targets to be generated in each directory in which you work
The files in such multiple project directories will generally be quite
redundant. Therefore, to avoid regenerating code for referenced models moretimes than necessary, you might want to choose a specific working directoryand remain in it for all sessions.
As model reference code generated for Real-Time Workshop targets as well as
for simulation targets is placed in project directories, the same considerations
as above apply even if one is generating target applications only. That is, code
for all models referenced from a given model ends up being generated in thesame project directory, even if it is generated for different targets and atdifferent times.

3-62

Quick Start Tutorials

3-633 Working with Real-Time Workshop

3-64Glossary
application
modulesWith respect to Real-Time Workshop program architecture, these arecollections of programs that implement functions carried out by thesystem-dependent, system-independent, and application components.

atomicsubsystem

Subsystem whose blocks are executed as a unit before moving on. Conditionally
executed subsystems are atomic, and atomic subsystems are nonvirtual.
Unconditionally executed subsystems are virtual by default, but can be
designated as atomic. Real-Time Workshop can generate reusable code only for
nonvirtual subsystems.

base sample rate

Fundamental sample time of a model; in practice, limited by the fastest rate at
which a processor’s timer can generate interrupts. All sample times must be
integer multiples of the base rate.

block I/O
structure(model_B)

Global data structure for storing block output signals. The number of block
output signals is the sum of the widths of the data output ports of all nonvirtual
blocks in your model. By default, Simulink and Real-Time Workshop try to
reduce the size of the model_B structure by reusing the entries in the model_B
structure and making other entries local variables.

block target file

File that describes how a specific Simulink block is to be transformed to alanguage such as C, based on the block’s description in the Real-TimeWorkshop file (model.rtw). Typically, there is one block target file for each
Simulink block.

code reuse

Optimization whereby code generated for identical nonvirtual subsystems iscollapsed into one function that is called for each subsystem instance withappropriate parameters. Code reuse, along with expression folding, candramatically reduce the amount of generated code.

configuration

Set of attributes for a model which defines parameters governing how a model
simulates and generates code. A model can have one or more such configuration
sets, and users can switch between them to change code generation targets or
to modify the behavior of models in other ways.

configuration
component

Named element of a configuration set. Configuration components encapsulatesettings associated with the Solver, Data Import/Export, Optimization,
Diagnostics, Hardware Implementation, Model Referencing, andReal-Time Workshop panes in the Configuration Parameters dialog. A
component may contain sub-components.

embeddedreal-time (ERT)targetTarget configuration that generates model code for execution on an
independent embedded real-time system. Requires Real-Time Workshop
Embedded Coder.

Glossary-1

expression
folding

Code optimization technique that minimizes the computation of intermediate
results at block outputs and the storage of such results in temporary buffers orvariables. It can dramatically improve the efficiency of generated code,achieving results that compare favorably with hand-optimized code.

file extensions

The table below lists the file extensions associated with Simulink, the Target
Language Compiler, and Real-Time Workshop.

generic
real-time (GRT)
targetGlossary-2

Extension

Created by

Description.cTarget Language
Compiler

The generated C code.hTarget Language
Compiler

C include header file used by the .c
program.mdl

Simulink

Contains structures associated with
Simulink block diagrams.mkReal-Time Workshop

Makefile specific to your model thatis derived from the template makefile.rtw

Real-Time Workshop

Intermediate compilation(model.rtw) of a .mdl file used ingenerating C code

.tlc

The MathWorks andReal-Time Workshop
users

Target Language Compiler script
files that Real-Time Workshop uses
to generate code for targets andblocks.tmf

Supplied with
Real-Time Workshop

Template makefiles.tmw

Real-Time Workshop

Project marker file inside a build
directory that identifies the date andproduct version of generated code

Target configuration that generates model code for a real-time system, with theresulting code executed on your workstation. (Note that execution is not tied toa real-time clock.) You can use GRT as a starting point for targeting custom
hardware.

Glossary

host system

Computer system on which you create and may compile your real-time
application. Also referred to as emulation hardware.

inlineGenerally, this means to place something directly in the generated source code.
You can inline parameters and S-functions using Real-Time Workshop and theTarget Language Compiler.

inlinedparameters(Target Language Compiler Boolean global variable: InlineParameters) The
numerical values of the block parameters are hard-coded into the generated
code. Advantages include faster execution and less memory use, but you lose
the ability to change the block parameter values at run-time.

inlinedS-function

An S-function can be inlined into the generated code by implementing it as a.tlc file. The code for this S-function is placed in the generated model code
itself. In contrast, noninlined S-functions require a function call to an
S-function residing in an external MEX-file.

interrupt
service routine(ISR)

Piece of code that your processor executes when an external event, such as atimer, occurs.

loop rolling(Target Language Compiler global variable: RollThreshold) Depending on theblock's operation and the width of the input/output ports, the generated codeuses a for statement (rolled code) instead of repeating identical lines of code
(flat code) over the signal width.

make

Utility to maintain, update, and regenerate related programs and files. The
commands to be executed are placed in a makefile.

makefiles

Files that contain a collection of commands that allow groups of programs,
object files, libraries, etc., to interact. Makefiles are executed by yourdevelopment system’s make utility.

model.rtw

Intermediate record file into which Real-Time Workshop compiles the blocks,
signals, states, and parameters a model, which the Target Language Compiler
reads to generate code to represent the model.

multitasking

Process by which a microprocessor schedules the handling of multiple tasks. In
generated code, the number of tasks is equal to the number of sample times inyour model. See also pseudomultitasking.

noninlined
S-function

In the context of Real-Time Workshop, this is any C-MEX S-function that is not
implemented using a customized .tlc file. If you create a C-MEX S-function as

Glossary-3

part of a Simulink model, it is by default noninlined unless you write your own.tlc file that inlines it.
nonreal-time

Simulation environment of a block diagram provided for high-speed simulationof your model. Execution is not tied to a real-time clock.

nonvirtual block

Any block that performs some algorithm, such as a Gain block. Real-TimeWorkshop generates code for all nonvirtual blocks, either inline or as separate
functions and files, as directed by users.

pseudomultitasking

On processors that do not offer multitasking support, you can perform
pseudomultitasking by scheduling events on a fixed time-sharing basis.

real-time model
data structure

Real-Time Workshop encapsulates information about the root model in thereal-time model data structure, often abbreviated as rtM. rtM contains global
information related to timing, solvers, and logging, and model data such as
inputs, outputs, states, and parameters.

real-time system

Computer that processes real-world events as they happen, under theconstraint of a real-time clock, and that can implement algorithms in dedicatedhardware. Examples include mobile telephones, test and measurement
devices, and avionic and automotive control systems.

Real-Time
Workshop target

Set of code files generated by Real-Time Workshop for a standard or custom
target, specified by a Real-Time Workshop configuration component. Thesesource files can be built into an executable program that will run
independently of Simulink. See also simulation target, configuration.

run-timeinterface

Wrapper around the generated code that can be built into a stand-alone
executable. The run-time interface consists of routines to move the time
forward, save logged variables at the appropriate time steps, etc. The run-time
interface is responsible for managing the execution of the real-time program
created from your Simulink block diagram.

S-function

Customized Simulink block written in C, Fortran, or M-code. Real-TimeWorkshop can target C-code S-functions as is or users can inline C-code
S-functions by preparing TLC scripts for them.

simstruct

Simulink data structure and associated application program interface (API)that enables S-functions to communicate with other entities in models.
Simstructs are included in code generated by Real-Time Workshop for
noninlined S-functions.

Glossary-4

Glossary

simulation
targetSet of code files generated for a model which is referenced by a Model block.
Simulation target code is generated into /slprj/sim project directory in theworking directory. Also an executable library compiled from these codes that
implements a Model block. See also Real-Time Workshop Target.

singletasking

Mode in which a model runs in one task, regardless of the number of sample
rates it contains.

stiffness

Property of a problem that forces a numerical method, in one or more intervalsof integration, to use a step length that is excessively small in relation to thesmoothness of the exact solution in that interval.

system target
file

Entry point to the Target Language Compiler program, used to transform theReal-Time Workshop file into target-specific code.

target file

File that is compiled and executed by the Target Language Compiler. The blockand system target TLC files used specify how to transform the Real-TimeWorkshop file (model.rtw) into target-specific code.

TargetLanguageCompiler (TLC)

Program that compiles and executes system and target files by translating amodel.rtw file into a target language by means of TLC scripts and template
makefiles.

TargetLanguageCompiler
program

One or more TLC script files that describe how to convert a model.rtw file into
generated code. There is one TLC file for the target, plus one for each built-in
block. Users can provide their own TLC files in order to inline S-functions or to
wrap existing user code.

target system

Specific or generic computer system on which your real-time application isintended to execute. Also referred to as embedded hardware.

targeting

Process of creating software modules appropriate for execution on your target
system.

task identifier(tid)

In generated code, each sample rate in a multirate model is assigned a task
identifier (tid). The tid is used by the model output and update routines tocontrol the portion of your model that should execute at a given time step.
Single-rate systems ignore the tid. See also base sample rate.

templatemakefile

Line-for-line makefile used by a make utility. Real-Time Workshop converts
the template makefile to a makefile by copying the contents of the template
makefile (usually system.tmf) to a makefile (usually system.mk) replacing
tokens describing your model’s configuration.

Glossary-5

virtual block

Connection or graphical block, for example a Mux block, that has noalgorithmic functionality. Virtual blocks incur no real-time overhead as no codeis generated for them.

work vector

Data structures for saving internal states or similar information, accessible toblocks that may require such work areas. These include state work (rtDWork),real work (rtRWork), integer work (rtIWork), and pointer work (rtPWork)structures. For example, the Memory block uses a real work element for eachsignal.

Glossary-6

IndexB
block target file 2-17
build directory
contents of 2-27
f14 example 3-18
naming convention 2-26
build process
steps in 2-15

Ccode format
definition of 3-3
code generation
tutorial 3-30
code verification
tutorial 3-25
compilers
optimization settings 1-15
supported on UNIX 1-15
supported on Windows 1-14

D
data logging
from generated code 3-27
tutorial 3-19
via Scope blocks
example 3-25
directories
build 3-9
working 3-9
documentation
online 1-17
printing 1-18

E
external modebuilding executable 3-42
control panel 3-45
model setup 3-40
parameter tuning 3-50
running executable 3-45
tutorial 3-39

F
files
generated See generated files

G
generated files 2-22
model (UNIX executable) 2-25
model.c 2-23
model.exe (PC executable) 2-25
model.h 2-23
model.mdl 2-22
model.mk 2-25
model.rtw 2-23
model_capi.c 2-26
model_capi.h 2-26
model_data.c 2-24
model_dt.h 2-26
model_private.h 2-24
model_targ_data_map.m 2-25
model_types.h 2-24
rt_nonfinite.c 2-25
rt_nonfinite.h 2-25
rtmodel.h 2-25
rtw_proj.tmw 2-25
rtwtypes.h 2-25

Index-1

Indexsubsystem.c 2-24

Rsubsystem.h 2-24

Real-Time Workshop
basic concepts 3-2
capabilities and benefits 1-3
components and features 1-2
demos 1-16
extensible make process 1-5
installing 1-11
integration with Simulink 1-4
model-based debugging support 1-4
software development with 1-6
third-party compiler support 1-12
related products 1-18
run-time interface modules 3-33

generic real-time (GRT) target 3-4
tutorial 3-9H
host
and target 3-3

Mmake utility 2-13
components 3-3
MAT-files
loading 3-28
MATLAB 1-2
model explorer
viewing code in 3-58
model reference
code generation for 3-56
model referencing
tutorial 3-51
model.rtw filelocation of 2-26

S
Simulink 1-2
code generator 1-3
subsystems
converting to referenced models 3-54
treating as atomic units 3-52
system target file 2-17

TO
optimizations
expression folding 3-36
signal storage reuse 3-34

Pparametersand code generation 3-6
setting correctly 3-10

Index-2

targetavailable configurations 3-3
generic real-time See generic real-time (GRT)
targettarget fileblock 2-17
system 2-17
Target Language Compiler
block target file 3-4
function library 2-17
generation of code by 2-17

Indexsystem target file 3-4
TLC scripts 2-17
template makefile
introduction to 3-5
tutorials
building generic real-time program 3-9
code generation 3-30
code verification 3-25
data logging 3-19
external mode 3-39
model referencing 3-51

W
working directory 3-9

Index-3

IndexIndex-4