UART通讯流控制方法

fangfeidefengzheng 2010-10-11

展开全文

UART通讯流控制方法收藏
谈这个问题之前我们先介绍另一个概念,DCE(Data Communication Equipment数据通讯设备)速度。它是指两个Modem之间即电话线之间的传输速度,我们所说的56K指的就是这个速度。而DTE(Data Terminal Equipment数据终端设备)速度是指从本地计算机到Modem的传输速度,如果电话线传输速率(DCE速度)为56000bps,Modem在接收到数据后按V.42 bis协议解压缩56000×4=115200bps,然后以此速率传送给计算机,由此可见56K猫(使用V.42bis)的DTE速度在理想状态下都应达到115200bps。

可用CTS/RTS或Xon/Xoff流量控制(Flow control)

从上边的介绍我们已经了解到DTE与DCE速度之间存在很大差异,这样在数据的传送与接收过程当中很可能出现收方来不及接收的情况,这时就需要对发方进行控制,以免数据丢失,这个过程就是所谓的流量控制。控制的方式有两种,Xon/Xoff和CTS/RTS。前者由软件产生控制码,并将控制码加入到数据流中,Xoff表示停止发送,Xon表示继续发送,此种方法通常用于2400bps左右的低速猫。CTS(clear to send)/RTS(request to send)则是通过计算机与Modem之间的信号线传送控制信号来实现流量控制的，即硬件方式。请求发送信号(RTS)由计算机产生,通知Modem可以发送数据,清除发送信号(CTS)由Modem产生,通知计算机可以传送数据.由于硬件控制的反应速度要比软件快，所以多用于高速Modem。在使用 MNP,V.42以及传真时也应使用硬件方式。

CTS (Clear to send) 允许发送, 很多文章翻译成清除发送, 是不正确的.

CTS 是对RTS 的应答.

A向B发送RTS信号，表明A要向B发送若干数据，B收到RTS后，向所有基站发出CTS信号，表明已准备就绪，A可以发送

CTS和RTS是串行通讯中流控制的两个管脚，本身成对出现。一般连接方式如下图所示：

图2 UART流控制示意图。
具体地说，就是当接收方（UART2）认为可以接受UART数据时，将RTS置为有效位。发送方（UART1）的CTS管脚接收到此信号后，才将数据进行发送。一般来说，当UART数据接收缓存大于两个字节空余时，就可以将RTS置为有效接收。当然，OD2101的UART接收缓冲区具有64位的字节，用户可以按照自己数据流量的需求定义RTS。

一、远距离通信

第1和第2中情况是属于远距离通信（传输距离大于15m的通信）的例子，故一般要加调制解调器MODEM，因此使用的信号线较多。注意：在以下各图中，DTE信号为RS-232-C信号，DTE与计算机间的电平转换电路未画出。

1、采用Modem(DCE)和电话网通信时的信号连接：

若在双方MODEM之间采用普通电话交换线进行通信，除了需要2～8号信号线外还要增加RI(22号)和DTR(20号)两个信号线进行联络，如图1所示：

图1

DSR、DTR：数传机（DCE）准备好、数据终端（DTE）准备好，只表示设备本身可用。

首先，通过电话机拔号呼叫对方，电话交换台向对方发出拔号呼叫信号，当对方DCE收到该信号后，使RI（振铃信号）有效，通知DTE，已被呼叫。当对方“摘机”后，两方建立了通信链路。

若计算机要发送数据至对方，首先通过接口电路（DTE）发出RTS（请求发送）信号。此时，若DCE（Modem）允许传送，则向DTE回答CTS（允许发送）信号。一般可直接将RTS/CTS接高电平，即只要通信链路已建立，就可传送信号。（RTS/CTS可只用于半双工系统中作发送方式和接收方式的切换。

当DTE获得CTS信号后，通过TXD线向DCE发出串行信号，DCE（Modem）将这些数字信号调制成模拟信号（又称载波信号），传向对方。

计算机向DTE“数据输出寄存器”传送新的数据前，应检查Modem状态和数据输出寄存器为空。当对方的DCE收到载波信号后，向对方的DTE发出DCD信号（数据载波检出），通知其DTE准备接收，同时，将载波信号解调为数据信号，从RXD线上送给DTE，DTE通过串行接收移位寄存器对接收到的位流进行移位，当收到1个字符的全部位流后，把该字符的数据位送到数据输入寄存器，CPU可以从数据输入寄存器读取字符。

2、采用专用电话线通信：在通信双方的MODEM之间采用电话线进行通信，则只要使用2～8号信号线进行联络与控制。不需要电话机、振铃信号RI和DTR信号，其信号线的连接如图2那样。

图2

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/tequlialv/archive/2010/10/09/5929409.aspx