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

[Graeme Russ]

Hi Wolfgang,

On Monday, October 24, 2011, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <
CALButCJH8BVzfVh14D83WR2JOV89O9jvJO9VzzB7r_ZgKzZqeg at mail.gmail.com> you
wrote:
>>
>> > Problems happen only with multi-line input, so it is perfectly fine
>> > to handle just that - at the root cause, i. e. when input turns into
>> > multi-line input.
>>
>> Can the U-Boot command line handle multiple commands per line (delimited
by
>> ; for example)
>
> Yes, it can.
>
>> If so, could it not be possible that a Kermit/ymodem command followed by
a
>> time consuming command on the same line cause lost input?
>
> I don't think so.  All serial transfers use a protocol - and when the
> transfer is complete, it does not matter any more, because no more
> data are flowing.

My point is that the transfer turns off flow control - When the transfer
completes, flow control will be off when the next command begins to run.
If the next command is one which takes a long time to execute and it is on
the same line as the transfer command (i.e. no \r to send XOFF) and the
user types something then that input can be lost.

I think the solution is fairly trivial though - During the processing of
commands entered via readline(), cause an XOFF to be sent each time (i.e.
immediately before) the command string is dispatched a to the command
processor just in case the previous command called getc() (and thus caused
an XON to be sent)

Regards,

Graeme