Re: Interrupt handling

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

>I've been playing with another microcontroller families recently (Atmel
>AVRs) writting an LGPL'd embedded OS and have ended up with a similar
>sort of design to VSTa where I want to handle all interrupts within
>normally scheduled threads and hit on a slightly different solution - I
>need this because pulling a 1.5k packet out of an ethernet chip with an
>8 bit micro can take serveral ms and I don't want to screw up my UART
>code. Rather than trying to clear the interrupt cause down in the ISR
>(which is what I started doing), my latest tack is to temporarily
>disable the interrupt within the interrupt management unit (effectively
>the PIC) which allows me to leave the ISR, but without upsetting the
>state of the interrupting device. My threads then re-enable the
>interrupt within the IMU once they've handled the interrupting event.
>
>Anyway, the question is: How general a mechanism is this? I know that
>this works for several micro families, but I don't know if there are any
>subtle gotcha's that would cause this to fail on other micros or
>interrupt units.

This approach is OK for smaller scale systems. The underlying assumption is
that interrupt granularity (to wit, masking) matches driver granularity.
I've worked with a number of embedded systems where there are too many
devices sharing the same CPU interrupt level. In some of these systems,
there is a secondary interrupt controller which can mask individual sources.
But then you're back to the same problem--in the kernel, before you return,
being able to decode sources. In some cases, you can do this in a general
way--the secondary interrupt decode logic can be read to determine source.
In others, you have to go query each specific kind of device to find the
"culprit". And then you're right back to the problem of device specific
code needing to run before you can return from kernel mode.

So yes, your approach is a nice middle ground for the middle ground of level
triggered interrupts where each CPU general level corresponds to a
particular device. This would usually work on PC's, but of course one
generally has edge triggered interrupts anyway so it isn't needed.

Andy Valencia
Received on Sun May 28 08:35:28 2000