rlin@cs.ubc.ca (Robert Lin) (07/11/90)
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>
tnixon@hsfmsh.UUCP (Toby Nixon) (07/12/90)
In article <8635@ubc-cs.UUCP>, Robert Lin writes:
- Does anyone know if there is a device that converts a hardware hand-
- shaking device into XON/XOFF protocol?
Hmmmm. The Hayes Transet 1000 does that just fine (including giving
you 512K of buffers!), but we don't see it anymore. What you need
to get is a serial-to-serial buffer box from some place like Inmac
or Black Box Corp. These can usually be configured to have
different flow control methods on the two ports. Black Box has
something they call a "Micro Print Spooler" for $190 in a
serial-to-serial version. Inmac has an interface converter that,
with 0K buffer memory, costs only $125; it has both parallel and
serial ports, bidirectional, with flow control conversion at up to
38,400bps. I think the Inmac is closer to what you need.
- 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.
It's probably dependent on the device -- the depth of the FIFOs in
the UART, the interrupt latency in the operating system, the
priority of comm interrupts as opposed to others, etc. I've run
XON/XOFF at 38,400 with no problems, but on a device that has deep
FIFOs in the hardware.
-- Toby
-----------------------------------------------------------------------------
Toby Nixon, Principal Engineer Fax: +1-404-441-1213 Telex: 6502670805
Hayes Microcomputer Products Inc. Voice: +1-404-449-8791 CIS: 70271,404
Norcross, Georgia, USA BBS: +1-404-446-6336 MCI: TNIXON
Telemail: T.NIXON/HAYES AT&T: !tnixon
UUCP: ...!uunet!hayes!tnixon Internet: hayes!tnixon@uunet.uu.net
MHS: C=US / AD=ATTMAIL / PN=TOBY_L_NIXON / DD=TNIXON
-----------------------------------------------------------------------------kloppen@gmdzi.UUCP (Jelske Kloppenburg) (07/13/90)
rlin@cs.ubc.ca (Robert Lin) writes: > ... >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 am just at the beginning and working always with 19200. I observed too a termination of the shell in the following situation: press ^S, wait, press ^Q, press ^S. I have to admit I never tried with less than 19200. Regards j.k. (Jelske Kloppenburg / GMD) kloppen@gmdzi.UUCP
hyc@math.lsa.umich.edu (Howard Chu) (07/14/90)
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...
neil@uninet.cpd.com (Neil Gorsuch) (07/18/90)
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. How about a device that supports hardware flow control directly, such as our SCSI based serial/parallel box that is currently being ported to the NeXT? -- Neil Gorsuch INTERNET: neil@uninet.cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news
phil@ux1.cso.uiuc.edu (07/21/90)
> 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. This factor alone will prevent me from purchasing such a computer. Have you looked into whether it is a hardware limitation or a software limitation? I've found that in the PC world, virtually all serial ports do have hardware capability for CTS/RTS, but very few software products are capable of handling it. If it is a software limitation perhaps someone has, or you could, write a better serial port driver and relink it into the kernel. Keep in mind that ^Q ^R ^S ^T do not always have the same meaning. If the software on each end of a communication path operate in "raw" mode, it is these programs that determine what the meaning of these characters is. Networks and modems should NEVER interpret these. CTS/RTS is the correct way to flow control a single interface. With that in mind, I am also looking for some data compression modems that will CORRECTLY pass ^Q ^R ^S ^T fully transparently in both directions. They should be configurable to be transparent in all 8 bits and all 256 codes. --Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society <phil@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.