Setting up RTS and CTS handshake lines

Please check the frequently asked questions before posting to the forum.
Post Reply
Author
Message
jdcowpland
Posts: 91
Joined: 10 Sep 2013 11:01

Setting up RTS and CTS handshake lines

#1 Post by jdcowpland » 03 Dec 2013 17:18

Does anyone know if there are any library functions that support RTS/CTS for the uarts? If not, is it easy enough to set up?

User avatar
filip
mikroElektronika team
Posts: 11874
Joined: 25 Jan 2008 09:56

Re: Setting up RTS and CTS handshake lines

#2 Post by filip » 04 Dec 2013 10:15

Hi,

The UART library implements only asynchronous communication, not synchronous.

Regards,
Filip.

jdcowpland
Posts: 91
Joined: 10 Sep 2013 11:01

Re: Setting up RTS and CTS handshake lines

#3 Post by jdcowpland » 04 Dec 2013 12:35

But synchronous refers to the clock, not handshake lines?

jpc
Posts: 1986
Joined: 22 Apr 2005 17:40
Location: France 87

Re: Setting up RTS and CTS handshake lines

#4 Post by jpc » 06 Dec 2013 08:34

as such it should be no problem to implement but you should perhaps tell more about the actual requirements.
What side is the PIC to be ? DTE or DCE ? or is it to be used in a symmetric way?
an extract from http://en.wikipedia.org/wiki/RS-232 tells us
RTS/CTS handshaking[edit]
Further information: Flow control (data)
In older versions of the specification, RS-232's use of the RTS and CTS lines is asymmetric: The DTE asserts RTS to indicate a desire to transmit to the DCE, and the DCE asserts CTS in response to grant permission. This allows for half-duplex modems that disable their transmitters when not required, and must transmit a synchronization preamble to the receiver when they are re-enabled. This scheme is also employed on present-day RS-232 to RS-485 converters, where the RS-232's RTS signal is used to ask the converter to take control of the RS-485 bus—a concept that does not otherwise exist in RS-232. There is no way for the DTE to indicate that it is unable to accept data from the DCE.
A non-standard symmetric alternative, commonly called "RTS/CTS handshaking," was developed by various equipment manufacturers. In this scheme, CTS is no longer a response to RTS; instead, CTS indicates permission from the DCE for the DTE to send data to the DCE, and RTS indicates permission from the DTE for the DCE to send data to the DTE. RTS and CTS are controlled by the DTE and DCE respectively, each independent of the other. This was eventually codified in version RS-232-E (actually TIA-232-E by that time) by defining a new signal, "RTR (Ready to Receive)," which is CCITT V.24 circuit 133. TIA-232-E and the corresponding international standards were updated to show that circuit 133, when implemented, shares the same pin as RTS (Request to Send), and that when 133 is in use, RTS is assumed by the DCE to be ON at all times.[12]
Thus, with this alternative usage, one can think of RTS asserted (positive voltage, logic 0) meaning that the DTE is indicating it is "ready to receive" from the DCE, rather than requesting permission from the DCE to send characters to the DCE.
Note that equipment using this protocol must be prepared to buffer some extra data, since a transmission may have begun just before the control line state change.
RTS/CTS handshaking is an example of hardware flow control. However, "hardware flow control" in the description of the options available on an RS-232-equipped device does not always mean RTS/CTS handshaking.
Au royaume des aveugles, les borgnes sont rois.

Post Reply

Return to “mikroPascal FAQ”