BlueNRG系列協處理器實戰經驗簡介

01

協處理器模式概述

BlueNRG 系列芯片從最早的一代 BlueNRG-MS 開始就支持協處理器模式。在協處理器模式下，BLE 功能在 BlueNRG 芯片端完成，應用部分在 MCU 端完成。與 AT 指令的模式類似，協處理器方式也具有高內聚、低耦合的特點，但相比于 AT 指令模式，協處理器方式更為強大靈活，而且還兼顧了 MCU 間通信的睡眠和相互喚醒等方面的需求。

BlueNRG 系列的所有芯片都支持協處理器模式。在使用協處理器時，BlueNRG 需要燒錄一個 DTM 固件。DTM 原本是指 Direct Test Mode，而 ST 在這個固件的功能上進行了擴充。除了用于 RF 測試（包括 RF 發射功率、接收靈敏度、頻偏、諧波等方面的測試），BlueNRG 的 DTM 固件還可以用于協處理器模式。

BlueNRG GUI 工具是一個針對 BlueNRG 芯片協處理器應用的工具。在使用協處理器時，協處理器可以搭配任何帶有串口或 SPI 接口的 MCU、MPU 或 PC 端使用。

如下圖所示，官方協處理器資料可以通過 SDK 中文檔 index.html 進行索引。

圖1.BlueNRG 端協處理器官方資料

02

協處理器軟件分層

BlueNRG GUI 工具的使用屬于一個 BlueNRG 芯片協處理器的應用。

協處理器可以搭配任意帶UART或者 SPI 的 MCU、MPU 或者 PC 端使用。

軟件框架如下圖所示。協處理器模式有兩種分層。

? [處理器] APP <------------> [BlueNRG] (Host+Controller)

? [處理器](APP+Host) <------------> [BlueNRG] (Controller)

圖2.協處理器軟件框架

大部分應用會采用第一種方式，對應用處理器或者 MCU 只需要關注應用部分，這種方式，處理器和 MCU 之間是通過 ACI 指令進行交互，ACI 是 HCI 指令的擴展。

第二種方式，BlueNRG 系列運行 Controller 部分，MCU 或者處理器 Host 層協議和應用，使用的場景比較少，雙方之間通過 HCI 經行交互。BlueNRG 系列如果需要使用這種方式的協議棧，則編譯 DTM 固件的時候，則需要在 Preprocessor Symbols 中使能“LL_ONLY”宏。

03

ACI 指令格式

Bluetooth LE 協議棧 ACI 指令利用并擴展了標準 HCI 數據格式。

圖3.HCI 指令格式

根據 Bluetooth 核心規范，標準 HCI 數據包可以是以下幾種類型：

? HCI 命令數據包（數據包類型：0x01）

? HCI ACL 數據包（數據包類型：0x02）

? HCI 同步數據包（數據包類型：0x03）

? HCI 事件數據包（數據包類型：0x04）

? HCI 擴展命令（數據包類型：0x81）

? HCI 擴展事件（數據包類型：0x82）

詳細的數據包格式可以通過如下方式詳細查看：

打開 BlueNRG-LP 或者 BlueNRG-LPS SDK 中 index.html ------->Network Coprocessor (UART, SPI mode)章節中的 Bluetooth LE stack v3.x ACI Data format -----------> Bluetooth LE stack v3.x ACI commands data format.

了解 ACI 指令格式有助于在實際調試雙通信部分時遇到問題時分析定位問題。

詳細的其他協處理器資料可以通過 SDK 中 index.html 中的如下章節進行查找。

04

DTM 相關的工程介紹

BlueNRG SDK 中提供了很多個不同的 DTM 的工程，用戶難以分辨。

為了簡化，絕大部分應用，建議選擇功能最齊全的 DTM 工程下，“UART_WITH_UPDATER”工程配置或者“SPI_WITH_UPDATER”工程配置。

圖4.BlueNRG DTM 相關的工程

其中 SDK 中包含的工程如下 :

? DTM: // DTM 是 Full Stack

? DTM_basic: // DTM 配置為 Basic stack

? DTM_Updater: // 帶 boot 程序 DTM 的 boot 源碼工程

其中 DTM 工程和 DTM_basic 工程是實現 DTM 功能的工程，他們之間的差別主要是一個默認是 Full stack，另一個默認為 Basic stack。而 DTM_Updater 只是一個 DTM 的 boot 源碼工程。

打開 DTM 或者 DTM_basic 工程可以看到如下不同工程配置：

? UART: DTM 使用 UART 接口(不包含升級代碼)

? UART_WITH_UPDATER:DTM 使用 UART 接口,DTM 在 Flash 的第一頁中包含 DTM_Updater .并且包含 DTM 功能。

? UART_FOR_UPDATER: DTM 使用 UART 接口,DTM 固件在 Flash 第一頁中留空不填充 (偏移 0x2000). 用戶制作升級固件，包含 DTM 功能。

? SPI: DTM 使用 SPI 接口(不包含升級代碼)

? SPI_WITH_UPDATER: DTM 使用 SPI 接口,DTM 在 Flash 的第一頁中包含DTM_Updater .并且包含 DTM 功能。

? SPI_FOR_UPDATER: DTM 固件在 Flash 第一頁中留空不填充 (偏移 0x2000). 用戶制作升級固件。包含 DTM 功能。

其中分兩大類通信方式，一類是 UART，一類是 SPI。其中 UART 通信方式的第一個“UART”工程配置是單純的 DTM，使用 UART 通信接口和其他 MCU 或者 MPU 通信作為協處理器功能的代碼。而“UART_WITH_UPDATER”工程配置包含了兩個程序，其中一個是將 DTM_Updater 工程編譯的二進制代碼放置編譯在數組中，作為啟動代碼；另外一個程序就是 DTM 程序偏移一定位置的代碼?！癠ART_FOR_UPDATER”工程配置只有一個程序，即 DTM 程序配置偏移了一定位置的代碼，它和“DTM”工程配置的差別僅僅是代碼偏移不同，實際內容一樣。

05

基于 STM32CubeMX 軟件包的協處理器模式

基于 STM32CubeMX 軟件包支持協處理器的有以下幾個：

圖5.STM32CubeMX 中的軟件包

或者參考官方的幫助文檔，如下圖右下邊的文檔。

圖6.X-CUBE-BLE2 軟件配置

06

基于源碼移植的協處理器模式

如果使用的另外一端的 MCU 并非是 STM32，或者一些 ST 官方還沒有適配的型號（如 BlueNRG-LPS）則需要移植協處理器模式源碼到 MCU 上。需要移植如下代碼：

圖7.非 STM32 使用 BlueNRG 協處理器需要移植的代碼

移植后上去后，需要適配。適配主要是實現 SPI 或者串口初始化部分的代碼以及實現這個函數：

可以參考 BlueNRG SDK 工程下協處理器相關的例子：

BlueNRG-LP/LPS: BlueNRG-LP_LPS_LPF DK x.x.xProjectsExternal_Micro

BlueNRG-1/2: BlueNRG-1_2 DK x.x.xProjectSTM32L

07

應用處理器（MCU）端軟件處理主框架

主要處理流程分為兩大類：

? MCU 或者處理器主動發送數據

? BlueNRG 主動發送數據

MCU 或者處理器主動發送數據的流程是這樣的：當應用端主動調用 aci_xxxx 等函數時，這些函數的處理是同步超時的。最后會調用"hci_send_req()"函數，在這個函數中，會先發送數據到 BlueNRG 端，然后在 while(1)循環中帶超時的等待，以查看hciReadPktRxQueue 隊列中是否有數據收到。當 BlueNRG 返回數據給應用處理器端（MCU）時，會通過 IO 中斷，最后觸發調用“hci_tl_lowlevel_isr()”函數。在這個函數中執行讀取數據的操作。如果成功讀取數據，將數據壓入 hciReadPktRxQueue 隊列中。整個執行 aci_xxxx 等函數的過程是同步執行的，直到超時還沒有讀取到數據放入隊列中。

BlueNRG 主動發送數據的流程如下：當 BlueNRG 發生一些事件，例如藍牙連接上了設備，這時 BlueNRG 會拉相應的 IO 口，通過應用處理器的外部中斷通知應用處理器端（MCU）。這會觸發調用“hci_tl_lowlevel_isr()”函數，在這個函數中執行讀取數據的操作。如果成功讀取數據，將數據壓入 hciReadPktRxQueue 隊列中。然后在主循環處理函數“hci_user_evt_proc()”中，會解析接收隊列中的函數。最后，如果成功解析，則會觸發對應的 xxx_event 事件。這里的 xxx_event 事件如果應用沒有定義，則默認執行一個弱定義的空函數。如果應用程序定義了，則執行用戶定義的函數。

08

交互時序圖

下文分別描述通過串口和 SPI 交互時的時序圖。了解雙方通信的時序，有助于理解雙發睡眠和喚醒，以及在定位問題時能夠更快速準確定位分析問題。

8.1. UART接口交互時序圖

使用UART接口進行交互時，時序圖如下所示：

圖8.串口方式交互時序圖

上圖時 MCU 主動發送 ACI 指令流程，分為以下幾個步驟：

? MCU 發送數據

o 1：MCU 喚醒 BlueNRG 芯片

o 2：BlueNRG 芯片被喚醒完成

o 3：MCU 通過串口發送數據

如果流控允許

o 4：MCU 發送完畢數據釋放 MCU_RTS

o 5：BlueNRG 芯片允許進入睡眠

?BlueNRG 發送數據

o A: BlueNRG 喚醒 MCU

o B: MCU 被喚醒

o C: BlueNRG 通過串口發送數據

如果串口流控允許

o D: BlueNRG 發送完數據釋放 MCU_CTS

o E: MCU 允許進入睡眠

8.2. SPI 接口操作時序圖

SPI 時序圖官方文檔中描述比較詳細，建議查看官方的文檔（在 SDK 的幫助文檔index.html 中）。

圖9.協處理器 SPI 通信協議

09

小結

本文介紹了 BlueNRG 系列芯片的協處理器模式、軟件分層、ACI 指令格式以及 DTM相關的工程。BlueNRG 芯片的協處理器模式與 AT 指令模式類似，但更為強大靈活，同時兼顧了 MCU 間通信的睡眠和相互喚醒等方面的需求。BlueNRG 系列的所有芯片都支持協處理器模式，且可搭配任何帶有串口或 SPI 接口的 MCU、MPU 或 PC 端使用。在軟件框架方面，協處理器模式有兩種分層，大部分應用采用第一種方式，對應用處理器或 MCU只需要關注應用部分，處理器和 MCU 之間通過 ACI 指令進行交互。了解 ACI 指令格式有助于在實際調試雙通信部分時遇到問題時分析定位問題。在 DTM 相關的工程介紹方面，建議選擇功能最齊全的 DTM 工程下，“UART_WITH_UPDATER”工程配置或者“SPI_WITH_UPDATER”工程配置。

審核編輯：劉清