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

[J. William Campbell]

On 10/24/2011 3:22 PM, Graeme Russ wrote:
> 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
Hi All,
       The problem with all this is that the transmitting CPU may send 
"several" characters after the XOFF is transmitted, where several will 
be at least two if the transmitting CPU has no output fifo, up to 
possibly the output fifo length + 2. Furthermore, this "overage" can 
theoretically increase with each x-on x-off sequence, as each command 
may be, in theory,  shorter than the output fifo length. So the input 
buffering is needed in all cases, i.e. the receive fifo must be "run 
dry" before executing a command. If the receive fifo is shorter than the 
transmit fifo +2, you are doomed. If the receive fifo is larger than 
this, you are ok, the transmitting CPU will stop before overrunning the 
input fifo and data being lost. However, a 16 byte buffer will not be 
enough if there are lots of "short" commands in the input stream.

Best Regards,
Bill Campbell
>
> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>