ISR Misses Interrupts

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I’m having another odd problem this week. I have a FPGA generating a 600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours), but
then it starts to miss the interrupts. When this mode starts, the ISR will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first thing I
do after unblocking from the InterruptWait, in my handler thread, is to call
InterruptUnmask.

Is there anything there any task that could be pre-empting the ISR and
causing the interrupt to be lost from the queue? This is QNX 6.1 on a 166
MHz PC-104.

Thanks for the help.

David Kuechenmeister

2

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote in message
news:arm41i$12h$1@inn.qnx.com…

I’m having another odd problem this week. I have a FPGA generating a 600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours), but
then it starts to miss the interrupts. When this mode starts, the ISR will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first thing
I
do after unblocking from the InterruptWait, in my handler thread, is to
call
InterruptUnmask.

Can you clairify that it is in fact the ISR handler and not the interrupt
event driven thread that is “missing” interrupts. Also, what platform are
you targeting? x86?

Is there anything there any task that could be pre-empting the ISR and
causing the interrupt to be lost from the queue? This is QNX 6.1 on a 166
MHz PC-104.

Preemption of the ISR can occur by anybody with a higher priority IRQ.
There can be a world of time between the dispatching of the interrupt
event, and the scheduling of your interrupt handling thread - which means
you could be potentially leaving that interrupt masked for too long?

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

3

Thanks Adam,

Sorry, my nomenclature seems to be a bit different. My ISR is the the code
that actually services the interrupt. My Interrupt Handler is the code that
attaches the interrupt, waits for the ISR to return, sends some messages to
other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

It is the ISR that seems to be “missing” the hardware interrupts on IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my IRQ 7
arrived, the ISR would be called when it was rescheduled.

I noticed you mentioned that the interrupt could be masked for too long. I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source and
before the ISR returns?

For your information, I used the examples in the sdk help at
<QNXsdk\target\qnx6\usr\help\product\neutrino_2.11_en\prog\inthandler.html>
to create my ISR and Interrupt handler.

Thanks again,
Dave

“Adam Mallory” <amallory@qnx.com> wrote in message
news:arm5qi$j46$1@nntp.qnx.com…

David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in message
news:arm41i$12h$> 1@inn.qnx.com> …
I’m having another odd problem this week. I have a FPGA generating a
600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours), but
then it starts to miss the interrupts. When this mode starts, the ISR
will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first
thing
I
do after unblocking from the InterruptWait, in my handler thread, is to
call
InterruptUnmask.

Can you clairify that it is in fact the ISR handler and not the interrupt
event driven thread that is “missing” interrupts. Also, what platform are
you targeting? x86?

Is there anything there any task that could be pre-empting the ISR and
causing the interrupt to be lost from the queue? This is QNX 6.1 on a
166
MHz PC-104.

Preemption of the ISR can occur by anybody with a higher priority IRQ.
There can be a world of time between the dispatching of the interrupt
event, and the scheduling of your interrupt handling thread - which means
you could be potentially leaving that interrupt masked for too long?

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

4

Sorry, my nomenclature seems to be a bit different. My ISR is the the code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages
to
other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

Ok, so ISR = code running at interrupt time, and “interrupt handler” refers
to code that runs at user process time.

It is the ISR that seems to be “missing” the hardware interrupts on IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my IRQ
7
arrived, the ISR would be called when it was rescheduled.

Interrupts are not queued on the 8259PIC, an IRQ just remains pending
regardless of if 1 or 100 requests occured.

How are you determining that interrupts are being lost? If it’s a counter,
are you decalaring the counter to be volatile (variables an ISR touches
should be declared volatile as a rule)?

I noticed you mentioned that the interrupt could be masked for too long. I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source and
before the ISR returns?

The procedure is fine, just be aware, that the time between the return from
an ISR and the scheduling of the thread containing the interrupt handler
could be really long depending on the number of ready higher priority
threads than your thread.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

5

Hi David,

The first thing I would suggest you to do, check CPU load. The 600Hz rate
for 166MHz computer may be critical depending what processing do you do.
Another check you can do unmask the interrupt inside the interrupt handler
and put some counter there, and put another counter after InterruptWait().
In this case if you CPU doesn’t have enough power, you’ll see that first
counter is greater than second because pulses generated by IRQ handler are
queued.

We have the similar system. We collect data from 2 FPGAs, do some math and
report the results to next level. To make this thing fly on 1.6Khz we needed
P III 1.2GHz. We also managed to achieve the same functionality on P266, but
at about 500Hz rate only.

Sincerely,

Serge

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:arm76j$4lq$1@inn.qnx.com…

Thanks Adam,

Sorry, my nomenclature seems to be a bit different. My ISR is the the code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages
to
other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

It is the ISR that seems to be “missing” the hardware interrupts on IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my IRQ
7
arrived, the ISR would be called when it was rescheduled.

I noticed you mentioned that the interrupt could be masked for too long. I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source and
before the ISR returns?

For your information, I used the examples in the sdk help at

QNXsdk\target\qnx6\usr\help\product\neutrino_2.11_en\prog\inthandler.html
to create my ISR and Interrupt handler.

Thanks again,
Dave

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:arm5qi$j46$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in message
news:arm41i$12h$> 1@inn.qnx.com> …
I’m having another odd problem this week. I have a FPGA generating a
600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours),
but
then it starts to miss the interrupts. When this mode starts, the ISR
will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first
thing
I
do after unblocking from the InterruptWait, in my handler thread, is
to
call
InterruptUnmask.

Can you clairify that it is in fact the ISR handler and not the
interrupt
event driven thread that is “missing” interrupts. Also, what platform
are
you targeting? x86?

Is there anything there any task that could be pre-empting the ISR and
causing the interrupt to be lost from the queue? This is QNX 6.1 on a
166
MHz PC-104.

Preemption of the ISR can occur by anybody with a higher priority IRQ.
There can be a world of time between the dispatching of the interrupt
event, and the scheduling of your interrupt handling thread - which
means
you could be potentially leaving that interrupt masked for too long?

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

\

6

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:arm76j$4lq$1@inn.qnx.com…

Thanks Adam,

Sorry, my nomenclature seems to be a bit different. My ISR is the the code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages

Sends some messages? What type of messages? All you are allow to do in an
interrutp handler (as opposose to interrupt event handler) is return a
sig_event.

other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

It is the ISR that seems to be “missing” the hardware interrupts on IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my IRQ
7
arrived, the ISR would be called when it was rescheduled.

I noticed you mentioned that the interrupt could be masked for too long. I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source and
before the ISR returns?

For your information, I used the examples in the sdk help at

QNXsdk\target\qnx6\usr\help\product\neutrino_2.11_en\prog\inthandler.html
to create my ISR and Interrupt handler.

Thanks again,
Dave

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:arm5qi$j46$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in message
news:arm41i$12h$> 1@inn.qnx.com> …
I’m having another odd problem this week. I have a FPGA generating a
600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours),
but
then it starts to miss the interrupts. When this mode starts, the ISR
will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first
thing
I
do after unblocking from the InterruptWait, in my handler thread, is
to
call
InterruptUnmask.

Can you clairify that it is in fact the ISR handler and not the
interrupt
event driven thread that is “missing” interrupts. Also, what platform
are
you targeting? x86?

Is there anything there any task that could be pre-empting the ISR and
causing the interrupt to be lost from the queue? This is QNX 6.1 on a
166
MHz PC-104.

Preemption of the ISR can occur by anybody with a higher priority IRQ.
There can be a world of time between the dispatching of the interrupt
event, and the scheduling of your interrupt handling thread - which
means
you could be potentially leaving that interrupt masked for too long?

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

\

7

“Adam Mallory” <amallory@qnx.com> wrote in message
news:armc5b$ml6$1@nntp.qnx.com…

Sorry, my nomenclature seems to be a bit different. My ISR is the the
code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages
to
other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

Ok, so ISR = code running at interrupt time, and “interrupt handler”
refers
to code that runs at user process time.

It is the ISR that seems to be “missing” the hardware interrupts on
IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my
IRQ
7
arrived, the ISR would be called when it was rescheduled.

Interrupts are not queued on the 8259PIC, an IRQ just remains pending
regardless of if 1 or 100 requests occured.

I wasn’t familiar with Intel products until recently, so I did my homework
on the 8259PIC this weekend. Now, I understand more about the hierarchy of
x86 interrupts. It is a little bit different than my favorite Motorola
processors.

How are you determining that interrupts are being lost? If it’s a
counter,
are you decalaring the counter to be volatile (variables an ISR touches
should be declared volatile as a rule)?

I have the FPGA write a pulse to a discrete output. I have the ISR toggle a
discrete output after clearing the FPGAs interrupt. Then I just watch the
show on a 'scope. I added volatile to the declaration of the register
contents that I use to write the discretes from the ISR. That might have
caused some problems.

I noticed you mentioned that the interrupt could be masked for too long.
I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source
and
before the ISR returns?

The procedure is fine, just be aware, that the time between the return
from
an ISR and the scheduling of the thread containing the interrupt handler
could be really long depending on the number of ready higher priority
threads than your thread.

This is my data acquisition timing thread. I’ve made it the highest priority
thread in the application. The only higher thread would be something in the
OS.

Thanks again Adam.

Regards,
Dave Kuechenmeister

8

Serge,
Thanks for a couple good suggestions. Is there a way to WAG the CPU load?
I don’t know enough about all the QNX utilities to know to do that. I this
is a problem we will have to face, even if it doesn’t have a direct bearing
on this particular problem.

Regards,
Dave


“Serge Yuschenko” <serge.yuschenko@rogers.com> wrote in message
news:arohle$kg6$1@inn.qnx.com…

Hi David,

The first thing I would suggest you to do, check CPU load. The 600Hz rate
for 166MHz computer may be critical depending what processing do you do.
Another check you can do unmask the interrupt inside the interrupt handler
and put some counter there, and put another counter after InterruptWait().
In this case if you CPU doesn’t have enough power, you’ll see that first
counter is greater than second because pulses generated by IRQ handler are
queued.

We have the similar system. We collect data from 2 FPGAs, do some math and
report the results to next level. To make this thing fly on 1.6Khz we
needed
P III 1.2GHz. We also managed to achieve the same functionality on P266,
but
at about 500Hz rate only.

Sincerely,

Serge

“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:arm76j$4lq$> 1@inn.qnx.com> …
Thanks Adam,

Sorry, my nomenclature seems to be a bit different. My ISR is the the
code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages
to
other processes, etc. I am using a x86 platform on a
WinSystems PC-104 card.

It is the ISR that seems to be “missing” the hardware interrupts on
IRQ7.
That’s why I’m puzzled. I thought that the interrupts would be queued so
that even if my ISR was pre-empted or interrupts were disabled when my
IRQ
7
arrived, the ISR would be called when it was rescheduled.

I noticed you mentioned that the interrupt could be masked for too long.
I
thought I was using the recommended procedure for masking and unmasking
interrupts. Should I unmask the interrupt after I’ve reset the source
and
before the ISR returns?

For your information, I used the examples in the sdk help at


QNXsdk\target\qnx6\usr\help\product\neutrino_2.11_en\prog\inthandler.html
to create my ISR and Interrupt handler.

Thanks again,
Dave

“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:arm5qi$j46$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in
message
news:arm41i$12h$> 1@inn.qnx.com> …
I’m having another odd problem this week. I have a FPGA generating a
600Hz
interrupt on IRQ 7. My ISR works fine for a while ( 12 to 24 hours),
but
then it starts to miss the interrupts. When this mode starts, the
ISR
will
miss one out of around every ten interrupts.

The first thing I do in the ISR is call InterruptMask and the first
thing
I
do after unblocking from the InterruptWait, in my handler thread, is
to
call
InterruptUnmask.

Can you clairify that it is in fact the ISR handler and not the
interrupt
event driven thread that is “missing” interrupts. Also, what platform
are
you targeting? x86?

Is there anything there any task that could be pre-empting the ISR
and
causing the interrupt to be lost from the queue? This is QNX 6.1 on
a
166
MHz PC-104.

Preemption of the ISR can occur by anybody with a higher priority IRQ.
There can be a world of time between the dispatching of the
interrupt
event, and the scheduling of your interrupt handling thread - which
means
you could be potentially leaving that interrupt masked for too long?

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net



\

9

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:arr5j3$g96$1@inn.qnx.com…

“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:arm76j$4lq$> 1@inn.qnx.com> …
Thanks Adam,

Sorry, my nomenclature seems to be a bit different. My ISR is the the
code
that actually services the interrupt. My Interrupt Handler is the code
that
attaches the interrupt, waits for the ISR to return, sends some messages

Sends some messages? What type of messages? All you are allow to do in
an
interrutp handler (as opposose to interrupt event handler) is return a
sig_event.

I think there is a little difference in our terminology. My Interrupt
handler blocks on a InterruptWait(), then sends the messages. My ISR
services the hardware interrupt. It returns a sig_event.

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give semaphores,
and make other potentially disasterous calls in the ISR. But that isn’t
going to change and I’ll deal with it.

Sincerely,
David Kuechenmeister

10

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give semaphores,
and make other potentially disasterous calls in the ISR. But that isn’t
going to change and I’ll deal with it.

It’s not just about shooting yourself in the foot, we let you do that in
lots of places. It also has to do with over complicating the kernel
entry/exit/call sequences and making them longer than they need to be.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

11

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give semaphores,
and make other potentially disasterous calls in the ISR.

Oh, but we do permit you do make such potentially disastrous calls
from within an ISR. We just warn you that disaster will strike almost
100% of the time.

Or, to put it another way, we don’t have code that detects that you
made one of these calls in an ISR, and halts the OS on purpose. Rather,
the OS generally enters an unrecoverable disaster state because you did
it, and halts.

-David

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

12

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:artjfm$1c9$3@nntp.qnx.com…

David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give
semaphores,
and make other potentially disasterous calls in the ISR.

Oh, but we do permit you do make such potentially disastrous calls
from within an ISR. We just warn you that disaster will strike almost
100% of the time.

Or, to put it another way, we don’t have code that detects that you
made one of these calls in an ISR, and halts the OS on purpose. Rather,
the OS generally enters an unrecoverable disaster state because you did
it, and halts.

Good, I like to learn new things. Especially when it looks like Neutrino
will be a part of my job for some time to come.

Okay, so I try to do a sem_post() in an ISR. The call doesn’t block, like a
MsgSend would. Why isn’t it ISR-safe? I guess the question is valid for a
MsgSendPulse call too? I’m just planning to synchronize a process on the
same processor, no SMP or networking involved.

Does this go back to the more complicated ISR exit procedures that are
required to implement these calls?

Thanks,
David Kuechenmeister

13

David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:


Good, I like to learn new things. Especially when it looks like Neutrino
will be a part of my job for some time to come.

Okay, so I try to do a sem_post() in an ISR. The call doesn’t block, like a
MsgSend would. Why isn’t it ISR-safe? I guess the question is valid for a
MsgSendPulse call too? I’m just planning to synchronize a process on the
same processor, no SMP or networking involved.

Does this go back to the more complicated ISR exit procedures that are
required to implement these calls?

I’m not a kernel coder, so this explanation is just my understanding.

Most paths through the kernel are fully, or nearly fully interruptible.
To allow the kernel (in general) to be re-entrant from ISRs would have
required more work on all kernel calls, and more work on the switch
to handling an interrupt. Or, it would have required disabling
interrupts for much longer chunks of the kernel code. This would have
resulted in a far higher interrupt latency, and more expensive kernel
operations. Instead, we documented that (essentially) all kernel calls
are not safe to use from an ISR, and specified the method of notification
that was allowed – the returning of struct sigevent pointer.

-David

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

14

Most paths through the kernel are fully, or nearly fully interruptible.
To allow the kernel (in general) to be re-entrant from ISRs would have
required more work on all kernel calls, and more work on the switch
to handling an interrupt. Or, it would have required disabling
interrupts for much longer chunks of the kernel code. This would have
resulted in a far higher interrupt latency, and more expensive kernel
operations. Instead, we documented that (essentially) all kernel calls
are not safe to use from an ISR, and specified the method of notification
that was allowed – the returning of struct sigevent pointer.

Or that a sem_post() can/will causing scheduling requirements to change;
something you’d rather not do at ISR time since the lists you’d need to
traverse might be long. In a more general sense, a kernel call could result
in a deep call stack (which is also dangerous, since your stack is small in
the ISR case), and that call could also result in a block (pagewait comes to
mind) or an unacceptable delay. You’re basically throwing latency to the
wind and saying you don’t care if you ever come out of your ISR anytime
soon - not a great philosophy in an ISR IMHO.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

15

Also, when you are running an ISR you are basically in the context
of the kernel itself (depends on the CPU architecture). It really
isn’t a good idea to make a kernel call inside of the kernel. When you
are in the kernel what process are you (I don’t belive that neutrino makes
any assurances)? That is why you “return” a sigevent_t and not call
MsgDeliverEvent(). Then the kernel can do the work it normally would do
with for a MsgDeliverEvent() with the structure you passed back to it.

On a mono-kernel, since your ISR would be linked into the kernel at
compile time, you would have access to the kernel’s internal symbols and
functions. So instead of making a kernel call you just call what you need
directly. Things have to be a little more restrictive with a ukernel. But
this does tend to lead to better written ISRs as you aren’t free to go off
do what you like in a critical path. :slight_smile:

chris


Adam Mallory <amallory@qnx.com> wrote:

Most paths through the kernel are fully, or nearly fully interruptible.
To allow the kernel (in general) to be re-entrant from ISRs would have
required more work on all kernel calls, and more work on the switch
to handling an interrupt. Or, it would have required disabling
interrupts for much longer chunks of the kernel code. This would have
resulted in a far higher interrupt latency, and more expensive kernel
operations. Instead, we documented that (essentially) all kernel calls
are not safe to use from an ISR, and specified the method of notification
that was allowed – the returning of struct sigevent pointer.

Or that a sem_post() can/will causing scheduling requirements to change;
something you’d rather not do at ISR time since the lists you’d need to
traverse might be long. In a more general sense, a kernel call could result
in a deep call stack (which is also dangerous, since your stack is small in
the ISR case), and that call could also result in a block (pagewait comes to
mind) or an unacceptable delay. You’re basically throwing latency to the
wind and saying you don’t care if you ever come out of your ISR anytime
soon - not a great philosophy in an ISR IMHO.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
\

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

16

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:art6r9$ng5$1@inn.qnx.com…

Serge,
Thanks for a couple good suggestions. Is there a way to WAG the CPU
load?
I don’t know enough about all the QNX utilities to know to do that. I this
is a problem we will have to face, even if it doesn’t have a direct
bearing
on this particular problem.

No problem.

This is the stuff that does the job:
http://qnx.wox.org/qnx/sources/load-src.tar.gz

Regards,
Dave

17

Thanks very much for the lesson, gentlemen.

As far as my original problem goes, it appears the interrupt from the FPGA
may be the culprit. Thanks for the assistance.

Sincerely,
David Kuechenmeister


“Chris McKillop” <cdm@qnx.com> wrote in message
news:arub4p$gaj$1@nntp.qnx.com…

Also, when you are running an ISR you are basically in the context
of the kernel itself (depends on the CPU architecture). It really
isn’t a good idea to make a kernel call inside of the kernel. When you
are in the kernel what process are you (I don’t belive that neutrino makes
any assurances)? That is why you “return” a sigevent_t and not call
MsgDeliverEvent(). Then the kernel can do the work it normally would do
with for a MsgDeliverEvent() with the structure you passed back to it.

On a mono-kernel, since your ISR would be linked into the kernel at
compile time, you would have access to the kernel’s internal symbols and
functions. So instead of making a kernel call you just call what you need
directly. Things have to be a little more restrictive with a ukernel.
But
this does tend to lead to better written ISRs as you aren’t free to go off
do what you like in a critical path. > :slight_smile:

chris


Adam Mallory <> amallory@qnx.com> > wrote:
Most paths through the kernel are fully, or nearly fully interruptible.
To allow the kernel (in general) to be re-entrant from ISRs would have
required more work on all kernel calls, and more work on the switch
to handling an interrupt. Or, it would have required disabling
interrupts for much longer chunks of the kernel code. This would have
resulted in a far higher interrupt latency, and more expensive kernel
operations. Instead, we documented that (essentially) all kernel calls
are not safe to use from an ISR, and specified the method of
notification
that was allowed – the returning of struct sigevent pointer.

Or that a sem_post() can/will causing scheduling requirements to change;
something you’d rather not do at ISR time since the lists you’d need to
traverse might be long. In a more general sense, a kernel call could
result
in a deep call stack (which is also dangerous, since your stack is small
in
the ISR case), and that call could also result in a block (pagewait
comes to
mind) or an unacceptable delay. You’re basically throwing latency to
the
wind and saying you don’t care if you ever come out of your ISR anytime
soon - not a great philosophy in an ISR IMHO.

–

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net



\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

18

Hi Dave

Allowing messages from ISR would put a big burden on the OS. One that most
of us don’t want at a critical time.

But it is very easy to get around this. Let your interrupt handler do the
messaging.

“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:art76b$oc9$1@inn.qnx.com…

I think there is a little difference in our terminology. My Interrupt
handler blocks on a InterruptWait(), then sends the messages. My ISR
services the hardware interrupt. It returns a sig_event.

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give semaphores,
and make other potentially disasterous calls in the ISR. But that isn’t
going to change and I’ll deal with it.

Sincerely,
David Kuechenmeister

19

Hi Bill,
I’m starting to understand the differences between the micro kernel that
RTP uses, vis the big kernel RTOSes that I’m familiar with. I know where I
want to go, it just isn’t a straight line anymore.

I wouldn’t expect to do a FFT in an ISR, but if I am using the interrupt
to time a task, I would like to give a semaphore to the pended task
directly, wthout having to context switch to a handling thread where I send
a pulse. Or if I collect a bunch of data, I’d like to send it to the
consumer in a non-blocking message rather than context switch to a handler
that unblocks the data collection task. When your dealing with high
interrupt rates, I think this extra context switching can force one to a
faster, more expensive processor that would be required otherwise. For
instance, with a big kernel RTOS, I was able to able to collect data, pack a
message, and send it to the consumer task – all in a ISR servicing a 5 KHz
interrupt. That was on a 25 MHz MVME68040. Right now, I’m having a rough
time servicing a 600 Hz interrupt and performing some associated data
collection and processing on a P166. I’ll probably find a bone-headed thing
that I’ve done that slows it down, but it isn’t obvious, yet.

Again, the difference is that I used to be able to link the kernel along
with the application, so that messaging was easy for the kernel to sort out.
Not so, now. I’m probably still missing the point of a micro kernel, but I
do think it poses some limitations in these particular cases.

Thanks for the advice. I know I’ll need more.

Sincerely,

Dave Kuechenmeister

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

Hi Dave

Allowing messages from ISR would put a big burden on the OS. One that
most
of us don’t want at a critical time.

But it is very easy to get around this. Let your interrupt handler do the
messaging.

“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:art76b$oc9$> 1@inn.qnx.com> …

I think there is a little difference in our terminology. My Interrupt
handler blocks on a InterruptWait(), then sends the messages. My ISR
services the hardware interrupt. It returns a sig_event.

However, this is one of the things I consider flawed in QNX. Programmers
should be permitted, at their own risk, to send messages, give
semaphores,
and make other potentially disasterous calls in the ISR. But that isn’t
going to change and I’ll deal with it.

Sincerely,
David Kuechenmeister
\

20

[SNIP]

faster, more expensive processor that would be required otherwise. For
instance, with a big kernel RTOS, I was able to able to collect data, pack a
message, and send it to the consumer task – all in a ISR servicing a 5 KHz
interrupt. That was on a 25 MHz MVME68040. Right now, I’m having a rough
time servicing a 600 Hz interrupt and performing some associated data
collection and processing on a P166. I’ll probably find a bone-headed thing
that I’ve done that slows it down, but it isn’t obvious, yet.

You might want to look at the I/O overhead on the PC vs. on the 68K as well.
At 600Hz you are looking at about 1.5ms between each cycle. I assume
you are either running your tasks at a priority higher then the rest of a
standard QNX6 install or you are running this on a custom setup that doesn’t
have any other CPU eating processes running. So we are looking at 2-3
context switches on each interrupt. On my P166 running QNX I have a context
switch time of about 5us. So we are looking at about 15-20us of OS overhead
for context switches.

I mocked up a little test case, http://qnx.wox.org/qnx/sources/fakeint.c.
This is running on my P166 right now and I am using about 0.15% of the CPU.
The test grabs the timer interrupt (0), which fires every ~1ms. It then
signals another process to write data into a consumer process (/dev/null).

So, I am not sure you can easily blame context-switch overhead.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/