From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sun, 1 Dec 2013 00:04:06 +0100 Subject: [U-Boot] [PATCH] serial: lpc32xx: send CR before LF In-Reply-To: <20131130204347.EFF9B38015F@gemini.denx.de> References: <1385822821-7465-1-git-send-email-vz@mleia.com> <201311301642.36531.marex@denx.de> <20131130204347.EFF9B38015F@gemini.denx.de> Message-ID: <201312010004.06379.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201311301642.36531.marex@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