Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: quasar@ctt.bellcore.com (Laurence R. Brothers)
Newsgroups: comp.sys.sun
Subject: Sun serial port communication problem
Message-ID: <13782@bellcore.bellcore.com>
Date: 13 Feb 89 20:33:11 GMT
Sender: usenet@rice.edu
Organization: Computer Technology Transfer, Bellcore
Lines: 39
Approved: Sun-Spots@rice.edu
Original-Date: 1 Feb 89 21:22:54 GMT
X-Sun-Spots-Digest: Volume 7, Issue 151, message 6 of 16

OK, here's my problem. USA4SUN hasn't gotten back to me yet, so....

I'm writing a little application to read stuff coming in over my sun's
serial port (Sun-4/260, though it shouldn't make much difference).

Since I don't yet have the OGM (Obsolete Garbagey Machine) that will be
supplying the RS232 chatter, I'm faking it by connecting a null modem from
ttya to ttyb, writing to a, and reading from b.

My test reader just does an open on /dev/ttyb and sits there busy-waiting,
copying anything it reads to stdout. To write to ttya, I just either cat a
file into the device, or open it for writing from a toy program.

The problem is that my reader reads garbage. I mean, I get maybe half the
catted file more or less OK, (for some reason, all the end-of-line
characters get doubled), but after the file has been sent, the reader
still manages to get junk coming in. By junk, I don't mean just random
characters, but a sort of cuisinarted version of the original file, like
there's some buffer somewhere which is getting cycled through with
dissociated press.

If I cat from the keyboard into the ttya device, the result is even worse
-- the first line gets sent OK, the second is typically garbled, and the
third is totally scrambled.

I've tried a large variety of things. For example, removing the getty on
tty's a and b (yes, I reran init), doing reads and writes instead of
getc's and putc's, doing fgets's instead of getc's, setting
setbuf(stream,0) on a file pointer gotten from the device's file
descriptor, putting usleeps in both the writer and reader, etc. etc.  etc.

I suspect either some sort of timing problem, or some fundamental mistake
in trying to read and write these devices.

Can someone take pity on a poor AI hacker who doesn't even know the pins
in an RS232 plug by heart... (sob)?

	    Laurence R. Brothers (quasar@ctt.bellcore.com)
Bellcore -- Computer Technology Transfer -- Expert Systems Development