Hi Wolfgang,
On 25/10/11 18:31, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message
> <CALButCLNEjjEB=1zvvikrvo5-x9vyyoecu1-zrpxf2myavm...@mail.gmail.com> you
> wrote:
>>
>> 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.
>
> This is a fundamentally broken design. No command should ever need to
> have any such knowledge, not to mention that we must not littering
> potentially all code with serial flow control calls.
Well, if a command reads from the console (a transfer command for example)
and then has a long delay (busy processing loop) before returning back to
the command line processor then that command must be fundamentally broken -
there are five ways I see to fix it:
a) Fix the command so it isn't broken
b) Have the command tell the console it has finished with the console
before it starts the busy loop
c) Use UART managed hardware flow control
d) Implement interrupt based serial drivers
e) Prohibit multi-line input
> You will have really hard times to get anything like that into mainline.
So let's assume for the meantime that there are no 'broken' commands we can
simply issue an XOFF before running each command - That should eliminate
most dropped character issues - This is Simon's latest 2-patch series.
Adding rx_flush() and a small local buffer will fix dropped characters due
to insufficiently small local UART Rx buffers (and brain-dead remote Tx
buffers) - That's a separate small patch
So any remaining dropped character issues are reduced to 'broken' commands
that use console I/O and then enter a busy loop which does not process
console I/O - Now we're into hack territory
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
