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