Lpc2000

Sorry for the delay guys,

Point taken for the answers to 1,2, and 3. Thanks Karl & Robert. 

> 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, I haven't yet seen the problem you described that's 
interestingly the opposite to what I'm getting. Debugging through 
the JTAG and using a serial port data logger I see all the receiver 
bytes coming in from the PC. I usually send up to 16 bytes per THRE 
& for the most part the lpc sends the reply packet correctly. But 
only in that special case I see the lpc not respond to the last 
command packet. It came across the receive line ok (logger) so the 
PC's ok. However on the lpc side I debug and see the packet looking 
truncated. Like some bytes got lost while receiving, which looks 
kinda wierd. I haven't yet seen the opposite happen b4.

> a. Check U0IIR, handle the highest-priority pending interrupt, 
> thereby doing the Interrupt Reset action, and return.  If more 
than 
> one interrupt was pending, the UART will immediately interrupt 
again, 
> and then present the next-highest priority interrupt in U0IIR, and 
so 
> on.  This way is the easiest, and the best one if multiple 
> simultaneous interrupts are rare.
> 
> 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.

Interesting stuff Karl. I wasn't really paying attention to the IIR 
table. So, I'll have to review my code just incase I did a bit too 
much for RDA & THRE. Basically, the code I'm using is following Plan 
B. Bill Knight's code follows the same concept too. I'll give Plan A 
a try though, since my PC <-> lpc communication is on a small scale, 
and Robert's having more success with it.