Max time for IRQ handler?

I use qnx_hint_attach for hardware irq. I’d like to know how long
would be considered too long.

At the moment processor is some Pentium running 700 Mhz.


M. Tavasti / tavastixx@iki.fi / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address

“M. Tavasti” <tavastixx@iki.fi.invalid> wrote in message
news:m2it90b6d7.fsf@akvavitix.vuovasti.com

I use qnx_hint_attach for hardware irq. I’d like to know how long
would be considered too long.

I think that’s subjective. If for example you don’t have a network card
nor a HD (booting from flash), it could probably be as long as 1ms.

It’s all depends on the price you are willing to pay. If you don’t mind
loosing network packet, loosing data on serial port, slow HD and network
performance you can make it very long…

It also depends on the rate of the IRQ, if it comes once every 10 seconds,
making it 1ms is not big deal, but if it comes 10000 a sec and last 50us
you will be consuming 50% of the CPU just for the ISR, that’s bad IMO

My rule of thumb is simple, make it as short as possible, that’s the
real-time
way :wink:

At the moment processor is some Pentium running 700 Mhz.


M. Tavasti / > tavastixx@iki.fi > / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address

Mario Charest wrote:


I think that’s subjective. If for example you don’t have a network card
nor a HD (booting from flash), it could probably be as long as 1ms.

It’s not really subjective; it is determined by the requirements of the
real-time application that is being developed (which the poster made no
reference to). Simply put; the sum of the worst-case execution time for
all interrupt handlers (including any that are being written) must
be a lower number than the minimum response deadline that must be met (a
lot of assumptions in this statement, and of course there are other
issues to consider beside interrupt handlers).

It’s all depends on the price you are willing to pay. If you don’t mind
loosing network packet, loosing data on serial port, slow HD and network
performance you can make it very long…

Hey, this isn’t a windoze ng :wink:


My rule of thumb is simple, make it as short as possible, that’s the
real-time
way > :wink:

I’ll add to this: …make it schedulable as soon as possible, so that
you have control over how the CPU cycles are allocated.

Rennie

“Mario Charest” <goto@nothingness.com> writes:

I use qnx_hint_attach for hardware irq. I’d like to know how long
would be considered too long.
I think that’s subjective. If for example you don’t have a network card
nor a HD (booting from flash), it could probably be as long as 1ms.

What about QNX point of view? When QNX crashes, and prints out
‘interrupt failed’ with stackdump? On early stages of development I
have seen those.

This relates to our problem of whole system freeze on IRQ-handler, and
one suggestions was ‘too long irq time’. IRQ will be fired something
like 50-500 times/second, and it takes 30 us.

However, system works fine most of the time, but we get freeze maybe
once/24 hours. And no stackdump, or anything, just total system
freeze. And it’s not ISR called endlessly.


M. Tavasti / tavastixx@iki.fi / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address

“M. Tavasti” <tavastixx@iki.fi.invalid> wrote in message
news:m2k7tb9kh6.fsf@akvavitix.vuovasti.com

“Mario Charest” <> goto@nothingness.com> > writes:

I use qnx_hint_attach for hardware irq. I’d like to know how long
would be considered too long.
I think that’s subjective. If for example you don’t have a network card
nor a HD (booting from flash), it could probably be as long as 1ms.

What about QNX point of view? When QNX crashes, and prints out
‘interrupt failed’ with stackdump? On early stages of development I
have seen those.

This relates to our problem of whole system freeze on IRQ-handler, and
one suggestions was ‘too long irq time’. IRQ will be fired something
like 50-500 times/second, and it takes 30 us.

500 times/second * (30us + 5us overhead) = 17.5ms total = 1.75% of
the CPU power. Well below anything that could cause problem.

However, system works fine most of the time, but we get freeze maybe
once/24 hours. And no stackdump, or anything, just total system
freeze. And it’s not ISR called endlessly.

Does your board use DMA, if so it could possibly lock up the RAM
thus stalling the CPU.

Is it possible for you to remove the board, and then hook the ISR to
the timer interrupt (intr 0 ) and simulate the behavior of the board. If
you
set the tick size to 1ms, your ISR will be called 1000 per seconds.
If the machine doesn’t crash, problem is definitly hardware related.


M. Tavasti / > tavastixx@iki.fi > / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address

“Mario Charest” <goto@nothingness.com> writes:

Does your board use DMA, if so it could possibly lock up the RAM
thus stalling the CPU.

No, plain memory mapped io.

Is it possible for you to remove the board, and then hook the ISR to
the timer interrupt (intr 0 ) and simulate the behavior of the board. If
you
set the tick size to 1ms, your ISR will be called 1000 per seconds.
If the machine doesn’t crash, problem is definitly hardware related.

I don’t think it’s possible. Or it is, but then interrupt can’t do
‘real’ things, and I don’t think finding real problem without handling
real hardware can be done.


M. Tavasti / tavastixx@iki.fi / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address