![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Top]](icons/top.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This section provides a summary of VxWorks facilities; they are described in more detail in the following subsections. For details on any of these facilities, see the appropriate chapters in this manual.
Modern real-time systems are based on the complementary concepts of multitasking and intertask communications. A multitasking environment allows real-time applications to be constructed as a set of independent tasks, each with a separate thread of execution and its own set of system resources. The intertask communication facilities allow these tasks to synchronize and coordinate their activity.
The VxWorks multitasking kernel, wind, uses interrupt-driven, priority-based task scheduling. It features fast context switch times and low interrupt latency. Under VxWorks, any subroutine can be spawned as a separate task, with its own context and stack. Other basic task control facilities allow tasks to be suspended, resumed, deleted, delayed, and moved in priority. See 2.3 Tasks and the reference entry for taskLib.
The wind kernel supplies semaphores as the basic task synchronization and mutual-exclusion mechanism. There are several kinds of semaphores in wind, specialized for different application needs: binary semaphores, counting semaphores, mutual-exclusion semaphores, and POSIX semaphores. All of these semaphore types are fast and efficient. In addition to being available to application developers, they have also been used extensively in building higher-level facilities in VxWorks.
For intertask communications, the wind kernel also supplies message queues, pipes, sockets, and signals. The optional component VxMP provides shared-memory objects as a communication mechanism for tasks executing on different CPUs. For information on all these facilities, see 6. Shared-Memory Objects and 2.4 Intertask Communications. In addition, semaphores are described in the semLib and semPxLib reference entries; message queues are described in the msgQLib and mqPxLib reference entries; pipes are described in the pipeDrv reference entry and 2.4.5 Pipes; sockets are described in the sockLib reference entry and 2.4.6 Network Intertask Communication; and signals are described in the sigLib reference entry and 2.4.7 Signals.
POSIX (the Portable Operating System Interface) is a set of standards under development by representatives of the software community, working under an ISO/IEEE charter. The purpose of this effort is to support application portability at the source level across operating systems. This effort has yielded a set of interfaces (POSIX standard 1003.1b, formerly called 1003.4) for real-time operating system services. Using these interfaces makes it easier to move applications from one operating system to another.
For a list of POSIX facilities, look under POSIX in the keyword index in the VxWorks Reference Manual or in the Tornado Online Manuals. Nearly all POSIX 1003.1b interfaces are available in VxWorks, including POSIX interfaces for:
The VxWorks I/O system provides uniform device-independent access to many kinds of devices. You can call seven basic I/O routines: creat( ), remove( ), open( ), close( ), read( ), write( ), and ioctl( ). Higher-level I/O routines (such as ANSI C-compatible printf( ) and scanf( ) routines) are also provided.
VxWorks also provides a standard buffered I/O package (stdio) that includes ANSI C-compatible routines such as fopen( ), fclose( ), fread( ), fwrite( ), getc( ), and putc( ). These routines increase I/O performance in many cases.
The VxWorks I/O system also includes POSIX-compliant asynchronous I/O: a library of routines that perform input and output operations concurrently with a task's other activities.
VxWorks includes device drivers for serial communication, disks, RAM disks, SCSI tape devices, intertask communication devices (called pipes), and devices on a network. Application developers can easily write additional drivers, if needed. VxWorks allows dynamic installation and removal of drivers without rebooting the system.
Internally, the VxWorks I/O system allows individual drivers complete control over how the user requests are serviced. Drivers can easily implement different protocols, unique device-specific routines, and even different file systems, without interference from the I/O system itself. VxWorks also supplies several high-level packages that make it easy for drivers to implement common device protocols and file systems.
For a detailed discussion of the I/O system, see 3. I/O System. Relevant reference entries include ioLib for basic I/O routines available to tasks, fioLib and ansiStdio for various format-driven I/O routines, aioPxLib for asynchronous I/O, and iosLib and tyLib for routines available to driver writers. Also see the reference entries for the supplied drivers.
VxWorks includes several local file systems for use with block devices (disks). These devices all use a standard interface so that file systems can be freely mixed with device drivers. Local file systems for SCSI tape devices and CD-ROM devices are also included. The VxWorks I/O architecture makes it possible to have several different file systems on a single VxWorks system, even at the same time.
VxWorks provides the dosFs file system, which is compatible with the MS-DOS file system (for MS-DOS versions up to and including 6.2). The capabilities of dosFs offer considerable flexibility appropriate to the varying demands of real-time applications. Major features include:
VxWorks provides the rt11Fs file system, which is compatible with that of the RT-11 operating system. This file system has been used for real-time applications because all files are contiguous. However, rt11Fs does have some drawbacks. It lacks a hierarchical file organization that is particularly useful on large disks. Also, the rigid contiguous allocation scheme may result in fragmented disk space. For these reasons, dosFs is preferable to rt11Fs.
The VxWorks implementation of the RT-11 file system includes byte-addressable random access (seeking) to all files. Each open file has a block buffer for optimized reading and writing.
Services for file-oriented device drivers using rt11Fs are implemented in rt11FsLib.
VxWorks provides rawFs, a simple "raw disk file system" for use with disk devices. rawFs treats the entire disk much like a single large file. The rawFs file system permits reading and writing portions of the disk, specified by byte offset, and it performs simple buffering. When only simple, low-level disk I/O is required, rawFs has the advantages of size and speed.
Services for file-oriented device drivers using rawFs are implemented in rawFsLib.
VxWorks provides a file system for tape devices that do not use a standard file or directory structure on tape. The tape volume is treated much like a raw device where the entire volume is a large file. Any data organization on this large file is the responsibility of a higher-level layer.
Services for SCSI sequential device drivers using tapeFs are implemented in tapeFsLib.
VxWorks provides the cdromFs file system which lets applications read any CD-ROM that is formatted in accordance with ISO 9660 file system standards. After initializing cdRomFs and mounting it on a CD-ROM block device, you can access data on that device using the standard POSIX I/O calls.
In VxWorks, the file system is not tied to the device or its driver. A device can be associated with any file system. Alternatively, you can supply your own file systems that use standard drivers in the same way, by following the same standard interfaces between the file system, the driver, and the VxWorks I/O system.
Virtual memory support is provided for boards with Memory Management Units (MMU). Bundled virtual memory support provides the ability to mark buffers noncacheable. This is useful for multiprocessor environments where memory is shared across processors or where DMA transfers take place. For information on bundled virtual memory support, see 7. Virtual Memory Interface and the reference entries for vmBaseLib and cacheLib.
Unbundled virtual memory support is available as the optional component VxVMI. VxVMI provides the ability to make text segments and the exception vector table read-only, and includes a set of routines for developers to manage their own virtual memory contexts. For information on VxVMI, see 7. Virtual Memory Interface and the reference entry for vmLib.
The following shared-memory objects (available with VxWorks as the optional component, VxMP) are used for communication and synchronization between tasks on different CPUs:
For information on VxMP, see 6. Shared-Memory Objects and the reference entries for smObjLib, smObjShow, semSmLib, msgQSmLib, smMemLib, and smNameLib.
In the Tornado development system, a full suite of development tools reside and execute on the host machine; see the Tornado User's Guide for details. However, a target-resident shell, symbol table, and module loader/unloader can be configured into the VxWorks system if necessary, for example, to create a dynamically configured run-time system.
For information on these target-resident tools, see 9. Target Shell and the reference entries for shellLib, usrLib, dbgLib, loadLib, unldLib, and symLib.
VxWorks supports C++ development. The GNU C++ compiler is shipped with Tornado. The Tornado compiler provides support for multi-thread-safe exception handling. Tornado includes a new version of the iostream library and the SGI implementation of the Standard Template Library. The standard Tornado interactive development tools such as the debugger, the shell, and the incremental loader include C++ support.
In addition, you can order the Wind Foundation Classes optional component to add the following libraries:
For more information on these libraries, see 5. C++ Development.
VxWorks supplies many subroutines of general utility to application developers. These routines are organized as a set of subroutine libraries, which are described below. We urge you to use these libraries wherever possible. Using library utilities reduces both development time and memory requirements for the application.
VxWorks supplies routines for handling hardware interrupts and software traps without having to resort to assembly language coding. Routines are provided to connect C routines to hardware interrupt vectors, and to manipulate the processor interrupt level.
For information on interrupt handling, see the intLib and intArchLib reference entries. Also see 2. Basic OS for information about the context where interrupt-level code runs and for special restrictions that apply to interrupt service routines.
A watchdog facility allows callers to schedule execution of their own routines after specified time delays. As soon as the specified number of ticks have elapsed, the specified "timeout" routine is called at the interrupt level of the system clock, unless the watchdog is canceled first. This mechanism is entirely different from the kernel's task delay facility. For information on watchdog timers, see 2.6 Watchdog Timers and the reference entry for wdLib.
A simple message logging facility allows applications to send error or status messages to a logging task, which then formats and outputs the messages to a system-wide logging device (such as the system console, disk, or accessible memory). The message logging facility can be used from either interrupt level or task level. For information on this facility, see 3.5.3 Message Logging and the reference entry for logLib.
VxWorks supplies a memory management facility useful for dynamically allocating, freeing, and reallocating blocks of memory from a memory pool. Blocks of arbitrary size can be allocated, and you can specify the size of the memory pool. This memory scheme is built on a much more general mechanism that allows VxWorks to manage several separate memory pools.
VxWorks includes a complete set of ANSI C library string formatting and scanning subroutines that implement printf( )/scanf( ) format-driven encoding and decoding and associated routines. See the reference entries for fioLib and ansiStdio.
The library bLib contains buffer manipulation routines such as copying, filling, comparing, and so on, that have been optimized for speed. The library rngLib provides a set of general ring buffer routines that manage first-in-first-out (FIFO) circular buffers. Additionally, these ring buffers have the property that a single writer and a single reader can access a ring buffer "simultaneously" without being required to interlock their accesses explicitly.
The library lstLib contains a complete set of routines for creating and manipulating doubly-linked lists.
VxWorks provides all C libraries specified by ANSI X3.159-1989. The ANSI C specification includes the following libraries: assert, ctype, errno, float, limits, locale, math, setjmp, signal, stdarg, stdio, stddef, stdlib, string, and time.
The header files float.h, limits.h, errno.h, and stddef.h provide ANSI-specified definitions and declarations. The more commonly used libraries are described in the following reference entries:
|
a variety of routines, including those for type translation, memory allocation, and random number generation |
|||||||||||||||||||
To understand and optimize the performance of a real-time system, it can be useful to time some of the VxWorks or application routines. VxWorks provides various timing facilities to help with this task.
The VxWorks execution timer can time any subroutine or group of subroutines. Because the system clock is too slow to provide the resolution necessary to time especially fast routines, the timer can also repeatedly execute a group of routines until the time of a single iteration is known to a reasonable accuracy. For information on the execution timer, see the timexLib reference entry.
VxWorks also provides the spy utility, which provides CPU utilization information for each task: the CPU time consumed, the time spent at interrupt level, and the amount of idle time. Time is displayed in ticks and in percentages. For information on this utility, see the spyLib reference entry.2
Even more powerful monitoring of the VxWorks system is available using the optional product WindView; for more information, see the WindView User's Guide.
The target agent follows the WDB (Wind DeBug) protocol, allowing a VxWorks target to be connected to the Tornado development tools. In the target agent's default configuration, shown in Figure 1-1, the agent runs as the VxWorks task tWdbTask. The Tornado target server sends debugging requests to the target agent. The debugging requests often result in the target agent controlling or manipulating other tasks in the system.
By default, the target server and agent communicate using the network. However, you can use alternative communication paths. For more information on the default configuration or alternative configurations of the target agent, see Tornado Getting Started. For information on the Tornado target server, see the Tornado User's Guide: Overview.
Two target-specific libraries, sysLib and sysALib, are included with each port of VxWorks. These libraries are the heart of VxWorks portability; they provide an identical software interface to the hardware functions of all boards. They include facilities for hardware initialization, interrupt handling and generation, hardware clock and timer management, mapping of local and bus memory spaces, memory sizing, and so on.
Each BSP also includes a boot ROM or other boot mechanism. Many of these import the run-time image from the development host. For information on boot ROMs and other booting mechanisms see Tornado Getting Started and 8.9 Creating Bootable Applications.
For information on target-specific libraries, see 8.2 The Board Support Package (BSP) and the target-specific reference entries for your board type.
VxSim, the VxWorks simulator, is a program that simulates a VxWorks target for use as a prototyping and testing environment. The integrated version of the simulator allows a single simulator to be run. The VxSim optional product adds networking facilities, allowing the simulator to obtain an Internet address and communicate with the host (or other nodes on the network) using the VxWorks networking tools.
VxSim is essentially a port of VxWorks. In most regards, its capabilities are identical to a true VxWorks system running on remote target hardware. You can link in an application and rebuild the VxWorks image exactly the same way as in any other VxWorks cross-development environment. All Tornado development tools can be used with VxSim.
The difference between VxSim and a remote VxWorks target environment is that in VxSim, the image executes on the host machine itself as a host process. There is no emulation of instructions, because the code is in the host's own CPU architecture. Because target hardware interaction is not possible, device-driver development may not be suitable for simulation. However, the VxWorks scheduler is implemented in the VxSim process, maintaining true tasking interaction with respect to priorities and preemption. This means that any application that is written in a portable style and with minimal hardware interaction should be portable between VxSim and VxWorks.
For more information on VxSim, see H. VxSim.
1: BSD stands for Berkeley Software Distribution, and refers to a version of UNIX.
2: You can also use this utility through the Tornado browser; see the Tornado User's Guide: Browser for details.
