雖然串口通訊已經是普遍的標準而且廣為大家熟知，但驅動中涉及的部分內容也可能在平時的應用中并不是很常用到，在這里做一個簡單的介紹待后面說明到具體代碼的時候可以連貫一些。
　　串行通訊接口是目前十分流行的通訊接口之一。由于其電氣界面的簡單性使其在計算機領域的應用相當的廣泛。在這里提到的串行通訊接口主要是指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實例。驅動的編寫就是針對這些函數來一一進行實現。