中低端路由器上使用disp interface 查看相应串口状态信息,其中DCD、DTR、DSR、RTS及CTS等五个状态指示分别代表什么意思? DCD ( Data Carrier Detect 数据载波检测) DTR(Data Terminal Ready,数据终端准备好) DSR(Data Set Ready 数据准备好) RTS( Request To Send 请求发送) CTS(Clear To Send 清除发送) 在这五个控制信号中,DTR和RTS是DTE设备(数据终端设备,在实际应用中就是路由器)发出的,DSR、CTS和DCD是DCE设备(数据电路终结设备,在实际中就是各种基带MODEM)发出的。 这五个控制信号的协商机制如下: 1、在路由器的串口没有配置流控命令的情况下,只要一上电,DTR和RTS就会被置成有效(即只要一加电这两个状态就UP,不管串口有没有接电缆),当路由器检测到对端送过来的DSR、CTS和DCD三个信号时,串口的物理状态就上报UP(任何一个物理信号无效都不会报UP,或者说,这三个信号中只要有一个为DOWN,路由器串口的物理状态就处于DOWN的状态)。 另外,如果在路由器的串口上配置了NO DETECT DSR-DTR命令,DTE侧(路由器)就不会检测对端是否送过来DSR和CTS信号,只要检测到DCD信号,物理层就报UP。 2、如果在路由器的串口上配置了流控命令(具体命令为flowcontrol auto),RTS和CTS两个信号就会用于流量控制(路由器串口和基带Modem之间的数据发送、接收流控)。当出现数据处理不及时的情况,这两个控制信号就可能处于DOWN的状态
转自:http://blog.csdn.net/zeroboundary/article/details/8966586
最近太忙了,没时间写对Ucos-II的移植,先将工作中容易搞错的一个知识点记录下来,关于CTS与RTS的。
在RS232中本来CTS 与RTS 有明确的意义,但自从贺氏(HAYES ) 推出了聪明猫(SmartModem)后就有点混淆了,不过现在这种意义为主流意义的,各大芯片制造厂家对UART控制器的流控基本采用HAYES MODEM流控解释。
在RS232中RTS 与CTS 是用来半双工模式下的方向切换,本文不解释;
如果UART只有RX、TX两个信号,要流控的话只能是软流控;如果有RX,TX,CTS,RTS 四个信号,则多半是支持硬流控的UART;如果有 RX,TX,CTS ,RTS ,DTR,DSR 六个信号的话,RS232标准的可能性比较大。
SIMCOM公司对RTS/CTS的解释:
(要注意区别是不是讲串口支持硬流控的RTS/CTS,别看为益,在和瑞芯微调试硬件流控时,别这个非主流的解释搞得晕头转向的,下面用灰色小字体表示)
RTS是模块的输入端,用于MCU通知模块,MCU是否准备好,模块是否可向MCU发送信息,RTS的有效电平为低。
CTS是模块的输出端,用于模块通知MCU,模块是否准备好,MCU是否可向模块发送信息,CTS的有效电平为低
HAYES Modem中的RTS ,CTS 是用来进 行硬件流控的。现在通常UART的RTC、CTS的含义指后者,即用来做硬流控的。
硬流控的RTS、CTS:
(现在做串口使用RTS/CTS必看内容,因为MTK/)
RTS (Require ToSend,发送请求)为输出信号,用于指示本设备准备好可接收数据,低电平有效,低电平说明本设备可以接收数据。
CTS (Clear ToSend,发送允许)为输入信号,用于判断是否可以向对方发送数据,低电平有效,低电平说明本设备可以向对方发送数据。
此处有人将CTS翻译为发送允许,我感觉的确比翻译为清除发送好。因为CTS是对方的RTS控制己方的CTS是否允许发送的功能。
用AP与MODEM采用流控收发串口数据举例:
CTS 为输入
RTS 为输出
AP的CTS对接MODEM的RTS;MODEM的CTS对接AP的RTS。
默认启动时:
AP的CTS为高
AP的RTS为低
MODEM的CTS 高 但极容易被拉低
MODEM的RTS 低
默认休眠时
MODEM的CTS 高 但极容易被拉低
MODEM的RTS 高
其中CTS用电压表测量电压时发现:在测量最初的大概200ms时,为高电平,然后电压值不断下降,变成低电平,这说明CTS悬空时应该为高,这中高电平仅仅是一定量的正电荷而已。
不知道芯片设计时,规格说明书为什么要写CTS默认为高,CTS仅仅是输入端,不需要什么默认值啊。并且在流控打开情况下,不接CTS与RTS,也是可以正常3根线(RXD/TXD/GND)通信的,这说明不接RTS/CTS时,CTS为低电平才对。为何实际使用与芯片规格说明书不一致,可能是被外壳金属盖干扰到低电平了,毕竟自己用的模块,CTS是如此靠近低电平的金属保护盖,并且CTS为输入口,没有上拉下拉电平能力。
AP与MODEM的流控这样通信的:
AP串口可用时,将AP-RTS拉低,MODEM-CTS检测到AP-RTS为低,知道AP串口已准备好,可以发送数据;
AP串口不可用时,将AP-RTS拉高,MODEM-CTS检测到AP-RTS为高,知道AP串口还未准备好,就不会放数据。
MODEM串口可用与不可用时的交互是同样道理。
没有串口控制器,用中断和普通IO口即可实现RTS与CTS功能。
RTS用GPIO实现,串口就绪拉低电平,串口忙拉高电平
CTS用中断实现,检测到低电平,将串口数据发送出去,检测到高电平则保留串口数据直到检测到低电平为止。
下面是摘录网上有用的参考资料:
假定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 circuitEquipment )来说,默认的方向是DTE接收,DCE发送。如果DTE要发送数据,必须发出RTS 信号,请求发送数据。DCE收到后如果空闲则发出CTS 回应RTS 信号,表示响应请求,这样通信方向就变为DTE->TCE,同时RTS 与CTS 信号必须一直保持。从这里可以看出,CTS ,TRS虽然也有点流控的意思(如CTS 没有发出,DTE也不能发送数据),但主要是用来进行方向切换的。
流控制在串行通讯中的作用
这里讲到的“流”,当然指的是数据流。数据在两个串口之间传输时,常常会出现丢失数据的现象,或者两台计算机的处理速度不同,如台式机与单片机之间的通讯,接收端数据缓冲区已满,则此时继续发送来的数据就会丢失。现在我们在网络上通过MODEM进行数据传输,这个问题就尤为突出。流控制能解决这个问题,当接收端数据处理不过来时,就发出“不再接收”的信号,发送端就停止发送,直到收到“可以继续发送”的信号再发送数据。因此流控制可以控制数据传输的进程,防止数据的丢失。PC机中常用的两种流控制是硬件流控制(包括RTS/CTS、DTR/CTS等)和软件流控制XON/XOFF(继续/停止),下面分别说明。
硬件流控制
硬件流控制常用的有RTS/CTS流控制和DTR/DSR(数据终端就绪/数据设置就绪)流控制。
硬件流控制必须将相应的电缆线连上,用RTS/CTS(请求发送/清除发送)流控制时,应将通讯两端的RTS、CTS线对应相连,数据终端设备(如计算机)使用RTS来起始调制解调器或其它数据通讯设备的数据流,而数据通讯设备(如调制解调器)则用CTS来起动和暂停来自计算机的数据流。这种硬件握手方式的过程为:我们在编程时根据接收端缓冲区大小设置一个高位标志(可为缓冲区大小的75%)和一个低位标志(可为缓冲区大小的25%),当缓冲区内数据量达到高位时,我们在接收端将CTS线置低电平(送逻辑0),当发送端的程序检测到CTS为低后,就停止发送数据,直到接收端缓冲区的数据量低于低位而将CTS置高电平。RTS则用来标明接收设备有没有准备好接收数据。
常用的流控制还有还有DTR/DSR(数据终端就绪/数据设置就绪)。我们在此不再详述。由于流控制的多样性,我个人认为,当软件里用了流控制时,应做详细的说明,如何接线,如何应用。
软件流控制
由于电缆线的限制,我们在普通的控制通讯中一般不用硬件流控制,而用软件流控制。一般通过XON/XOFF来实现软件流控制。常用方法是:当接收端的输入缓冲区内数据量超过设定的高位时,就向数据发送端发出XOFF字符(十进制的19或Control-S,设备编程说明书应该有详细阐述),发送端收到XOFF字符后就立即停止发送数据;当接收端的输入缓冲区内数据量低于设定的低位时,就向数据发送端发出XON字符(十进制的17或Control-Q),发送端收到XON字符后就立即开始发送数据。一般可以从设备配套源程序中找到发送的是什么字符。
应该注意,若传输的是二进制数据,标志字符也有可能在数据流中出现而引起误操作,这是软件流控制的缺陷,而硬件流控制不会有这个问题。
版权声明:本文为博主原创文章,未经博主允许不得转载。
本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/4760255.html,如需转载请自行联系原作者