Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!date '+%m/%d/%y %H:%M:%S'brchs1!bnr.ca!riceu!sun-spots-request
From: bds@hou2d.att.com (Bruce D Szablak)
Newsgroups: comp.sys.sun
Subject: Serial port access on Sun SLC
Keywords: Hardware
Message-ID: <434@brchh104.bnr.ca>
Date: 26 Nov 90 17:30:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
X-Original-Date: Sat, 10 Nov 90 15:36:22 EST
X-Sun-Spots-Digest: Volume 9, Issue 370, message 15
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

I need help connecting my SLC to Datakit.

I'm using Sun's splitter cable to permit access to both of the SLC's
serial ports (A and B). Using a loopback through a null modem I can login
into one port (that runs a getty) from the other port using cu without a
problem.

After performing that preliminary test I attempted to connect up to
Datakit. On port A, I found that using cu at 9600 baud worked only
occasionally - a speed mismatch appears to be the problem. Using another
window (I'm running under Openwindows), I did a "stty 2400 >/dev/ttya" and
got a working connection in those cases.

With a working connection to Datakit, I attempted to issue breaks to
Datakit using cu's ~%break command. The breaks merely caused Datakit to
repeat the DESTINATION prompt. From a nearby terminal, the breaks cause
the DKC: prompt to be displayed on that Datakit port.

Does anyone have any ideas/suggestions about breaks on the Sun SLC?

The other problem is with port B which simply does not work at all. I've
placed a breakout box on the line, and I believe that the Datakit requires
DTR to be high. When forced high on the breakout box, I get the same sort
of behaviour as on Port A. Note: The diagram for the SLC serial port
doesn't show a port B lead for DTR. Any suggestions about this problem?

Thanks in advance.