Extra \r in putc?

SRLM

I have a simple program that should output six characters per iteration: a \r, \n, and 4 bytes from an int. However, when I run the program I get the following output (in hex):

...
00000000: ec 2e 00 00 0d 0d 0a d5   32 00 00 0d 0d 0a be 36 
00000010: 00 00 0d 0d 0a a7 3a 00   00 0d 0d 0a 90 3e 00 00 
00000020: 0d 0d 0a 79 42 00 00 0d   0d 0a 62 46 00 00 0d 0d 
00000030: 0a 4b 4a 00 00 0d 0d 0a   34 4e 00 00 0d 0d 0a 1d 
...

Notice the double 0d in the output, even though the program only has one putc(0xD). This 0d is repeated throughout, so I know it's not a random event from outputing the four bytes from the int. I've looked at the assembly file, and it's has six calls to #_fputc, as expected.

There is a second problem as well. I've attached a screenshot of a logic analyzer capture of a packet of data, and the bytes are out of order. Notice how the \r\r\n is at the end of the packet, instead of at the beginning as expected. Again, I looked at the assembly code and it's as expected: the waitcnt is at the end of the packet, and the \r\n is at the beginning.

Any ideas on what is going on with this curious behavior?

#include <propeller.h>
#include <stdio.h>

int main(void){
	for(int i = 0;;i+=1001){
		putc(0xD, stdout);
		putc(0xA, stdout);		
		putc(((unsigned)(i & 0xFF)      ) >> 0,  stdout);
		putc(((unsigned)(i & 0xFF00)    ) >> 8,  stdout);
		putc(((unsigned)(i & 0xFF0000)  ) >> 16, stdout);
		putc(((unsigned)(i & 0xFF000000)) >> 24, stdout);
		waitcnt(CLKFREQ/2 + CNT);
	}
}

Compiled with:

propeller-elf-g++ -mlmm -O0 -save-temps simple_output.cpp
propeller-load -r -e a.out

Notes:
-I tried it with printf as well, and got the same results.
-I can "fix" the first problem by removing the first putc line, but the mystery character still appears.
-The same thing happens in -Os and -mcmm modes.

Thanks for any and all feedback.

David Betz

SRLM wrote: »

I have a simple program that should output six characters per iteration: a \r, \n, and 4 bytes from an int. However, when I run the program I get the following output (in hex):

...
00000000: ec 2e 00 00 0d 0d 0a d5   32 00 00 0d 0d 0a be 36 
00000010: 00 00 0d 0d 0a a7 3a 00   00 0d 0d 0a 90 3e 00 00 
00000020: 0d 0d 0a 79 42 00 00 0d   0d 0a 62 46 00 00 0d 0d 
00000030: 0a 4b 4a 00 00 0d 0d 0a   34 4e 00 00 0d 0d 0a 1d 
...

Notice the double 0d in the output, even though the program only has one putc(0xD). This 0d is repeated throughout, so I know it's not a random event from outputing the four bytes from the int. I've looked at the assembly file, and it's has six calls to #_fputc, as expected.

There is a second problem as well. I've attached a screenshot of a logic analyzer capture of a packet of data, and the bytes are out of order. Notice how the \r\r\n is at the end of the packet, instead of at the beginning as expected. Again, I looked at the assembly code and it's as expected: the waitcnt is at the end of the packet, and the \r\n is at the beginning.

Any ideas on what is going on with this curious behavior?

#include <propeller.h>
#include <stdio.h>

int main(void){
	for(int i = 0;;i+=1001){
		putc(0xD, stdout);
		putc(0xA, stdout);		
		putc(((unsigned)(i & 0xFF)      ) >> 0,  stdout);
		putc(((unsigned)(i & 0xFF00)    ) >> 8,  stdout);
		putc(((unsigned)(i & 0xFF0000)  ) >> 16, stdout);
		putc(((unsigned)(i & 0xFF000000)) >> 24, stdout);
		waitcnt(CLKFREQ/2 + CNT);
	}
}

Compiled with:

propeller-elf-g++ -mlmm -O0 -save-temps simple_output.cpp
propeller-load -r -e a.out

Notes:
-I tried it with printf as well, and got the same results.
-I can "fix" the first problem by removing the first putc line, but the mystery character still appears.
-The same thing happens in -Os and -mcmm modes.

Thanks for any and all feedback.

This is the standard way that text mode output to terminals works in C, all \n characters are translated to \r\n on output. This has been true since the Unix days. You can put the terminal in "raw mode" to prevent this translation but it happens by default.

SRLM

Ah, good to know. After I saw your answer, I did a brief search and the only reference for this behavior that I could find was this page where it says that "\n" is newline and carriage return. Still, a very quiet bug that might catch those who aren't paying attention (like me).

SRLM

A related thread: http://forums.parallax.com/showthread.php/147031-propeller-load-terminal-and-carriage-return-newline?p=1173259