[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to mask IRQ

Thomas Doerfler wrote:
Hello Sergei,

I have read the current discussion and what I do not yet understand in
your approach is how you manage interrupts between the "off the shelf"
BSP drivers and the application specific interrupts. When you "manually
manage" IRQ masks in the interrupt handlers, they get more and more
board specific and writing portable drivers might get more difficult.

All in all I think that, although your approach looks promising, it
would require (another) major rework of the RTEMS interrupt API. We
already have two APIs now and I think for RTEMS it is a bad idea to get
a third one.

I think the initial request from Leon should be considered, to extend
the "new exception processing" API with some means to disable/enable
certain interrupt controller inputs either from application level (well,
we already have that, I think) or from within an interrupt handler. IMHO
 it would be nice if any interrupt handler can enable/disable the
request input of any other interrupt source, therefore I would recommend
not to use a special return value to manage this, but function calls to
manage this.

Any comments?

I think it is important to point out that Jennifer made significant
progress in making the x86, PowerPC, and ARM interrupt processing adhere to the same API. This work is on the CVS head.

For the PowerPC, there is only the new exception model on all but the
PPC4xx models which (unfortunately) are still only old exception model.

I would rather see explicit calls since return values tend to be fragile.


Sergei Organov schrieb:

As an example, our data recording system needs to acquire upto 12 fast
input channels, while acquired messages must be time stamped with high
accuracy. Obviously, the faster the channel the more time stamp error
is significant...:-))

Summarizing my opinion, I think this will be great to have two (enough?) interrupts processing models - one existing (Eric - thanks!) and one Sergei talks about, but how to implement this?

Those one I talk about was there before Eric's work, and still is, so we
already have two of them. However, having two interrupt processing
models is not a good solution, IMHO. Though I don't believe automatic
interrupts prioritization worth the trouble especially when no PIC is
available, it could be done using the model I advocate by means of
manually managing the IRQ masks in the ISR handlers. Besides, that's
what the original post was all about, -- inability to manage IRQ masks
from interrupt handler.

Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985