When 0x0d become 0x0a

[Les Cargill]

I'm porting some code from one Linux to another. It uses serial ports.

As opened, the serial port converts 0x0d characters to 0x0a characters.

I have done some googling to find which *opts() functions control
setting the file referred to by the handle for the serial port
to be a pure, binary file. I see the one that turns off this conversion,
but I want all characters to be received completely untrammelled.

I also need to use fopen()... fclose(), so ORed together last-argument
things in open() are out.

What's a good website that shows *all* the serial port options for Linux?

--
Les Cargill

[Lew Pitcher]

On Thursday 13 February 2014 19:39, in comp.os.linux.embedded, "Les Cargill"

<lcarg...@comcast.com> wrote:

> I'm porting some code from one Linux to another. It uses serial ports.
>
> As opened, the serial port converts 0x0d characters to 0x0a characters.
>
> I have done some googling to find which *opts() functions control
> setting the file referred to by the handle for the serial port
> to be a pure, binary file. I see the one that turns off this conversion,
> but I want all characters to be received completely untrammelled.
>
> I also need to use fopen()... fclose(), so ORed together last-argument
> things in open() are out.

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.

> What's a good website that shows *all* the serial port options for Linux?

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
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[Grant Edwards]

On 2014-02-14, Les Cargill <lcarg...@comcast.com> wrote:
> I'm porting some code from one Linux to another. It uses serial ports.
>
> As opened, the serial port converts 0x0d characters to 0x0a characters.
>
> I have done some googling to find which *opts() functions

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

> control setting the file referred to by the handle for the serial
> port to be a pure, binary file. I see the one that turns off this
> conversion, but I want all characters to be received completely
> untrammelled.

http://www.cmrr.umn.edu/~strupp/serial.html

> I also need to use fopen()... fclose(), so ORed together last-argument
> things in open() are out.

Whatever.

--
Grant

[Les Cargill]

Lew Pitcher wrote:
> On Thursday 13 February 2014 19:39, in comp.os.linux.embedded, "Les Cargill"
> <lcarg...@comcast.com> wrote:
>
>> I'm porting some code from one Linux to another. It uses serial ports.
>>
>> As opened, the serial port converts 0x0d characters to 0x0a characters.
>>
>> I have done some googling to find which *opts() functions control
>> setting the file referred to by the handle for the serial port
>> to be a pure, binary file. I see the one that turns off this conversion,
>> but I want all characters to be received completely untrammelled.
>>
>> I also need to use fopen()... fclose(), so ORed together last-argument
>> things in open() are out.
>
> 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

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().

> (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.
>
>
>> What's a good website that shows *all* the serial port options for Linux?
>
> 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.
>

Excellent - those are a good start. Thanks!

> HTH
>

--
Les Cargill

[David]

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

Try: http://www.tldp.org/HOWTO/html_single/Serial-HOWTO/

[Les Cargill]

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.

--
Les Cargill

[Grant Edwards]

On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:

> 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).

--
Grant

[Przemek Klosowski]

On Sat, 15 Feb 2014 04:31:16 +0000, Grant Edwards wrote:

> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>
>> 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.

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

[Les Cargill]

Grant Edwards wrote:
> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>
>> 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?
>

http://gd.tuwien.ac.at/languages/c/programming-bbrown/c_075.htm

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.

http://stackoverflow.com/questions/2266992/no-o-binary-and-o-text-flags-in-linux

> 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.

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

> 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).
>

--

Les Cargill

[Les Cargill]

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.



--
Les Cargill

[Grant Edwards]

On 2014-04-12, Les Cargill <lcarg...@comcast.com> wrote:
> Grant Edwards wrote:
>> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>>
>>> 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?
>>
>
> http://gd.tuwien.ac.at/languages/c/programming-bbrown/c_075.htm
>
> 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.

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...

--
Grant Edwards grant.b.edwards Yow! LBJ, LBJ, how many
at JOKES did you tell today??!
gmail.com

[Les Cargill]

Grant Edwards wrote:
> On 2014-04-12, Les Cargill <lcarg...@comcast.com> wrote:
>> Grant Edwards wrote:
>>> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>>>
>>>> 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?
>>>
>>
>> http://gd.tuwien.ac.at/languages/c/programming-bbrown/c_075.htm
>>
>> 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.
>
> After a bit of Googling it appears it might be a Microsoftism.

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! :)

> Google
> also finds discussion of adding O_TEXT and O_BINARY flags to cygwin. I
> don't know if it happened...
>

--

Les Cargill

[Grant Edwards]

On 2014-04-14, Les Cargill <lcarg...@comcast.com> wrote:
> Grant Edwards wrote:
>> On 2014-04-12, Les Cargill <lcarg...@comcast.com> wrote:
>>> Grant Edwards wrote:
>>>> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>>>>
>>>>> 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?
>>>>
>>>
>>> http://gd.tuwien.ac.at/languages/c/programming-bbrown/c_075.htm
>>>
>>> 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.
>>
>> After a bit of Googling it appears it might be a Microsoftism.
>
> 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.

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.

--
Grant Edwards grant.b.edwards Yow! Do you think the
at "Monkees" should get gas on
gmail.com odd or even days?

[Les Cargill]

Grant Edwards wrote:
> On 2014-04-14, Les Cargill <lcarg...@comcast.com> wrote:
>> Grant Edwards wrote:
>>> On 2014-04-12, Les Cargill <lcarg...@comcast.com> wrote:
>>>> Grant Edwards wrote:
>>>>> On 2014-02-15, Les Cargill <lcarg...@comcast.com> wrote:
>>>>>
>>>>>> 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?
>>>>>
>>>>
>>>> http://gd.tuwien.ac.at/languages/c/programming-bbrown/c_075.htm
>>>>
>>>> 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.
>>>
>>> After a bit of Googling it appears it might be a Microsoftism.
>>
>> 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.
>
> 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.

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.

*and by extension Windows...

> 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.
>

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

--
Les Cargill

[Grant Edwards]

On 2014-04-15, Les Cargill <lcarg...@comcast.com> wrote:

>>> All goes back to "raw" and "cooked" mode in DOS, which originated
>>> there, SFAIK.
>>
>> 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.
>
> Ah; so it's tty devices, not all files.

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

> Where in DOS*, I'm thinking it was extended to all files -
> fopen(...,"rb") being the override to be binary.

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.

> *and by extension Windows...
>
>> 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.
>
> Right. stty ,termios.h ad nauseum. Kewl.

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

--
Grant Edwards grant.b.edwards Yow! NEWARK has been
at REZONED!! DES MOINES has
gmail.com been REZONED!!