RTS与CTS的含义【转】-阿里云开发者社区

开发者社区> 人工智能> 正文
登录阅读全文

RTS与CTS的含义【转】

简介:

转自:http://www.cnblogs.com/sunyubo/archive/2010/04/21/2282176.html

一、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)有效时,恢复发送; 
收. 0当接收buffers中的bytes当接收buffers中的bytes>N 时,给 RTS 无效信号(-3v to -15v); 
  MODEM端处理: 
同上,但RTS与CTS交换。












本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/sky-heaven/p/4837409.html,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
人工智能
使用钉钉扫一扫加入圈子
+ 订阅

了解行业+人工智能最先进的技术和实践,参与行业+人工智能实践项目

其他文章