Searching \ for 'RTS, CTS etc.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=rts+cts+etc
Search entire site for: 'RTS, CTS etc.'.

Truncated match.
PICList Thread
'RTS, CTS etc.'
1997\03\10@002836 by Ed Todd

picon face
Our PIC talks to a PC, and is therefore DCE.

For the PC to talk to the PIC, it raises RTS.  The PIC raises CTS to accept
data, drops CTS when done.  There are some limitations in this area:

- some PC OS's leave RTS high even when there is no data.  You can get
locked unless you raise CTS with a timeout.
- when the PIC drops CTS, communication of several bytes can occur: depends
on the card, I suppose.  A cached UART seems to send contents of cache
after CTS dropped, at least on cards I used.  You either need to cache on
the PIC or manage the queue and flow control carefully with the PC
application.

For the PIC to talk to the PC, the PIC raises DSR and waits for the PC to
raise DTR.  Watch for DTR dropping on each byte boundary: cache full, queue
full, application messed up pulling in data, whatever.  Drop DSR when done
sending.  Again, a timeout on waiting for DTR is advisable: the plug could
come loose, PC crash, etc.

What if no PC, PIC to PIC communications?  Really, one PIC needs to be the
PC, one the modem.  That means two lots of PIC code, one with RTS in, the
other with RTS out, rather complex.  The simplest way to do this is to
ignore all that, have both PICs pretend they are talking to a PC (RTS in,
CTS out, etc) and cross wires between PICs as in a standard NULL modem,
described in most basic COMMS books.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...