Dear Graeme Russ, In message <4ea67491.5090...@gmail.com> you wrote: > > 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 -
???? Could you please explain what makes you think so? What the command does, and when it performs I/O or when it spens time for other tasks is only up to the command. If anything is broken then it is a design that puts restrictions on such behaviour. > 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 Prohibit is a bit of a strong word here. "Not support" is more like it. > So let's assume for the meantime that there are no 'broken' commands we can This is not an assumption. No implementation must put any restrictions on the timing behaviour of any commands. > simply issue an XOFF before running each command - That should eliminate That's brainded overhead. In 99.999% of all cases it's not needed. And it happens at completely the wrong place. Serial flow control is something we should deal with in the serial driver code. Nowhere else. I will not accept such a design nor such an implementation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Have you lived in this village all your life?" "No, not yet." _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
