dag@esleng.uucp (David A. Gilmour) (12/19/90)
I have just established a UUCP node and I've been having some problems with the CTS handshaking between my modem and my computer. I'm using an Everex Step 386/33 running Interactive Unix System V, R3.2. The modem is a Telebit T2500. The serial card in the machine is the Everex EV-170. Communication between the modem and the computer is working with the exception that I have not been able to get the CTS signal from the modem to cause the computer to "shut up" when the modem's buffers are about to overflow. The CTS signal from my modem (T2500), when asserted, is completely ignored by the computer. My documentation seems to indicate that if I use the proper tty device I will automatically get the required handshaking. I'm using /dev/ttyd0 for my uugetty, which I think should support modem controls. I've also tried /dev/acu0; no joy. The cable's been buzzed out and I have determined that the CTS signal is in fact reaching the UART on the serial card. If anyone has had similar problems and can provide any help/direction, it would be much appreciated. Thanks. -- __________________________________________________________________________ David A. Gilmour | dag%esleng.uucp%micor.uucp@ccs.carleton.ca Excalibur Systems Limited | uunet!mitel!cunews!micor!esleng!dag Kanata, Ontario, Canada |
cec@cup.portal.com (Cerafin E Castillo) (12/21/90)
I have seen this behaviour in relation to UART failures at above 9600 bps.
I would suggest that you lower your port speed to 9600 bps and test again.
I would also suspect the device drivers in your ISC UNIX. Call ISC and
ask about this situation with the O/S, then call Everex and ask them about
their RTS/CTS flow control implementation. I would also test using a
PC or UNIX system hooked-up with a null modem cable. Run UUCP or Kermit
over this connection starting at 9600 bps and going up to 19.2 kbps to
see if a similar failure doesn't occur. An RS-232 Protocol analyzer would
help with this kind of testing. I suspect that the failure will be your
Everex multiport board and its drivers. Oh, I forgot the obvious, if there
are any motherboard COMM ports (ie COMM1 / COMM2) attach the modem to
those ports and try your UUCP transfer as you are doing so now, on your
multiport board. You might just see better RTS/CTS handling at 9600 and
19200 bps on COMM1/COMM2. If not, then I would suspect the O/S and its
drivers.
Good Luck!
===============================================================================
Cerafin E. Castillo || //\\ ||\\ ||
Network Consultant || //__\\ || \\ || Los Altos
Los Altos Networks || // ---\\|| \\|| Networks
340 Second St. #6 ||___// \ | \ |
Los Altos, CA 94022
(415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec
INTERNET: cec@cup.portal.com
"...No hay mal que por bien no venga..."
===============================================================================ron@motmpl.UUCP (Ron Widell) (01/09/91)
Ralf Holighaus (ralfi@pemstgt.PEM-Stuttgart.de) writes: > dag@esleng.uucp (David A. Gilmour) writes: > > > [...] > > [A description of difficulties getting RTS/CTS to work on a PC clone ] > > Try to use the correct getty settings, i. e. verify that IXON is set in the > correct field of /etc/gettydefs. While {IXON,IXANY} and IXOFF ordinarily refer to in-band control characters (ctl-Q,any and ctl-S, respectively), this may still be your best alternative. I would be suspicious of a buggy device driver. Since most (by device type) UARTs implement CTS in hardware (when the line is negated the transmitter stops) most unix device drivers ignore the signal and just look to see if the Tx buffer is empty prior to shipping out the next character. Unfortunately, this won't work if the UART is functionally identical to the 8250 (read- every PC clone I know of) because they *DO NOT* disable the transmitter when the CTS line is negated. Instead, the driver has to monitor the status bit to ensure that it's OK to send another character. What I would do is: 1) Boot the system up in {PC,MS}-DOS and use DEBUG to see if the appropriate bit in the status register toggles as I change the state of the CTS line. 2) Iff item 1 verifies my suspicions that the UART is functioning normally, notify the vendor of the buggy device driver and request a fixed version. 3) Use XON/XOFF flow control until the vendor can supply a driver that works with hardware flow control. Regards, -- Ron Widell, Field Applications Eng. |UUCP: {...}mcdchg!motmpl!ron Motorola Semiconductor Products, Inc., |Voice:(612)941-6800 9600 W. 76th St., Suite G | I'm from Silicon Tundra, Eden Prairie, Mn. 55344 -3718 | what could I know?