[ECOS] Interrupt mode for MIPS32 in eCos - compatibility or vectored

[ECOS] Interrupt mode for MIPS32 in eCos - compatibility or vectored

[Elad Yosef]

Hi,
My MIPS32 4KEc supports Interrupt Vectors or compatibility mode.
From what is see in the eCos code is only support the compatibility mode
So that SW decodes the cause register and jumps to handler according
to the vsr_table.

Interrupt Vectors is functionality in the MIPS32.
When it is on, the CPU HW decodes the cause register to get the
exception/interrupt number.
And then it jumps to the handler.
The handlers are in a fixed location that is calculated by formula
that looks like  - BASE+(exp_code*space_between_handlers)
the spacing is configurable in the MIPS.
It is up to the SW to supply the handlers and place then in the
correct location. The handlers are basically the ISR

My questions are:
-Am I wrong in my assumption ?
-Can eCos supports Interrupt Vectors, so decode of the cause and the
jump to handler are done by HW ?


Thanks
Elad

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Interrupt mode for MIPS32 in eCos - compatibility or vectored

[Daniel Helgason]

On Thu, 2011-02-03 at 09:25 +0200, Elad Yosef wrote:
> Hi,
> My MIPS32 4KEc supports Interrupt Vectors or compatibility mode.
> From what is see in the eCos code is only support the compatibility mode
> So that SW decodes the cause register and jumps to handler according
> to the vsr_table.
> 
> Interrupt Vectors is functionality in the MIPS32.
> When it is on, the CPU HW decodes the cause register to get the
> exception/interrupt number.
> And then it jumps to the handler.
> ...
> My questions are:
> -Am I wrong in my assumption ?
> -Can eCos supports Interrupt Vectors, so decode of the cause and the
> jump to handler are done by HW ?
> ...

Elad!

eCos maintains the interrupt vectors and decodes the interrupt causes
without the need for vectoring in hardware. I think it would be
difficult for the HAL to abstract, in an efficient manner, the various
ways that hardware can auto-vector and still support hardware that
cannot.

Also, to work within the context of an RTOS, interrupts usually share
common code before and after the specific code that they need to run.
Auto-vectored interrupts would have to call the common code anyway and
that would negate their main advantage.

You must be using a MIPS32v2 device. That's the only MIPS instruction
arch to support vectored interrupts that I know of.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss