David Lawyer wrote:
>
> >
> >> 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.
I use a breakout box but I am interested in modemstat. Where/How can I
get a copy?
>
> >> >> 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?
setserial lists the uart, port, irq as expected but I haven't tried the
port with anything else. My application has a test mode that ignores
modem control and it passes data just fine in that mode.
Thanks,
john
--
------------------------------------------------------------------------
John Florence, Mathematician, VSS Group, 25-162 Phone: 240-228-6685
JHU/APL, Johns Hopkins Road, Laurel, MD 20723 FAX: 240-228-6663
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
