From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] NS16550: buffer reads
Date: Sat, 15 Oct 2011 18:21:00 +0200 [thread overview]
Message-ID: <4E99B2EC.9070004@aribaud.net> (raw)
In-Reply-To: <CAPnjgZ3wZo4nkP2GjKbS_r8AWmRaCkagFDqrXrJg5MniykxCNw@mail.gmail.com>
Le 15/10/2011 18:12, Simon Glass a ?crit :
> Hi Wolfgang,
>
> On Sat, Oct 15, 2011 at 9:02 AM, Wolfgang Denk<wd@denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message<CAPnjgZ34FFotBBiqb=Y5xsuyRiavOWud5G2sy9GModsG4LB6=w@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.
next prev parent reply other threads:[~2011-10-15 16:21 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 0:03 [U-Boot] [PATCH v2] NS16550: buffer reads Simon Glass
2011-10-15 10:43 ` Albert ARIBAUD
2011-10-15 14:47 ` Simon Glass
2011-10-15 16:02 ` Wolfgang Denk
2011-10-15 16:12 ` Simon Glass
2011-10-15 16:21 ` Albert ARIBAUD [this message]
2011-10-15 16:50 ` Simon Glass
2011-10-15 17:45 ` Simon Glass
2011-10-15 19:14 ` Wolfgang Denk
2011-10-16 4:46 ` Simon Glass
2011-10-16 19:52 ` Wolfgang Denk
2011-10-16 21:02 ` Simon Glass
2011-10-15 19:05 ` Wolfgang Denk
2011-10-15 19:00 ` Wolfgang Denk
2011-10-16 4:39 ` Simon Glass
2011-10-16 19:47 ` Wolfgang Denk
2011-10-16 20:43 ` Simon Glass
2011-10-16 21:00 ` Wolfgang Denk
2011-10-17 4:56 ` [U-Boot] How to unsubscribe Sandeep Kumar
2011-10-17 15:40 ` Mike Frysinger
-- strict thread matches above, loose matches on Subject: below --
2011-10-16 5:14 [U-Boot] [PATCH v4 1/2] NS16550: trivial code clean for checkpatch Simon Glass
2011-10-16 5:14 ` [U-Boot] [PATCH v4 2/2] NS16550: buffer reads Simon Glass
2011-10-17 12:18 ` Wolfgang Denk
2011-10-17 16:40 ` Simon Glass
2011-10-22 8:44 ` Albert ARIBAUD
2011-10-22 22:15 ` Graeme Russ
2011-10-23 8:20 ` Wolfgang Denk
2011-10-23 11:50 ` Graeme Russ
2011-10-23 17:15 ` Wolfgang Denk
2011-10-23 20:17 ` Graeme Russ
2011-10-23 21:22 ` Wolfgang Denk
2011-10-23 21:32 ` [U-Boot] [PATCH v2] " Graeme Russ
2011-10-23 22:18 ` Wolfgang Denk
2011-10-23 23:30 ` Graeme Russ
2011-10-24 4:47 ` Simon Glass
2011-10-24 18:46 ` Wolfgang Denk
2011-10-24 19:26 ` Graeme Russ
2011-10-24 20:00 ` Wolfgang Denk
2011-10-24 20:40 ` Graeme Russ
2011-10-24 21:59 ` Wolfgang Denk
2011-10-24 22:22 ` Graeme Russ
2011-10-24 23:31 ` J. William Campbell
2011-10-25 7:31 ` Wolfgang Denk
2011-10-25 8:34 ` Graeme Russ
2011-10-25 18:41 ` Wolfgang Denk
2011-10-25 22:37 ` Graeme Russ
2011-10-25 23:17 ` Simon Glass
[not found] ` <CALButCK2XnZ=HR72VaXioCfxkMFgMh2JbXzSDq9TadgKFH52rQ@mail.gmail.com >
2011-10-25 23:37 ` Graeme Russ
2011-10-25 23:48 ` Simon Glass
2011-10-26 3:41 ` Graeme Russ
2011-10-26 7:00 ` Wolfgang Denk
2011-10-26 9:18 ` Graeme Russ
2011-10-26 10:19 ` Wolfgang Denk
2011-10-26 16:55 ` Scott Wood
2011-10-26 18:17 ` Wolfgang Denk
2011-10-26 18:50 ` Scott Wood
2011-10-26 19:19 ` Wolfgang Denk
2011-10-26 6:54 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E99B2EC.9070004@aribaud.net \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox