How to mask IRQ

Sergei Organov osv at topconrd.ru
Tue May 31 11:34:00 UTC 2005


Eric Valette <eric.valette at free.fr> writes:

> Sergei Organov wrote:
> 
> > It could be an alternative solution to throw away the idea of automatic
> > management of nested interrupts and their priorities altogether. Instead
> > of emulating priority IC in software, let the threads scheduler handle
> > priorities by delegating most of the work from IRQ handlers level to the
> > task level. This way you will have simple and fast IRQ dispatcher that
> > won't touch IRQ masks at all allowing you to manage them whatever way
> > you wish.
> 
> Unfortunately, the overhead of thread context switch is usually far too
> high to be ued in RT systems.

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

-- 
Sergei.




More information about the users mailing list