[ECOS] about interrupts nesting and vector number decoding

Jonathan Larmour jlarmour@redhat.com
Tue Oct 24 21:02:00 GMT 2000


> yyl wrote:
> Q1:From document,i know that isr is excuted with interrupt disabled,but
> dsr enable interrupt,so i think the interrupt nesting is occured  in
> dsr.But from another place in the document,

which document?

>something is said as followed:
> 
>       The VSR should follow the following approximate plan:
>           ........
>           (Optional) Re-enable interrupts to permit nesting.
>           Decode the actual external interrupt being delivered from the
> interrupt controller. This will yield the ISR vector number.
>           Using the ISR vector number as an index, retrieve the ISR
> pointer and its data pointer from the ISR vector table.
>           Construct a C call stack frame.
> 
> If re-enable interrupts before isr being called ,it seems that in isr
> interrupt is enabled.
> Who can tell me the procedure  about the interrupt nesting?

I don't know where this comes from to derive the context. It certainly
isn't
http://sources.redhat.com/ecos/docs-latest/porting/hal-interrupts.html for
example. I don't know whether this is talking about writing your own VSRs
or the default interrupt VSR for porting.

But anyway, as you can see permitting nesting is optional. And in fact I
don't know any eCos targets where nested ISRs are permitted by default, but
I may be wrong of course. And when it does say you _could_ allow nesting,
this would primarily be aimed at allowing higher priority interrupts to
interrupt lower priority ones. Until processed, any interrupt being handled
would remain masked until processing was completed, usually in the DSR.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault


More information about the Ecos-discuss mailing list