[U-Boot] [PATCH v2] NS16550: buffer reads

[Graeme Russ]

Hi Wolfgang,

On Tue, Oct 25, 2011 at 8:59 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4EA5CD39.2070203 at gmail.com> you wrote:
>>
>> > Assume we have a simple device with a small Rx FIFO - say, 8 bytes
>> > only. Guess what the chances are that we will overrun this FIFO (and
>> > then lose characters) before the other side stops sending?
>>
>> Should be zero (if you disable the hardware Tx buffer) unless you have an
>> incredibly slow Rx routine (in which case, your baud rate is too high). And
>> even with a Tx buffer in play the solution is fairly simple - After sending
>> an XOFF, flush the Rx buffer (and remote Tx buffer) into an internal buffer
>> until tstc() returns false - use this buffer for getc() until it is empty.
>
> Things are becoming more and more complicated, it seems.
>
> If you ask me: forget about all this, and stick with single line
> input.  Do the processing on the sender's side (always wait for a
> prompt before sending the next line).  This is MUCH easier.

Oh, I wholehearedly agree that if we impose such a limitation, life will
be much easier for us all ;)

But realistically, the solution is actually very trivial and comprises
just two parts:

1a) When the command line interpreter (which is just the really simple
    function detecting new-line or command delimiter) dispatches a
    command string to the command interpreter (which looks up the
    command table and if it finds a command runs it) send an XOFF
1b) When the command interpreter returns control back to the command
    line interpreter, send an XON
1c) If an XOFF has been recently sent (i.e. no XON since) send an XON
    in getc()

2) After sending XOFF, flush the transmitter's buffer into a small
   (16 bytes chould sufffice) buffer. Grab characters from this buffer
   before grabing from the UART when getc() is called

The second part should not even be necessary if you have a half-sane
serial port with a half-decent hardware buffer.

It really would not be that hard (maybe a few dozen lines of code at most),
would work for all UARTS and should (hopefully) resolve all 'dropped
character' issues.

Now 1c) makes the bold assumption that any command which calls getc()
'knows what it is doing' and will consume all input characters at a fast
enough rate AND will not invoke a delay between receiving the last
character and returning back to the command line interpreter. If the
command knows it received characters and knows it will invoke a delay (some
kind of post-processing) then in order to not lose characters, the command
MUST issue it's own XOFF - nothing else aside from an interrupt driven
serial driver will solve the problem in this case.

Regards,

Graeme