資料介紹
雖然串口通訊已經(jīng)是普遍的標準而且廣為大家熟知,但驅(qū)動中涉及的部分內(nèi)容也可能在平時的應用中并不是很常用到,在這里做一個簡單的介紹待后面說明到具體代碼的時候可以連貫一些。
串行通訊接口是目前十分流行的通訊接口之一。由于其電氣界面的簡單性使其在計算機領域的應用相當?shù)膹V泛。在這里提到的串行通訊接口主要是指UART(通用串行)和IRDA兩種。通常的串行連接電氣連接上有3wire和9wire兩種。3wire的接線方式下定義了發(fā)送、接收和地三根連接。其用途就如名稱一樣分別用于發(fā)送、接收。
通常在串行接口控制器上會有兩個FIFO用作接收和發(fā)送的緩沖,當接收到數(shù)據(jù)后會直接將接收到的數(shù)據(jù)置入該緩沖器,并同時由控制電路向本地總線發(fā)出通知,以便讓本地總線將緩沖器內(nèi)的數(shù)據(jù)讀走,這樣在響應(等待和讀取)的過程中仍然能通過緩沖器來接收數(shù)據(jù)。而發(fā)送發(fā)送的過程剛剛相反,本地總線可一直向發(fā)送緩沖寫入數(shù)據(jù)直到器填滿為止,而無需對每個數(shù)據(jù)的發(fā)送進行等待。這就是基本的收發(fā)流程(這部分邏輯流程相信大家是最熟悉的)。這一點在3wire和9wire中都是相同的。但是我們考慮下面的情況,如果接收一方的響應由于某種原因的干擾(如處理器被其他中斷服務占用)的時候可能就來不及相應之前ReceiveFIFO就可能被填滿了,這樣后續(xù)發(fā)送過來的數(shù)據(jù)就會丟失,這樣在需要數(shù)據(jù)可靠傳輸?shù)那闆r下串行通訊的弊端也就顯示出來了。如需要數(shù)據(jù)的可靠傳輸就需要對數(shù)據(jù)流的收發(fā)進行控制。在9wire中將串行連接定義為如下形式。
針號123456789
縮寫DCDRXDTXDDTRGNDDSRRTSCTSDELL
功能說明數(shù)據(jù)載波檢測接收數(shù)據(jù)發(fā)送數(shù)據(jù)數(shù)據(jù)終端就緒信號地數(shù)據(jù)設備就緒請求發(fā)送清除發(fā)送振鈴指示
也就是說在原3wire的基礎上增加了DCD,DTR,DSR,RTS,CTS,DELL六個控制線。其中RTS/CTS用于流控制,另外的DCD和DELL則留作連接modem使用。有了專門的硬件流控制引腳也就使得流控制成為可能,以完成收發(fā)兩端的匹配使得數(shù)據(jù)可以可靠的傳輸。用RTS/CTS(請求發(fā)送/清除發(fā)送)流控制時,應將通訊兩端的RTS、CTS線對應相連)。在發(fā)送端準備發(fā)送數(shù)據(jù)之前設置RTS(Request to send)也就使發(fā)送請求線,若接收端以作好接收準備,就啟動響應的CTS(Clear to send)引線。這樣,收發(fā)雙發(fā)就進入數(shù)據(jù)傳輸狀態(tài),在此過程中如若接收端處理數(shù)據(jù)的速度低于發(fā)送端的發(fā)送速度,接收一端還可以設置CTS引線恢復原來阻塞得狀態(tài)以暫時中斷數(shù)據(jù)傳輸,之后若需要恢復數(shù)據(jù)傳輸恢復CTS狀態(tài)即可。這樣UART的傳輸即實現(xiàn)了流控制,保障了數(shù)據(jù)傳輸?shù)耐陚湫浴?br /> 在這里還要說一下軟件流控制,雖然硬件已經(jīng)可以完成流控制的任務但很多少時候受到連線數(shù)的限制不能使用硬件流控制也就設計了專門的軟件流控制的方法。現(xiàn)在回到3線傳輸?shù)那榫埃艚邮斩私邮諗?shù)據(jù)過程中緩沖器的負載到達某一限制(也就是留出一定的緩沖空間)時接收端向發(fā)送端發(fā)送一個特殊的標示位(接收停止位),當發(fā)送端收到該標示的時候就停止發(fā)送,直到接收端緩沖器低于另一限制后發(fā)送標示(接收許可位)給發(fā)送端,這樣就可以控制數(shù)據(jù)流的傳輸起停。這種軟件流控制是在給緩沖器留余量來完成的,在收發(fā)雙端處理器速度差很大的時候就不太適用了,就必須要用硬件流控制。
其他幾個引腳都是與modem相關的,DSR數(shù)據(jù)裝置準備好(Data set ready)用于表明MODEM處于可以使用的狀態(tài)。DTR數(shù)據(jù)終端準備好(Data terminal ready)表明數(shù)據(jù)終端可以使用。這兩個信號用于檢查Modem是否連接。DELL腳當有電話撥入時Modem將會設置這個引腳。DCD信號是當Modem接收到數(shù)字載波信號的時候被設置,用于了解Modem接收信號的情況。
至于剩下的奇偶效驗和停止位設置就只是需要針對寄存器設置無需軟件干涉就可以完成了。下面我們來看具體的驅(qū)動程序。
架構
在wince中串口的驅(qū)動實現(xiàn)是有固定模型的,ce中的串口模型遵循ISO/OSI網(wǎng)絡通訊模型(7層),就是說串口屬于CE網(wǎng)絡模塊的一個部分。其中rs232界面(或其它的物理介質(zhì))實現(xiàn)網(wǎng)絡的物理層,而驅(qū)動和serialAPI共同組成數(shù)據(jù)鏈路層,其它部分都沒有做定義。在典型的應用中,serialAPI與間接通過TAPI或直接與ActiveSync交互,組成CE網(wǎng)絡的一部分。而紅外本身的協(xié)議就相對復雜的多,它有專門的一套模型來描述其使用規(guī)則,對紅外設備本身了解不多也就不能深入下去。在串口的這一側(cè),整個驅(qū)動模型也是相當?shù)膹碗s的,但所幸的是驅(qū)動僅僅使用到SerialAPI這一層,在這個層次上串口的行為還是相對簡單的。
我們這里僅僅涉及上面所提到的Serial/irda Driver這部分(綠色部分)。在wince提供的驅(qū)動例程中串口/紅外驅(qū)動采用分層結構設計,MDD提供框架性的實現(xiàn),負責提供OS所需的基本實現(xiàn),并將代碼設計與具體的硬件設計無關。而PDD提供了對硬件操作相應的代碼。這些代碼通過結構HWOBJ來相互聯(lián)系。對于MDD+PDD的整體驅(qū)動來看,串口驅(qū)動模型是作為Stream來實現(xiàn)的。 兩者合一以達到實現(xiàn)驅(qū)動的目的。DDSI就是指這兩個部分之間的接口,這個接口并非受到強制的物理/邏輯關系來約束,而是人為的規(guī)定的。在涉及到一種特定硬件我們進行針對實現(xiàn)的時候往往需要的是了解硬件的物理特性和控制邏輯,然后根據(jù)DDSI的約束就來進行實現(xiàn)。對于這里描述的驅(qū)動模型而言結合關鍵在于結構指針HWOBJ的使用和具體實現(xiàn)。在實際的驅(qū)動應用中僅僅需要實現(xiàn)HWOBJ相關的一系列函數(shù),而無需從驅(qū)動頂層完全開發(fā)。串口驅(qū)動模型作為一種常用驅(qū)動模型在windowsCE中常常用于串口/紅外/USB Client的具體實現(xiàn)。該驅(qū)動模型中對全功能的串口進行了定義,除了常用的TX和RX引線定義以外,針對DTR、RTS等功能引腳都進行了支持,使得用該模型設計的串口驅(qū)動支持流控制、具備驅(qū)動Modem等設備的能力。
事實上,如果需要的話完全可以將該驅(qū)動一體化設計(拋開PDD-MDD的劃分,也就無須DDSI)。也就是不使用現(xiàn)有的驅(qū)動架構來進行實現(xiàn)。考慮到串口驅(qū)動的使用頻率和執(zhí)行效率要求都不是很苛刻的情況下拋棄驅(qū)動架構另外實現(xiàn)的就沒有多大必要了。
對于驅(qū)動本身而言,串行驅(qū)動從功能和實現(xiàn)上相當?shù)暮唵危_具被相當全面的成分,對該驅(qū)動的分析和了解無疑是學習流式驅(qū)動程序很好的典范。
代碼分析
在開始具體代碼之前我們先來看看,相關的一些結構。 HWOBJ是相應的硬件設備操作的抽象集合。結構的定義后的注釋與實際的用途有點點出入,BandFlags指定IST的啟動時間,可選為在初始化過程啟動或是在打開設備的時候起動ISR.而第二個參數(shù)則是指定攔截的具體的系統(tǒng)中斷號。最后一個參數(shù)是一個結構,該結構定義了硬件操作的各式行為函數(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ù)指針的集合,該結構所指向的函數(shù)包括了初始化、打開、關閉、接收、發(fā)送、設置Baudrate等一系列操作。結構存在就像紐帶一樣聯(lián)系著PDD中的具體實現(xiàn)和MDD中的抽象操作。PDD的實現(xiàn)必須遵循HW_VTBL中所描述的函數(shù)形式,并構造出相應的HW_VTBL實例。驅(qū)動的編寫就是針對這些函數(shù)來一一進行實現(xiàn)。
串行通訊接口是目前十分流行的通訊接口之一。由于其電氣界面的簡單性使其在計算機領域的應用相當?shù)膹V泛。在這里提到的串行通訊接口主要是指UART(通用串行)和IRDA兩種。通常的串行連接電氣連接上有3wire和9wire兩種。3wire的接線方式下定義了發(fā)送、接收和地三根連接。其用途就如名稱一樣分別用于發(fā)送、接收。
通常在串行接口控制器上會有兩個FIFO用作接收和發(fā)送的緩沖,當接收到數(shù)據(jù)后會直接將接收到的數(shù)據(jù)置入該緩沖器,并同時由控制電路向本地總線發(fā)出通知,以便讓本地總線將緩沖器內(nèi)的數(shù)據(jù)讀走,這樣在響應(等待和讀取)的過程中仍然能通過緩沖器來接收數(shù)據(jù)。而發(fā)送發(fā)送的過程剛剛相反,本地總線可一直向發(fā)送緩沖寫入數(shù)據(jù)直到器填滿為止,而無需對每個數(shù)據(jù)的發(fā)送進行等待。這就是基本的收發(fā)流程(這部分邏輯流程相信大家是最熟悉的)。這一點在3wire和9wire中都是相同的。但是我們考慮下面的情況,如果接收一方的響應由于某種原因的干擾(如處理器被其他中斷服務占用)的時候可能就來不及相應之前ReceiveFIFO就可能被填滿了,這樣后續(xù)發(fā)送過來的數(shù)據(jù)就會丟失,這樣在需要數(shù)據(jù)可靠傳輸?shù)那闆r下串行通訊的弊端也就顯示出來了。如需要數(shù)據(jù)的可靠傳輸就需要對數(shù)據(jù)流的收發(fā)進行控制。在9wire中將串行連接定義為如下形式。
針號123456789
縮寫DCDRXDTXDDTRGNDDSRRTSCTSDELL
功能說明數(shù)據(jù)載波檢測接收數(shù)據(jù)發(fā)送數(shù)據(jù)數(shù)據(jù)終端就緒信號地數(shù)據(jù)設備就緒請求發(fā)送清除發(fā)送振鈴指示
也就是說在原3wire的基礎上增加了DCD,DTR,DSR,RTS,CTS,DELL六個控制線。其中RTS/CTS用于流控制,另外的DCD和DELL則留作連接modem使用。有了專門的硬件流控制引腳也就使得流控制成為可能,以完成收發(fā)兩端的匹配使得數(shù)據(jù)可以可靠的傳輸。用RTS/CTS(請求發(fā)送/清除發(fā)送)流控制時,應將通訊兩端的RTS、CTS線對應相連)。在發(fā)送端準備發(fā)送數(shù)據(jù)之前設置RTS(Request to send)也就使發(fā)送請求線,若接收端以作好接收準備,就啟動響應的CTS(Clear to send)引線。這樣,收發(fā)雙發(fā)就進入數(shù)據(jù)傳輸狀態(tài),在此過程中如若接收端處理數(shù)據(jù)的速度低于發(fā)送端的發(fā)送速度,接收一端還可以設置CTS引線恢復原來阻塞得狀態(tài)以暫時中斷數(shù)據(jù)傳輸,之后若需要恢復數(shù)據(jù)傳輸恢復CTS狀態(tài)即可。這樣UART的傳輸即實現(xiàn)了流控制,保障了數(shù)據(jù)傳輸?shù)耐陚湫浴?br /> 在這里還要說一下軟件流控制,雖然硬件已經(jīng)可以完成流控制的任務但很多少時候受到連線數(shù)的限制不能使用硬件流控制也就設計了專門的軟件流控制的方法。現(xiàn)在回到3線傳輸?shù)那榫埃艚邮斩私邮諗?shù)據(jù)過程中緩沖器的負載到達某一限制(也就是留出一定的緩沖空間)時接收端向發(fā)送端發(fā)送一個特殊的標示位(接收停止位),當發(fā)送端收到該標示的時候就停止發(fā)送,直到接收端緩沖器低于另一限制后發(fā)送標示(接收許可位)給發(fā)送端,這樣就可以控制數(shù)據(jù)流的傳輸起停。這種軟件流控制是在給緩沖器留余量來完成的,在收發(fā)雙端處理器速度差很大的時候就不太適用了,就必須要用硬件流控制。
其他幾個引腳都是與modem相關的,DSR數(shù)據(jù)裝置準備好(Data set ready)用于表明MODEM處于可以使用的狀態(tài)。DTR數(shù)據(jù)終端準備好(Data terminal ready)表明數(shù)據(jù)終端可以使用。這兩個信號用于檢查Modem是否連接。DELL腳當有電話撥入時Modem將會設置這個引腳。DCD信號是當Modem接收到數(shù)字載波信號的時候被設置,用于了解Modem接收信號的情況。
至于剩下的奇偶效驗和停止位設置就只是需要針對寄存器設置無需軟件干涉就可以完成了。下面我們來看具體的驅(qū)動程序。
架構
在wince中串口的驅(qū)動實現(xiàn)是有固定模型的,ce中的串口模型遵循ISO/OSI網(wǎng)絡通訊模型(7層),就是說串口屬于CE網(wǎng)絡模塊的一個部分。其中rs232界面(或其它的物理介質(zhì))實現(xiàn)網(wǎng)絡的物理層,而驅(qū)動和serialAPI共同組成數(shù)據(jù)鏈路層,其它部分都沒有做定義。在典型的應用中,serialAPI與間接通過TAPI或直接與ActiveSync交互,組成CE網(wǎng)絡的一部分。而紅外本身的協(xié)議就相對復雜的多,它有專門的一套模型來描述其使用規(guī)則,對紅外設備本身了解不多也就不能深入下去。在串口的這一側(cè),整個驅(qū)動模型也是相當?shù)膹碗s的,但所幸的是驅(qū)動僅僅使用到SerialAPI這一層,在這個層次上串口的行為還是相對簡單的。
我們這里僅僅涉及上面所提到的Serial/irda Driver這部分(綠色部分)。在wince提供的驅(qū)動例程中串口/紅外驅(qū)動采用分層結構設計,MDD提供框架性的實現(xiàn),負責提供OS所需的基本實現(xiàn),并將代碼設計與具體的硬件設計無關。而PDD提供了對硬件操作相應的代碼。這些代碼通過結構HWOBJ來相互聯(lián)系。對于MDD+PDD的整體驅(qū)動來看,串口驅(qū)動模型是作為Stream來實現(xiàn)的。 兩者合一以達到實現(xiàn)驅(qū)動的目的。DDSI就是指這兩個部分之間的接口,這個接口并非受到強制的物理/邏輯關系來約束,而是人為的規(guī)定的。在涉及到一種特定硬件我們進行針對實現(xiàn)的時候往往需要的是了解硬件的物理特性和控制邏輯,然后根據(jù)DDSI的約束就來進行實現(xiàn)。對于這里描述的驅(qū)動模型而言結合關鍵在于結構指針HWOBJ的使用和具體實現(xiàn)。在實際的驅(qū)動應用中僅僅需要實現(xiàn)HWOBJ相關的一系列函數(shù),而無需從驅(qū)動頂層完全開發(fā)。串口驅(qū)動模型作為一種常用驅(qū)動模型在windowsCE中常常用于串口/紅外/USB Client的具體實現(xiàn)。該驅(qū)動模型中對全功能的串口進行了定義,除了常用的TX和RX引線定義以外,針對DTR、RTS等功能引腳都進行了支持,使得用該模型設計的串口驅(qū)動支持流控制、具備驅(qū)動Modem等設備的能力。
事實上,如果需要的話完全可以將該驅(qū)動一體化設計(拋開PDD-MDD的劃分,也就無須DDSI)。也就是不使用現(xiàn)有的驅(qū)動架構來進行實現(xiàn)。考慮到串口驅(qū)動的使用頻率和執(zhí)行效率要求都不是很苛刻的情況下拋棄驅(qū)動架構另外實現(xiàn)的就沒有多大必要了。
對于驅(qū)動本身而言,串行驅(qū)動從功能和實現(xiàn)上相當?shù)暮唵危_具被相當全面的成分,對該驅(qū)動的分析和了解無疑是學習流式驅(qū)動程序很好的典范。
代碼分析
在開始具體代碼之前我們先來看看,相關的一些結構。 HWOBJ是相應的硬件設備操作的抽象集合。結構的定義后的注釋與實際的用途有點點出入,BandFlags指定IST的啟動時間,可選為在初始化過程啟動或是在打開設備的時候起動ISR.而第二個參數(shù)則是指定攔截的具體的系統(tǒng)中斷號。最后一個參數(shù)是一個結構,該結構定義了硬件操作的各式行為函數(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ù)指針的集合,該結構所指向的函數(shù)包括了初始化、打開、關閉、接收、發(fā)送、設置Baudrate等一系列操作。結構存在就像紐帶一樣聯(lián)系著PDD中的具體實現(xiàn)和MDD中的抽象操作。PDD的實現(xiàn)必須遵循HW_VTBL中所描述的函數(shù)形式,并構造出相應的HW_VTBL實例。驅(qū)動的編寫就是針對這些函數(shù)來一一進行實現(xiàn)。
下載該資料的人也在下載
下載該資料的人還在閱讀
更多 >
- 臺達串口DVP系列驅(qū)動如何使用?
- 基于WINCE的CAN總線設備驅(qū)動研究 6次下載
- 關于進程與線程的解析PDF文件資料
- 最詳盡的——解析串口通信數(shù)據(jù) 2次下載
- 基于WinCE_NET下串口驅(qū)動開發(fā)設計 3次下載
- WinCE環(huán)境下指紋識別設備驅(qū)動的設計和實現(xiàn) 3次下載
- WinCE流驅(qū)動程序設計概述 7次下載
- 基于WinCE通知API的解析及在控制程序中的應用 3次下載
- WinCE系統(tǒng)上大容量NANDFlash驅(qū)動設計與優(yōu)化 5次下載
- WinCE下PCI設備驅(qū)動程序的設計 65次下載
- 基于WinCE下光電編碼器的驅(qū)動程序設計 19次下載
- Wince_net下流接口驅(qū)動研究與實現(xiàn) 12次下載
- WinCE串口調(diào)試助手 11次下載
- WinCE NET下串口驅(qū)動開發(fā)設計
- 基于WINCE&ARM9的液晶屏驅(qū)動設計
- 串口驅(qū)動分析之serial driver 501次閱讀
- 嵌入式開發(fā):映射表在串口數(shù)據(jù)解析中的應用 472次閱讀
- C語言映射表在串口數(shù)據(jù)解析中的應用 500次閱讀
- HDF驅(qū)動框架中USB DDK的解析與開發(fā)指導 2259次閱讀
- 基于USB設備的接口驅(qū)動設計方法解析 1336次閱讀
- 英創(chuàng)信息技術WinCE主板接入3G網(wǎng)絡教程 1448次閱讀
- 盈鵬飛科技AM335X-Wince 7.0 BSP簡介 2981次閱讀
- 盈鵬飛科技at91sam9g45-Wince6.0 BSP簡介 2294次閱讀
- 盈鵬飛科技AM335x-Wince6.0 BSP簡介 2858次閱讀
- USB驅(qū)動開發(fā)的步驟及方法解析 1.1w次閱讀
- 基于STM32單片機的串口使用解析 5253次閱讀
- Apollo與GPS串口通信的數(shù)據(jù)格式 6531次閱讀
- WINCE車機平臺手機互聯(lián)使用說明 10.7w次閱讀
- Wince已死?智能化時代來臨Android稱霸市場? 1.1w次閱讀
- labview串口數(shù)據(jù)解析 5.8w次閱讀
下載排行
本周
- 1TC358743XBG評估板參考手冊
- 1.36 MB | 330次下載 | 免費
- 2開關電源基礎知識
- 5.73 MB | 6次下載 | 免費
- 3100W短波放大電路圖
- 0.05 MB | 4次下載 | 3 積分
- 4嵌入式linux-聊天程序設計
- 0.60 MB | 3次下載 | 免費
- 5基于FPGA的光纖通信系統(tǒng)的設計與實現(xiàn)
- 0.61 MB | 2次下載 | 免費
- 6基于FPGA的C8051F單片機開發(fā)板設計
- 0.70 MB | 2次下載 | 免費
- 751單片機窗簾控制器仿真程序
- 1.93 MB | 2次下載 | 免費
- 8基于51單片機的RGB調(diào)色燈程序仿真
- 0.86 MB | 2次下載 | 免費
本月
- 1OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 2555集成電路應用800例(新編版)
- 0.00 MB | 33564次下載 | 免費
- 3接口電路圖大全
- 未知 | 30323次下載 | 免費
- 4開關電源設計實例指南
- 未知 | 21548次下載 | 免費
- 5電氣工程師手冊免費下載(新編第二版pdf電子書)
- 0.00 MB | 15349次下載 | 免費
- 6數(shù)字電路基礎pdf(下載)
- 未知 | 13750次下載 | 免費
- 7電子制作實例集錦 下載
- 未知 | 8113次下載 | 免費
- 8《LED驅(qū)動電路設計》 溫德爾著
- 0.00 MB | 6653次下載 | 免費
總榜
- 1matlab軟件下載入口
- 未知 | 935054次下載 | 免費
- 2protel99se軟件下載(可英文版轉(zhuǎn)中文版)
- 78.1 MB | 537796次下載 | 免費
- 3MATLAB 7.1 下載 (含軟件介紹)
- 未知 | 420026次下載 | 免費
- 4OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 5Altium DXP2002下載入口
- 未知 | 233046次下載 | 免費
- 6電路仿真軟件multisim 10.0免費下載
- 340992 | 191185次下載 | 免費
- 7十天學會AVR單片機與C語言視頻教程 下載
- 158M | 183278次下載 | 免費
- 8proe5.0野火版下載(中文版免費下載)
- 未知 | 138040次下載 | 免費
評論