This WindView event-logging level works a little differently from the CSE level or the TST level. When this level is selected, WindView gathers all the information included in the other two levels, as well as additional information about particular objects that you have instrumented. Instrumenting an object causes WindView to log all operations on the object, including creation, gives or sends, takes or receives, and deletion. Events are generated for these operations whether or not they result in task state transitions, context switches, or neither; for example, a semTake( ) of a semaphore that is available is logged at this level.

See additional instrumentation event-logging level.

Analysis packs are preprogrammed functions which calculate analog information for event logs. For example, there is an analysis pack to measure and display how much system memory is allocated at a given moment.

Application code is any user-supplied code in the real-time system.

Many target boards include an auxiliary clock which, when enabled, runs continually and emits a periodic interrupt. In a VxWorks application, the application code can use the auxiliary clock unless it is being used by the timestamp driver. See also system clock.

A binary semaphore may be viewed as a cell in memory that can be full or empty. A binary semaphore is useful for both mutual exclusion and synchronization.

For mutual exclusion, you create a binary semaphore with an initial state of full to "guard" a resource. When a task needs to use the resource, it attempts to take the semaphore; when the task is finished with the resource, it gives the semaphore. Other tasks cannot use the resource until the semaphore is again available. (Note that VxWorks also offers another type of semaphore that may be more appropriate for some applications: a specialized mutual exclusion semaphore.)

For synchronization, the binary semaphore is created with an initial state of empty. A task waits to synchronize with another task or an ISR by attempting to take the semaphore. When the other task or ISR gives the semaphore, the original task is again able to execute. Thus, the original task and the "giving" task or ISR are synchronized. See also counting semaphore.

See pended state.

The BSP provides the interface between VxWorks and a specific target board. This includes hardware initialization, interrupt handling, chip device drivers, hardware clock and timer management, mapping of local and bus memory spaces, and memory sizing.

A breakpoint is a location in a program at which the debugger will stop the application. This allows you to examine the stack, values of particular variables, and other items of interest. See also eventpoint.

A chained trigger is enabled by another trigger's firing.

See event collection.

See context switch, current context, task context.

The Context Attributes dialog box displays a list of all tasks in the real-time system, along with their task IDs and their associated CPU number if the log includes multiple CPUs. You can also use this dialog box to select which tasks are displayed in the view graph.

See task state.

The Context State Summary window shows summary statistics about a selected task during a specified interval. These statistics include a count, minimum, maximum, average, and total time the task spent in each state during the interval. Open this window by selecting Information from the task pop-up menu.

The Context State Information window displays information about the context that generated a selected event. Open this window by selecting Context State from the event pop-up menu.

A context switch is an operation performed by a multitasking operating system in which the current thread of execution is switched for another. Examples of this are one task preempting another, a task delaying itself or pending on a resource (making the processor available for another thread of execution), or a task being interrupted by an ISR. See also current context, task context.

This WindView event-logging level shows the current context and where it is switched. The current context is shown as a solid, horizontal line ( ). When a context switch occurs, a dotted, vertical line connects the previous context's line to the current context's line.

The following events are also shown at CSE level:

See also event-logging level.

In this mode, the event buffer is initialized and the WindView upload task, tWVUpload, is spawned. When event logging is active, event data is written to the dynamic ring buffer. When the buffer threshold is reached, tWVUpload uploads the buffer's contents to the host. On the host, the event data is streamed to the WindView view graph, to a file, or to the evtRecv tool. See also deferred upload mode and post-mortem mode.

The Control window displays status information about the WindView configuration and WindView event logging. It also has a toolbar for controlling data collection and upload.

A counting semaphore is similar to a binary semaphore except that it keeps track of the number of times the semaphore has been given. Every time the semaphore is given, the count is incremented; every time the semaphore is taken, the count is decremented. If the count reaches zero, any task that tries to take the semaphore makes a transition to the pended state.

Counting semaphores can be used for mutual exclusion and synchronization. They are most useful, however, in guarding resources of which there are multiple copies. For example, the use of five tape drives can be coordinated using a counting semaphore with an initial count of five. See also mutual exclusion semaphore.

CPU starvation refers to a task that is "starving" for CPU time. In other words, the task never gets to run, because it is never the highest-priority ready task. This is a common bug in multitasking real-time systems, easily diagnosed with WindView.

Cross-development is the development of an application on one platform (the host) for eventual execution on another platform (the target). This allows you to use the powerful host development resources, while minimizing the run-time effect on the target resources. For example, you might be developing a real-time application on a Windows NT workstation that when finished will run on a 68040 target board. Cross-development requires the use of special tools (such as cross compilers) that can handle this host versus target dichotomy.

See context switch event-logging level.

In real-time systems, the term "current context" usually refers to the currently executing task and information needed to restore the task's state, such as the state of the processor registers, operating system control information, and the stack (see task context). For WindView, the meaning has been extended to include ISRs and the kernel's idle loop.

Two or more tasks are in deadlock when they keep each other from running. For example, taskA and taskB are deadlocked when taskA is pending on a semaphore waiting to be unblocked by taskB, but taskB is pending on another semaphore waiting to be unblocked by taskA. This is a common bug in real-time systems, easily diagnosed with WindView.

A task is in the dead state if it has been deleted with the taskDelete( ) or taskDeleteForce( ) routine, or if it has exited. There is no stipple for this state, but users can define one if they wish to track it. See also task state, task state transition, deletion safety.

This is the default event-upload mode. In this mode, data is written to the dynamic ring buffer until the maximum number of buffers is full. Then data collection stops. Data is uploaded when the user requests it. See also continuous upload mode and post-mortem mode.

A task is in the delayed state (shown by the stipple) if it has been delayed with the taskDelay( ) routine. See also task state, task state transition.

A task can make itself "safe" from deletion by other tasks by calling the taskSafe( ) routine. This protection is often needed when a task executes in a critical region or engages a critical resource. Any task that attempts to delete a protected task makes a transition to the pended state. When finished with its critical resource, the protected task can make itself eligible for deletion by issuing taskUnsafe( ), which unblocks any deleting task. taskSafe( ) routines can be nested; a task can only be deleted when the number of taskUnsafe( ) routines equals the number of taskSafe( ) routines. A task is also safe from deletion if it takes a mutual exclusion semaphore with the SEM_DELETE_SAFE option set. See also dead state.

Downloading refers to the transference of programs and data from the host to the target.

The dynamic ring buffer is a buffer ring that grows and shrinks dynamically between user-defined limits by adding or deleting buffers of user-specified size to the ring.

An embedded system is a system built into a larger device that is dedicated to performing a specific task, such as a coffee maker or a satellite tracking system.

In WindView, an event is any action undertaken by a task or an 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, and interrupts. VxWorks has been instrumented to log this event information. See also event-logging level, instrumented code, user-generated events.

The event buffer is a user-configurable area of memory on the target into which instrumented events are logged. In the default event upload mode (deferred mode) when this buffer becomes full, data collection stops. In continuous mode, when this buffer becomes full, its contents are uploaded to the host by the WindView upload task (tWVUpload).

This is information that is logged to the WindView event buffer. This data is uploaded to the host by the WindView upload task, tWVUpload.

This is the process of starting event logging on the VxWorks target, and then capturing the event data as it is uploaded to the host.

The event dictionary lists all possible events generated by WindView logging. It provides information about the circumstances under which the real-time system could generate each event, the icon associated with it, and the information logged. The event dictionary is available in the WindView User's Guide and in the online help. It can be reached online by selecting WindView Help>Legend in the main Help menu, by selecting Help in the WindView event pop-up menu, or by double-clicking on the appropriate item in the Legend window.

Depending on the event-logging level that is specified, various icons are displayed in the view graph that correspond to events. For information on what each event icon represents, see the Legend window. To learn specific information on a particular instance of an icon, use the Show Event dialog box.

An event log is a finite collection of event data that resides on the host.

This is the target activity of writing information about events to the WindView event buffer as the events occur. You start event logging with the Start WV button in the Control window or with the wvEvtLogEnable( ) routine.

The event-logging facility operates in one of three user-enabled event-logging levels. These levels are differentiated by the amount of information logged for each event. At the lowest level (the CSE level), events that result in context switches are logged. At the next level (the TST level), events that result in task state transitions are logged. At the highest level (the AIL level), any actions that occur to any of the objects that you have instrumented are logged. When any of these event-logging levels is active, you can add application-specific events; see user-generated events.

Eventpoints are WindView-specific facilities that are analogous to breakpoints. They are locations in a program that cause WindView to display a user event icon when they are "hit" (that is, executed). Eventpoints are inserted dynamically from the Tornado shell with the e( ) routine. See also user-generated events.

The event pop-up menu provides commands for navigating the view graph and for displaying event information. Open it by right-clicking on any event icon in the view graph.

This is the host port over which the WindView GUI or evtRecv tool listens for connections from the target; specifically, WindView listens for event data from the upload task, tWVUpload. The default event port number is 6164.

The event buffer upload mode is set by selecting the desired mode in the Control Properties dialog box. The options are: deferred upload mode, continuous upload mode, and post-mortem mode. The modes differ by whether data is uploaded from the target to the host as it is collected or on request, and by where the target buffers are located in memory.

This is a host tool supplied with WindView that allows you to collect an event log in a host file without the target overhead of a file system. You can later import the log into the GUI with the Open command in the File menu.

An exception is an error in program code or data, such as an illegal instruction, a bus error, or a divide-by-zero error.

A task or other context is in the executing state (shown by the stipple) if it has control of the processor. For a task to be in the executing state, there must be no interrupts to service, the task must be the highest-priority ready task in the system, and there must be no other tasks with preemption locking enabled. ISRs are in the executing state after their interrupt has been acknowledged by the kernel; if there is more than one ISR to service, the one at the processor's highest interrupt level executes. The idle loop is in the executing state when there are no tasks to run and no ISRs to service. See also current context, task state, task state transition.

See thread of execution.

See file descriptor.

A file descriptor (fd) is a handle that allows the I/O system to reference a particular file. Fds are returned by the open( ) and creat( ) routines. Three fds are reserved and have special meanings: 0 for standard input, 1 for standard output, 2 for standard error output. Because fds are built on top of semaphores, fd-related operations are displayed in WindView as semaphore operations.

The Filter Events/States dialog box allows you to select which types of events and which context states are displayed in the view graph. It does not affect what data is logged. Open this dialog box by selecting Filter Events in the main View menu or by clicking the Filter Events button on the WindView toolbar.

Graphical User Interface: the portion of WindView running on the host with which you view event data.

The host is the platform on which you develop your real-time system and on which the main component of WindView runs. This allows you to use familiar development tools while minimizing the amount of target resources consumed.

The buffer on the host that temporarily holds the event data before it is processed by WindView when you are using the GUI to collect event data.

When there are no tasks ready to execute and no interrupts to service, the kernel enters its idle loop. In this "state," the kernel services interrupts and continually checks to see if a task is ready to run. Analyzing the amount of time your application is idle can help you fine-tune the application: too much time in the idle loop may mean the application is not using the CPU efficiently; too little time may mean that the application is interrupted too often to run effectively.

A task is in the inherited state (shown by the stipple) when its priority has been increased because it owns a mutual exclusion semaphore that has priority inheritance enabled and a higher-priority task is waiting for that semaphore.

Instrumented code is software that has been modified to provide information about its own operation. In the case of the wind kernel, this information is event data that contains a record of the significant moments in the flow of control within a real-time system. In the case of the additional instrumented libraries, this information is event information that contains a record of supporting, non-kernel functions such as I/O and memory management. Application code can be instrumented with the wvEvent( ) and e( ) routines; see user-generated events.

An instrumented object is an object for which all operations that occur to it are logged to the WindView event buffer, including creation, gives or sends, takes or receives, and deletion operations. You specify which types of objects are to be instrumented with the Collection Control dialog box. You can specify specific objects with the wvObjInst( ), wvSigInst( ), and wvObjInstModeSet( ) WindView routines.

An interrupt is a "message" from hardware that lets the microprocessor know that something has occurred in the external world. For example, the microprocessor may receive an interrupt when a clock tick occurs or when a character is received on a serial port. See also interrupt service routine (ISR).

See interrupt service routine (ISR).

Interrupt latency is the longest amount of time during which the processor's ability to respond to interrupts is inhibited. Both the hardware and software architecture contribute to interrupt latency. Hardware influences on interrupt latency include such things as prioritizing interrupt requests and preventing interrupt handling until the completion of lengthy instructions. Software influences stem from disabling interrupt response with intLock( ) for mutual exclusion.

Interrupts arrive at the microprocessor at various levels; these levels and their effects are determined by the CPU architecture.

Code can guarantee exclusive access to the CPU by locking out interrupts with the intLock( ) routine (they are re-enabled with the intUnlock( ) routine). Because such an action can be unacceptable for many real-time systems because of the inherent inability to respond to external events for the duration of the lock, it is important to keep interrupt locks short. Note that context switches among tasks can still occur while interrupts are locked, but only as a result of calls made by the task that performed the intLock( ). If a context switch occurs, interrupts are unlocked while any other tasks execute. See also mutual exclusion, preemption locks.

Also known as an interrupt handler, an ISR is a routine that is called when a particular interrupt occurs. For example, when a character is received on a serial port, the associated ISR is called to handle that interrupt. (Handling such an interrupt typically consists of copying the input character to a buffer and clearing the serial device for the next character.)

ISRs run in a special interrupt-level context, which is separate from any task's context.

In a VxWorks application, ISRs that call VxWorks routines are connected to their interrupts with intConnect( ). Note that there are some restrictions on what ISRs can do: the primary restriction is that they must not invoke functions that might cause blocking (pending) of the caller; see the VxWorks Programmer's Guide for details.

Intertask communication facilities allow tasks to synchronize and communicate so that they can coordinate their activity. The VxWorks intertask communication facilities include semaphores, message queues, pipes, sockets, and signals.

In WindView, intrusion refers to the amount of overhead added to the target system by including instrumented code and starting event logging.

The VxWorks I/O system provides uniform device-independent access to many kinds of devices and a stdio buffered I/O package that includes UNIX-compatible routines. VxWorks also includes device drivers for serial communications lines, disks, pipes, and network devices, and allows dynamic installation and removal of many drivers without rebooting the system.

This WindView window shows what each event icon and state stipple represents. It can be displayed with the Legend command in the event pop-up menu or by selecting Legend in the main Help>WindView Help menu.

The VxWorks scheduler can be explicitly disabled and enabled on a per-task basis with the taskLock( ) and taskUnlock( ) routines. When preemption locking is enabled (shown by the stipple), priority-based preemption does not occur unless the task explicitly blocks or suspends. When the preemption-locked task unblocks and begins running again, preemption is again disabled. Note that multiple nested calls to taskLock( ) may be made; each one must be explicitly unlocked before normal priority-based scheduling is enabled. In addition, note that preemption-locked tasks are still subject to interrupts.

See event-logging level.

In the context of the WindView User's Guide, the main window means the window which contains the WindView toolbar and the Control window. It also contains the menu referred to as the main menu. On a Windows host, this is the Tornado window. On a UNIX host, this is a separate window that opens when you launch WindView. For more information, see Figure 2-1.

VxWorks includes a message logging facility that allows error or status messages to be sent to a logging task. The logging task then formats and outputs the messages to a system-wide logging device, such as the system console, disk, or specific memory area. The message logging facility can be used from interrupt level or task level. For details, see the manual entry for logLib in the VxWorks Reference Manual.

VxWorks message queues allow a variable number of messages, each of variable length, to be queued in FIFO or priority order. Any task or ISR can send messages to a message queue, and any task can receive messages from a message queue. Multiple tasks can send to and receive from the same message queue. Full-duplex communication between two tasks generally requires two message queues, one for each direction.

When a task attempts to receive a message, if a message is in the message queue, the task gets the message and continues executing. If no messages are available, the task pends on the message queue until one becomes available or until the specified timeout expires. Tasks can pend on the message queue in FIFO or priority order.

When a task (or an ISR) sends a message, if there are no tasks waiting for a message, the sender continues executing. If there are tasks waiting on the message queue, the first one makes a transition to the ready state. A context switch occurs if the newly readied task is of higher priority than the task that sent the message.

Multitasking provides the fundamental mechanism for an application to control and react to multiple, discrete real-world events. Multitasking creates the appearance of many threads of execution running concurrently, but actually, the operating system interleaves the threads' execution on the basis of a scheduling algorithm. Multitasking also permits much more flexible and modular application designs than does a single-threaded model. See also preemptive priority scheduling, round-robin scheduling, task.

Mutual exclusion is the restriction of access to a particular resource (such as a data structure in memory) to only one task at a time. If mutual exclusion is not provided to certain resources, task execution order can affect the integrity of the resource, leading to race conditions. For example, if a task is writing to memory and is interrupted before it is finished, another task may write to the same area, corrupting memory. See also interrupt lock, preemption lock, semaphore.

A mutual exclusion ("mutex") semaphore is a specialized binary semaphore designed to address issues inherent in mutual exclusion, including priority inversion, deletion safety, and recursive access to resources. A mutex semaphore's behavior is identical to a binary semaphore's, with the following exceptions: it can be used only for mutual exclusion (not for synchronization); it can be given only by the task that took it; it may not be given from interrupt-level code; the semFlush( ) operation is illegal. See also counting semaphore.

A task is in the nonexistent state before it is spawned with the taskSpawn( ) or taskInit( ) routine. There is no stipple for this state, but users can define one if they wish to track it. See also task state, task state transition.

In a VxWorks system, objects include tasks, semaphores, watchdog timers, and message queues. The objects that can be instrumented are tasks, semaphores, watchdog timers, message queues, signals, and memory calls. For all objects except signals, you can enable instrumentation programmatically for a particular object, such as task t1, or a group of objects, such as all semaphores. You can instrument combinations of objects: for example, you might be interested in how task t1, all semaphores, and message queues mq1 and mq2 interact. For signals, you cannot specify particular signals to instrument: either all signals are instrumented, or none of them are. See also additional instrumentation event-logging level.

In a view graph, a page is the width of the current time interval; that is, the portion of the event log currently displayed in the view graph.

A task is in the pended state (shown by the stipple) if it attempted to obtain an object but the object was not available; for example, if it made a call to the semTake( ) or msgQReceive( ) routine but the semaphore or a message was not available. A task in this state is also known as a blocked task. See also task state, task state transition.

Pipes provide an alternative interface to the message queue facility: the interaction occurs through the VxWorks I/O system. Pipes are named virtual I/O devices managed by the pipeDrv driver. Because pipes are built on top of message queues, pipes and pipe operations are displayed in WindView as message queues and message queue operations.

In this event upload mode, you must configure WindView to locate the WindView buffer in memory that is not that is not overwritten if the target reboots. The event buffer is written to this memory and overwritten cyclically when it is filled. The buffer contents are uploaded when you request it, and are preserved in the event of a system failure.

If a task becomes ready to execute and it has a higher priority than the currently executing task, the "new" task preempts the current task. That is, the operating system immediately saves the current task's context and switches to the context of the higher-priority task. See also task state transition.

See locked state.

In VxWorks, each task is assigned a priority, and the kernel ensures that the CPU is allocated to the highest-priority ready task. The scheduling is preemptive in that if a task of a higher priority than the executing task becomes ready, the kernel preempts the current task and switches to the higher-priority task. See also context switch, task state transition.

A region of memory that is not overwritten during a warm reboot. It is used to store the event buffer in post-mortem mode so that it can be uploaded after reboot.

The standard VxWorks scheduler provides 256 task priority levels, numbered 0 (highest) through 255 (lowest). Tasks are assigned a priority when created; however, while executing, a task may change its priority using taskPrioritySet( ). See also priority inheritance.

Priority inheritance is a solution for the priority inversion problem. When a mutual exclusion semaphore is created with the SEM_INVERSION_SAFE option, priority inheritance is enabled. This algorithm ensures that a task that owns a resource executes at the priority of the highest-priority task pended on that resource. When the task gives up the resource, it returns to its normal priority. WindView shows priority inheritance with the stipple.

Priority inversion arises when a higher-priority task is forced to wait an indefinite period of time for the completion of a lower-priority task. For example, taskHi needs to take the mutual exclusion semaphore for a region, but taskLow currently owns the semaphore. Although taskHi preempts taskLow, it pends immediately because it cannot take the semaphore. Under normal circumstances, taskLow can now run, complete its critical region, and issue a semGive( ), releasing taskHi. But if a third task, taskMed, preempts taskLow so that taskLow is unable to issue the semGive( ), taskHi may never get to run. See also priority inheritance.

When the outcome of a program is erroneously determined by which of two or more events occurs first (for example, is a particular variable read first, or updated first?), it is said that a race condition exists. This kind of problem can often be solved by using mutual exclusion semaphores to synchronize the tasks' use of the resource, or by using the intLock( ) routine to synchronize ISRs and tasks.

An rBuff is a dynamic ring buffer.

To configure the rBuff for WindView, use the Control Properties dialog box.

A task is in the ready state (shown by the stipple) if it is not waiting for any resource other than the CPU; that is, it is ready to execute, but is not the highest-priority ready task in the system. See also task state, task state transition.

General term referring to the "system" formed by the VxWorks operating system, your real-time application, and the target hardware. This system must respond to external events within prescribed time limits.

A system object for which a task may contend with other tasks. Examples of resources are memory pool data structures, message queues, and semaphores. If the resource is not available, a task contending for that resource makes a transition to the pended state. See also task state transition.

To resume a task means to change its state to that which it held before it was suspended; this is usually accomplished with the taskResume( ) routine.

A round-robin scheduling algorithm shares the CPU fairly among all ready tasks of the same priority (a priority group) by using time slicing. No task of a priority group is allocated a second slice of time before all tasks of a group have been given a slice. Round-robin scheduling is enabled with the kernelTimeSlice( ) routine.

See executing state.

See preemptive priority scheduling and round-robin scheduling.

A semaphore is a VxWorks system object that provides mutual exclusion of shared resources and intertask synchronization. See also binary semaphore, counting semaphore, mutual exclusion semaphore.

When a timestamp driver is not present, events are tagged with sequence numbers that represent the order in which the events occurred on the target. The events are then spaced equidistantly from each other in the view graph.

The Show Event dialog box displays information about the event: its name, its timestamp, the context in which it occurred, and any other event information that has been logged. Double-click on an event icon in the view graph, or right-click on the icon and click Show Event in the event pop-up menu, to display this information.

VxWorks includes information facilities for most system services. The show( ) routine prints pertinent system status on the specified object or service to the stdout file descriptor. This routine presents only a snapshot of the system service at the time of the call and may not reflect the current state of the system; however, it can be useful in conjunction with WindView, showing, for example, the list of tasks pending on a semaphore or the contents of a message queue. See the VxWorks Reference Manual for more information on the show( ) routine.

VxWorks supports UNIX BSD-style signals as well as POSIX-compatible signals for asynchronous transfer of control within a task, based on hardware or software exceptions.

The VxWorks software signaling facility provides a set of 31 distinct signals. A task can specify a signal handler routine to take appropriate action when the associated signal is received. When signal handling is complete, normal task execution resumes, unless the signal corresponds to an exception.

A signal handler is a user-supplied routine that is bound to a specific signal (with the sigvec( ) or sigaction( ) routine) and performs whatever actions are necessary whenever the signal is received. The task being signaled immediately stops execution of its current thread and begins execution of a task-specified signal handler routine. Note that the signal handler gets invoked even if the task is blocked. Signals are most appropriate for error and exception handling, rather than as a general intertask communication facility.

A socket is a software interface for transferring byte streams between tasks, regardless of location in a networked application.

See task state.

The state stipples are the horizontal lines on the view graph that show the current state of each task in the real-time system. For information on what each state stipple represents, see the Legend window.

A sub-time interval is the space between two time instants. Select the beginning and ending time instants by clicking and dragging. Two vertical lines are displayed in the event log, and details about the sub-interval are displayed in the time interval field. It can be useful to know the amount of time that has occurred between events, or to select a sub-interval that you zoom in on with the Zoom In icon.

A task is in the suspended state (shown by the stipple) if it has been suspended with the taskSuspend( ) routine or by other means. Suspension does not inhibit state transition, only task execution. Thus, suspended-pended tasks may still unblock and suspended-delayed tasks may still awaken. In both cases, the resulting state is suspended-ready. (These additive task states are shown as suspended in the view graph.) See also task state, task state transition.

See real-time system.

In a VxWorks real-time system, this term refers to any code that is not application code. It includes the wind kernel, VxWorks system libraries, device drivers, and so on.

Target boards include a system clock, which continually runs and emits a periodic interrupt known as a tick. VxWorks uses the system clock to manage watchdog timers, task delays, and so on. See also auxiliary clock.

The target is the board on which your real-time system executes. After the application is written and compiled on the host, it is downloaded to the target or is burned into ROM for use on the target.

The Target Server File System is an expansion of the VxWorks virtual I/O facility into a file system.TSFS implements the standard I/O commands and supports a socket as a special file type. Thus TSFS can upload data either to a file or through a socket to the view graph or another destination. It requires much less target resource to provide these facilities than are required by the TCP/IP network stack or by NFS.

A task is an independent program in a VxWorks application that has its own job to perform, such as the management of a robot arm. Each task has its own context, which is the CPU environment and system resources the task "sees" each time it is scheduled to run by the kernel. On a context switch, a task's context is saved in the task control block (TCB). Tasks can communicate and synchronize with each other through intertask communication facilities.

Combined with preemptive priority-based scheduling, tasks provide the basis for building a real-time system. See also multitasking.

A task's context includes the following; note the difference between this and the WindView concept of current context:

Any code running in a task's context can be said to be running at task level.

The task pop-up menu provides commands for tailoring the view graph display and for displaying summary information about tasks. Open this menu by right-clicking on any task name on the left side of the view graph.

See preemption.

See priority.

In VxWorks applications, task states include the following: delayed, pended, ready, suspended. For WindView, the concept of "task state" has been extended to include the following: dead, executing, inherited, locked, nonexistent, unknown.

This term refers to the process of a task exiting from one state and entering into another (this is different from context switch, which refers to a change in the controlling context within the processor). For example, a task makes a transition from the executing state to the pended state when it calls the semTake( ) routine but the semaphore is not available, and it makes a transition from the delayed state to the ready state when the number of ticks specified in a call to taskDelay( ) have expired. A task state transition may or may not result in a context switch, depending on the states of other tasks in the system when the task in question makes its transition between states.

This WindView event-logging level shows task state transitions and the events that cause them. A task state is shown by the type of horizontal line (known as a state stipple) used to display it. Note that if you are using a color monitor, these state stipples are further differentiated by color. In addition, the event that caused the task state transition is shown as an icon. For example, a semGive( ) that results in a task state transition is shown as a solid semaphore flag icon ( ).

Note, however, that at this logging level, WindView does not provide information on events that do not result in task state transitions. For example, if no tasks are pended on a particular semaphore, a semGive( ) of that semaphore will not result in any task state transitions; thus, the semGive event icon will not be shown.

As an optimization, events are not separately timestamped when collected at TST level. However, such events receive the timestamp or sequence number of the next exit from the wind kernel. This exit is typically only a few microseconds after the event that caused the task state transition, and marks the moment at which the task state transition truly takes effect.

Tool command language; see F. Customizing WindView and User Applications for information.

The sequence of instructions that a particular process (such as a task or ISR) executes to carry out its job.

System clocks emit "ticks" to indicate the passage of time. They are hardware interrupts, and as such, are handled by clock ISRs. A particular tick may be more interesting than other ticks if it, for example, readies a task that was delayed for a certain number of ticks, causes a watchdog routine to execute, or readies a task that was pending with a timeout.

The time interval is the portion of the event log currently displayed in the view graph. If timestamping is enabled, the time interval is an amount of time. If sequential event display is used, the time interval is a number of events. The bounds and duration of the interval are shown at the bottom of the view graph in the time interval field.

If a task attempts to obtain a resource that is not available (for example, it attempts to take a semaphore, or receive a message from a message queue), it can specify a timeout value, typically specified as a number of clock ticks. In this case, the task makes a transition to the pended state until the resource becomes available or until the timeout expires, whichever occurs first.

When you enable round-robin scheduling with the kernelTimeSlice( ) routine, you specify the amount of time (in ticks) per "slice." The slices are allocated in rotation among a group of equal-priority tasks. When a time slice expires, the next task in the priority group executes for an equivalent time slice. See also round-robin scheduling.

When the instrumented kernel is run on a target with a supported timestamp driver, certain logged events are tagged with a high-resolution timestamp. The events are displayed in the view graph along a timeline showing when they occurred based on their timestamps. See also sequential event display.

See task state transition.

Triggering is a new VxWorks function. A trigger can be set to fire when specific conditions are met in your real-time system. When the trigger fires, it can cause an action to occur, which might be starting or stopping WindView or running any VxWorks function. Access the triggering function by selecting Triggering on the main Tools menu or by clicking the Trigger Launch button on the main toolbar.

The Triggering window shows summary information for all triggers that are loaded into the system. It also provides a toolbar for managing triggers and starting and stopping triggering.

The Trigger Maintenance dialog box is where triggers and their actions are defined.

See Target Server File System.

See task state transition event-logging level.

A task that is pended (blocked) on a resource is unblocked when the resource becomes available, its timeout expires, or it is explicitly unblocked.

A task is said to be in the unknown state (shown by the stipple) if you are performing post-mortem analysis and no context switch has yet occurred for the task. See also task state, task state transition.

Uploading refers to the transference of data from the target to the host.

The upload destination refers to where the uploaded event log is placed on the host: in a file, in the view graph, or in the evtRecv tool.

The upload mode refers to how upload is initiated, by user request (deferred upload mode and post-mortem mode) or automatically when the amount of data collected reaches a threshold (continuous mode).

The upload path refers to how data is uploaded from the target to the host. WindView can use TSFS, TCP/IP (network sockets), or NFS (Network File System).

The upload task (tWVUpload) is the VxWorks task used by WindView to upload the contents of the WindView event buffer from the target to the host. This task is created automatically when upload is requested in deferred upload mode and post-mortem mode, or when data collection is enabled and before it starts in continuous mode.

A user-defined event icon is an event icon that has been defined to appear when a user event occurs; see user-generated events. If you have not created your own icons, the icon appears by default, preceded by the event number.

When event logging has been started at any logging level, you can cause WindView to show application-specific events. There are two ways to do this: by setting eventpoints with the e( ) routine, or by inserting calls to wvEvent( ) into application source code.

See GUI.

This is the WindView window that lets you examine event data logged about your real-time system. In this window, time is represented on the horizontal axis, while the current system's contexts are represented on the vertical axis.

The VxWorks watchdog timer facility allows C functions to be connected to a specific time delay. Watchdog timers are invoked as part of the system clock ISR; thus, functions invoked by watchdog timers execute at the system clock's interrupt level or at the level of the interrupted context. All restrictions on ISRs apply to routines connected to watchdog timers.