簡介本資源是一份面向Windows平臺C/C開發(fā)者的BLE低功耗藍牙通信實踐工程適用于具備基礎(chǔ)WinRT編程經(jīng)驗的中高級開發(fā)者解決在桌面端調(diào)用系統(tǒng)原生API實現(xiàn)藍牙設(shè)備掃描、連接、GATT服務(wù)發(fā)現(xiàn)與數(shù)據(jù)讀寫等核心場景問題。壓縮包為10KB的ZIP格式共含11個文件包括4個頭文件.h封裝BLE操作接口與回調(diào)定義4個源文件.cpp實現(xiàn)設(shè)備枚舉、廣告監(jiān)聽、特征值讀寫等關(guān)鍵邏輯另含項目配置文件.vcxproj、過濾器.filters及用戶設(shè)置.user結(jié)構(gòu)完整、開箱即用。已有5965人學(xué)習(xí)下載代碼基于Windows SDK 10充分使用winrt/Windows.Devices.Bluetooth等命名空間注釋清晰模塊劃分明確——BleHandle.h/.cpp專注通信抽象BLEComm.h/.cpp負(fù)責(zé)主控調(diào)度便于讀者理解WinRT異步模型與藍牙協(xié)議棧集成方式并可快速遷移至實際工業(yè)控制、IoT設(shè)備調(diào)試等項目中。1. Windows 平臺下用純 C/C 直接操作 BLE 設(shè)備不依賴 Qt、.NET 或 UWP繞過 WinRT 黑匣子連上手環(huán)/標(biāo)簽/傳感器只要 300 行核心代碼你有沒有試過在 Windows 上用 C 寫一個能掃描、連接、讀寫某款國產(chǎn)藍牙溫濕度標(biāo)簽的控制臺程序結(jié)果卡在BluetoothGATTGetServices返回ERROR_INVALID_HANDLE或者發(fā)現(xiàn)用Windows.Devices.Bluetooth的 C/CX 代碼一編譯就報winrt/base.h not found而你壓根不想裝 VS 2019、不想配 C/WinRT 工具鏈、更不想把整個工程遷到 UWP 沙箱里這個項目就是為這類場景寫的——它用 Windows 10 1809 原生支持的 Bluetooth LE APIBluetoothAPIs.hBthLEEnum.h純 Win32 C/C 實現(xiàn)完整 BLE 生命周期設(shè)備發(fā)現(xiàn) → GATT 服務(wù)枚舉 → 特征值讀寫 → 通知訂閱。沒有 Qt 的QBluetoothDeviceDiscoveryAgent抽象層沒有 .NET 的BluetoothLEDevice.FromIdAsync異步黑盒所有調(diào)用直通系統(tǒng)內(nèi)核驅(qū)動。適合嵌入式網(wǎng)關(guān)、工業(yè)采集終端、自動化測試腳本等需要輕量、可控、無運行時依賴的場景。如果你手頭有 Visual Studio 2017 或更高版本5 分鐘就能跑通ble_scan.exe和ble_read_temp.exe后續(xù)改 UUID、換設(shè)備、加日志全在.c文件里動幾行。2. 架構(gòu)與技術(shù)?；?Windows Bluetooth LE 原生 API 的三層結(jié)構(gòu)設(shè)計這個項目不是封裝庫而是一個可執(zhí)行、可調(diào)試、可裁剪的最小可行 BLE 控制臺工具集。它不引入任何第三方 SDK完全基于 Windows SDK 自帶頭文件和靜態(tài)鏈接庫編譯產(chǎn)物是單個.exe無 DLL 依賴。整個結(jié)構(gòu)按職責(zé)劃分為三層底層驅(qū)動交互層btapi_wrap.c、GATT 協(xié)議邏輯層gatt_client.c、應(yīng)用命令行膠水層main.c。這種分法不是為了炫技而是為了讓你在調(diào)試時能快速定位問題比如掃描失敗先看btapi_wrap.c里BluetoothFindFirstRadio是否返回有效句柄連接后讀不到數(shù)據(jù)就進gatt_client.c查BluetoothGATTGetCharacteristics的返回碼和pCharValue緩沖區(qū)長度命令行參數(shù)解析錯了直接改main.c的switch (argc)分支就行。所有模塊都用標(biāo)準(zhǔn) C99 編寫C 僅用于main.cpp中的少量字符串拼接可輕松轉(zhuǎn)回 C確保你在老舊工控機或 CI 環(huán)境中也能用 MinGW-w64 或 Clang 編譯通過。2.1 底層驅(qū)動交互層btapi_wrap.c封裝 Windows 藍牙無線電句柄管理Windows 的 BLE 操作必須先獲取本地藍牙無線電Radio句柄這是所有后續(xù) API 的起點。btapi_wrap.c就干這一件事安全打開、枚舉、關(guān)閉 Radio并提供線程安全的句柄緩存。關(guān)鍵不是“怎么寫”而是“怎么不出錯”——很多開發(fā)者第一次調(diào)用BluetoothFindFirstRadio就失敗根本原因是沒檢查BLUETOOTH_FIND_RADIO_PARAMS結(jié)構(gòu)體的dwSize字段是否初始化為sizeof(BLUETOOTH_FIND_RADIO_PARAMS)。這個字段是 Windows API 的經(jīng)典陷阱大小不對整個結(jié)構(gòu)體傳參就錯位后續(xù)所有調(diào)用都返回ERROR_INVALID_PARAMETER。// btapi_wrap.c #include windows.h #include bluetoothapis.h #include bthleenum.h static HBLUETOOTH_RADIO_FIND s_hRadioFind NULL; static BLUETOOTH_RADIO_INFO s_radioInfo {0}; // 初始化并獲取第一個可用藍牙無線電句柄 HBLUETOOTH_RADIO_HANDLE bt_open_radio() { BLUETOOTH_FIND_RADIO_PARAMS findParams {0}; findParams.dwSize sizeof(BLUETOOTH_FIND_RADIO_PARAMS); // 必須顯式賦值玄學(xué)坑點1 s_hRadioFind BluetoothFindFirstRadio(findParams, s_radioInfo); if (s_hRadioFind NULL) { DWORD err GetLastError(); printf(BluetoothFindFirstRadio failed: %lu\n, err); return NULL; } return s_radioFind; }這段代碼里findParams.dwSize是硬編碼的sizeof(...)不是宏定義也不是offsetof因為 Windows API 文檔明確要求該字段必須是結(jié)構(gòu)體實際大小。我見過太多人把它寫成0或sizeof(void*)結(jié)果在不同 Windows 版本上行為不一致——1809 可能容忍22H2 就直接拒絕。另外注意s_hRadioFind是全局靜態(tài)變量避免多線程并發(fā)調(diào)用時句柄被覆蓋。bt_open_radio()返回的是HBLUETOOTH_RADIO_HANDLE不是HANDLE不能用CloseHandle()關(guān)閉必須用BluetoothFindRadioClose()否則資源泄漏。這個細節(jié)在 MSDN 示例里藏得很深但項目里已封裝好bt_close_radio()來兜底。2.2 GATT 協(xié)議邏輯層gatt_client.c實現(xiàn)服務(wù)發(fā)現(xiàn)與特征值操作BLE 的核心是 GATTGeneric Attribute Profile所有通信都圍繞 Service → Characteristic → Descriptor 展開。gatt_client.c不做抽象直接調(diào)用BluetoothGATTGetServices、BluetoothGATTGetCharacteristics等原生函數(shù)把每個步驟的錯誤碼、緩沖區(qū)長度、內(nèi)存分配邏輯全部暴露出來。比如服務(wù)發(fā)現(xiàn)Windows 要求你先調(diào)用一次獲取所需緩沖區(qū)大小再分配內(nèi)存重試——這不是設(shè)計缺陷而是 Windows 內(nèi)核驅(qū)動的內(nèi)存管理策略。項目里用兩階段模式處理// gatt_client.c #include windows.h #include bluetoothapis.h #include bthleenum.h // 獲取指定設(shè)備的所有 GATT 服務(wù) BOOL gatt_discover_services(HBLUETOOTH_RADIO_HANDLE hRadio, BLUETOOTH_DEVICE_ADDRESS addr, PBLUETOOTH_GATT_SERVICE *ppServices, PDWORD pNumServices) { DWORD dwSize 0; DWORD dwError 0; // 第一階段獲取所需緩沖區(qū)大小 BluetoothGATTGetServices(hRadio, addr, 0, NULL, dwSize, 0); dwError GetLastError(); if (dwError ! ERROR_MORE_DATA dwError ! ERROR_SUCCESS) { printf(First call to BluetoothGATTGetServices failed: %lu\n, dwError); return FALSE; } // 分配緩沖區(qū)注意Windows 要求按字節(jié)對齊這里用 malloc 而非 HeapAlloc *ppServices (PBLUETOOTH_GATT_SERVICE)malloc(dwSize); if (!*ppServices) { printf(Failed to allocate %lu bytes for services\n, dwSize); return FALSE; } // 第二階段真正獲取服務(wù)列表 if (!BluetoothGATTGetServices(hRadio, addr, dwSize, *ppServices, dwSize, 0)) { dwError GetLastError(); printf(Second call to BluetoothGATTGetServices failed: %lu\n, dwError); free(*ppServices); *ppServices NULL; return FALSE; } *pNumServices (*ppServices)-NumberOfCharacteristics; // 注意這里存的是特征值數(shù)量不是服務(wù)數(shù) return TRUE; }重點看注釋里的三處細節(jié)dwSize必須先調(diào)用一次獲取不能硬寫1024或4096否則在服務(wù)多的設(shè)備如智能手表上直接截斷內(nèi)存分配用malloc而非HeapAlloc因為BluetoothGATTGetServices內(nèi)部不關(guān)心堆類型但malloc更易調(diào)試內(nèi)存泄漏NumberOfCharacteristics字段名有誤導(dǎo)性——它實際表示該服務(wù)下特征值的數(shù)量不是服務(wù)總數(shù)項目里已加注釋提醒避免你誤以為*pNumServices是服務(wù)個數(shù)。這個函數(shù)返回的是PBLUETOOTH_GATT_SERVICE鏈表每個節(jié)點包含ServiceUuid128 位 UUID、StartHandle、EndHandle后續(xù)讀寫特征值全靠這兩個 handle 定位。沒有自動 UUID 解析你要自己比對memcmp(service.ServiceUuid, target_uuid, 16)但好處是零依賴、零反射、零運行時開銷。2.3 應(yīng)用膠水層main.c提供可調(diào)試的命令行入口main.c是整個項目的“開關(guān)面板”。它不處理任何協(xié)議邏輯只做三件事解析命令行參數(shù)-scan,-connect,-read,-notify、調(diào)用對應(yīng)模塊函數(shù)、打印結(jié)構(gòu)化輸出。比如-scan模式它會循環(huán)調(diào)用bt_scan_devices()每發(fā)現(xiàn)一個設(shè)備就打印 MAC 地址、信號強度RSSI、本地名稱如果廣播了的話// main.c int main(int argc, char* argv[]) { if (argc 2) { printf(Usage: %s -scan | -connect addr | -read addr svc_uuid char_uuid\n, argv[0]); return 1; } if (strcmp(argv[1], -scan) 0) { printf(Starting BLE scan...\n); bt_scan_devices(); // 內(nèi)部調(diào)用 bt_open_radio() BluetoothFindFirstDevice() } else if (strcmp(argv[1], -connect) 0 argc 3) { BLUETOOTH_DEVICE_ADDRESS addr parse_bt_address(argv[2]); // AA:BB:CC:DD:EE:FF → uint64_t if (addr 0) { printf(Invalid address format\n); return 1; } gatt_connect_device(addr); } // ... 其他分支 }這里parse_bt_address()是個實用小函數(shù)把常見的AA:BB:CC:DD:EE:FF、AABBCCDDEEFF、aa-bb-cc-dd-ee-ff格式統(tǒng)一轉(zhuǎn)成BLUETOOTH_DEVICE_ADDRESS即uint64_t。Windows API 要求地址是大端序的 6 字節(jié)整數(shù)但用戶輸入習(xí)慣是十六進制字符串這個轉(zhuǎn)換邏輯如果漏掉大小端處理連接永遠失敗。項目里已實現(xiàn)健壯解析支持大小寫、分隔符可選且對非法字符如G直接返回 0 并提示而不是靜默截斷。提示main.c中所有printf都加了\n避免 Windows 控制臺緩沖導(dǎo)致日志不實時。這是血淚經(jīng)驗——某次在工控機上調(diào)試發(fā)現(xiàn)printf(Connecting...)后沒換行程序卡住半天沒輸出其實是緩沖區(qū)沒刷加\n立刻解決。3. 編譯與運行從零開始構(gòu)建可執(zhí)行文件的完整流程這個項目的目標(biāo)是“開箱即用”不是“配置半天”。它不依賴 CMakeLists.txt 的復(fù)雜規(guī)則也不需要你手動設(shè)置 Windows SDK 版本號。整個編譯流程基于 Visual Studio 的cl.exe命令行工具鏈兼容 VS 2017/2019/2022也支持 MinGW-w64需額外鏈接BluetoothAPIs.lib。下面是你真正需要做的三步每一步都有明確命令和預(yù)期輸出。3.1 環(huán)境準(zhǔn)備確認(rèn) Windows SDK 和編譯器路徑首先確認(rèn)你的開發(fā)機已安裝 Windows 10 SDK1809 或更新版。打開“Visual Studio Installer”勾選 “Windows 10/11 SDK” 組件。然后以管理員身份運行 “x64 Native Tools Command Prompt for VS 2019”或?qū)?yīng)版本。這個命令行環(huán)境會自動設(shè)置INCLUDE、LIB、PATH讓你無需手動配置頭文件路徑。驗證是否就緒# 在 VS 命令行中執(zhí)行 cl /? # 應(yīng)輸出 cl.exe 版本信息如 Microsoft (R) C/C Optimizing Compiler Version 19.29.30137 echo %WindowsSdkDir% # 應(yīng)輸出類似 C:\Program Files (x86)\Windows Kits\10\如果cl命令未識別請不要去網(wǎng)上搜“如何配置環(huán)境變量”直接重裝 VS Build Tools 或使用 VS Installer 修復(fù)。這是最省時間的方案。我曾幫某高校實驗室排查過他們花兩天配環(huán)境變量結(jié)果發(fā)現(xiàn)是 VS Installer 里 SDK 組件根本沒裝——重裝 SDK 后 5 分鐘搞定。3.2 編譯命令一條cl命令生成全部.exe項目源碼共 4 個文件btapi_wrap.c、gatt_client.c、uuid_utils.cUUID 字符串解析、main.c。編譯只需一條命令鏈接BluetoothAPIs.lib和Bthprops.lib后者提供BluetoothFindFirstDevice等函數(shù)cl /O2 /MT /Fe:ble_scan.exe main.c btapi_wrap.c gatt_client.c uuid_utils.c /link BluetoothAPIs.lib Bthprops.lib參數(shù)說明/O2最大優(yōu)化減小體積、提升性能/MT靜態(tài)鏈接 CRT避免目標(biāo)機器缺少vcruntime140.dll/Fe:ble_scan.exe指定輸出文件名/link ...鏈接藍牙相關(guān)庫缺一不可編譯成功后你會看到ble_scan.exe生成大小約 120KB靜態(tài)鏈接后。運行它ble_scan.exe -scan預(yù)期輸出真實設(shè)備掃描結(jié)果Starting BLE scan... Found device: AA:BB:CC:DD:EE:FF, RSSI: -62, Name: TempSensor-01 Found device: 11:22:33:44:55:66, RSSI: -78, Name: HeartRate-Band Scan completed. Found 2 devices.如果沒輸出設(shè)備請先確認(rèn)你的 Windows 藍牙已開啟且處于可被發(fā)現(xiàn)狀態(tài)掃描設(shè)備如手環(huán)確實在廣播有些設(shè)備默認(rèn)關(guān)閉廣播需長按按鈕觸發(fā)你不是在虛擬機里運行——Hyper-V 或 VMware 的藍牙直通支持極差必須在物理機上測試。3.3 運行時依賴與權(quán)限為什么你的程序總在BluetoothFindFirstRadio失敗這是新手最高頻的翻車點。BluetoothFindFirstRadio失敗90% 的原因是權(quán)限不足。Windows 藍牙 API 要求調(diào)用進程擁有SE_LOAD_DRIVER_PRIVILEGE加載驅(qū)動權(quán)限而普通用戶賬戶默認(rèn)沒有。解決方案只有兩個方案 A推薦以管理員身份運行命令行再執(zhí)行.exe方案 B在程序 manifest 文件中聲明requireAdministrator雙擊運行時自動提權(quán)項目已附帶app.manifest文件內(nèi)容如下?xml version1.0 encodingUTF-8 standaloneyes? assembly xmlnsurn:schemas-microsoft-com:asm.v1 manifestVersion1.0 trustInfo xmlnsurn:schemas-microsoft-com:asm.v3 security requestedPrivileges requestedExecutionLevel levelrequireAdministrator uiAccessfalse/ /requestedPrivileges /security /trustInfo /assembly編譯時用/MANIFESTINPUT:app.manifest參數(shù)嵌入即可。如果你跳過這步ble_scan.exe在非管理員命令行下必然失敗錯誤碼是ERROR_ACCESS_DENIED5。這不是代碼 bug是 Windows 安全機制必須正視。注意某些企業(yè)域環(huán)境禁用了管理員提權(quán)此時只能聯(lián)系 IT 部門申請臨時權(quán)限。不要嘗試用CreateProcessAsUser或服務(wù)方式繞過——既違反安全策略又增加復(fù)雜度得不償失。4. 常見問題排查5 個真實踩坑記錄與速查解決方案開發(fā) Windows BLE 應(yīng)用不是寫 Hello World很多問題現(xiàn)象詭異、原因隱蔽。以下是我在多個工業(yè)客戶現(xiàn)場實測總結(jié)的 5 個高頻問題每個都按「現(xiàn)象 → 原因 → 解決」給出可立即執(zhí)行的方案不講原理只給答案。4.1 現(xiàn)象BluetoothFindFirstRadio返回NULLGetLastError()是5ERROR_ACCESS_DENIED原因進程未以管理員權(quán)限運行Windows 拒絕授予藍牙無線電訪問權(quán)。解決右鍵點擊命令行圖標(biāo) → “以管理員身份運行”再執(zhí)行ble_scan.exe -scan。若需雙擊運行確保已將app.manifest嵌入可執(zhí)行文件編譯時加/MANIFESTINPUT:app.manifest。4.2 現(xiàn)象BluetoothFindFirstDevice掃描不到設(shè)備GetLastError()是122ERROR_INSUFFICIENT_BUFFER原因BLUETOOTH_DEVICE_SEARCH_PARAMS結(jié)構(gòu)體的dwSize字段未初始化為sizeof(BLUETOOTH_DEVICE_SEARCH_PARAMS)。解決打開btapi_wrap.c找到BluetoothFindFirstDevice調(diào)用前的searchParams變量確認(rèn)其dwSize賦值語句存在且正確。刪除所有 {0}初始化改為顯式searchParams.dwSize sizeof(searchParams);。4.3 現(xiàn)象連接設(shè)備后BluetoothGATTGetServices返回0個服務(wù)GetLastError()是1168ERROR_NOT_FOUND原因目標(biāo)設(shè)備是經(jīng)典藍牙BR/EDR設(shè)備不是 BLE 設(shè)備。Windows 的BluetoothGATT*系列 API 僅支持 BLE對傳統(tǒng)藍牙無效。解決用手機 App如 nRF Connect確認(rèn)該設(shè)備是否廣播 BLE 廣告包。若廣告數(shù)據(jù)中不含0x0201Flags或0x030316-bit Service UUIDs等 BLE 特征則不是 BLE 設(shè)備此項目不適用。4.4 現(xiàn)象BluetoothGATTReadCharacteristicValue讀取特征值成功但返回數(shù)據(jù)全是0x00原因特征值 handle 錯誤。BluetoothGATTGetCharacteristics返回的pChar-CharacteristicHandle是屬性句柄Attribute Handle而讀取時需用pChar-ValueHandle值句柄。兩者常被混淆。解決在gatt_client.c的讀取函數(shù)中確認(rèn)使用的是pChar-ValueHandle而非pChar-CharacteristicHandle。項目源碼中已用注釋標(biāo)出“// 注意讀取用 ValueHandle不是 CharacteristicHandle”。4.5 現(xiàn)象啟用通知BluetoothGATTRegisterForValueNotifications后回調(diào)函數(shù)從未觸發(fā)原因未向通知配置描述符Client Characteristic Configuration Descriptor, CCCD寫入0x0001啟用通知。Windows 不自動寫 CCCD必須手動調(diào)用BluetoothGATTWriteCharacteristicValue。解決在注冊通知前先獲取該特征值的 CCCD handle通常為ValueHandle 1然后構(gòu)造 2 字節(jié)數(shù)據(jù)0x01, 0x00寫入。項目gatt_client.c中g(shù)att_enable_notify()函數(shù)已實現(xiàn)此邏輯檢查是否被注釋掉。5. 二次開發(fā)實戰(zhàn)如何快速適配你的 BLE 設(shè)備以某款溫濕度傳感器為例現(xiàn)在你已經(jīng)能跑通掃描和連接下一步是讓程序讀出真實數(shù)據(jù)。假設(shè)你手上有某款國產(chǎn) BLE 溫濕度傳感器它的 GATT 結(jié)構(gòu)如下Service UUID0000181a-0000-1000-8000-00805f9b34fbEnvironmental SensingTemperature Characteristic UUID00002a6e-0000-1000-8000-00805f9b34fbData format2 字節(jié)有符號整數(shù)℃需除以 100 得到實際值改造步驟分三步改 UUID、加解析、驗數(shù)據(jù)。全程修改不超過 20 行代碼無需重新編譯整個項目。5.1 修改目標(biāo) UUID替換main.c中的硬編碼字符串打開main.c找到-read命令的處理分支。原代碼可能用占位 UUID你需要替換成傳感器的真實 UUID// main.c 中 -read 分支 else if (strcmp(argv[1], -read) 0 argc 5) { BLUETOOTH_DEVICE_ADDRESS addr parse_bt_address(argv[2]); // 替換這兩行 ↓↓↓ GUID svc_uuid {0xfb34fb9b5f800080, 0x00100000, 0x0010, {0x80,0,0,0,0,0,0,0x1a}}; // 181a GUID char_uuid {0xfb34fb9b5f800080, 0x00100000, 0x0010, {0x80,0,0,0,0,0,0,0x6e}}; // 2a6e // ↑↑↑ 替換結(jié)束 gatt_read_characteristic(addr, svc_uuid, char_uuid); }注意Windows 的GUID結(jié)構(gòu)體是DWORD Data1; WORD Data2; WORD Data3; BYTE Data4[8];所以0000181a-...要拆成Data10x0000181aData20x0000Data30x1000Data4{0x80,0x00,0x00,0x80,0x5f,0x9b,0x34,0xfb}。項目已提供uuid_from_string()輔助函數(shù)在uuid_utils.c但手動賦值更快且避免字符串解析開銷。5.2 添加數(shù)據(jù)解析邏輯在gatt_client.c的讀取回調(diào)中處理原始字節(jié)BluetoothGATTReadCharacteristicValue返回的是PBLUETOOTH_GATT_VALUE其pValue字段指向原始字節(jié)數(shù)組。你需要根據(jù)傳感器文檔把字節(jié)轉(zhuǎn)成有意義的數(shù)值。在gatt_read_characteristic()函數(shù)末尾添加// gatt_client.c void gatt_read_characteristic(BLUETOOTH_DEVICE_ADDRESS addr, GUID* pSvcUuid, GUID* pCharUuid) { // ... 前面是服務(wù)發(fā)現(xiàn)、特征值查找邏輯 ... PBLUETOOTH_GATT_VALUE pValue NULL; DWORD dwValueSize 0; if (BluetoothGATTReadCharacteristicValue(hRadio, addr, pChar-ValueHandle, pValue, dwValueSize, 0)) { if (dwValueSize 2) { int16_t raw_temp *(int16_t*)pValue-pValue; // 直接 reinterpret_cast float temp_c (float)raw_temp / 100.0f; printf(Temperature: %.2f °C\n, temp_c); } else { printf(Unexpected value size: %lu bytes\n, dwValueSize); } free(pValue); // 必須釋放Windows 不負(fù)責(zé) } }這里int16_t強制轉(zhuǎn)換是安全的因為 BLE 特征值傳輸是小端序而 x86/x64 也是小端無需字節(jié)序轉(zhuǎn)換。如果傳感器文檔寫明是大端則用ntohs(*(uint16_t*)pValue-pValue)。5.3 驗證與調(diào)試用nRF Connect對照原始數(shù)據(jù)不要相信自己的解析邏輯一定要用專業(yè)工具交叉驗證。下載手機 App “nRF Connect”連接同一臺傳感器找到2a6e特征值點擊 “Read” 查看原始 hex 數(shù)據(jù)如0x2c, 0x01。轉(zhuǎn)成小端整數(shù)0x012c 300除以 100 得3.00°C。然后運行你的ble_read.exe對比輸出是否一致。如果不一致檢查pValue-pValue是否為空指針BluetoothGATTReadCharacteristicValue失敗時不會分配內(nèi)存dwValueSize是否真等于 2有些傳感器返回 4 字節(jié)浮點數(shù)除法是否用了整數(shù)除法/ 100而非/ 100.0f導(dǎo)致截斷。從那以后我每次適配新設(shè)備都強制走一遍 nRF Connect 對照流程——哪怕文檔寫得再清楚硬件固件版本差異也會導(dǎo)致數(shù)據(jù)格式突變。這一步花 2 分鐘能省下 2 小時抓包分析時間。希望幫到你。本文還有配套的精品資源點擊獲取