FW: rtems on nios2 collaborative efforts
sebastian.huber at embedded-brains.de
Tue Apr 10 07:16:00 UTC 2012
On 04/04/2012 06:32 PM, Hill, Jeffrey O wrote:
> Hi Again,
> Maybe I can summarize.
> I suspect we probably agree on all these points
> Open Questions Here
> * The following issues don't need immediate resolution because my
> system is happy to run with ienable initialized to all ones,
> and this is presumably not messed with by drivers.
> * Should _ISR_Set_level / _ISR_Get_level set the background (quiescent)
> ienable when there is an IIC? We can easily test for existence of IIC/EIC
> during startup in generic CPU kit code, and branch on this later. Efficiency
> isn't important.
On other platforms (like PowerPC or classic ARM) the interrupt level of the
interrupt controller is kept separate from the RTEMS interrupt level. On
PowerPC and classic ARM you can only enable or disable the interrupts (two
levels). In addition to that you can call BSP specific routines to set the
interrupt level of particular interrupt sources in the interrupt controller.
This is used during nesting of interrupts.
> * context switching - should we save the ienable register - what does that
It doesn't cost much, but what is the benefit?
> * Since rtems_interrupt_disable/enable is used only to briefly globally
> lock out _all_ interrupts I am wondering if its sufficient to only manipulate
> the PIE bit and not change any of the other bits in the status register?
For the IIC this is all right, but not for the EIC with shadow registers. In
one application we use the high priorities to support interrupt service
routines without operating system support. They operate in their own register
set and don't have to maintain or take care about the operating system state.
This enables very fast interrupt response times. In case they need operating
system support, they can trigger low priority software interrupts.
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel