簡介這份面向 Delphi 12 開發(fā)者的通信控件完整源碼包圍繞 nrCommLib Pro v9.54 展開適合需要在桌面應用中集成串口通信、終端交互、設備信息讀取及條碼掃描等能力的開發(fā)者參考。壓縮包共收錄 462 個文件、約 18.7MB以 95 個 pas 源碼、66 個 dcu 編譯單元、43 個 dfm 窗體、33 個 dpr 工程及 37 個 cpp、19 個 h 文件為主并配有 res 資源、示例 exe 和 chm、hlp 幫助文檔兼顧 Pascal 與 C Builder 環(huán)境下的查閱和二次開發(fā)。示例工程覆蓋終端模擬、串口設備枚舉、條碼掃描、語音與 Kermit 傳輸?shù)鹊湫蛨鼍氨阌诶斫饪丶{用方式和協(xié)議處理思路。已有 153 人學習下載完整源碼與示例工程適合用于控件機制研究、項目集成驗證及通信模塊排錯參考。1. 串口通信在 Delphi 12 里到底該怎么做一個老控件的完整源碼能省掉哪些事做上位機的同行大多碰過這種場面現(xiàn)場擺著一臺電子秤、一臺條碼槍、一臺老 PLC清一色 RS232客戶要求三天內出個能跑的界面。這時候翻 delphi 控件 的老倉庫串口那一塊永遠是第一道坎——TComPort 這類輕量控件開個口還行一旦遇上斷線重連、粘包解析、XModem 傳文件就頂不住了。nrCommLib Pro 這套 Full Source 版本的價值就在這里它把串口、Modem、終端、文件傳輸這些常年重復造輪子的東西做成了一組可編譯、可調試的組件而且源碼是全部給的出問題能一路跟到 ReadFile 那一層不用對著一個黑匣子 DCU 猜。適合誰適合手上已經有 Delphi 12 工程、需要把設備通信做穩(wěn)而不是做完的人。2. 解包看結構Full Source 里到底裝了什么拿到一個 7z 包第一件事不是急著裝而是先看清楚里面分成幾層。Full Source 類資源最怕的就是目錄結構混亂——源碼、預編譯包、示例工程、文檔全堆在一個根目錄下裝到 IDE 里就是一場災難。nrCommLib Pro 這類成熟控件的組織方式相對規(guī)整按功能分層源碼和示例分開放裝之前先摸清楚這三段式結構后面編譯才不會莫名其妙地引用到舊版本單元。2.1 解壓后第一眼源碼、包、Demo 三段式解開壓縮包把目錄攤平看一遍典型結構大致是這樣不同小版本會有出入以實際解壓結果為準# 解壓后先看二級目錄別一頭扎進去 7z x nrCommLib_Pro_v9.54_D12.7z -o./nrcomm_src cd ./nrcomm_src find . -maxdepth 2 -type d | sort # 輸出大致會是這幾類 # ./Source 運行時核心單元串口、協(xié)議、編碼都在這里 # ./Packages .dpk / .dprojDelphi 12 的包工程 # ./Demos 示例按組件分子目錄 # ./Help 幫助文檔.chm 或 .hlp # ./Lib 可能存在的預編譯 DCU裝源碼時要留意別用它這三段式里最容易翻車的是Lib目錄。很多包會順手塞一份預編譯好的 DCU 進去如果你在 IDE 的 Library Path 里同時掛了Lib和Source編譯器會優(yōu)先命中 DCU于是一改源碼就發(fā)現(xiàn)「怎么改了沒效果」——因為根本沒重新編譯。我一般會在安裝前直接把Lib挪走或者改名為Lib_bak強制所有單元都從 Source 編譯寧可變慢幾十秒也不要讓調試信息斷在中間。Source目錄是這套資源的真正主體。串口通信的全部底層邏輯都在這里包括端口枚舉、握手線控制、讀寫線程、緩沖區(qū)管理以及上層的協(xié)議解析。Full Source 的意義就在這——你可以在這些單元里下斷點看CreateFile返回的句柄、看ReadFile一次到底讀回來多少個字節(jié)、看線程是怎么在超時之后退出的。商業(yè)控件通常只給你 DCU出錯時只能靠日志和猜這種差異在現(xiàn)場排查時是致命的。Demos目錄不要跳過。成熟控件的示例往往比文檔更準因為它必須能編譯通過才有資格被發(fā)出來。示例里會告訴你哪個組件配哪個單元、事件簽名長什么樣、典型的初始化順序是什么。我習慣先把 Demos 里最簡的那個工程打開編譯一遍能跑通再談別的——這比讀十頁幫助文檔有效得多。2.2 .dpk 與 .dprojDelphi 12 下的編譯單元Delphi 的組件包分兩種運行時包Runtime和設計時包Design-time。運行時包包含真正的功能單元編譯出來是 .bpl設計時包依賴運行時包只負責把組件注冊到工具面板上還帶一個Register過程。裝包的正確順序是先編運行時包再編設計時包順序反了會直接報「找不到單元」或者「類未注冊」。Packages目錄里通常能找到對應的兩組工程文件。用 Delphi 12 打開.dproj時IDE 會提示是否轉換工程格式——這一步不要猶豫直接讓它轉會生成對應新版本的.dproj.local和編譯配置。轉換完之后第一件事是檢查Target PlatformsDelphi 12 默認可能勾了 Win64 和 Win32 兩個平臺如果這個包只支持 Win32就要把 Win64 取消掉否則編譯時會報一堆平臺相關的條件編譯錯誤。// 典型的 .dpk 內容重點是 contains 段和 Register 過程 package nrCommProR; // 運行時包只有單元沒有 Register {$R *.res} {$ALIGN 8} {$ASSERTIONS ON} requires rtl, vcl, vclx; contains nrcomm in ..\Source\nrcomm.pas, nrcore in ..\Source\nrcore.pas, nrcrc in ..\Source\nrcrc.pas; // 其余單元按實際列表補齊 end.// 設計時包依賴運行時包負責注冊組件圖標 package nrCommProD; requires rtl, vcl, designide, nrCommProR; // 關鍵requires 里引用運行時包 contains nrCommReg in ..\Source\nrCommReg.pas; end.這兩個文件的差別是理解 Delphi 組件體系的關鍵。運行時包contains里列的全是功能單元編譯產物可以被最終 EXE 引用設計時包requires里必須寫上運行時包的名稱它自己不包含任何業(yè)務邏輯只調用RegisterComponents。參數(shù)上要注意requires段的順序不能亂designide必須在設計時包里出現(xiàn)否則Register過程里的 IDE 相關調用會鏈接失敗。編譯時還有一個隱性坑包工程的輸出路徑和搜索路徑。默認情況下.dpk的單元搜索路徑是相對路徑..\Source如果你把包工程從Packages目錄挪到別處相對路徑立刻失效。我一般不改路徑就地在原目錄編譯編譯完把生成的.bpl和.dcp找出來手工確認它們落在哪個目錄——Delphi 12 默認可能輸出到C:\Users\Public\Documents\Embarcadero\Studio\...\Bpl這個路徑在后續(xù)工程引用時要寫對。2.3 從單元名反推模塊邊界不用等編譯光看Source目錄下的文件名就能大致畫出模塊圖。這類庫的命名習慣高度一致基本是nr前綴加功能名單元名前綴大致職責典型場景nrcomm/nrcore端口打開關閉、參數(shù)配置、讀寫線程所有串口通信的地基nrcrc/nrutils校驗算法、字節(jié)序轉換、緩沖區(qū)工具協(xié)議封包解包終端類單元字符流渲染、回車換行處理、ANSI 轉義調試串口、AT 命令交互文件傳輸類單元XModem / YModem / ZModem 狀態(tài)機給設備升級固件、傳配置短信 / Modem 類單元AT 命令隊列、PDU 編解碼工業(yè)現(xiàn)場的無線告警這張表的價值在于幫你判斷「我到底要用哪幾個單元」。如果只是讀個電子秤的重量值nrcomm加一個校驗工具就夠完全不用碰文件傳輸那套狀態(tài)機也就不會把一堆用不上的單元拖進 EXE。反過來如果要做固件升級那就必須啃傳輸協(xié)議的實現(xiàn)而且要重點看它的超時和重傳邏輯——這部分自己寫一遍至少要兩天還未必穩(wěn)。單元之間的依賴關系也要留意。核心單元一般不引用 UI 單元這是好設計但有些包會在核心單元里uses了Forms或者Dialogs一旦這樣你在控制臺程序或者服務程序里就沒法用它。翻源碼時順手 grep 一下uses Forms能提前避開這個雷。3. 核心模塊拆解一次收發(fā)從打開端口到回調的完整鏈路裝包只是準備工作真正要讀懂的是數(shù)據(jù)從設備進來、到你的代碼拿到字節(jié)中間經過了哪些層。串口通信看著簡單——不就是打開、讀、寫、關——但每一層都有坑尤其是緩沖和線程這兩塊寫錯了程序在辦公室跑得好好的到現(xiàn)場就開始丟包。這一章按一次完整收發(fā)的順序把關鍵代碼和參數(shù)拆開講。3.1 打開端口屬性表其實就決定了一半的穩(wěn)定性打開端口之前要先配參數(shù)參數(shù)配錯后面所有的調試都是白費。常見的配置項和取值含義屬性常用取值說明端口名COM3/\\.\COM10端口號大于 9 時必須用\\.\前綴波特率9600 / 19200 / 115200必須和從設備完全一致差一點都不行數(shù)據(jù)位8 / 7多數(shù)設備是 8老儀表可能是 7停止位1 / 29600 下多數(shù)是 1校驗位None / Even / Odd工業(yè)儀表常用 Even通信模塊常用 None流控None / RTS-CTS / XON-XOFF三線制接法必須設 None否則永遠收不到數(shù)據(jù)// 打開端口的標準姿勢先配置最后一步才 Active : True procedure TFormMain.OpenPort(const AName: string); begin nrComm1.Active : False; // 冪等防止重復打開 nrComm1.CommName : AName; // 端口號大于 9 時內部需補 \\.\ 前綴 nrComm1.BaudRate : br115200; // 與從設備嚴格一致 nrComm1.DataBits : db8; nrComm1.StopBits : sbOne; nrComm1.Parity : ptNone; nrComm1.Handshake : hsNone; // 三線制接法必須關閉硬件流控 nrComm1.BufferSize : 8192; // 接收緩沖區(qū)高頻設備建議調大 try nrComm1.Active : True; // 到這一步才真正 CreateFile except on E: Exception do Log(open %s failed: %s, [AName, E.Message]); end; end;這段代碼里有幾個參數(shù)值得單獨說。CommName在端口號小于等于 9 時寫COM3就行一旦到了COM10及以上Windows 的CreateFile需要\\.\COM10這種格式好在多數(shù)封裝庫內部已經做了轉換但如果你直接調 API 就必須自己補。Handshake是最容易出事的一項現(xiàn)場為了省錢只接 RX、TX、GND 三根線程序里卻開著 RTS/CTS 硬件流控結果就是發(fā)送一直阻塞、接收一個字節(jié)都收不到現(xiàn)象看起來像「設備沒反應」實際是流控在等一根永遠不會拉低的信號線。BufferSize是另一個實際問題。默認緩沖區(qū)通常只有 1024 或 4096 字節(jié)如果你的設備是 1ms 一幀連續(xù)上報主線程稍微卡一下緩沖區(qū)就溢出了溢出之后底層驅動會直接丟數(shù)據(jù)而且不報錯。把緩沖調大到 8K 甚至 32K 是低成本高收益的做法代價只是多占一點內存。Active : True要放在 try 里。端口被別的程序占用、USB 轉串口沒插好、權限不足都會在這一步拋異常?，F(xiàn)場最常見的現(xiàn)象是設備管理器里明明有COM3程序一打開就報拒絕訪問——多半是上一版程序沒退干凈句柄還掛在系統(tǒng)里。3.2 OnReceiveData 與緩沖區(qū)數(shù)據(jù)不是「一次性到齊」的串口是字節(jié)流不是消息流。設備發(fā) 20 個字節(jié)的一幀你可能第一次收到 8 個第二次收到 12 個也可能一次收全取決于驅動調度和你的讀取時機。很多人第一次寫串口代碼時在事件里直接把收到的字節(jié)當完整幀解析在辦公室的低速設備上跑得挺好一換成 115200 的高速設備立刻錯幀——這就是沒處理粘包和半包。// 事件里只做一件事把字節(jié)搬進自己的緩沖然后交給解析器 procedure TFormMain.nrComm1ReceiveData(Sender: TObject; Buffer: Pointer; BufferSize: Cardinal); var n: Cardinal; begin if BufferSize 0 then Exit; // 關鍵先申請空間再一次性拷進去不要在事件里做解析 n : Length(FRecvBuf); SetLength(FRecvBuf, n BufferSize); Move(Buffer^, FRecvBuf[n], BufferSize); // 只置標志解析放到主線程定時器或獨立解析線程里做 FHasNewData : True; end;Buffer是底層緩沖區(qū)的一個指針BufferSize是這一次回調拿到的字節(jié)數(shù)。注意這個指針只在回調執(zhí)行期間有效事件返回之后內存可能被復用所以必須立刻Move出來不能把指針存起來稍后再讀——這是新手最常犯的錯現(xiàn)象是「有時候數(shù)據(jù)對有時候是亂碼」。SetLength加Move的組合是動態(tài)數(shù)組追加的標準寫法但頻率高的時候會引發(fā)反復的內存重分配。生產代碼里我一般改成環(huán)形緩沖區(qū)或者固定大小的塊式緩沖避免在 1ms 級別的事件里做堆操作。這里的寫法是為了講清楚語義真上項目要換實現(xiàn)。事件里不做解析是為了把「收數(shù)據(jù)」和「處理數(shù)據(jù)」解耦。解析可能要查表、要計算校驗、要更新界面這些操作耗時不確定一旦卡在事件里下一次回調就會被推遲緩沖區(qū)堆積嚴重時直接丟包。用一個FHasNewData標志把活推給別的線程事件本身的執(zhí)行時間可以控制在微秒級。還有一點OnReceiveData的觸發(fā)時機由底層決定可能是每收到一批就觸發(fā)一次也可能是攢夠一定量才觸發(fā)。不要假設「一次事件等于一幀」也不要假設「事件一定會在多少毫秒內到來」。所有超時判斷都應該基于你自己的定時器而不是靠事件間隔。3.3 線程模型為什么事件里不能干重活串口讀寫在 Windows 上本來就是異步的底層驅動有自己的內核緩沖但你的應用層如果處理得慢緩沖區(qū)遲早會被填滿。這是串口程序卡頓和丟包的根本原因跟控件好壞關系不大是架構問題。常見的三種線程模型擺在這里對比模型做法優(yōu)點風險全主線程事件里直接解析并刷界面代碼簡單無同步問題界面一卡就丟包設備一多必崩主線程收 定時器解析事件入緩沖Timer 定時消費改動小同步簡單解析慢時仍然拖界面獨立解析線程事件入線程安全隊列worker 消費吞吐穩(wěn)界面流暢要處理同步和退出順序// 獨立解析線程的骨架隊列 信號量退出時必須能干凈收尾 type TParseThread class(TThread) private FQueue: TThreadedQueueByte; // 線程安全隊列Delphi 自帶 protected procedure Execute; override; public constructor Create(AQueue: TThreadedQueueByte); end; procedure TParseThread.Execute; var B: Byte; Frame: TBytes; begin while not Terminated do begin // 100ms 超時保證 Terminated 能被及時檢查到 if FQueue.PopItem(B) wrSignaled then begin Frame : FeedByte(B); // 狀態(tài)機逐字節(jié)喂入 if IsFrameComplete(Frame) then Synchronize(procedure begin OnFrameReady(Frame); end); end; end; end;TThreadedQueue是 Delphi 自帶的線程安全隊列PopItem帶超時參數(shù)這是它比TList加臨界區(qū)好用的地方——超時讓你有機會檢查Terminated不至于線程卡在等待上永遠退不出去。退出順序很關鍵先Terminate再往隊列里塞一個哨兵值或者等超時最后WaitFor三步缺一不可。少寫WaitFor的后果是程序關掉之后進程還掛在任務管理器里現(xiàn)場用戶會以為程序崩了。Synchronize會把調用切回主線程執(zhí)行所以界面更新放在這里面是安全的但它也會阻塞解析線程直到主線程處理完。如果界面更新很頻繁用Queue代替Synchronize更好后者是異步投遞不等待返回。這個差別在高頻數(shù)據(jù)場景下非常明顯。還有一個容易忽略的點串口對象本身的線程親和性。多數(shù)封裝的Active : False必須在創(chuàng)建它的線程里調用如果在解析線程里直接關端口可能觸發(fā)訪問沖突。穩(wěn)妥做法是主線程發(fā)指令、設置標志位等 worker 自己檢測到標志再退出最后由主線程關端口。3.4 協(xié)議層與上層組件終端、文件傳輸、短信底層打通之后上層組件才是這套庫拉開差距的地方。終端組件負責把字節(jié)流渲染成可讀字符處理回車換行、退格、ANSI 轉義序列——別小看這個調試 AT 命令的時候如果沒有終端組件你得自己處理\r\n和各種控制字符光是把回顯對齊就要花半天。文件傳輸組件實現(xiàn)的是 XModem / YModem / ZModem 這類經典協(xié)議本質是帶確認和重傳的分塊傳輸狀態(tài)機。這類協(xié)議的細節(jié)很瑣碎塊大小、校驗方式累加和還是 CRC16、超時重傳次數(shù)、文件名和長度的傳遞方式。自己實現(xiàn)一版能用的至少要兩三天而且邊界情況很難覆蓋全。源碼在手的好處是出問題能看狀態(tài)機卡在哪個狀態(tài)——是等 ACK 超時了還是 CRC 校驗一直失敗日志一打就清楚。短信和 Modem 相關的組件則是把 AT 命令的收發(fā)、響應匹配、PDU 編解碼封裝起來。工業(yè)現(xiàn)場用無線模塊做告警上行的場景不少AT 命令的坑主要在響應匹配上模塊返回OK之前可能先回一堆CREG、CSQ之類的主動上報如果不做甄別命令隊列會全亂。這類組件一般會把「發(fā)命令 → 等期望響應 → 超時重試」做成一個隊列看源碼的時候重點看它的超時和重試策略這兩個參數(shù)直接決定現(xiàn)場穩(wěn)定性。4. 跑起來Delphi 12 裝包、編譯、第一個 Demo理論講完落到操作。這一節(jié)按順序走一遍確認環(huán)境、編譯包、裝組件、寫第一個能收能發(fā)的窗口、用虛擬串口對自測。每一步都寫清楚失敗時看哪里照著做基本能在半小時內跑通。4.1 編譯前先把搜索路徑和環(huán)境確認掉裝包之前先把 IDE 的環(huán)境理干凈這一步省不得。Delphi 12 的庫路徑分全局Library Path和工程級Search Path全局路徑里如果殘留了舊版本的單元目錄編譯時會優(yōu)先命中舊單元報錯信息還特別誤導人。操作順序打開Tools → Options → Language → Delphi → Library在Library path里檢查有沒有舊版本的nr相關路徑有就刪掉。然后確認Bpl輸出目錄Tools → Options → Environment Options → Delphi Options → Library記下Package output directory的值后面裝包完成后要去這個目錄找.bpl。磁盤上還建議做一件事把解壓出來的整個目錄放在一個不含中文和空格的路徑下比如D:\dev\nrcomm954\。Delphi 的編譯器對路徑里的空格處理一直不算好.dproj里的相對路徑遇到空格容易斷這種問題排查起來極其浪費時間。4.2 裝包與組件面板進Packages目錄先打開運行時包的.dproj。IDE 提示轉換工程時選「是」然后在項目管理器里右鍵 →Build。編譯成功的標志是輸出窗口出現(xiàn)Success并且在之前記下的Package output directory里能看到對應的.bpl。# 編譯后確認產物路徑按你機器上的實際值替換 dir C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl\nrComm*.bpl # 順便確認 dcp 也生成了后續(xù)工程引用需要它 dir C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\nrComm*.dcp運行時包編譯通過后再打開設計時包同樣 Build。設計時包編譯成功會自動彈出安裝提示選「是」即可如果沒彈右鍵工程 →Install。裝完之后打開一個 VCL 工程組件面板上應該能看到新增的頁簽。看不到就先別懷疑包有問題去Component → Install Packages里確認設計時包是否在列表中并且勾選狀態(tài)正?！Ｒ娗闆r是編譯成功了但沒執(zhí)行安裝。如果編譯運行時包時報「找不到單元 xxx」八成是.dpk里的相對路徑和實際目錄對不上。直接在 IDE 的工程選項里把Source目錄加進Search path用絕對路徑比改.dpk快。這個改動只影響當前包工程不會污染全局配置。4.3 十分鐘寫一個能發(fā)能收的窗口新建一個 VCL Forms Application放一個串口組件、兩個 Memo、一個 ComboBox 選端口、一個 Button 發(fā)送。端口列表用系統(tǒng) API 枚舉不要硬編碼COM1到COM8現(xiàn)場設備接在COM12上的情況太常見了。// 枚舉本機可用串口填進 ComboBox procedure TFormMain.FillPorts; var I: Integer; begin cbPort.Items.Clear; for I : 1 to 256 do if nrComm1.IsPortAvailable(COM IntToStr(I)) then // 以實際 API 為準 cbPort.Items.Add(COM IntToStr(I)); if cbPort.Items.Count 0 then cbPort.ItemIndex : 0; end; // 發(fā)送先轉成字節(jié)數(shù)組再一次性寫出 procedure TFormMain.btnSendClick(Sender: TObject); var Data: TBytes; begin if not nrComm1.Active then Exit; Data : TEncoding.ASCII.GetBytes(mmSend.Text #13#10); // 多數(shù)設備以 CRLF 結尾 nrComm1.WriteData(Data[0], Length(Data)); end;IsPortAvailable這類方法在不同版本里名字可能略有差異以你手上的聲明為準實在沒有就自己調CreateFile試打開一次再關掉也能達到同樣效果。發(fā)送時把字符串轉成字節(jié)數(shù)組這一步不能省Delphi 12 默認字符串是 Unicode直接往串口寫字符串在部分版本上會走隱式轉換出來的字節(jié)數(shù)翻倍設備收到的全是0x00。TEncoding.ASCII明確指定編碼就沒有這個歧義。#13#10是 CRLF絕大多數(shù)命令行式設備以此作為一幀結束。但有例外有些稱重儀表只認#13有些 MODBUS 設備根本沒有結束符靠固定長度或時間間隔斷幀。先把設備的通信協(xié)議翻出來看清楚再決定發(fā)送的結尾是什么這一步猜錯的話后面解析全是白忙。5. 避坑與排查串口通信里那些玄學問題串口這塊的問題有個特點現(xiàn)象和原因經常對不上號。下面五條是這類庫在實際項目里最常遇到的每條按「現(xiàn)象 → 原因 → 解決」寫省得你一條條去試。5.1 端口明明在設備管理器里一打開就報拒絕訪問現(xiàn)象設備管理器里COM3正常顯示沒有黃色感嘆號程序一執(zhí)行Active : True就拋異常提示拒絕訪問或者端口不存在。原因九成是端口被占用。上一個版本的調試程序沒退干凈進程還掛在后臺或者串口調試助手開著沒關再或者這個端口被某個系統(tǒng)服務比如某些虛擬串口工具的后臺進程持有。少數(shù)情況是權限問題比如程序以普通用戶運行但端口被以管理員身份啟動的進程占著。解決先在任務管理器里把可疑進程全部結束再重試。仍不行就用命令行查占用handle.exe -a COM3Sysinternals 工具或者干脆重啟機器——虛擬串口驅動出問題時重啟是最快的后悔藥。長期方案是在程序啟動時先嘗試打開再關閉做探測把「端口被占用」這個狀態(tài)顯式提示給用戶而不是讓它以一個看不懂的異常彈窗出現(xiàn)。5.2 跑到現(xiàn)場就亂碼辦公室卻好好的現(xiàn)象同一套程序辦公室接著調試線收發(fā)正常裝到現(xiàn)場設備上收到的全是亂碼偶爾還夾雜幾個正確字節(jié)。原因參數(shù)不匹配。最常見的是波特率差一檔9600 和 19200 看起來都「能收到東西」、校驗位設錯、數(shù)據(jù)位設成 8 而設備是 7。其次是接線問題RS232 的 TX/RX 接反了不會完全收不到而是收到自己發(fā)出去的回顯看起來像亂碼。還有一種隱蔽情況是設備要求硬件流控但程序里關了導致設備發(fā)一半被丟棄。解決先把波特率、數(shù)據(jù)位、停止位、校驗位四項逐個和設備的說明書核對不要憑經驗。然后拿一個獨立的串口監(jiān)聽工具掛在線上抓原始字節(jié)和在程序里收到的對比——如果監(jiān)聽工具收到的就是亂碼問題在物理層或參數(shù)如果監(jiān)聽工具正常而程序亂碼問題在編碼轉換上去查TEncoding有沒有用錯。5.3 USB 轉串口一拔一插程序就啞了現(xiàn)象USB 轉串口線拔掉再插上端口號可能從COM3變成COM5程序仍然抓著舊句柄界面不報錯但數(shù)據(jù)再也不進來了。原因USB 設備的枚舉是動態(tài)的拔插之后系統(tǒng)會重新分配端口號而已經打開的句柄在設備移除后失效ReadFile返回錯誤但很多封裝不會主動觸發(fā)斷開事件于是程序就處于「以為自己還連著」的狀態(tài)。解決注冊設備變更通知WM_DEVICECHANGE收到DBT_DEVICEREMOVECOMPLETE就主動關端口并把狀態(tài)置為斷開收到DBT_DEVICEARRIVAL就重新枚舉端口列表。同時在讀線程里判斷讀操作的返回值連續(xù) N 次讀失敗就認定連接斷開觸發(fā)重連流程。重連要有退避不要死循環(huán)狂開端口那樣會把 CPU 占滿。5.4 編譯期報找不到單元 / 版本不匹配現(xiàn)象包能編譯但新建的工程一引用就報Unit nrcomm was compiled with a different version of ...或者干脆提示找不到某個單元。原因Delphi 的單元二進制格式和編譯器版本強綁定。你的機器上可能同時存在舊版本編譯出來的 DCU被搜索路徑優(yōu)先命中了。另一種情況是工程引用了運行時包但運行時包的.dcp不在搜索路徑里。解決第一步全盤搜一下有沒有同名的.dcu散落在別的目錄有就刪掉或者把那個目錄從 Library Path 里移除。第二步把Source目錄加到工程的Search path強制從源碼編譯。第三步確認工程的Runtime Packages列表里包含運行時包名并且.dcp目錄在Library path里。這三步做完基本能解決剩下的就是徹底清理一次dcu輸出目錄重新編譯。5.5 界面一卡一卡數(shù)據(jù)還丟包現(xiàn)象設備數(shù)據(jù)頻率一高界面就明顯卡頓按鈕點下去要等一兩秒才有反應同時收到的數(shù)據(jù)開始出現(xiàn)缺幀。原因解析和界面刷新都在主線程做而且是在接收事件里直接做。事件頻率高的時候主線程被占滿消息隊列積壓界面自然卡同時因為處理慢底層緩沖區(qū)被填滿驅動開始丟數(shù)據(jù)。解決按 3.3 節(jié)的模型改造事件里只搬運字節(jié)解析放到獨立線程界面更新用Queue異步投遞并且做節(jié)流——比如每 100ms 才刷新一次顯示而不是每收到一幀就刷。很多人舍不得這個改動覺得「先跑起來再說」結果是現(xiàn)場數(shù)據(jù)一密就崩最后還是得回來改白白多花兩天。6. 二次開發(fā)把控件包封裝成你自己的通信服務層拿到源碼之后最容易犯的錯是讓業(yè)務代碼直接uses控件單元、直接在窗體上拖一個串口組件、在每個按鈕里寫發(fā)送邏輯。這樣做的項目等設備從一種換成另一種、從串口換成網口就得全項目改一遍。我的做法是先封一層接口把控件關在實現(xiàn)層里業(yè)務只認接口。6.1 先包一層別讓業(yè)務代碼直接摸控件接口只暴露業(yè)務需要的東西打開、關閉、發(fā)一幀、收一幀、狀態(tài)變化通知?？丶膶傩?、事件、異常類型全部不出現(xiàn)在接口簽名里。// 業(yè)務層只依賴這個接口換實現(xiàn)時業(yè)務代碼零改動 type IDeviceLink interface [{6B1C2F7A-3E4D-4A21-9C58-0F2D7E9A1B33}] function Open(const Port: string; Baud: Integer): Boolean; procedure Close; function SendFrame(const Payload: TBytes): Boolean; function IsOpen: Boolean; property OnFrame: TProcTBytes read GetOnFrame write SetOnFrame; end; // 串口實現(xiàn)內部持有控件把所有細節(jié)擋在外面 type TSerialLink class(TInterfacedObject, IDeviceLink) private FComm: TnrComm; FParser: TFrameParser; procedure HandleData(Sender: TObject; Buffer: Pointer; Size: Cardinal); public constructor Create; destructor Destroy; override; function Open(const Port: string; Baud: Integer): Boolean; procedure Close; function SendFrame(const Payload: TBytes): Boolean; end;這層的價值不只是「解耦」這種空話。真正的好處是單元測試可以不接硬件用一個TFakeLink實現(xiàn)接口往OnFrame里灌構造好的字節(jié)流把解析邏輯測透。硬件相關的部分打開端口、參數(shù)配置留給現(xiàn)場聯(lián)調邏輯部分在辦公室就能驗證完。這樣做一輪下來現(xiàn)場調試的時間能砍掉一大半。SendFrame的返回值要有意義。發(fā)送失敗的原因分幾種端口沒開、寫超時、緩沖區(qū)滿。返回Boolean太粗生產代碼里我一般返回一個枚舉或者拋帶錯誤碼的異常讓上層能針對不同原因做不同處理——端口沒開就重連寫超時就重發(fā)緩沖區(qū)滿就等一會。6.2 粘包與斷幀協(xié)議解析才是真正的活串口收到的是純字節(jié)流業(yè)務要的是「一幀」。斷幀規(guī)則通常有三種固定長度、固定結束符、長度字段。前兩種簡單第三種最穩(wěn)但要注意長度字段本身的字節(jié)序。// 狀態(tài)機式的斷幀器喂一個字節(jié)吐一幀或 nil function TFrameParser.FeedByte(B: Byte): TBytes; begin Result : nil; case FState of fsHead: if B $AA then // 幀頭 begin FBuf : [B]; FState : fsLen; end; fsLen: begin FBuf : FBuf [B]; FExpect : B; // 長度字段不含幀頭幀尾 FState : fsBody; end; fsBody: begin FBuf : FBuf [B]; if Length(FBuf) FExpect 2 then // 幀頭 長度 長度值 begin if CheckSum(FBuf) FBuf[High(FBuf)] then Result : FBuf; FBuf : nil; FState : fsHead; // 無論校驗成敗都回到找?guī)^ end; end; end; end;這里有幾個細節(jié)值得注意。校驗失敗之后必須把狀態(tài)機復位到找?guī)^否則會一直卡在半幀狀態(tài)。緩沖區(qū)FBuf用動態(tài)數(shù)組拼接在低頻場景夠用高頻場景要換成預分配的環(huán)形緩沖加讀指針避免頻繁SetLength。FExpect一定要設上限收到一個聲稱長度是 255 但實際只有 10 個字節(jié)的壞幀時不能無限等下去超時或者長度越界都要復位。還有一種情況是幀頭出現(xiàn)在數(shù)據(jù)體里。如果協(xié)議沒有做字節(jié)轉義比如 HDLC 的 0x7D 轉義那么數(shù)據(jù)體里出現(xiàn)0xAA就會誤判。穩(wěn)妥的斷幀器要么依賴長度字段跳過數(shù)據(jù)體要么在幀頭匹配后加一個二次校驗如果協(xié)議本身沒有長度字段那只能靠超時斷幀這時候定時間隔的取值就很關鍵——太短會切斷正常幀太長會拖慢響應。6.3 怎么驗證改對了改完代碼得知道有沒有改對。我的習慣是備一張最小驗證清單每次動通信層都過一遍驗證項方法通過標準正常收發(fā)接設備發(fā)一幀讀一幀3 秒內收到正確響應校驗通過半包用虛擬串口對分兩次發(fā)一幀解析器能拼出完整幀粘包一次發(fā)兩幀連在一起解析器連續(xù)吐出兩幀斷線重連拔掉 USB 轉串口再插回5 秒內自動恢復不彈異常框高頻壓力100ms 一幀連續(xù)跑 30 分鐘內存不漲、界面不卡、無丟幀異常幀故意發(fā)校驗錯的幀解析器丟棄并復位不卡死這套用例不需要真實硬件也能跑前四項用虛擬串口對軟件建一對互通的端口一邊寫一邊讀邏輯層的問題全能暴露出來。后兩項必須上真機尤其是高頻壓力那一項——辦公室里跑十分鐘沒問題現(xiàn)場跑一天就內存泄漏的情況太常見了。最后說一點我自己的教訓。早年做這類項目時總覺得「通信層簡單先把界面做完再說」結果每次都是界面做完、業(yè)務寫完回頭一調通信發(fā)現(xiàn)底層假設全錯只能推倒重來。從那以后我每次接新設備都強制先把虛擬串口對搭起來、把斷幀器和狀態(tài)機跑通、把上面那張清單過一遍再動手寫第一個界面。這個順序看著慢實際省時間。希望幫到你。本文還有配套的精品資源點擊獲取