I know this is implementation specific but to make it a little less
ambiguous let's deal with an XScale or any ARM core for that matter.
Under what conditions would you _miss_ interrupts? Let's say I have a
UART that only generates one interrupt to the interrupt controller but
the source of this interrupt within the UART can be due to various
reasons. For example, maybe there is a FIFO overflow or maybe there is
some sort of error condition, etc which each can cause the one
interrupt line to the interrupt controller to be asserted.

1)First, if interrupts are disabled in the UART and some condition
that can generate an interrupt arises, such as an empty FIFO, and I
then enable interrupts in the UART sometime later, will an interrupt
be generated then at this time if the FIFO is still empty?

2) If the FIFO overflows and I get an interrupt and I am in the
interrupt service routine, and interrupts are globally disabled by the
processor, if while I am in the ISR another condition in the UART
causes an interrupt, will this cause me to reenter the ISR once I
return after servicing the FIFO overflow? Does this have anything to
do with where in the ISR I clear the status flag in the UART register
that indicates a FIFO overflow, i.e. clearing at the start of the ISR
or right before I return? I have always heard to clear the flag at the
start of the ISR, but I am not sure the exact reason.

3) With regards to missing interrupts, would this only happen if for
example I have a timer set to interrupt me every 1 ms but I am in an
ISR for a UART, for example, that takes longer than 1 ms to execute?

Thanks.

In article <1...@g4g2000hsf.googlegroups.com>, joshc 
says...
> I know this is implementation specific but to make it a little less
> ambiguous let's deal with an XScale or any ARM core for that matter.
> Under what conditions would you _miss_ interrupts? Let's say I have a
> UART that only generates one interrupt to the interrupt controller but
> the source of this interrupt within the UART can be due to various
> reasons. For example, maybe there is a FIFO overflow or maybe there is
> some sort of error condition, etc which each can cause the one
> interrupt line to the interrupt controller to be asserted.
> 
> 1)First, if interrupts are disabled in the UART and some condition
> that can generate an interrupt arises, such as an empty FIFO, and I
> then enable interrupts in the UART sometime later, will an interrupt
> be generated then at this time if the FIFO is still empty?

Maybe.  It depends on how the UART is designed, both types exist.

> 2) If the FIFO overflows and I get an interrupt and I am in the
> interrupt service routine, and interrupts are globally disabled by the
> processor, if while I am in the ISR another condition in the UART
> causes an interrupt, will this cause me to reenter the ISR once I
> return after servicing the FIFO overflow? 

Maybe. It depends on the details of your ISR and to some extent on the 
hardware.

> Does this have anything to
> do with where in the ISR I clear the status flag in the UART register
> that indicates a FIFO overflow, i.e. clearing at the start of the ISR
> or right before I return? 

Yes, Certainly. If you clear the interrupt flag after new interrupts 
have arrived they may be lost.  Which is the reason some peripherals 
with multiple interrupt sources have methods for clearing them 
individually rather than as a whole.  Having said that, I only have 
vague recollections of systems using the latter method.  It's quite 
possible my recollection is flawed.

> I have always heard to clear the flag at the
> start of the ISR, but I am not sure the exact reason.

That's generally recommended so that if another interrupt source occurs 
while you are servicing the one you are dealing with it will be flagged.

> 3) With regards to missing interrupts, would this only happen if for
> example I have a timer set to interrupt me every 1 ms but I am in an
> ISR for a UART, for example, that takes longer than 1 ms to execute?

How about another maybe :)

It will depend on on whether the timer interrupt has to be reloaded, in 
which case you won't lose the interrupt just time.  More properly to 
your question if you recieve multiple interrupts of the same source 
before you service them you will generally only see the one unless you 
have some sort of queueing mechanism in the peripheral.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

On Jun 9, 11:05 pm, Robert Adsett <s...@aeolusdevelopment.com> wrote:
> In article <1181440973.846650.221...@g4g2000hsf.googlegroups.com>, joshc
> says...
>
> > I know this is implementation specific but to make it a little less
> > ambiguous let's deal with an XScale or any ARM core for that matter.
> > Under what conditions would you _miss_ interrupts? Let's say I have a
> > UART that only generates one interrupt to the interrupt controller but
> > the source of this interrupt within the UART can be due to various
> > reasons. For example, maybe there is a FIFO overflow or maybe there is
> > some sort of error condition, etc which each can cause the one
> > interrupt line to the interrupt controller to be asserted.
>
> > 1)First, if interrupts are disabled in the UART and some condition
> > that can generate an interrupt arises, such as an empty FIFO, and I
> > then enable interrupts in the UART sometime later, will an interrupt
> > be generated then at this time if the FIFO is still empty?
>
> Maybe.  It depends on how the UART is designed, both types exist.
>
> > 2) If the FIFO overflows and I get an interrupt and I am in the
> > interrupt service routine, and interrupts are globally disabled by the
> > processor, if while I am in the ISR another condition in the UART
> > causes an interrupt, will this cause me to reenter the ISR once I
> > return after servicing the FIFO overflow?
>
> Maybe. It depends on the details of your ISR and to some extent on the
> hardware.
>
> > Does this have anything to
> > do with where in the ISR I clear the status flag in the UART register
> > that indicates a FIFO overflow, i.e. clearing at the start of the ISR
> > or right before I return?
>
> Yes, Certainly. If you clear the interrupt flag after new interrupts
> have arrived they may be lost.  Which is the reason some peripherals
> with multiple interrupt sources have methods for clearing them
> individually rather than as a whole.  Having said that, I only have
> vague recollections of systems using the latter method.  It's quite
> possible my recollection is flawed.
>
> > I have always heard to clear the flag at the
> > start of the ISR, but I am not sure the exact reason.
>
> That's generally recommended so that if another interrupt source occurs
> while you are servicing the one you are dealing with it will be flagged.
>
> > 3) With regards to missing interrupts, would this only happen if for
> > example I have a timer set to interrupt me every 1 ms but I am in an
> > ISR for a UART, for example, that takes longer than 1 ms to execute?
>
> How about another maybe :)
>
> It will depend on on whether the timer interrupt has to be reloaded, in
> which case you won't lose the interrupt just time.  More properly to
> your question if you recieve multiple interrupts of the same source
> before you service them you will generally only see the one unless you
> have some sort of queueing mechanism in the peripheral.
>
> Robert

Thanks for the reply. The "maybes" are frustrating because I have
worked with various different processor architectures (PowerPC, ARM,
various 16/8-bit architectures), but I have yet to see any of the
reference manuals for the processors mention anything about losing
interrupts if the interrupt flag is not cleared or whether or not they
queue interrupts.

In article <1...@k79g2000hse.googlegroups.com>, 
joshc says...
> On Jun 9, 11:05 pm, Robert Adsett <s...@aeolusdevelopment.com> wrote:
> > In article <1181440973.846650.221...@g4g2000hsf.googlegroups.com>, joshc
> > says...
> >
> > > I know this is implementation specific but to make it a little less
> > > ambiguous let's deal with an XScale or any ARM core for that matter.
> > > Under what conditions would you _miss_ interrupts? Let's say I have a
> > > UART that only generates one interrupt to the interrupt controller but
> > > the source of this interrupt within the UART can be due to various
> > > reasons. For example, maybe there is a FIFO overflow or maybe there is
> > > some sort of error condition, etc which each can cause the one
> > > interrupt line to the interrupt controller to be asserted.
> > How about another maybe :)
> >
> 
> Thanks for the reply. The "maybes" are frustrating because I have
> worked with various different processor architectures (PowerPC, ARM,
> various 16/8-bit architectures), but I have yet to see any of the
> reference manuals for the processors mention anything about losing
> interrupts if the interrupt flag is not cleared or whether or not they
> queue interrupts.

Hmm, I've never had much problem determing that from the documentation.  
Sometimes it's not more than a sentence but it's there.  As a general 
rule, if it doesn't mention some sort of queueing of the interrupt 
source it's not done.  It's not a common item.

Determining whether an interrupt will be lost usually is a matter of 
judging side effect of status reading and acknowledgement operations and 
watching for race conditions.  The interrupt flag and status bits are 
generally quite simple logic, there is usually no method of indicating 
multiple occurences so if more than one occurs you will only see the 
one.  It gets more complicated with FIFOs and multiple interrupt source 
peripherals but the documentation will be in the peripherals as to how 
they behave.  Sometimes all you get is a simple flag and a simple 
acknowledge that acknowledges all outstanding interrupt sources leaving 
it up to the user to check all possibile sources.  Sometimes you have 
separate acknowledge flags for each source in a peripheral and the 
interrupt will remain active as long as one unacknowledged source 
remains.

Also there is the question of edge sensitive vs level sensitive 
interrupts. Internal peripherla to interrupt controller interrupt lines 
are usually but not always level sensitive.  If they are edge sensitive 
then if the interrupt flag is set you won't get any more interrupts 
until it is cleared which can lead to missed interrupts if you are nor 
careful to check, and in some cases re-check, anything that can set the 
interrupt before leaving an ISR.

What you won't see is a single blanket statement covering all cases,  
simply because some of the behaviour resets with the peripherals and 
some with the interrupt controller. 

Further complicating matters in the case of the ARM family is that there 
are multiple types of interrupt controllers used.  And you may have to 
acknowledge/clear the interrupt not only in the peripheral but in the 
interrupt controller as well.

There's also the question of nested interrupts.  In most cases you do 
not want to re-enable interrupts until you've cleared/acknowledged the 
current interrupt.  I hope the reasons are obvious.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com