Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201311301642.36531.ma...@denx.de> you wrote: > > Dear Vladimir Zapolskiy, > > > > > For LPC32XX high-speed UART it is required to send a carriage return > > > symbol along with line feed. > > > > Why ? > > Because we are actually emulating a classical type writer here, and to > start printing at the beginning of a new line requires two separate > actions: performing a line feed (i. e. scrolling the paper one line > up) and a crriage return (i. e. repositioning the drum such that the > next character will be printed in column 1. > > In the strict sense, the ASCII characters represent the line feed and > '\r' the carriage return, respectively. To print the equivalent of > the "new line" as it is interpreted by the C standard, we have to > translate the single C character into a two-character sequence. You > can trace this back to the very beginnings of Unix; you can see the > same in Unix version 6 drivers, for example.
Thanks for such a nice explanations ;-) I still have to wonder, why do we not do this emulation in the serial subsystem core now, but still have such a duplication of code in drivers ? I guess I can answer this myself though: a) We didn't clean this up, even if we do now have a CONFIG_SERIAL_MULTI enabled by default b) There might still be people invoking the driver functions directly There might be even more reasons, but OK, I guess I get it now. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
