InterruptAttach()

The following quote is from the Neutrino documentation for the function
InterruptAttach():

“The first process to attach to an interrupt unmasks the interrupt. When
the last process detaches from an interrupt the system masks it.”

Shouldn’t it read, “The first process to attach to an interrupt MASKS
the interrupt. When the last process detaches from an interrupt the
system UNMASKS it.”? If the interrupt were unmasked, wouldn’t it
recurse upon itself?

No, I think the documentation is quite correct. Unmasking an interrupt
means the interrupt is enabled. In other words, once the interrupt is
unmasked, the interrupt will occur when some hardware device actually
activates the interrupt line. With level-sensitive interrupts (such as PCI
bus interrupts), it is true that an interrupt handler will be re-entered as
soon as it exits if the interrupt condition has not been cleared. That’s
why the interrupt handler must poke some appropriate register on the
interrupting device to get it to stop driving the interrupt line active.

When an interrupt is masked, the interrupt controller will simply ignore the
state of the respective interrupt line, and the interrupt handler will never
be entered.

Make sense yet?

Regards,

Bert Menkveld
Engineer
Corman Technologies Inc.


Neutrino User <user@neutrino.org> wrote in message
news:3A68A44D.C3FFD5A6@neutrino.org

The following quote is from the Neutrino documentation for the function
InterruptAttach():

“The first process to attach to an interrupt unmasks the interrupt. When
the last process detaches from an interrupt the system masks it.”

Shouldn’t it read, “The first process to attach to an interrupt MASKS
the interrupt. When the last process detaches from an interrupt the
system UNMASKS it.”? If the interrupt were unmasked, wouldn’t it
recurse upon itself?

OK, I understand what you said and all, but my question is this - if the
interrupt is unmasked (enabled) while it is executing its ISR, won’t it recurse
into itself? Don’t you want the interrupt masked (disabled) until the hardware
is twiddled to “service” the interrupt request?

I guess where I’m going with this is that I want other system interrupts to be
able to interrupt my ISR, regardless of priority. If my ISR is long (I don’t
know what “long” is for Neutrino - I’m used to 8-bit uPs where a few uS is a
LONG time), I want to get my most important things done first, then enable all
other system interrupts, and finish whatever needs to be done (logic that would
potentially allow recursion).

It looks like that state of the OS during my ISR is that all interrupts are
unmasked (enabled). If that’s the case I assume that only a higher priority
interrupt will interrupt my ISR - can I change my interrupts’ priority? It
looks like I can in the uP, but does the OS support this level of
functionality? If so, I can’t find any mention in the docs. I hate to hack
something.

Bert Menkveld wrote:

No, I think the documentation is quite correct. Unmasking an interrupt
means the interrupt is enabled. In other words, once the interrupt is
unmasked, the interrupt will occur when some hardware device actually
activates the interrupt line. With level-sensitive interrupts (such as PCI
bus interrupts), it is true that an interrupt handler will be re-entered as
soon as it exits if the interrupt condition has not been cleared. That’s
why the interrupt handler must poke some appropriate register on the
interrupting device to get it to stop driving the interrupt line active.

When an interrupt is masked, the interrupt controller will simply ignore the
state of the respective interrupt line, and the interrupt handler will never
be entered.

Make sense yet?

Regards,

Bert Menkveld
Engineer
Corman Technologies Inc.

Neutrino User <> user@neutrino.org> > wrote in message
news:> 3A68A44D.C3FFD5A6@neutrino.org> …
The following quote is from the Neutrino documentation for the function
InterruptAttach():

“The first process to attach to an interrupt unmasks the interrupt. When
the last process detaches from an interrupt the system masks it.”

Shouldn’t it read, “The first process to attach to an interrupt MASKS
the interrupt. When the last process detaches from an interrupt the
system UNMASKS it.”? If the interrupt were unmasked, wouldn’t it
recurse upon itself?

“Neutrino User” <user@neutrino.org> wrote in message
news:3A759604.B2B85E70@neutrino.org

OK, I understand what you said and all, but my question is this - if the
interrupt is unmasked (enabled) while it is executing its ISR, won’t it
recurse
into itself?

No, not if the hardware interrupts are level sensitive, and all interrupt
sources are cleared before returning from the ISR.

Don’t you want the interrupt masked (disabled) until the
hardware
is twiddled to “service” the interrupt request?

With edge triggered interrupts perhaps, but even then, your ISR should be
sufficiently fast wrt the hardware to prevent re-entrancy.

I guess where I’m going with this is that I want other system interrupts
to be
able to interrupt my ISR, regardless of priority. If my ISR is long (I
don’t
know what “long” is for Neutrino - I’m used to 8-bit uPs where a few uS is
a
LONG time), I want to get my most important things done first, then enable
all
other system interrupts, and finish whatever needs to be done (logic that
would
potentially allow recursion).

In Neutrino, on modern hardware 1 us is a reasonable time to complete an
ISR, and trigger a pulse which is scheduled by priority. Don’t do anything
for a long time in the interrupt handler, just clear the interrupt source
and trigger the pulse. Let the pulse handler do the bulk of the work, as it
is schedulable.

It looks like that state of the OS during my ISR is that all interrupts
are
unmasked (enabled). If that’s the case I assume that only a higher
priority
interrupt will interrupt my ISR - can I change my interrupts’ priority?

QNX 4 used to have an option for this, but procnto doesn’t appear to. It is
basically, a moot point, since you should let the scheduler schedule (after
all that is one of the things your paying for when you buy QNX).

It
looks like I can in the uP, but does the OS support this level of
functionality?

Sure it does. QNX has a priority driven pre-emptive scheduler.

Neutrino User <user@neutrino.org> wrote:

OK, I understand what you said and all, but my question is this - if the
interrupt is unmasked (enabled) while it is executing its ISR, won’t it recurse
into itself?

No, the hardware doesn’t work that way. Your I/O card pulls the line
high, causing the interrupt controller to generate an interrupt. Until
that interrupt has been acknowledged by the issuing of an end of interrupt
(eoi) to it, another interrupt will not be generated. When the EOI
is issued, the controller will, then, determine if it needs to generate
a new interrupt (possibly immediately in the level-triggered case), and
generate another interrupt at the appropriate time. You won’t get another
interrupt while in the ISR. (Note, under QNX – NTO or 4 – the OS issues
the EOI, your ISR doesn’t have to, and should NOT do so.)

I guess where I’m going with this is that I want other system interrupts
to be able to interrupt my ISR, regardless of priority.

Again, can’t be done – the hardware doesn’t work that way. Different
interrupts have different priorities (and not all controllers or hw
have different priority irqs, or may have several lines with the same
priority, or all irqs with the same priority), and only a higher priority
interrupt will interrupt your ISR. NOTE: this has nothing to do with the
priority of the process/thread that attached the ISR, this is a hardware
priority, not a software (OS) priority.


It looks like that state of the OS during my ISR is that all interrupts are
unmasked (enabled).

Yup.

If that’s the case I assume that only a higher priority
interrupt will interrupt my ISR - can I change my interrupts’ priority?

It depends on the hardware – generally you’d have to mess with the startup
code that initializes the interrupt controller.

-David

QNX Training Services
dagibbs@qnx.com