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:

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:

Events affecting the following VxWorks system objects can be logged:

Events affecting the following VxWorks library can also be logged:

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:

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.

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

For information on configuring WindView timestamp drivers, see Timestamp Driver. For additional information, see 7.6 Timestamping. For information on writing your own timestamp driver, see G. 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 E. 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:

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.7 Dynamic Buffer Allocation.