1. 項目概述與核心價值如果你正在或打算涉足物聯(lián)網(wǎng)設(shè)備的開發(fā)尤其是那些需要長時間待機、靠電池供電的傳感器類產(chǎn)品那么低功耗藍牙技術(shù)絕對是你繞不開的核心技能。我接觸過不少項目從智能手環(huán)到醫(yī)療貼片大家遇到的第一個攔路虎往往不是功能實現(xiàn)而是如何讓設(shè)備在有限的電量下“活”得更久。德州儀器的BLE SDK特別是其豐富的示例應(yīng)用就像一位經(jīng)驗豐富的向?qū)軒湍憧焖倜彘T道避開很多新手容易栽進去的坑。這份SDK文檔里列舉的十多個示例遠不止是幾行演示代碼那么簡單。它系統(tǒng)性地展示了如何將一個具體的業(yè)務(wù)需求比如測量心率、血壓通過BLE協(xié)議棧轉(zhuǎn)化成一個穩(wěn)定、可靠、低功耗的無線外設(shè)產(chǎn)品。從最基礎(chǔ)的設(shè)備廣播、連接建立到復(fù)雜的數(shù)據(jù)服務(wù)定義、安全配對乃至電源管理和連接參數(shù)優(yōu)化每一個示例都是一個完整的、可編譯運行的參考設(shè)計。對于開發(fā)者而言其價值在于提供了一個“最佳實踐”的模板你可以直接基于它進行二次開發(fā)極大地縮短了從原理圖到可演示原型的周期。今天我們就以其中最具代表性的血壓傳感器和心率傳感器兩個示例為切入點深入拆解其實現(xiàn)邏輯、關(guān)鍵配置以及在實際開發(fā)中那些文檔里不會明說但至關(guān)重要的經(jīng)驗細節(jié)。無論你是剛接觸BLE的新手還是想深入了解TI協(xié)議棧特點的資深工程師相信都能從中獲得直接的啟發(fā)和可復(fù)用的代碼思路。2. TI BLE SDK示例應(yīng)用整體架構(gòu)解析在深入具體示例之前有必要先理解TI BLE SDK示例應(yīng)用的整體設(shè)計哲學(xué)和代碼組織方式。這能幫助你在修改和移植時清楚地知道該動哪里以及為什么這么動。2.1 基于角色的工程結(jié)構(gòu)TI的示例應(yīng)用嚴格遵循了藍牙SIG定義的“角色”模型。例如血壓/心率示例扮演的是“傳感器”角色而像glucose_collector、simple_central則扮演“收集器”或“中心設(shè)備”角色。這種角色劃分直接體現(xiàn)在工程的文件結(jié)構(gòu)和初始化流程上。每個示例工程的核心通常包含以下幾個關(guān)鍵文件main.c應(yīng)用入口負責(zé)硬件初始化、ICall框架初始化和創(chuàng)建應(yīng)用任務(wù)。app.c或類似命名的應(yīng)用文件應(yīng)用任務(wù)的主體實現(xiàn)了SimpleProfile的回調(diào)函數(shù)處理來自GATT層的事件如連接、斷開、讀/寫/通知請求。peripheral.c或central.c實現(xiàn)了設(shè)備角色外設(shè)或中心設(shè)備的通用操作如廣播控制、連接參數(shù)更新請求等。服務(wù)實現(xiàn)文件如heartrateservice.c、bloodpressureservice.c。這些文件定義了該示例專屬的GATT服務(wù)、特征值及其屬性讀、寫、通知、指示。這里是業(yè)務(wù)邏輯的核心數(shù)據(jù)如何生成、封裝、發(fā)送都在這里完成。實操心得當你需要創(chuàng)建一個新的傳感器類型時最快捷的方式不是從頭開始而是復(fù)制一個最接近的示例比如心率傳感器然后重點修改其對應(yīng)的服務(wù)實現(xiàn)文件。你需要修改服務(wù)UUID、特征值定義以及數(shù)據(jù)模擬或真實采集的邏輯而廣播、連接管理、電源管理這些底層框架幾乎可以復(fù)用。2.2 協(xié)議棧與應(yīng)用的分層ICall機制TI的BLE協(xié)議棧運行在一個獨立的CPU內(nèi)核或任務(wù)中對于CC26xx系列是ROM中的協(xié)議?；騌adio Core。應(yīng)用層代碼通過一個名為ICall的進程間通信機制與協(xié)議棧交互。簡單理解ICall就是一套定義好的消息隊列和API應(yīng)用層通過發(fā)送消息來請求協(xié)議棧執(zhí)行操作如啟動廣播、發(fā)送通知協(xié)議棧也通過回調(diào)消息來通知應(yīng)用層事件如連接建立、特征值被寫入。在示例代碼中你會頻繁看到ICall_registerApp、ICall_wait等函數(shù)。對于初學(xué)者可以暫時不用深究其內(nèi)部機制但必須明白所有與藍牙連接、數(shù)據(jù)收發(fā)相關(guān)的操作最終都需要通過ICall消息來驅(qū)動。例如當你在app.c中收到一個SBP_WRITE_EVT事件表示中心設(shè)備寫入了一個特征值來使能通知你的應(yīng)用代碼需要構(gòu)造一個GATT通知消息并通過GATT_Notification函數(shù)發(fā)送這個函數(shù)內(nèi)部就是通過ICall將請求遞交給協(xié)議棧的。2.3 示例的硬件抽象層與按鍵驅(qū)動幾乎所有示例都依賴SmartRF06評估板上的按鍵和LCD進行交互。這背后是硬件抽象層在起作用。HAL層將具體的硬件操作如讀取某個GPIO引腳的狀態(tài)、控制LCD顯示特定字符抽象成統(tǒng)一的API如HalKeyRead()、HalLcdWriteString()。為什么這很重要當你要將示例代碼移植到自己的硬件板時最需要修改的就是HAL層。TI提供了HAL的源碼你需要根據(jù)自己板子的原理圖重新實現(xiàn)或修改hal_key.c、hal_lcd.c等文件中的函數(shù)。例如你的按鍵可能接在不同的GPIO上或者你根本不用LCD而改用串口打印日志。處理好HAL層是代碼成功移植的第一步。以按鍵處理為例示例中通常采用中斷或輪詢方式檢測按鍵。在heartrate.c的初始化函數(shù)里會調(diào)用HalKeyConfigure()來配置按鍵并注冊一個回調(diào)函數(shù)。當用戶按下“UP”鍵循環(huán)切換數(shù)據(jù)格式時實際上是HAL層檢測到按鍵事件調(diào)用注冊的回調(diào)回調(diào)函數(shù)再根據(jù)當前連接狀態(tài)執(zhí)行HeartRate_Notify來發(fā)送不同格式的心率數(shù)據(jù)。3. 血壓傳感器示例深度剖析與實操血壓傳感器示例是一個嚴格按照藍牙SIG《血壓剖面規(guī)范》實現(xiàn)的經(jīng)典案例。它模擬了一個專業(yè)的醫(yī)療設(shè)備數(shù)據(jù)上報流程涉及多種數(shù)據(jù)格式和單位轉(zhuǎn)換非常適合用來學(xué)習(xí)如何構(gòu)建一個符合行業(yè)標準的BLE設(shè)備。3.1 服務(wù)與特征值定義解析在bloodpressureservice.c中你會找到血壓服務(wù)的完整定義。它主要包含兩個核心服務(wù)設(shè)備信息服務(wù)這是一個通用服務(wù)用于提供設(shè)備制造商、型號、序列號、固件版本等信息。任何標準的BLE設(shè)備掃描工具都能讀取這些信息。血壓服務(wù)這是核心其UUID為0x1810。它內(nèi)部定義了多個特征值血壓測量這是最重要的特征屬性為Indicate。Indicate與Notify類似都能主動向中心設(shè)備發(fā)送數(shù)據(jù)但Indicate要求接收方回復(fù)一個確認因此更可靠適合血壓這種重要的醫(yī)療數(shù)據(jù)。其值是一個結(jié)構(gòu)體包含收縮壓、舒張壓、脈搏、時間戳、用戶ID、狀態(tài)標志等字段。血壓測量上下文可選特征用于提供額外的測量環(huán)境信息如用戶姿勢、袖帶尺寸等。血壓特征用于描述血壓測量特征值的各種描述符例如“客戶端特征值配置描述符”中心設(shè)備通過向這個描述符寫入0x0002來啟用Indication。在代碼中這些是通過一個靜態(tài)常量數(shù)組bloodPressureServCBs來聲明和初始化的。理解這個數(shù)據(jù)結(jié)構(gòu)是自定義服務(wù)的基礎(chǔ)。3.2 數(shù)據(jù)模擬與格式切換邏輯示例中的數(shù)據(jù)是模擬的但這恰恰是開發(fā)初期最高效的方式。在BloodPressure_MeasNotify函數(shù)中你會看到數(shù)據(jù)是如何被組裝的。static uint8_t bpSimulation[BP_MEAS_LEN_MAX]; ... // 填充收縮壓和舒張壓 bpSimulation[0] LO_UINT16(systolic); bpSimulation[1] HI_UINT16(systolic); bpSimulation[2] LO_UINT16(diastolic); bpSimulation[3] HI_UINT16(diastolic); // 根據(jù)當前格式標志位選擇性填充脈搏、時間戳等字段 if (formatFlags BP_FLAG_PULSE_RATE_PRESENT) { // 填充脈搏數(shù)據(jù) } ... // 調(diào)用GATT_Notification發(fā)送 GATT_Notification( connHandle, bloodPressureMeas, ATT_BT_UUID_SIZE );格式切換是此示例的一個亮點。通過按下“UP”鍵可以在mmHg帶時間戳、純kPa、kPa帶脈搏等多種格式間循環(huán)。這實際上是通過修改一個全局的formatFlags變量來實現(xiàn)的。這個標志位不僅控制著數(shù)據(jù)組裝邏輯在中心設(shè)備讀取“血壓特征”描述符時也會返回這個標志告知中心設(shè)備當前數(shù)據(jù)包包含哪些字段。這種設(shè)計充分體現(xiàn)了GATT協(xié)議的靈活性。3.3 安全配對流程與實操細節(jié)文檔中提到如果對端設(shè)備發(fā)起配對血壓傳感器會要求輸入密碼默認為000000。這個行為是在協(xié)議棧的GAP層配置的。在bloodpressure.c的初始化函數(shù)BloodPressure_init中通常會調(diào)用GAPBondMgr_SetParameter來設(shè)置配對參數(shù)比如是否要求綁定、使用哪種IO能力鍵盤顯示、只輸出等。對于血壓計這種可能沒有顯示屏的設(shè)備IO能力通常設(shè)置為GAPBOND_IO_CAP_DISPLAY_ONLY或GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT并配合一個固定密碼。關(guān)鍵配置點GAPBOND_DEFAULT_PASSCODE默認密碼示例中可能硬編碼為000000。GAPBOND_PAIRING_MODE設(shè)置為GAPBOND_PAIRING_MODE_WAIT_FOR_REQ等待中心設(shè)備發(fā)起配對。GAPBOND_MITM_PROTECTION是否要求中間人保護。對于醫(yī)療數(shù)據(jù)通常建議開啟。注意事項在實際產(chǎn)品中絕對不要使用默認密碼。你應(yīng)該在應(yīng)用初始化時動態(tài)生成一個隨機密碼或者通過某種用戶交互方式如按特定組合鍵來設(shè)置。將固定密碼編譯進固件是嚴重的安全隱患。3.4 廣播與連接狀態(tài)機管理血壓傳感器的廣播行為是典型的“按需廣播”上電后設(shè)備處于休眠狀態(tài)不廣播。用戶按下“RIGHT”鍵啟動廣播快速廣播間隔如20ms。被連接后停止廣播。連接斷開后不會自動恢復(fù)廣播必須再次按下“RIGHT”鍵。這個邏輯在app.c的事件處理函數(shù)中實現(xiàn)。當收到GAP_DEVICE_INIT_DONE_EVENT設(shè)備初始化完成后應(yīng)用并不立即啟動廣播。只有當收到KEY_CHANGE事件且對應(yīng)按鍵是“RIGHT”鍵時才調(diào)用GAP_DeviceInit設(shè)置廣播參數(shù)并啟動廣播。連接斷開事件GAP_LINK_TERMINATED_EVENT觸發(fā)后應(yīng)用也只是更新內(nèi)部狀態(tài)為“斷開”等待下一次按鍵事件。為什么這樣設(shè)計為了極致省電。在等待用戶操作的待機狀態(tài)下設(shè)備可以進入深度睡眠功耗可能低至1μA以下。這種設(shè)計非常適合不頻繁使用的醫(yī)療設(shè)備。4. 心率傳感器示例實現(xiàn)與優(yōu)化策略心率傳感器示例同樣基于SIG規(guī)范但相比血壓傳感器它更側(cè)重于連續(xù)、周期性的數(shù)據(jù)流傳輸并且在電源管理策略上有所不同。4.1 心率服務(wù)的數(shù)據(jù)結(jié)構(gòu)與能量計算心率服務(wù)除了基本的心率測量值Heart Rate Measurement還定義了“身體傳感器位置”、“能量消耗累計值”、“RR間隔”等可選特征。示例中通過“UP”鍵循環(huán)切換的7種數(shù)據(jù)格式正是這些特征值的不同組合。RR間隔是一個值得深入理解的參數(shù)。它代表連續(xù)心跳之間的時間間隔單位是毫秒。提供RR間隔數(shù)據(jù)對于計算心率變異性至關(guān)重要這在運動科學(xué)和健康監(jiān)測中很有價值。在代碼中模擬RR間隔數(shù)據(jù)需要生成一個時間間隔數(shù)組。能量消耗的計算是一個小難點。規(guī)范中定義能量消耗的單位是千焦耳。示例中通常采用一個簡化的模擬算法可能基于心率值和模擬的體重、運動強度來估算。在實際產(chǎn)品中這需要集成加速度計等傳感器數(shù)據(jù)通過更復(fù)雜的算法如ACSM代謝計算公式來估算。4.2 通知與指示的選用策略心率傳感器使用的是Notify而血壓傳感器使用的是Indicate。這是有講究的。通知服務(wù)器發(fā)送后不要求客戶端確認?？赡軄G失但開銷小、延遲低。指示服務(wù)器發(fā)送后要求客戶端確認?？煽康看伟l(fā)送都有額外的確認包開銷功耗和延遲更高。心率數(shù)據(jù)是連續(xù)、高頻每秒一次或多次且允許偶爾丟失的流式數(shù)據(jù)使用Notify更為合適。血壓數(shù)據(jù)是單次、關(guān)鍵、不允許出錯的測量結(jié)果使用Indicate保證可靠性更為重要。這個選擇體現(xiàn)了BLE協(xié)議設(shè)計中對不同業(yè)務(wù)場景的權(quán)衡。4.3 連接參數(shù)與廣播間隔的優(yōu)化心率示例的廣播行為比血壓示例更智能按鍵啟動或連接因鏈路丟失斷開時先以快速間隔廣播30秒以期快速重連然后切換到慢速間隔廣播以節(jié)省電量。正常斷開連接時直接以慢速間隔廣播60秒然后休眠。連接參數(shù)對功耗和性能的影響巨大但示例中通常使用協(xié)議棧默認值。在實際開發(fā)中你必須根據(jù)應(yīng)用場景調(diào)整它們。這些參數(shù)在連接建立后可以由外設(shè)通過GAP_UpdateLinkParamReq發(fā)起更新請求。連接間隔兩個數(shù)據(jù)包之間的時間。間隔越短實時性越好但功耗越高。心率傳輸可能需要100ms以下的間隔而血壓計可能用500ms甚至更長。從機延遲允許從設(shè)備跳過多少個連接事件而不監(jiān)聽。增大此值可顯著降低平均功耗但會增大數(shù)據(jù)延遲。監(jiān)督超時鏈路無通信多久后判定為斷開。通常是連接間隔的10倍以上。在heartrate.c中你可以找到類似HEARTRATE_ADV_FAST_INT和HEARTRATE_ADV_SLOW_INT的宏定義這里就是調(diào)整廣播行為的地方。4.4 低功耗模式下的傳感器調(diào)度這是示例代碼沒有展示但真實產(chǎn)品必須考慮的。假設(shè)你的心率傳感器集成了光學(xué)心率模塊該模塊每秒鐘測量一次會消耗5mA電流。你不能讓它一直工作。一個常見的策略是在未連接時心率傳感器完全關(guān)閉設(shè)備處于深度睡眠。連接建立后收到中心設(shè)備“啟用通知”的寫入請求。應(yīng)用層啟動一個定時器例如1秒周期。定時器中斷中喚醒心率傳感器模塊進行測量填充數(shù)據(jù)調(diào)用GATT_Notification發(fā)送然后立即關(guān)閉傳感器。在連接間隔之間MCU和射頻部分可以進入睡眠。你需要利用TI-RTOS的時鐘模塊或簡單的硬件定時器來實現(xiàn)這個調(diào)度邏輯并確保測量、發(fā)送的時序不會錯過連接事件。5. 從示例到產(chǎn)品關(guān)鍵問題排查與實戰(zhàn)技巧把示例跑通只是第一步把它變成穩(wěn)定可靠的產(chǎn)品中間還有很長的路要走。下面分享幾個我踩過坑后總結(jié)的關(guān)鍵點和排查技巧。5.1 連接不穩(wěn)定與斷線重連問題現(xiàn)象設(shè)備經(jīng)常無故斷開或者手機App顯示設(shè)備時連時斷。排查步驟1檢查電源。這是最常見的原因。使用示波器測量設(shè)備在射頻發(fā)射時的電池電壓。如果電壓跌落嚴重例如低于芯片的最低工作電壓會導(dǎo)致復(fù)位或掉線。解決方法優(yōu)化電源電路增加大容量電容或選擇更高放電能力的電池。排查步驟2分析空中包。使用TI的Packet Sniffer或商用藍牙嗅探器抓取空中數(shù)據(jù)包。查看連接請求、參數(shù)更新、斷開連接等指令是誰發(fā)起的以及原因碼是什么。例如斷開原因碼0x08代表“連接超時”通常意味著監(jiān)督超時時間內(nèi)沒有成功通信。排查步驟3調(diào)整連接參數(shù)。中心設(shè)備通常是手機可能拒絕了外設(shè)的參數(shù)更新請求。在peripheral.c的peripheralGapRoleCB回調(diào)函數(shù)中處理GAPROLE_PARAM_UPDATE_EVENT事件檢查狀態(tài)是否為SUCCESS。如果不成功可以嘗試在應(yīng)用層實現(xiàn)一個退避策略稍后再次發(fā)起請求。排查步驟4檢查軟件流控。如果使用串口與外部傳感器通信確保串口緩沖區(qū)足夠大且處理速度夠快避免數(shù)據(jù)堵塞導(dǎo)致看門狗復(fù)位。5.2 數(shù)據(jù)發(fā)送失敗或中心設(shè)備收不到通知現(xiàn)象設(shè)備日志顯示調(diào)用了GATT_Notification但手機App收不到數(shù)據(jù)。排查步驟1確認通知已使能。這是最根本的原因。必須在中心設(shè)備寫入“客戶端特征值配置描述符”CCCD為0x0001后外設(shè)才能發(fā)送通知。在app.c的寫事件處理中打印出寫入的特征值句柄和值確認CCCD被正確寫入。排查步驟2檢查連接句柄。GATT_Notification函數(shù)需要傳入正確的連接句柄。確保在連接建立事件GAP_LINK_ESTABLISHED_EVENT中保存了全局的連接句柄并且在斷開事件中將其重置為無效值。排查步驟3檢查緩沖區(qū)與長度。確保傳遞給GATT_Notification的數(shù)據(jù)指針有效且數(shù)據(jù)長度不超過該特征值定義的最大長度ATT_MTU - 3。超過長度會被協(xié)議棧靜默丟棄。排查步驟4MTU交換。默認的ATT_MTU是23字節(jié)有效載荷只有20字節(jié)。如果數(shù)據(jù)包很大需要在連接后發(fā)起MTU交換請求以獲取更大的傳輸單元。示例中可能沒有啟用你需要調(diào)用GATT_ExchangeMTU函數(shù)。5.3 功耗高于預(yù)期現(xiàn)象電池續(xù)航遠低于理論計算值。優(yōu)化點1最大化睡眠時間。使用TI-RTOS的電源管理框架確保在無事可做時任務(wù)調(diào)用Task_sleep()或進入POWER_SAVING模式。使用ICall_wait等待事件本身就是一種低功耗設(shè)計。優(yōu)化點2優(yōu)化廣播參數(shù)。在非連接狀態(tài)下功耗主要由廣播決定。盡可能使用最慢的廣播間隔如1秒甚至更長并縮短快速廣播的持續(xù)時間。將廣播數(shù)據(jù)包做得盡可能小。優(yōu)化點3優(yōu)化連接參數(shù)。如前所述在滿足數(shù)據(jù)實時性要求的前提下盡可能增大連接間隔和從機延遲。一個從機延遲為5、連接間隔為100ms的連接其平均功耗可能比從機延遲為0時降低80%以上。優(yōu)化點4關(guān)閉無用外設(shè)和調(diào)試接口。在最終產(chǎn)品固件中禁用所有未使用的GPIO、串口、LED驅(qū)動并將用于調(diào)試的LOG輸出宏定義為空。一個閃爍的LED或持續(xù)的串口輸出會消耗可觀的電量。5.4 自定義服務(wù)的添加與調(diào)試當你需要基于示例創(chuàng)建自己的服務(wù)時使用GATT數(shù)據(jù)庫工具TI提供了GATT DatabaseExcel表格或BTool來可視化地設(shè)計服務(wù)。定義好服務(wù)、特征值、屬性、UUID后工具可以生成對應(yīng)的.c和.h文件直接替換到工程中。這比手動編寫數(shù)組要可靠得多。為每個特征值分配獨立的事件在simpleGATTprofile.c中TI使用一個simpleProfileChangeEvt事件來處理所有特征值的通知使能。對于復(fù)雜服務(wù)最好為每個可通知/指示的特征值定義獨立的事件標志邏輯更清晰。善用ATT_MTU如果你的特征值數(shù)據(jù)很長務(wù)必在連接后執(zhí)行MTU交換。在app.c的連接建立事件中添加GATT_ExchangeMTU的調(diào)用。并在回調(diào)事件中檢查交換后的MTU值用它來約束你后續(xù)發(fā)送的數(shù)據(jù)包大小。6. 開發(fā)環(huán)境搭建與調(diào)試實戰(zhàn)指南理論最終要落到實操?；赥I BLE SDK開發(fā)通常有兩種主流的路徑基于IAR Embedded Workbench或德州儀器自家的Code Composer Studio。我個人更推薦CCS因為它對TI的芯片支持更原生且社區(qū)版免費。6.1 工程導(dǎo)入與基礎(chǔ)編譯獲取SDK從TI官網(wǎng)下載最新的SimpleLink CC13xx/CC26xx SDK。確保其版本與你的芯片型號如CC2640R2F, CC2652R匹配。導(dǎo)入示例工程打開CCS選擇“Import CCS Projects”導(dǎo)航到SDK安裝目錄下的examples\rtos\CC2640R2_LAUNCHXL\ble5stack選擇你想用的示例工程如simple_peripheral。配置預(yù)編譯符號這是關(guān)鍵一步。在項目屬性 - Build - ARM Compiler - Predefined Symbols中你需要根據(jù)你的硬件板定義正確的符號。例如對于CC2650 LaunchPad需要定義CC2650_LAUNCHXL。如果使用自定義板你可能需要定義BOARD_DISPLAY_USE_UART用串口代替LCD等。解決頭文件路徑SDK工程通常已經(jīng)配置好路徑。如果編譯報錯找不到頭文件檢查“Include Options”中的路徑是否指向了SDK的source和kernel\tirtos等目錄。6.2 調(diào)試工具鏈從LOG到空中抓包LOG輸出最基礎(chǔ)的調(diào)試手段。TI的示例工程通常使用Display_printf或Log_info。你需要先在Board.h中啟用Display_DISABLE_ALL或xdc.runtime.Log的支持并指定輸出到UART。連接開發(fā)板的串口到電腦用串口助手工具如Putty、SecureCRT查看打印信息。TI-RTOS System AnalyzerCCS內(nèi)置的強大工具。它可以圖形化地顯示任務(wù)切換、信號量、事件、隊列等RTOS內(nèi)核對象的狀態(tài)對于分析多任務(wù)間的協(xié)作和死鎖問題非常有效。EnergyTrace如果你使用的是TI的LaunchPad開發(fā)板并且連接了XDS110調(diào)試器可以使用EnergyTrace功能。它能實時測量芯片的電流消耗并分解到各個任務(wù)和模塊是功耗優(yōu)化的終極利器。藍牙協(xié)議分析儀這是解決復(fù)雜無線問題的必備工具。除了TI的Packet Sniffer市面上還有Ellisys、Frontline等商業(yè)分析儀。它們不僅能抓取BLE空中包還能解碼各層協(xié)議PHY, LL, L2CAP, ATT, GATT讓你清晰地看到連接建立、數(shù)據(jù)交換、參數(shù)更新的全過程。當遇到手機兼容性問題時抓包對比分析往往是唯一有效的解決途徑。6.3 向真實傳感器演進替換模擬數(shù)據(jù)示例中使用的是模擬數(shù)據(jù)要連接真實傳感器你需要選擇通信接口根據(jù)傳感器類型可能是I2C、SPI或ADC。TI的SDK提供了對應(yīng)的驅(qū)動庫DriverLib或TI-RTOS的GPIO,I2C,SPI驅(qū)動。編寫傳感器驅(qū)動創(chuàng)建一個獨立的.c/.h文件封裝傳感器的初始化、配置、數(shù)據(jù)讀取函數(shù)。參考SDK中SensorTag示例的傳感器驅(qū)動寫法。集成到應(yīng)用任務(wù)在原有的應(yīng)用任務(wù)如HeartRate_taskFxn中將原來生成模擬數(shù)據(jù)的代碼替換為調(diào)用你的傳感器驅(qū)動來讀取真實數(shù)據(jù)。注意時序和阻塞問題傳感器讀取可能是毫秒級的操作要避免在任務(wù)中長時間阻塞?？梢钥紤]使用TI-RTOS的時鐘或硬件中斷來觸發(fā)周期性讀取然后將數(shù)據(jù)通過消息隊列發(fā)送給應(yīng)用任務(wù)進行處理和發(fā)送。從閱讀文檔、運行示例到修改代碼、調(diào)試問題最終打造出屬于自己的低功耗藍牙產(chǎn)品這個過程充滿挑戰(zhàn)但也極具成就感。TI的這套示例和協(xié)議棧為你鋪好了最堅實的地基剩下的就是結(jié)合具體的業(yè)務(wù)需求在上面建造穩(wěn)固而精巧的建筑。記住低功耗藍牙開發(fā)一半是通信協(xié)議另一半是電源管理兩者結(jié)合才能做出真正優(yōu)秀的產(chǎn)品。