root@mjbtn.JOBSOFT.COM (Mark J. Bailey) (04/02/91)
Hello Netlanders, 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 a Telebit Trailblazer Plus modem. I am locking the baud rate from the serial port to the modem at 19200 baud. I have S66=001 so that the modem serial port baud rate stays locked at that no matter what. I therefore need the hardware flow control for it to work reliably. I setup my /etc/gettydefs for RTSFLOW CTSFLOW as best as I could determine from the OS docs. My 19200 baud entry is as follows: 19200 # EXTA IGNPAR ICANON IXON IXANY OPOST HUPCL ECHO ECHOE ECHOK CS8 CREAD # EXTA IGNPAR ICANON IXON IXANY RTSFLOW CTSFLOW OPOST CS8 HUPCL ECHO ECHOE ECHOK CREAD #Telebit (tty2A)\r\nmjbtn!login: # 19200 Before I began working on this, I had only set CTSFLOW (not RTSFLOW too). That seems to work most of the time, but I wanted to do it more like the book and have the OS (DTE) signal RTS to the modem (DCE). My troubles begin when I include RTSFLOW. I use the dialTBIT.c file for my dialer. The MSETUP strings are: #define MDSETUP1 "AT&FE0F1M0Q4V1X3S0=2S2=043S45=0S48=1S50=0S51=254S52=2\r" #define MDSETUP2 "ATS53=1S54=3S55=0S58=2S60=0S66=1S68=255S92=1S110=255S111=255&W\r" The Telebit settings resulting are: E0 F1 M1 Q4 P V1 X1 Version BA4.00 S00=002 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S45=000 S47=004 S48=000 S49=000 S50=000 S51=254 S52=002 S53=002 S54=003 S55=000 S56=017 S57=019 S58=002 S59=000 S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 S90=000 S91=000 S92=000 S95=000 S100=000 S101=000 S102=000 S104=000 S110=255 S111=030 S112=001 S121=000 What is happening is that when the RTSFLOW kicks in (in the "final" phase of getty init - when calling login), the port freezes completely. When it first answers the phone, the prompt comes up just fine. Doing 'stty -a </dev/tty2A' results in: speed 19200 baud; ispeed 14 baud; ospeed 14 baud; line = 0; intr = DEL; quit = ^\; erase = ^H; kill = ^U; eof = ^A; eol = ^@; swtch = ^@;susp = ^@; -parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -ctsflow -rtsflow -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc -ixon -ixany -ixoff -isig -icanon min = 1 time = 0 -xcase echo -echoe -echok -echonl -noflsh -iexten -tostop opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel This is when it is sitting at 'login:'. Note that CTSFLOW and RTSFLOW are still off. Now, when I type a userid, and hit enter, the 'Password:' prompt comes up, and it is frozen from there on. You can hit ENTER, etc., and *NO* data seems to be showing up on the modem. The stty settings in this state are: speed 19200 baud; ispeed 14 baud; ospeed 14 baud; line = 0; intr = DEL; quit = ^\; erase = #; kill = @; eof = ^D; eol = ^@; swtch = ^@;susp = ^@; -parenb -parodd cs8 -cstopb hupcl cread -clocal loblk ctsflow rtsflow -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon ixany -ixoff -isig icanon -xcase -echo -echoe -echok -echonl -noflsh -iexten -tostop opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel Notice that 'loblk' came on even though it was not specifically specified. It seems to be tied with RTSFLOW. Now, I was curious as to what was happening with the RTS signal from the computer, so I got one of those dinky Radio Shack RS-232 Mini Testers (you know that has the red and green lights for TD, RD, RTS, CTS, DSR, DTR, and CD). What is happening is very interesting. I don't know for sure, but it seems that when a light is OFF, there is no voltage, when it is GREEN, it is +5v and when it is RED it is -5v (mere interpolations). When the line is in the -rtsflow state, the RTS light is GREEN (I assume high). Now, when the RTSFLOW flag kicks in the "final" state, the RTS light always drops RED (low?) and that is when the port freezes. If RTS is not going high (GREEN), then that would explain why the modem will not transmit data to the computer. Why would RTS be staying low???? What other settings might be at work here? Help!? 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. I think I have covered the problem completely enough to give an appropriate picture. If not, please ask for more details! :-) This is driving me crazy! :-) The Telebit guy said, most of the time, the CTS handshake the modem does to have the computer wait is probably enough to work fine 99% time. But, I would like to get it working completely FULL duplex for 100% of the time. 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. Thanks in advance, Mark. -- Mark J. Bailey, N4XHX _______/====X11====\_______ USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 | JobSoft | VOICE: +1 615 893 0098 | Design & Development Co.| UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Murfreesboro, TN USA | DOMAIN: mjb@mjbtn.JOBSOFT.COM CIS: 76314,160 --------------------------- <KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>
steve@wattres.uucp (Steve Watt) (04/03/91)
In article <5176@mjbtn.JOBSOFT.COM> root@mjbtn.JOBSOFT.COM (Mark J. Bailey) writes: >Hello Netlanders, > >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 >a Telebit Trailblazer Plus modem. I am locking the baud rate from the serial [ he tries lots of things that look entirely reasonable ] My solution to this particular problem was the same as my solution to the poor throughput that you'll see once you get the line up: Find a serial card that you can replace the 16450s with 16550s (not strictly needed), and install the FAS (Final Async Solution, I think) that was posted to (I think) comp.unix.i386. It handles FULL flow control and FULL modem control, seems to be somewhat lower overhead than SCOs driver, and supports the 16550's 16 character FIFO to improve the throughput while reducing system load. I'm not sure if the FAS driver is available from UUNET, but I would not be surprised. I'll mail you a copy (release 2.07 patchlevel 0). In fact, if I'm behind, I'd appreciate someone mailing me a more current one. Have fun! -- Steve Watt steve@wattres.UUCP swatt@IBM.COM ...!decwrl!gigo!wattres!steve ...!apple!claris!wattres!steve Never trust a computer bigger than you can lift.
macleod@cmllab.rgb.sub.org (Connor MacLeod) (04/04/91)
Hi Mark (the original author of the article I'm replying to)
Hi Netlanders...
(For those who missed Marks article: he's got troubles when trying to
get SCO Unix 3.2.1 (ODT) driving his TBIT with RTS/CTS flow full duplex
at 19200 bd...)
I just had the same problem. It's just as the guy at Telebit said:
using the hardware handshake only in half duplex mode is ok for 99%
of all the data transmission. But...
I've got some dropouts when polling large files (it's the remaining 1%
I bet :>) and I decided to set up RTS and CTS flow. It didn't work at all.
<sigh>
I asked a few people around here and I was told to exchange the 16450
chips on my serial cards by 16550 ones. The NS16550A is able to run in
16 byte FIFO mode and this buffer stores the byte(s) in case the system
is on havy load and not able to get all the data from the modem in time.
The next step is to replace the original sio driver of the SCO Unix by
a public domain driver called FAS 2.08 (I can mail/post more information
about this driver if someone is interested in).
This driver is able to do the RTS/CTS flow in full duplex mode 100%!
Well. I haven't got the time to install the FAS driver so far but from
the moment on I replaced the 16450s all works fine (about a month now).
If anyone decides to replace his serial chips, too, make sure to get the
16550A! The 16550 chips have a hardware bug and the FAS driver will not
work with them...
I hope this is of some help :)
Rgds
--
Uwe Obst # {connor|macleod}@cmllab.rgb.sub.org
(aka Connor MacLeod) # "Trust me, I know what I'm doing!" -- Sledge Hammergemini@geminix.in-berlin.de (Uwe Doering) (04/05/91)
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
gemini@geminix.in-berlin.de (Uwe Doering) (04/05/91)
steve@wattres.uucp (Steve Watt) writes: > I'm not sure if the FAS driver is available from UUNET, but I would not >be surprised. I'll mail you a copy (release 2.07 patchlevel 0). In fact, >if I'm behind, I'd appreciate someone mailing me a more current one. Please don't use FAS 2.07 any more. It has some nasty problems (hanging ports). Get a fresh copy of FAS 2.08 PL0 from the net. Or if you can FTP, it's available on methan.chemie.fu-berlin.de (130.133.2.81) as `pub/unix/driver/fas/fas208pl0.zoo'. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini
dvv@hq.demos.su (Dmitry V. Volodin) (04/06/91)
SCO interprets RTS in good old half-duplex manner - RTS high means
"I want to transmit", not "I am ready to receive". Forget using
it with full-duplex modems. Or install FAS.
--
Dmitry V. Volodin <dvv@hq.demos.su> |
fax: +7 095 233 5016 | Call me Dima ('Dee-...)
phone: +7 095 231 2129 |