网上的资料,顺便科普下:
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设置为了无效),那么就不能发生数据了。
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的过程就Over了。