Win32 串口通訊編程四大方案深度解析

引言

在 32 位 Windows 環境下實現串口（COM 口）通訊，主要有四種技術路線，各有適用場景與優劣權衡。本文系統梳理這四種方案的核心 API、代碼骨架與選型建議。

方案一：以檔案方式打開串口（Win32 API 標準做法）

最通用、最推薦的方式。串口在 Windows 中視為檔案物件，使用 CreateFile、ReadFile、WriteFile 等標準 I/O API，支援同步/非同步（Overlapped I/O）模式。

關鍵步驟與代碼骨架

// 1. 開啟串口
HANDLE hComm = CreateFile(
    L"COM1",                       // 埠名
    GENERIC_READ | GENERIC_WRITE,  // 讀寫權限
    0,                             // 獨佔存取
    NULL,                          // 安全屬性
    OPEN_EXISTING,                 // 必須存在
    FILE_FLAG_OVERLAPPED,          // 非同步 I/O 關鍵旗標
    NULL);

if (hComm == INVALID_HANDLE_VALUE) { /* 錯誤處理 */ }

// 2. 設定通訊參數 (DCB 結構)
DCB dcb = {0};
dcb.DCBlength = sizeof(DCB);
GetCommState(hComm, &dcb);
dcb.BaudRate = CBR_115200;
dcb.ByteSize = 8;
dcb.Parity   = NOPARITY;
dcb.StopBits = ONESTOPBIT;
SetCommState(hComm, &dcb);

// 3. 設定逾時 (COMMTIMEOUTS)
COMMTIMEOUTS ct = {0};
ct.ReadIntervalTimeout = 50;
ct.ReadTotalTimeoutMultiplier = 10;
ct.ReadTotalTimeoutConstant = 1000;
SetCommTimeouts(hComm, &ct);

// 4. 非同步讀寫 (需 OVERLAPPED 結構 + 事件通知/完成埠)
OVERLAPPED ov = {0};
ov.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
WriteFile(hComm, buffer, len, &written, &ov);
ReadFile(hComm, buffer, len, &read, &ov);
// 配合 GetOverlappedResult / WaitForSingleObject / IOCP 完成

優缺點

• ✅ 系統原生支援，無額外依賴，BCB/VC/VS 通用。
• ✅ 完整控制流控、逾時、非同步模型，適合高可靠性工業應用。
• ❌ 代碼較繁瑣，需熟悉 DCB、COMMTIMEOUTS、OVERLAPPED 等結構。

方案二：使用現成 ActiveX 控件（MSComm / 第三方）

• 微軟 MSComm32.ocx 封裝了 Win32 API，提供事件驅動模型（OnComm），極大降低開發門檻。
• BCB/VC/VB 均可透過「匯入 ActiveX」直接拖放使用。
• ⚠️ 需隨應用程式部署 OCX 並註冊；64 位系統相容性需驗證；底層細節不可控。

方案三：內嵌組合語言直接操作埠（僅限 Win9x/實模式）

// BCB __fastcall 慣例：參數經由 EAX、EDX 傳遞
unsigned char __fastcall ReadByte(WORD port) {
    asm {
        mov dx, ax
        in  al, dx
    }
}
void __fastcall WriteByte(unsigned char val, WORD port) {
    asm {
        mov dx, ax
        out dx, al
    }
}

• ⚠️ Windows NT/2000/XP/7/10/11 全部禁止：Ring 3 應用程式無法直接執行 IN/OUT 指令，會觸發權限違規例外。
• ⚠️ 僅在 Win95/98/Me（非完整保護模式）下可行，現代系統完全不可用。

方案四：開發 VxD / Kernel 模式驅動（最高難度）

• 繞過 Ring 3 限制，在核心模式直接操作硬體，實現極低延遲、高吞吐、獨佔存取。
• 需深厚的核心開發功力（WDM/KMDF）、簽名驅動、測試簽名模式部署等工程成本極高。
• 除非極特殊需求（如高精度時序、硬體加密狗），一般應用強烈不建議。

選型決策表

實戰提示

1. 永遠檢查 CreateFile 回傳值，失敗時呼叫 GetLastError() 診斷（常見：埠被佔用、權限不足、名稱錯誤）。
2. 非同步 I/O 必須配合 OVERLAPPED.hEvent 或 I/O 完成埠，避免輪詢浪費 CPU。
3. 嚴謹處理 ClearCommError 回傳的錯誤碼（溢位、幀錯、奇偶校驗錯）。
4. 關閉埠前呼叫 PurgeComm 清空緩衝區，再 CloseHandle。

總結

現代 Windows 串口開發首選方案一，掌握 Win32 非同步 I/O 模型是核心競爭力；方案二適合快速交付；方案三已成歷史；方案四留給驅動開發專家。理解四者邊界，才能在專案中做出最合理的架構決策。