一、串口引脚
1 DCD 载波检测 2 RXD Receive Data 接收数据 3 TXD Transmit Data 发送数据 4 DTR Data Terminal Ready 数据终端准备 5 GND System Ground 接地 6 DSR Data Set Ready 数据准备完成 7 RTS Request to Send 请求发送 8 CTS Clear to Send 清除发送 9 RI Ring Indicator 振铃提示 RS232标准 DB9只有9根线,遵循RS232标准。定义如下: DTR,DSR------DTE设备准备好/DCE设备准备好。主流控信号。 RTS,CTS------请求发送/清除发送。用于半双工时,收发切换。属于辅助流控信号。半双工的意思是说,发的时候不收,收的时候不发。那么怎么区分收发呢?缺省时是DCE向DTE发送数据,当DTE决定向DCE发数据时,先有效RTS,表示DTE希望向DCE发送,一般DCE不能马上转换收发状态,DTE就通过监测CTS是否有效来判断可否发送,这样避免了DTE在DCE未准备好时发送所导致的数据丢失。 全双工时,这两个信号一直有效即可。 当前默认标准 自从贺氏(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<M 时,给 RTS 有效信号(+3v to +15v), 当接收buffers中的bytes>N 时,给 RTS 无效信号(-3v to -15v); MODEM端处理: 同上,但RTS与CTS交换 二、流控说明 .流控制在串行通讯中的作用 解决丢失数据的问题 .硬件流控制 硬件流控制常用的有RTS/CTS(请求发送/清除发送)流控制和DTR/DSR(数据终端就绪/数据设置就绪)流控制 .软件流控制 一般通过XON/XOFF来实现软件流控制 三、有关有关硬件流控与软件流控 硬件流控与软件流控都是采用流量控制的原理进行工作,只是采用的信号不同而乙。硬件流控时,计算机通过置RST信号为低来停止MODEM传输,置为高时恢复传输;MODEM通过RST为低来暂停计算机的发送,置为高时恢复发送。软件流控不使用RST和CTS信号,而是靠发送特殊的字符XOFF来停止对方的发送,发送XON来恢复对方的发送,计算机接收时,流控信号XON/XOFF字符从TD线发至MODEM;当MODEM接收时,XON/XOFF字符从RD线发至计算机。软件流控不适合于用来传输二进制文件,因为它会把文件中的数据误认为是流控信号。一般情况下,应采用硬件流控。 |
转自: http://renyan.spaces.eepw.com.cn/articles/trackback/item/84498