[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Interrupt latency problems on MPC860
- Date: Thu, 15 Nov 2001 09:58:29 -0600
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: Interrupt latency problems on MPC860
Phil Torre wrote:
> On Wed, Nov 14, 2001 at 02:49:06PM -0600, Joel Sherrill wrote:
> > Moreover, this really may be tough to attain on the PowerPC
> > architecture without VERY special care. The PowerPC by default does
> > not really have interrupt priority or (without work) nesting of
> > interrupts. So all you have to do is take > 79 usecs to process
> > an interrupt and you are nailed. Since (I am pretty sure about this)
> > interrupts are disabled from the time a handler is vectored by HW
> > until the entire ISR returns, you have a long window there.
> Originally, this was the case. There is a comment in irq_stub.S,
> right after _ISR_Nest_level is incremented, which says "From here on
> out, interrupts can be re-enabled. RTEMS convention says not". I
> added an instruction there to re-enable interrupts by setting MSR[EE],
> but it seems to make no difference.
Does your CPU/board have an external PIC that must be tinkered with
before a 2nd interrupt occurs? There is a nested path through the
code where you could set a variable to see if nesting ever occurred.
> Am I right in thinking that there should only be two times when maskable
> interrupts are disabled: In between the hardware vector and nesting,
> and in between rtems_interrupt_disable() and rtems_interrupt_enable()?
Yes. If nesting is not allowed, this it is the entire processing time.
> Phil Torre phone: 425-820-6363 x234
> Design Engineer email: ptorre at zetron.com
> Switching Systems Group fax: 425-820-7031
> Zetron, Inc. web: http://www.zetron.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