“Rennie Allen” <firstname.lastname@example.org> wrote in message
You could also attach two (or more proxies) and have your single
interrupt handler (attached to all the h/w interrupts you will service)
return with the proxy that represents the IRQ that was triggered. Of
course, Bert’s suggestion is fundamentally the same (six of one - half
dozen of the other) - take your choice.
…so. if i understand it correct the question was: how to determine inside
interrupt handling function which IRQ was triggered in order to return
according proxy (previously attached of course and so on) ? i see at least
first is you can determine which IRQ was triggered by asking it from your
reall hardware. for example, UARTs 8250 and upper have a state register
which bits define the reason of triggered IRQ i.e. it was generated course
of RX buffer is full or TX buffer is empty or line error detected or any
combination of them. if you need to support several alike devices
(COM1/COM2) with the same interrupt handler, you can read this register for
all UARTs and trigger appropriate proxy.
second is that you can ask according Programmable Interrupt Controller (PIC,
first or second for AT) about its IRQ requests currently been in service.
note that if nested interrupts are enabled then there can be more then one
interrupt in service at this moment (nested interrupts).
third is that you can determine which IRQ was fired from appropriate first
level Interrupt Service Routine (ISR) is called then just map software
interrupt number into IRQ number and pass this value into upper level
interrupt handling routine. or at least pass there number of software
interrupt so routine could map it by itself.
which way to choose… under dos i used second or third methods due to if
carefully coded it’s a way more universal. under qnx4 i usually prefer to
stay away from manual PICs programming and qnx4 kernel’s first level ISRs
don’t pass nor interrupt nor mapped IRQ numbers into attached user interrupt
handlers so i use first method or if just attach one interrupt handler per
Davide Ancri wrote:
Thanks Bert, the approach you describe it’s the one I’ve started working
Bert Menkveld wrote:
I think the simplest and cleanest way to get this info is to attach a
separate interrupt handler for each interrupt. This may seem
but in reality you’re not likely to have more than a few different
interrupts to handle. You can still have each handler call a common
function to perform whatever common code you need to handle each
Corman Technologies Inc.