The timer counts up or down to a programmed value (called the terminal count), at which point it generates a hardware interrupt. The counter is reset (either by hardware or software), and begins to count up or down again towards the terminal count. The interrupt is the sole output of a periodic interrupt timer. After acknowledging the interrupt, an interrupt service routine (ISR) usually calls an operating system facility to log the interrupt as a clock tick. In some cases, the ISR calls an application-specific routine instead.

The terminal count may be adjusted so that an interrupt is generated at a specified time interval. For instance, if the terminal count is set such that an interrupt occurs every 10 msec, 100 ticks per second are generated (100Hz). The VxWorks system and auxiliary clocks use the underlying hardware timers in periodic interrupt mode.

The timer counts up or down to a programmed terminal count, at which point it generates a hardware interrupt. The counter is then disabled (either by hardware or software). An ISR acknowledges the interrupt, and then calls a user-specified routine.

Currently, VxWorks does not provide a one-shot timer facility, although this type of timer may be simulated by having a periodic interrupt timer disable the counter in the ISR.

The timer counts up or down to its maximum count (0 or 0xfff) at which point it generates a hardware interrupt. The counter rolls over and begins to count again towards the maximum value. After acknowledging the interrupt, an ISR calls an operating system facility or application-specific routine to log the counter rollover. At any time, the operating system or application may read the counter value to obtain high-resolution timing information in timestamp tick units.

This mode of operation differs from a periodic interrupt timer in that the counter is usually allowed to count to its maximum value (that is, the terminal count is set to 0 or 0xfff). Additionally, the counter value is the primary output of the timestamp timer, and the interrupt is only used to announce a counter rollover. Timestamp timer components are typically similar to Figure G-2.      

The remainder of this document deals only with timers operating in timestamp mode.

The most important characteristic of a good timestamp timer is the ability to read the counter's value without having to stop the timer from counting. If the timer must be disabled to read the timestamp value accurately, the time spent without the timer running is not recorded, although the system is actually doing work and other timers are continuing to run (the system clock, for instance). This situation is commonly called time skew. As time skew accumulates, the timestamp values become more and more removed from the absolute time of the system, as kept by the system clock. Additionally, interrupts must be locked out while the timer is stopped. Both of these effects are detrimental to real-time systems.

The input clock is often passed through a prescaler counter to divide the input clock frequency, thereby producing a lower frequency input for the timestamp counter. Although a prescaler is not always present (and need not be used) it can be a useful way of tuning timer devices that have an unusually high input clock frequency.

The timer's counter should be at least 16 bits wide, although a 24- or 32-bit counter is preferable. The wider a counter, the less often it must roll over, and therefore the less system overhead its ISR incurs. The input frequency can also be higher with a wide counter, which yields more accurate timing information.

Some timers require that the counter be preloaded with a value before counting resumes. This is an issue only for timers that cannot be read while enabled. This characteristic adds to the time spent with the timer disabled, thereby increasing time-skew problems. The preload mechanism itself provides a way to correct skew, but determining the amount of the correction is difficult; see the discussion of counter preloading in Working Around Deficiencies in Hardware Timers.

As with all hardware devices, the locations of timer device registers must be cache coherent. This ensures that reads and writes to timer registers are actually accessing the register locations themselves, and not CPU data cache locations. If data cache memory exists, and there is no hardware mechanism (such as an MMU) to guarantee data cache coherency for register locations, the timestamp timer driver must make explicit calls to flush and invalidate the CPU's data cache. This adds to the overhead of reading the timestamp tick value. For more information, see the VxWorks BSP Porting Kit: Cache and Virtual Memory Library Support.

The timestamp timer must be able to generate a hardware interrupt once the maximum (or terminal) count is reached. An interrupt is needed to avoid aliasing, by announcing the rollover event. Without the interrupt, timestamps are ambiguous, since there is no way to distinguish two timestamps separated by the timer's period.

The timestamp tick resolution is calculated as follows:

To be effective, the resolution should be 10 µsec or less (that is, a timestamp tick frequency of at least 100KHz). Although this is not a strict requirement, it is consistent with timing limitations within the VxWorks kernel. If the timestamp timer output is slower than 100KHz, some instrumented kernel events may not have distinguishable timing information.

The time between timestamp rollovers is the timestamp timer's period. The period is defined as the product of the timer resolution and the timer's maximum count:

To be effective, the period should be at least 10 msec. If rollovers are more frequent, the overhead of servicing the rollover interrupt may be too intrusive. The greater the period, the better.