RS232中RTS和CTS的作用

问:
以前挺明白的,今天一下子觉得以前的理解都不对了,以下三种解释哪个对呢?

解释一:
RTS
:终端我已经准备就绪,有数据就发过来吧
CTS
:来了,接招

解释二:
RTS
:终端我准备发数据给你,快用CTS应答,准备好没?
CTS
:好了,来吧

解释三:
CTS
:主机,我有数据,请求接收
RTS
:我是主机,就绪,请求发送。

我今天弄了个SIM100模块,我将RTS设置无效之后,凡是要发往主机的数据都没有发过来(包括主动数据RING),指令和指令返回结果都没有返回,都缓存在模块之中,等我将RTS设置有效后,缓存的数据全发来了,包括一大堆指令的执行结果,由此,我觉得上面的“解释一”应该正确,而“解释二”应该是错的,但“解释三”是否正确呢?就是说CTSRTS哪个是发起者呢?

答:
一是错的
二是RS232标准
三是MODEM的硬件流控
SIMCOM
公司的解释完全正确

    
很久很久以前,计算机还没有出现,那时就已经存在了(计算机)史前的串口设备(电传打字机,工控测量设备,通信调制解调器),为了连接这些串口,EIA制定了RS232标准,采用DB25接插件,支持同步和异步串口,D型的接口可以有效防止插反。标准化给使用带来了便利。
    
时光荏苒,个人计算机出现了,这些已有的串口设备毫无疑问地成为了最初的外设,自然而然地RS232标准被个人计算机采纳。但是设备制造商倾向于体积更小,成本更低的接口,因此,将DB25中未使用的和支持同步模式的引脚去掉,形成DB9。最初的情况相当混乱,因为DB9只定义了信号,却没有指定信号和引脚的对应关系,各个制造商只能自行定义。幸运的是,IBMPC成了工业标准,DB9逐渐统一到IBM的定义上来。
    DB9
只有9根线,遵循RS232标准。定义如下:
    DTR,DSR------DTE
设备准备好/DCE设备准备好。主流控信号。
    RTS,CTS------
请求发送/清除发送。用于半双工时,收发切换。属于辅助流控信号。半双工的意思是说,发的时候不收,收的时候不发。那么怎么区分收发呢?缺省时是DCEDTE发送数据,当DTE决定向DCE发数据时,先有效RTS,表示DTE希望向DCE发送,一般DCE不能马上转换收发状态,DTE就通过监测CTS是否有效来判断可否发送,这样避免了DTEDCE未准备好时发送所导致的数据丢失。
    
全双工时,这两个信号一直有效即可。
    
    
随着计算机的日益普及,很多非RS232的串口也要接入PC机,如果为每一种新出现的串口都增加一个新的I/O口显然不现实,因为PC后面板位置有限,因此,将RS232串口和非RS232串口都通过RS232口接入是最佳方案。UARTU(通用)指的就是这个意思。早期ROM BIOSDOS里的通信软件都是为RS232设计的,在没有检测到DCD有效前不会发送数据,因此,就连发送一个字符这样朴素的应用也要给出DCDDTRDSR等控制信号。因此,串口接头上要将一些控制线短接,或者干脆绕过系统软件自己写通信程序。
    
到此,UART的涵义就总结为:通用的 异步 (串行) I/O口。
    
就在UART冠以通用二字,准备一统江湖的时候,制造商们不满于它的速度、体积和灵活性(软件可配置),推出了USB1394串口。目前,笔记本上的UART串口有被取消的趋势,因而有网友发出了“没有串口,吾谁与归”的慨叹,古今多少事,都付笑谈中,USB取代UART是后话,暂且不表。
    
话说自从贺氏(Hayes)公司推出了聪明猫(SmartModem),他们制定的MODEM接口就成了业界标准,自此以后,所有公司制造的兼容猫都符合贺氏标准(AT指令也兼容,大家一起抄他呗)
    
细观贺氏制定的MODEM串口,与RS232标准大不相同。DTR在整个通信过程中一直保持有效,DSRMODEM上电后/可以拨号前有效(取决于软件对DSR的理解),在通信过程的任意时刻,只要DTR/DSR无效,通信过程立即终止。在某种意义上,这也可以算是流控,但肯定不是RS232所指的那种主流控。如果拘泥于RS232,你是不会理解DTRDSR的用途的。
    
贺氏不但改了DTRDSR,竟然连RTSCTS的涵义也重新定义了。因此,RTSCTS已经不具有最开始的意义了。从字面理解RTSCTS,是用于半双工通信的,当DTE想从收模式改为发模式时,就有效RTS请求发送,DCE收到RTS请求后不能立即完成转换,需要一段时间,然后有效CTS通知DTEDCE已经转到发模式,DTE可以开始发送了。在全双工时,RTSCTS都缺省置为有效即可。然而,在贺氏的MODEM串口定义中,RTSCTS用于硬件流控,和什么劳什子的全双工/半双工一点关系也没有。
    
注意,硬件流控是靠软件实现的,之所以强调“硬件”二字,仅仅是因为硬件流控提供了用于流量情况指示的硬件连线,并不是说,你只要把线连上,硬件就能自己流控。如果软件不支持,光连上RTSCTS是没有用的。
    RTS
CTS硬件流控的软件算法如下:(RTS有效表示PC机可以收,CTS有效表示MODEM可以收,这两个信号互相独立,分别指示一个方向的流量情况。
  
<think>好的,我现在要回答用户关于带CTSRTS的RS-232的问题。首先,我需要回忆一下RS-232的基本知识,然后理解CTSRTS作用。记得RS-232是一种串行通信标准,用于设备之间的数据传输,比如计算机调制解调器。 下来,CTSRTS应该属于流量控制的机制。流量控制在串行通信中很重要,防止数据丢失。CTS是Clear To Send,RTS是Request To Send。这两个信号线用于硬件流量控制,也就是所谓的“硬件握手”。我需要确认这一点是否正确。 然后,我需要详细解释这两个信号的工作流程。当发送方(比如计算机)准备好发送数据时,它会拉高RTS线,表示请求发送。收方(比如调制解调器)如果准备好收,就会拉高CTS线,作为响应,允许发送方开始传输数据。如果收方缓冲区满了,CTS会被拉低,发送方暂停发送。这个过程确保数据不会溢出,导致丢失。 另外,可能需要比较软件流量控制,比如XON/XOFF,说明硬件控制的优势,比如更快的响应更高的可靠性,尤其是在高速传输时。不过RS-232通常用于较低速的场景,但硬件流量控制仍然重要。 还要注意RS-232的物理层特性,比如电压电平、DB9或DB25连器的引脚分配。CTSRTS通常使用特定的引脚,例如在DB9连器中,RTS是引脚7,CTS是引脚8。这部分可能需要检查是否正确,避免混淆其他引脚如TXD、RXD等。 此外,用户可能想知道应用场景,比如在什么情况下需要使用CTSRTS。例如,当两台设备之间的数据传输速率不匹配,或者收方处理速度较慢时,硬件流量控制能有效防止数据丢失。应用实例包括老式的调制解调器通信、工业控制设备等。 需要确保解释清晰,步骤分明,先介绍RS-232,再引入流量控制的必要性,然后详细讲解CTSRTS的工作原理,最后总结它们的应用优势。同时,注意使用中文口语化的表达,避免过于技术化的术语,但又要准确无误。 可能存在的疑问点:是否所有RS-232通信都必须使用CTSRTS?应该说明这是可选的,根据实际需求配置。另外,是否需要提到其他流量控制方法作为对比?比如软件流量控制,可以简要提及以突出硬件控制的优势。 最后检查LaTeX格式是否符合要求,行内公式用$...$,独立公式用$$...$$,但在这个问题中可能涉及较少的数学公式,更多是信号流程的解释。不过如果有涉及方程或符号,比如时序图,可能需要用LaTeX描述,但可能更倾向于文字描述流程图。 总结回答的结构:引言、RS-232概述、流量控制的重要性、CTSRTS作用机制、物理连、应用场景、其他方法的对比、总结。这样用户能够逐步理解整个概念。</think>带CTS(Clear To Send)RTS(Request To Send)的RS-232是一种通过硬件信号实现流量控制的串行通信协议。以下是详细解释: --- ### 1. **RS-232基础** RS-232是一种异步串行通信标准,用于设备间数据传输(如计算机调制解调器)。其特点包括: - 使用正负电压表示逻辑值(如+3~+15V为“0”,-3~-15V为“1”)。 - 常见口类型为DB9或DB25连器。 --- ### 2. **流量控制的必要性** 当发送端速率 > 收端处理能力时,数据可能丢失。**流量控制**通过协调收发节奏解决此问题。RS-232支持两种方式: - **软件流量控制**:用XON/XOFF字符控制(灵活性高,但延迟大)。 - **硬件流量控制**:用CTSRTS信号(响应快、可靠性高)。 --- ### 3. **CTSRTS作用机制** CTSRTS是两根独立的控制信号线,属于硬件握手协议: 1. **RTS(Request To Send)** - 由发送端(如计算机)控制。 - 拉高(逻辑“0”)表示发送端准备好发送数据。 2. **CTS(Clear To Send)** - 由收端(如调制解调器)控制。 - 拉高(逻辑“0”)表示收端准备好收数据。 **工作流程**: 1. 发送端拉高RTS,请求发送。 2. 收端若就绪,则拉高CTS。 3. 发送端检测到CTS有效后,开始传输数据。 4. 若收端缓冲区满,拉低CTS,发送端暂停传输。 --- ### 4. **物理连(以DB9为例)** | 引脚 | 名称 | 方向 | 功能 | |------|------|----------|----------------| | 7 | RTS | 输出 | 发送端请求发送 | | 8 | CTS | 输入 | 收端允许发送 | | 2 | TXD | 输出 | 发送数据 | | 3 | RXD | 输入 | 收数据 | --- ### 5. **应用场景** - **高速通信**:CTS/RTS可避免缓冲区溢出(优于软件控制)。 - **长距离传输**:硬件信号抗干扰能力强。 - **工业设备**:PLC、传感器等需要可靠控制的场景。 --- ### 6. **其他流量控制的对比** | 类型 | 优点 | 缺点 | |----------|-----------------------|-----------------------| | CTS/RTS | 实时性强、可靠性高 | 需额外连线 | | XON/XOFF | 无需硬件支持 | 延迟大、可能误触发 | --- ### 总结 带CTSRTS的RS-232通过硬件握手实现高效流量控制,适用于对可靠性要求高的场景。理解其引脚定义交互流程,可帮助正确配置串口通信设备。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值