本文不是全面的講述如何編寫(xiě)串行通訊程序，而是討論一些實(shí)際遇到的問(wèn)題。
1 選擇通訊方式 -- 同步還是非同步
正如在《Serial communications in Microsoft Win32》等文章中提到的，同步（NonOverLapped）方式是比較簡(jiǎn)單的一種方式，編寫(xiě)起來(lái)代碼的長(cháng)度要明顯少于異步（OverLapped）方式，我開(kāi)始用同步方式編寫(xiě)了整個(gè)子程序，在 Windows98 下工作正常，但后來(lái)在 Windows2000下測試，發(fā)現接收正常，但一發(fā)送數據，程序就會(huì )停在那里，原因應該在于同步方式下如果有一個(gè)通訊 Api 在操作中，另一個(gè)會(huì )阻塞直到上一個(gè)操作完成，所以當讀數據的線(xiàn)程停留在 WaitCommEvent 的時(shí)候，WriteFile 就停在那里。我又測試了我手上所有有關(guān)串行通訊的例子程序，發(fā)現所有使用同步方式的程序在 Windows 2000 下全部工作不正常，對這個(gè)問(wèn)題我一直找不到解決的辦法，后來(lái)在 Iczelion 站點(diǎn)上發(fā)現一篇文章提到 NT 下對串行通訊的處理和 9x 有些不同，根本不要指望在 NT 或 Windows 2000 下用同步方式同時(shí)收發(fā)數據，我只好又用異步方式把整個(gè)通訊子程序重新寫(xiě)了一遍。
所以對于這個(gè)問(wèn)題的建議是：如果程序只打算工作在 Win9x 下，為了簡(jiǎn)單起見(jiàn)，可以用同步方式寫(xiě)程序，如果程序打算在 NT 下也可以工作的話(huà)，就必須用異步方式寫(xiě)。
2 Win32 通訊 API Bug 之一 --- CommConfigDialog
CommConfigDialog 是彈出系統內置串口設置對話(huà)框的 API，我們在設備管理器中設置串口參數的對話(huà)框就是這個(gè)，使用這個(gè) API 時(shí)不用先打開(kāi)端口，它并不針對一個(gè)已打開(kāi)的端口，而是僅僅是把 DCB 的內容填寫(xiě)到對話(huà)框中，當按了 OK 后把輸入的結果存回到 DCB 數據結構中，至于什么時(shí)候把結果設置到串口上，那就是你自己要做的事情了。
CommCinfigDialog 的定義如下：
BOOL CommConfigDialog(
LPTSTR lpszName, // pointer to device name string
HWND hWnd, // handle to window
LPCOMMCONFIG lpCC // pointer to comm. configuration structure
);
但在使用中發(fā)現，對話(huà)框有時(shí)能出來(lái)，有時(shí)出不來(lái)，最后總結的經(jīng)驗是問(wèn)題出在 COMMCONFIG 結構的 dwSize 字段上，COMMCONFIG 的定義如下：
typedef struct _COMM_CONFIG {
DWORD dwSize;
WORD wVersion;
WORD wReserved;
DCB dcb;
DWORD dwProviderSubType;
DWORD dwProviderOffset;
DWORD dwProviderSize;
WCHAR wcProviderData[1];
} COMMCONFIG, *LPCOMMCONFIG;
在參數中，wVersion 要填 100h，dwProviderSubType 要填 1，但 dwSize 就不能填 sizeof COMMCONFIG 了，我發(fā)現好象一定要把 dwSize 設置為比 sizeof COMMCONFIG 對話(huà)框才能出來(lái)，所以我用的代碼中定義了一個(gè)足夠大的緩沖區作為結構的地址：
_CommConfigDialog proc
local @stCC[256]:BYTE
pushad
invoke RtlZeroMemory,addr @stCC,sizeof @stCC
mov (COMMCONFIG ptr @stCC).dwSize,256
mov (COMMCONFIG ptr @stCC).wVersion,100h
mov (COMMCONFIG ptr @stCC).dwProviderSubType,1
invoke CommConfigDialog,addr [esi].szPortName,[esi].hWnd,addr @stCC
popad
ret
_CommConfigDialog endp
3 Win32 通訊 API Bug 之二--- BuildCommDCB
BuildCommDCB 的功能是把一個(gè)字符串如 com1:9600,n,8,1 這樣的轉換到具體的數據填寫(xiě)到 DCB 中，但使用中也存在問(wèn)題，我發(fā)現我用它轉換象 com1:9600,e,7,1 之類(lèi)的帶校驗位的字符串，它總是無(wú)法把這個(gè) e 給我轉換過(guò)去，設置好串口一看，成了 9600,n,7,1，而上面提到的 CommConfigDialog 返回的結果用來(lái)設置串口卻是正確的，經(jīng)過(guò)比較，發(fā)現問(wèn)題出在 DCB.fbits.fParity 這個(gè) bit 上，只有把這個(gè) bit 置 1，校驗位才是有效的，而 BuildCommDCB 恰恰是漏了這個(gè) bit，所有如果你要使用 BuildCommDCB，別忘了補充把 DCB.fbits.fParity 設置回去，我用的代碼是：
_BuildCommDCB proc _lpszPara,_lpstDCB
pushad
mov esi,_lpstDCB
assume esi:ptr DCB
invoke RtlZeroMemory,esi,sizeof DCB
invoke BuildCommDCB,_lpszPara,esi
;********************************************************************
; 根據校驗位補充設置 DCB 中的 DCB.fbits.fParity 字段
;********************************************************************
mov dword ptr [esi].fbits,0010b
cld
@@:
lodsb
or al,al
jz @F
cmp al,‘=‘
jz _BCD_Check
cmp al,‘,‘
jnz @B
_BCD_Check:
lodsb
or al,al
jz @F
or al,20h
cmp al,‘n‘
jnz @B
;********************************************************************
; 掃描到 =n 或 ,n 則取消校驗位
;********************************************************************
mov esi,_lpstDCB
and dword ptr [esi].fbits,not 0010b
@@:
popad
ret
_BuildCommDCB endp
4 Win32 通訊編程的一般流程
由于同步方式相對比較簡(jiǎn)單，在這里講述的是異步方式的流程，在其他的很多文章里提到了 Windows 通訊 API 有二十多個(gè)，它們是：
BuildCommDCB
BuildCommDCBAndTimeouts
ClearCommBreak
ClearCommError
CommConfigDialog
EscapeCommFunction
GetCommConfig
GetCommMask
GetCommModemStatus
GetCommProperties
GetCommState
GetCommTimeouts
GetDefaultCommConfig
PurgeComm
SetCommBreak
SetCommConfig
SetCommMask
SetCommState
SetCommTimeouts
SetDefaultCommConfig
SetupComm
TransmitCommChar
WaitCommEvent
我剛看到這些 API 的時(shí)候，都不知道如何使用它們，但并不是所有這些 API 都是必須用的，比如說(shuō)你要檢測當前串口的設置可以只用 SetCommState 而不用 GetCommProperties 和 GetCommConfig，雖然它們返回的信息可能更多。同樣，如果有些值你想用缺省的，比如緩沖區的大小和超時(shí)的時(shí)間等等，那么 SetupComm 和 BuildCommDCBAndTimeouts、SetCommTimeouts 也可以不用，TransmitCommChar 是馬上在發(fā)送序列中優(yōu)先插入發(fā)送一個(gè)字符用的，平時(shí)也很少用到，下面講的是必須用到的 API 和使用步驟：
建立 Event -- 用 CreateEvent
invoke CreateEvent,NULL,TRUE,FALSE,NULL
用異步方式操作串口必須要定義 OVERLAPPED 結構，其中的 hEvent 必須自己建立，你要定義兩個(gè) OVERLAPPED 結構，一個(gè)用于讀一個(gè)用于寫(xiě)，當然也必須建立兩個(gè) Event，把它們放入 OVERLAPPED.hEvent
打開(kāi)串口 -- 用 CreateFile
invoke CreateFile,addr szPortName,GENERIC_READ or GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL
注意用異步方式必須指定 FILE_FLAG_OVERLAPPED，而文件方式必須 OPEN_EXISTING，讀寫(xiě)必須是 GENERIC_READ or GENERIC_WRITE
設置串口參數 -- 用 SetCommState
invoke SetCommState,hCom,addr dcbx
hCom 是前面打開(kāi)成功后返回的句柄，dcbx 是數據結構 DCB，里面包括了通訊的具體參數，至于這個(gè)參數的建立，你可以自己填寫(xiě)，也可以用前面提到的 BuildCommDCB 或 CommConfigDialog 填寫(xiě)
建立讀數據的線(xiàn)程
到這里，就可以開(kāi)始讀數據了，一般我們是在主線(xiàn)程中寫(xiě)數據，因為寫(xiě)是我們可以控制的，而讀的時(shí)候我們不知道數據什么時(shí)候會(huì )到，所以要建立一個(gè)線(xiàn)程專(zhuān)門(mén)用來(lái)讀數據，在這個(gè)線(xiàn)程中，我們循環(huán)地用 ReadFile 讀串口，同時(shí)用 WaitCommEvent 檢測線(xiàn)路狀態(tài)。
如果要檢測通訊狀態(tài)，如 CTS 信號，RingIn 等等 -- 用 SetCommMask、WaitCommEvent、ClearCommError、GetCommModemStatus
invoke SetCommMask,hCom,EV_BREAK or EV_CTS or EV_DSR or EV_ERR or EV_RING or EV_RLSD or EV_RXCHAR or EV_RXFLAG or EV_TXEMPTY
SetCommMask 指定 WaitCommEvent 要等待的事件名稱(chēng)，具體的參數請查手冊
invoke WaitCommEvent,hCom,addr dwEvent,NULL
WaitCommEvent 等待一直到 SetCommMask 指定事件之一發(fā)生
invoke ClearCommError,hCom,addr dwError,addr stComStat
在 WaitCommEvent 以后，要用 ClearCommError 清除事件的 Flag，以便進(jìn)行下一輪 WaitCommEvent，同時(shí)這個(gè) API 可以獲得更詳細的事件信息
invoke GetCommModemStatus,hCom,addr dwModemStatus
同樣，GetCommModemStatus 是用來(lái)獲得串口線(xiàn)路狀態(tài)的，如 CTS、RING 等等，當 WaitCommEvent 返回時(shí)，只是指出了如 CTS 等等狀態(tài)有變化，但具體是變成 On 還是 Off 了還要靠這個(gè) API 去取得更詳細的信息
讀數據 -- 用 ReadFile
invoke ReadFile,hCom,addr szBuffer,sizeof szBuffer,addr dwBytesRead,addr stReadState
最后一個(gè)參數是開(kāi)頭定義的 OVERLAPPED 結構的地址，指定了它就表示是用異步方式的讀方式，這個(gè) API 會(huì )馬上返回，接下去要用
invoke GetOverlappedResult,hCom,addr stReadState,addr dwBytesRead,FALSE
將其余的數據讀完
結束時(shí)關(guān)閉端口 -- 停止 WaitCommEvent 的等待以及關(guān)閉端口 CloseHandle
平時(shí)程序會(huì )停留在 WaitCommEvent 的等待中，當要終止線(xiàn)程的時(shí)候，必須是程序從 WaitCommEvent 中退出來(lái)，這時(shí)候要用
按照 Win32 手冊上的說(shuō)明，參數為 NULL 的 SetCommMask 會(huì )使另一個(gè)線(xiàn)程中的 WaitCommEvent 馬上返回，然后就是用 CloseHandle 關(guān)閉端口
invoke CloseHandle,hCom
5 Win32 通訊 API Bug 之二--- SetCommMask 和 WaitCommEvent
嚴格的說(shuō)這不應該是 Bug，而是偶然的情況，我發(fā)現有些時(shí)候我的讀線(xiàn)程無(wú)法結束，跟蹤發(fā)現是停在了 WaitCommEvent 上，這說(shuō)明有時(shí)候 invoke SetCommMask,hCom,NULL 并不能使 WaitCommEvent 退出，我最后使用的辦法是： 在 SetCommMask 以后再執行 invoke SetEvent,stReadState.hEvent，把讀的 OVERLAPPED 結構中的 Event 置位，讓 WaitCommEvent 認為有 Event 發(fā)生，它就會(huì )馬上返回，也許這并不是普遍的情況，但如果你的程序也是停在了 WaitCommEvent 的地方，不妨一試。
6 如何編寫(xiě)讀線(xiàn)程中的循環(huán)
按照
《Serial communications in Microsoft Win32》一文中的例程，讀循環(huán)可以用：
#define READ_TIMEOUT 500 // milliseconds
DWORD dwRes;
DWORD dwRead;
BOOL fWaitingOnRead = FALSE;
OVERLAPPED osReader = {0};
// Create the overlapped event. Must be closed before exiting
// to avoid a handle leak.
osReader.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if (osReader.hEvent == NULL)
// Error creating overlapped event; abort.
if (!fWaitingOnRead) {
// Issue read operation.
if (!ReadFile(hComm, lpBuf, READ_BUF_SIZE, &dwRead, &osReader)) {
if (GetLastError() != ERROR_IO_PENDING) // read not delayed?
// Error in communications; report it.
else
fWaitingOnRead = TRUE;
}
else {
// read completed immediately
HandleASuccessfulRead(lpBuf, dwRead);
}
}
if (fWaitingOnRead) {
dwRes = WaitForSingleObject(osReader.hEvent, READ_TIMEOUT);
switch(dwRes)
{
// Read completed.
case WAIT_OBJECT_0:
if (!GetOverlappedResult(hComm, &osReader, &dwRead, FALSE))
// Error in communications; report it.
else
// Read completed successfully.
HandleASuccessfulRead(lpBuf, dwRead);
// Reset flag so that another opertion can be issued.
fWaitingOnRead = FALSE;
break;
case WAIT_TIMEOUT:
// Operation isn‘t complete yet. fWaitingOnRead flag isn‘t
// changed since I‘ll loop back around, and I don‘t want
// to issue another read until the first one finishes.
//
// This is a good time to do some background work.
break;
default:
// Error in the WaitForSingleObject; abort.
// This indicates a problem with the OVERLAPPED structure‘s
// event handle.
break;
}
}
這一段程序在 98 下正常，但非常不幸的是在 Win2000 下，ReadFile 總是返回讀正確，并不返回 ERROR_IO_PENDING，使下面的 WaitForSingleObject 的循環(huán)形同虛設，要命的是，ReadFile 返回讀正確卻每次只讀一個(gè)字節，結果程序工作得很奇怪，即使緩沖區中有很多的字符，程序也每次只能讀一個(gè)字符，要等到發(fā)送字符或做其他的操作使線(xiàn)路狀態(tài)改變了，才能讀下一個(gè)字符，我不知道這個(gè)奇怪的現象是如何發(fā)生的，反正我解決的辦法是在 ReadFile 前加 WaitCommEvent，真正等到 EV_RXCHAR 以后才去 ReadFile，到最后，我用的循環(huán)是這樣的，雖然沒(méi)有一篇文章中的例子是這樣的，但它卻同時(shí)在 windows9x 和 windows2000 下工作得很好：
.while dwFlag & IF_CONNECT
;********************************************************************
; 檢測其它的通信事件
; 如果檢測到且定義了 lpProcessEvent 則調用 lpProcessEvent
;********************************************************************
invoke WaitCommEvent,hCom,addr @dwEvent,NULL ;addr stReadState
push eax
invoke ClearCommError,hCom,addr @dwError,addr @stComStat
pop eax
.if eax == 0
invoke GetLastError
.if eax == ERROR_IO_PENDING
or dwFlag,IF_WAITING
.endif
.else
;這里是線(xiàn)路狀態(tài)的處理
.endif
;********************************************************************
; 如果沒(méi)有在等待異步讀的過(guò)程中，則讀端口
;********************************************************************
.if ! (dwFlag & IF_WAITING)
mov @dwBytesRead,0
invoke ReadFile,hCom,addr @szBuffer,sizeof @szBuffer,\
addr @dwBytesRead,addr stReadState
.if eax == FALSE
or dwFlag,IF_WAITING
invoke GetLastError
.if eax != ERROR_IO_PENDING
;這里是錯誤處理
.endif
.else
and dwFlag,not IF_WAITING
mov eax,@dwBytesRead
.if eax != 0
;這里是接收到的數據處理
.endif
.endif
.endif
;********************************************************************
; 如果在異步讀端口中，則等待一段時(shí)間
;********************************************************************
.if dwFlag & IF_WAITING
invoke WaitForSingleObject,stReadState.hEvent,200
.if eax == WAIT_OBJECT_0
and dwFlag,not IF_WAITING
invoke GetOverlappedResult,hCom,addr stReadState,\
addr @dwBytesRead,FALSE
.if eax != 0
mov eax,@dwBytesRead
.if eax != 0
;這里是接收到的數據處理
.endif
.else
;這里是錯誤處理
invoke ClearCommError,hCom,addr @dwError,addr @stComStat
.endif
.else
;這里是錯誤處理
.endif
.endif
.endw
7 流控制的問(wèn)題
在流控制方式為“無(wú)”和“軟件控制”的情況下，基本上沒(méi)有什么問(wèn)題，但在“硬件控制”下，win32 手冊中說(shuō)明 RTS_CONTROL_HANDSHAKE 控制方式的含義是：
Enables RTS handshaking. The driver raises the RTS line when the "type-ahead" (input) buffer is less than one-half full and lowers the RTS line when the buffer is more than three-quarters full. If handshaking is enabled, it is an error for the application to adjust the line by using the EscapeCommFunction function.
也就是說(shuō)，當緩沖區快滿(mǎn)的時(shí)候 RTS 會(huì )自動(dòng) OFF 通知對方暫停發(fā)送，當緩沖區重新空出來(lái)的時(shí)候， RTS 會(huì )自動(dòng) ON，但我發(fā)現當 RTS 變 OFF 以后即使你已經(jīng)清空了緩沖區， RTS 也不會(huì )自動(dòng)的 ON，造成對方停在那里不發(fā)送了，所以，如果要用硬件流控制的話(huà)，還要在接收后最好加上檢測緩沖區大小的判斷，具體是使用 ClearCommError 后返回的 COMSTAT.cbInQue，當緩沖區已經(jīng)空出來(lái)的時(shí)候，要使用 invoke EscapeCommFunction,hCom,SETRTS 重新將 RTS 設置為 ON。
