Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!unido!math.fu-berlin.de!fub!geminix.in-berlin.de!gemini From: gemini@geminix.in-berlin.de (Uwe Doering) Newsgroups: comp.unix.sysv386 Subject: Re: Help Please with Telebit and SCO RTS/CTS Setup?! (LONG) Keywords: RTS/CTS Hardware Flow Telebit RS-232 Unix 386 SCO Message-ID: Date: 5 Apr 91 13:04:43 GMT References: <5176@mjbtn.JOBSOFT.COM> Organization: Private UNIX Site Lines: 58 root@mjbtn.JOBSOFT.COM (Mark J. Bailey) writes: >I am having a problem that I am not sure how to handle. Maybe some of you >can help. > >I am trying to get FULL DUPLEX hardware (RTS/CTS) flow control working on >SCO ODT 1.0 (unix version 3.2.1). I am not having much luck. The modem is This is a common misunderstanding of how RTSFLOW works under SCO UNIX (and Xenix as well). SCO implemented a half duplex type of hardware flow control, as it is described in the original RS232C standard. That is, RTS signals the modem whether there are any characters in the _computer's_ output buffer. If there are none, RTS is low, otherwise it's high. This won't work at all if the modem is configured to use full duplex hardware flow control. In this mode RTS signals the modem that the computer is ready to receive characters. As far as I know, there is no way to get this working with the original SCO sio driver, as it isn't designed for that type of handshake. > [detailed problem description deleted] >Now, I spoke with a tech support rep at Telebit, and he said that there was >a limitation with SCO Unix that when you run a port at speeds greater than >9600, RTS/CTS does not work in full duplex mode. He said 9600 or below it >works fine. Well, I tried this at 9600, and the exact same behavior occurred. >I tried this on different serial ports; same thing. I am using a straight >25-pin cable with serial port as DTE and modem as DCE. The fact that it also >fails on 9600 baud makes me suspect that something else is fouled up here. Yes. The port speed has nothing to do with your problem. >Any help and/or suggestions would be greatly appreciated. I am sure I am >not the only one to run into this. I do know about FAS 2.08, but I am really >not sure how to implement it into the SCO scheme of 'uugetty' and the post >dial/connect reset (dial -h .....). Ideas on that welcome too. FAS 2.08 is currently the only dumb port driver that is capable of full duplex hardware flow control (at least I think so). Therefore, you can't solve your problem without FAS as long as you don't want to buy an expensive "intelligent" card. You should be able to use FAS as a plug-in replacement for the sio without having to change your setup. This would only be necessary if you would want to use FAS's extended features like dialin/dialout on the same line while using `getty' etc. Note that the RTSFLOW (as well as the CTSFLOW) works in an SCO compatible way under FAS 2.08. But you can enable full duplex hardware flow control via the minor device number for a port. In this mode, RTS/CTSFLOW are simply ignored and hardware flow control is always enabled. As a side effect, your software can use hw handshaking without even knowing that there is such a feature in your UNIX kernel. No more worrying about whether a program knows about the RTS/CTSFLOW flags or not. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini