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

[Albert ARIBAUD]

Le 15/10/2011 18:12, Simon Glass a écrit :
> Hi Wolfgang,
>
> On Sat, Oct 15, 2011 at 9:02 AM, Wolfgang Denk<wd at denx.de>  wrote:
>> Dear Simon Glass,
>>
>> In message<CAPnjgZ34FFotBBiqb=Y5xsuyRiavOWud5G2sy9GModsG4LB6=w at mail.gmail.com>  you wrote:
>>>
>>>> A general question: is the issue with input as such, or with echoing this
>>>> input?
>>>
>>> The problem is in echoing the input, since this requires the uart to
>>> wait once its transmit FIFO is full. While it is waiting (and not
>>> checking the receive side), it misses characters coming from the other
>>> end. Basically we need to constantly check the receiving side while we
>>> are transmitting.
>>
>> No, we do not.
>>
>> U-Boot is strictly single tasking. This is one of the fundamental
>> design principles. We do not receive network packets while sending
>> ourself, or when doing other things. We do not receive characters on
>> the serial line while sending characters, or when doing other things.
>>
>> This is known behaviour, and you should just adapt to it. I don't know
>> what exactly is your situation when you run into such problems - the
>> recommended approach for example when remote-controlling U-Boot is to
>> wait for the next input prompt before sending the next line of
>> characters - and stop after the newline, until you receive the next
>> prompt.
>
> I certainly don't want to break a fundamental design principle.
> .
> The situation this occurs is when you paste characters into a serial
> terminal connected to U-Boot. This is a pretty common requirement. Yes
> you can manually select each line and paste it but that is a pain.
> With this patch it is possible to paste a series of 'setenv' commands,
> for example.
>
> This caused an awful lot of confusion here because characters would be
> silently dropped within the command line (normally about 16 chars from
> the end). Then the system would not boot. It is really not a friendly
> experience.
>
> Regards,
> Simon

How about using the time-honored flow-control mechanism? If the serial 
port supports hardware CTS and RTS signals, you can use them to sync 
with the sender. If not, you can send XOFF and XON to respectively ask 
the sender to pause and resume sending. Of course, the sender must 
support hardware or software flow control.

Amicalement,
-- 
Albert.