propeller-load terminal and carriage return / newline

Rayman · 2013-03-28 13:58

Just noticed the terminal and demos were probably written by non-Windows programmers...

Looks like it's rigged to work with "\n" and not "\r" for a new line...

So, my codes that were working fine with PST with just the "\r" are going to require changing to "\r\n"
to work in both places, I think...

David Betz · 2013-03-28 14:02

Rayman wrote: »

Just noticed the terminal and demos were probably written by non-Windows programmers...

Looks like it's rigged to work with "\n" and not "\r" for a new line...

So, my codes that were working fine with PST with just the "\r" are going to require changing to "\r\n"
to work in both places, I think...

The serial driver is supposed to translate \n to \r\n on output. I think this is actually a bug in PST. Yet another example of Parallax not following industry standards for handling terminal output. Most terminals require both \r and \n at the of a line.

Rayman · 2013-03-28 14:09

Ok, maybe that's why I saw somebody complaining about having two \r in their output...

So, I guess I have to put just "\n" to have it work right?
(if so, not sure I'm so happy about that...)

David Betz · 2013-03-28 14:53

Rayman wrote: »

Ok, maybe that's why I saw somebody complaining about having two \r in their output...

So, I guess I have to put just "\n" to have it work right?
(if so, not sure I'm so happy about that...)

Yes, \n is the Unix way of indicating newline and should output both \r and \n.

Rayman · 2013-03-28 15:03

Can you make it so \r\n gives just one 13 output and not two?

David Betz · 2013-03-28 15:07

Rayman wrote: »

Can you make it so \r\n gives just one 13 output and not two?

You can turn off "cooked" mode on stdout and then it will send to the terminal exactly what you print with no translations. Maybe we should instead get Parallax to fix PST?

David Betz · 2013-03-28 15:11

Try this:

stdout->_flag &= ~_IOCOOKED;

jazzed · 2013-03-28 15:26

Would the real Line-feed please stand up? Parallax will not change PST because of it.

This is a long standing problem. Good starting point http://en.wikipedia.org/wiki/Newline

Rayman · 2013-03-28 17:31

I imagine this is going to be nuisance issue going forward...

Having the serial driver replace \n with \r\n sounds a little strange to me. Is that what Linux does?
If not, I think we'd be better off without that... Can't you just have the terminal window treat \n as a newline with CR?
Is this "cooked" thing mean you are doing it in a non-standard way?

For now, I'll be happy if the "\r\n" combo in code works as I would expect the the loader's terminal...

SRLM · 2013-03-28 17:42

The same issue caught me by surprise as well: http://forums.parallax.com/showthread.php/146201-Extra-r-in-putc

David Betz · 2013-03-28 17:47

jazzed wrote: »

Would the real Line-feed please stand up? Parallax will not change PST because of it.

This is a long standing problem. Good starting point http://en.wikipedia.org/wiki/Newline

What audience do we want to address? Is it Spin programmers who might want to dabble in C? If so, matching PST might be a good idea. On the other hand, if we want to address C programmers then we should do what they expect. If they're coming from a Unix/Linux background I think they'll expect \n to be the end of line character and for it to send \r\n to the terminal. I believe that this also works in most C compilers that run under Windows.

Rayman · 2013-03-28 18:01

Since this is GCC, I guess I'd expect it to be the same as if it were Linux...
Does Linux really send \r\n over a serial connection when given \n?

David Betz · 2013-03-28 18:08

Rayman wrote: »

Since this is GCC, I guess I'd expect it to be the same as if it were Linux...
Does Linux really send \r\n over a serial connection when given \n?

I believe that is the normal behavior. You can use stty to change that though. I'm happy to be proven wrong on this and I agree that it is a pain that PropGCC does not behave the same as PST but I think it would be best for PropGCC to behave as C programmers expect.

Rayman · 2013-03-28 18:47

I think it's important to understand this behavior...
What do PropGCC and regular GCC do when writing to a file instead of serial port?
Does it then just do the \n character? Or, does it add the \r there too?

David Betz · 2013-03-28 18:48

Rayman wrote: »

I think it's important to understand this behavior...
What do PropGCC and regular GCC do when writing to a file instead of serial port?
Does it then just do the \n character? Or, does it add the \r there too?

Under Unix/Linux, it will write only the \n. It only does the \n to \r\n translation when writing to a terminal.

David Betz · 2013-03-28 19:09

I have an idea to make this work so that it is compatible with PST and what Propeller user's expect. We could have the "cooked" mode of the PropGCC library translate all \n characters to \r. For this to work you'd either have to use PST as your terminal program or you'd have to configure whatever terminal program you're using to insert a \n after any \r. I think this is an option on most terminal programs. It probably isn't the default though so it would be a bit of a pain for people using anything other than PST. We could make propeller-load insert \n after every \r so it would work and I imagine Steve could make the terminal emulator in SimpleIDE behave in the same way. This would allow C programmers to use \n to terminate lines and the output would be as expected on PST and any terminal configured to insert \n after \r. It's kind of ugly but at least it lets C code be written as a C programmer would expect.

Eric: What is your opinion? Do you think this would help or just confuse things more?

Dr_Acula · 2013-03-28 23:53

This is a bit of a bugbear of mine as well. I do my own thing. Which happens to be the same as what is in the wiki article in post #8. I learnt to type on an ancient typewriter which punched out the 'o' as a hole. On a typewriter, a 'line feed' moves the paper up one line. And a 'carriage return' returns the carriage to the left side. Ditto on daisy wheel printers. So if you want a line feed, use an ascii 10. If you want a carriage return, use an ascii 13. If you want to overprint text three times, use ascii 13 three times but no ascii 10. And if you want to move the cursor to the left side, and go down to the next line, use both. Sometimes it is useful to have a carriage return but not have a line feed - ie a simple counter on a TV screen usingn the tv object that changes numbers on the same line but doesn't scroll them. Just issue an ascii 13 at the end of the line but not a 10. /end rant

Rayman · 2013-03-29 02:59

Dr_Acula sounds like a Windows/Dos guy like me... I always use "\r\n" in my WIndows C++ codes. I think that's what mose Windows programmers do...

I guess I'll be happy if "\r\n" works with the loader terminal. I think it will, sounds like treats the "\r" character properly, so having 2 of them probably makes no difference.

Actually, I guess it is PST that is behaving in a non-standard fashion by giving a newline with "\r"... Maybe that's something they could easily add an option to fix...

ersmith · 2013-03-29 04:23

David Betz wrote: »

I have an idea to make this work so that it is compatible with PST and what Propeller user's expect. We could have the "cooked" mode of the PropGCC library translate all \n characters to \r.

I think that would just confuse things more.

In C the \n character means "end of line"; it is *not* necessarily ASCII 10. The standard "hello, world" program is:

#include <stdio.h>
void main() { printf("hello, world\n"); }

(see Kernighan and Ritchie, page 7, or the first few Google hits for "C hello world"). There is no \r. K&R specifies that \n advances the cursor to the left margin of the next line. For many terminals, this means outputting the ASCII sequence 13, 10.

Eric

David Betz · 2013-03-29 04:35

ersmith wrote: »
I think that would just confuse things more.

In C the \n character means "end of line"; it is *not* necessarily ASCII 10. The standard "hello, world" program is:
#include <stdio.h>
void main() { printf("hello, world\n"); }
(see Kernighan and Ritchie, page 7, or the first few Google hits for "C hello world"). There is no \r. K&R specifies that \n advances the cursor to the left margin of the next line. For many terminals, this means outputting the ASCII sequence 13, 10.

Eric

Sorry, I wasn't suggesting that Hello World be rewritten to use \r. I was just suggesting that cooked mode translate \n to \r on output. Your Hello World program would run fine as written. The big downside is that the output wouldn't look right on any terminal that didn't work like PST works. It only requires a \r to go to the beginning of the next line.

Edit: By the way, I don't really like what I'm suggesting. I'm just trying to find a way to make PropGCC work with the non-standard PST.

Rayman · 2013-03-29 06:11

I can't find anything saying that the Linux serial driver will replace outgoing \n with \r\n by default...

Do you have a reference that says this is the default behavior?

This page kinda suggests it only does this when told to with special commands:
http://frank.harvard.edu/~coldwell/terminals/

BTW: I found the loader works the way I want when fed "\r\n", so I'm happy the way it is.
And, I don't really see a need for using PST with PropGCC at the moment...

David Betz · 2013-03-29 06:32

From the article you mentioned:

Therefore, the most common character substitution configuration is to set the flags ICRNL and ONLCR and leave the rest cleared. 

    tios.c_iflag &= ~(IGNCR | INLCR);
    tios.c_iflag |= ICRNL;
    tios.c_oflag |= ONLCR;

The ONLCR is what translates \n to \r \n.

Edit: By the way, I was wrong about this having to do with "cooked" mode. That only affects input not output but I believe it is responsible for \r being translated to \n on input.

Rayman · 2013-03-29 06:44

Ok, I see that now. To me, this looks like Linux knows it's behaving badly internally and so is rigged to fix itself when talking to the outside world...

Ok, So I feel happier about the situation now. Only thing that troubles me now is why my own SPIN code has just "\r" in it...
I must have been unknownly influenced by a Mac programmer...

David Betz · 2013-03-29 06:49

Rayman wrote: »

Ok, I see that now. To me, this looks like Linux knows it's behaving badly internally and so is rigged to fix itself when talking to the outside world...

Ok, So I feel happier about the situation now. Only thing that troubles me now is why my own SPIN code has just "\r" in it...
I must have been unknownly influenced by a Mac programmer...

It only has \r in it because that is what PST expects isn't it?

By the way, I'm not saying that I like the Unix/Linux way of doing this. I'm just saying that it is probably what C programmers will expect.

SRLM · 2013-03-29 10:34

David Betz wrote: »

Edit: By the way, I was wrong about this having to do with "cooked" mode. That only affects input not output but I believe it is responsible for \r being translated to \n on input.

Do you have the code snippet for "uncooking" the output?

This page has the input version, but not the output. http://propgcc.googlecode.com/hg/doc/Library.html

David Betz · 2013-03-29 10:45

SRLM wrote: »

Do you have the code snippet for "uncooking" the output?

This page has the input version, but not the output. http://propgcc.googlecode.com/hg/doc/Library.html

Sorry, I was wrong about "cooked". It only affects the input side. It looks to me as though there is no way to turn off the expansion of \n to \r \n for terminal output. I guess we could add a flag to control that.

propeller-load terminal and carriage return / newline

Comments