Writing raw bytes to stdio

threadz

Is there a way to write raw bytes to the UART port on the propellers pins 30 and 31 without having any characters escaped?
Whenever I try to write the value 10 using any of these:

printf("%c", (char) val);

putchar(val);

char output[2];
output[0] = val;
puts(output);

it gets escaped to the two character sequence 0x0b 0x0a.
I believe these are the \n and \r characters, which would constitute a standard line break for windows systems, so I understand why this escaping would be helpful in some instances. Is there a way to turn this off or otherwise work around this problem? Preferably without involving another cog or any spin code.

Thanks in advance


EDIT: writing to different pins would also work

DavidZemon

--Edit--
This reply is incorrect. See PropGCC's raw/cooked modes as mentioned in posts 4 and 5 of this thread.

threadz wrote: »

it gets escaped to the two character sequence 0x0b 0x0a.
I believe these are the \n and \r characters, which would constitute a standard line break for windows systems, so I understand why this escaping would be helpful in some instances. Is there a way to turn this off or otherwise work around this problem? Preferably without involving another cog or any spin code.

Not with the Parallax-written utilities (that I know of). This was an insignificant pet-peeve of mine that I handled in PropWare (honestly thinking it was completely useless, and that no one would ever care about it). You can either download the source code for any existing serial device and modify it such that it doesn't replace all instances of "\n" with "\n\r" or use PropWare's UART & Printer implementations, which do not do any such magic without you knowing.

You can see on line 41 of this file how a string is concatenated with the macro "CRLF", which simply expands to "\n\r". If you don't want the "\r", simply add "\n" to the end of your string and forget about the CRLF macro.

DavidZemon

By the way, this replacement only happens with the \n character. No other bytes are ever substituted or replaced in the serial implementations.

David Betz

Check out this Wiki page: http://propgcc.googlecode.com/hg/doc/Library.html#stdio

In particular, you need to turn off "cooked" mode like this:

  stdout->_flag &= ~_IOCOOKED;

Yeah, I know it's ugly but it works.

Edit: Changed stdin to stdout because the original post was about writing to stdout.

Tor

The "normal" mode for a terminal device is so-called 'cooked' mode, where certain characters are handled differently (e.g. ctrl-C gives an interrupt, and line feed is changed to carriage return/linefeed). It's called 'cooked' mode because there is a 'raw' mode where nothing gets interpreted. Terminal editors will operate in raw mode, for example. And things like serial data transfer programs and the like. The way to switch between these modes is usually by an ioctl function, described in the 'termios' Unix man page.
I don't know if this has been implemented for the runtime library used by propeller gcc though.

Edit: David popped in with useful information about this while I was writing.

-Tor

Dave Hein

There is also the buffering issue. The stdio serial drivers use a buffer of 20 bytes, IIRC. Bytes that are written out to stdout will go into this buffer, and not be transmitted until it is full or until a '\n' is sent, or until stdin is read. Calling fflush(stdout) will also cause the buffer to be transmitted. The buffering flag can be turned off by calling setvbuf(stdout, NULL, _IONBF, 0).

A similar situation exists with stdin as well. Calling getchar() will not immediately return a keypress, but waits until the CR is pressed. Buffering would need to be turned off on stdin if you want to read one key at a time. And you would need to turn off the echo flag if you want to provide your own echoing.

Heater.

Dave,

Buffering would need to be turned off on stdin if you want to read one key at a time...

Surely buffering and "cooking" are two orthogonal issues?

I can imagine wanting to communicate with some external device over a raw binary untranslated serial link but would still like to have some buffering in there.

Dave Hein

Yes, buffering, cooking and echoing are all independent.