串行通訊接口是目前十分流行的通訊接口之一,串口通訊也已是普遍的標準而被大家廣為熟悉。
基本架構
在WinCE中,串口的驅(qū)動實現(xiàn)是有固定模型的,其串口模型遵循ISO/OSI網(wǎng)絡通訊模型。在典型的應用中,serialAPI與間接通過TAPI或直接與ActiveSync交互,組成CE網(wǎng)絡的一部分。其實整個驅(qū)動模型是相當復雜的,好在驅(qū)動僅僅使用到SerialAPI這一層,在這個層次上串口的行為相對比較簡單。在WinCE中,串口驅(qū)動模型是作為Stream來實現(xiàn)的(即:流設備驅(qū)動),其架構如圖所示:
串口驅(qū)動本身分為MDD層和PDD層。
MDD提供框架性的實現(xiàn),負責提供OS所需的基本實現(xiàn),它對上層的設備管理器,提供了標準的流設備驅(qū)動接口(COM_xxx);而PDD提供了對硬件操作相應的代碼,它實現(xiàn)了HWOBJ結構及結構中若干針對于串口硬件操作的函數(shù)指針。
DDSI是指MDD與PDD兩個部分之間的接口,這個接口是人為的規(guī)定的,在串口驅(qū)動中實際上就是指HWOBJ,PDD層會傳給MDD層一個HWOBJ的結構指針,這樣MDD層就可以調(diào)用PDD層的函數(shù)來操作串口。在實際的驅(qū)動應用中僅僅需要實現(xiàn)HWOBJ相關的一系列函數(shù),而無需從驅(qū)動頂層完全開發(fā)。
通常的串行連接有3wire和9wire兩種。3wire的接線方式下定義了發(fā)送、接收和地三根連接。而在9wire中將串行連接定義為如下形式。
針號 |
1 |
2 |
3 |
4 |
[!--empirenews.page--]5 |
6 |
7 |
8 |
9 |
縮寫 |
DCD |
RXD |
TXD |
DTR |
GND |
DSR |
RTS |
CTS |
DELL |
功能說明 |
數(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ù)可以可靠的傳輸,即實現(xiàn)了流控制,保障了數(shù)據(jù)傳輸?shù)耐陚湫浴?/p>
其他幾個引腳都是與modem相關的,DSR數(shù)據(jù)裝置準備好用于表明MODEM處于可以使用的狀態(tài)。
函數(shù)分析
1、HWOBJ
HWOBJ是相應的硬件設備操作的抽象集合,實現(xiàn)了對串口硬件的操作,并在MDD層被調(diào)用。
typedef struct __HWOBJ {
ULONG BindFlags;.
DWORD dwIntID;
PHW_VTBL pFuncTbl;
} HWOBJ, *PHWOBJ;
其中,BandFlags用于控制MDD層指定IST的啟動時間,MDD正是通過這些函數(shù)來訪問具體的PDD操作。
dwInitID是系統(tǒng)的中斷號。
pFuncTbl則是指向一個PHW_VTBL結構,該結構中包含一個函數(shù)指針列表,這些函數(shù)指針指向串口硬件操作函數(shù),用于操作串口。
2、MDD
MDD層向上提供了流設備接口,用于管理串口,由Device.exe直接調(diào)用。
? COM_Init (ULONG Identifier):
它是該驅(qū)動的初始化函數(shù),通過硬件抽象接口HWInit初始化硬件。如果驅(qū)動被設備管理器加載,參數(shù)Identifier包含一個注冊表鍵值在“HKEY_LOCAL_MACHINE\Drivers\Active”的路徑下。
? COM_Deinit(void):
當驅(qū)動被稱被卸下的時候該事件啟動,用作與COM_Init相反的操作。停止在MDD中的所有IST,釋放內(nèi)存資源和臨界區(qū)等系統(tǒng)資源。
? COM_Open(HANDLE pContext, DWORD AccessCode, DWORD ShareMode):
COM_Oepn在CreateFile后被調(diào)用,用于以讀/寫模式打開設備,并初始化所需要的空間/資源等,創(chuàng)建相應的實例。Open操作完成后,驅(qū)動就進入了工作狀態(tài)。
? COM_Close(DWORD pContext):
COM_Close釋放COM_Open所使用的系統(tǒng)資源,停止IST線程,恢復驅(qū)動狀態(tài)。
? COM_Read(HANDLE pContext, PUCHAR pTargetBuffer,
ULONG BufferLength, PULONG pBytesRead):
COM_Read是獲取串口所接收到數(shù)據(jù)的操作,在前面的IST中沒有看到對RX buffer進行修改Read標記的操作,也就是這兒來完成的。
? COM_Write(HANDLE pContext, PUCHAR pSourceBytes,
ULONG NumberOfBytes):
COM_Write是與COM_Read相對應的操作,是寫串口數(shù)據(jù)的。應用程序調(diào)用WriteFile函數(shù)寫串口的時候,該函數(shù)被調(diào)用。在程序的開始,同樣也是參數(shù)檢查,內(nèi)容與COM_Read一致。其中pContext參數(shù)是COM_Open函數(shù)返回的Handle。pSourceBytes指向一個Buffer,該Buffer包含要寫入串口的數(shù)據(jù)。NumberOfBytes表示要寫入串口的數(shù)據(jù)的大小。
? COM_PowerUp/ COM_PowerDown (HANDLE pContext):
這兩個函數(shù)的調(diào)用都由CE的電源事件來引發(fā),MDD并沒有對這兩個函數(shù)進行處理,僅僅是將其傳遞給PDD。
? COM_IOControl (DWORD dwOpenData, DWORD dwCode, PBYTE pBufIn, DOWRD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut):
該函數(shù)主要實現(xiàn)了一些串口的IO控制,他會被應用層的一些串口函數(shù)調(diào)用來獲得或者設置串口的狀態(tài)。
3、PDD
實際上,在PDD層的主要工作就2個:一是控制硬件;二是和上層打好關系。先說上層接口,上層用了GetSerialHead()來獲得接口,所以PDD里面要實現(xiàn)GetSerialHead()的函數(shù),并且將接口返回給上層。
GetSerialObject( DWORD DeviceArrayIndex )
{
PHWOBJ pSerObj;
pSerObj=(PHWOBJ)LocalAlloc( LPTR ,sizeof(HWOBJ) );
if ( !pSerObj )
return (NULL);
pSerObj->BindFlags = THREAD_IN_PDD;
pSerObj->dwIntID = DeviceArrayIndex;
pSerObj->pFuncTbl = (HW_VTBL *) & IoVTbl;
return (pSerObj);
}
PDD層的函數(shù)主要是實現(xiàn)了對串口硬件的操作,函數(shù)不少,可以參考以下列表:
序號 |
函數(shù)[!--empirenews.page--] |
說明 |
1 |
GetSerialObject |
返回一個指向HWOBJ結構的指針,該結構包含了相關硬件接口函數(shù)的函數(shù)指針 |
2 |
HWClearBreak |
清除串口中斷狀態(tài),用于串口從中斷狀態(tài)恢復 |
3 |
HWClearDTR |
設置串口的DTR管腳為低 |
4 |
HWClearRTS |
設置串口的RTS管腳為低 |
5 |
HWClose |
關閉由HWInit函數(shù)初始化的設備 |
6 |
HWDisableIR |
禁用串口的紅外模式 |
7 |
HWEnableIR |
啟用串口的紅外模式 |
8 |
HWGetCommProperties |
重新獲得當前串口設備的硬件屬性 |
9 |
HWGetIntrType |
獲得當前的中斷類型 |
10 |
HWGetModemStatus |
獲得Modem的狀態(tài) |
11 |
HWGetRxBufferSize |
獲得串口硬件接收Buffer的大小 |
12 |
HWGetRxStart |
返回硬件接收Buffer的起始位置 |
13 |
HWGetStatus |
獲得硬件狀態(tài)信息 |
14 |
HWInit |
初始化串口硬件設備 |
15 |
HWIoctl |
執(zhí)行I/O控制 |
16 |
HWLineIntrHandler |
線路狀態(tài)信息中斷處理函數(shù) |
17 |
HWOpen |
打開串口設備 |
18 |
HWPowerOff |
串口硬件進入Suspend模式 |
19 |
HWPowerOn |
串口硬件從Suspend模式恢復到工作模式 |
20 |
HWSetDCB |
設置串口硬件設備信息 |
21 |
HWSetDTR |
設置串口的DTR管腳為高 |
22 |
HWSetRTS |
設置串口的RTS管腳為高 |
23 |
HWPurgeComm |
清除串口硬件buffer的信息 |
24 |
HWPutBytes |
通過寫數(shù)據(jù)到硬件中來直接發(fā)送數(shù)據(jù) |
25 |
HWReset |
復位串口硬件 |
26 |
HWRxIntrHandler |
接收數(shù)據(jù)中斷處理函數(shù) |
27 |
HWSetBreak |
設置串口為中斷狀態(tài),停止發(fā)送接收數(shù)據(jù) |
28 |
HWTxIntrHandler |
串口發(fā)送中斷處理函數(shù) |
非獨占式串口驅(qū)動
用過串口進行過開發(fā)的兄弟們都知道,串口驅(qū)動是一個典型的獨占設備。簡單點來說,就是在成功地調(diào)用CreateFile打開串口之后,沒有通過CloseHandle進行關閉,是無論如何都不能再次調(diào)用CreateFile來再次打開相同的串口,這樣做可以避免產(chǎn)生數(shù)據(jù)丟失,也避免獲取數(shù)據(jù)的線程是反復讀取。
但是現(xiàn)在的嵌入式設備功能都非常多,需要非獨占式串口驅(qū)動,也就是虛擬串口驅(qū)動。它主要是處理數(shù)據(jù)的分發(fā),可以和具體的硬件分開,優(yōu)勢也很明顯,可以不用理會具體的硬件規(guī)格,只要采用的是WinCE系統(tǒng),虛擬串口驅(qū)動就能正常工作。
在設計驅(qū)動的時候需要注意,同一時間只能有一個進程對外輸出數(shù)據(jù),其余進程只能在該進程輸出完畢之后才能進行。當然,程序不應該主動調(diào)用ReadFile來輪詢獲取數(shù)據(jù),而是通過WaitCommEvent進行檢測。為了不丟失數(shù)據(jù),緩沖大小一定要等于或大于READ_BUFFER_LENGTH。
在寫代碼的時候需要注意一點,WaitCommEvent函數(shù)只能被一個線程調(diào)用,同一時間只有唯一的一個線程通過WaitCommEvent函數(shù)進入等待狀態(tài)。因此對于IOCTL_SERIAL_WAIT_ON_MASK控制碼的處理,可以通過調(diào)用WaitForSingleObject進行線程等待。這時虛擬串口驅(qū)動會額外開放一個線程,該線程主要是通過調(diào)用WaitCommEvent來獲取原生串口的狀態(tài),當狀態(tài)有通知時,再發(fā)送event給等待的線程。
switch(xxxx){
...
case IOCTL_SERIAL_WAIT_ON_MASK:
{ if(dwBufOutSize < sizeof(DWORD) ||
WaitForSingleObject(g_hEventComm,INFINITE) == WAIT_TIMEOUT)
{ *pBytesReturned = 0;
return FALSE;
} else {
InterlockedExchange(reinterpret_cast
*pBytesReturned = sizeof(DWORD);
return TRUE;
}
}...
多串口擴展
在WinCE應用環(huán)境中,對擴展的多串口的編程方法,實際上與標準的串口應用程序完全一樣。[!--empirenews.page--]
注意在打開串口號大于9的串口時,需要使用“\\$device\\COMxx”,而不是通常的“COMx:”。
考慮到共享中斷的異步特性,各個串口可能同時請求中斷,從而產(chǎn)生極高的中斷頻率,所以建議客戶把低波特率的串口通道,如9600bps或以下的波特率,配置在擴展串口上,以均衡CPU對各個硬件設備的開銷;相應地把需要使用高波特率的通道配置到嵌入式主板自帶的串口通道上,比如:EM9360的COM2-COM7,這些串口均配置有獨立的硬件中斷。
在WinCE標準的串口驅(qū)動程序中,為每個串口分配了2KB的接收數(shù)據(jù)緩沖區(qū),所以各個串口上層處理線程可參考buffer的深度,采用合適的響應方式,以最大限度的避免線程空轉(zhuǎn)所帶來的CPU時間的無謂消耗。
WinCE下的驅(qū)動開發(fā)減少了開發(fā)者的工作量,不過其中還存在很多細節(jié)性的問題,動手實踐中就能慢慢體會到了。