Tornado provides the optimal cross-development environment by ensuring the smallest possible difference between the target system during development and after deployment. This is accomplished by segregating the vast majority of the development facilities on the host system, while providing precise yet minimally intrusive access to the target. For all practical purposes, the facilities of the run-time and the development environment are independent of each other, regardless of the scale of the target application.

With Tornado, you can use the cross-development host to manage project files, to edit, compile, link, and store real-time code, to configure the VxWorks operating system, as well as to run and debug real-time code on the target while under host-system control. To understand this environment more clearly, it is useful to outline the typical development process.

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 serial link. If hardware or hardware-specific code is not initially available, the integrated VxWorks target simulator can be used to begin application development.

A typical host development system is fully 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. The target may include no more than a CPU with on-chip RAM and a serial I/O channel (although connections with higher throughput are generally desirable).

Application modules in C or C++ are compiled with the cross-compiler provided as part of Tornado. These application modules can draw on the VxWorks run-time libraries to accelerate application development. 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. Instead, Tornado can load the relocatable object modules directly, using the symbol tables in each object module to resolve external symbol references dynamically. In Tornado, this symbol table resolution is done by the target server (which executes on the host).

With Tornado, object-module sizes are considerably smaller during development, in contrast with other environments. This is because there is no requirement to link the application fully. This advantage provides important leverage in a cross-development environment: the less data to be downloaded, the shorter the development cycle. Dynamic linking means that it makes sense for even partially completed modules to be downloaded for incremental testing and debugging. The host-resident Tornado shell and debugger can then 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.