Re: [ECOS] IRQ interrupt at highest priority

[Hugo 'NOx' Tyson <hmt at cygnus dot co dot ukx>]

"Amlan  Chakraborty" <amlan.cha@wipro.com> writes:

> 1) Will a lower priority interrupt under execution  get
> pre-empted when a higher priority interrupt arrives?
> 
> 2) I found in file packages/kernel/.../src/common/clock.cxx ,
> the TIMER2 interrupt for the real-time clock ISR is created
> with priority 1 ( not the highest priority ). Hence when the
> real-time clock ISR is under execution will an interrupt of
> higher priority (say 0) pre-empt it?
> 
> 3) Does ECOS internally use any other interrupt that is created
> with the highest priority (i.e. 0)?

Here's an important point: on most platforms, the priority parameter to
creating an interrupt handler is a place holder; it does nothing.

Some hardware PICs have prioritization built in.  Some CPUs have
prioritization built in.  In some of these, that prioritization might be
programmable.  In those cases, that priority parameter does something
hardware-specific and probably not very well documented.

AFAIK ARM does not support such a thing.

Interrupt prioritization (as you are thinking of it) is platform dependent.
On the PID, it is controlled by this routine from pid_misc.c

//
// This routine is called to respond to a hardware interrupt (IRQ).  It
// should interrogate the hardware and return the IRQ vector number.

int hal_IRQ_handler(void)
{
    // Do hardware-level IRQ handling
    int irq_status, vector;
    HAL_READ_UINT32(CYG_DEVICE_IRQ_Status, irq_status);
    //diag_init();  diag_printf("%s, status: %x\n", __PRETTY_FUNCTION__, irq_status); 
    for (vector = 1;  vector < 16;  vector++) {
        if (irq_status & (1<<vector)) return vector;
    }
    return CYGNUM_HAL_INTERRUPT_unused; // This shouldn't happen!
}

which as you can see just picks the first one that's active, starting from
number 1 and working upwards to 15, through the bits in the IRQ Status
register.

So if sources 3,5 and 11 are interrupting, 3 will win.

HTH,
	- Huge