>
>> My understanding of CRTSCTS is that the DCE device uses CTS to start
>and
>> stop the DTE device Tx to prevent buffer overrun. My DCE device won't
>> grant CTS if it can't receive but expects the DTE to drop RTS to signal
>> end of message.
Lawson wrote:
>I thought it only held RTS when it had something to send, so it should
>drop it when it's done sending, but ICBW. Also, it will do other things
>like block on DSR and DCD at open, which you might not want.
Perhaps 20 years ago this was the way RTS behaved. But it's now held on
by the DTE when the DTE is ready to receive. A transition to off signals
the DCE to stop sending (flow control). Then back to on signals the DCE
to resume sending. CTS is similar but protects the DCE. You can watch
these using the modemstat program. It has a color-coded display in a tiny
window and runs as a daemon. You might wan't to use this for monitoring
RTS althogh a voltmeter works also.
>> >> The symptoms on the Dell laptop are:
>> I successfully deassert RTS in initialization. I do this since RTS goes
>> high on open of the serial device. When I try to assert RTS nothing
>> happens. The application thinks all is ok and procedes to wait for
>CTS.
Are you sure that setserial shows the port correctly? Will the port work
OK normally without using your special program?
David Lawyer
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
