[ECOS] Interrupt acknowledge in ISR.

felixwong@i-technologies.cc felixwong@i-technologies.cc
Thu Dec 6 18:22:00 GMT 2001

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?

-----Original Message----- (from Nick Garnett).
>This business of masking the interrupt in the ISR and unmasking it in
>the DSR is specific to the way the serial drivers are designed. In
>general there should be no need to mess with the interrupt mask at
>all once the device has been enabled.
>The correct approach is for the ISR to do whatever is necessary at the
>device to cancel the interrupt condition, and to then call
>cyg_drv_interrupt_acknowledge() to cancel it in the interrupt
>controller. cyg_drv_interrupt_acknowledge() should *always* be in the
>ISR, it is poor practice to put it elsewhere.

More information about the Ecos-discuss mailing list