This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Interrupt acknowledge in ISR.
- From: <felixwong at i-technologies dot cc>
- To: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
- Cc: <nickg at redhat dot com>, <jlarmour at redhat dot com>
- Date: Fri, 7 Dec 2001 10:25:18 +0800
- Subject: RE: [ECOS] Interrupt acknowledge in ISR.
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".
Or should it be HAL_ENABLE_INTERRUPTS(), HAL_DISABLE_INTERRUPTS()
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.