380
引言
客戶的 STM32WB 產(chǎn)品考慮功耗和 OTA 傳輸速率的平衡，在正常工作和做 OTA 升級時(shí)會(huì)使用兩套不同的 BLE 連接參數(shù)。這就涉及到 BLE 連接參數(shù)更新?？蛻舻膯栴}也正是由更新 BLE 連接參數(shù)引起。連接參數(shù)的更新除了會(huì)影響 BLE 的傳輸速率，還需要考慮 OTA接收到數(shù)據(jù)后的擦寫 Flash 操作。
BLE 連接參數(shù)及更新過程
我們先簡單回顧一下影響 OTA 傳輸速率，也就是 BLE 傳輸速率的因素：
- PHY：BLE 的 PHY 是選用 1M, 還是 2M
- DLE: Data length extension 允許數(shù)據(jù)包大小容納更大的負(fù)載最大為 251 字節(jié)，禁用時(shí)為 27 字節(jié)
- ATT MTU ，當(dāng)開啟 DLE 時(shí)建議最大值設(shè) 247 字節(jié)
- 連接間隔（connection interval），范圍是 7.5ms 至 4000ms
- 連接事件（connection event），每個(gè)連接事件的最大數(shù)據(jù)包數(shù)，受限于 BLE 堆棧，Android 和 IOS 設(shè)備會(huì)有差異。
- 從機(jī)端的間隔喚醒（Slave Latency）: 定義從機(jī)可以忽略主機(jī)發(fā)起的連接事件數(shù)。
- 發(fā)送數(shù)據(jù)后是否需要 RSP,不需要的時(shí)候選用 write without RSP/notify 的方式速度更快。
客戶的應(yīng)用中其 BLE 連接參數(shù)更新其實(shí)只涉及 connection interval 和 slave latency 兩個(gè)。
問題產(chǎn)生
從上面的描述可知，客戶的程序設(shè)計(jì)是每接收到 4KB 數(shù)據(jù)，就要做 BLE 連接參數(shù)的更新。頻繁的 BLE 連接參數(shù)更新會(huì)引發(fā)了一些問題。首先是連接參數(shù)更新是由從設(shè)備STM32WB 發(fā)起把更新請求發(fā)給主機(jī)，主機(jī)收到更新請求后，正常會(huì)回一個(gè) response 給從機(jī)，告訴從機(jī)后面可以按新的連接參數(shù)進(jìn)行通信。但有些主設(shè)備有可能不支持參數(shù)更新或更新參數(shù)的時(shí)機(jī)有差異。導(dǎo)致更新失敗。這就產(chǎn)生了兼容性的問題。
問題解決
為了解決 BLE 連接參數(shù)更新帶來的問題。有兩個(gè)建議，一個(gè)是可以在 OTA 更新數(shù)據(jù)之前將 Flash 區(qū)域提前擦除，后面收到 OTA 數(shù)據(jù)后直接寫 Flash。因?yàn)樵?BLE 射頻 IDLE 時(shí)間內(nèi)寫 Flash 的操作不受限制，這樣就可以不用頻繁更新 BLE 連接參數(shù)，完成 OTA 升級。另一個(gè)是建議對于 STM32WB BLE 協(xié)議棧，只要主機(jī)對從機(jī)更新連接參數(shù)請求有response，從機(jī)收到這個(gè) response 后就可以再次發(fā)起連接參數(shù)更新請求，而無需等待30s。這樣也不會(huì)影響 OTA 的升級速率。
其實(shí)上面是針對使用的是 STM32Cube_FW_WB_V1.8 的協(xié)議棧版本的解決方案，它必須使用 ACI_L2CAP_CONNECTION_PARAMETER_UPDATE_REQ 命令發(fā)送更新請求。
小結(jié)
本文分享了客戶為提升 STM32WB OTA 速率引發(fā)的關(guān)于 BLE 連接參數(shù)更新的討論。最后根據(jù)客戶需要頻繁更新連接參數(shù)，給出了相應(yīng)的處理辦法。以上供大家參考。
