96

What's the difference between DTR/DSR and RTS/CTS hardware flow control? When is each one used? Why do we need more than one kind of hardware flow control? :)

Andy
  • 5,188
  • 10
  • 42
  • 59
Gili
  • 86,244
  • 97
  • 390
  • 689

3 Answers3

83
  • DTR - Data Terminal Ready
  • DSR - Data Set Ready
  • RTS - Request To Send
  • CTS - Clear To Send

There are multiple ways of doing things because there were never any protocols built into the standards. You use whatever ad-hoc "standard" your equipment implements.

Just based on the names, RTS/CTS would seem to be a natural fit. However, it's backwards from the needs that developed over time. These signals were created at a time when a terminal would batch-send a screen full of data, but the receiver might not be ready, thus the need for flow control. Later the problem would be reversed, as the terminal couldn't keep up with data coming from the host, but the RTS/CTS signals go the wrong direction - the interface isn't orthogonal, and there's no corresponding signals going the other way. Equipment makers adapted as best they could, including using the DTR and DSR signals.

EDIT

To add a bit more detail, its a two level hierarchy so "officially" both must happen for communication to take place. The behavior is defined in the original CCITT (now ITU-T) standard V.28.

enter image description here

The DCE is a modem connecting between the terminal and telephone network. In the telephone network was another piece of equipment which split off to the data network, eg. X.25.

The modem has three states: Powered off, Ready (Data Set Ready is true), and connected (Data Carrier Detect)

The terminal can't do anything until the modem is connected.

When the terminal wants to send data, it raises RTS and the modem grants the request with CTS. The modem lowers CTS when its internal buffer is full.

So nostalgic!

MV.
  • 947
  • 1
  • 11
  • 14
Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • 1
    Nicely summarized. Then 'soft' flow-control xOn/xOff came to be. – n8wrl Jun 05 '09 at 18:40
  • Note: DTR/DSR became less common than RTS/CTS after the mid 80's. Linux kernal never supported DTR/DSR: by the time the linux kernal supported DTR/DSR, 232 serial had become obsolete. – david Sep 17 '13 at 12:18
  • 11
    @david These signals are not restricted to RS232, but are used in TTL UARTs as well. And these are far from being obsolete. – glglgl Nov 29 '13 at 17:36
  • 2
    So in terms of the DTE (computer) and DCE (modem) RTS/CTS ensures the DCE (modem) is not overwhelmed with data and DTR/DSR ensures that the DTE (computer) is not overwhelmed with data. Is that correct? – skinnedknuckles Mar 12 '18 at 21:08
  • 1
    @skinnedKnuckles that's correct to the best of my memory. It's been too many years since I had to worry about this stuff. – Mark Ransom Mar 12 '18 at 22:56
33

The difference between them is that they use different pins. Seriously, that's it. The reason they both exist is that RTS/CTS wasn't supposed to ever be a flow control mechanism, originally; it was for half-duplex modems to coordinate who was sending and who was receiving. RTS and CTS got misused for flow control so often that it became standard.

chaos
  • 122,029
  • 33
  • 303
  • 309
  • 2
    I completely forgot about half duplex. I vaguely remember seeing that in action, on a combo line printer/card reader. Thanks for that answer. – Mark Ransom Jun 05 '09 at 18:47
  • Now superuser.com does exist, and it tells us that at the time of asking, the linux kernal did not support DTR/DSR signaling. http://superuser.com/questions/345005/how-to-do-hardware-dtr-dsr-flow-control-on-linux-serial-port-programming. Which points to another difference: DTR/DSR signalling is less common/was not used by smart-modems. – david Sep 17 '13 at 12:11
1

An important difference is that some UARTs (16550 notably) will stop receiving characters immediately if their host instructs them to set DSR to be inactive. In contrast, characters will still be received if CTS is inactive. I believe that the intention here is that DSR indicates that the device is no longer listening and so sending any further characters is pointless, while CTS indicates that a buffer is getting full; the latter allows for a certain amount of 'skid' where the flow control line changed state between the DTE sampling it and the next character being transmitted. In (relatively) later devices that support a hardware FIFO it's possible that a number of characters could be transmitted after the DCE has set CTS to be inactive.

Frog
  • 121
  • 2