When 0x0d become 0x0a

I'm afraid that if you need such tight control of the serial-port data, you are probably going to have to work with low-level file I/O, at least a bit.

Specifically, you are going to need the fd of your FILE * file (use POSIX fileno(3) to retrieve), and either the termios(3) tcgetattr()/tcsetattr() calls, or the ioctl(2) tty calls. You want to change the line conditioning of your serial port from COOKED or CBREAK mode to RAW mode.

Sorry, I can't help you there. I don't know of any website that shows all the serial port options for Linux.

However, the tty_ioctl(4), ioctl(2), and termios(3) manpages should help you.

HTH

I've no idea what "*opts() functions" mean.

Whatever.

Not a problem - familiar with fileno(); I should have said as much; there's some boilerplate stuff already in the code to set baud rate and all using a return from fileno();

I've just never done the full, comprehensive study of all the serial port options in Linux.

I forget what it was that I ran into that forced the use of fopen() rather than open().

Excellent - those are a good start. Thanks!

At Thu, 13 Feb 2014 18:39:23 -0600, Les Cargill rearranged some electrons to write:

Try:

I said this because there is a bit you can OR into the last argument to open() that causes the LF/CR translation to stop. I can't use that.

Huh? Can you point to code or documentation for that?

I've been using serial ports on Linux for 20 years, I've written multiple tty and serial drivers for Linux, and I've spent a lot of time in general wandering around the the Linux serial subsystem. I've never heard of such a thing before. It's also not mentioned in the open() man page. The last parameter to open() controls a newly created file's mode bits (read/write/execute for user/group/other). That argument is ignored (and need not even be passed) when opening a file or device that already exists (as you are when opening a serial port).

Is it possible that Les remembers the Windows I/O routines which did indeed have a binary/ascii option that handled line endings?

This may be a local heresy specific to the system I am using. To be sure, this system's the first one I'd seen that does this.

my habit is to use fopen() as a default ( because it seems more multiplatform than open() and I have to mix Windows and Linux a lot ) , so I probably have many less miles on open() than you do.

The stack I am using may merge _fmode semantics in with open(). Seems kinda Windows-ish, though.

You are absolutely correct. I'll try to report back later.

That would certainly explain it, although this happens to be on something identified as Linux. I'll try to clear this up later.

It may be that the library in play ( this is a Tiny Linux ) mixes _fmode and open() semantics.

Text vs.binary mode is a non-sequitur when it comes to Linux.

After a bit of Googling it appears it might be a Microsoftism. Google also finds discussion of adding O_TEXT and O_BINARY flags to cygwin. I don't know if it happened...

Definitively. I just suspect it may have bled over into nominally Linux systems.

All goes back to "raw" and "cooked" mode in DOS, which originated there, SFAIK.

Heresy! :)

No, raw and cooked mode is a Unix thing and predates DOS by a long time. On Unix, tty devices (like serial ports) can be in raw or canonical (AKA "cooked") mode. When in cooked mode, you can enable things like conversion of cr->lf or vice versa, mapping lowercase->uppercase, handling various control characters, xon/xoff flow control, and so on.

Ah; so it's tty devices, not all files. Where in DOS*, I'm thinking it was extended to all files - fopen(...,"rb") being the override to be binary.

Right. stty ,termios.h ad nauseum. Kewl. Thanks, Grant.

Right. It's something you configure using termios.h and friends after you've opened the file.

Yes, I think that was common practice for fopen() provided with many DOS compilers. I don't remember if there was a corresponding option to open() as you mentioned, but I wouldn't be surprised.

Yep, where Unix's "everything is just a stream of bytes" model starts to unravel.