雖然串口通訊已經(jīng)是普遍的標(biāo)準(zhǔn)而且廣為大家熟知，但驅(qū)動(dòng)中涉及的部分內(nèi)容也可能在平時(shí)的應(yīng)用中并不是很常用到，在這里做一個(gè)簡(jiǎn)單的介紹待后面說明到具體代碼的時(shí)候可以連貫一些。
　　串行通訊接口是目前十分流行的通訊接口之一。由于其電氣界面的簡(jiǎn)單性使其在計(jì)算機(jī)領(lǐng)域的應(yīng)用相當(dāng)?shù)膹V泛。在這里提到的串行通訊接口主要是指UART（通用串行）和IRDA兩種。通常的串行連接電氣連接上有3wire和9wire兩種。3wire的接線方式下定義了發(fā)送、接收和地三根連接。其用途就如名稱一樣分別用于發(fā)送、接收。
　　通常在串行接口控制器上會(huì)有兩個(gè)FIFO用作接收和發(fā)送的緩沖，當(dāng)接收到數(shù)據(jù)后會(huì)直接將接收到的數(shù)據(jù)置入該緩沖器，并同時(shí)由控制電路向本地總線發(fā)出通知，以便讓本地總線將緩沖器內(nèi)的數(shù)據(jù)讀走，這樣在響應(yīng)（等待和讀取）的過程中仍然能通過緩沖器來接收數(shù)據(jù)。而發(fā)送發(fā)送的過程剛剛相反，本地總線可一直向發(fā)送緩沖寫入數(shù)據(jù)直到器填滿為止，而無需對(duì)每個(gè)數(shù)據(jù)的發(fā)送進(jìn)行等待。這就是基本的收發(fā)流程（這部分邏輯流程相信大家是最熟悉的）。這一點(diǎn)在3wire和9wire中都是相同的。但是我們考慮下面的情況，如果接收一方的響應(yīng)由于某種原因的干擾（如處理器被其他中斷服務(wù)占用）的時(shí)候可能就來不及相應(yīng)之前ReceiveFIFO就可能被填滿了，這樣后續(xù)發(fā)送過來的數(shù)據(jù)就會(huì)丟失，這樣在需要數(shù)據(jù)可靠傳輸?shù)那闆r下串行通訊的弊端也就顯示出來了。如需要數(shù)據(jù)的可靠傳輸就需要對(duì)數(shù)據(jù)流的收發(fā)進(jìn)行控制。在9wire中將串行連接定義為如下形式。
　　針號(hào)123456789
　　縮寫DCDRXDTXDDTRGNDDSRRTSCTSDELL
　　功能說明數(shù)據(jù)載波檢測(cè)接收數(shù)據(jù)發(fā)送數(shù)據(jù)數(shù)據(jù)終端就緒信號(hào)地?cái)?shù)據(jù)設(shè)備就緒請(qǐng)求發(fā)送清除發(fā)送振鈴指示
　　也就是說在原3wire的基礎(chǔ)上增加了DCD，DTR，DSR，RTS，CTS，DELL六個(gè)控制線。其中RTS/CTS用于流控制，另外的DCD和DELL則留作連接modem使用。有了專門的硬件流控制引腳也就使得流控制成為可能，以完成收發(fā)兩端的匹配使得數(shù)據(jù)可以可靠的傳輸。用RTS/CTS（請(qǐng)求發(fā)送/清除發(fā)送）流控制時(shí)，應(yīng)將通訊兩端的RTS、CTS線對(duì)應(yīng)相連）。在發(fā)送端準(zhǔn)備發(fā)送數(shù)據(jù)之前設(shè)置RTS（Request to send）也就使發(fā)送請(qǐng)求線，若接收端以作好接收準(zhǔn)備，就啟動(dòng)響應(yīng)的CTS（Clear to send）引線。這樣，收發(fā)雙發(fā)就進(jìn)入數(shù)據(jù)傳輸狀態(tài)，在此過程中如若接收端處理數(shù)據(jù)的速度低于發(fā)送端的發(fā)送速度，接收一端還可以設(shè)置CTS引線恢復(fù)原來阻塞得狀態(tài)以暫時(shí)中斷數(shù)據(jù)傳輸，之后若需要恢復(fù)數(shù)據(jù)傳輸恢復(fù)CTS狀態(tài)即可。這樣UART的傳輸即實(shí)現(xiàn)了流控制，保障了數(shù)據(jù)傳輸?shù)耐陚湫浴?br /> 　　在這里還要說一下軟件流控制，雖然硬件已經(jīng)可以完成流控制的任務(wù)但很多少時(shí)候受到連線數(shù)的限制不能使用硬件流控制也就設(shè)計(jì)了專門的軟件流控制的方法。現(xiàn)在回到3線傳輸?shù)那榫埃艚邮斩私邮諗?shù)據(jù)過程中緩沖器的負(fù)載到達(dá)某一限制（也就是留出一定的緩沖空間）時(shí)接收端向發(fā)送端發(fā)送一個(gè)特殊的標(biāo)示位（接收停止位），當(dāng)發(fā)送端收到該標(biāo)示的時(shí)候就停止發(fā)送，直到接收端緩沖器低于另一限制后發(fā)送標(biāo)示（接收許可位）給發(fā)送端，這樣就可以控制數(shù)據(jù)流的傳輸起停。這種軟件流控制是在給緩沖器留余量來完成的，在收發(fā)雙端處理器速度差很大的時(shí)候就不太適用了，就必須要用硬件流控制。
　　其他幾個(gè)引腳都是與modem相關(guān)的，DSR數(shù)據(jù)裝置準(zhǔn)備好（Data set ready）用于表明MODEM處于可以使用的狀態(tài)。DTR數(shù)據(jù)終端準(zhǔn)備好（Data terminal ready）表明數(shù)據(jù)終端可以使用。這兩個(gè)信號(hào)用于檢查Modem是否連接。DELL腳當(dāng)有電話撥入時(shí)Modem將會(huì)設(shè)置這個(gè)引腳。DCD信號(hào)是當(dāng)Modem接收到數(shù)字載波信號(hào)的時(shí)候被設(shè)置，用于了解Modem接收信號(hào)的情況。
　　至于剩下的奇偶效驗(yàn)和停止位設(shè)置就只是需要針對(duì)寄存器設(shè)置無需軟件干涉就可以完成了。下面我們來看具體的驅(qū)動(dòng)程序。
　　架構(gòu)
　　在wince中串口的驅(qū)動(dòng)實(shí)現(xiàn)是有固定模型的，ce中的串口模型遵循ISO/OSI網(wǎng)絡(luò)通訊模型（7層），就是說串口屬于CE網(wǎng)絡(luò)模塊的一個(gè)部分。其中rs232界面（或其它的物理介質(zhì)）實(shí)現(xiàn)網(wǎng)絡(luò)的物理層，而驅(qū)動(dòng)和serialAPI共同組成數(shù)據(jù)鏈路層，其它部分都沒有做定義。在典型的應(yīng)用中，serialAPI與間接通過TAPI或直接與ActiveSync交互，組成CE網(wǎng)絡(luò)的一部分。而紅外本身的協(xié)議就相對(duì)復(fù)雜的多，它有專門的一套模型來描述其使用規(guī)則，對(duì)紅外設(shè)備本身了解不多也就不能深入下去。在串口的這一側(cè)，整個(gè)驅(qū)動(dòng)模型也是相當(dāng)?shù)膹?fù)雜的，但所幸的是驅(qū)動(dòng)僅僅使用到SerialAPI這一層，在這個(gè)層次上串口的行為還是相對(duì)簡(jiǎn)單的。
　　我們這里僅僅涉及上面所提到的Serial/irda Driver這部分（綠色部分）。在wince提供的驅(qū)動(dòng)例程中串口/紅外驅(qū)動(dòng)采用分層結(jié)構(gòu)設(shè)計(jì)，MDD提供框架性的實(shí)現(xiàn)，負(fù)責(zé)提供OS所需的基本實(shí)現(xiàn)，并將代碼設(shè)計(jì)與具體的硬件設(shè)計(jì)無關(guān)。而PDD提供了對(duì)硬件操作相應(yīng)的代碼。這些代碼通過結(jié)構(gòu)HWOBJ來相互聯(lián)系。對(duì)于MDD+PDD的整體驅(qū)動(dòng)來看，串口驅(qū)動(dòng)模型是作為Stream來實(shí)現(xiàn)的。 兩者合一以達(dá)到實(shí)現(xiàn)驅(qū)動(dòng)的目的。DDSI就是指這兩個(gè)部分之間的接口，這個(gè)接口并非受到強(qiáng)制的物理/邏輯關(guān)系來約束，而是人為的規(guī)定的。在涉及到一種特定硬件我們進(jìn)行針對(duì)實(shí)現(xiàn)的時(shí)候往往需要的是了解硬件的物理特性和控制邏輯，然后根據(jù)DDSI的約束就來進(jìn)行實(shí)現(xiàn)。對(duì)于這里描述的驅(qū)動(dòng)模型而言結(jié)合關(guān)鍵在于結(jié)構(gòu)指針HWOBJ的使用和具體實(shí)現(xiàn)。在實(shí)際的驅(qū)動(dòng)應(yīng)用中僅僅需要實(shí)現(xiàn)HWOBJ相關(guān)的一系列函數(shù)，而無需從驅(qū)動(dòng)頂層完全開發(fā)。串口驅(qū)動(dòng)模型作為一種常用驅(qū)動(dòng)模型在windowsCE中常常用于串口/紅外/USB Client的具體實(shí)現(xiàn)。該驅(qū)動(dòng)模型中對(duì)全功能的串口進(jìn)行了定義，除了常用的TX和RX引線定義以外，針對(duì)DTR、RTS等功能引腳都進(jìn)行了支持，使得用該模型設(shè)計(jì)的串口驅(qū)動(dòng)支持流控制、具備驅(qū)動(dòng)Modem等設(shè)備的能力。
　　事實(shí)上，如果需要的話完全可以將該驅(qū)動(dòng)一體化設(shè)計(jì)（拋開PDD-MDD的劃分，也就無須DDSI）。也就是不使用現(xiàn)有的驅(qū)動(dòng)架構(gòu)來進(jìn)行實(shí)現(xiàn)?？紤]到串口驅(qū)動(dòng)的使用頻率和執(zhí)行效率要求都不是很苛刻的情況下拋棄驅(qū)動(dòng)架構(gòu)另外實(shí)現(xiàn)的就沒有多大必要了。
　　對(duì)于驅(qū)動(dòng)本身而言，串行驅(qū)動(dòng)從功能和實(shí)現(xiàn)上相當(dāng)?shù)暮?jiǎn)單，確具被相當(dāng)全面的成分，對(duì)該驅(qū)動(dòng)的分析和了解無疑是學(xué)習(xí)流式驅(qū)動(dòng)程序很好的典范。
　　代碼分析
　　在開始具體代碼之前我們先來看看，相關(guān)的一些結(jié)構(gòu)。 HWOBJ是相應(yīng)的硬件設(shè)備操作的抽象集合。結(jié)構(gòu)的定義后的注釋與實(shí)際的用途有點(diǎn)點(diǎn)出入，BandFlags指定IST的啟動(dòng)時(shí)間，可選為在初始化過程啟動(dòng)或是在打開設(shè)備的時(shí)候起動(dòng)ISR.而第二個(gè)參數(shù)則是指定攔截的具體的系統(tǒng)中斷號(hào)。最后一個(gè)參數(shù)是一個(gè)結(jié)構(gòu)，該結(jié)構(gòu)定義了硬件操作的各式行為函數(shù)的指針，MDD正是通過這些函數(shù)來訪問具體的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則是代表具體硬件操作函數(shù)指針的集合，該結(jié)構(gòu)所指向的函數(shù)包括了初始化、打開、關(guān)閉、接收、發(fā)送、設(shè)置Baudrate等一系列操作。結(jié)構(gòu)存在就像紐帶一樣聯(lián)系著PDD中的具體實(shí)現(xiàn)和MDD中的抽象操作。PDD的實(shí)現(xiàn)必須遵循HW_VTBL中所描述的函數(shù)形式，并構(gòu)造出相應(yīng)的HW_VTBL實(shí)例。驅(qū)動(dòng)的編寫就是針對(duì)這些函數(shù)來一一進(jìn)行實(shí)現(xiàn)。