Lpc2000

At 10:07 PM 11/17/04 +0000, you wrote:
>b. Check U0IIR, handle the highest-priority pending interrupt,
>thereby doing the Interrupt Reset action.  Re-check U0IIR, and loop
>around if another interrupt is pending.  When no more interrupts are
>pending, return.  This way is better if multiple simultaneous
>interrupts are so likely that it pays off to save the multiple
>interrupt entry/exit code.

That's certainly the way it's supposed to work (and the way I have done it 
on 'real' 16550s) but when I do this on an LPC2106 with both transmit and 
receive interrupts I occasionally miss THRE interrupts (they just never 
occur).  This only happens when receive is occurring at the same time as 
transmit (I used a simple echo test) and it only occurs infrequently 
(several 100K up to a megabyte or more of transmitted bytes before it would 
halt).  The only explanation I have is an undocumented race condition in 
updating the IIR as it is being read but as I said in an earlier post I 
haven't seen any duplication.  Changing to the less conventional one IIR 
read per interrupt seems to eliminate the problem but maybe all it does is 
reduce the probability.

Leighton's symptoms appear to be similar to (but not the same as) what I've 
seen so I'm wondering if he hasn't run across the same underlying problem I 
have.

The THRE interrupts are the only serial interrupts that do not re-assert if 
they are not serviced so they are particularly vulnerable.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III