Odd Behavior On Line Endings

Projects Programming
1

Probably get chewed out for cross-posting, as I mistakenly posted this in the Due forum. But, here goes...

I have two programs which communicate over serial to a PC. Although both are based on the same code, compiled with the same compiler, and both are running on the exact same hardware, when I do a "Serial.printf("hello\n");" one of them sends the string terminated by a single LF (as it should), and the other sends the string terminated by CR/LF! I can't for the life of me figure out why they are behaving differently. If I change the string to "hello\r", they both send the string followed by a CR, as they should. They are both communicating with a PC terminal program which is doing NO mapping so I can see what is actually received.

This happens whether the Serial port used in the Due Programming Port, Native Port, or one of the HardwareSerial ports, so it seems to be something happening within printf or perhaps the Stream or Print drivers.

Is there some magic setting or incantation that can cause LF to be conditionally mapped to CR/LF? There is nothing different in my code that could possibly explain this.

Regards,
Ray L.

2

Ray, yes, I noticed your post in the Due section :slight_smile:

You say " Although both are based on the same code ..", based, meaning that there are differences then ?
I assume you have #undef printf somewhere ?

Have you tried just printf(...) to see what result you get ?

There must be something in there that causes the compiler or pre-compiler stage to give those different results.
Code snippets ?

Paul

3

Does#undef printf have some effect on line endings?

There are no #undef printf's in either project....

Regards,
Ray L.

4

Hmmmm...... Using print, instead of printf, solves the problem. Not sure what to make of that...

Regards,
Ray L.

5

Take a look at this discussion:

6

I found the cause. In the modification to Print.h to enable full printf, are two instances of this stupid code:

	for(char *p = &buf[0]; *p; p++) // emulate cooked mode for newlines
	{
		if(*p == '\n')
			write('\r');
		write(*p);
	}

Took those out, and all is now as it should be.

Why on earth would that be included by default?

Regards,
Ray L.

7

Why on earth would that be included by default?

Causes that's what tty drivers on unix systems normally do. Because they used to actually be ttys.

otherwise you can
                 get output that looks
                                      like this!