关于WinCE串口驱动的解析

虽然串口通讯已经是普遍的标准而且广为大家熟知，但驱动中涉及的部分内容也可能在平时的应用中并不是很常用到，在这里做一个简单的介绍待后面说明到具体代码的时候可以连贯一些。
　　串行通讯接口是目前十分流行的通讯接口之一。由于其电气界面的简单性使其在计算机领域的应用相当的广泛。在这里提到的串行通讯接口主要是指UART（通用串行）和IRDA两种。通常的串行连接电气连接上有3wire和9wire两种。3wire的接线方式下定义了发送、接收和地三根连接。其用途就如名称一样分别用于发送、接收。
　　通常在串行接口控制器上会有两个FIFO用作接收和发送的缓冲，当接收到数据后会直接将接收到的数据置入该缓冲器，并同时由控制电路向本地总线发出通知，以便让本地总线将缓冲器内的数据读走，这样在响应（等待和读取）的过程中仍然能通过缓冲器来接收数据。而发送发送的过程刚刚相反，本地总线可一直向发送缓冲写入数据直到器填满为止，而无需对每个数据的发送进行等待。这就是基本的收发流程（这部分逻辑流程相信大家是最熟悉的）。这一点在3wire和9wire中都是相同的。但是我们考虑下面的情况，如果接收一方的响应由于某种原因的干扰（如处理器被其他中断服务占用）的时候可能就来不及相应之前ReceiveFIFO就可能被填满了，这样后续发送过来的数据就会丢失，这样在需要数据可靠传输的情况下串行通讯的弊端也就显示出来了。如需要数据的可靠传输就需要对数据流的收发进行控制。在9wire中将串行连接定义为如下形式。
　　针号123456789
　　缩写DCDRXDTXDDTRGNDDSRRTSCTSDELL
　　功能说明数据载波检测接收数据发送数据数据终端就绪信号地数据设备就绪请求发送清除发送振铃指示
　　也就是说在原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网络的一部分。而红外本身的协议就相对复杂的多，它有专门的一套模型来描述其使用规则，对红外设备本身了解不多也就不能深入下去。在串口的这一侧，整个驱动模型也是相当的复杂的，但所幸的是驱动仅仅使用到SerialAPI这一层，在这个层次上串口的行为还是相对简单的。
　　我们这里仅仅涉及上面所提到的Serial/irda Driver这部分（绿色部分）。在wince提供的驱动例程中串口/红外驱动采用分层结构设计，MDD提供框架性的实现，负责提供OS所需的基本实现，并将代码设计与具体的硬件设计无关。而PDD提供了对硬件操作相应的代码。这些代码通过结构HWOBJ来相互联系。对于MDD+PDD的整体驱动来看，串口驱动模型是作为Stream来实现的。 两者合一以达到实现驱动的目的。DDSI就是指这两个部分之间的接口，这个接口并非受到强制的物理/逻辑关系来约束，而是人为的规定的。在涉及到一种特定硬件我们进行针对实现的时候往往需要的是了解硬件的物理特性和控制逻辑，然后根据DDSI的约束就来进行实现。对于这里描述的驱动模型而言结合关键在于结构指针HWOBJ的使用和具体实现。在实际的驱动应用中仅仅需要实现HWOBJ相关的一系列函数，而无需从驱动顶层完全开发。串口驱动模型作为一种常用驱动模型在windowsCE中常常用于串口/红外/USB Client的具体实现。该驱动模型中对全功能的串口进行了定义，除了常用的TX和RX引线定义以外，针对DTR、RTS等功能引脚都进行了支持，使得用该模型设计的串口驱动支持流控制、具备驱动Modem等设备的能力。
　　事实上，如果需要的话完全可以将该驱动一体化设计（抛开PDD-MDD的划分，也就无须DDSI）。也就是不使用现有的驱动架构来进行实现。考虑到串口驱动的使用频率和执行效率要求都不是很苛刻的情况下抛弃驱动架构另外实现的就没有多大必要了。
　　对于驱动本身而言，串行驱动从功能和实现上相当的简单，确具被相当全面的成分，对该驱动的分析和了解无疑是学习流式驱动程序很好的典范。
　　代码分析
　　在开始具体代码之前我们先来看看，相关的一些结构。 HWOBJ是相应的硬件设备操作的抽象集合。结构的定义后的注释与实际的用途有点点出入，BandFlags指定IST的启动时间，可选为在初始化过程启动或是在打开设备的时候起动ISR.而第二个参数则是指定拦截的具体的系统中断号。最后一个参数是一个结构，该结构定义了硬件操作的各式行为函数的指针，MDD正是通过这些函数来访问具体的PDD操作。
　　typedef struct __HWOBJ {
　　ULONG BindFlags; // Flags controlling MDD behaviour. Se above.
　　DWORD dwIntID; // Interrupt Identifier used if THREAD_AT_INIT or THREAD_AT_OPEN
　　PHW_VTBL pFuncTbl;
　　} HWOBJ， *PHWOBJ;
　　而HW_VTBL则是代表具体硬件操作函数指针的集合，该结构所指向的函数包括了初始化、打开、关闭、接收、发送、设置Baudrate等一系列操作。结构存在就像纽带一样联系着PDD中的具体实现和MDD中的抽象操作。PDD的实现必须遵循HW_VTBL中所描述的函数形式，并构造出相应的HW_VTBL实例。驱动的编写就是针对这些函数来一一进行实现。