# UART Flow Control

I confused little bit regarding flow control. I have two devices, one is having UART flow control pins (RTS and CTS) named as Device 1 but other device don't have named as Device 2.

The device 1 which having UART flow control pin i configured as hardware flow control. So device 2 (which doesn't have flow control) need to send 1 (asserted) to before sending data, then it need to check the RTS pin of device 1 (device which having flow control) by device ( which doesn't have flow control). then it will send data.

Is my understanding is correct?

What is difference between CTS bar and CTS?

## 1 Answer

Flow control requires the cooperation of both ends. RTS means Request To Send and CTS is Clear To Send. Typically the RTS of one side is connected to the CTS of the other. So when a device has data to send to the other device, it waits until CTS is asserted before it begins transmitting. The device that is receiving would assert RTS when it's not busy with other tasks and when there is buffer space available (if it's a buffered implementation, which is common).

Note that in the typical case of a full duplex link, both sides can transmit at the same time, so each end would have both CTS and RTS lines.

So, in your particular case, Device 2 does not support hardware flow control, so you won't ever get flow control signals from that device. This means that for Device 1 to communicate with Device 2, it should either have hardware flow control turned off (check your UART data sheet) or should have the input signals (RTS in this case) hardwired to always allow sending.

Alternatively, if Device 2 is part of a microprocessor, you may be able to do your own hardware flow control using spare GPIO lines to serve the function of CTS and RTS.

CTS bar (commonly indicated as $\overline{\text{CTS}}$ or #CTS) would simply be an inverted version of CTS. Adding the bar or the # are two common ways of indicating the inverse of the usual logic sense, hence a $\text{RESET}$ line, which is often active low, is often shown as $\overline{\text{RESET}}$.

• The inversion of the signals customarily also goes with the difference between low voltage "logic level" signaling, and higher voltage RS232 specification signaling - one shouldn't use just any inverter (at least not by itself), but rather a level translator. In actual implementations, CTS/RTS pins many not be particularly "special" - often they are managed by software so any other GPIO pin could be used to provide that capability if needed. And often software can simply ignore them if the other end does not provide them. Aug 22, 2014 at 15:01
• So. According you I cannot use flow control?. Can't I drive Device 2 gpio pin as RTS and CTS pin? Aug 25, 2014 at 10:44
• @rock_buddy: You could indeed create your own RTS and CTS in firmware if device 2 is a microprocessor for which you are creating firmware. I've edited my answer to include that. Aug 25, 2014 at 11:46