Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!sdd.hp.com!hp-pcd!hpfcso!hpfcdc!perry
From: perry@hpfcdc.HP.COM (Perry Scott)
Newsgroups: comp.sys.hp
Subject: Re: RS232 Hardware Handshaking
Message-ID: <5570484@hpfcdc.HP.COM>
Date: 4 Sep 90 22:49:31 GMT
References: <429@node17.mecazh.uu.ch>
Organization: HP Fort Collins, Co.
Lines: 38

>The minor device number seems to be a major stumbling block, because
>nobody at HP whom I spoke to had had any experience of using the same line 
>as call-in/call-out. 

Create two devices - cuaXX/culXX and ttyXX.

mknod /dev/cuaXX c 1 0x0d0001		# uucp call-out
ln /dev/cuaXX /dev/culXX
mknod /dev/ttyXX c 1 0x0d0000		# uucp call-in

Put a getty on /dev/ttyXX for call-in.


>Further the HP documentation is contradictory about bit 3. One piece of 
>documentation states that as of HP-UX 5.2 Bit 3 of the minor device number 
>implements CTS/RTS handshaking. The spec for the HP98642 says NA against 
>Bit 3. The documentation for modem(7) says that setting the device to CCITT 
>mode (Bit 2) enables handshaking, as did someone at HP.

The 300 MUX driver responds to changes on the CTS line if you |= 0x08.
It is a hack; and is equivalent in the driver to receiving XOFF.

Since the MUX itself is not handling the pacing, you may experience the
MUX dribbling up to 16 characters after CTS goes low.  If that is a
problem, limit the transmitter buffer size.  This is from the driver:

define TXLIMIT 0x000030        /* minor number field */
u_char mux_tx_limit[4] = {16,8,4,1};    /* max chars sent after getting XOFF */

So, |= 0x00 => 16 bytes, |= 0x10 => 8 bytes, ..., |= 0x30 => 1 byte.
Setting this to one byte will make your CPU work harder.


I don't know if HP officially supports this - it was originally done to
get some big-deal business.  It works on against a 4955 protocol analyzer,
but never tried on a Swiss modem.  Caveat emptor....

Perry Scott