9.4 Development Environments and Tools

Depending upon the processor, developers will need to license compilers or cross compilers that run on their host workstations. For example, a developer working with a VxWorks™ development environment under Windows™ for a target using the PowerPC™ 750 processor will need a cross compiler, linker, and loader running under VxWorks for the PowerPC processor. RTOS vendors may offer these tools as part of the development environment, such as the Tornado Development Environment from Wind River. Alternately, the developer may need to license the tools from a third-party vendor such as Green Hills.

Some RTOS vendors offer the source code for their operating systems as part of the development licensing agreement. This is more the exception than the rule. Most vendors offer only the object code for the operating system for the processor needed by the customer. In our example, Wind River will provide VxWorks object files for the PowerPC processor, which need to be linked into the application comprising the protocol tasks, OSAL, and management tasks, as shown in Figure 9.3 (a). Some system files include a few source files and include files which can be modified for the specific target hardware initialization, application startup, and timer interrupt handling.

Figure 9.3: Typical development environment

The cross-development tools for the PowerPC 750 are used to compile the source code for the application into PowerPC object code and linked with the VxWorks OS object files to build a loadable image to download to the target. The download happens through an Ethernet port on the target, which is designated as the management port. The image can also be burned into flash for a faster boot. For multi-board systems, a separate image is burned into flash on each board.

On startup, initialization status is displayed with diagnostic messages on a serial port. The messages can be viewed by connecting a terminal or a PC with a terminal emulation program with parameters set to match with those for the serial port on the board. The messages include initialization status for DRAM, SRAM, hardware controllers, and the creation of data structures and buffer pools. Once initialization is complete, each of the tasks wait on events in their main loop.

To debug on the target, developers need to compile with the debug option. The code can be debugged through the serial port or through a host-based debugger which connects with the target over an Ethernet or serial connection. A target server exists on the target to act as the “local representative” of the host-based debugger (see Figure 9.3 (b)). The sequence of operations is as follows:

1. The developer uses host-based GUI commands for debugging.

2. The debugger communicates to the target server.

3. The target server performs the debug operations as though it were locally attached.

4. The target server sends the results of the debug operation to the host-based debugger.

Several RTOSes offer file system capabilities either in local RAM or a remote development station. In this case, it may be possible to mount a directory on a user development station as a file system on the target; then diagnostic information can be written to a file on the target system. The information is transmitted using a UDP or TCP connection from the target to the host.