Richard,

Thanks for your comments; but I would like to ask you to comment on your comments :-) further...



The example is to be viewed in the context of Jon's document. Jon gives reasons for usage of interrupt-driven software-FIFO-buffered serial communication there; maybe an example would be fine.
But one thing first: it really does not matter if software- or hardware-FIFO, the question is, whether FIFO is needed at all (using the internal UART of '51, the hardware FIFO is then ruled out).
The answer is simple, this all is for the convenience of programmer. If the programmer can ensure that the receiver is checked often enough, and/or can spend time to trnasmit a string, then no need for FIFO. If the programmer wants to have some time for a relatively lengthy process and there is chance that bytes will arrive and he does not want to loose them; and/or if he wants to transmit a string (a packet of data) and don't want to wait until it gets actually transmitted, then he needs the FIFO.
That's all.
A good example is a packet-based communication network. Let's assume a simple example: a packet of 10 bytes arrives, say at 9600 bauds, the controller processes it and is supposed to transmit a 10 bytes packet answer. The "main" program is a loop, where the mcu reads status of some pushbuttons, displays some data, reads some ADC and writes ocassionally into an EEPROM - the loop may take more than 1ms, which is approximately the time it takes for one byte to arrive; hence more than one character might arrive while the loop is executing and if (without interrupt and FIFO) the receiver would be checked only once per loop, characters might get lost. The loop then would have to be broken up into pieces and the receiver checking routine would have to be inserted on more places. Using interrupt and FIFO, there is simply only one place in the loop, where a complete packet reception is checked; and only if it happens, then the packet processing routine is invoked. It produces an outgoing packet, and not to waste time transmitting it byte by byte (which would take 10 ms for 10 bytes), it simply stores it into the output FIFO and starts the transmission. While it happily can resume the main loop, the interrupt takes care of transmitting the whole packet "in background".

Is this a good example?


Hmmmm... Maybe some specific header is missing, but I believe this can be assembled by any '51 assembler, can't it? I thought the '51 assemblers all assume a basic set of 8051 registers to be implicitly known; Keil for example requires to de-activate these to be able to include a custom set of register definitions, but I don't know all the '51 assemblers around...
Can you perhaps correct it to be assembler-independent?


The names of character input/output in C are a bad joke. There is getc, getch, getche, getchar, fgetc, fgetchar (maybe more) providing similar or same functionality with little differences. More importantly, don't expect this from ME, I hate C.


Programming style... In asm, I think there are no established rules. We can try to put down some here, if you want, but don't expect everybody be happy with them; I think everybody makes up his own style.

I just don't think this is the right place to discuss style; as I said the program itself is not of such importance as the comments on it are.

Jan Waclawek