RTS与CTS的含义

====================================我是分割线首先介绍下网上看到的========================================================================================

一、RS232标准中的RTS与CTS

RTS,CTS------请求发送/清除发送，用于半双工时的收发切换，属于辅助流控信号。半双工的意思是说，发的时候不收，收的时候不发。那么怎么区分收发呢？缺省时是DCE向DTE发送数据，当DTE决定向DCE发数据时，先有效RTS，表示DTE希望向DCE发送。一般DCE不能马上转换收发状态，DTE就通过监测CTS是否有效来判断可否发送，这样避免了DTE在DCE未准备好时发送所导致的数据丢失。

二、MODEM硬件流控中的RTS与CTS

按照SIMCOM公司的解释，RTS和CTS是独立,

1.RTS是模块的输入端，用于MCU通知模块，MCU是否准备好，模块是否可向MCU发送信息，RTS的有效电平为低。 
2.CTS是模块的输出端，用于模块通知MCU，模块是否准备好，MCU是否可向模块发送信息，CTS的有效电平为低 
从文字看，RTS和CTS是独立的，不存在每次单向数据传输的发起者问题。如果主机输出RTS有效，那么模块有数据就会发往主机；如果模块输出CTS有效，那么主机就可以将数据送达模块接收。 
三、通信协议中的RTS与CTS

RTS/CTS协议即请求发送/允许发送协议，相当于一种握手协议，主要用来解决"隐藏终端"问题。"隐藏终端"（Hidden Stations）是指，基站A向基站B发送信息，基站C未侦测到A也向B发送，故A和C同时将信号发送至B，引起信号冲突，最终导致发送至B的信号都丢失了。"隐藏终端"多发生在大型单元中（一般在室外环境），这将带来效率损失，并且需要错误恢复机制。当需要传送大容量文件时，尤其需要杜绝"隐藏终端"现象的发生。IEEE802.11提供了如下解决方案。在参数配置中，若使用RTS/CTS协议，同时设置传送上限字节数----一旦待传送的数据大于此上限值时，即启动RTS/CTS握手协议：首先，A向B发送RTS信号，表明A要向B发送若干数据，B收到RTS后，向所有基站发出CTS信号，表明已准备就绪，A可以发送，其余基站暂时"按兵不动"，然后，A向B发送数据，最后，B接收完数据后，即向所有基站广播ACK确认帧，这样，所有基站又重新可以平等侦听、竞争信道了。

附：UART串口历史

很久很久以前，计算机还没有出现，那时就已经存在了(计算机)史前的串口设备(电传打字机，工控测量设备，通信调制解调器)，为了连接这些串口，EIA制定了RS232标准，采用DB25接插件，支持同步和异步串口，D型的接口可以有效防止插反。标准化给使用带来了便利。 
时光荏苒，个人计算机出现了，这些已有的串口设备毫无疑问地成为了最初的外设，自然而然地RS232标准被个人计算机采纳。但是设备制造商倾向于体积更小，成本更低的接口，因此，将DB25中未使用的和支持同步模式的引脚去掉，形成DB9。最初的情况相当混乱，因为DB9只定义了信号，却没有指定信号和引脚的对应关系，各个制造商只能自行定义。幸运的是，IBM的PC成了工业标准，DB9逐渐统一到IBM的定义上来。 
    DB9只有9根线，遵循RS232标准。定义如下： 
    DTR,DSR------DTE设备准备好/DCE设备准备好。主流控信号。 
RTS,CTS------请求发送/清除发送。用于半双工时，收发切换。属于辅助流控信号。半双工的意思是说，发的时候不收，收的时候不发。那么怎么区分收发呢？缺省时是DCE向DTE发送数据，当DTE决定向DCE发数据时，先有效RTS，表示DTE希望向DCE发送，一般DCE不能马上转换收发状态，DTE就通过监测CTS是否有效来判断可否发送，这样避免了DTE在DCE未准备好时发送所导致的数据丢失。全双工时，这两个信号一直有效即可。 
随着计算机的日益普及，很多非RS232的串口也要接入PC机，如果为每一种新出现的串口都增加一个新的I/O口显然不现实，因为PC后面板位置有限，因此，将RS232串口和非RS232串口都通过RS232口接入是最佳方案。UART的U(通用)指的就是这个意思。早期ROM BIOS和DOS里的通信软件都是为RS232设计的，在没有检测到DCD有效前不会发送数据，因此，就连发送一个字符这样朴素的应用也要给出DCD、DTR、DSR等控制信号。因此，串口接头上要将一些控制线短接，或者干脆绕过系统软件自己写通信程序。 
到此，UART的涵义就总结为：通用的 异步 (串行) I/O口。 
就在UART冠以通用二字，准备一统江湖的时候，制造商们不满于它的速度、体积和灵活性(软件可配置)，推出了USB和1394串口。目前，笔记本上的UART串口有被取消的趋势，因而有网友发出了“没有串口，吾谁与归”的慨叹，古今多少事，都付笑谈中，USB取代UART是后话，暂且不表。 
话说自从贺氏(Hayes)公司推出了聪明猫(SmartModem)，他们制定的MODEM接口就成了业界标准，自此以后，所有公司制造的兼容猫都符合贺氏标准(连AT指令也兼容)。 
细观贺氏制定的MODEM串口，与RS232标准大不相同。DTR在整个通信过程中一直保持有效，DSR在MODEM上电后/可以拨号前有效(取决于软件对DSR的理解)，在通信过程的任意时刻，只要DTR/DSR无效，通信过程立即终止。在某种意义上，这也可以算是流控，但肯定不是RS232所指的那种主流控。如果拘泥于RS232，你是不会理解DTR和DSR的用途的。 
贺氏不但改了DTR和DSR，竟然连RTS和CTS的涵义也重新定义了。因此，RTS和CTS已经不具有最开始的意义了。从字面理解RTS和CTS，是用于半双工通信的，当DTE想从收模式改为发模式时，就有效RTS请求发送，DCE收到RTS请求后不能立即完成转换，需要一段时间，然后有效CTS通知DTE：DCE已经转到发模式，DTE可以开始发送了。在全双工时，RTS和CTS都缺省置为有效即可。然而，在贺氏的MODEM串口定义中，RTS和CTS用于硬件流控，和什么全双工/半双工一点关系也没有。 注意，硬件流控是靠软件实现的，之所以强调“硬件”二字，仅仅是因为硬件流控提供了用于流量情况指示的硬件连线，并不是说，你只要把线连上，硬件就能自己流控。如果软件不支持，光连上RTS和CTS是没有用的。 
RTS和CTS硬件流控的软件算法如下：(RTS有效表示PC机可以收，CTS有效表示MODEM可以收，这两个信号互相独立，分别指示一个方向的流量情况。) 
    PC端处理： 
　　   发.　　  当发现（不一定及时发现） CTS (-3v to -15v)无效时，停止发送, 
　　　　　　   当发现（不一定及时发现） CTS (3v to 15v)有效时，恢复发送； 
　　   收. 　　 当接收buffers中的bytes当接收buffers中的bytes>N 时，给 RTS 无效信号（-3v to -15v); 
    MODEM端处理： 
同上，但RTS与CTS交换。

在RS232中本来CTS 与RTS 有明确的意义，但自从贺氏(HAYES) 推出了聪明猫(SmartModem)后就有点混淆了。在RS232中RTS 与CTS 是用来半双工模式下的方向切换；HAYES Modem中的RTS ，CTS 是用来进 行硬件流控的。通常UART的RTC、CTS 的含义指后者，即用来做硬流控的。

硬流控的RTS 、CTS ：RTS （Require To Send，发送请求）为输出信号，用于指示本设备准备好可接收；CTS（Clear To Send，发送清除）为输入信号，有效时停止发送。假定A、B两设备通信，A设备的RTS 连接B设备的CTS ；A设备的CTS 连接B设备 的RTS 。 前一路信号控制B设备的发送，后一路信号控制A设备的发送。对B设备的发送（A设备接收）来说，如果A设备接收缓冲快满的时发出RTS 信号（意思 通知B设备停止发送），B设备通过CTS 检测到该信号，停止发送；一段时间后A设备接收缓冲有了空余，发出RTS 信号，指示B设备开始发送数据。A设备发（B设备接收） 类似。上述功能也能在数据流中插入Xoff（特殊字符）和Xon（另一个特殊字符）信号来实现。A设备一旦接收到B设备发送过来的Xoff，立刻停止发 送；反之，如接收到B设备发送过来的Xon，则恢复发送数据给B设备。同理，B设备也类似，从而实现收发双方的速度匹配。

半双工的方向切换：RS232中使用DTR（Date Terminal Ready，数据终端准备）与DSR（Data Set Ready ，数据设备准备好）进行主流控，类似上述的RTS 与CTS 。对半双工的通信的DTE（Date Terminal Equipment，数据终端设备）与DCE（Data circuit Equipment ）来说，默认的方向是DTE接收，DCE发送。如果DTE要发送数据，必须发出RTS 信号，请求发送数据。DCE收到后如果 空闲则发出CTS 回 应RTS 信 号，表示响应请求，这样通信方向就变为DTE->TCE，同时RTS 与CTS 信号必须一直保持。从这里可以看出，CTS ，TRS虽 然也有点流控的意思（如CTS 没有发出，DTE也不能发送数据），但主要是用来进行方向切换的。

如果UART只有RX、TX两个信号，要流控的话只能是软流控；如果有RX，TX，CTS ，RTS 四个信号，则多半是支持硬流控的UART；如果有 RX，TX，CTS ，RTS ，DTR，DSR 六个信号的话，RS232标准的可能性比较大。

顺便提一下：

DCD（ Data Carrier Detect， 数据载波检测）：DCE向DTE指示，线路上检测到载波。

RI（Ring Indicator，振铃指示）：DCE向DTE指示，有呼叫接入。

====================================我是分割线=====================================================================================================

　　这两天基于STM32的串口做了测试。之前一直用的时候根本没有往串口协议上靠，只是能用起来解决了问题就匆匆完事。直到最近看《深入理解计算机网络》这本网络基础书，里面讲232协议以及485协议时，忽然想拿板子测试下。上面提到的CTS/RTS流控方面的应用是我之前使用串口时没有注意到的。之前在用USART做串口编程时，一般都是设备作为从机来使用，包括一些教程也都是从这样的应用来讲解。大部分的教程都是在将单片机Usart同上位机超级终端之间通过232协议转换模块进行通信。最最常见的用法就是使用串口中断进行流控(当然这种做法是推荐的，因为232的CTS/RTS不是干这个用的，本文只是那上位机的232这么测试一下。。。)

　　前几天看书看到232的时候，我忽然想到是不是可以用RTS/CTS来代替中断实现上位机的交互。上位机的超级终端或者串口小助手，在接收的数据的时候，可以游刃有余，因为stm32函数库里面，usart的发送数据是通过串口打印冲定义实现的，将fputs（）函数进行了修改，最终使用printf函数进行输出。这种方法其实是通过函数fputs（）本身进行了缓存操作，使得USART_SendData函数能一位位的将数据发出。也就是说，即是不用发送中断，我们依然能够井然有序的通过stm32的Usart的TX端口将数据发出。如下代码是stm32函数库中串口打印冲定义函数，注意是USART1。

 #ifdef __GNUC__
 /* With GCC/RAISONANCE, small printf (option LD Linker->Libraries->Small printf
      set to 'Yes') calls __io_putchar() */
 #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
 #else
 #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
 #endif /* __GNUC__ */

 PUTCHAR_PROTOTYPE
 {
     /* Place your implementation of fputc here */
     /* e.g. write a character to the USART */
     USART_SendData(USART1,(u8)ch);

     /* Loop until the end of transmission */
     while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);

     return ch;
 }

　　但是，如果我们不使用中断，而从上位机超级终端向stm32发送数据的话，你会发现，单片机只能收到你发的字符串的首个字符。其它的字符全部丢失。这就是没有做流控的结果。比如下面：

 int main(void)
 {
     u32 i=0xffffff;
     SystemInit();
     usart_Configuration();
     //NVIC_Configuration();
       while()
     {
         printf("Waveshare!\r\n");
         while(--i);
         i=0xffffff;
         printf("%c",USART_ReceiveData(USART1));
       }
 }

　　但是如果我们使用中断，或者是使用RTS/RTS做流控则不会发生这种现象。从机理上讲，上面是发生了接收溢出错误。串口状态寄存器的ORE位由于在RENE=1的情况（也就是第一个字符已经被写满数据寄存器DR）下接收到了数据，造成了数据溢出，此时SR.ORE位会置1.这点参考硬件手册，而且读取DR数据寄存器的话，仅会清除RXNE位，而不会清空数据寄存器DR。所以一直会输出S。但是如果我们发送再次发送一个字符，比如ASDF。则会发现输出字符变成了AWaveshare！道理跟之前一样，因为我们已经通过调用USART_ReceiveData()清空了RXNE，所以第一个字符A还是能读进去的，只不过当第二字字符S时又发生了前面的事情。所以，在做通信的时候必须做流控。

　　使用中断做流控我们就不说了，很多。这里说一下CTS/RTS。其实这个比中断简单，因为中断我们还得配置，而且中断可以写中断服务函数，所以应用广。毕竟CTS/RTS其实是用来做流控或者半双工通信的，具体的含义不一样，这里只讲232的。以RTS为例，其含义如下：

　　也就是说，Tx管脚接收到1个字符（默认8bit通信），硬件上RTS会产生一个置位，使得接收数据标志位RXNE=1.所以只要在软件里我们判断RXNE的状态，就可以实现流控。CTS道理一个样。故而代码可以如下：

 int main(void)
 {
     SystemInit();
 USART_CTRT_Configuartion();
     while(NbrOfDataToTransfer--)
       {
         USART_SendData(USART1,TxBuffer[TxCounter++]);
         while(USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); //等待发送结束
       }

       /*Receive a string (Max RxBufferSize bytes) from the Hyperterminal ended by '\r' (Enter key) */
     do
     {
         if((USART_GetFlagStatus(USART1, USART_FLAG_RXNE) != RESET)&&(RxCounter < RxBufferSize))    //0xFF:256字符
         {
            RxBuffer[RxCounter] = USART_ReceiveData(USART1);
            USART_SendData(USART1, RxBuffer[RxCounter++]);
         }   

     }while((RxBuffer[RxCounter - ] != '\r')&&(RxCounter != RxBufferSize));

 //串口配置函数

 void USART_CTRT_Configuartion(void)
 {
     USART_InitTypeDef USART_InitStruct;

     Rcc_Configuration();

     USART_InitStruct.USART_BaudRate = ;
     USART_InitStruct.USART_StopBits = USART_StopBits_1;
     USART_InitStruct.USART_WordLength = USART_WordLength_8b;
     USART_InitStruct.USART_Parity = USART_Parity_No;
     USART_InitStruct.USART_HardwareFlowControl = USART_HardwareFlowControl_RTS_CTS;
     USART_InitStruct.USART_Mode = USART_Mode_Tx | USART_Mode_Rx;

     USART_Init(USART1, &USART_InitStruct);

     USART_Cmd(USART1, ENABLE);

     UsartGPIO_CTRT_Configuration();
 }

　　完整的代码可以自己参考库函数。这里不再贴了。

引用参考：http://www.cnblogs.com/sunyubo/archive/2010/04/21/2282176.html