Synching threads with ISR

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.

Is there a way to direct multiple pulses/events or whatever to the threads I
need to unblock, all while still in the ISR?

Thanks,
David Kuechenmeister
mailto:david.kuechenmeister@viasat.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
\

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. But, I’m
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. 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.

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


\

David Kuechenmeister wrote:

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.

As Mario said, what if you sent a message across the LAN from your ISR ?

Oh, but those big kernel “designers” haven’t even broached the subject
of a network distributed kernel have they ? …so something like a
network semaphore (which QNX has) doesn’t exist in those kernels does it
? You’re right, you do need to make that attitudinal shift out of the
sixties and into the eighties :wink:

the hardware interrupt? If I can’t, the answer does seem to lie with the
InterruptAttachEvent() function.

Yes. InterruptAttachEvent() is what you want to use.

Rennie

Hi David

What you want to do is NOT unreasonable. But currently you can’t do it.

It’s like saying I want to mark off every 15 inches and my only measuring
stick is a 1 foot ruler (1 ms). Apparently you can trade that in for a 6
inch ruler (500 us) but that still doesn’t help you much.

You can write cover functions that check time till the next scheduled timer
tick and do appropriate millisecond sleeps coupled with nanosleep()s but
that is goofy and will actually kill your real-time performance (unless
maybe you have SMP and can afford to spin one of the CPUs). You can
tolerate the frequent over or under-timings but that sucks.

You can generate interrupts with an external device, wake up a thread in the
ISR that wakes up the other threads (which I don’t see as so bad, if I
already owned the external timing device).

The real question is: In today’s world of multi-GHz CPUs, why is it that the
best timer we can get is 1 ms (or .5 ms)? Yes I realize that the more a
timer interrupts the OS the more overhead there is for the OS. But hell, in
the days of 486-DX2s we couldn’t afford to waste 3 % of the CPU cycles. But
now, if I have a 1 GHz CPU and I want to waste 1 % of the CPU (and I know it
wouldn’t actually take 1 %) then damn it, I want to waste 1 % of my CPU!
What does is buy me? I don’t have to write goofy, hoky code, ridiculous
code to wait 1.3 ms.

QSSL, please consider giving us the ability to set timer resolution to say
10 us if we want. You can put a big disclaimer with BIG letters that this
will waste 1 % of my CPU. I’ll bet that the change only involves changing a
constant in an already existing if() statement and another constant where
you have to adjust for the .999347 (or whatever the number was) discrepancy.


“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. But,
I’m
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. 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.

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




\

“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 :wink:

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 :wink:

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




\

I find it amazing that QNX assumes everyone wants to work across networks.
This project doesn’t now and will never have any need for distributed
processing. In fact, in 15 years of bit flipping, I haven’t run across any
embedded project that needed a distributed kernel. Other RTOSs support
scramNet and VME backplanes. If I need multiple processors or remotely
devices, I can use that.

I didn’t want this to turn into “us vs them” thread. We’ve paid the money
and we will have to make QNX work for us. I was trying to put my problems in
a particular context by bringing out examples of my prior experience.

“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB4A6D3.5030809@csical.com

David Kuechenmeister wrote:

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.


As Mario said, what if you sent a message across the LAN from your ISR ?

Oh, but those big kernel “designers” haven’t even broached the subject
of a network distributed kernel have they ? …so something like a
network semaphore (which QNX has) doesn’t exist in those kernels does it
? You’re right, you do need to make that attitudinal shift out of the
sixties and into the eighties > :wink:

the hardware interrupt? If I can’t, the answer does seem to lie with the
InterruptAttachEvent() function.


Yes. InterruptAttachEvent() is what you want to use.

Rennie

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.

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.

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 > :wink:

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 > :wink:

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






\

“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 :wink:

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 > :wink:

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 > :wink:

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








\

David Kuechenmeister wrote:

I find it amazing that QNX assumes everyone wants to work across networks.
This project doesn’t now and will never have any need for distributed
processing. In fact, in 15 years of bit flipping, I haven’t run across any
embedded project that needed a distributed kernel.

I can’t speak for QSSL, but I surely don’t assume that everyone wants to
do distributed real-time, but QSSL have designed an operating system
that makes it possible to do, and to do very well.

In my 15 years of bit flipping I have run across many embedded projects
that ended up costing far less because of the availability of a
distributed kernel (no one doing an embedded system needs an operating
system of any kind, it is simply a question of economics).

Other RTOSs support
scramNet and VME backplanes. If I need multiple processors or remotely
devices, I can use that.

These are expensive, and limited in their capabilities, and comparing
two hardware subsystems to QNXs’ overall distribution capabilities
indicates that you don’t have a full appreciation of what QNXs’
capabilities are. There is nothing wrong with being critical, as long
as you understand what it is your criticizing.

I was trying to put my problems in
a particular context by bringing out examples of my prior experience.

That’s not the way I read it, but I’ll take your word for it.

Rennie

Hi Mario

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize. I don’t think that
anyone will complain that a timer of such fine resolution is off by .01 %.

The time of day clock can then adjust on every 1000000/10 interrupt.

“Mario Charest” <goto@nothingness.com> wrote in message
news:a943kd$ii5$1@inn.qnx.com

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.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:a94avu$njv$1@inn.qnx.com

Hi Mario

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize.

I don’t think that
anyone will complain that a timer of such fine resolution is off by .01 %.

Oh yes there will, lol! But that’ not a good enough reason not to do it.

The time of day clock can then adjust on every 1000000/10 interrupt.

“Mario Charest” <> goto@nothingness.com> > wrote in message
news:a943kd$ii5$> 1@inn.qnx.com> …

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.
\

Bill Caroselli (Q-TPS) wrote:

Hi Mario

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize. I don’t think that
anyone will complain that a timer of such fine resolution is off by .01 %.

Doh ! This freewheeling with the semantics of timers is what Posix
explicitly disallows. I agree that if you only every wanted your code
to run on a PC, that this is acceptable, however, if you change the
semantics of a 1msec delay for the PC then the developer trying to write
portable code has no guarantee whatsoever about how long a program will
block when a 1msec delay is called for (in the Posix case, they know
that it will block at least the time specified - while not the
greatest guarantee, it is better than no guarantee).

Using the RTC on the PC is no big deal if you don’t care about
portability, and Posix compliance is cool if you do care about
portability. QNX allows you to choose.

btw: I do agree that we should be able to set the tick size smaller than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).

Rennie

“Mario Charest” <goto@nothingness.com> wrote

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize.

I don’t think that anyone will complain that a timer of such fine
resolution is off by .01 %.

Oh yes there will, lol! But that’ not a good enough reason not to do it.

Wait a minute! (Or at best .999847ths of a minute) Just stalling 153 ticks

out of every 1000000 does NOT make this timer any more accurate. It’s
precision is what it’s precision is. We can adjust for know discrepencies,
and we should. But we can’t pretend that these timers are all that precise.
They aren’t. They are not claiming that the period is .999847000 us.

Hell it wasn’t too long ago when I’d come in on a Tuesday morning and be
happy if my computer still thought is was Tuesday.

No, no, no!

I’m saying that in the OS for a PC, know that an adjusted tick is actually
9.99847 us. If my C program says delay(1); then the OS should delay 101
times 9.99847 us or 1.00984547 ms.

That is what POSIX demands. The only overhead is a divide operation when
the timer is first set. I’m kind of sure that they need to do a divide in
there anyway.

“Rennie Allen” <rallen@csical.com> wrote in message
news:3CB5BC77.8060707@csical.com

Bill Caroselli (Q-TPS) wrote:

Hi Mario

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize. I don’t think that
anyone will complain that a timer of such fine resolution is off by .01
%.


Doh ! This freewheeling with the semantics of timers is what Posix
explicitly disallows. I agree that if you only every wanted your code
to run on a PC, that this is acceptable, however, if you change the
semantics of a 1msec delay for the PC then the developer trying to write
portable code has no guarantee whatsoever about how long a program will
block when a 1msec delay is called for (in the Posix case, they know
that it will block at least the time specified - while not the
greatest guarantee, it is better than no guarantee).

Using the RTC on the PC is no big deal if you don’t care about
portability, and Posix compliance is cool if you do care about
portability. QNX allows you to choose.

btw: I do agree that we should be able to set the tick size smaller than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).

Rennie

Rennie Allen <rallen@csical.com> wrote:

btw: I do agree that we should be able to set the tick size smaller than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).

Why should the OS impose a limit on this at all? I’m of the
opinion if, as root (which this requires) you want to do a stupid
hardware thing, why should the OS get in the way? If you truly
think you can handle a 10usec ticksize, try setting it. But,
I don’t make these decisions. (The only problem with that some
arbitrary value is the lower bound, is that give it a year, and
that value is too slow/too big again.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Rennie Allen <rallen@csical.com> wrote:

If the hardware limitation is .999847 us then divide (or multiply,
whichever) that by 10 and give us a 10 us ticksize. I don’t think that
anyone will complain that a timer of such fine resolution is off by .01 %.

Doh ! This freewheeling with the semantics of timers is what Posix
explicitly disallows. I agree that if you only every wanted your code
to run on a PC, that this is acceptable, however, if you change the
semantics of a 1msec delay for the PC then the developer trying to write
portable code has no guarantee whatsoever about how long a program will
block when a 1msec delay is called for (in the Posix case, they know
that it will block at least the time specified - while not the
greatest guarantee, it is better than no guarantee).

What other kind of guarantee would you expect?

It wouldn’t be a good idea for POSIX to make us promise you that your
thread will be woken up and actually get enough CPU to get to the first
opcode after the nanosleep() call exactly 1ms from after the first
opcode of nanosleep() was executed, would it?


Wojtek Lerch QNX Software Systems Ltd.

David Gibbs <dagibbs@qnx.com> wrote:

Rennie Allen <> rallen@csical.com> > wrote:

btw: I do agree that we should be able to set the tick size smaller than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).

If you truly think you can handle a 10usec ticksize, try setting it. But,
I don’t make these decisions.

Well, apparently we have been listened to. From the 6.2 docs for
ClockPeriod:

the kernel call limits how small a period can be specified. The
lowest clock period that can currently be set on any machine is 10
microseconds.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Thank you David and all the powers that be at QSSL !

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:a94o3i$r9m$1@nntp.qnx.com

David Gibbs <> dagibbs@qnx.com> > wrote:
Rennie Allen <> rallen@csical.com> > wrote:

btw: I do agree that we should be able to set the tick size smaller
than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).

If you truly think you can handle a 10usec ticksize, try setting it.
But,
I don’t make these decisions.

Well, apparently we have been listened to. From the 6.2 docs for
ClockPeriod:

the kernel call limits how small a period can be specified. The
lowest clock period that can currently be set on any machine is 10
microseconds.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:

Rennie Allen <> rallen@csical.com> > wrote:


btw: I do agree that we should be able to set the tick size smaller than
we currently can on QNX6 (I have made several postings arguing this
position - I happen to think that 100usec is a reasonable limit).


If you truly think you can handle a 10usec ticksize, try setting it. But,
I don’t make these decisions.

I agree, but at one time, Brian had asked for opinions on a reasonable
lower bound.


Well, apparently we have been listened to. From the 6.2 docs for
ClockPeriod:

the kernel call limits how small a period can be specified. The
lowest clock period that can currently be set on any machine is 10
microseconds.

Coooool (I have 6.2 but didn’t notice the change).

Rennie