How to mask IRQ

[Joel Sherrill <joel@OARcorp.com>]

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.

> wkr,
> Thomas.
> 
> 
> 
> 
> 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 at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985