Is there any Guru who knows why interrupts are disabled in ISR?

[Joel Sherrill]

Leon Pollak wrote:
> 
> Hello Gurus,
>         I shall be very thankful for the explanation of the following moment:
>         I look into PPC code file irq_stub.S routine __ISR_handler I see that
> all
> interrupts are disabled almost immediatly. They are reenabled at the end of
> the ISR, after the user ISR has finished its processing, almost at the point
> of exit from __ISR_handler.
>         This text contains the comment after the _ISR_NestLevel incrementing:
> "From here on out, interrupts can be re-enabled, RTEMS convention says not".
>         Can somebody explain me why interrupts must be disabled inside the
> user ISR?

Didn't we answer this a while back?  

On a CPU family with "good native" interrupt level support RTEMS uses
that.
The m68k is an example of that.  RTEMS does not disable interrupts but
simply leaves them alone and lets higher priority interrupts be dealt
with by the CPU.

But the i386 and many PowerPC's have a single interrupt level from 
the CPU's perspective.  RTEMS does not automatically enable all 
external interrupts since a PIC would have to be touched and
generically we don't know about it.  So it is the user's 
responsibility to deal with that PIC and "reenable" interrupts.

> Thanks.
> --
> l
> --
> Dr.Leon M.Pollak
> Director
> PLR Information Systems Ltd.
> leonp at plris.com

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