serial: stm32: Automatically generate CR when LF is observed

Currently the u-boot output looks rather odd when running the minicom terminal emulator in its default mode (just a string of "random" looking text down the right hand side of the screen).

This is caused by a combination of minicom not automatically wrapping lines and the stm32 serial driver never sending a carriage return.

Issue is trivially solved by automatically generating a CR whenever a LF is transmitted, Several other serial drivers implement this behaviour.

---
 drivers/serial/serial_stm32.c | 4 ++++
 1 file changed, 4 insertions(+)

index 3c80096..8c613db 100644
@@ -81,6 +81,10 @@ static int stm32_serial_getc(void)
 static void stm32_serial_putc(const char c)
 {
 	struct stm32_serial *usart = (struct stm32_serial *)USART_BASE;
+
+	if (c == '\n')
+		stm32_serial_putc('\r');
+
 	while ((readl(&usart->sr) & USART_SR_FLAG_TXE) == 0)
 		;
 	writel(c, &usart->dr);

2.1.0

Strange, this was already posted by Kunhua Huang - then reverted in commit 698a12bef9e782dcd99c555a739c16eec8669f14. Anyway, yes this carriage return should be added there. I simply forgot it since I had implicit CR for each LF turned on in my terminal. Never thought this would cause so much havoc for users ;)

/Kamil

2015-05-12 21:25 GMT+02:00 Daniel Thompson <[email protected]>:

I reverted it since the author said it wasn't needed with the other patch they did being applied. Daniel, can you confirm the odd behavior exists with top of tree? Thanks!

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150512/7d809f1d/attachment.sig>

Sorry about my wrong expression.

In these two patch "[U-Boot] [PATCH v2] stm32f4: fix serial output" and "[U-Boot] [PATCH v2] stm32f4: add serial print port" , there are same and similar code as below.

In "[U-Boot] [PATCH v2] stm32f4: fix serial output" :

	struct stm32_serial *usart = (struct stm32_serial *)USART_BASE;
	+
	+	if (c == '\n')
	+		stm32_serial_putc('\r');
	+
	while ((readl(&usart->sr) & USART_SR_FLAG_TXE) == 0)
			;
	writel(c, &usart->dr);

In "[U-Boot] [PATCH v2] stm32f4: add serial print port" :

	-	struct stm32_serial *usart = (struct stm32_serial *)USART_BASE;
	+	struct stm32_serial *usart =
	+		(struct stm32_serial *)usart_base[USART_PORT];
	+
	+	if (c == '\n')
	+		stm32_serial_putc('\r');
	+
		while ((readl(&usart->sr) & USART_SR_FLAG_TXE) == 0)
				;
		writel(c, &usart->dr);

If these "two patch" patch at the same time, it may happened conflict.

I have reply the mail in "[U-Boot] [U-Boot,v2] stm32f4: add serial print port" as below,

This means that "add serial print port" has already include "stm32f4: fix serial output".
So, if patch "add serial print port", then patch "stm32f4: fix serial output" should not be patch.

But patch these "two patch" and then revert it. It will cause the code disappear.

Thanks to Daniel Thompson.

Yes, the odd behavior still exists with top of tree.

That said, I lucked out here.

In truth I had the problem because my git tree was slightly more out of date than I thought it was (and because a google search for "serial u-boot stm32" before posting my patch didn't notice the code from Kunhua).

So... my patch won't apply to HEAD anyway but reverting the revert would be very welcome!

Daniel.