【背景】
之前就折腾过很多关于RTS/CTS,DTR/DSR的内容：
【整理】RTS/CTS，DTR/DSR的区别
【整理】RS232 RTS/CTS的流控制的具体过程/机制
【整理】HART协议中串口配置和Handshake（RTS/CTS等）
但是至今还是觉得，没有彻底明白，还有有一点点迷惑。
现在重新去整理相关知识。
【折腾过程】
1.参考：
What is the difference between DTR/DSR and RTS/CTS flow control?
先贴出缩写的含义：
- 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.参考：
RTS/CTS
中，又进一步了解到：
DTR/DSR，主要是用来做：
建立链接
即：
数据发送和接受之前，先要建立A和B的连接
这时候，才用到DTR/DSR
3.参考：
RS232 serial null modem cable wiring
目前来说：
还是没有完全明白作者解释的几种连线方式。
我们目前所常见的，遇到的，都是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
看了别的一些资料：
RS232串口通信基本接线方法
RS-232接线
也是各种接法都有。
目前还是不太确定如何接的。
4.其他一些参考资料：
RS232 Data Interface
Introduction to Serial Communications
The RS232 STANDARD
RS232 Specifications and standard
5.后来是看了：
RS232 Specifications and standard
后，又进一步的搞懂了一些内容：
之前的那套逻辑：
A设置RTS表示要发送数据给B，而B设置CTS表示可以接受数据，通知A发送数据给B，A就开始去真正的发送数据给B了
的背景是：
硬件连接是：
A的RTS<->B的RTS
A的CTS<->B的CTS
对应的
A一般是计算机PC
B一般是接在PC上的一个modem猫
对应的，A要发送数据给B的执行过程是：
- A设置A的RTS：表示要发数据给B；
- A检测A的CTS：
- 如果A的CTS是被设置了，那说明B设置了B的CTS
- 如果A的CTS没被设置，那说明B没有去设置B的CTS
- 说明B还出于busy忙的状态
- 等B忙清了，再去设置B的CTS
- 此时A才能检测到A的CTS，是被设置了，才能发送数据给B
而如果交叉连接：
A的RTS<->B的CTS
A的CTS<->B的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的RTS<->B的RTS
A的CTS<->B的CTS
的：
A想要发送数据给B之前：需要两个步骤：（1）去设置一次A的RTS，（2）并且通过检测A的CTS，去判断是否可以发送数据给B
变成了：
物理上RTS/CTS交叉连接：
A的RTS<->B的RTS
A的CTS<->B的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
转载请注明：在路上 » 【整理】串口(RS232/RS485等)通讯中RTS/CTS,DTR/DSR的含义详解
