Tornado is an integrated environment for software cross-development. It provides an efficient way to develop real-time and embedded applications with minimal intrusion on the target system. Tornado consists of the following elements:

• VxWorks, a high-performance real-time operating system.

• Application-building tools (compilers and associated programs).

• A development environment that facilitates managing and building projects, establishing and managing host-target communication, and running, debugging, and monitoring VxWorks applications.

The Tornado interactive development tools include:

• The launcher, an integrated target-management utility.

• A project management facility.

• Integrated C and C++ compilers and make.

• The browser, a collection of visualization aids to monitor the target system.

• CrossWind, a graphically enhanced source-level debugger.

• WindSh, a C-language command shell that controls the target.

• An integrated version of the VxWorks target simulator, VxSim.

• An integrated version of the WindView logic analyzer for the target simulator.

The Tornado environment is designed to provide this full range of features regardless of whether the target is resource-rich or resource-constrained. Tornado facilities execute primarily on a host system, with shared access to a host-based dynamic linker and symbol table for a remote target system. Figure 1-1 illustrates the relationships between the principal interactive host components of Tornado and the target system. Communication between the host tools and VxWorks is mediated by the target server and target agent.

The run-time system (often called simply the run-time) is the code that is intended for the final application, as distinguished from the complete Tornado cross-development environment. The run-time includes the real-time kernel, and typically also includes some selection of VxWorks library code as well as application-specific code. It does not usually include the target agent, although in some cases the target agent can be included to provide field debugging.

With Tornado, the cycle between developing an idea and observing its implementation is minimized. Fast incremental downloads of application code are linked dynamically with the VxWorks operating system and are thus available for symbolic interaction with minimal delay.

The Tornado cross-development environment ensures the smallest possible difference between the target system during development and the system after deployment. This is accomplished by segregating most development facilities on the host system, while providing minimally intrusive access to the target. The facilities of the run-time and the development environment are as independent of each other as possible, regardless of the scale of the target application. You can use the cross-development host to manage project files, to edit, compile, link, and store real-time code, and to configure the VxWorks operating system. Application modules in C or C++ are compiled with the Tornado cross-compiler. These application modules can draw on the VxWorks run-time libraries to accelerate application development. You can also run and debug real-time code on the target while under host-system control.

The hardware in a typical development environment includes one or more networked development host systems and one or more embedded target systems. A number of alternatives exist for connecting the target system to the host, but usually the connection is either an Ethernet or a serial link. If hardware or hardware-specific code is not initially available, the integrated VxSim target simulator can be used to begin application development.

A typical host development system is equipped with large amounts of RAM and disk space, backup media, printers, and other peripherals. In contrast, a typical target system has only the resources required by the real-time application, and perhaps some small amount of additional resources for testing and debugging.

A fundamental advantage of the Tornado environment is that the application modules do not need to be linked with the run-time system libraries or even with each other. Tornado loads the relocatable object modules directly, using the symbol tables in each module to resolve external symbol references dynamically. In Symbol table resolution is done by the target server (which executes on the host).

Tornado minimizes object-module sizes during development because there is no requirement to link the application fully. This shortens the development cycle because less data is downloaded, thus shortening the development cycle. Even partially completed modules can be downloaded for incremental testing and debugging. The host-resident Tornado shell and debugger can be used interactively to invoke and test either individual application routines or complete tasks.

Tornado maintains a complete host-resident symbol table for the target. This symbol table is incremental: the server incorporates symbols as it downloads each object module. You can examine variables, call subroutines, spawn tasks, disassemble code in memory, set breakpoints, trace subroutine calls, and so on, all using the original symbolic names.

In addition, the Tornado development environment includes the CrossWind debugger, which allows developers to view and debug applications in the original source code. Setting breakpoints, single-stepping, examining structures, and so on, is all done at the source level, using a convenient graphical interface.

The complete VxWorks operating-system environment is included in Tornado. This includes a multitasking kernel that uses an interrupt-driven, priority-based task scheduling algorithm. Run-time facilities include POSIX interfaces, intertask communication, extensive networking, file system support, and many other features.

Target-based tools analogous to some of the Tornado tools are included as well: a target-resident command shell, symbol table, and dynamic linker. In some situations the target-resident tools are appropriate, or even required, for a final application.

Tornado integrates the various aspects of VxWorks programming into a single environment for developing and debugging VxWorks applications. Tornado allows developers to organize, write, and compile applications on the host system; and then download, run, and debug them on the target. This section summarizes the major features of Tornado tools.

The launcher lets you start, manage, and monitor target servers, and connects the remaining interactive Tornado tools to the target servers of your choice. When you select a particular target server, the launcher shows information about the hardware and software environment on the target, as well as monitoring and reporting on what Tornado tools are currently attached to that target. You can reserve target servers for your own use with the launcher, or allow others to use them as well.

In many ways the launcher is the central Tornado control panel. Besides providing a convenient starting point to run the other tools, the launcher can also:

• Aid in the installation of additional Tornado components.

• Provide access to Wind River publications on the Internet.

• Help you prepare and transmit support requests to the customer support group at Wind River.

The launcher is described in 3. Launcher.

The Tornado project facility simplifies organizing, configuring, and building VxWorks applications. It includes graphical configuration of the build environment (including compiler flags), as well as graphical configuration of VxWorks (with dependency and size analysis). The project facility also provides for basic integration with common configuration management tools such as ClearCase.

The project facility is described in 4. Projects.

Tornado includes the GNU compiler for C and C++ programs, as well as a collection of supporting tools that provide a complete development tool chain:

• cpp, the C preprocessor

• gcc, the C and C++ compiler

• make, the program-building automation tool

• ld, the programmable static linker

• as, the portable assembler

• binary utilities

These tools are supported, commercial versions of the GNU tools originally developed by the Free Software Foundation (FSF). The Tornado project facility provides a GUI for the GNU tools that is powerful and easy to use.

For more information, see 4. Projects, GNU ToolKit User's Guide, and GNU Make User's Guide.

In addition, the Diab compiler for C and C++, available as an optional product, is fully integrated with Tornado. For more information, see 4. Projects, 5. Command Line Configuration and Build, and the Diab C/C++ Compiler User's Guide for your target architecture.

WindSh is a host-resident command shell that provides interactive access from the host to all run-time facilities. The shell can interpret and execute almost all C-language expressions. It supports C++, including demangling to allow developers to refer to symbols in the same form as used by the original C++ source code. The Tornado shell also includes a complete Tcl interpreter.

The shell can be used to call run-time system functions, call any application function, examine and set application variables, create new variables, examine and modify memory, and even perform general calculations with all C operators. The shell also provides the essential symbolic debugging capabilities, including breakpoints, single-stepping, a symbolic disassembler, and stack checking.

The shell interpreter maintains a command history and permits command-line editing. The shell can redirect standard input and standard output, including input and output to the virtual I/O channels supported by the target agent.

The shell is described in 7. Shell.

The remote source-level debugger, CrossWind, is an extended version of the GNU source-level debugger (GDB). The most visible extension to GDB is a straightforward graphical interface. CrossWind also includes a comprehensive Tcl scripting interface that allows you to create sophisticated macros or extensions for your own debugging requirements. For maximum flexibility, the debugger console window synthesizes both the GDB command-line interface and the facilities of WindSh, the Tornado shell.

From your development host, you can use CrossWind to do the following:

• Spawn and debug tasks on the target system.

• Attach to already-running tasks, whether spawned from your application, from a shell, or from the debugger itself.

• Use breakpoints and other debugging features at either the application level or the system level.

• View your application code as C or C++ source, as assembly-level code, or in a mixed mode that shows both.

The debugger is described in 9. Debugger. Also see the GDB User's Guide.

The Tornado browser is a system-object viewer, a graphical companion to the Tornado shell. The browser provides display facilities to monitor the state of the target system, including the following:

• Summaries of active tasks (classified as system tasks or application tasks).

• The state of particular tasks, including register usage, priority, and other attributes.

• Comparative CPU usage by the entire collection of tasks.

• Stack consumption by all tasks.

• Memory allocation.

• Summary of modules linked dynamically into the run-time system.

• Structure of any loaded object module.

• Operating-system objects such as semaphores, message queues, memory partitions, and watchdog timers.

The browser is described in 8. Browser.

WindView is the Tornado logic analyzer for real-time software. It is a dynamic visualization tool that provides information about context switches, and the events that lead to them, as well as information about instrumented objects.

Tornado includes an integrated version of WindView designed solely for use with the VxSim target simulator. WindView is available as an optional product for all supported target architectures.

WindView is described in the WindView User's Guide.

The VxSim target simulator is a port of VxWorks to the host system that simulates a target operating system. No target hardware is required. The target simulator facilitates learning Tornado usage and embedded systems development. More significantly, it provides an independent environment for developers to work on parts of applications that do not depend on hardware-specific code (BSPs) and target hardware.

Tornado includes an integrated version of the target simulator that runs as a single instance per user, without networking support. Optional networking products such as SNMP are not available for this version.

The VxSim full simulator is available as an optional product. It supports multiple-instance use, networking, and most other optional products.

See the Tornado Getting Started Guide for a introductory discussion of target simulator usage, and 4. Projects for information about its use as a development tool.

The elements of Tornado described in this section provide the link between the host and target development environments:

• The target agent is a scalable component of VxWorks that communicates with the target server on the host system.

• The target server connects Tornado tools such as the shell and debugger with the target agent.

• The Tornado registry provides access to target servers, and may run on any host on a network.

On the target, all Tornado tools are represented by the target agent. The target agent is a compact implementation of the core services necessary to respond to requests from the Tornado tools. The agent responds to requests transmitted by the target server, and replies with the results. These requests include memory transactions, notification services for breakpoints and other target events, virtual I/O support, and task control.

The agent synthesizes two modes of target control: task mode (addressing the target at application level) and system mode (system-wide control, including ISR debugging). The agent can execute in either mode and switches between them on demand.

The agent is independent of the run-time operating system, interfacing with run-time services indirectly so that it can take advantage of kernel features when they are present, but without requiring them. The agent's driver interface is also independent of the run-time, avoiding the VxWorks I/O system. Drivers for the agent are raw drivers that can operate in either a polling or an interrupt-driven mode. A polling driver is required to support system-level breakpoints.

Run-time independence means that the target agent can execute before the kernel is running. This feature is valuable for the early stages of porting VxWorks to a new target platform.

A key function of the agent is to service the requests of the host-resident object-module loader. If the agent is linked into the run-time and stored in ROM. The target server automatically initializes the symbol table from the host-resident image of the target run-time system as it starts. From this point on, all downloads are incremental in nature, greatly reducing download time.

The agent itself is scalable; you can choose what features to include or exclude. This permits the creation of final-production configurations that still allow field testing, even when very little memory can be dedicated to activities beyond the application's purpose.

The target server runs on the host, and connects the Tornado tools to the target agent. There is one server for each target; all host tools access the target through this server, whose function is to satisfy the tool requests by breaking each request into the necessary transactions with the target agent. The target server manages the details of whatever connection method to the target is required, so that each tool need not be concerned with host-to-target transport mechanisms.

In some cases, the server passes a tool's service request directly to the target agent. In other cases, requests can be fulfilled entirely within the target server on the host. For example, when a target-memory read hits a memory region already cached in the target server, no actual host-to-target transaction is needed.

The target server also allocates target memory from a pool dedicated to the host tools, and manages the target's symbol table on the host. This permits the server to do most of the work of dynamic linking--address resolution--on the host system, before downloading a new module to the target.

A target server need not be on the same host as the Tornado tools, as long as the tools have network access to the host where the target server is running.

Target servers can be started from the Tornado launcher, from the UNIX command line, or from scripts. See 2.7 Connecting a Tornado Target Server for a discussion of starting a server from the UNIX command line, and see 3.5 Managing Target Servers for details on using graphical facilities in the launcher. For reference information on target servers, see the tgtsvr entry in in Help>Manuals Contents>Tornado Reference/Tornado Tools.

Tornado provides a central target server registry that allows you to select a target server by a convenient name. The registry associates a target server's name with the network address needed to connect with that target server. You can see the registry indirectly through the list of available targets. The Tornado registry need not run on the same host as your tools, as long as it is accessible on the network.

To help keep server names unique over a network of interacting hosts, target-server names have the form targetName@host, where targetName is a target-server name selected by the user who launches a server (with the network name of the target as a default). The registry rejects registration attempts for names that are already in use.

It is recommended that a single registry be used at a development site, to allow access to all targets on the network. To ensure that the registry starts up automatically in the event of a server reboot, it should be invoked from a UNIX system initialization file. A registry should never be killed; without a registry, target servers cannot be named, and no Tornado tool can connect to a target.

For more information, see 2.2 Setting up the Tornado Registry.

Virtual I/O is a service provided jointly by the target agent and target server. It consists of an arbitrary number of logical devices (on the VxWorks end) that convey application input or output through standard C-language I/O calls, using the same communication link as other agent-server transactions.

This mechanism allows developers to use standard C routines for I/O even in environments where the only communication channel is already in use to connect the target with the Tornado development tools.

From the point of view of a VxWorks application, a standard I/O channel is an ordinary character device with a name like /vio/0, /vio/1, and so on. It is managed using the same VxWorks calls that apply to other character devices, as described in the VxWorks Programmer's Guide: I/O System. This is also the developer's point of view while working in the Tornado shell.

On the host side, virtual I/O is connected to the shell or to the target server console, which is a window on the host where the target server is running. See Target-Server Configuration Options for information about how to configure a target server with a virtual console.

Wind River is committed to meeting the needs of its customers. As part of that commitment, Wind River provides a variety of services, including training courses and contact with customer support engineers, along with a Web site containing the latest advisories, FAQ lists, known problems lists, and other valuable information resources.