“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:a93ulq$97n$1@nntp.qnx.com…
Sorry, I obviously didn’t state the problem well enough.
In order to get a stable 800 Hz timing signal, whether it comes from an
hardware timer or from a software timer, I need to be counting at a much
higher rate than what is currently permitted by most RTOS software timers.
You have stated that very well. Like Bill, I wish we could use the
processor
clock to compute timing. I could get a very stable rate if I were to use
the
166 MHz clock on my board. Give Bill’s proposition on increasing the clock
speed my vote.
That is the reason that I am using a hardware timer. I can divide the 10
MHz
signal to 800 Hz and generate an interrupt at 800 Hz +/- 1/(10e6) sec.
From
there, I can count the interrupts and trigger threads that are running at
rates that are common factors of the base rate.
QNX timer are doing exactly that except the hardware timer they are using
is a timer hardware that is precise to .999847 us. That’s the only
difference.
In theory it’s possible to hook QNX timers to what ever hardware you want.
This has to be done in the startup-code. I don’t know of anyone who
as done that for PC hardware. QNX sells and embedded kit to allow you
to do that.
As far as vxWorks goes, I don’t know how they deal with messages from the
ISR, except that the ISR runs in kernel space and all the messaging is
done
in kernel space, as well. One project I coded, acquired data at 5000 Hz
and
sent it to a logging task while in the ISR. I timestamped the data and
never
missed a frame.
Then we bought a Gage and started collecting data at 10 Msamples/sec.
Yeah that’s what nice about VxWorks , drivers
Regards,
David
“Mario Charest” <> goto@nothingness.com> > wrote in message
news:a92p8g$itu$> 1@inn.qnx.com> …
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in
message
news:a926mu$jj$> 1@nntp.qnx.com> …
Mario,
Thanks for the quick answer. I still haven’t made the attitudinal
shift
from working with a big kernel, as in vxWorks, to working with the
microkernel, here. In a big kernel, there is no overhead in sending a
message, releasing a semaphore, etc… as long as you don’t block.
?? There has to be overhead, for example some scheduling must occur if
for example message a priority based. At anyrate I don’t know didly
squad
about VxWork >
not using one of those RTOSs, so I’ll try to make the best of what we
have.
Your comment about using timers was interesting, but I see a problem.
Say
I have a high speed thread, 800Hz, for example. If I set the system
clock
to
a high rate, say 1000Hz, my resolution is still only 1/1000 sec,
right?
That’s unacceptable for this thread. That is why I want to drive the
threads
with a hardware timer that is based on a 10MHz clock. Now my timing
jitter
is only 1/(10e6) sec. Much better.
Huh? You can’t generate interrupt every 100 ns, you bring the system to
its
knees.
Hence you will have to use a multi of that. Bill post explain the
problem
but I’ll
use real number
If you have 800Hz, 700Hz, 500Hz, 300Hz, 60Hz ok?
That means one tick every 1.25, 1.42, 2, 3.3 and 16 ms. To get the
resolution
needed to get these time you would need to generate a tick every 10us.
So
that
100000 interrupt a second, even at that speed precision they will drift
since
I rounded the time to 10us.
I guess with some funky hardware timer programming you could change the
time
between each interrupt.
Can I connect the QNX software timers to
the hardware interrupt? If I can’t, the answer does seem to lie with
the
InterruptAttachEvent() function.
Yes and now. The problem is much more complexe then that >
The fact that you can’t do much from the ISR isn’t really a problem.
Thanks again for the advice.
Regards,
David Kuechenmeister
“Mario Charest” <> goto@nothingness.com> > wrote in message
news:a923kc$4jt$> 1@inn.qnx.com> …
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in
message
news:a922kc$qum$> 1@nntp.qnx.com> …
I’m trying to synchronize several threads, all in different
processes
and
at
different rates, with an interrupt from a hardware timer. The ISR,
much
to
my dismay, can’t send messages, release semaphores, or any of the
other
non-blocking kernel calls that I am accustomed to using in vxWorks
and
other
RTOSs. I need to unblock one or several of these threads,
depending
on
the
clock tick, i.e. the 100Hz thread runs each tick, the 50Hz on
every
other,
the 20Hz every fifth tick, and so on. What I would like to do is
send
a
message to each thread that needs to unblock from the ISR.
It looks like all an ISR CAN do is return a sigevent destined for
a
single
thread. It seems backwards to use the clock to interrupt the
processor,
only
to require that the ISR unblock a scheduling thread to wake up the
other
threads, but that is the way QNX appears to be leading me.
IMHO ISR are meant to be FAST (an furious), sending messages from
inside
an ISR is a very bad idea (imagine if it would have to go over the
network),
the ISR would take forever. So is sending pulses to 100 threads for
example.
Is there a way to direct multiple pulses/events or whatever to the
threads
I
need to unblock, all while still in the ISR?
No.
If your events are based on the timer interrupt why don’t you just
used
timers?
Other solution is to not use ISR but rather InterruptAttachEvent().
Then
your handler (which isn’t running in an ISR context) is free to do
what
ever it wants (barrier, mutext, semaphore, etc ) to unblock the
threads.
Thanks,
David Kuechenmeister
mailto:> david.kuechenmeister@viasat.com
\