WindView provides a flexible environment for real-time application analysis. The functional elements of WindView are modular; they can potentially be customized or even replaced by user-defined functionality. WindView adds components to Tornado on both the target and the host. On the target side, instrumentation points, the dynamic ring buffer, event logging, timestamping, data upload, and triggering can all be separately configured. On the host, the event-base can be customized, information can be analyzed and displayed in real-time or saved for later processing, and WindView or other tools can be used for analysis and display.

An important aspect of WindView's modularity is the ability to customize the event set understood by WindView at runtime. To accomplish this, the basic VxWorks events are gathered into a human-readable file (indicated by the extension .e). This file can be extended with new components, such as the events required to instrument new libraries. Further, it is possible to replace the VxWorks .e file with one set up for other operating systems (for example, WiSP or I2O). The initial segment of an event-base specifies the DLL to be loaded. Each DLL is responsible for locating and loading the corresponding .e file, which in turn is responsible for locating and loading the various extension files that correspond to the various components.

On the target, events are recorded in the WindView ring buffer as they occur. All requested events are logged, whether they are generated in system tasks ¹ or in application tasks. The WindView event manager (tWVUpload) transfers the data in the WindView buffers to the host as the user specifies. This may occur whenever the upload threshold is reached or when requested by the host tool.

The second portion of WindView resides on the host as part of the Tornado host-resident tools. It accepts event data from the target, displays the event data, and sends target control requests (such as requests to start event logging) to the target.

Figure A-1 shows how the various parts of WindView on the host and the target interact. Note that in the case of the integrated WindView which works with the simulator, all the elements that appear in the target block in Figure A-1 actually exist in a simulator block on the Tornado host.  

As with all Tornado tools, WindView keeps as much processing as possible on the host in order to minimize the effect of logging on target activities. In the case of WindView, this is particularly important since understanding target behavior depends on not changing it in the act of measuring it.

One portion of WindView resides on the host as part of the Tornado host-resident tools. It provides the following services:

• Controls WindView on the target.

• Processes and displays event data.

• Stores data for later analysis.

In addition, WindView uses information in the .e file are responsible to tell the GUI how to select instrumentation for the component libraries and how to filter out the events the user chooses not to display at a particular moment. The .e files also contain pointers to the bitmaps used by the view graph for the display of kernel and component events.

The event-base also resides on the host, as part of WindView.It provides controlled access to raw event data received from the target by:

• Providing C++ and Tcl programming interfaces.

• Exporting classes representing the event-base, the event-contexts, the individual events, and a cursor.

• Causing the correct .e file to be loaded (the file matching the target operating system).

WindView provides facilities to export event data to other host tools. Currently the ability to export data to an Excel spreadsheet is implemented for Windows hosts.

The primary WindView-related activities that occur on the VxWorks target are event logging: collecting, timestamping, and uploading event data to the host. In addition, the VxWorks triggering function takes place on the target. While this function is separate from WindView, it is discussed here because it can be used to manage WindView activities.

On the target, WindView manages and coordinates the following:

• Event logging

• Data uploading

• Communication with WindView on the host

WindView considers an event to be any action undertaken by a task or an interrupt service routine (ISR) that can affect the state of the real-time system. Examples of events are:

• Semaphore gives and takes

• Task spawns and deletions

• Timer expirations

• Interrupts

• Memory allocations and deallocations (optional)

• Network events (optional)

Events affecting the following VxWorks system objects can be logged:

• Tasks

• Semaphores

• Message queues

• Watchdog timers

• Interrupts

• Exceptions

• Signals

• Networking

Events affecting the following VxWorks library can also be logged:

• VxWorks events

• memLib

The amount and type of information logged is determined by the current event-logging level. In general, however, the information logged for each event includes such things as the action that occurred (such as a semGive or semTake), the context in which the event occurred (that is, the ISR, task, or idle loop), the timestamp, and other status information as appropriate (for example, the semaphore ID for a semGive). WindView's event-logging levels include:

• Context Switch (CSE)

• Task State Transition (TST)

• Additional Instrumentation (AIL)

Each logging level provides a trade-off: as you move away from the center of the circle, you gain more detailed information on more events, but you intrude more into the real-time application (for details, see 3.2 Selecting a Logging Level).

A key data element that is logged for each event is the timestamp. For most BSPs, WindView provides two options:

• High-resolution timestamp driver

• Sequential timestamp driver

For information on configuring WindView timestamp drivers, see Timestamp Driver. For additional information, see 7.5 Timestamping. For information on writing your own timestamp driver, see E. Creating a VxWorks Timestamp Driver.

The triggering API allows a user to hook actions to one or more events during VxWorks execution. The mechanism takes advantage of the existing event instrumentation for WindView. A trigger can be set at any of the WindView event points. Once the trigger is set, when the event occurs, the action related to the trigger is performed. For more information, see 6. Triggering and C. Triggering API.

The dynamic ring buffer (rBuff) serves to decouple data collection from data upload and storage, thus maximizing the flexibility of the system. Events are logged to a user-configurable, dynamic ring of buffers on the target. The GUI allows users to configure the following:

• Size of the buffers in the ring

• Minimum and maximum number of buffers

When one buffer fills, data is written to the next buffer in the ring. If there are no more buffers and the current number of buffers is less than the maximum, a new buffer is added. If a buffer is emptied and the current number is greater than the minimum, the empty buffer is removed. For detailed information on the dynamic buffer, see 4.2 Dynamic Ring Buffer and 7.6 Dynamic Buffer Allocation.

Communication between the host and target portions of WindView is provided by the WDB protocol over a serial line or a network connection. This is the same path used by all the Tornado host tools to communicate with the target. For information on configuring this communication path, see the Tornado User's Guide: Setup and Startup.

Event data may be uploaded through the same communication path as is used by the Tornado tools or using the network and it can be uploaded after collection is complete or continuously during collection.