How to mask IRQ

[Sergei Organov]

leonp at plris.com writes:

> On Tuesday, 31 в▒May 2005 14:34, Sergei Organov wrote:
> > So, what do you think is the meaning of "RT" in "RTEMS"? ;) IMHO, one of
> > the purposes of RTOS is to make it possible to design RT systems without
> > huge, ugly, multi-level, multi-priority interrupt handlers mess. The
> > design of any RTOS and RTEMS in particular is centered around the idea
> > of having fast small interrupt handlers and threads doing most of actual
> > work.
> >
> > I do program actual production RT systems. My experience is that context
> > switch overhead is not that high for most cases, and where it is, one
> > could enable interrupts in those interrupt handlers that do take too
> > much time to execute. For example, in the system I program, only one IRQ
> > handler enables interrupts (and FPU) during its work. All others either
> > do their work quick enough (e.g., RS232 handlers that just copy a few
> > bytes between hardware and software buffers), or delegate their actual
> > work to threads level (e.g., Ethernet, USB, etc.).
> >
> > IMHO, the rule of thumb is: do minimum amount of work required to manage
> > hardware in ISRs. Do everything else at tasks level. Consider doing
> > other work in ISR only if measurements tell the task switch overhead
> > does matter. Consider enabling interrupts in the ISR handler if
> > measurements show it takes too much time to be executed at interrupts
> > disabled.
> >
> > Besides, I wonder how many times did you indeed measure the overhead to
> > make sure it's too high for particular case? If a piece of code is so
> > short that context switch overhead is significant relative to it, it
> > well could be executed from ISR, and maybe even without enabling
> > interrupts.
> >
> > Overall, the solution I advocate gives programmer opportunity to build
> > his system in the most optimal way instead of forcing him to use "one
> > true approach".
>
> Well, all above is absolutely correct and incorrect, IMHO.
>
> As a general recommendation theory, it is more than correct.
>
> But practice is always more complicated than theory. And there are different 
> situation, where context switch time becomes significant factor.

I thought I've said above that I do apply the theory in practice and
still didn't encounter iron curtains. I believe 90% of these cases could
in fact be solved by more thinking about application design, and the
rest 10% could be handled by manually enabling interrupts and managing
IRQ masks. The problem with current interrupt processing model is that
it's focused on those 10% taken from 10% of applications and makes it
inefficient and in some cases even impossible to use more
straightforward policies.

> 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.

-- 
Sergei.