DTR/DSR 和 RTS/CTS 流量控制有什么区别？
DTR/DSR 和 RTS/CTS 硬件流控制有什么区别？ 每一个什么时候使用？ 为什么我们需要不止一种硬件流控制？ :)
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? :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
执行操作的方法有多种，因为标准中从未内置任何协议。 您可以使用您的设备实施的任何临时“标准”。
仅从名称来看，RTS/CTS 似乎是天生的组合。 然而，它与随着时间的推移而发展的需求背道而驰。 这些信号是在终端批量发送满屏数据时创建的，但接收器可能尚未准备好，因此需要流量控制。 后来问题会逆转，因为终端无法跟上来自主机的数据，但 RTS/CTS 信号走错方向 - 接口不是正交的，并且没有相应的信号走相反的路。 设备制造商尽最大努力进行调整，包括使用 DTR 和 DSR 信号。
编辑
要添加更多细节，它是一个两级层次结构，因此“正式”两者都必须发生才能进行通信。 该行为在原始 CCITT（现为 ITU-T）标准 V.28 中定义。
DCE 是连接终端和电话网络之间的调制解调器。 在电话网络中有另一台设备分离到数据网络，例如。 X.25。
调制解调器具有三种状态：关闭、就绪（数据集就绪为真）和已连接（数据载波检测）。
在调制解调器启动之前，终端无法执行任何操作。连接的。
当终端想要发送数据时，它会提高 RTS，调制解调器会通过 CTS 批准该请求。 当调制解调器的内部缓冲区已满时，调制解调器会降低 CTS。
太怀旧了！
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.
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!
它们之间的区别在于它们使用不同的引脚。 说真的，就是这样。 它们同时存在的原因是 RTS/CTS 最初不应该是一种流量控制机制； 它是由半双工调制解调器协调谁发送和谁接收的。 RTS 和 CTS 经常被误用于流量控制，以至于它成为标准。
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.
一个重要的区别是，如果主机指示某些 UART（特别是 16550）将 DSR 设置为非活动状态，它们将立即停止接收字符。 相反，如果 CTS 处于非活动状态，仍然会收到字符。 我相信这里的意图是 DSR 表明设备不再侦听，因此发送任何进一步的字符是没有意义的，而 CTS 表明缓冲区已满； 后者允许一定量的“滑动”，其中流量控制线在 DTE 对其进行采样和传输下一个字符之间改变状态。 在（相对）较新的支持硬件 FIFO 的设备中，在 DCE 将 CTS 设置为非活动状态后，可能会传输多个字符。
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.