Hi Wolfgang, On Monday, October 24, 2011, Wolfgang Denk <w...@denx.de> wrote: > Dear Graeme Russ, > > In message < calbutcjh8bvzfvh14d83wr2jov89o9jvjo9vzzb7r_zgkzz...@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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
