發(fā)串口調(diào)試助手ComTest:從串口通信原理到實(shí)戰(zhàn))
簡(jiǎn)介ComTest串口調(diào)試工具是一份基于VC實(shí)現(xiàn)的串口通信示例程序面向硬件調(diào)試、嵌入式開(kāi)發(fā)和物聯(lián)網(wǎng)設(shè)備測(cè)試人員也適合初學(xué)Win32串口編程的讀者。資源包共18個(gè)文件以h頭文件和cpp源文件為主并包含rc資源腳本、ico圖標(biāo)及工程配置文件可完整還原一個(gè)基于對(duì)話框的MFC串口調(diào)試助手。用戶可通過(guò)界面完成串口打開(kāi)、參數(shù)設(shè)置、數(shù)據(jù)收發(fā)與狀態(tài)檢查直觀理解RS-232標(biāo)準(zhǔn)下CreateFile、SetCommState、ReadFile、WriteFile等核心API的用法。包體僅27KB結(jié)構(gòu)緊湊適合快速閱讀源碼、跟蹤通信流程。目前已有539人學(xué)習(xí)下載不少開(kāi)發(fā)者將其作為串口工具二次開(kāi)發(fā)的基礎(chǔ)模板。通過(guò)研讀代碼讀者可以掌握串口屬性的配置方法、事件驅(qū)動(dòng)與錯(cuò)誤處理思路并借助cnComm等封裝類(lèi)加深對(duì)串行通信機(jī)制的理解為后續(xù)自主編寫(xiě)調(diào)試工具或集成到嵌入式項(xiàng)目提供參考。 ComTest 串口調(diào)試工具名字不起眼但做過(guò)的朋友都知道這里面坑不少。我從接收區(qū)亂碼一路調(diào)到發(fā)送死鎖最后用 VC 把整個(gè)串口調(diào)試助手完整做出來(lái)前后折騰了差不多三周。今天把這個(gè)項(xiàng)目從設(shè)計(jì)、編碼到發(fā)布的完整過(guò)程寫(xiě)出來(lái)給還在用串口單步調(diào)試的朋友一個(gè)可以直接照著干的參考。先說(shuō)清楚這個(gè) ComTest 是干嘛的它就是一個(gè)運(yùn)行在 Windows 上的串口調(diào)試助手功能上對(duì)標(biāo)大家熟悉的友善串口助手但代碼完全是自己用 VC 6.0VC6寫(xiě)的。用來(lái)和單片機(jī)、GPS 模塊、傳感器、PLC 這類(lèi)帶串口或 USB 轉(zhuǎn)串口的設(shè)備做雙向通信驗(yàn)證特別適合嵌入式開(kāi)發(fā)、硬件調(diào)試、上位機(jī)驗(yàn)證這幾個(gè)場(chǎng)景。如果你正在做畢設(shè)里的上位機(jī)或者剛接手一個(gè)需要和硬件聯(lián)調(diào)的 Windows 小工具這篇博文可以直接幫你省掉一半的彎路。1. 串口調(diào)試工具的核心邏輯先搞明白它到底在干什么1.1 串口通信的本質(zhì)串行數(shù)據(jù)流很多新手第一次寫(xiě)串口工具都會(huì)糾結(jié)界面、糾結(jié)按鈕其實(shí)串口調(diào)試工具最核心的一件事只有三行邏輯打開(kāi)串口 - 收發(fā)數(shù)據(jù) - 顯示數(shù)據(jù)。串口通信和網(wǎng)口、USB 的并行結(jié)構(gòu)不一樣它是一條數(shù)據(jù)線按位發(fā)送、按位接收屬于典型串行異步通信。這意味著通信雙方必須提前約定好波特率一秒鐘傳多少個(gè) bit、數(shù)據(jù)位8 位還是 7 位、停止位1 位還是 2 位、校驗(yàn)位無(wú)、奇校驗(yàn)還是偶校驗(yàn)這四個(gè)參數(shù)就是所謂的“串口通信四要素”。我當(dāng)時(shí)做 ComTest 第一版時(shí)天真地以為四要素隨便填、能選中就行結(jié)果聯(lián)調(diào)的時(shí)候死活收不到單片機(jī)發(fā)來(lái)的數(shù)據(jù)。后來(lái)才意識(shí)到串口不是類(lèi)似 HTTP 那種帶格式封裝的協(xié)議它是一根裸線雙方只要參數(shù)不齊收到的就是一堆亂二進(jìn)制流連“報(bào)文錯(cuò)”都算不上。所以你在寫(xiě)串口工具之前必須先確認(rèn)對(duì)方的參數(shù)。實(shí)踐中最常見(jiàn)的配置是 9600-8-N-19600 波特率、8 數(shù)據(jù)位、無(wú)校驗(yàn)、1 停止位如果你不知道設(shè)備參數(shù)先按這個(gè)試。1.2 為什么選 VC 而不是 C# 或 Python這是很多人的第一反應(yīng)。我選 VC6 這個(gè)“老古董”而不是 C# 或 Python有三點(diǎn)考慮。第一ComTest 需要調(diào)用 Win32 API 中的 CreateFile、SetCommState、ReadFile、WriteFile 這些底層串口函數(shù)VC 里直接順手MFC 封裝的 MSComm 控件做界面又非???。第二VC6 生成的 exe 體積小、不依賴(lài) .NET Framework在工控機(jī)、舊電腦甚至 Win7/WinXP 上都能直接跑這對(duì)硬件調(diào)試場(chǎng)景特別重要——你永遠(yuǎn)不知道客戶現(xiàn)場(chǎng)的電腦是什么配置。第三我當(dāng)時(shí)的項(xiàng)目就是 VC6 寫(xiě)的底層 DLL上位機(jī)用 VC6 保證進(jìn)程內(nèi)調(diào)用時(shí)數(shù)據(jù)類(lèi)型完全一致省去托管代碼和非托管代碼互操作的爛事。不過(guò)話說(shuō)回來(lái)如果你只是臨時(shí)調(diào)試、不想編譯Python 的 pyserial 庫(kù)也很高效但那是“腳本”不是“工具”。ComTest 定位是發(fā)給別人用的獨(dú)立工具所以我選擇 VC MSComm 控件這也是工控行業(yè)里經(jīng)典的搭配。2. 關(guān)鍵技術(shù)原理與 VC 串口編程模型拆解2.1 MSComm 控件的工作機(jī)制MSCommMicrosoft Communications Control是微軟在 VB/VC 時(shí)代提供的串口通信 ActiveX 控件到現(xiàn)在用起來(lái)依然順手。它底層其實(shí)幫你封裝了 CreateFile 和線程回調(diào)的流程暴露出來(lái)幾個(gè)關(guān)鍵屬性和事件。最核心的就是 CommPort串口號(hào)、Settings波特率/數(shù)據(jù)位/停止位/校驗(yàn)位、InputMode接收模式0文本1二進(jìn)制、RThreshold觸發(fā) OnComm 事件的接收字節(jié)數(shù)閾值、InputLen每次讀取長(zhǎng)度、Input讀數(shù)據(jù)、Output寫(xiě)數(shù)據(jù)和 OnComm 事件。我一開(kāi)始最容易踩坑的是 RThreshold 設(shè)置為 0。RThreshold0 表示不觸發(fā)接收事件你永遠(yuǎn)收不到 OnComm 里的數(shù)據(jù)設(shè)為 1 則表示接收緩沖每收到 1 個(gè)字節(jié)就觸發(fā)一次事件。對(duì)大多數(shù)情況來(lái)說(shuō)RThreshold 設(shè)為 1 就夠了雖然事件觸發(fā)頻率高但 VC 的消息循環(huán)扛得住。真正要小心的是 InputMode如果你把 InputMode 設(shè)成文本模式0接收到的二進(jìn)制數(shù)據(jù)比如 0x00會(huì)被當(dāng)作字符串結(jié)束符干掉導(dǎo)致數(shù)據(jù)莫名變短。所以調(diào)試帶 0x00 的協(xié)議幀必須用二進(jìn)制模式。2.2 異步通信與 OnComm 事件的實(shí)時(shí)性串口通信天生是異步的你不能讓界面卡在一個(gè)死循環(huán)里等數(shù)據(jù)必須讓系統(tǒng)在數(shù)據(jù)到達(dá)時(shí)“通知”你。MSComm 的 OnComm 事件就是干這個(gè)的。事件觸發(fā)后你需要在事件處理函數(shù)里判斷 commEvent 是什么類(lèi)型comEvReceive 表示收到數(shù)據(jù)comEvSend 表示發(fā)送緩沖空了這個(gè)用得少comEventRxOver 表示接收緩沖溢出。我初學(xué)時(shí)犯過(guò)一個(gè)低級(jí)錯(cuò)誤——直接在 OnComm 里做字符串拼接結(jié)果數(shù)據(jù)量一大界面就卡死。原因是 OnComm 本身是在消息循環(huán)里執(zhí)行的如果你在里面做耗時(shí)操作、更新界面控件消息就沒(méi)法及時(shí)返回后續(xù)的數(shù)據(jù)就積壓越積越多界面直接假死。正確做法是把接收到的數(shù)據(jù)先追加到一個(gè) CString 或 CByteArray 緩沖區(qū)里然后給主界面發(fā)一條自定義消息PostMessage在主線程里更新編輯框。這樣 OnComm 立刻返回不阻塞底層接收線程。3. ComTest 的界面與核心功能模塊設(shè)計(jì)3.1 界面布局串口調(diào)試工具的“黃金分區(qū)”ComTest 界面布局我參考了市面主流調(diào)試助手的習(xí)慣分三個(gè)區(qū)域。左上角是串口參數(shù)設(shè)置區(qū)包含串口下拉框COM1-COM16、波特率下拉框1200 到 115200、數(shù)據(jù)位、校驗(yàn)位、停止位以及一個(gè)“打開(kāi)串口”按鈕。右邊是接收區(qū)的大編輯框多行、只讀接收區(qū)下方有“清空接收”“保存接收數(shù)據(jù)”“停止顯示”三個(gè)按鈕。下面一大塊是發(fā)送區(qū)包括文本輸入框和“發(fā)送”“自動(dòng)發(fā)送”“定時(shí)發(fā)送周期”幾個(gè)控件這樣做的好處是符合用戶使用習(xí)慣如果你給客戶現(xiàn)場(chǎng)用他們不用你教就能上手。一個(gè)細(xì)節(jié)是串口列表不要寫(xiě)死而是用枚舉注冊(cè)表的方式動(dòng)態(tài)獲取。Windows 的串口信息存在注冊(cè)表 HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM 下程序啟動(dòng)時(shí)循環(huán)讀取把所有 COM 口列出來(lái)。如果寫(xiě)死 COM1-COM8遇到 USB 轉(zhuǎn)串口產(chǎn)生 COM9 以上端口時(shí)就露餡了。3.2 打開(kāi)串口的完整流程CreateFile DCB 配置打開(kāi)串口的本質(zhì)是打開(kāi)一個(gè)文件設(shè)備。核心代碼是 CreateFile(COM3, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)返回的句柄就代表這個(gè)串口。拿到句柄后通過(guò) GetCommState 獲取當(dāng)前 DCB 結(jié)構(gòu)體修改 BaudRate、ByteSize、StopBits、Parity 四個(gè)字段再 SetCommState 寫(xiě)回去。這一步有不少細(xì)節(jié)波特率直接用枚舉值 CBR_9600、CBR_115200 等數(shù)據(jù)位是 4~8停止位用 ONESTOPBIT 或 TWOSTOPBITS校驗(yàn)位用 NOPARITY、ODDPARITY、EVENPARITY。除此之外還要設(shè)置超時(shí)。很多人打開(kāi)串口成功但讀數(shù)據(jù)總是返回 0多半是沒(méi)設(shè)置 COMMTIMEOUTS。我當(dāng)時(shí)給 ComTest 設(shè)置的超時(shí)策略是 ReadTotalTimeoutConstant500也就是每次讀操作最多等 500 毫秒。這個(gè)值不要太大否則 OnComm 響應(yīng)不積極也不要太小高頻數(shù)據(jù)會(huì)頻繁觸發(fā)超時(shí)錯(cuò)誤。最后一個(gè)關(guān)鍵函數(shù)是 SetCommMask(hCom, EV_RXCHAR)告訴系統(tǒng)我們只關(guān)心“收到字符”這個(gè)事件配合 WaitCommEvent 使用。用 MSComm 控件時(shí)這些都被封裝了但如果你看例程里有人用純 API 讀串口這套流程是標(biāo)準(zhǔn)動(dòng)作。3.3 發(fā)送與接收文本、HEX 雙模式發(fā)送區(qū)必須支持兩種格式字符串和 HEX 字節(jié)流。單片機(jī)工程師習(xí)慣看 HEX上位機(jī)聯(lián)調(diào)時(shí)也經(jīng)常需要一個(gè)字節(jié)一個(gè)字節(jié)地發(fā)比如發(fā) 55 AA 00 FF。字符串發(fā)送直接 CString - Output 就行但 HEX 發(fā)送需要自己做解析把“55 AA 00 FF”按空格拆開(kāi)每?jī)蓚€(gè)字符轉(zhuǎn)成一個(gè) BYTE再拼成 CByteArray 發(fā)給串口。接收區(qū)同理。如果你設(shè)的是二進(jìn)制模式收到的是一串 BYTE要顯示成 HEX 就得做字節(jié)到“XX ”字符串的轉(zhuǎn)換。這里有一個(gè)熱詞叫“vc 字節(jié)數(shù)組轉(zhuǎn)換成字符串”問(wèn)題是很多新手用 CString 的 Format(%x, data[i]) 慢慢拼數(shù)據(jù)量一上來(lái)效率極低。我后來(lái)改成了查表法提前建一個(gè) const char* hex_table[] {00,01,...FF}每個(gè)字節(jié)直接取下標(biāo)拼接速度快 10 倍不止。如果你也想做一個(gè)高性能串口工具這個(gè)技巧值得抄。4. 實(shí)操過(guò)程從零搭建 ComTest 的完整步驟4.1 創(chuàng)建 VC6 工程與插入 MSComm 控件第一步打開(kāi) VC6新建一個(gè) MFC AppWizard (exe) 工程工程名為 ComTest選“基于對(duì)話框”其他一路默認(rèn)。創(chuàng)建完成后在對(duì)話框資源里右鍵選擇“Insert ActiveX Control”找到 Microsoft Communications Control, version 6.0點(diǎn)確定??丶?huì)出現(xiàn)在工具箱里拖到對(duì)話框合適位置然后把它的 ID 改成 IDC_MSCOMM1這個(gè)控件在運(yùn)行時(shí)不需要顯示所以放在對(duì)話框外面或把它 Visible 屬性設(shè)為 FALSE 也行。注意一點(diǎn)有的精簡(jiǎn)版 VC6 沒(méi)有這個(gè) OCX 控件會(huì)報(bào)“控件未注冊(cè)”。解決辦法是去 Windows\SysWOW64 或 System32 下找 mscomm32.ocx用 regsvr32 mscomm32.ocx 注冊(cè)。我遇到過(guò)只拷貝 DLL 不注冊(cè)導(dǎo)致一直調(diào)用失敗的特別提醒。4.2 綁定變量與初始化串口參數(shù)在 ClassWizard 里給 MSComm 控件添加一個(gè)成員變量類(lèi)型是 CMSComm名字叫 m_MSComm。然后在 OnInitialUpdate 或 OnInitDialog 里初始化串口默認(rèn)參數(shù)。我的習(xí)慣是默認(rèn)選 COM1、9600、8、無(wú)校驗(yàn)、1 停止位下拉框里直接插入字符串方便用戶改。打開(kāi)串口的按鈕響應(yīng)函數(shù)核心邏輯是先判斷當(dāng)前串口是否已經(jīng)打開(kāi)如果打開(kāi)了就關(guān)閉如果沒(méi)打開(kāi)就嘗試打開(kāi)。代碼邏輯是if (m_MSComm.GetPortOpen()) m_MSComm.SetPortOpen(FALSE); m_MSComm.SetCommPort(m_nComPort); m_MSComm.SetSettings(9600,n,8,1); m_MSComm.SetInputMode(1); // 二進(jìn)制模式 m_MSComm.SetRThreshold(1); // 每收一個(gè)字節(jié)觸發(fā)事件 m_MSComm.SetInputLen(0); // 全部讀取 m_MSComm.SetPortOpen(TRUE);這里最陰險(xiǎn)的坑是 SetCommPort 前必須先關(guān)串口而且 SetSettings 要在 SetPortOpen 之前調(diào)用否則某些串口設(shè)備會(huì)以默認(rèn)參數(shù)打開(kāi)導(dǎo)致后面配置失效。另外我習(xí)慣用 CString 拼 settings 字符串比如str.Format(%d,%c,%d,%d, baud, parity, databits, stopbits)這樣用戶改了下拉框后就能動(dòng)態(tài)生成配置不用寫(xiě)死。4.3 接收事件與數(shù)據(jù)顯示MSComm 事件的添加方式是在對(duì)話框類(lèi)上右鍵 - Events - MSComm1選擇 OnComm。在 OnComm 里先判斷 commEvent 是否為 2comEvReceive然后循環(huán)讀取數(shù)據(jù)VARIANT vInput; BYTE btData[4096]; int nLen 0; if (m_MSComm.GetCommEvent() 2) { vInput m_MSComm.GetInput(); // 返回 VARIANT 類(lèi)型 COleSafeArray saInput vInput; nLen saInput.GetOneDimSize(); saInput.AccessData((void**)btData); // 把 btData[0..nLen-1] 追加到接收緩沖區(qū) saInput.UnaccessData(); }這里 GetInput 返回的是 VARIANT里面裝著一個(gè)字節(jié)數(shù)組。用 COleSafeArray 把它拆開(kāi)取出 BYTE 指針。數(shù)據(jù)取出后不要直接 DrawText而是追加到 CString m_strReceive 里然后 PostMessage(WM_MY_RECEIVE_MSG)在主線程里刷新編輯框的顯示。我實(shí)測(cè)下來(lái)最大問(wèn)題出在 AccessData 之前沒(méi)有判斷 vInput.vt 是不是 VT_ARRAY|VT_UI1如果 InputMode 設(shè)成了文本模式返回的 VARIANT 類(lèi)型就不是字節(jié)數(shù)組AccessData 會(huì)直接崩潰。所以——再次強(qiáng)調(diào)InputMode1二進(jìn)制模式。4.4 自動(dòng)發(fā)送與定時(shí)器實(shí)現(xiàn)“自動(dòng)發(fā)送”就是每隔固定時(shí)間把發(fā)送區(qū)內(nèi)容發(fā)一次。實(shí)現(xiàn)方式兩種一是用 SetTimer 配合 WM_TIMER 消息二是在線程里 Sleep。我推薦 SetTimer簡(jiǎn)單可靠適合低頻率周期性發(fā)送。定時(shí)器設(shè)置代碼是這樣if (m_bAutoSend) { SetTimer(1, m_nInterval, NULL); // m_nInterval 單位毫秒 } else { KillTimer(1); }然后在 OnTimer 里判斷 nIDEvent1就調(diào)用發(fā)送函數(shù)。這里有一個(gè)坑當(dāng)串口還沒(méi)打開(kāi)時(shí)定時(shí)器卻已經(jīng)啟動(dòng)那么每個(gè)周期都會(huì)觸發(fā)發(fā)送發(fā)送函數(shù)里可能因?yàn)閷?xiě)一個(gè)無(wú)效句柄而報(bào)錯(cuò)甚至崩潰。所以發(fā)送函數(shù)第一行必須判斷 m_MSComm.GetPortOpen()沒(méi)打開(kāi)就直接 return。自動(dòng)發(fā)送周期不要低于 50ms否則系統(tǒng)消息隊(duì)列會(huì)被擠爆串口實(shí)際發(fā)送速率也達(dá)不到預(yù)期看起來(lái)就像界面卡住了一樣。4.5 文件發(fā)送與保存接收數(shù)據(jù)調(diào)試過(guò)程中經(jīng)常會(huì)遇到需要把某個(gè) bin 文件或文本文件整個(gè)發(fā)出去的情況。ComTest 在發(fā)送區(qū)旁邊放了一個(gè)“發(fā)送文件”按鈕邏輯是把文件按二進(jìn)制讀入 CFile然后分批發(fā)送。注意一次性不要把所有內(nèi)容都塞進(jìn) Output應(yīng)該每 4096 字節(jié)發(fā)一次發(fā)完 Sleep(50)避免系統(tǒng)緩沖溢出。我用 4096 這個(gè)值是因?yàn)?Windows 串口驅(qū)動(dòng)內(nèi)部緩沖通常也是這個(gè)量級(jí)每次發(fā)太大容易丟失。保存接收數(shù)據(jù)則直接寫(xiě)文件。細(xì)節(jié)在于保存編碼選擇文本模式保存成 ANSI 或 UTF-8HEX 模式建議保存成原始字節(jié)流或“55 AA”文本方便重新導(dǎo)入對(duì)比。如果你想后續(xù)做自動(dòng)化回歸強(qiáng)烈建議把接收數(shù)據(jù)保存成帶時(shí)間戳的日志文件這屬于調(diào)試工具的增值功能。5. 發(fā)布前必做的細(xì)節(jié)圖標(biāo)、運(yùn)行庫(kù)與兼容性5.1 VC6 工程的應(yīng)用圖標(biāo)與資源替換熱詞里有“vc 6 應(yīng)用圖標(biāo)”這確實(shí)是發(fā)布時(shí)容易忽略的地方。VC6 默認(rèn)生成的 exe 圖標(biāo)是小電腦 MFC 方塊拿出去非常業(yè)余。替換圖標(biāo)的方法是在工作區(qū)資源視圖里展開(kāi)資源文件找到 IDR_MAINFRAME 圖標(biāo)資源右鍵刪除然后把做好的 .ico 文件導(dǎo)入工程把 ID 改成 IDR_MAINFRAME。注意圖標(biāo)尺寸最好備三份16x16、32x32、48x48。否則在資源管理器里縮放時(shí)會(huì)出現(xiàn)鋸齒。實(shí)際經(jīng)驗(yàn)是VC6 的圖標(biāo)資源編輯器比較老拖進(jìn)去的 ico 如果是新版 PNG 壓縮格式編譯可能失敗或圖標(biāo)顯示空白。我當(dāng)時(shí)用 IcoFX 存成 256 色 BMP 格式的 ico 才正常。發(fā)布前記得在客戶機(jī)上看一眼圖標(biāo)別在開(kāi)發(fā)機(jī)上正常換臺(tái)機(jī)器就白塊。5.2 微軟 VC 運(yùn)行庫(kù)與免安裝發(fā)布VC6 默認(rèn)動(dòng)態(tài)鏈接 MFC 和 C 運(yùn)行時(shí)庫(kù)所以你拿到一臺(tái)沒(méi)有裝過(guò) VC6 的電腦上跑大概率會(huì)彈“找不到 MFC42.DLL”或“找不到 MSVCRT.DLL”。這就是熱詞“微軟vc運(yùn)行庫(kù)”的來(lái)源。解決辦法有兩種一是打包發(fā)布時(shí)帶上 mfc42.dll、msvcp60.dll、msvcrt.dll 這三個(gè)文件放到 exe 同目錄二是在工程設(shè)置里改成“使用靜態(tài)鏈接庫(kù)”編譯產(chǎn)物直接變成單個(gè) exe不需要其他 DLL。我建議第二種因?yàn)榭蛻衄F(xiàn)場(chǎng)的工控機(jī)不一定允許你裝運(yùn)行庫(kù)靜態(tài)編譯最省心。切換靜態(tài)編譯的路徑是 Project - Settings - GeneralMicrosoft Foundation Classes 選“Use MFC in a Static Library”。代價(jià)是 exe 體積從幾十 KB 變成一兩 MB但對(duì)調(diào)試工具來(lái)說(shuō)完全無(wú)所謂。實(shí)測(cè)靜態(tài)編譯的 ComTest 在 Win7 Win10 Win11 都能直接雙擊運(yùn)行兼容性最好。5.3 與 DLL 調(diào)用的配合熱詞里有“vc 調(diào)用dll”這和串口工具其實(shí)密切相關(guān)。很多設(shè)備廠商會(huì)提供自己的通信 DLL比如“設(shè)備初始化 DLL”“協(xié)議解析 DLL”。ComTest 除了直接收發(fā)串口數(shù)據(jù)我也預(yù)留了一個(gè)“調(diào)用 DLL 解析”的擴(kuò)展點(diǎn)把接收到的原始數(shù)據(jù)傳給 DLL 的解析函數(shù)再把解析結(jié)果比如溫度、電壓顯示在獨(dú)立窗口。VC6 里調(diào)用 DLL 最常用的是隱式鏈接把 DLL 的 .lib 文件加入工程然后直接調(diào)用函數(shù)。但要注意調(diào)用約定DLL 導(dǎo)出的是 __stdcall 還是 __cdecl函數(shù)名是否有修飾。用 extern C __declspec(dllimport) 聲明可以避免名字修飾問(wèn)題。如果你拿到的是沒(méi)有 .lib 的裸 DLL就只能用 LoadLibrary 和 GetProcAddress 動(dòng)態(tài)加載了。這里提醒DLL 和 exe 都要保證和串口工具用同一套字符編碼多字節(jié)或 Unicode否則字符串參數(shù)會(huì)亂碼。6. 實(shí)測(cè)中的高頻問(wèn)題與排查實(shí)錄6.1 打不開(kāi)串口或被占用表現(xiàn)SetPortOpen(TRUE) 返回 FALSE或彈“無(wú)法打開(kāi)串口”。排查順序先看設(shè)備管理器里有沒(méi)有這個(gè) COM 口再看是不是被其他軟件占用最后看是否插了 USB 轉(zhuǎn)串口但驅(qū)動(dòng)沒(méi)裝好。經(jīng)驗(yàn)USB 轉(zhuǎn)串口的驅(qū)動(dòng)不穩(wěn)定時(shí)會(huì)出現(xiàn) COM 口“幽靈殘留”設(shè)備管理器里顯示在但實(shí)際不存在讓用戶重新插拔或卸載驅(qū)動(dòng)重啟。6.2 收不到數(shù)據(jù)表現(xiàn)發(fā)數(shù)據(jù)正常對(duì)方也回了但接收區(qū)沒(méi)顯示。排查順序首先確定引腳接線有沒(méi)有交叉TXD 對(duì) RXD其次確認(rèn)波特率是否一致再確認(rèn) RThreshold 是否大于 0。如果 RThreshold 設(shè)置正確請(qǐng)?jiān)?OnComm 里加一個(gè)斷點(diǎn)或 OutputDebugString 看事件有沒(méi)有觸發(fā)。經(jīng)驗(yàn)還有一種情況是對(duì)方設(shè)備是 3.3V 電平你的 USB 轉(zhuǎn)串口工具不兼容需要換一個(gè)支持電平轉(zhuǎn)換的模塊。這類(lèi)問(wèn)題在調(diào)試 STM32 時(shí)特別常見(jiàn)。6.3 中文亂碼與半字節(jié)亂碼表現(xiàn)收到的中文變成莫名字符。原因Windows 中文系統(tǒng)默認(rèn) ANSI 編碼但設(shè)備發(fā)來(lái)的可能是 UTF-8 或 GBK。如果設(shè)備發(fā)的是 GBK你直接按 ANSI 顯示沒(méi)問(wèn)題如果是 UTF-8你需要先轉(zhuǎn)碼。處理方案在接收區(qū)設(shè)置“編碼選擇”默認(rèn) ANSI可選 UTF-8。UTF-8 轉(zhuǎn) ANSI 用 MultiByteToWideChar 加 WideCharToMultiByte 兩個(gè) API 配合完成。注意HEX 模式下不存在亂碼問(wèn)題因?yàn)轱@示的是字節(jié)本身這也是我建議聯(lián)調(diào)階段優(yōu)先用 HEX 模式的根本原因——直接把亂碼問(wèn)題繞開(kāi)。6.4 自動(dòng)發(fā)送時(shí)界面卡死表現(xiàn)勾選自動(dòng)發(fā)送后窗口無(wú)法拖動(dòng)、按鈕點(diǎn)不了。原因SetTimer 周期太短或者發(fā)送函數(shù)里做了耗時(shí)操作。處理周期調(diào)到 200ms 以上發(fā)送函數(shù)里不要?jiǎng)?chuàng)建窗口對(duì)象不要 AddString 到下拉框只操作緩沖區(qū)。經(jīng)驗(yàn)如果必須高頻發(fā)送就把發(fā)送邏輯放到輔助線程里主線程只負(fù)責(zé)界面刷新。這個(gè)改動(dòng)不復(fù)雜但很多人第一次做上位機(jī)時(shí)會(huì)忽略。6.5 串口數(shù)據(jù)一多就丟包表現(xiàn)設(shè)備以 10ms 間隔發(fā) 200 字節(jié)一幀ComTest 顯示出來(lái)中間缺一段。原因接收線程沒(méi)有及時(shí)取走數(shù)據(jù)或者 InputLen 設(shè)置為 0 導(dǎo)致一次讀取全部但緩沖區(qū)溢出了。處理把 RThreshold 設(shè) 1InputLen 設(shè) 0保證每次事件把緩沖全部取走。如果還是丟可以在 OnComm 里循環(huán)調(diào)用 GetInput 直到取空。經(jīng)驗(yàn)盡量關(guān)閉“停止顯示”功能以外的額外界面刷新日志寫(xiě)入文件可以異步??傊尳邮章窂奖M量短??偨Y(jié)一點(diǎn)個(gè)人體會(huì)做了 ComTest 這個(gè)工具之后我對(duì)“串口調(diào)試”三個(gè)字的理解變深了一層??傆腥擞X(jué)得串口工具是簡(jiǎn)單的串口工具但真正聯(lián)調(diào)時(shí)一個(gè)個(gè)字節(jié)地從示波器級(jí)別看數(shù)據(jù)再把它變成清晰、可靠的上位機(jī)程序是一門(mén)需要摳細(xì)節(jié)的功夫。MSComm 控件雖老勝在穩(wěn)定如果你剛開(kāi)始寫(xiě)上位機(jī)用它熟悉串口通信模型、理解異步事件機(jī)制是一條很合適的路徑。等 CRUD 熟悉了再往底層換串口 API 方向進(jìn)階也不遲。最后一個(gè)小技巧送給還在調(diào)的你任何時(shí)候串口數(shù)據(jù)不符合預(yù)期先把接收區(qū)切到 HEX 模式看一眼亂碼、丟包、錯(cuò)位一目了然。沒(méi)有這個(gè)按鈕的所謂串口調(diào)試工具趁早換掉省錢(qián)省心。本文還有配套的精品資源點(diǎn)擊獲取