looking at the API docs, I see
int rt_timer_start ( RTIME /nstick/ )
/
nstick/ The timer period in nanoseconds. If this parameter is equal to
TM_ONESHOT, the underlying hardware timer is set to operate in
oneshot-programmable mode. In this mode, timing accuracy is higher -
since it is not rounded to a constant time slice - at the expense of a
lesser efficicency when many timers are simultaneously active. The
oneshot mode gives better results in configuration involving a few tasks
requesting timing services over different time scales that cannot be
easily expressed as multiples of a single base tick, or would lead to a
waste of high frequency periodical ticks.
This leaves me unclear on how to program the timer to expire in say, 1.5
mSec.
For background (in case it prompts any strategy advice)
Im trying to build a timing-generator state-machine that
drives a sequence of pins high for an arbitrary interval each.
More precisely, its a 2 channel PWM controller,
with simultaneous rising edges, independent falling edges,
and same period (~16 ms). the pulse width Im after is ~0.5 - 2.5 ms
IIUC, a periodic timer cannot handle this problem, except by slicing
time into small chunks, and transitioning on multiples of them.
This sounds bad, it raises the 'interrupt' rate, or makes the pulse-width
changes very discrete (limited steps)
Is this something I should be using nucleus for ?
( while Im asking, rt_timer_start is part of native services,
and xntimer_start is nucleus services ? )
It seems that the API supports creating multiple timers,
but I see no advantage in using multiples vs 1 for my app,
either way I have to reprogramm timer-duration and handler each time.
Also, I see that
int xnpod_start_timer ( u_long /nstick/,
xnisr_t /tickhandler/
)
Start the system timer.
suggests that there is 1 hardware timer.
Isnt there hardware that has more than 1 timer ? (examples ?)
how does one use the extra capabilities ?
Finally, I note that linux appears to be moving towards uniform
treatment of time
in nanoseconds, rather than jiffies/ticks (I think this work, by John
Stultz, is in -mm now)
Do you have a sense how this might affect fusion going forward ?
thanks in advance,
Jim Cromie
