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

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. This greatly simplifies debugging of any aspect of an embedded application, whether it be a task, an interrupt service routine, or the kernel itself.

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, because it avoids 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.

This 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. Given the incremental loading capabilities of Tornado, it is quite common to configure the target with the agent linked into the run-time and stored in ROM. When started, the target server automatically initializes the symbol table from the host-resident image of the target run-time system. 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 or from the UNIX command line (or 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 C. Tornado Tools Reference.

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.

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.