先把E104-BT02這塊模塊擺到桌面上說。很多做物聯(lián)網(wǎng)、智能硬件、上位機通訊的朋友第一次接觸BLE藍牙模塊時容易被一堆術(shù)語嚇住GATT、MTU、廣播類型、綁定……其實這類模塊的本質(zhì)就是一個“串口轉(zhuǎn)藍牙”的橋你用串口發(fā)什么對端藍牙就能收到什么反過來也一樣。E104-BT02是億佰特家基于Nordic nRF52832方案做的一款BLE 5.0透傳模塊特點就是便宜、穩(wěn)定、資料全而且官方和社區(qū)里能拿到開源電路和驅(qū)動代碼非常適合快速驗證原型或者直接進量產(chǎn)。這篇就圍繞“5分鐘上手”這個目標把硬件電路、AT指令配置、STM32/HAL庫驅(qū)動、以及那些容易踩的坑一次講清楚。我最早用這個模塊是在一個環(huán)境監(jiān)測項目里MCU采集溫濕度數(shù)據(jù)要通過手機App實時查看。當時也在ESP32板載藍牙和獨立BLE模塊之間猶豫過后來選E104-BT02的原因很簡單它把射頻天線、晶振、匹配電路、協(xié)議棧全都封裝好了我只需要關(guān)心串口通信不用去折騰BLE協(xié)議棧和射頻調(diào)試硬件設計風險直接降到最低。1. E104-BT02到底是個什么模塊要快速上手得先搞清楚它的定位。E104-BT02本質(zhì)上是一個成品BLE通信模組芯片方案是nRF52832支持BLE 5.0工作頻段2.4GHz特色是“透傳”。什么叫透傳就是模塊內(nèi)部幫你把串口數(shù)據(jù)和藍牙無線數(shù)據(jù)互相轉(zhuǎn)換你不需要懂BLE協(xié)議棧把它當成一根“無線串口線”來用就行。模塊對外提供兩種使用形態(tài)一種是AT指令配置模式上電后通過串口發(fā)AT指令可以修改廣播名稱、串口波特率、廣播間隔、連接間隔、MAC地址等參數(shù)另一種是數(shù)據(jù)透傳模式配置完成后模塊直接進入透傳狀態(tài)所有從串口收到的數(shù)據(jù)會自動打包通過BLE發(fā)出去反過來收到藍牙數(shù)據(jù)也會從串口吐出來。這個設計非常符合MCU開發(fā)者的習慣因為串口是單片機最基礎的接口誰都會用。順便說一句藍牙技術(shù)里常提到的BR/EDR和BLE的區(qū)別。BR/EDR是傳統(tǒng)藍牙注重高數(shù)據(jù)速率和持續(xù)連接比如藍牙耳機、藍牙音箱BLE是低功耗藍牙主打低功耗、快連接、小數(shù)據(jù)量傳輸適合傳感器、遙控器、智能家居設備。E104-BT02只能用來做BLE不能兼容傳統(tǒng)藍牙但這在實際物聯(lián)網(wǎng)場景里完全夠用甚至更合適因為手機、電腦都原生支持BLE不需要額外配對授權(quán)。模塊電氣參數(shù)方面供電范圍典型值是3.3V但也能容忍2.0V到3.6V這意味著用兩節(jié)干電池或者鋰電池直接供電都沒問題。串口電平默認是TTL 3.3V如果MCU是5V系統(tǒng)必須加電平轉(zhuǎn)換不然后患無窮。工作電流在廣播狀態(tài)下大概十幾毫安連接狀態(tài)下幾毫安深度睡眠模式下更低具體數(shù)值手冊里都有表格做電池供電設計時一定要提前查好。2. 開源電路拆解硬件設計的關(guān)鍵細節(jié)E104-BT02模塊本體已經(jīng)把射頻部分都處理好了模塊是板載天線外面只需要接電源、地、串口收發(fā)引腳就能跑起來。但“能跑”和“穩(wěn)定跑”是兩碼事尤其是量產(chǎn)項目硬件設計的細節(jié)直接決定無線性能。2.1 供電電路別小看這3.3VBLE射頻發(fā)射瞬間電流峰值能到十幾毫安甚至更高如果電源紋波大、動態(tài)響應慢會導致模塊射頻指標下降表現(xiàn)就是通信距離變短、連接不穩(wěn)定、偶爾斷開。所以別用那種老舊的LDO或者直接從MCU的GPIO口取電最好用專門的LDO或者DC-DC給模塊單獨供電。我給一個常用的參考電路輸入5V或者鋰電池電壓經(jīng)過一顆RT9013或者XC6206這類低 dropout 的LDO輸出3.3V輸出端放一個10uF鉭電容并聯(lián)一個100nF陶瓷電容分別負責低頻儲能和高頻去耦。模塊電源引腳旁邊再就近放一個1uF和100nF越小越靠近模塊越好這是很多工程師容易忽略的細節(jié)。如果項目里有電機、繼電器、蜂鳴器這類感性負載一定要保證模塊供電不跟這些負載共用同一路電源或者在電源入口串磁珠、加TVS管否則模塊極易被干擾復位甚至損壞。2.2 串口連接電平匹配是第一優(yōu)先級E104-BT02的串口是3.3V TTL電平如果你的MCU是3.3V系統(tǒng)直接交叉連接就行模塊的TX接MCU的RX模塊的RX接MCU的TXGND必須共地。這里有個血淚教訓模塊的RX引腳內(nèi)部沒有強上拉如果MCU的TX引腳在復位期間是高阻態(tài)模塊可能收到亂碼所以規(guī)范做法是模塊的RX引腳外部加一個10K上拉到3.3V。如果是5V的MCU比如老款Arduino、51單片機不能直接連必須做電平轉(zhuǎn)換。最簡單的方案是兩顆MOS管搭雙向電平轉(zhuǎn)換或者直接用一體的電平轉(zhuǎn)換模塊。千萬別偷懶串電阻分壓分壓后的信號沿變差高速通信時容易誤碼。2.3 天線布局凈空區(qū)和地平面模塊是板載PCB天線天線區(qū)域周圍必須保持凈空。意思是PCB上天線投影范圍內(nèi)頂層和底層都不能鋪銅、不能走線、不能放置金屬器件和塑料外殼遮擋凈空建議至少5mm以上。天線區(qū)域正下方最好完整鋪地給射頻信號提供良好回路。如果你把模塊貼在金屬外殼上或者天線正上方放一顆大電解電容通信距離減半很正常別怪模塊怪自己布局。另外模塊盡量放在PCB邊緣天線朝外懸空這一點和所有2.4G模塊的布局要求一致。如果實在空間受限也可以考慮用外置天線版本的模塊通過IPEX座子引出天線放遠一點。2.4 引腳分配除了串口還有哪些能用E104-BT02除了串口還引出了一些通用GPIO比如狀態(tài)指示引腳、喚醒引腳、復位引腳。建議把狀態(tài)指示引腳接一個LED模塊連接上藍牙后LED狀態(tài)會變化這對調(diào)試太重要了。復位引腳通過10K上拉接3.3V再對地接100nF電容需要的時候MCU拉低做硬件復位。喚醒引腳在深度睡眠模式下用平時可以先懸空。整體開源電路的設計邏輯其實就是上一節(jié)這些點加上模塊最小系統(tǒng)一顆LDO、若干電容、一串引腳排針。億佰特官方資料包里有參考原理圖和PCB封裝直接拿來改改就行。我實際打板驗證過照抄官方參考設計實測室內(nèi)穿一堵墻通信穩(wěn)定距離大概30米沒問題。3. 5分鐘快速上手從AT指令到雙向透傳這部分就是標題說的“5分鐘上手”我盡量把流程壓縮到最短但同時保證你理解每一步在干什么。提前準備的工具一塊E104-BT02模塊、一個USB轉(zhuǎn)TTL模塊、杜邦線若干、手機安裝好任意一款BLE調(diào)試助手App。3.1 硬件連接和串口參數(shù)把模塊和USB轉(zhuǎn)TTL接好模塊TX接USB轉(zhuǎn)TTL的RX模塊RX接USB轉(zhuǎn)TTL的TXGND接GND模塊的VCC接3.3V。打開電腦上的串口助手波特率選9600模塊出廠默認數(shù)據(jù)位8停止位1無校驗無流控。這個波特率不是固定的后面可以用AT指令改但第一次上手先用默認值。打開串口助手后給模塊發(fā)送“AT\r\n”或者“AT\n”注意看模塊手冊說的結(jié)束符格式常見的是回車換行。如果模塊回復“OKOK”說明通信正常。如果沒反應先檢查TX/RX是不是接反了再看看供電電壓是不是3.3V大概率是這兩個問題。3.2 修改廣播名稱和關(guān)鍵參數(shù)默認廣播名稱一般是“BLE_XXXX”或者模塊型號為了好認可以改成自己的設備名。發(fā)送ATNAMEMyDevice模塊會回復OK并保存。注意BLE廣播名稱有長度限制一般最長20字節(jié)左右超過部分可能顯示不全或者廣播包超長導致其他設備掃不到別取太長。廣播間隔是一個重要的省電參數(shù)指令大概是ATADVINT100單位是毫秒這里配置的是100ms廣播一次。廣播間隔越小手機掃到模塊的速度越快但功耗越高越大則反之。如果你的項目是低功耗傳感器可以設到500ms以上如果追求快速連接100ms合適。實際項目中不需要經(jīng)常改這個參數(shù)調(diào)好一次就行了。3.3 連接測試手機與模塊雙向通信手機打開BLE調(diào)試助手App掃描到改好名字的設備后點擊連接。連接成功后App界面一般會顯示這個設備的Service和Characteristic模塊默認透傳服務通常是一個自定義的UUID比如FFE0/FFE1這類。在App里找到可寫的Characteristic向它發(fā)送任意字符串同時打開串口助手你會在串口里收到同樣的內(nèi)容說明藍牙到串口的通路已經(jīng)通了。反向測試在串口助手里發(fā)送一個字符串App對應的通知Characteristic界面應該能收到數(shù)據(jù)。有的App需要先“開啟通知”或者“訂閱”點一下對應按鈕就行。兩端都通說明這個模塊的核心功能你已經(jīng)完全掌握了整個過程熟練的話確實不到5分鐘。3.4 數(shù)據(jù)組包長度和透傳機制的坑透傳模塊有沒有限制每次發(fā)送的最大長度答案是有的。E104-BT02在透傳模式下一包數(shù)據(jù)最長一般是160字節(jié)左右不同固件版本有差異以手冊為準。如果你從串口一次性發(fā)超過這個長度的數(shù)據(jù)模塊會自己拆包分多次發(fā)送或者丟棄多余部分特別坑。所以MCU側(cè)代碼里要做組幀和拆包把大數(shù)據(jù)切成150字節(jié)左右的小包每包之間留時間間隔或者靠模塊的空閑時間判斷幀結(jié)束。我實際測試過串口波特率115200、BLE連接間隔7.5ms時單向持續(xù)傳輸大概能跑到6~8KB/s作為傳感器數(shù)據(jù)上報完全夠用。如果你要傳大文件或者音頻流BLE透傳模塊就不是最優(yōu)方案了得換方案。4. 驅(qū)動代碼設計與實現(xiàn)不只是“打開串口”很多人拿到模塊在STM32上寫驅(qū)動就是初始化UART然后收發(fā)數(shù)據(jù)。但這個模塊真正用起來還得處理幾個問題AT指令超時等待、透傳數(shù)據(jù)拼接、狀態(tài)變化檢測。這一節(jié)我把驅(qū)動代碼的設計思路和關(guān)鍵代碼貼出來基于HAL庫可以移植到F1/F4/G0等多種型號。4.1 串口DMA收發(fā)框架如果用串口中斷一個字節(jié)一個字節(jié)收發(fā)在115200波特率下容易丟數(shù)據(jù)而且CPU占用率高。推薦的做法是串口空閑中斷加DMA接收DMA把串口收到的數(shù)據(jù)自動存到緩沖區(qū)檢測到串口空閑一幀數(shù)據(jù)結(jié)束后觸發(fā)中斷這時候一次性處理緩沖區(qū)里的完整數(shù)據(jù)。初始化部分開啟UART的DMA接收并配置空閑中斷HAL_UART_Receive_DMA(huart1, uart_rx_buf, UART_RX_BUF_SIZE); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE);然后在中斷回調(diào)里判斷幀結(jié)尾提取有效數(shù)據(jù)再把DMA緩沖區(qū)重新初始化。核心代碼類似void UART_IDLE_Callback(UART_HandleTypeDef *huart) { if (huart huart1) { uint16_t len UART_RX_BUF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); if (len 0) { ble_uart_rx_handler(uart_rx_buf, len); } HAL_UART_DMAStop(huart1); HAL_UART_Receive_DMA(huart1, uart_rx_buf, UART_RX_BUF_SIZE); } }這個框架是通用模板不管最終對接什么模塊都能用區(qū)別只在收到的數(shù)據(jù)怎么處理。4.2 數(shù)據(jù)透傳通道的封裝在應用層我習慣把BLE模塊的收發(fā)封裝成兩個接口ble_send_data(uint8_t *data, uint16_t len)和ble_data_ind(uint8_t *data, uint16_t len)。前者負責把數(shù)據(jù)拆包發(fā)送后者是接收回調(diào)由上層邏輯決定數(shù)據(jù)往哪走。拆包發(fā)送的要點是檢查長度超過模塊單包上限就循環(huán)拆包void ble_send_data(uint8_t *data, uint16_t len) { uint16_t offset 0; while (len - offset BLE_MAX_PACKET_SIZE) { HAL_UART_Transmit(huart1, data offset, BLE_MAX_PACKET_SIZE, 100); offset BLE_MAX_PACKET_SIZE; HAL_Delay(5); } HAL_UART_Transmit(huart1, data offset, len - offset, 100); }每包之間加5ms延時是為了給模塊和BLE協(xié)議棧留出處理時間實測下來丟了包的情況少很多。接收回調(diào)里我一般會把數(shù)據(jù)放遞到一個環(huán)形緩沖區(qū)然后設置一個事件標志讓主循環(huán)去處理不占用中斷上下文void ble_data_ind(uint8_t *data, uint16_t len) { ring_buf_write(ble_rx_ring, data, len); ble_rx_event 1; }4.3 AT指令交互的狀態(tài)機寫AT指令查詢函數(shù)的時候如果簡單發(fā)一條“ATNAMExxx”然后死等串口回復超時機制很難處理。我建議用一個簡單的狀態(tài)機發(fā)送指令后記錄時間戳定時掃描是否收到“OK”或者“ERROR”。用HAL庫的HAL_GetTick()做超時判斷超時時間一般500ms到1s足夠。參考實現(xiàn)uint8_t ble_at_cmd(char *cmd, char *reply_buf, uint16_t timeout_ms) { uint16_t len strlen(cmd); HAL_UART_Transmit(huart1, (uint8_t*)cmd, len, 100); uint32_t start HAL_GetTick(); while (HAL_GetTick() - start timeout_ms) { if (ble_rx_event) { // 從環(huán)形緩沖區(qū)取一行判斷 return parse_at_reply(reply_buf); } } return 0; // 超時 }注意AT指令結(jié)束符一定按手冊來有的是\r\n有的是\n格式不對模塊不識別這是新手最常犯的錯。4.4 擴展HAL庫驅(qū)動OLED和SPI Flash項目做到后面很多人喜歡加OLED顯示屏實時顯示藍牙連接狀態(tài)、信號強度或者加一顆SPI Flash存歷史數(shù)據(jù)等手機連上后再批量同步。這兩個場景分別用到了屏幕上提到的“hal庫驅(qū)動oled代碼”和“sst25vf080b驅(qū)動代碼”。OLED驅(qū)動我用的是常見的0.96寸SSD1306I2C接口HAL庫的I2C驅(qū)動加上SSD1306的顯存映射刷新率控制在10Hz以上沒問題代碼網(wǎng)上很多核心就是初始化序列加畫點函數(shù)。SPI Flash我手頭是SST25VF080B8Mbit容量SPI接口HAL庫驅(qū)動SPI后核心操作是讀ID、擦除扇區(qū)、頁編程。頁編程一次最多寫256字節(jié)讀寫地址要按扇區(qū)對齊。加一個簡單的FatFS文件系統(tǒng)數(shù)據(jù)管理就方便很多。5. 深入BLE協(xié)議棧GATT、MTU、綁定與連接過程如果你只是把E104-BT02當透傳模塊用前面幾節(jié)的內(nèi)容已經(jīng)足夠了。但項目里一旦出現(xiàn)“連不上”“連上了收不到數(shù)據(jù)”“傳輸速率上不去”這類問題你就需要懂一點BLE協(xié)議棧的基本概念否則排查起來兩眼一抹黑。5.1 GATT結(jié)構(gòu)找對服務和特征BLE的數(shù)據(jù)交互不是像串口那樣發(fā)個字節(jié)就完事而是基于GATT通用屬性協(xié)議的層次結(jié)構(gòu)。一個設備有若干個Service每個Service下面有若干個Characteristic每個Characteristic又有讀、寫、通知等屬性。透傳模塊的Service通常是自定義UUID比如FFE0其中用于數(shù)據(jù)收發(fā)的Characteristic常見是FFE1可寫可通知。手機App就是通過“發(fā)現(xiàn)服務—發(fā)現(xiàn)特征—訂閱通知—寫數(shù)據(jù)”這個過程和模塊交互的。如果你在App里連上模塊卻看不到數(shù)據(jù)十有八九是沒找到正確的Service或者沒開通知。5.2 連接過程和MTU協(xié)商BLE的連接過程大致是外設廣播主機掃描到廣播后發(fā)起連接請求雙方進入連接態(tài)并協(xié)商連接參數(shù)連接間隔、從機延遲、超時時間接著做服務發(fā)現(xiàn)然后是MTU協(xié)商最后才能高效傳數(shù)據(jù)。MTU全稱Max Transmission Unit決定了一包數(shù)據(jù)最多能承載多少字節(jié)的LL層載荷。BLE 4.0/4.2默認MTU是23字節(jié)減去3字節(jié)頭部實際應用層數(shù)據(jù)只有20字節(jié)。E104-BT02支持協(xié)商更大的MTU比如247字節(jié)這樣一包能傳更多數(shù)據(jù)吞吐率大幅提升。手機App一般自動協(xié)商但有的App沒有開啟MTU協(xié)商設置導致一次只能傳20字節(jié)傳輸慢是正常的。要提升傳輸速率可以從三方面入手調(diào)小連接間隔比如7.5ms、開啟DLE數(shù)據(jù)長度擴展、協(xié)商更大MTU。E104-BT02的AT指令里一般有設置MTU或者連接間隔的選項具體看手冊。5.3 綁定與配對不只是“連上就行”熱搜詞里有“ble調(diào)試助手綁定(bond)”這是很多人的痛點。BLE的綁定Bonding和配對Pairing不同配對是一次性的安全認證過程綁定是在配對基礎上把密鑰存下來下次連接免密重建安全通道。透傳模塊默認可能是“Just Works”配對不需要輸入PIN碼安全性較低但對大多數(shù)數(shù)據(jù)采集場景夠用。如果你遇到“手機上配對成功了但模塊重啟后又得重新配對”說明模塊沒有保存綁定信息或者被配置成不保存綁定。解決方法一般是發(fā)AT指令開啟綁定保存功能不同模塊指令不一樣查手冊拿到對應指令比如ATBOND1之類。另外一個相關(guān)坑綁定之后手機端把模塊刪掉重新掃描有時候會掃不到或者連不上。因為模塊還在嘗試用舊的綁定信息加密連接。解決辦法是清空模塊側(cè)綁定信息一般是通過AT指令恢復出廠設置或者按住模塊上的復位鍵加某個引腳電平觸發(fā)清除。6. 常見問題與排查技巧實錄我積攢了不少這個模塊的排查經(jīng)驗整理成速查表遇到問題對著查能省很多時間?，F(xiàn)象可能原因排查及解決方法串口發(fā)AT無回復TX/RX接反交換串口兩根線串口結(jié)束符不對換\r\n或\n試驗模塊未上電測量VCC-GND電壓手機掃描不到模塊模塊在休眠喚醒模塊廣播名稱超長改短名稱廣播間隔過長改小廣播間隔等待模塊設置成不可發(fā)現(xiàn)恢復出廠設置連接后串口收不到藍牙數(shù)據(jù)未開啟通知App里訂閱Characteristic沒找到正確Service查看模塊手冊的UUID數(shù)據(jù)被組包截斷拆包發(fā)送調(diào)整幀間隔傳輸速率很慢MTU沒協(xié)商大開大MTU按模塊指令配置連接間隔太大調(diào)小連接間隔距離短、連不上天線凈空不夠檢查PCB布局附近有2.4G干擾換信道或錯開使用時間模塊亂碼波特率不匹配查看模塊配置的波特率電平不匹配加電平轉(zhuǎn)換供電紋波大加強濾波電容6.1 綁定失敗的快速處置手機和模塊綁定失敗經(jīng)常出現(xiàn)在新手機系統(tǒng)、舊模塊固件之間。我建議先升級模塊固件到最新版本然后再試。很多所謂“支持有問題”最后都是固件版本太老升級后一切正常。如果固件沒法升級試試手機是否裝了多個BLE調(diào)試工具有些App會占用后臺連接導致其他App連不上關(guān)掉重試就好。6.2 Linux環(huán)境下只保留BLE關(guān)閉BR的坑如果是做嵌入式Linux開發(fā)經(jīng)常會用到bluetoothctl命令行工具來調(diào)試BLE。裝上BlueZ后默認br0接口可能和ble0接口共存導致掃描列表雜、連接目標混亂。建議關(guān)閉傳統(tǒng)藍牙BR/EDR只保留BLE。方法通常是修改/lib/systemd/system/bluetooth.service把ExecStart那行加上--nopluginhostname參數(shù)或者用命令關(guān)閉PSCAN和ISCAN。具體做法因系統(tǒng)版本而不同但方向是一致的讓協(xié)議棧不要開啟BR/EDR的inquiry scan和page scan。6.3 從快速上手到穩(wěn)定量產(chǎn)模塊在原型跑通后要進量產(chǎn)之前有幾個點必須復查模塊天線區(qū)域的最終裝配結(jié)構(gòu)是否遮擋、外殼是否是金屬、電源在極端電壓下是否紋波超標、長時間運行后模塊溫度是否正常。另外每一批模塊的出廠固件版本可能不一樣擰螺絲前先在PCBA測試工裝里跑一輪自動測試腳本檢查廣播名稱、串口透傳、AT指令回復是否都正常。這些檢查看起來繁瑣但能避免后來在客戶端出現(xiàn)大面積售后問題。我真正在這類藍牙模塊上吃過虧的一次是量產(chǎn)時忽略了一個IO電平?jīng)_突導致模塊在某個批次主板上休眠后喚醒不了。排查了很久才發(fā)現(xiàn)是MCU那邊一個復用引腳在初始化時為低電平把模塊的喚醒引腳一直拉低了。后來在硬件設計規(guī)范里加了一條模塊所有控制引腳默認高阻或者上拉MCU側(cè)初始化完成后再主動控制狀態(tài)。7. 進階玩法一主多從、廣播應用和低功耗設計E104-BT02雖然定位是透傳模塊但在固件能力范圍內(nèi)還能玩出不少花樣。如果你不滿足于簡單透傳可以深入研究這幾個方向。7.1 一主多從組網(wǎng)模塊如果支持多連接可以做一個簡單的一主多從采集網(wǎng)絡一個主機手機或者MCU模塊連接多個從機設備每個從機采集不同的傳感器數(shù)據(jù)。這種場景下要注意每個從機用不同廣播名稱區(qū)分主機端要根據(jù)MAC地址或者廣播名稱識別設備。串口透傳模式下要自己加設備地址幀頭比如每個設備一個字節(jié)地址主機根據(jù)地址分發(fā)數(shù)據(jù)。7.2 廣播包攜帶自定義數(shù)據(jù)BLE的廣播包不只能廣播設備名稱還可以攜帶廠商自定義數(shù)據(jù)。如果你希望設備在不連接的情況下就能周期性的廣播一些狀態(tài)信息比如溫濕度值可以走這個方案。E104-BT02有些固件版本支持通過AT指令設置廣播數(shù)據(jù)這樣手機不用連接就能掃描到設備數(shù)據(jù)省去了連接流程功耗也更低。缺點是廣播數(shù)據(jù)容量很小一般只能放十幾個字節(jié)有效數(shù)據(jù)且單行道只能設備發(fā)到手機。7.3 低功耗設計的關(guān)鍵參數(shù)做電池供電產(chǎn)品時低功耗設計比功能更重要。核心參數(shù)是廣播間隔、連接間隔和從機延遲。廣播間隔越大越省電但掃描發(fā)現(xiàn)變慢連接間隔越大空閑功耗越低但數(shù)據(jù)延遲變大從機延遲允許模塊在多個連接事件內(nèi)不監(jiān)聽主機數(shù)據(jù)進一步省電。這些參數(shù)要結(jié)合業(yè)務場景反復測試沒有一勞永逸的配置。另外模塊不工作時盡量進入休眠用MCU GPIO喚醒需要時再發(fā)一條AT指令切回透傳模式實測下來休眠功耗能比連續(xù)工作降低好幾個數(shù)量級。7.4 與ESP32等平臺的聯(lián)合調(diào)試最后提一個常見的聯(lián)合調(diào)試場景很多做原型驗證的工程師會把E104-BT02掛到ESP32開發(fā)板上利用ESP32的Wi-Fi/BLE雙模能力實現(xiàn)本地串口清障、云端上報兩套路徑。這時候驅(qū)動代碼可以沿用前面的HAL庫思路只是把UART對接從STM32換成ESP32的UART驅(qū)動業(yè)務邏輯完全復用。我在實際做這個組合時踩過一個小坑ESP32的GPIO默認上拉狀態(tài)和模塊的某些引腳沖突導致模塊啟動異常后來在代碼里初始化UART引腳前先把引腳模式強制設好才解決。這個細節(jié)在文檔里沒人提但一旦遇到會卡很久。8. 開源資料與擴展建議官方資料包里一般包含的東西有模塊硬件手冊、AT指令集手冊、原理圖PDF、封裝庫、演示用的單片機例程、手機App源碼或者調(diào)試工具說明。拿到資料后我建議優(yōu)先看“AT指令集”和“硬件手冊”這兩份關(guān)鍵文檔的優(yōu)先級最高。原理圖參考價值在于電源和天線布局不要直接照抄到自己的高密度板子上。如果你打算把這個模塊的方案做成一個通用的無線透傳平臺后續(xù)還可以擴展的方向很多多個模塊互傳組網(wǎng)、和藍牙網(wǎng)關(guān)對接做資產(chǎn)管理、配合手機App做遠程參數(shù)配置、加入OTA固件升級等。OTA這個方向尤其值得研究E104-BT02基于nRF52832理論上是支持OTA的量產(chǎn)產(chǎn)品在不拆機的情況下升級固件對售后維護幫助很大。我個人在做過幾個BLE項目之后最大的體會是這類透傳模塊真正花時間的部分往往不是模塊本身而是外圍業(yè)務邏輯包括數(shù)據(jù)分包、協(xié)議設計、低功耗策略、平臺對接。模塊只是把一個大的復雜系統(tǒng)變成了一個標準串口設備剩下的工程細節(jié)照樣要靠自己填。所以在最初選型時與其糾結(jié)哪塊模塊的信號更好不如考慮它的資料完整度、社區(qū)活躍度、以及供應商的長期供貨穩(wěn)定性。E104-BT02這個模塊這三個維度都算合格所以我后來在不少項目里都愿意繼續(xù)復用這套方案。