Xref: utzoo comp.sys.next:6982 comp.dcom.modems:6256
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.next,comp.dcom.modems
Subject: Re: CTS->XON/XOFF
Message-ID: <1990Jul14.062823.13751@math.lsa.umich.edu>
Date: 14 Jul 90 06:28:23 GMT
References: <8635@ubc-cs.UUCP>
Sender: usenet@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 43

In article <8635@ubc-cs.UUCP> rlin@cs.ubc.ca (Robert Lin) writes:
>Does anyone know if there is a device that converts a hardware hand-
>shaking device into XON/XOFF protocol? Here's the situation. I have
>a piece of hardware that talks through RS-232. It only supports
>hardware handshaking (CTS/RTS flow control). I want to communicate
>with it with a NeXT computer.
>
>The STUPID !@#?^% NeXT serial port only supports software XON/XOFF
>flow control. So now I am looking for a device that translates a
>CTS transition from off to on, into a ^Q, and a CTS transition
>from on to off, into a ^S. So to simulate software XON/XOFF with
>hardware.
>
>On the same note, has anyone had trouble with XON/XOFF at speeds
>greater than 9600? Everything seems to work fine at 9600, but when
>I crank it up to 19200, something screws up and the buffers get
>overflowed.
>
>Robert Lin <rlin@cs.ubc.ca>

I haven't had any problems at 19200, but 38400 is kind of poor. (At
least, I get lots of errors with Zmodem. Zmodem at 19200 runs along
nonstop, no troubles.)

The box you're asking for sounds a little strange. Since there's no
clock data to sync to in the signal lines, you'd have to select the
speed externally. And, you'd need a few bytes of buffering, since it's
likely that the side (de-)asserting the CTS will still have stuff to
transmit while you're inserting a ctrl-S/ctrl-Q.

(Say, what device is it you've got, anyway... I've been bothered by
this same problem with a USR HST modem. I guess it's an issue for any
high speed modem.)

Does your other box support any other type of flow control? (I know
HP plotters mean DTR toggling when they say "hardware flow control" I
guess support for this wasn't written into the 4.3BSD tty drivers, but
maybe it made it into the NeXT kernel...)
--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...