WinCE下的串口驱动分析

串口驱动分析

Auth：nasiry

date： 2005年4月12日
abort： windowsCE.net 420串口驱动分析

虽然串口通讯已经是普遍的标准而且广为大家熟知，但驱动中涉及的部分内容也可能在平时的应用中并不是很常用到，在这里做一个简单的介绍待后面说明到具体代码的时候可以连贯一些。

串行通讯接口是目前十分流行的通讯接口之一。由于其电气界面的简单性使其在计算机领域的应用相当的广泛。在这里提到的串行通讯接口主要是指UART(通用串行)和IRDA两种。通常的串行连接电气连接上有3wire和9wire两种。3wire的接线方式下定义了发送、接收和地三根连接。其用途就如名称一样分别用于发送、接收。下面是通常3wire连接的结构框图

通常在串行接口控制器上会有两个FIFO用作接收和发送的缓冲，当接收到数据后会直接将接收到的数据置入该缓冲器，并同时由控制电路向本地总线发出通知，以便让本地总线将缓冲器内的数据读走，这样在响应(等待和读取)的过程中仍然能通过缓冲器来接收数据。而发送发送的过程刚刚相反，本地总线可一直向发送缓冲写入数据直到器填满为止，而无需对每个数据的发送进行等待。这就是基本的收发流程(这部分逻辑流程相信大家是最熟悉的)。这一点在3wire和9wire中都是相同的。但是我们考虑下面的情况，如果接收一方的响应由于某种原因的干扰(如处理器被其他中断服务占用)的时候可能就来不及相应之前ReceiveFIFO就可能被填满了，这样后续发送过来的数据就会丢失，这样在需要数据可靠传输的情况下串行通讯的弊端也就显示出来了。如需要数据的可靠传输就需要对数据流的收发进行控制。在9wire中将串行连接定义为如下形式。

也就是说在原3wire的基础上增加了DCD,DTR,DSR,RTS,CTS,DELL六个控制线。其中RTS/CTS用于流控制，另外的DCD和DELL则留作连接modem使用。有了专门的硬件流控制引脚也就使得流控制成为可能，以完成收发两端的匹配使得数据可以可靠的传输。用RTS/CTS（请求发送/清除发送）流控制时，应将通讯两端的RTS、CTS线对应相连).在发送端准备发送数据之前设置RTS(Request to send)也就使发送请求线，若接收端以作好接收准备，就启动响应的CTS（Clear to send）引线。这样，收发双发就进入数据传输状态，在此过程中如若接收端处理数据的速度低于发送端的发送速度，接收一端还可以设置CTS引线恢复原来阻塞得状态以暂时中断数据传输，之后若需要恢复数据传输恢复CTS状态即可。这样UART的传输即实现了流控制，保障了数据传输的完备性。

在这里还要说一下软件流控制，虽然硬件已经可以完成流控制的任务但很多少时候受到连线数的限制不能使用硬件流控制也就设计了专门的软件流控制的方法。现在回到3线传输的情景，若接收端接收数据过程中缓冲器的负载到达某一限制(也就是留出一定的缓冲空间)时接收端向发送端发送一个特殊的标示位(接收停止位)，当发送端收到该标示的时候就停止发送，直到接收端缓冲器低于另一限制后发送标示(接收许可位)给发送端，这样就可以控制数据流的传输起停。这种软件流控制是在给缓冲器留余量来完成的，在收发双端处理器速度差很大的时候就不太适用了，就必须要用硬件流控制。

其他几个引脚都是与modem相关的，DSR数据装置准备好（Data set ready)用于表明MODEM处于可以使用的状态。DTR数据终端准备好(Data terminal ready)表明数据终端可以使用。这两个信号用于检查Modem是否连接。DELL脚当有电话拨入时Modem将会设置这个引脚。DCD信号是当Modem接收到数字载波信号的时候被设置，用于了解Modem接收信号的情况。

至于剩下的奇偶效验和停止位设置就只是需要针对寄存器设置无需软件干涉就可以完成了。下面我们来看具体的驱动程序。

在wince中串口的驱动实现是有固定模型的，ce中的串口模型遵循ISO/OSI网络通讯模型(7层)，就是说串口属于CE网络模块的一个部分。其中rs232界面(或其它的物理介质)实现网络的物理层，而驱动和serialAPI共同组成数据链路层，其它部分都没有做定义。在典型的应用中,serialAPI与间接通过TAPI或直接与ActiveSync交互，组成CE网络的一部分。而红外本身的协议就相对复杂的多，它有专门的一套模型来描述其使用规则，对红外设备本身了解不多也就不能深入下去。在串口的这一侧，整个驱动模型也是相当的复杂的，但所幸的是驱动仅仅使用