(my emphasis)


No, that's not what he meant at all!
He's just telling you that you can't use it in the way you've tried to!

Note that some UART chips - eg, the ones used in PCs - do have built-in FIFO buffers, but your average 8051 does not.
Your average 8051's UART handles just one character at a time - and, therefore, so must your code.


Absolutely!
I've used up to four UARTs on a Triscend - all streaming serial data.
Handling serial data on an 8051 is extremely common indeed.


Correct so far.

At this point, it would probably be helpful if you had chapter 3 of the "bible" open in front of you at page 11, and refer to figure 12 on page 12:

Chapter 3 - 80C51 Family Hardware Description:
http://www.semiconductors.philips.com/acrobat/v...WARE_1.pdf

For simplicity, assume that nothing at all is happening on the transmit half of the 8051 UART...

As the serial data bits are received, they are shifted into a shift register. When a complete byte has been received (start bit, 8 data bits, stop bit), it is copied from the shift register into SBUF, and RI is set.


Not quite.

As noted above, the RI bit is set by the hardware when the completed received byte is loaded into SBUF.
If the serial interrupt is enabled, setting the RI bit causes an interrupt to occurr - and the processor jumps to the serial interrupt vector location. Again, this all happens in hardware.

So, when your Interrupt Service Routine (ISR) is entered, you know that exactly one received byte is present in SBUF.
Therefore, the job of your ISR is:

Clear the RI bit;

Retrieve the character from SBUF into some suitable storage.
and that's all it should do - this leaves the serial port ready for the next byte.
When reception of the next byte is complete (and not before), SBUF will be loaded again, RI will be set again, and your ISR will be called again to retrieve another one byte.

and the program should loop until then.

The main program might loop - but the ISR certainly shouldn't!
In fact, the whole point of using interrupt-driven serial IO is that the main program does not need to waste time looping while waiting for characters!



That all assumed receive-only UART activity.
In general, the UART ISR will be entered whenever RI (the receiver interrupt) or TI (the transmit interrupt) or both is set; therefore a general UART ISR has two sections - one checks RI, and handles the receive interrupt; the other checks TI, and handles the transmit interrupt.

Hrm.. can an interupt be triggered from within itself?

If RI is (still) set when the ISR exits, the processor will immediately jump straight back into the ISR!