Re: [ECOS] nested interrupts

["Xavier Wang" <xavierwang at ms19 dot url dot com dot tw>]

Thanks, Jesper.

One more question. By looking into the source code, I still can't
figure out that why DSRs can call most kernel functions but
ISRs can't. Is it the stack problem or scheduler locking problem
or something else?

> Xavier> I got confused about nested interrupts. In
> Xavier> http://sources.redhat.com/ecos/docs-latest/porting/hal-interrupts.html
> Xavier> it seems that interrupts are disabled in ISRs, but enabled in
> Xavier> DSRs.
> 
> Xavier> But Hugo's description in the same page said that
> Xavier> higher priority interrupts are enabled before calling
> Xavier> ISR. Which is true for nested interrupts?
> 
> Both are true, but depending on configuration. There is an option that
> allows nested interrupts - when disabled, the former is valid, when
> enabled, the latter is valid.
> 
> Xavier> If it's the former, should I rewrite the 'hal_cpu_int_enable'
> Xavier> macro used in hal_interrupt_stack_call_pending_DSRs (in
> Xavier> vector.S) to enable only higher priority interrupts? If it's
> 
> No. All interrupts are allowed when executing DSRs. DSRs are only
> executin when no interrupts are pending.
> 
> Xavier> the latter, what should I do to support nested interrupts?
> Xavier> (I'm using TX39/JMR3904 platform, eCos version 1.3.1)
> 
> You need code that enabled higher level interrupts depending on the
> state of CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING.
> 
> The code needs to go either somewhere in vectors.S around the place
> where the hal_cpu_except_enable macro is called. I don't know if a
> variant/platform specific version of that macro would be a suitable
> solution. None of the other MIPS platforms allow nested interrupts.
> 
> Xavier> Besides, by looking into the source code, it seems that if
> Xavier> there is any pending DSRs, no thread will be run. So can a
> Xavier> high priority thread be blocked by a low priority interrupt
> Xavier> (DSR)?
> 
> Yes.
> 
> Xavier> Will it introduce some problems for a real-time application?
> 
> I guess that depends on how you program the DSRs/threads. But I don't
> have anything intelligent to say to that, so I won't.
> 
> Jesper