Vaisala RVP900

Appendix D _________________________________________________ RVP900 Developer's Notes
VAISALA______________________________________________________________________ 405
When no callbacks are registered, or when the registered callback does not
request any further activity, the printout will simply look like this:
RTC –First- #0(-) #1(-) #2(-)
RTC Disabling further callbacks for this PROC section
The first real-time callback does not set any of the iTVWaitOnNext fields,
and the whole timer mechanism simply goes to sleep until the next
ProcSection begins. In contrast, the following printout was generated by
the demonstration histogram callback that is provided in
rvp8main/open/rtctrl.c:
RTC –First- #0( dV:0 F:0 Rq:100000 ) #1(-) #2(-)
RTC Setting timer #0 clock source to 0 (1MHz)
RTC 0.100068 #0( dV:100009 F:1 Rq:2500 ) #1( dV:0 F:0 Rq:5 )
#2(-)
RTC Setting timer #1 clock source to 1 (Trig)
RTC 0.002512 #0( dV:2513 F:1 Rq:2500 ) #1( dV:2 F:0 Rq:5 )
#2(-)
RTC 0.002510 #0( dV:2510 F:1 Rq:2500 ) #1( dV:3 F:0 Rq:5 )
#2(-)
We see the first invocation requests a callback in 100000 counts of the
1 MHz timer. The "Rq" (request) field of timer #0 shows the iTimerWait
duration. The iTVWaitOnNext field causes the 1 MHz clock to be selected
as the timer source.
That callback fires a little more than a tenth of a second later (the additional
68 sec represents the Linux Interrupt-to-Running latency, plus the time to
set the clock source in the first place). On the second invocation, the demo
callback requests a delay of 2500 on the 1 MHz timer (2.5 ms), and a delay
of five counts on the Trigger timer. The RVP8 trigger is selected as the
clock source for timer #1.
From then on, the callbacks fire regularly based on activity on timers #0
and #1. The "dV" number show the "delta-value" for each timer, that is, the
change in the timer's count since the previous call. The "F" field indicates
whether each timer has fired (1) or is still counting up to the requested
delay (0). In this case, timer #0 is regularly firing every 2.5 ms; and since
we only get two or three trigger counts in that much time, timer #1 never
actually fires at all. If the PRF were increased, however, we would
suddenly see timer #1 counting up to five triggers and then firing before
the 2.5 ms expires.
NOTE
The clock source messages are only printed when changes are made.