簡(jiǎn)介基于WinUSB的上位機(jī)USB通信示例工程面向在Windows平臺(tái)下使用VS2010與C/MFC實(shí)現(xiàn)USB設(shè)備通信的嵌入式或上位機(jī)開(kāi)發(fā)者。工程完整演示了從設(shè)備枚舉、接口初始化到批量/控制傳輸?shù)耐暾溌凡⑴溆星逦鶰FC界面適合學(xué)習(xí)USB驅(qū)動(dòng)編程的學(xué)生或需要在項(xiàng)目中快速接入WinUSB的工程師。資源包為RAR格式共120個(gè)文件約33.26MB。核心內(nèi)容包括C源文件.cpp/.h、MFC界面資源.rc/.res/.ico、Visual Studio工程配置.vcxproj/.sln以及WinUSB運(yùn)行時(shí)所需的.dll/.lib/.inf/.cat文件另含較多編譯過(guò)程文件.obj/.pch/.tlog等與一份USB通信講解文檔.docx便于直接打開(kāi)工程對(duì)照學(xué)習(xí)。資料已有3099人學(xué)習(xí)實(shí)踐價(jià)值較高。通過(guò)該示例可掌握WinUSB初始化、管道讀寫、動(dòng)態(tài)插拔處理等方法同時(shí)可復(fù)用其MFC交互框架快速搭建自己的USB調(diào)試工具。 最早上位機(jī)和 USB 設(shè)備打交道的時(shí)候很多人第一反應(yīng)是走“USB轉(zhuǎn)串口”把設(shè)備偽裝成一個(gè) COM 口然后用串口那套邏輯收發(fā)數(shù)據(jù)。方案簡(jiǎn)單但吞吐量、實(shí)時(shí)性和穩(wěn)定性都很受限。后來(lái)我因?yàn)橐粋€(gè)項(xiàng)目要跟自制的高速采集板卡通信數(shù)據(jù)量一大串口方案直接頂不住這才認(rèn)真研究了 winusb 這條路子。簡(jiǎn)單說(shuō)winusb 是微軟提供的用戶態(tài)驅(qū)動(dòng)方案應(yīng)用程序可以直接通過(guò) WinUSB API 和 USB 設(shè)備通信不用寫內(nèi)核驅(qū)動(dòng)也繞開(kāi)了“虛擬串口”這層中轉(zhuǎn)帶寬和可靠性都上了一個(gè)臺(tái)階。本文整理的就是我在這個(gè)項(xiàng)目里的完整思路從硬件枚舉、驅(qū)動(dòng)安裝到上位機(jī) API 調(diào)用、BULK 端點(diǎn)收發(fā)再到抓包定位問(wèn)題適合那些剛接觸 USB 通信、或者被“數(shù)據(jù)量大只能轉(zhuǎn)串口”卡住的朋友參考。1. 為什么選 winusb通信方案先想清楚再動(dòng)手1.1 一棒子打死的“串口”方案做上位機(jī)通信最常見(jiàn)的就是 USB 轉(zhuǎn)串口比如 CH340、FT232 之類的方案。把 USB 橋接成 UART上位機(jī)打開(kāi) COM 口發(fā)數(shù)據(jù)單片機(jī)那邊用串口中斷接收手動(dòng)實(shí)現(xiàn)一些私有協(xié)議整個(gè)鏈路似乎都能跑通。但有兩個(gè)致命問(wèn)題。第一串口的瓶頸非常明顯。常見(jiàn)的波特率從 9600 到 921600 不等就算跑滿 921600也就是每秒大約 90KB 出頭實(shí)際因?yàn)閹袷胶蜁r(shí)序偏差還得打折。如果數(shù)據(jù)量是幾兆字節(jié)每秒的采集數(shù)據(jù)、圖片或者波形文件這個(gè)速度完全不夠看。第二線纜和電平轉(zhuǎn)換折騰人。串口電平轉(zhuǎn)換芯片、TTL 電平、地線隔離、干擾問(wèn)題做產(chǎn)品的時(shí)候都是成本。而且虛擬串口驅(qū)動(dòng)在不同 Windows 版本下行為有差異經(jīng)常出現(xiàn)“開(kāi)發(fā)機(jī)上好好的客戶機(jī)器上驅(qū)動(dòng)裝不上”這種離奇問(wèn)題。當(dāng)然串口方案也有它的生態(tài)優(yōu)勢(shì)調(diào)試工具多、協(xié)議現(xiàn)成、跨平臺(tái)如果數(shù)據(jù)量不大、對(duì)實(shí)時(shí)性要求一般是夠用的。但我的項(xiàng)目要求是連續(xù)傳輸幾十 KB 到幾百 KB 的采集數(shù)據(jù)還要保證 USB 總線利用率一次流程跑十幾秒不能掉鏈子。這么一來(lái)串口方案就不合適了需要直接使用 USB 原生協(xié)議。1.2 winusb 的優(yōu)勢(shì)邊界winusb 是微軟在 Windows 上提供的一種用戶態(tài)驅(qū)動(dòng)模型內(nèi)核里由 winusb.sys 這個(gè)系統(tǒng)自帶驅(qū)動(dòng)負(fù)責(zé)總線交互應(yīng)用層則通過(guò)一組 WinUSB API 與設(shè)備通信。也就是說(shuō)我不需要寫 .sys 內(nèi)核驅(qū)動(dòng)也不需要處理 Windows 驅(qū)動(dòng)簽名的麻煩事只需要一個(gè) INF 文件把設(shè)備綁定到 winusb.sys 上應(yīng)用就能拿到設(shè)備句柄。跟常見(jiàn)方案對(duì)比一下方案驅(qū)動(dòng)復(fù)雜度數(shù)據(jù)帶寬開(kāi)發(fā)難度適用場(chǎng)景USB 轉(zhuǎn)串口 / CDC低系統(tǒng)自帶/廠商驅(qū)動(dòng)低通常 1Mbps 有效低小數(shù)據(jù)量控制、日志、低速傳感器HID 設(shè)備低系統(tǒng)自帶免驅(qū)低中斷傳輸64字節(jié)/事務(wù)低鼠標(biāo)鍵盤、簡(jiǎn)單控制命令WINUSB中INF 系統(tǒng)驅(qū)動(dòng)高BULK 傳輸可達(dá)幾十MB/s中高速數(shù)據(jù)采集、固件升級(jí)、圖像傳輸廠商自定義內(nèi)核驅(qū)動(dòng)高極高很高專業(yè)設(shè)備、特殊總線行為從表格里能看出winusb 走的是“高帶寬 中等開(kāi)發(fā)量”的甜點(diǎn)區(qū)。BULK 端點(diǎn)可以充分利用 USB 帶寬正常 USB 2.0 高速模式下BULK 端點(diǎn)單方向跑到 30-40 MB/s 不算稀罕配合雙緩沖和異步 IO實(shí)際項(xiàng)目里拿 10-20 MB/s 非常輕松。而且由于驅(qū)動(dòng)是系統(tǒng)自帶的不需要擔(dān)心發(fā)行版兼容性只要 Windows 7 及以上基本都內(nèi)置了 winusb.sys。當(dāng)然也不是沒(méi)有代價(jià)。副作用就是設(shè)備插入后不能像 HID 那樣即插即用需要安裝 INF 綁定驅(qū)動(dòng)而且同一時(shí)刻默認(rèn)只能有一個(gè)應(yīng)用打開(kāi)設(shè)備句柄不支持多進(jìn)程共享訪問(wèn)。這些坑后面都會(huì)講到。1.3 別忽略的驅(qū)動(dòng)前提使用 winusb 需要從硬件枚舉階段就做好配合。設(shè)備端要有完整的 USB 描述符至少包括設(shè)備描述符、配置描述符、接口描述符和端點(diǎn)描述符并且要在接口描述符里聲明為 vendor-specific 或使用微軟兼容 IDMS OS Descriptor。最穩(wěn)妥的做法是 VID/PID 自定義然后 INF 里匹配 VID/PID。需要注意的是雖然 winusb.sys 是系統(tǒng)自帶的但它不會(huì)對(duì)所有設(shè)備自動(dòng)生效必須通過(guò) INF 文件把它指定為設(shè)備的驅(qū)動(dòng)。當(dāng)你看到設(shè)備管理器里設(shè)備顯示為“WinUsb 設(shè)備”或“USB 輸入設(shè)備”旁邊有個(gè)感嘆號(hào)多半是 INF 沒(méi)配對(duì)或者簽名有問(wèn)題。這也是本文后面實(shí)操環(huán)節(jié)我會(huì)重點(diǎn)講的部分。2. 硬件與枚舉把 USB 設(shè)備變成“WinUSB 設(shè)備”2.1 INF 文件設(shè)備綁定驅(qū)動(dòng)的關(guān)鍵要使用 winusb第一步是讓 Windows 在設(shè)備插入時(shí)自動(dòng)加載 winusb.sys 驅(qū)動(dòng)。這個(gè)動(dòng)作通過(guò) INF 文件完成。我可以給出一份最簡(jiǎn)可用的 INF 參考這個(gè)文件放在項(xiàng)目目錄里右鍵安裝一次后設(shè)備插入就會(huì)自動(dòng)綁定。[Version] Signature $Windows NT$ Class USBDevice ClassGuid {88BA0321-1AEC-4E6E-8F2A-844F469316B4} Provider %ProviderName% DriverVer 06/21/2024,1.0.0.0 [Manufacturer] %ProviderName% DeviceList,NTx86,NTamd64 [DeviceList.NTamd64] %DeviceName% USB_Install, USB\VID_1234PID_5678 [USB_Install] Include winusb.inf Needs WINUSB.NT [USB_Install.Services] Include winusb.inf Needs WINUSB.NT.SERVICES [USB_Install.Wdf] KmdfService WINUSB, WINUSB_Install [WINUSB_Install] KmdfLibraryVersion 1.11 [Strings] ProviderName MyCompany DeviceName My USB Device其中 VID_1234 和 PID_5678 換成你的設(shè)備實(shí)際 VID/PID。ClassGuid 是 USBDevice 類不要隨便改。安裝的時(shí)候在 INF 文件上右鍵選擇“安裝”即可。如果是 x86 系統(tǒng)把 NTamd64 改回 NTx86或者兩個(gè) section 都保留。有個(gè)細(xì)節(jié)INF 文件保存格式必須為 UTF-8 或者 ANSI帶 BOM 的 UTF-8 偶爾會(huì)有簽名問(wèn)題驅(qū)動(dòng)裝不上。另外一個(gè)常見(jiàn)問(wèn)題是 64 位系統(tǒng)強(qiáng)制驅(qū)動(dòng)簽名winusb 這種系統(tǒng)驅(qū)動(dòng)不需要額外的第三方簽名但 INF 本身如果加了自定義文件復(fù)制或者改注冊(cè)表動(dòng)作就得簽名。這里我建議只做“綁定 winusb.sys”這件事不要夾帶私貨簽名問(wèn)題就能繞開(kāi)。2.2 固件段要實(shí)現(xiàn)的描述符設(shè)備端的枚舉信息決定了上位機(jī)能不能認(rèn)出它。以 STM32 或者帶 USB 外設(shè)的 MCU 為例描述符配置要關(guān)注幾個(gè)字段bcdUSB 建議設(shè)置為 0x0200表示 USB 2.0。bDeviceClass、bDeviceSubClass、bDeviceProtocol 全部填 0表示接口層自定義。idVendor 和 idProduct 必須和 INF 里的 VID/PID 對(duì)應(yīng)。在接口描述符中bInterfaceClass 填 0xFFvendor-specificbInterfaceSubClass、bInterfaceProtocol 填 0。端點(diǎn)描述符至少準(zhǔn)備一對(duì) BULK IN、BULK OUT或者一對(duì)中斷端點(diǎn) 一對(duì) BULK 端點(diǎn)看數(shù)據(jù)流方向。很多 MCU 的 USB 庫(kù)已經(jīng)有現(xiàn)成的“Custom HID”模板稍微改改 VID/PID 和不必要的 HID 描述符就能當(dāng) vendor 設(shè)備用。但是注意如果固件里有多接口配置winusb 默認(rèn)會(huì)綁定接口 0。上位機(jī)如果想訪問(wèn)接口 1 或多個(gè)接口需要通過(guò) WinUSB API 里的 WinUsb_GetAssociatedInterface 遍歷這個(gè)后面會(huì)提到。實(shí)際開(kāi)發(fā)里我還犯過(guò)一個(gè)錯(cuò)把端點(diǎn)描述符里的 wMaxPacketSize 設(shè)得太小。比如高速模式下 BULK 端點(diǎn)最大包是 512 字節(jié)但如果固件配置的是 64 字節(jié)傳輸層會(huì)把一個(gè) 512 字節(jié)的事務(wù)拆成幾個(gè)小事務(wù)性能直線下降。所以固件配置時(shí)最好確定好高速/全速模式并配置正確的最大包長(zhǎng)。2.3 用 Zadig 做驅(qū)動(dòng)力挽狂瀾如果不想寫 INF或者只是開(kāi)發(fā)調(diào)試階段臨時(shí)用可以借助 Zadig 這個(gè)工具手動(dòng)把設(shè)備驅(qū)動(dòng)替換成 WinUSB。它會(huì)把設(shè)備驅(qū)動(dòng)從廠商驅(qū)動(dòng)換成 winusb.sys界面點(diǎn)上幾下就完成極其方便。但是 Zadig 有個(gè)隱患它會(huì)修改 Windows 的驅(qū)動(dòng) cache導(dǎo)致 INF 安裝不好用甚至把原本正常的驅(qū)動(dòng)搞亂。我在項(xiàng)目里只在研發(fā)階段用 Zadig 快速驗(yàn)證鏈路正式發(fā)給客戶或部署產(chǎn)線時(shí)一定用自己簽名的 INF 或安裝包來(lái)裝驅(qū)動(dòng)。要不然客戶機(jī)器上 Zadig 一操作設(shè)備管理器里驅(qū)動(dòng)路徑可能亂七八糟運(yùn)維說(shuō)都說(shuō)不清楚。3. 上位機(jī)代碼從打開(kāi)設(shè)備到收發(fā)數(shù)據(jù)3.1 打開(kāi)設(shè)備的三種姿勢(shì)上位機(jī)開(kāi)發(fā)我用的是 C#.NET Framework 和 .NET 6/8 都能跑。winusb 的 API 本身是 C 接口C# 需通過(guò) P/Invoke 調(diào)用。這里有個(gè)選擇直接 P/Invoke 所有 WinUSB API或者用 libusb 的 .NET 封裝比如 LibUsbDotNet。直接 P/Invoke 的好處是控制力強(qiáng)沒(méi)有額外依賴適合很簡(jiǎn)單的場(chǎng)景。但也有麻煩每次都要寫 DllImport、IntPtr、Marshalling錯(cuò)誤處理還特別繁瑣。LibUsbDotNet 則封裝了設(shè)備枚舉、熱插拔、批量傳輸?shù)裙δ艽a會(huì)簡(jiǎn)潔不少。不過(guò)它底層默認(rèn)用的是 libusb-win32 驅(qū)動(dòng)而不是 winusb需要把驅(qū)動(dòng)設(shè)成 WinUSB 后指定使用 WinUsb 驅(qū)動(dòng)模式或者設(shè)置 config 為 legacy。我最終選的是 P/Invoke 方案因?yàn)轫?xiàng)目里只需要打開(kāi)一個(gè)設(shè)備、一個(gè) IN 端點(diǎn)、一個(gè) OUT 端點(diǎn)邏輯不復(fù)雜。但如果設(shè)備支持多個(gè)接口、需要同時(shí)處理多路通道我建議你還是用封裝庫(kù)不然 P/Invoke 的參數(shù)會(huì)多到你崩潰。打開(kāi)設(shè)備的核心思路先通過(guò) SetupAPI 枚舉設(shè)備接口找到包含必要 VID/PID 的接口路徑再調(diào)用 CreateFile 拿到句柄最后用 WinUsb_Initialize 獲取 WinUSB 接口句柄。關(guān)鍵偽代碼如下// 1. 枚舉設(shè)備接口 Guid winusbGuid new Guid(CDB3B5AD-098B-4A88-B5F5-2B51A2D3F8A1); // WINUSB GUID // 使用 SetupDiGetClassDevs / SetupDiEnumDeviceInterfaces 找到設(shè)備路徑 // 2. 打開(kāi)設(shè)備文件 IntPtr hDevice CreateFile(devicePath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, IntPtr.Zero, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, IntPtr.Zero); // 3. 獲取 WinUSB 接口句柄 WinUsb_Initialize(hDevice, out IntPtr winUsbHandle);這里注意CreateFile 的共享模式必須設(shè)置 FILE_SHARE_READ | FILE_SHARE_WRITE否則后續(xù)重新打開(kāi)設(shè)備會(huì)失敗。WinUsb_Initialize 成功之后CreateFile 得到的句柄可以關(guān)掉了winUsbHandle 才是后續(xù)真正要用的接口句柄。3.2 端點(diǎn)選型與收發(fā)流程一套健壯的通信鏈路端點(diǎn)的角色要?jiǎng)澐智宄Ｎ伊?xí)慣用 BULK OUT 作為命令下發(fā)通道BULK IN 作為數(shù)據(jù)回傳通道中斷端點(diǎn)只在需要低延遲事件通知時(shí)使用。BULK 傳輸是最適合大數(shù)據(jù)量的但它不保證實(shí)時(shí)性也不保證單個(gè)事務(wù)的延遲。如果設(shè)備要做實(shí)時(shí)性強(qiáng)的操作比如電機(jī)控制或過(guò)程保護(hù)請(qǐng)把緊急事件放到中斷端點(diǎn)或單獨(dú)的控制傳輸里。USB 協(xié)議里 BULK 端點(diǎn)事務(wù)是有重試機(jī)制的對(duì)吞吐量比較有利但對(duì)實(shí)時(shí)性沒(méi)有幫助。讀數(shù)據(jù)時(shí)WinUsb_ReadPipe 調(diào)用需要注意幾個(gè)參數(shù)uint bytesRead; bool success WinUsb_ReadPipe(winUsbHandle, 0x81, buffer, bufferLength, out bytesRead, IntPtr.Zero);第一個(gè)參數(shù) 0x81 是端點(diǎn)地址bit7 為 1 表示 IN 端點(diǎn)如果設(shè)備是 0x82那就傳 0x82。bufferLength 建議設(shè)置為端點(diǎn)最大包的整數(shù)倍這樣一次 Read 會(huì)盡量填充整個(gè) buffer。WinUsb_ReadPipe 每次調(diào)用只返回一批當(dāng)前可用的數(shù)據(jù)不會(huì)“粘包”這點(diǎn)比串口好一些因?yàn)?USB 的包邊界是明確的。但是如果是連續(xù)的數(shù)據(jù)流上位機(jī)需要自己做分包、組包和校驗(yàn)而不能期待一次 Read 就拿到完整一幀數(shù)據(jù)。我的做法是約定每幀固定長(zhǎng)度比如 1024 字節(jié)前 4 字節(jié)是幀頭中間是 payload后 2 字節(jié)是 CRC16。上位機(jī)建立一個(gè)“接收緩沖 狀態(tài)機(jī)”不斷把每次讀到的數(shù)據(jù)填充進(jìn)緩沖解析幀頭、長(zhǎng)度、CRC直到拼出完整的一幀。3.3 超時(shí)與遷移異步 IO 的實(shí)踐心得WinUsb_ReadPipe 和 WritePipe 都有一個(gè)超時(shí)參數(shù)通過(guò) WinUsb_SetPipePolicy 設(shè)置比如uint policy PIPE_TRANSFER_TIMEOUT; uint timeout 1000; // 1秒 WinUsb_SetPipePolicy(winUsbHandle, 0x81, policy, timeout);如果不設(shè)置默認(rèn)超時(shí)系統(tǒng)默認(rèn)可能是一直等待程序容易莫名其妙卡死。所以我第一個(gè)建議任何讀寫操作都設(shè)置超時(shí)并且把超時(shí)時(shí)間設(shè)成一個(gè)合理的值比如 1-3 秒。這樣即使設(shè)備固件 bug 導(dǎo)致不返回?cái)?shù)據(jù)上位機(jī)不會(huì)整個(gè)線程掛住。另外一個(gè)經(jīng)驗(yàn)是BULK 傳輸在高頻、大數(shù)據(jù)量的場(chǎng)景下同步讀寫容易把 UI 線程卡死或者掉幀建議用 WinUsb_ReadPipe 的 overlapped 版本或者把讀寫放到獨(dú)立線程/Task 里。我實(shí)測(cè)下來(lái)用 .NET 的 Task.Run 包裹讀寫函數(shù)再在 UI 線程通過(guò) BeginInvoke 更新數(shù)據(jù)顯示界面流暢度要比直接在 UI 線程里循環(huán)讀數(shù)據(jù)好得多。再說(shuō)一個(gè)比較隱藏的點(diǎn)同一時(shí)刻對(duì)同一個(gè)端點(diǎn)發(fā)起多個(gè)異步 IO 是不允許的必須等前一個(gè)讀操作完成后才能發(fā)下一個(gè)。因?yàn)?WinUSB 內(nèi)部對(duì)每個(gè)端點(diǎn)的 IO 有一個(gè)“pending”標(biāo)記兩個(gè)未完成的讀請(qǐng)求會(huì)互相沖突。所以如果你用異步模式寫循環(huán)讀一定要做好信號(hào)量或者 Channel保證同一端點(diǎn)在任一時(shí)刻最多只有一個(gè)掛起的讀取請(qǐng)求。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 驅(qū)動(dòng)裝不上、設(shè)備有感嘆號(hào)這個(gè)是我遇到的最頻繁的問(wèn)題。設(shè)備管理器里看到 USB 設(shè)備顯示黃色感嘆號(hào)常見(jiàn)原因有三個(gè)INF 里 VID/PID 不匹配。這種情況設(shè)備能枚舉但系統(tǒng)找不到對(duì)應(yīng)驅(qū)動(dòng)。INF 文件編碼問(wèn)題或 section 名稱寫錯(cuò)。注意 winusb.inf 的 include/needs 語(yǔ)法64 位系統(tǒng)要匹配 NTamd64 節(jié)點(diǎn)。驅(qū)動(dòng)簽名策略問(wèn)題。如果機(jī)器開(kāi)啟了強(qiáng)制簽名某些修改過(guò)的 INF 可能不被加載需要禁用簽名強(qiáng)制或給驅(qū)動(dòng)簽名。排查方法右鍵設(shè)備看“詳細(xì)信息”里的“硬件 ID”確認(rèn)和 INF 中的 VID/PID 完全一致再用“更新驅(qū)動(dòng)程序”手動(dòng)指向 INF 目錄測(cè)試安裝看系統(tǒng)提示什么錯(cuò)誤。Windows 的事件查看器里也能看到驅(qū)動(dòng)安裝失敗的日志。4.2 數(shù)據(jù)收不到或讀超時(shí)如果驅(qū)動(dòng)正常但 WinUsb_ReadPipe 一直返回超時(shí)或讀取 0 字節(jié)優(yōu)先檢查端點(diǎn)地址是否正確、固件是否真的在往這個(gè)端點(diǎn)發(fā)數(shù)據(jù)。最容易忽略的是固件雖然配置了 IN 端點(diǎn)但實(shí)際發(fā)送時(shí)用的 FIFO 或緩沖區(qū)沒(méi)有數(shù)據(jù)導(dǎo)致 BULK IN 一直 NAK上位機(jī)就一直等。我通常會(huì)做一個(gè)“回聲測(cè)試”固件收到任意字節(jié)后原樣返回幾個(gè)字節(jié)。上位機(jī)發(fā)一個(gè) 8 字節(jié)的命令看能不能收回來(lái)。如果回聲通說(shuō)明鏈路是雙向的如果只通一個(gè)方向那就是固件或端點(diǎn)配置問(wèn)題。另一個(gè)方向的問(wèn)題是 BULK OUT 發(fā)不出去。如果上位機(jī)調(diào)用 WinUsb_WritePipe 返回 false錯(cuò)誤碼為 ERROR_GEN_FAILURE大概率是設(shè)備固件沒(méi)有及時(shí)讀取 OUT 端點(diǎn)或者固件根本沒(méi)有啟動(dòng)接收。USB 的 OUT 端點(diǎn)如果沒(méi)有被設(shè)備接收主機(jī)側(cè)可能會(huì)因?yàn)槌瑫r(shí)或重試失敗而報(bào)錯(cuò)。4.3 抓包工具USBlyzer 與 Wireshark遇到棘手問(wèn)題不要猜協(xié)議直接用抓包工具。Windows 下 USB 抓包常用的方案有兩個(gè)USBlyzer 和 Wireshark USBPcap。USBlyzer 是商業(yè)軟件但功能很全可以看每個(gè) USB 請(qǐng)求的詳情包括控制傳輸、BULK 傳輸?shù)臅r(shí)序和數(shù)據(jù)。Wireshark 配 USBPcap 是免費(fèi)方案抓包時(shí)選對(duì) USB 總線過(guò)濾條件可以用usb.device_address 3 usb.transfer_type 0x03看某個(gè)設(shè)備的 BULK 傳輸。我抓包時(shí)最喜歡看的是“Data Transfer”的 return 狀態(tài)和實(shí)際傳輸字節(jié)數(shù)這能直接區(qū)分“設(shè)備 NAK 導(dǎo)致主機(jī)重試”和“數(shù)據(jù)已發(fā)出但上位機(jī)沒(méi)解析出來(lái)”。有一次我卡了很久——大量數(shù)據(jù)在 USB 層已經(jīng)成功傳輸?shù)衔粰C(jī)狀態(tài)機(jī)寫錯(cuò)了導(dǎo)致解析出來(lái)的幀全部 CRC 錯(cuò)誤。如果不是抓包確認(rèn) USB 層沒(méi)問(wèn)題我不會(huì)想到去查協(xié)議解析邏輯。4.4 吞吐量上不去的常見(jiàn)原因如果實(shí)測(cè)吞吐量和理論值差很多先從這幾個(gè)方向檢查錯(cuò)誤地使用中斷端點(diǎn)傳大數(shù)據(jù)中斷端點(diǎn)單個(gè)事務(wù)最多 64 字節(jié)全速或 1024 字節(jié)高速天生不適合大批量傳輸。BULK 端點(diǎn) buffer 太小上位機(jī)每讀一次只拿回幾百字節(jié)造成大量 USB 總線空轉(zhuǎn)。建議 buffer 至少要等于端點(diǎn)最大包的整數(shù)倍比如 512 * 16 8192 字節(jié)。上位機(jī)在每次讀操作之間做了太多業(yè)務(wù)邏輯導(dǎo)致總線空閑。要么加緩存要么用異步循環(huán)讀讓數(shù)據(jù)持續(xù)回流。固件端發(fā)送邏輯沒(méi)有用“雙緩沖”或連續(xù) DMA而是發(fā)一包等一包 ACK也會(huì)明顯拉低帶寬。我項(xiàng)目里把上位機(jī) buffer 從 512 字節(jié)改到 16KB同樣的固件實(shí)測(cè)吞吐從不到 5 MB/s 提升到 15 MB/s 以上這個(gè)優(yōu)化立竿見(jiàn)影。所以遇到吞吐量問(wèn)題先檢查 buffer 大小再去看固件的發(fā)送策略。5. 工程落地從能通到好用5.1 協(xié)議設(shè)計(jì)別偷懶winusb 通信的上層協(xié)議我強(qiáng)烈建議設(shè)計(jì)成“幀頭 命令字 長(zhǎng)度 數(shù)據(jù) 校驗(yàn)”的結(jié)構(gòu)不要用裸字節(jié)流裸奔。原因很簡(jiǎn)單BULK 傳輸雖然包邊界清晰但上層業(yè)務(wù)數(shù)據(jù)可能跨包、也可能一包里有多個(gè)命令沒(méi)有協(xié)議邊界解析時(shí)一定會(huì)亂。我常用的幀格式[0xAA 0x55] [CmdID(1字節(jié))] [Length(2字節(jié),小端)] [Payload(Length字節(jié))] [CRC16(2字節(jié))]上位機(jī)建立接收緩沖按狀態(tài)機(jī)查找?guī)^然后讀長(zhǎng)度、收滿 payload、校驗(yàn) CRC。CRC 用 CRC16-CCITT 或者 CRC32 都行計(jì)算量不大查錯(cuò)效果也夠用。發(fā)送命令時(shí)按同一格式組包后交給 WinUsb_WritePipe。這樣無(wú)論數(shù)據(jù)多亂協(xié)議層都能自愈不會(huì)因?yàn)榘氚?、粘包?dǎo)致死鎖。5.2 多設(shè)備與熱插拔處理winusb 同時(shí)只允許一個(gè)應(yīng)用打開(kāi)同一個(gè)設(shè)備實(shí)例但系統(tǒng)里可以同時(shí)插入多個(gè) VID/PID 相同的設(shè)備這就出現(xiàn)了設(shè)備路徑選擇的問(wèn)題。枚舉設(shè)備接口時(shí)可以通過(guò) SetupDiGetDeviceInterfaceDetail 拿到每個(gè)設(shè)備的 instance ID然后按 USB 端口號(hào)或父設(shè)備信息區(qū)分。如果你只有一個(gè)設(shè)備那選擇枚舉到的第一個(gè)路徑即可。熱插拔處理更是必備功能。我的做法是在后臺(tái)輪詢?cè)O(shè)備是否存在比如每 500ms 調(diào)用一次 SetupDiGetClassDevs對(duì)比設(shè)備路徑列表。檢測(cè)到設(shè)備插入后自動(dòng)打開(kāi)并初始化檢測(cè)到設(shè)備移除后釋放句柄并通知 UI 層設(shè)備離線。重新插入后自動(dòng)重連。這套邏輯聽(tīng)起來(lái)簡(jiǎn)單但一旦沒(méi)做客戶可能隨手一拔線上位機(jī)就得重啟。項(xiàng)目中我至少被這個(gè)問(wèn)題折磨過(guò)兩輪后來(lái)老老實(shí)實(shí)把熱插拔模塊寫了。5.3 上位機(jī)的錯(cuò)誤處理與日志開(kāi)發(fā)過(guò)程里我發(fā)現(xiàn)很多問(wèn)題不是一次出現(xiàn)的而是偶發(fā)。比如連續(xù)傳輸大文件時(shí)偶爾失敗或者設(shè)備長(zhǎng)時(shí)間空閑后第一次命令超時(shí)。這種時(shí)候如果沒(méi)有日志排查就像大海撈針。我建議上位機(jī)里至少打三種日志系統(tǒng)級(jí)日志打開(kāi)設(shè)備、關(guān)閉設(shè)備、驅(qū)動(dòng)初始化是否成功。USB 讀寫日志每次讀寫超時(shí)、失敗、重試的次數(shù)。業(yè)務(wù)協(xié)議日志收到/發(fā)送的幀類型、長(zhǎng)度、CRC 結(jié)果。不要怕日志太多用環(huán)形緩沖或者文件日志都行但一定要保留現(xiàn)場(chǎng)。曾經(jīng)有一次客戶反饋“跑 20 分鐘后通信卡死”遠(yuǎn)程排查根本沒(méi)法復(fù)現(xiàn)。好在日志里記錄了錯(cuò)誤碼是 ERROR_SEM_TIMEOUT一搜就定位到是 BULK IN 超時(shí)進(jìn)一步追查發(fā)現(xiàn)是固件的端點(diǎn) FIFO 溢出導(dǎo)致一直 NAK問(wèn)題很快解決。5.4 固件側(cè)的幾個(gè)配合要點(diǎn)雖然這篇主要說(shuō)上位機(jī)但固件側(cè)有幾個(gè)配合不好會(huì)直接拉垮整個(gè)鏈路的地方我簡(jiǎn)單提一下端點(diǎn) FIFO 大小要合理。BULK IN 端點(diǎn)的 FIFO 最好大于一幀數(shù)據(jù)否則 DPSRAM 可能溢出。固件發(fā)送前要檢查端點(diǎn)是否忙。如果上一個(gè)事務(wù)還沒(méi)完成繼續(xù)寫 FIFO 會(huì)導(dǎo)致數(shù)據(jù)覆蓋。固件接收端不要從 OUT 端點(diǎn)讀一包就處理特別久否則主機(jī)的寫請(qǐng)求會(huì)堆積超時(shí)。最好用 DMA 或中斷把數(shù)據(jù)搬進(jìn)內(nèi)存處理邏輯放主循環(huán)。商用量產(chǎn)前做掉電、拔線、異常復(fù)位測(cè)試很多 USB 通信問(wèn)題都是在這種極端場(chǎng)景下暴露的。類似地上位機(jī)側(cè)也要針對(duì)固件異常復(fù)位做處理設(shè)備重新枚舉后句柄會(huì)失效上位機(jī)必須捕獲設(shè)備移除事件并重新打開(kāi)。這套“設(shè)備消失-重新上線”的循環(huán)邏輯一定要在項(xiàng)目初期就寫好不然后面改起來(lái)很痛苦。整個(gè)項(xiàng)目做下來(lái)我的實(shí)際感受是winusb 方案的技術(shù)門檻并不是高到讓人望而卻步真正的難點(diǎn)在于“枚舉—驅(qū)動(dòng)—傳輸—協(xié)議”這條鏈路的每一層都有一個(gè)“看不見(jiàn)的坑”比如端點(diǎn) buffer 太小、INF 編碼錯(cuò)誤、異步 IO 重疊等等。如果你正打算做類似的上位機(jī) USB 通信建議先把驅(qū)動(dòng)綁定和硬件枚舉這一關(guān)打通再寫收發(fā)邏輯最后再優(yōu)化吞吐和穩(wěn)定性。一步一步來(lái)這套方案是值得投入的。本文還有配套的精品資源點(diǎn)擊獲取