Problems with Everex<->T2500 CTS handshaking

Ron Widell ron at motmpl.UUCP
Wed Jan 9 19:23:01 AEST 1991


Ralf Holighaus (ralfi at pemstgt.PEM-Stuttgart.de) writes:
> dag at 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?



More information about the Comp.unix.sysv386 mailing list