This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interrupt acknowledge in ISR.


<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".
> 
> 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?
> 

In other targets where the interrupt mask/unmask is a long operation
we have written the HAL_INTERRUPT_MASK() and HAL_INTERRUPT_UNMASK()
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
it.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]