RTS-CTS bad on ttyf??

[karron at MCIRPS2.MED.NYU.EDU]

Vernon Schryver was kind enough to bring to my attention the
sgi specs for hardware serial port handshake. After more than
a few days, I find that, at least on my machine, a 70G,
the following IS NOT TRUE!!

I am sitting here with a breakout box lit up on top of the machine
to my right, and jumpers affixed to RTS-CTS and DCD-DTR.

>Each IRIX tty port has three aliases, distinquished by the two most
>significant bits of the minor device number, or by the /dev/tty[dmf]* name.
>
>ttyd* use pins 2,3, & 7.  Thus, the system simply babbles the output,
>    subject at most to XON/XOFF flow control.  At high speeds, either the
>    system or the printer will loose ^S or ^Q characters and bad things
>    will happen.

This always works, only at high speeds (> 9600) it drops characters, i assume
because XON-XOFF is not fast enough.

>ttym* use 2,3,7,8, and 9/20.  The system will refuse to complete an open(2)
>    until pin 8, DCD, is true.  Otherwise, ttym* are the same as ttyd*.  A
>    handy hack is to connect pins 8 and 9/20, to make a ttym* that is
>    really connected to a dumb, 3-wire device complete an open(2).

Yes, this checks out. The open does hang until DCD is asserted on all ports.

>ttyf* use 2,3,4,5,7,8, and 9/20.  A port under its ttyf name behaves the
>    same as under its ttym name, except that it honors CTS as required by
>    RS-232-C, and expects the device honor RTS as in the de facto standard
>    "hardware flowcontrol".

WRONG ! . These ports should open, but no characters should move until
CTS is engaged. I don't know about newer machines, but the CTS pin
seems to be GROUNDED, as I can't get the breakout box led to light
up when it is connected to +BATTERY, or low when -BATTERY.

I am also finding that the kermit I use does a core dump on trying
to open ttyf[1,2] with handshake engages. After a while, I am getting
messages about streams being out of resourses. I will reboot the
machine to clear the streams kernel, but this does not look good.

The /dev/tty{d,m}4 (I only tested 4, and don't want to spend
more time on this) do NOT do RTS-CTS, as expected. the /dev/tty{f}4 lines
does asssert RTS, and drops it as its buffer fills. It does NOT
listen to CTS. Indeed, I think that that line is shorted someplace
judging from the behavior of the break out box LEDs'.

I can use RTS-CTS between the host and the peripheral device.  The host can
tell the peripheral to stop transmitting, but the peripheral can not tell the
host to be quiet.  For my application (verbose peripheral limited by host),
that is fine.  However, since I can't get a signal from the hosts CTS,
loopback testing of the host RTS-CTS does NOT work.  Indeed, my experience
with RTS-CTS signaling is that the host should not transmit unless CTS is held
high.  It seems that sgi does not respect CTS, and holds RTS up except when it
does not want characters.  The tty{m}4 properties seem to work as expected.
The machine would send a HANGUP (or at least kermit said somthing) signal when
DCD was disconnected.

This may explain my problems with running laser printers at 19200 and higher
speeds (verbose host limited by peripheral).  There, the host has to respect
CTS, as the host is doing all of the talking.  My particular problem is with a
peripheral that is always talking, so I can get this project running at high
speed.

My expectation is that RTS-CTS would permit faster overall performance than
XON-XOFF or NO HANDSHAKE. I find that for short polled messages, performance
is WORSE. I don't lose characters on short messages, as the buffers
seen fast enough not to loose characters. The threshold for triggering
RTS as the communications circular buffers fill is set too low. The machine
is dropping RTS far too often, when without hanshaking, no characters are
lost. It there a way to set a high water mark on the comm buffers ?

I hope that this problem is limited only to my machine, and is not
a problem on newer systems. This would be most apparent with high
speed serial printers, not with high speed serial digitizers.

For your information, I am using a breakout box with
jumpers to loopback TD-RD, RTS-CTS, and DCD-DTR . I have tested the
9-25 wire cables, and verified things on all (/dev/tty{d,m,f}{1,2,3,4}
ports.

This stuff has been driving me crazy. I can't seem to get the speed up
on a number of serial devices because the hardware handshake is not
working properly. I have an old dunn video camera I gave up on and
run at 300 baud attached to a 50GT machine. I suspect that the problem
may also extend to that machine too, but has crashed and burned, and is
awaiting a service call.

uname -a

mcirps2 mcirps2 3.3 06011629 IP4

hinv
1 12 MHZ IP4 Processor
FPU: MIPS R2010 VLSI Floating Point Chip Revision: 2.0
CPU: MIPS R2000 Processor Chip Revision: 5.0
Data cache size: 32 Kbytes
Instruction cache size: 64 Kbytes
Main memory size: 16 Mbytes
ENP-10 Ethernet controller 0, firmware version 0 (CMC)
Graphics option installed
Interphase 3201 2-drive ESDI disk controller 0
ESDI Disk drive: unit 0 on Interphase controller 0
Integral SCSI controller 0: Version WD33C93
Tape drive: unit 7 on SCSI controller 0: QIC 24

I hope that this problem is unique to my configuration.
+-----------------------------------------------------------------------------+
| karron at nyu.edu                          Dan Karron                          |
| . . . . . . . . . . . . . .             New York University Medical Center  |
| 560 First Avenue           \ \    Pager <1> (212) 397 9330                  |
| New York, New York 10016    \**\        <2> 10896   <3> <your-number-here>  |
| (212) 340 5210               \**\__________________________________________ |
+-----------------------------------------------------------------------------+