Re: Serial port: open vs fcntl
From: Floyd L. Davidson (floyd_at_apaflo.com)
Date: 08/02/05
- Next message: Floyd L. Davidson: "Re: Serial port: O_NONBLOCK vs VMIN and VTIME"
- Previous message: David Schwartz: "Re: SOCK_DGRAM atomicity vs SOCK_STREAM reliability for unix domain"
- In reply to: Simon Elliott: "Re: Serial port: open vs fcntl"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 02 Aug 2005 04:16:06 -0800
"Simon Elliott" <Simon at ctsn.co.uk> wrote:
>On 01/08/2005, Floyd L. Davidson wrote:
>> Here are some coding examples on my own web page,
>>
>> http://www.apaflo.com/floyd_davidson/code/terminal/
>
>... but hadn't seen this one. I like the way you've set up your serial
>configuration with a set of #defines at the top: neatly keeps it all
>together.
Thank you for the feedback. (In particular about that
particular point, because it has confused a couple of people and
every time I need to cut and paste something for an example I
have to edit it, which I've been known to totally flub; but, it
does happen to be something I like too...)
>> Specifically, to turn on/off CTS/RTS flow control by setting or
>> unsetting the CRTSCTS bits in the c_cflag member of the termios
>> struct:
...
>Thanks for this. I wonder why POSIX has options for XON/XOFF but not
>for RTS/CTS.
That was POSIX compliant code though, because POSIX allows an
implementation to add to the minimal definition of struct
termios.
As to why it isn't defined, I don't know. Hardware flow control
is not done today the way it was originally defined by the
RS-232 Standard, and it is possible that the conflicts are the
reason it is not defined. Also, when POSIX was first defined
there were a number of other defines being used. For example,
W. Richard Stevens in "Advanced Programming in a UNIX
Environment" (APUE) published in 1992 lists CCTS_IFLOW and
CCTS_OFLOW from BSD 4.3, for individually enabling RTS and CTS
respectively, but does not list CRTSCTS at all.
Note that a number of other things are also missing. Speeds
higher than B38400, IMAXBEL, IXANY, IUCLC, and OLCUC are just
some of the non-POSIX extentions that are ubiquitous today.
Most of what is not defined just simply wasn't in earlier UNIX.
...
>... or maybe I still don't! It seems that CLOCAL and CRTSCTS are
>incompatible options. In the termios(3) man page:
>
>CLOCAL Ignore modem control lines.
>CRTSCTS (not in POSIX) Enable RTS/CTS (hardware) flow control.
CLOCAL also controls DSR, DTR, DCD line, and others (RI?, Clock
and Sync???) Those might well be needed when hardware flow
control is not. For example most RS-232 terminals simply do not
need hardware flow control, they do need all of the other modem
control lines if they are connected via a modem.
>Fair enough, I can see why these are mutually exclusive options. But in
Not really mutually exclusive, just interlocking. As with
several other options, one is not of any use unless the other is
unset. You will also find several options that have no
meaning if ICANON is not set, and some that have no meaning if
it is set.
>Michael Sweet's guide:
>
>"The c_cflag member contains two options that should always be enabled,
>CLOCAL and CREAD. These will ensure that your program does not become
>the 'owner' of the port subject to sporatic job control and hangup
>signals, and also that the serial interface driver will read incoming
>data bytes."
Ouch, this gets deep. I'll bush over parts of it, but you'll
really need to get a copy of Stevens' APUE to get the whole
picture of how all of these things interact. It is complex!
What Sweet is saying is very traditional POSIX. Of course today
all the world is *not* terminals that are either local (no
modem) or remote (with a modem that needs to be redialed), which
is what the flags like CLOCAL, ISIG, IGNBRK and others were
originally intended to deal with. Because serial ports were
originally designed for terminals, and the interface was
intended for that, it requires creative use of the little quirks
to use them for other purposes.
If CLOCAL is set, then we have a local terminal with no modem,
and the controlling process (session leader) need never be
concerned with it "disconnecting". If CLOCAL is unset though,
the connection is via some mechanism such as a modem, and a
reconnect process needs to be initiated... so a SIGHUP
communicates that from the device driver to the controlling
process.
Enabling CLOCAL and not using modem control lines is obviously
one way to insulate a program from SIGHUP signals from the
device driver. Having the process ignore SIGHUP signals is
another. Another, more commonly seen method, is to call open(2)
with the O_NOCTTY flag.
See termios flag ISIG, and characters SUSP, DSUSP plus signals
SIGQUIT, SIGINTR, SIGTTOU, SIGTTIN, and SIGTSTOP for similar
relationships between signals and Job Control. See termios
flags IGNBRK and BRKINT plus signal SIGINT for another
relationship between the device driver and signals that may be
sent to the process.
The point with CREAD seems obvious if the device is a terminal,
but in fact I see no reason to enable CREAD if there will never
be any incoming data. Not all uses of an RS-232 port are for
modems or terminals, and some devices are read only, or for that
matter do not even use the data lines at all (Tx or Rx!).
>What if I want my program to not become the owner of the port, not be
>hit by signals such as SIGHUP, but I do want RTS/CTS flow control?
Open the port with O_NOCTTY, clear CLOCAL, and set CRTSCTS. For
other signals SIGIGN and ISIG should be enabled, and BRKINT
cleared.
-- Floyd L. Davidson <http://www.apaflo.com/floyd_davidson> Ukpeagvik (Barrow, Alaska) floyd@apaflo.com
- Next message: Floyd L. Davidson: "Re: Serial port: O_NONBLOCK vs VMIN and VTIME"
- Previous message: David Schwartz: "Re: SOCK_DGRAM atomicity vs SOCK_STREAM reliability for unix domain"
- In reply to: Simon Elliott: "Re: Serial port: open vs fcntl"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
