🚀 go-pugleaf

Yes, RTS and CTS are for real, but they appear to be relevant to the two
parties that are communicating across the serial RS-232 line.  That is, the
receiving party announces its willingness to receive by making RTS true; the
sending party sees this at its CTS pin, by direct wire.   The RTS pin on the
connector of one party is connected directly to the CTS pin on the other
party's connector...that's the way I remember it.  It's been a long time, so
I could be wrong.
Nevertheless, this handshake protocol should be bilateral, as the same rule
applies when data needs to pass in the opposite direction.  True RTS
outbound from the willing data receiver is seen as true CTS inbound at the
data transmitting party.
A null modem is needed to perform the criss-cross in the cable, if both
parties are "DCE" or "DTE"; this gets RD connected to TD on the other
connector; CTS connected to RTS on the other connector.

If anyone can correct me on this, please feel free to do so.

But...
My problem is not RTS and CTS related, because I don't have a handshake need
over the serial cable.  I need a handshake on the other side of the COM
port.  That is, within one computer, between the COM port and the CPU.  I'm
getting some kind of under-run on the COM port, from excessive reads by the
CPU of the COM port.  I need some way of telling the CPU to wait and not
read the COM port UNTIL fresh data arrives at that port.


<disharp@swbell.net> wrote in message
news:3b4fb144.36256305@news.swbell.net...
>
> Hello John,
>  It has been a long time since I was into RS232C protocol. As I
> remember the transmitting side brings up a line called RTS(REQUEST TO
> SEND) and   the recieving brings up a CTS(Clear to send) line. These
> signals were used by the modems.  As how to implament these  signals
> I will leave to you.
>  Best,
>  Richard
>
>