理解串口流控

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设置为无效，表示数据已经发送完了。

这就是整个单个的数据发送流程。



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

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

1.A说，我要过马路

就相当于A要将CTS设置有效，表示要发送数据（过马路到B那里去）

2.B根据自己情况，决定亮红灯不允许过，还是亮绿灯允许过（CTS有效）

B对于接下来将要接受的数据，要有一个准备的过程，这要花点时间，在这段时间内，肯定不会让你发送数据，也就是，亮红灯不允许你过马路，将CTS设置无效，表示我还没准备好，然后A那边呢就一直检测CTS是否有效，发现是无效，就知道现在B那边还没准备好，不允许我发送数据，然后过了会B准备好了，就把CTS设置为有效，表示准备好了，A可以发送数据给B了，即亮绿灯，让A过马路了，而A此时就检测到CTS是有效的了，就可以发送数据了，即看到绿灯，可以过马路了。

3.A要发送给B的每一个字节数据之前，都会看看是否是绿灯，如果是，继续发送数据，如果不是，就停止发送

接下来的，A要把一个个字节的数据（就相当于一个个要过马路的人），发送给B，在发送之前都要像前面一样，去检测CTS是否有效，如果有效，即绿灯，就可以继续发送数据，即过马路，如果CTS无效，说明B出啥问题了，比如缓存满了，要处理一下，接着再让你发送数据，即亮红灯，A不能继续过马路了。然后A就一直检测CTS直到CTS有效，再发送数据，即A一直看灯，直到红灯变绿，再继续过马路。

4.在CTS一直有效的情况下，A发送数据完成后，把RTS设置为无效

所有的A都过完马路了，就把原先设置的标示RTS设置为无效，表示数据发送完成了。



看着上面解释的一大堆，其实只看标题，就是很简单的逻辑：

A要发送数据，即Request To Send “请求发送”（数据），B看到RTS有效了，决定，如果自己要做准备工作，就设置CTS无效，如果本身准备好了，就设置CTS，Clear To Send，表示对于你的Send发送（数据）来说，我已经Clear（忙清了）。所以A看到CTS有效就可以发送数据了。然后接下来的每一个从A发送到B的字节数据都是这么个过程。中间有可能遇到说，B的buffer full 缓存满了，所以要设置CTS无效，A发现后，就停止发送数据，继续检测CTS直到有效，才继续发送数据。正常数据发送完成后，A就把最开始设置为有效的RTS这个标示清除掉，即设置RTS无效，表示数据传完了。 由此，整个A发送数据到B的过程就完成了。