[OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> This is an example of one symptom:
> 
> oi%rhb {9} stty -a | egrep opost
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
> oi%rhb {10} stty -onlcr
> oi%rhb {11} stty -a | egrep opost
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

You're probably best off just using "truss -vioctl" to figure out what
those commands are actually doing.  I'll bet that you see a TCGETS with
oflag set to 0000005 followed by a TCSETSW with oflag set to 0000001,
showing that stty is in fact attempting to toggle that bit.

Then, when you do stty -a again, oflag is stubbornly set to 0000005.

The conclusion you can draw from that is that there's nothing at all
wrong with stty -- it's doing precisely what you asked -- and that it's
something else that's being cantankerous.

As an experiment, try this:

	stty -onlcr ; stty -a

You may well find that the output is jagged (due to the lack of
"onlcr"), and that the output includes "-onlcr".

The conclusion to draw from that experiment is that you're being
confused by your shell.  The shell itself (on issuing the prompt) is
"helpfully" setting some sane stty modes for you.

In other words, recompiling stty isn't going to do anything useful.

> I'm using tip running in an xterm to connect to an USB<->RS-232 adapter connected to an MSP430G2553 installed in a TI MSP430 LaunchPad.  The 'G2553 is running a forth interpreter.

OK.  I expect that the problems you have are related to the behavior of
"tip", not of stty.

> The example I gave looks like OBP because OBP is also a forth interpreter. I should probably have commented on that previously.  It's not really relevant, but could be confusing.

It's relevant because that remote system is sending data that is then
copied by tip through the tty to xterm.  Knowing what's going on
necessarily involves knowing precisely what the remote system is
expected to send.

> I have two different forth interpreters that run on the MSP430G2553, a 20 pin DIP w/ 16K flash & 512 byte RAM.  One was sending NL-CR and worked properly.  The second sent just NL which ttymon & tip *should* be able to convert to NL-CR for the display terminal, but did not.

When you're running "tip" in the foreground, it's in charge of the modes
on the tty.  stty has very little to do with it.

Looking at the tip source code (usr/src/cmd/tip/), it looks like tip
always puts the tty into "raw" mode (c_oflag = 0, and c_flag ~ICANON)
when handling data from the remote system.

Thus, that bare NL is going straight to xterm, and it's doing what the
xterm's default VT102-like terminal emulation tells it to do.  If this
is really xterm (and not the GNOME Terminal application or something
else), then setting "autolinefeed" (accessed by holding the ctrl key and
pressing the middle mouse- button) should fix the problem.

In short, the configuration of the terminal emulator (xterm in this
case) MUST match what the remote system thinks it's talking to.  If it
doesn't, you'll see unfortunate results.

> As noted previously, I've now modified the second forth so that it sends NL-CR and things work fine for my purposes.
> 
> In summary, I'm connecting to a remote host over a serial line. Old and obsolete cruft to most these days, but the predominate means of communicating w/ microcontrollers today and probably always will be.  It only takes 2 pins, Rx & Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU pins are very precious. It also doesn't even require a UART in the MCU, though many have them.  So *any* MCU w/ 2 free pins can use RS-232 to talk to the outside world.
> 
> This is what stty & ttymon exist for.  But it doesn't seem to work and appears to have been broken for some time as Solaris 10 has the same problem.  Nemeth et al note Solaris serial line discipline is a mess.  However, it appears to be worse than that.  It appears to be broken.

I don't think anything at all is wrong with the Solaris line discipline
support.  But those writing books can say whatever they want.  ;-}

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>