【背景】

之前就折腾过很多关于RTS/CTS,DTR/DSR的内容：

但是至今还是觉得，没有彻底明白，还有有一点点迷惑。

现在重新去整理相关知识。

【折腾过程】

1.参考：

先贴出缩写的含义：DTR – Data Terminal Ready

DSR – Data Set Ready

RTS – Request To Send

CTS – Clear To Send

对应的相关的其他术语还有：DCE：Data Communication Equipment，可以理解为：数据的发起发

DTE：Data Terminal Equipment，可以理解为：数据的接收方

然后了解到：

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.

RTS/CTS和DTR/DSR，是用的物理引脚是不同的；

而关于DTR/DSR和RTS/CTS共存(没有统一只使用单个的一组硬件引脚(要么用RTS/CTS，要么用DTR/DSR)去实现流控制)的原因是：

背景是：

最开始先出现的RTS/CTS，但是设计出RTS/CTS的初衷，即原先的目的，就不是把RTS/CTS去用来当做流控制的

-> 而是用来：去协调两个半双工(工作模式下的)的猫modem之间的通讯

-> 不至于让两个半双工的modem，在通讯时，互相掐架，互相抢占数据通道，互相同时要么都要发送数据，要么都要接受数据，由此而容易导致混乱和(总线上的)数据异常

-> 但是结果，(被设计用于协调两个两个半双工的modem之间的通讯的)RTS/CTS，结果被大家误用，误当做(后来大量出现和使用的，全双工的串口等设备中的)流控制

-> 即，对于都是全双工的两个串口来说：

计算机(上面的串口) (开发板或其他设备上面的)串口

分别对应着的概念是：

DCE DTE

此处，分别叫做：

数据发送方 数据接收方

此处，暂且叫做：

串口A 串口B

此时就是：

A打算发送数据到B中

A设置RTS(Request To Send)，表示：请求发送(数据到对方)

此时：正常情况下，数据接收方，B不忙的时候，即不是busy的状态，则：B去设置对应的CTS(Clear To Send)：

两种理解，不确定是哪种：清除(发送者A之前的设置的RTS)，表示可以接受数据了

Clear表示OK，清楚，明白，意思是明白对方的意思了，表示对方可以发送数据了

-> 发送者A，就可以直接去发送数据给B了，B也就可以去接受数据，处理收到的数据了；

偶尔特殊的时候，处于忙的状态，即busy，比如忙着处理上次发送的数据呢，所以没空理会你这次还要发的数据：那么此时就是：不去设置对应的CTS，表示自己忙，来不及处理你将要发送的数据

-> 数据发送者A，见状，就继续检测CTS，直到(数据接受者B，忙清了自己手上的活，有空接受数据了，然后)CTS被接受者B去设置对应的CTS，表示可以接受数据了，然后A才去发送数据给B

2.参考：

中，又进一步了解到：

DTR/DSR，主要是用来做：

建立链接

即：

数据发送和接受之前，先要建立A和B的连接

这时候，才用到DTR/DSR

3.参考：

目前来说：

还是没有完全明白作者解释的几种连线方式。

我们目前所常见的，遇到的，都是DB9的两个端口，直接相接。

感觉应该是：

Null modem with partial handshaking

即：

A的RTS，CTS，分别接B的CTS，RTS

A的Tx，Rx，分别接B的Rx和Tx

但是，感觉，普通的DB9直接接DB9的话，应该是：

A的RTS，CTS，分别接B的RTS，CTS

A的Tx，Rx，分别接B的Rx和Tx

看了别的一些资料：

也是各种接法都有。

目前还是不太确定如何接的。

4.其他一些参考资料：

5.后来是看了：

后，又进一步的搞懂了一些内容：

之前的那套逻辑：

A设置RTS表示要发送数据给B，而B设置CTS表示可以接受数据，通知A发送数据给B，A就开始去真正的发送数据给B了

的背景是：

硬件连接是：

A的RTSB的RTS

A的CTSB的CTS

对应的

A一般是计算机PC

B一般是接在PC上的一个modem猫

对应的，A要发送数据给B的执行过程是：A设置A的RTS：表示要发数据给B；

A检测A的CTS：如果A的CTS是被设置了，那说明B设置了B的CTS表示B可以接受数据了A就去发送数据给B了

如果A的CTS没被设置，那说明B没有去设置B的CTS说明B还出于busy忙的状态等B忙清了，再去设置B的CTS此时A才能检测到A的CTS，是被设置了，才能发送数据给B

而如果交叉连接：

A的RTSB的CTS

A的CTSB的RTS

则就变成了其所说的：

非猫连接(null modem connection)(模式)

此时：

A的RTS，就不是：A用来通知B，A要发送数据(给B)了

就变成了：

A用于指示(告诉)B，A是否可以接受数据

即：

A的RTS，由于连着B的CTS，所以如果A直接检测到A被设置了

那么说明B已经设置了B的CTS(就传到了对应的A的RTS)，此时A就可以直接通过检测A的RTS，而判断出B是否可以接受数据

所以就是从：

物理上RTS/CTS直连：

A的RTSB的RTS

A的CTSB的CTS

的：

A想要发送数据给B之前：需要两个步骤：(1)去设置一次A的RTS，(2)并且通过检测A的CTS，去判断是否可以发送数据给B

变成了：

物理上RTS/CTS交叉连接：

A的RTSB的RTS

A的CTSB的CTS

的：

A想要发送数据给B之前：直接一个步骤就实现了：(1)直接检测A自己的RTS，即B的CTS，是否被设置，如果被设置了，直接发送数据

由此：

简化了数据发送前的执行步骤，提高了数据传输的效率

当然，当：

物理上RTS/CTS交叉连接

时，对应的软件的流控制协议，也要根据上述的逻辑，去做对应的改动；

【总结】

1.RTS/CTS之间协调工作，实现流控制的逻辑，目前的理解是：对于都是全双工的两个串口来说：

计算机(上面的串口) (开发板或其他设备上面的)串口

分别对应着的概念是：

DCE DTE

此处，分别叫做：

数据发送方 数据接收方

此处，暂且叫做：

串口A 串口B

此时就是：

A打算发送数据到B中

A设置RTS(Request To Send)，表示：请求发送(数据到对方)

此时：正常情况下，数据接收方，B不忙的时候，即不是busy的状态，则：B去设置对应的CTS(Clear To Send)：

两种理解，不确定是哪种：清除(发送者A之前的设置的RTS)，表示可以接受数据了

Clear表示OK，清楚，明白，意思是明白对方的意思了，表示对方可以发送数据了

-> 发送者A，就可以直接去发送数据给B了，B也就可以去接受数据，处理收到的数据了；

偶尔特殊的时候，处于忙的状态，即busy，比如忙着处理上次发送的数据呢，所以没空理会你这次还要发的数据：那么此时就是：不去设置对应的CTS，表示自己忙，来不及处理你将要发送的数据

-> 数据发送者A，见状，就继续检测CTS，直到(数据接受者B，忙清了自己手上的活，有空接受数据了，然后)CTS被接受者B去设置对应的CTS，表示可以接受数据了，然后A才去发送数据给B

2.但是对于目前常见的，直接两个DB9的串口直接相连，物理上对应的引脚的接法：

估计是：A的RTS，CTS，分别接B的RTS，CTS

A的Tx，Rx，分别接B的Rx和Tx

3.目前对于DTR/DSR的理解：

主要是用来做：建立链接

即：

数据发送和接受之前，先要建立A和B的连接

这时候，才用到DTR/DSR