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(-)
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 5 counts on the trigger timer. The RVP trigger is
selected as the clock source for timer #1.
The clock source messages are only printed when changes are made.
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 regularly fires every 2.5 ms; and since we
only get two or three trigger counts in that much time, timer #1 never fires at all. If the PRF
were increased, however, we would see timer #1 counting up to 5 triggers and then
firing
before the 2.5 ms expires.
RVP900 User Guide M211322EN-J
378
To Next Page
Loading...