簡介一個(gè)基于C MFC類庫的RS485串口通信完整演示工程面向工業(yè)自動(dòng)化、物聯(lián)網(wǎng)設(shè)備調(diào)試以及串口通信初學(xué)者適合在Visual Studio 2015下直接編譯學(xué)習(xí)。壓縮包共22個(gè)文件以頭文件.h、C源文件.cpp和VS工程文件.sln/.vcxproj為主另含對話框界面資源、圖標(biāo)和說明文檔整體僅52KB結(jié)構(gòu)清晰便于按模塊查閱。已有3197人學(xué)習(xí)下載。工程實(shí)現(xiàn)了串口打開、波特率/數(shù)據(jù)位/停止位/校驗(yàn)位配置、數(shù)據(jù)讀寫與關(guān)閉等核心流程并展示MFC對話框程序如何響應(yīng)串口事件幫助理解RS485半雙工通信和MFC消息映射機(jī)制代碼注釋完整解壓后導(dǎo)入Visual Studio 2015即可運(yùn)行可動(dòng)手修改參數(shù)觀察效果也可作為二次開發(fā)的基礎(chǔ)框架。 最近在做一個(gè)老設(shè)備的改造項(xiàng)目工控機(jī)用的是Windows MFC老框架下位機(jī)是好幾臺(tái)分布在現(xiàn)場不同位置的儀表距離遠(yuǎn)、干擾大串口通信這塊最后定下來走RS485總線。網(wǎng)上翻了一圈關(guān)于C MFC做RS485串口通信的demo要么年頭太久、要么只有片段真正能直接拿來改的不多。所以我把自己最后落地的完整版代碼和踩坑過程整理出來給后面接類似活兒的兄弟一個(gè)參考。這篇文章適合兩類人一是剛接觸MFC串口開發(fā)、需要快速做出一個(gè)能收發(fā)數(shù)據(jù)的上位機(jī)demo的學(xué)生或轉(zhuǎn)行開發(fā)者二是已經(jīng)寫了幾年代碼、但總在485通信的邊角問題上反復(fù)折騰的工程師。內(nèi)容會(huì)覆蓋RS485的物理層要點(diǎn)、MFC里串口通信的方案取舍、完整代碼拆解以及我在調(diào)試中遇到的一堆真實(shí)問題。1. 三類串口的本質(zhì)區(qū)別為什么項(xiàng)目必須用RS485很多人上來就寫代碼結(jié)果連硬件選型都搞錯(cuò)了。RS232、RS422、RS485雖然長得像但電氣特性完全不同直接決定了你的通信距離、節(jié)點(diǎn)數(shù)量和抗干擾能力。1.1 從RS232到RS485核心變化在物理層RS232是單端信號傳輸信號地共用電壓差只有±3V到±15V抗干擾能力弱理論傳輸距離也就15米左右。RS485用的是差分信號A、B兩根線之間的電壓差來表示邏輯1和0共模干擾被抵消掉傳輸距離能到1200米而且同一總線上可以掛32個(gè)節(jié)點(diǎn)標(biāo)準(zhǔn)負(fù)載下。表RS232和RS485關(guān)鍵參數(shù)對比項(xiàng)目RS232RS485信號方式單端差分A、B兩線傳輸距離≤15米≤1200米節(jié)點(diǎn)數(shù)1對1最多32個(gè)標(biāo)準(zhǔn)負(fù)載抗干擾弱強(qiáng)通信模式全雙工半雙工常見那現(xiàn)場為什么不用以太網(wǎng)或者CAN設(shè)備是老儀表只有485接口換總線等于換設(shè)備成本完全不可接受。在工業(yè)改造場景里RS485依然是存量設(shè)備的絕對主力上位機(jī)這邊做適配是最省事的路徑。1.2 半雙工和方向控制485項(xiàng)目最容易翻車的地方RS485最BT的點(diǎn)在于它是半雙工同一時(shí)刻只能收或者只能發(fā)。普通RS232串口的TX、RX是獨(dú)立物理通道收發(fā)同時(shí)進(jìn)行沒問題但485的A、B線就一對發(fā)數(shù)據(jù)的時(shí)候必須把驅(qū)動(dòng)器使能拉高發(fā)完再拉低切回接收模式。這個(gè)方向切換如果時(shí)序不對就會(huì)出現(xiàn)一種很詭異的現(xiàn)象發(fā)出去的命令對端能收到但收不到對方的回包或者回包收了一半突然斷了。因?yàn)榉较蚯袚Q太快最后一個(gè)字節(jié)還沒從移位寄存器里完全發(fā)出去就把驅(qū)動(dòng)器關(guān)掉了。實(shí)踐里的處理方式發(fā)送完數(shù)據(jù)后必須等發(fā)送緩沖區(qū)徹底清空再切換方向。串口API里頭需要檢查發(fā)送隊(duì)列是否為空或者延時(shí)一個(gè)字節(jié)的時(shí)間再切。// 發(fā)送方向控制示例根據(jù)485轉(zhuǎn)換器的控制引腳翻轉(zhuǎn)電平 // 假設(shè)使用RTS作為方向控制常見的RS485轉(zhuǎn)接器方案 void SetRS485Mode(BOOL bSend) { // bSend TRUE: 發(fā)送模式拉高RTS // bSend FALSE: 接收模式拉低RTS EscapeCommFunction(m_hCom, bSend ? SETRTS : CLRRTS); }1.3 組網(wǎng)拓?fù)渚栈ㄦ溈偩€不是星型連接485組網(wǎng)是手拉手的菊花鏈每臺(tái)設(shè)備的A接A、B接B在總線兩端各接一個(gè)120Ω終端電阻。星型連接或者漏接終端電阻會(huì)在高速波特率下出現(xiàn)信號反射表現(xiàn)就是偶發(fā)亂碼。很多人在實(shí)驗(yàn)室調(diào)試沒問題一到現(xiàn)場就出亂碼80%是這兩件事沒做對終端電阻沒接全、或者線接成了星型。如果你要接的設(shè)備數(shù)量多比如超過10臺(tái)還要注意總線上每個(gè)節(jié)點(diǎn)的地址規(guī)劃協(xié)議層得做從站地址區(qū)分。2. MFC串口通信方案取舍MSComm控件還是Windows APIMFC做串口通信方案其實(shí)就兩大派ActiveX控件MSComm和直接用Win32通信API。網(wǎng)上demo一半以上用的是MSComm因?yàn)樗庋b好拖個(gè)控件、設(shè)幾個(gè)屬性、綁定事件就完事。但我最終選擇了純API方案原因后面細(xì)說。2.1 MSComm控件的問題打包分發(fā)和回調(diào)線程坑MSComm是ActiveX控件依賴mscomm.ocx文件注冊到系統(tǒng)。做工程的人都知道控件注冊這步在開發(fā)機(jī)上沒事?lián)Q個(gè)部署機(jī)器就各種報(bào)錯(cuò)未注冊、組件未找到、x64與x86位數(shù)不匹配。MFC項(xiàng)目本身帶系統(tǒng)庫都很麻煩再拖個(gè)OCX就是給自己找事。另外MSComm的OnComm事件其實(shí)是在工作線程里回調(diào)的你在事件處理函數(shù)里直接去更新界面控件十有八九要閃退或者死鎖。網(wǎng)上教程根本沒提這茬新手就卡在這里。2.2 純API方案的優(yōu)勢可控性強(qiáng)、部署簡單、資料透明CreateFile打開串口、GetCommState/SetCommState配置DCB、ReadFile/WriteFile收發(fā)、WaitCommEvent等事件——這套東西不依賴任何第三方組件msvcrt和kernel32搞定部署到哪臺(tái)機(jī)器都不會(huì)因?yàn)槿苯M件掛掉。我在實(shí)際項(xiàng)目里還因?yàn)橐粋€(gè)需求不得不放棄MSComm需要精確控制485的方向引腳時(shí)序要能直接操作串口的RTS/DTR線。如果用MSComm這個(gè)操作要繞一大圈才能實(shí)現(xiàn)而API方案一個(gè)EscapeCommFunction函數(shù)就搞定了。// 打開串口注意dwShareMode必須為0 HANDLE hCom CreateFileA(COM3, GENERIC_READ | GENERIC_WRITE, 0, // 獨(dú)占模式不允許共享 NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hCom INVALID_HANDLE_VALUE) { AfxMessageBox(_T(串口打開失敗請檢查設(shè)備是否被占用)); return FALSE; }這里有個(gè)細(xì)節(jié)dwShareMode必須傳0表示獨(dú)占串口。如果不獨(dú)占同一個(gè)COM口被另一個(gè)進(jìn)程打開之后讀寫行為會(huì)變得不可預(yù)期。之前有人圖方便用了FILE_SHARE_READ | FILE_SHARE_WRITE結(jié)果兩個(gè)程序同時(shí)打開同一串口數(shù)據(jù)直接亂掉。2.3 工作線程與超時(shí)機(jī)制界面不卡頓的保證MFC界面程序里絕對不能把ReadFile放在按鈕點(diǎn)擊事件里同步等待。串口讀數(shù)據(jù)如果沒設(shè)置超時(shí)ReadFile會(huì)一直阻塞界面直接假死。正確的姿勢是搞一個(gè)后臺(tái)通信線程死循環(huán)讀數(shù)據(jù)解析完成之后通過PostMessage把數(shù)據(jù)丟回主界面線程。線程的核心邏輯是串口的事件驅(qū)動(dòng) 超時(shí)控制。開發(fā)中最常用的是在監(jiān)聽線程中WaitCommEvent等待數(shù)據(jù)到達(dá)結(jié)合等待超時(shí)防止線程卡死線程退出時(shí)用事件信號通知。這里超時(shí)機(jī)制的配置很多人忽略了COMMTIMEOUTS結(jié)構(gòu)體設(shè)置不當(dāng)會(huì)導(dǎo)致讀取阻塞。// 配置串口參數(shù)9600, 8, N, 1 DCB dcb { 0 }; dcb.DCBlength sizeof(DCB); GetCommState(hCom, dcb); dcb.BaudRate CBR_9600; dcb.ByteSize 8; dcb.Parity NOPARITY; dcb.StopBits ONESTOPBIT; SetCommState(hCom, dcb); // 設(shè)置超時(shí)讀操作最多等待200ms COMMTIMEOUTS timeouts { 0 }; timeouts.ReadIntervalTimeout 50; timeouts.ReadTotalTimeoutMultiplier 10; timeouts.ReadTotalTimeoutConstant 200; SetCommTimeouts(hCom, timeouts);3. 完整代碼拆解從打開串口到CRC校驗(yàn)一條龍這一節(jié)把demo的核心模塊一個(gè)個(gè)拆開講。完整的工程文件結(jié)構(gòu)大概是CComPort類串口底層封裝、CMy485Dlg類界面交互、通信協(xié)議解析庫幀格式封裝。我這里挑了最核心的幾個(gè)代碼段貼出來的都是能直接編譯的部分。3.1 通信幀協(xié)議設(shè)計(jì)不能靠裸字節(jié)混日子RS485總線上多設(shè)備共享線路如果在協(xié)議層不把消息幀邊界定清楚接收端根本不知道一幀數(shù)據(jù)從哪開始、到哪結(jié)束。最常用的幀設(shè)計(jì)是幀頭地址功能碼數(shù)據(jù)長度數(shù)據(jù)域校驗(yàn)0xAA1字節(jié)1字節(jié)1字節(jié)N字節(jié)1字節(jié)異或校驗(yàn)幀頭0xAA、地址01代表主機(jī)本身、功能碼0x03是讀寄存器、0x06是寫寄存器這些都是照搬Modbus-RTU的思路只不過我做了一個(gè)輕量簡化版。校驗(yàn)我用的BCC異或校驗(yàn)數(shù)據(jù)量大的項(xiàng)目建議直接上CRC16。3.2 接收緩沖區(qū)的環(huán)形隊(duì)列設(shè)計(jì)串口數(shù)據(jù)是字節(jié)流一幀數(shù)據(jù)可能分好幾次到達(dá)。寫接收代碼時(shí)最忌諱的做法是讀一個(gè)字節(jié)處理一個(gè)字節(jié)因?yàn)榈诙巫x到的可能是上一幀的尾巴。正確方式是把讀到的字節(jié)先丟進(jìn)一個(gè)環(huán)形接收緩沖區(qū)再從緩沖區(qū)里按幀頭、地址、長度、校驗(yàn)依次解析。// 環(huán)形緩沖區(qū)定義 #define RX_BUF_SIZE 4096 BYTE g_RxBuf[RX_BUF_SIZE]; int g_nRxHead 0; // 寫入位置 int g_nRxTail 0; // 讀取位置 // 往緩沖區(qū)寫入一字節(jié)滿了則丟棄 void PushRxByte(BYTE bData) { int nNext (g_nRxHead 1) % RX_BUF_SIZE; if (nNext ! g_nRxTail) { g_RxBuf[g_nRxHead] bData; g_nRxHead nNext; } } // 從緩沖區(qū)讀取一字節(jié) BOOL PopRxByte(BYTE* pData) { if (g_nRxTail g_nRxHead) return FALSE; *pData g_RxBuf[g_nRxTail]; g_nRxTail (g_nRxTail 1) % RX_BUF_SIZE; return TRUE; }環(huán)形隊(duì)列的好處是不用頻繁搬移內(nèi)存讀寫雙方只用維護(hù)各自的游標(biāo)。這個(gè)結(jié)構(gòu)你要用得很熟因?yàn)槿魏我粋€(gè)工業(yè)串口項(xiàng)目基本都跑不掉這套東西。3.3 接收線程事件驅(qū)動(dòng)防止CPU空轉(zhuǎn)接收線程用WaitCommEvent加超時(shí)等待而不是死循環(huán)ReadFile。死循環(huán)讀串口是惡搞CPU占用率直接給你干到30%電腦風(fēng)扇呼呼轉(zhuǎn)。UINT CComPort::ReceiveThread(LPVOID pParam) { CComPort* pPort (CComPort*)pParam; OVERLAPPED ov { 0 }; ov.hEvent CreateEvent(NULL, TRUE, FALSE, NULL); DWORD dwMask 0; while (pPort-m_bThreadRunning) { // 等待數(shù)據(jù)到達(dá)事件超時(shí)500ms用于檢查線程退出標(biāo)記 if (!WaitCommEvent(pPort-m_hCom, dwMask, ov)) { if (GetLastError() ERROR_IO_PENDING) { WaitForSingleObject(ov.hEvent, 500); // 等待500ms } } if (!pPort-m_bThreadRunning) break; if (dwMask EV_RXCHAR) { // 有數(shù)據(jù)到達(dá)讀取 BYTE buf[512] { 0 }; DWORD dwRead 0; ReadFile(pPort-m_hCom, buf, sizeof(buf), dwRead, NULL); for (DWORD i 0; i dwRead; i) { PushRxByte(buf[i]); } // 通知主界面處理接收數(shù)據(jù) ::PostMessage(pPort-m_hWnd, WM_RX_DATA, 0, 0); } } CloseHandle(ov.hEvent); return 0; }注意這個(gè)設(shè)計(jì)接收線程只負(fù)責(zé)把字節(jié)塞進(jìn)環(huán)形隊(duì)列、通知界面線程有新數(shù)據(jù)了真正的解析幀、更新界面全部在主線程完成。這樣不會(huì)出現(xiàn)界面假死也避免線程不同步導(dǎo)致的內(nèi)存競爭。3.4 數(shù)據(jù)發(fā)送和485方向切換精確到字節(jié)的操作發(fā)送部分要結(jié)合RS485半雙工特性。發(fā)送流程是置發(fā)送模式拉高RTS- 寫數(shù)據(jù) - 等待發(fā)送緩沖區(qū)清空 - 切回接收模式。切換的時(shí)機(jī)控制不對通信就一抽一抽的。BOOL CComPort::SendData(BYTE* pData, int nLen) { if (!m_hCom || !pData || nLen 0) return FALSE; // 485方向切換為發(fā)送模式 SetRS485Mode(TRUE); DWORD dwWritten 0; BOOL bRet WriteFile(m_hCom, pData, nLen, dwWritten, NULL); // 等待數(shù)據(jù)完全發(fā)出 FlushFileBuffers(m_hCom); // 切回接收模式注意這里不能太快 Sleep(10); SetRS485Mode(FALSE); return bRet (dwWritten (DWORD)nLen); }有個(gè)細(xì)節(jié)要提WriteFile返回只說明數(shù)據(jù)進(jìn)了系統(tǒng)發(fā)送緩沖區(qū)不代表已經(jīng)發(fā)出去了。所以必須FlushFileBuffers等待物理發(fā)送完成再切方向。加的那個(gè)Sleep(10)是為了兜底波特率9600下一字節(jié)大約是1.04ms10ms足夠發(fā)完幾十個(gè)字節(jié)。3.5 發(fā)送數(shù)據(jù)的協(xié)議打包按幀格式組裝發(fā)送時(shí)要把原始命令按協(xié)議格式封裝。Modbus風(fēng)格的讀寫指令核心就是把地址、功能碼、寄存器地址、數(shù)據(jù)長度、校驗(yàn)值算好拼接。我封裝了一個(gè)BuildWriteCommand函數(shù)輸入?yún)?shù)是設(shè)備地址、寄存器地址和值輸出一個(gè)標(biāo)準(zhǔn)報(bào)文// 計(jì)算BCC異或校驗(yàn) BYTE CalcBCC(BYTE* pData, int nLen) { BYTE bBCC 0; for (int i 0; i nLen; i) bBCC ^ pData[i]; return bBCC; } // 組裝讀命令 int BuildReadCommand(BYTE bAddr, WORD wRegAddr, WORD wRegCount, BYTE* pOut) { int nIndex 0; pOut[nIndex] 0xAA; // 幀頭 pOut[nIndex] bAddr; // 設(shè)備地址 pOut[nIndex] 0x03; // 功能碼讀 pOut[nIndex] HIBYTE(wRegAddr); // 寄存器地址高字節(jié) pOut[nIndex] LOBYTE(wRegAddr); // 寄存器地址低字節(jié) pOut[nIndex] HIBYTE(wRegCount); // 寄存器數(shù)量高字節(jié) pOut[nIndex] LOBYTE(wRegCount); // 寄存器數(shù)量低字節(jié) pOut[nIndex] CalcBCC(pOut, nIndex); // 校驗(yàn) nIndex; return nIndex; }4. 實(shí)測中的大坑亂碼、丟幀、USB轉(zhuǎn)485的隱形問題代碼寫完之后調(diào)試才是真正大戰(zhàn)。我在這個(gè)項(xiàng)目里踩了一連串坑有些坑如果沒人提前講自己排查估計(jì)要耗掉一整天。4.1 數(shù)據(jù)位校驗(yàn)和停止位不匹配從設(shè)備參數(shù)不統(tǒng)一查起第一個(gè)坑就出在串口參數(shù)上?，F(xiàn)場有一臺(tái)設(shè)備是9位數(shù)據(jù)位8位數(shù)據(jù)校驗(yàn)位當(dāng)數(shù)據(jù)用另外幾臺(tái)是標(biāo)準(zhǔn)8N1。我用統(tǒng)一參數(shù)打開串口結(jié)果其中一臺(tái)設(shè)備回的數(shù)據(jù)全亂。查了半天發(fā)現(xiàn)是設(shè)備廠家出廠設(shè)置的校驗(yàn)位是Even偶校驗(yàn)串口配置不匹配讀上來的數(shù)據(jù)自然不對。這個(gè)問題的處理方式比較直接先把所有設(shè)備的串口參數(shù)摸清統(tǒng)一配置。485總線上所有設(shè)備的波特率、校驗(yàn)位、數(shù)據(jù)位、停止位必須完全一致否則整個(gè)總線都不能正常通信。所以做項(xiàng)目第一步不是寫代碼而是找設(shè)備廠家要參數(shù)表。4.2 USB轉(zhuǎn)RS485模塊的隱患自動(dòng)收發(fā)電路導(dǎo)致第一個(gè)字節(jié)丟實(shí)驗(yàn)室測試用的是USB轉(zhuǎn)485模塊代碼調(diào)通了拿到現(xiàn)場接工控機(jī)原本的COM口主板原生串口就出問題。第一條命令發(fā)出去設(shè)備不響應(yīng)第二條開始正常。后來查資料才明白很多USB轉(zhuǎn)485模塊用的是自動(dòng)收發(fā)切換電路靠檢測數(shù)據(jù)線上的電平變化來切換收發(fā)方向這沒問題。但工控機(jī)原生串口沒有這個(gè)電路我代碼里用手動(dòng)RTS控制方向時(shí)序上第一個(gè)字節(jié)還沒穩(wěn)定就發(fā)出去了設(shè)備沒收到。手動(dòng)切向發(fā)送模式時(shí)在置位RTS之后加一點(diǎn)延時(shí)再WriteFile。別小看這幾毫秒對RS485這種電平型信號來說方向刀閘沒打開就放信號等于把數(shù)據(jù)扔進(jìn)了空氣里。// 置位RTS之后留出方向切換穩(wěn)定時(shí)間 SetRS485Mode(TRUE); Sleep(5); // 根據(jù)實(shí)際模塊調(diào)整5-20ms都試過 WriteFile(m_hCom, pData, nLen, dwWritten, NULL);4.3 120Ω終端電阻不在現(xiàn)場你根本想不到的坑設(shè)備端A、B線之間短路或者總線兩端沒接終端電阻高速率下數(shù)據(jù)會(huì)因信號反射而亂碼。現(xiàn)場設(shè)備已經(jīng)預(yù)埋了10年不可能拆開去接終端電阻只能在主機(jī)端想辦法。在主機(jī)接線端子上直接并聯(lián)了一個(gè)特制的信號適配板它內(nèi)含120Ω終端電阻和TVS保護(hù)。信號質(zhì)量肉眼可見地改善原來偶發(fā)的亂碼徹底消失。如果你碰到遠(yuǎn)端和主機(jī)端通信不穩(wěn)定先檢查兩端的終端電阻這個(gè)最容易被忽略但影響卻是致命的。4.4 丟幀和粘幀問題協(xié)議解析必須要有狀態(tài)機(jī)在調(diào)試中發(fā)現(xiàn)一個(gè)典型的丟幀場景主機(jī)發(fā)送讀取指令后設(shè)備回包長度50字節(jié)但接收線程只收到了30字節(jié)剩下的20字節(jié)晚了幾十毫秒才到。這種拆包情況如果用一次ReadFile去讀整幀必然丟數(shù)據(jù)。解決方案就在前面的環(huán)形隊(duì)列設(shè)計(jì)上。接收線程無腦讀、無腦塞隊(duì)列解析層按狀態(tài)機(jī)從隊(duì)列里一節(jié)一節(jié)啃出幀頭、地址、長度、數(shù)據(jù)、校驗(yàn)。每個(gè)字節(jié)都走一遍這個(gè)狀態(tài)機(jī)直到校驗(yàn)通過才認(rèn)為一幀完整。狀態(tài)機(jī)這一步必須做扎實(shí)上電第一位不是幀頭就跳過收到幀頭后下一個(gè)字節(jié)不是本機(jī)地址就重置長度字段超出數(shù)據(jù)域上限直接丟棄重置。這些都是防御性處理在總線上有其他噪聲干擾時(shí)能擋住99%的無效數(shù)據(jù)。幀解析狀態(tài)機(jī)流轉(zhuǎn) IDLE → 收到0xAA → 已接收幀頭 → 接收地址 → 匹配則繼續(xù) → 接收功能碼 → 接收長度 → 接收數(shù)據(jù)域 → 接收校驗(yàn) → 校驗(yàn)通過則一幀完成 任意一步不匹配 → 回到IDLE丟棄當(dāng)前累積5. 工程化細(xì)節(jié)從demo到能交付的代碼還差什么網(wǎng)上很多demo能跑通但拿到現(xiàn)場一用就露餡。因?yàn)閐emo停留在讀取串口數(shù)據(jù)打印到文本框這個(gè)層面而真正的工程代碼要解決日志、異?；謴?fù)、設(shè)備斷線重連等一堆破事。5.1 串口異常斷開后的自動(dòng)重連機(jī)制現(xiàn)場調(diào)試會(huì)頻繁拔插USB轉(zhuǎn)485線或者設(shè)備斷電重啟。這時(shí)串口句柄可能已經(jīng)失效任何讀寫操作都會(huì)失敗。一個(gè)健壯的通信模塊必須做異常檢測和重連。我的方案是在工作線程里每次讀寫操作檢查返回值連續(xù)失敗超過3次就關(guān)閉串口句柄并通知界面串口異常斷開界面彈提示并啟動(dòng)一個(gè)定時(shí)器嘗試重連直到重新打開成功。定時(shí)器重連邏輯void CMy485Dlg::OnTimerReconnect() { // 嘗試重新打開串口 if (m_pComPort-Open(m_nComPort)) { KillTimer(m_nReconnectTimerId); SetStatusText(_T(串口重連成功)); m_pComPort-StartReceiveThread(); } else { SetStatusText(_T(等待重連...)); } }5.2 通信日志排障的照妖鏡項(xiàng)目上線后的第一訴求基本是出問題時(shí)能查日志。尤其是485這種總線上掛著多臺(tái)設(shè)備的場景沒有日志你根本不知道哪臺(tái)設(shè)備沒回包、哪個(gè)字節(jié)是錯(cuò)的。我在demo里加了一個(gè)日志模塊所有發(fā)送和接收的字節(jié)都按十六進(jìn)制寫進(jìn)文本文件帶時(shí)間戳。這玩意成本極低但價(jià)值極高現(xiàn)場排障全靠它。void LogData(const CString strDir, BYTE* pData, int nLen) { CString strLine; strLine.Format(_T([%s] %s: ), CTime::GetCurrentTime().Format(_T(%H:%M:%S)), strDir); for (int i 0; i nLen; i) { CString strByte; strByte.Format(_T(%02X ), pData[i]); strLine strByte; } // 寫入文件 CStdioFile file; if (file.Open(_T(comm_log.txt), CFile::modeCreate | CFile::modeNoTruncate | CFile::modeWrite)) { file.SeekToEnd(); file.WriteString(strLine _T(\n)); file.Close(); } }5.3 打包部署MFC運(yùn)行庫和驅(qū)動(dòng)要一起帶走最后交付時(shí)跑demo的機(jī)器要裝MFC運(yùn)行庫才能運(yùn)行。Debug版本還得帶一堆調(diào)試動(dòng)態(tài)庫Release版本的運(yùn)行庫文件要一并帶上。用VS2013以上版本做的MFC程序目標(biāo)機(jī)器大概率裝了更新版的VC運(yùn)行庫但保險(xiǎn)起見還是把對應(yīng)版本的vcredist_x86安裝包隨程序一起交付。另外如果是USB轉(zhuǎn)485模塊USB驅(qū)動(dòng)也要一起打包?，F(xiàn)場經(jīng)常有人插上新機(jī)器發(fā)現(xiàn)沒驅(qū)動(dòng)臨時(shí)找驅(qū)動(dòng)盤找不到這個(gè)坑屬于高頻。把驅(qū)動(dòng)的exe安裝文件放進(jìn)部署包的驅(qū)動(dòng)目錄下能省去售后一堆電話。寫代碼容易調(diào)通現(xiàn)場才是本事做這類項(xiàng)目到最后你會(huì)發(fā)現(xiàn)寫代碼其實(shí)是最快的一步真正花時(shí)間的全在現(xiàn)場排查設(shè)備接地不良導(dǎo)致的共模電壓、A/B線接線反了、總線上兩臺(tái)設(shè)備地址沖突……每一個(gè)都是文檔里不會(huì)寫、但實(shí)際必然遇到的坑。給你們留一個(gè)實(shí)際檢驗(yàn)過的經(jīng)驗(yàn)如果新接到一個(gè)485通信的需求先別急著寫代碼花半天把現(xiàn)場設(shè)備的電氣參數(shù)、通信協(xié)議、接線拓?fù)涿宄@個(gè)時(shí)間花得絕對值。協(xié)議文檔拿到手之后按上面這套代碼骨架去改最多一天能把基礎(chǔ)通信跑通。后面就算遇到玄學(xué)問題只要協(xié)議解析和方向時(shí)序這兩塊做扎實(shí)基本都能在日志里浮出水面。本文還有配套的精品資源點(diǎn)擊獲取