[ECOS] Interrupt acknowledge in ISR.

Nick Garnett nickg@redhat.com
Fri Dec 7 02:44:00 GMT 2001

<felixwong@i-technologies.cc> writes:

> Agree to have cyg_drv_interrupt_acknowledge() put into the ISR, unless
> the interrupt controller of the target MCU(if any) is not allowed to do so.
> I am trying to use the advice from Nick Garnett - not to mess with the mask
> and unmask during ISR/DSR processes.
> In case I must use mask/unmask (such as the voltage LEVEL interrupts), or if 
> there are 2 serial driver ISRs enabled at the same time, something has to be 
> added in some MCUs including mine.
> For the ARM MCU I am using, the interrupt mask uses the Read/Modify/Write 
> (R/M/W) 3 instructions method of "masking" or "unmasking" process.  It 
> seems that I have to use the "cyg_drv_isr_lock()" to mask off the I/F of CPSR 
> before the (R/M/W). Then "cyg_drv_isr_unlock()" to enable ISRs again.
> Before using "cyg_drv_isr_lock()", the output I can see is - the ISR works fine
> for some length time, then that ISR can never be entered (possibily masked
> by other ISRs in R/M/W process).  The length of time will be shortened if 
> I add some delay into the R/M/W process intentionally.  This can also be verified 
> in another thread that output the interrupt MASK in random time intervals.
> i.e. in some MCUs, you cannot use "cyg_drv_interrupt_mask()" or 
> "cyg_drv_interrupt_unmask()" alone without "cyg_drv_isr_lock()"/"unlock".
> instead of "cyg_drv_isr_lock()"/"unlock" pairs for less CPU overhead in 
> single MCU systems?
> Any comment?

In other targets where the interrupt mask/unmask is a long operation
macros to disable and restore the interrupt state around the
operation. However, that is often just for paranoia, most of the
places where interrupts are masked/unmasked are already places where
interrupts are disabled.

If you know that some mask/unmask operation may be called outside of a
interrupt-disabled context, then you should use the ISR lock around

Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

More information about the Ecos-discuss mailing list