先列出关于流控制协议的一些名词：

于此相关的其他一些名词：

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），表示：请求发送（数据到对方）

此时：

DTR/DSR，主要是用来做建立链接

即，数据发送和接受之前，先要建立A和B的连接，这时候才用到DTR/DSR

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

的背景是：

硬件连接是：

对应的：

对应的，A要发送数据给B的执行过程是：

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

目前对于DTR/DSR的理解：

数据发送和接受之前，先要建立A和B的连接。这时候才用到，用于建立链接的，DTR/DSR

RTS/CTS的流控制过程如下：

如果A和B，（其中A是Imager，要发送图像数据，B是对应的接受设备），A想要发送数据给B，那么用硬件的RTS/CTS作为硬件流控制机制的话，

A如果想要发送数据给B的话，A会使得RTS(Request To Send)引脚有效，表明其想要“请求发送”数据给作为接收设备的B，

然后A接着就会去检测对应的来自B的CTS引脚，直到CTS有效（此时意味着B已经做 好了相关的准备工作了，然后设置了CTS(Clear To Send) ，表明自己准备好接受数据了)，才会真正开始发送数据。

并且在接下来发送每个字符（data character）之前，都会去检测对应的CTS是否有效

如果有效，才会继续传输对应的数据，

如果发现CTS无效（此时意味着B那么发生了啥情况，导 致无法继续正常接受数据了，所以将CTS设置为了无效），那么就不能再继续发送数据。

对于上述CTS一直有效的情况下，A就一直发送数据给B，到了最后数据发送完之后，再把RTS设置为无效，表示数据已经发送完了。

这就是整个单个的数据发送流程，用RTS和CTS来控制传输的逻辑。

对此流程，做个简单的比喻，未必很恰当，但是可以很形象的说明数据发送的流程：

A和B，相当于马路的两边，A要发送数据给B，就相当于A要过马路，具体的流程就是：

可以将上面一大堆繁琐的解释，总结为简单的逻辑：