From: bender@oobleck (Duke of Canterbury)
Newsgroups: comp.sys.sun.hardware
Subject: Re: Using STTY to change TTY characteristics
Date: 27 Jul 92 20:51:48 GMT
Reply-To: bender@oobleck.eng.sun.com
Distribution: na
Organization: SPARK's R US
NNTP-Posting-Host: oobleck
X-Newsreader: Tin 1.1 PL3

tarsa@elijah.mv.com (Greg Tarsa) writes:
: 
: In trying to do this I have encountered a strange problem: I cannot seem to
: set the terminal line characteristics with stty.  As far as I can tell, the
: stty call is either having no effect, or something is changing the
: characteristics back as soon as my stty request is complete.
:
: I am using the UCB version of stty as follows (for example):
: 	stty > /dev/ttya
: 
: and the speed indicated is 9600.  When I execute the following:
: 	stty 19200 > /dev/ttya
:
: I expect the speed to change to 19200 and it does not, likewise for any other
: terminal characteristic.  Executing the command as superuser or regular user
: does not change the outcome.  The terminal line is turned off in ttytab,
: that is the entry in /etc/tty (produced at startup) is "02ttya".

What is happening is the following:

    1. shell opens /dev/ttya as stdout for stty

    2. stty issues the ioctl(B19200) that sets the line characteristics
	(i.e. sets the baud rate to 19.2K in your example)

    3. stty exits, the shell closes /dev/ttya

    4. /dev/ttya is still at 19.2K baud, but the port is closed

    5. another process comes along and does an open(/dev/ttya)

    6. the device driver, as part of it's open() routine, sets up the serial
	port to default parameters (baud rate, parity, etc...)

    7. the driver returns from the open(/dev/ttya) call and the user process
	gets control again; it does a write(foo...)  to the serial port, but
	the data goes out at the default baud rate (9600 in this case).

The trick is to keep /dev/ttya open after stty is finished mucking with the
port parameters; one way that I've done it is:

	% ( stty 19200 ; command_to_run ) >/dev/ttya

This of course has the nasty side effect of sending "command_to_run"'s
stdout to the serial port as well, but that might not be a problem in some
cases.  The other thing you could do is:

	% ( stty 19200 ; sleep 1000000 ) >/dev/ttya &
	% command_to_run

This assumes that "command_to_run" will open /dev/ttya as well; if not, them
you can of course do:

	% ( stty 19200 ; sleep 1000000 ) >/dev/ttya &
	% command_to_run >/dev/ttya

BTW - the sllep should keep the port open for about 11-1/2 days...

This whole thing begs the question, however, of why the application that you
are trying to run doesn't explicitly set the serial port baud rate (and
perhaps other characteristics)?  If you are familiar with Sun's SPC/S, the
8-port serial card (with 1 parallel port), there is a mechanism that allows
you to establish various default settings on a per-port basis, so that for
example you could set up /dev/ttyz02 to have a default of 1200 baud, 8
bits/char and no parity whenever the driver opened that port.  Normal
ioctl()'s to change port parameters issued by the application that opened
the port will still work, of course.

: I have perused the stty(1v) and tty(4) manual pages but have no clue as to
: what I am doing wrong.  This command seqence works fine under ULTRIX.
			  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, that's not surprising.

mike
Newsgroups: com.dsp,comp.sys.sun.hardware