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