This is the mail archive of the
mailing list for the eCos project.
Re: Interrupt mode for MIPS32 in eCos - compatibility or vectored
- From: Daniel Helgason <dhelgason at shaw dot ca>
- To: ecos-discuss at ecos dot sourceware dot org
- Cc: Elad Yosef <elad dot yosef at gmail dot com>
- Date: Thu, 03 Feb 2011 10:37:11 -0800
- Subject: Re: [ECOS] Interrupt mode for MIPS32 in eCos - compatibility or vectored
- References: <AANLkTimfq3eqfqPesXvziuxWR=eGO1=g4H4=KteLTfirstname.lastname@example.org>
On Thu, 2011-02-03 at 09:25 +0200, Elad Yosef wrote:
> 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 ?
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
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