簡介周立功zlgcan C#二次開發(fā)例程是一套面向C#開發(fā)者的CAN總線通信二次開發(fā)參考工程適合需要基于ZLGCAN接口實現(xiàn)設(shè)備交互、消息收發(fā)與上層定制的工業(yè)自動化、嵌入式及物聯(lián)網(wǎng)場景入門與中級開發(fā)者均可從中找到對應(yīng)實現(xiàn)思路。資源共172個文件以C#源碼、Visual Studio工程文件與依賴動態(tài)庫為主體輔以XML配置、界面資源、調(diào)試緩存和說明文檔壓縮包約1.56MB結(jié)構(gòu)清晰便于按模塊檢索。目前已有613人學(xué)習(xí)瀏覽。例程圍繞ZLGCAN API展開覆蓋設(shè)備初始化、過濾器設(shè)置、數(shù)據(jù)收發(fā)、事件訂閱與異步回調(diào)等關(guān)鍵流程并針對“云設(shè)備”場景提供修復(fù)后的工程代碼結(jié)合源碼可直觀認(rèn)識C#事件驅(qū)動和異常處理在硬件通信中的落地方式同時了解CAN標(biāo)準(zhǔn)幀/擴(kuò)展幀、設(shè)備句柄管理等底層概念。對于需要快速上手CAN二次開發(fā)或擴(kuò)展周立功設(shè)備應(yīng)用的開發(fā)者這份例程能提供可直接參考的編碼范例與調(diào)試線索。1. 周立功 zlgcan 的 C# 二次開發(fā)一套 DLL 就能撐起上位機(jī) CAN 通信做產(chǎn)線工裝、汽車電子臺架或工業(yè)設(shè)備上位機(jī)的人大概率都繞不開周立功的 CAN 卡。zlgcan 這套庫的好處是不管底層是 USB 轉(zhuǎn) CAN 還是 PCIe 卡對外接口基本一致拿到板卡后 C# 上位機(jī)通過 P/Invoke 調(diào) DLL 就能收發(fā)報文不需要自己碰驅(qū)動。但真正的二次開發(fā)難點(diǎn)從來不在 API 數(shù)量而在結(jié)構(gòu)體對齊、濾波掩碼和接收模式這些細(xì)節(jié)上。這篇就按我從聲明到收發(fā)、再到排錯的完整思路把 zlgcan 的 C# 開發(fā)路徑講清楚。適合剛拿到例程卻不知道怎么組織代碼的入門者也適合已經(jīng)被“收不到數(shù)據(jù)”折磨過的熟手對照排查。2. zlgcan 庫的本質(zhì)與接入姿勢為什么 C# 必須走 P/Invoke2.1 驅(qū)動庫的分層結(jié)構(gòu)zlgcan.dll 在中間扮演什么角色zlgcan 的官方資料里通常把二次開發(fā)接口放在一個 C 動態(tài)庫里早期版本常見 ControlCAN.dll后來新版本統(tǒng)一叫 zlgcan.dll。上層是硬件驅(qū)動中間這層 DLL 把打開設(shè)備、初始化通道、收發(fā)報文、讀取設(shè)備信息都封裝成了標(biāo)準(zhǔn) C 導(dǎo)出函數(shù)C# 這邊沒有對應(yīng)的托管封裝所以必須用 DllImport 聲明函數(shù)原型再調(diào)用。這個“繞一層”的說法聽著麻煩實際上是好事函數(shù)簽名的 C 風(fēng)格非常穩(wěn)定只要把結(jié)構(gòu)體布局搞對C# 調(diào)用幾乎可以和 C 代碼一一對應(yīng)。常見做法是下載廠商提供的“二次開發(fā)庫及例程”壓縮包里面通常有 C/VB 的 demo、頭文件 zlcanapi.h 和 DLL 本體。C# 例程很少或者說很多套件里壓根沒有 C# 版需要自己做 P/Invoke 封裝。我第一次做的時候也想著有沒有現(xiàn)成 NuGet 包找了一圈發(fā)現(xiàn)社區(qū)包要么過時、要么針對舊版 ControlCAN于是干脆自己封了一層。與其依賴不確定的第三方代碼不如對著頭文件把函數(shù)聲明整理成一套自己的 C# 靜態(tài)類后續(xù)維護(hù)也清晰。封裝時的核心點(diǎn)有三個第一DLL 要能程序找到最簡單就是放在 exe 輸出目錄第二函數(shù)入口點(diǎn)名字不能錯Delphi 和 C# 的調(diào)用約定不同這里用默認(rèn) Winapi 即可第三結(jié)構(gòu)體內(nèi)存布局必須和 C 側(cè)完全一致這決定了報文能不能正確解析。下面這個最小骨架就是最基礎(chǔ)的聲明先跑通它再談收發(fā)。2.2 最小調(diào)用骨架先把 DllImport 聲明寫對using System; using System.Runtime.InteropServices; public static class ZlgCanNative { private const string ZLGCAN_DLL zlgcan.dll; // 打開設(shè)備返回設(shè)備句柄0 表示失敗 [DllImport(ZLGCAN_DLL, EntryPoint VCI_OpenDevice)] public static extern uint VCI_OpenDevice(uint deviceType, uint deviceInd, uint reserved); // 關(guān)閉設(shè)備 [DllImport(ZLGCAN_DLL, EntryPoint VCI_CloseDevice)] public static extern uint VCI_CloseDevice(uint deviceType, uint deviceInd); // 初始化某個 CAN 通道 [DllImport(ZLGCAN_DLL, EntryPoint VCI_InitCan)] public static extern uint VCI_InitCan(uint deviceType, uint deviceInd, uint canIndex, ref VCI_INIT_CONFIG pInitConfig); // 啟動 CAN 通道 [DllImport(ZLGCAN_DLL, EntryPoint VCI_StartCAN)] public static extern uint VCI_StartCAN(uint deviceType, uint deviceInd, uint canIndex); // 發(fā)送報文 [DllImport(ZLGCAN_DLL, EntryPoint VCI_Transmit)] public static extern uint VCI_Transmit(uint deviceType, uint deviceInd, uint canIndex, VCI_CAN_OBJ[] pObj, uint len); // 接收報文 [DllImport(ZLGCAN_DLL, EntryPoint VCI_Receive)] public static extern uint VCI_Receive(uint deviceType, uint deviceInd, uint canIndex, VCI_CAN_OBJ[] pReceive, uint len, int waitTime); } [StructLayout(LayoutKind.Sequential, Pack 1)] public struct VCI_INIT_CONFIG { public uint AccCode; public uint AccMask; public uint Filter; public byte Timing0; public byte Timing1; public byte Mode; } [StructLayout(LayoutKind.Sequential, Pack 1)] public struct VCI_CAN_OBJ { public uint ID; public uint TimeStamp; public byte TimeFlag; public byte SendType; public byte RemoteFlag; public byte ExternFlag; public byte DataLen; [MarshalAs(UnmanagedType.ByValArray, SizeConst 8)] public byte[] Data; [MarshalAs(UnmanagedType.ByValArray, SizeConst 3)] public byte[] Reserved; }這段代碼是把頭文件里的函數(shù)聲明原樣搬到 C#函數(shù)參數(shù)類型、順序都不能改。需要注意的細(xì)節(jié)是 VCI_InitCan 的第二個參數(shù)用的是 ref因為初始化配置需要傳入地址VCI_CAN_OBJ 里的 Data 和 Reserved 必須用 MarshalAs 定長數(shù)組聲明否則 C# 的數(shù)組只是引用傳過去的是指針而不是結(jié)構(gòu)體內(nèi)聯(lián)的 8 字節(jié)數(shù)據(jù)。參數(shù)部分deviceType 是硬件型號編號每種板卡對應(yīng)一個固定值具體以設(shè)備手冊為準(zhǔn)deviceInd 是多設(shè)備時的索引默認(rèn)從 0 開始canIndex 是通道號雙通道卡傳 0 或 1。這里順帶說一下調(diào)用約定。C# 默認(rèn)的 CallingConvention 是 Winapi在 Windows 上即 StdCall而大多數(shù) C DLL 導(dǎo)出函數(shù)用的就是 StdCall所以不寫也能工作。但如果你后來換了 Linux 或跨平臺方案這地方就要改成 Cdecl否則棧不平衡會隨機(jī)崩潰。3. 設(shè)備打開與 CAN 通道初始化讓板卡真正跑起來3.1 打開設(shè)備的正確順序從 OpenDevice 到 StartCAN設(shè)備接入不是調(diào)用一個 OpenDevice 就完事完整順序是打開設(shè)備、初始化通道參數(shù)、啟動通道。這三步任何一步失敗后面收發(fā)都是零。很多人在 InitCan 上卡住其實不是參數(shù)寫錯而是 OpenDevice 返回的句柄沒判斷或者板卡驅(qū)動沒裝好導(dǎo)致句柄為 0。我一般會在封裝類里把這四步串成一個方法返回統(tǒng)一的枚舉結(jié)果這樣 UI 層不用關(guān)心底層細(xì)節(jié)。public enum CanOpenResult { Success 0, OpenFailed 1, InitFailed 2, StartFailed 3 } public CanOpenResult OpenAll(uint deviceType, uint deviceInd, VCI_INIT_CONFIG[] configs) { if (ZlgCanNative.VCI_OpenDevice(deviceType, deviceInd, 0) 0) { return CanOpenResult.OpenFailed; } for (int i 0; i configs.Length; i) { if (ZlgCanNative.VCI_InitCan(deviceType, deviceInd, (uint)i, ref configs[i]) 0) { return CanOpenResult.InitFailed; } if (ZlgCanNative.VCI_StartCAN(deviceType, deviceInd, (uint)i) 0) { return CanOpenResult.StartFailed; } } return CanOpenResult.Success; }這段代碼的邏輯是先打開設(shè)備失敗就直接返回成功后再逐個通道初始化并啟動。configs 數(shù)組長度代表要初始化的通道數(shù)實際項目中我都是先讀一下設(shè)備信息里的通道數(shù)再分配數(shù)組避免越界。失敗分支里最好把錯誤碼也記下來比如 OpenFailed 時十有八九是占用問題InitFailed 時優(yōu)先懷疑波特率參數(shù)StartFailed 時查驅(qū)動狀態(tài)這樣排查速度快很多。還有一個容易忽略的點(diǎn)OpenDevice 的第三個參數(shù) reserved 傳 0 就行別自作聰明傳其他值。之前有同事傳了進(jìn)程 ID 進(jìn)去結(jié)果設(shè)備怎么都打不開換回 0 立刻正常。這是典型的“看函數(shù)覺得能用就亂傳”的翻車現(xiàn)場接口文檔沒解釋的參數(shù)默認(rèn) 0 就是最安全的。3.2 VCI_INIT_CONFIG 的每個字段都是坑波特率與濾波參數(shù)怎么填初始化配置結(jié)構(gòu)體只有七個字段但每個字段都能制造玄學(xué)問題。AccCode 和 AccMask 是驗收碼和屏蔽碼決定哪些報文能進(jìn)入接收緩沖區(qū)Filter 是濾波開關(guān)0 表示單濾波1 表示雙濾波Timing0 和 Timing1 決定波特率Mode 是工作模式0 為正常模式1 為只聽模式。很多初學(xué)者看到 Filter1 就把 AccCode 和 AccMask 按網(wǎng)上抄來的值填結(jié)果一條報文都收不到因為濾波把 ID 全部擋掉了。先看波特率。Timing0 和 Timing1 不是直接填波特率數(shù)值而是查表取十六進(jìn)制組合。常用的幾個值500Kbps 對應(yīng) Timing00x00、Timing10x1C250Kbps 對應(yīng) 0x01、0x1C125Kbps 對應(yīng) 0x03、0x1C。這里有個血淚經(jīng)驗永遠(yuǎn)以官方手冊附錄里的波特率參數(shù)表為準(zhǔn)不要自己算因為不同晶振和總線時鐘下同樣波特率對應(yīng)的寄存器值會變。下表是幾個常見配置方便你寫測試程序時快速起手。波特率Timing0Timing1備注1000Kbps0x000x00高速測試常用500Kbps0x000x1C汽車電子最常見250Kbps0x010x1C工業(yè)現(xiàn)場常用125Kbps0x030x1C低速總線濾波參數(shù)是我見過最坑的字段。雙濾波模式下 AccCode 和 AccMask 的規(guī)律是AccMask 對應(yīng)位為 0 表示必須匹配為 1 表示不關(guān)心。想接收所有報文AccCode0、AccMask0xFFFFFFFF 是最穩(wěn)的寫法因為每一位都被屏蔽全部報文直接放行。想只接收某個固定 ID把 AccCode 設(shè)為該 IDAccMask 設(shè)為 0。很多實際項目只是采集數(shù)據(jù)對濾波沒要求那就干脆用 Filter1 雙濾波、AccCode0、AccMask0xFFFFFFFF把坑先讓開。public static VCI_INIT_CONFIG CreateDefaultConfig(byte timing0, byte timing1) { return new VCI_INIT_CONFIG { AccCode 0, AccMask 0xFFFFFFFF, Filter 1, Timing0 timing0, Timing1 timing1, Mode 0 }; }這段代碼返回一個“接收全部報文、正常收發(fā)、按給定波特率運(yùn)行”的配置適合拿來跑通鏈路。注意 Mode 字段調(diào)試時有人會把它設(shè)為 1導(dǎo)致只能聽不能發(fā)而且這種現(xiàn)象不是每次必現(xiàn)和總線上其他節(jié)點(diǎn)的狀態(tài)有關(guān)。如果發(fā)送總失敗先看 Mode 是不是 0。另外 InitCan 的返回值 0 代表失敗非 0 是成功和 OpenDevice 的句柄含義不同別搞混。4. 報文收發(fā)輪詢、緩沖區(qū)結(jié)構(gòu)與時間戳4.1 用 VCI_Receive 收報文長度參數(shù)和等待時間的門道接收報文常用 VCI_Receive函數(shù)簽名里 len 表示 pReceive 數(shù)組最多能容納多少幀waitTime 是等待時間單位毫秒。如果用 0表示緩沖區(qū)沒有數(shù)據(jù)就立即返回適合放在獨(dú)立線程輪詢?nèi)绻麄髡龜?shù)線程會阻塞到有數(shù)據(jù)或超時。返回值是實際收到的幀數(shù)。我一般推薦在專門接收線程里用 waitTime50 的短超時輪詢而不是無限阻塞或非阻塞瘋狂循環(huán)。為什么不用無限阻塞因為 CAN 收發(fā)的回調(diào)機(jī)制不適用于所有場景單純阻塞在 Receive 上設(shè)備拔出或通信故障時線程會卡死沒法做看門狗。為什么不用 waitTime0 的死循環(huán)因為 CPU 占用會飆升一個空轉(zhuǎn)接收線程能吃掉一個核心在工控機(jī)上很不劃算。短超時輪詢折中了響應(yīng)速度和資源占用。下面這段代碼是典型的接收線程骨架。private void ReceiveLoop() { VCI_CAN_OBJ[] frames new VCI_CAN_OBJ[64]; while (_running) { uint count ZlgCanNative.VCI_Receive(_deviceType, _deviceInd, (uint)_canIndex, frames, 64, 50); if (count 0) { for (uint i 0; i count; i) { var frame frames[i]; // 這里統(tǒng)一處理幀校驗ID、解析數(shù)據(jù)、入隊列 OnFrameReceived?.Invoke(frame); } } } }這里把接收數(shù)組長度設(shè)為 64單次最多取 64 幀既避免頻繁調(diào)用 DLL又不會讓單次處理時間過長。waitTime 用 50 毫秒意味著最壞情況下 50ms 才喚醒一次對絕大多數(shù)總線應(yīng)用足夠。處理幀時不要直接在回調(diào)里寫數(shù)據(jù)庫或刷新 UI應(yīng)該放到隊列里由消費(fèi)線程做否則接收線程被慢操作拖住緩沖區(qū)滿了就開始丟幀。這是從翻車經(jīng)歷里總結(jié)出來的早先直接在 Receive 循環(huán)里更新 ListView總線報文一密界面就卡死丟幀率肉眼可見往上漲。時間戳字段 TimeFlag 表示該幀是否帶時間戳TimeStamp 的單位是 0.1ms也就是 100 微秒。做總線測試統(tǒng)計時特別有用但要注意時間戳的零點(diǎn)從啟動 CAN 通道開始計數(shù)不是從系統(tǒng)啟動開始跨通道對比時兩個通道的零點(diǎn)是一致的。如果設(shè)備驅(qū)動不帶時間戳功能TimeFlag 會是 0這時候 TimeStamp 的值沒有意義別拿去算間隔。4.2 發(fā)送與遠(yuǎn)程幀VCI_Transmit 的避雷點(diǎn)發(fā)送用 VCI_Transmit參數(shù)里 pObj 是待發(fā)送幀數(shù)組len 是幀數(shù)。返回值是實際發(fā)送成功的幀數(shù)。需要注意 SendType 字段0 表示正常發(fā)送1 表示單次發(fā)送。正常工作用 0。RemoteFlag 是遠(yuǎn)程幀標(biāo)志ExternFlag 是擴(kuò)展幀標(biāo)志這兩個字段好多新手不設(shè)置默認(rèn) 0 表示數(shù)據(jù)幀 標(biāo)準(zhǔn)幀如果總線上跑的是擴(kuò)展幀就會對不上。下面是個發(fā)送標(biāo)準(zhǔn)數(shù)據(jù)幀的封裝。public uint SendFrame(uint id, byte[] data, byte dataLen 8) { var frame new VCI_CAN_OBJ { ID id 0x7FF, SendType 0, RemoteFlag 0, ExternFlag 0, DataLen dataLen, Data new byte[8] }; Array.Copy(data, frame.Data, Math.Min(data.Length, 8)); return ZlgCanNative.VCI_Transmit(_deviceType, _deviceInd, (uint)_canIndex, new[] { frame }, 1); }發(fā)送返回 0 時先別懷疑發(fā)送函數(shù)按優(yōu)先級查三件事通道是否 StartCAN、Mode 是否設(shè)成了只聽模式、ID 是否被總線上其他節(jié)點(diǎn)仲裁掉。普通板卡的發(fā)送函數(shù)是同步提交到發(fā)送緩沖區(qū)不保證總線真的發(fā)出去所以返回 1 只能說明寫進(jìn)了驅(qū)動隊列不能證明對端收到了。想確認(rèn)必須靠對端回幀或者總線分析儀器。遠(yuǎn)程幀在這里再說一句RemoteFlag 置 1 表示發(fā)送的是遠(yuǎn)程幀這時 DataLen 可以為 0重點(diǎn)在 ID。很多控制器收到遠(yuǎn)程幀后會自動回復(fù)數(shù)據(jù)幀調(diào)試轉(zhuǎn)速等請求-應(yīng)答場景很常用。但注意部分板卡的遠(yuǎn)程幀發(fā)送有已知限制如果發(fā)現(xiàn)發(fā)遠(yuǎn)程幀后對端沒反應(yīng)先用手冊確認(rèn)當(dāng)前驅(qū)動版本是否支持。5. zlgcan C#開發(fā)避坑五個高頻翻車現(xiàn)場5.1 打開設(shè)備一直返回 0DLL 找不到還是設(shè)備被占用現(xiàn)象設(shè)備管理器里能看到 CAN 卡驅(qū)動也正常但 VCI_OpenDevice 始終返回 0。原因通常有兩個zlgcan.dll 不在 exe 的運(yùn)行目錄或者設(shè)備被另一個進(jìn)程占用。DLL 找不到時 DllImport 會拋 DllNotFoundException而返回 0 的情況下 DLL 是找到了的問題在設(shè)備層。解決先把 DLL 拷貝到 exe 所在目錄再確認(rèn)設(shè)備類型編號 deviceType 是否和你的硬件型號匹配最后打開任務(wù)管理器查有沒有其他程序占用了這個設(shè)備。有些測試軟件卸載后進(jìn)程沒退干凈一樣的現(xiàn)象。5.2 初始化成功卻收不到任何報文濾波把數(shù)據(jù)全擋了現(xiàn)象InitCan 和 StartCAN 都返回成功但 Receive 永遠(yuǎn)超時換另一個工具軟件又能看到總線數(shù)據(jù)。原因AccCode/AccMask 設(shè)置成了“只接收特定 ID”的組合而總線上的 ID 恰好不在范圍內(nèi)。解決確認(rèn) Filter1 時 AccCode0、AccMask0xFFFFFFFF這是放行所有幀的組合。如果要按 ID 過濾先把公式寫在紙上再填碼別憑感覺填。這個問題是濾波字段最容易踩的坑先拿全放行配置跑通鏈路再加過濾。5.3 收到的報文 ID 和數(shù)據(jù)對不上結(jié)構(gòu)體對齊錯位了現(xiàn)象能收到數(shù)據(jù)但 ID 看起來不對Data 數(shù)組第一位總是 0或者幀與幀之間錯位。原因C# 結(jié)構(gòu)體默認(rèn)按 8 字節(jié)對齊而 C 端結(jié)構(gòu)體通常按 1 字節(jié)打包兩邊內(nèi)存布局不一致導(dǎo)致字段偏移全部錯位。解決所有 zlgcan 相關(guān)結(jié)構(gòu)體統(tǒng)一加 StructLayout(LayoutKind.Sequential, Pack1)發(fā)送和接收用的 VCI_CAN_OBJ 必須同一個定義不能接收用打包版發(fā)送用默認(rèn)版。這個坑排查起來特別磨人因為數(shù)據(jù)看起來“有內(nèi)容但不對”很難第一時間想到對齊。5.4 發(fā)送返回成功但總線上抓不到幀無聲失敗的三板斧現(xiàn)象Transmit 返回 1但示波器或另一張 CAN 卡就是抓不到幀。原因按頻率排序通道沒 StartCAN、Mode 被設(shè)成 1 只聽模式、擴(kuò)展幀/數(shù)據(jù)幀標(biāo)志位和總線節(jié)點(diǎn)配置不匹配。解決先打印 StartCAN 返回值再檢查配置結(jié)構(gòu)體的 Mode最后核對幀的 ExternFlag 和 RemoteFlag。這三項全對還不能解決就換一個已知能用的幀從最小測試程序發(fā)排除業(yè)務(wù)代碼的干擾。發(fā)送是“數(shù)組提交成功”和“總線真的發(fā)出”兩回事這個認(rèn)知得擺正。5.5 高頻總線下丟幀嚴(yán)重接收線程處理太慢現(xiàn)象波特率一提到 500K 以上GetReceiveNum 查到的緩沖區(qū)積壓幀數(shù)越來越多實際處理到的幀數(shù)遠(yuǎn)小于預(yù)期。原因接收線程在處理幀時做了耗時操作比如寫數(shù)據(jù)庫、刷新 UI、做解析導(dǎo)致 Receive 調(diào)用頻率跟不上總線流量。解決接收線程只入隊列另起消費(fèi)線程做處理隊列長度做溢出保護(hù)滿了優(yōu)先丟最舊幀并計數(shù)。還有一個容易被忽略的點(diǎn)接收線程優(yōu)先級設(shè)為 ThreadPriority.AboveNormal在工控機(jī)多任務(wù)環(huán)境下體驗差異明顯。6. 進(jìn)階技巧濾波掩碼計算、性能驗證與線程模型收尾想按指定 ID 范圍接收掩碼公式可以做個小工具函數(shù)。雙濾波下匹配條件是 (ID ~AccMask) (AccCode ~AccMask)。接收固定 ID 0x123 時AccCode0x123、AccMask0 即可接收一組 ID 時先把它們的公共位算出來公共位對應(yīng)的 AccMask 位設(shè) 0其余設(shè) 1。我習(xí)慣在工具類里寫一個 BitConverter 風(fēng)格的輔助方法把 mask 計算封裝成單元測試避免每次手算。性能驗證我一般做兩件事一是連續(xù)發(fā)送 5 萬幀統(tǒng)計發(fā)送返回值和實際發(fā)送數(shù)是否一致二是雙卡回環(huán)測試一張卡發(fā)給另一張卡統(tǒng)計接收端丟幀率。丟幀率超過 0.01% 就要查接收線程和隊列設(shè)計不要拿“板卡硬件緩存不夠”當(dāng)借口多數(shù)情況下是上位機(jī)處理速度問題。線程模型方面最終方案是接收線程 消費(fèi)隊列 事件通知接收線程只做 Receive 和入隊消費(fèi)線程處理解析和存儲UI 通過事件拿到已處理的數(shù)據(jù)。這套結(jié)構(gòu)用了多個項目沒有出過大問題。我自己的習(xí)慣是每臺設(shè)備封裝一個獨(dú)立的 CanDevice 類內(nèi)部持有線程和隊列暴露 Start/Stop/FrameReceived 接口業(yè)務(wù)層從沒見過 DLL 函數(shù)。這樣做的最大好處是換設(shè)備型號時只改 deviceType 和配置代碼結(jié)構(gòu)完全不動。最后一句老實話zlgcan 的 C# 開發(fā)核心不在 API 背得多熟而在把結(jié)構(gòu)體布局、濾波參數(shù)和線程模型這三個基本功打牢。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取