01

協(xié)處理器模式概述

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

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

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

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

圖1.BlueNRG 端協(xié)處理器官方資料

02

協(xié)處理器軟件分層

BlueNRG GUI 工具的使用屬于一個 BlueNRG 芯片協(xié)處理器的應(yīng)用。

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

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

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

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

圖2.協(xié)處理器軟件框架

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

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

03

ACI 指令格式

Bluetooth LE 協(xié)議棧 ACI 指令利用并擴展了標準 HCI 數(shù)據(jù)格式。

圖3.HCI 指令格式

根據(jù) Bluetooth 核心規(guī)范，標準 HCI 數(shù)據(jù)包可以是以下幾種類型：

? HCI 命令數(shù)據(jù)包（數(shù)據(jù)包類型：0x01）

? HCI ACL 數(shù)據(jù)包（數(shù)據(jù)包類型：0x02）

? HCI 同步數(shù)據(jù)包（數(shù)據(jù)包類型：0x03）

? HCI 事件數(shù)據(jù)包（數(shù)據(jù)包類型：0x04）

? HCI 擴展命令（數(shù)據(jù)包類型：0x81）

? HCI 擴展事件（數(shù)據(jù)包類型：0x82）

詳細的數(shù)據(jù)包格式可以通過如下方式詳細查看：

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

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

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

04

DTM 相關(guān)的工程介紹

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

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

圖4.BlueNRG DTM 相關(guān)的工程

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

? DTM: // DTM 是 Full Stack

? DTM_basic: // DTM 配置為 Basic stack

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

其中 DTM 工程和 DTM_basic 工程是實現(xiàn) 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 通信作為協(xié)處理器功能的代碼。而“UART_WITH_UPDATER”工程配置包含了兩個程序，其中一個是將 DTM_Updater 工程編譯的二進制代碼放置編譯在數(shù)組中，作為啟動代碼；另外一個程序就是 DTM 程序偏移一定位置的代碼。“UART_FOR_UPDATER”工程配置只有一個程序，即 DTM 程序配置偏移了一定位置的代碼，它和“DTM”工程配置的差別僅僅是代碼偏移不同，實際內(nèi)容一樣。

05

基于 STM32CubeMX 軟件包的協(xié)處理器模式

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

圖5.STM32CubeMX 中的軟件包

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

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

06

基于源碼移植的協(xié)處理器模式

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

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

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

可以參考 BlueNRG SDK 工程下協(xié)處理器相關(guān)的例子：

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

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

07

應(yīng)用處理器（MCU）端軟件處理主框架

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

? MCU 或者處理器主動發(fā)送數(shù)據(jù)

? BlueNRG 主動發(fā)送數(shù)據(jù)

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

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

08

交互時序圖

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

8.1. UART接口交互時序圖

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

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

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

? MCU 發(fā)送數(shù)據(jù)

o 1：MCU 喚醒 BlueNRG 芯片

o 2：BlueNRG 芯片被喚醒完成

o 3：MCU 通過串口發(fā)送數(shù)據(jù)

如果流控允許

o 4：MCU 發(fā)送完畢數(shù)據(jù)釋放 MCU_RTS

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

?BlueNRG 發(fā)送數(shù)據(jù)

o A: BlueNRG 喚醒 MCU

o B: MCU 被喚醒

o C: BlueNRG 通過串口發(fā)送數(shù)據(jù)

如果串口流控允許

o D: BlueNRG 發(fā)送完數(shù)據(jù)釋放 MCU_CTS

o E: MCU 允許進入睡眠

8.2. SPI 接口操作時序圖

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

圖9.協(xié)處理器 SPI 通信協(xié)議

09

小結(jié)

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

審核編輯：劉清