RTT 那邊的 Kconfig 配置完成，項目的基本開發內容就完成了。然后再對協議棧在 Bluenrg2 芯片上采用 SPI 作為 HCI 的數據傳輸進行測試。

數據傳輸使用的是 zephyr_polling 的 thoughput Example。

配置

軟件包配置

數據傳輸

數據吞吐例程內部邏輯是將接收到的數據轉發回中心設備。主要提供了兩個 GATT 服務：write 和 notify。前者用于接收中心設備發來的數據，后者用于向連接的中心設備發送數據。

輸入zephyr運行Example。

手機端使用 BLE調試寶(類似的BLE APP應該都行)連接設備，開啟notify服務：

數據傳輸

數據吞吐例程內部邏輯是將接收到的數據轉發回中心設備。主要提供了兩個 GATT 服務：write 和 notify。前者用于接收中心設備發來的數據，后者用于向連接的中心設備發送數據。

輸入zephyr運行Example。

手機端使用 BLE調試寶(類似的BLE APP應該都行)連接設備，開啟notify服務：

連續發送數據：

收發數據沒有丟包。

串口打印如下：

initialize rti_board_start:0 done
initialize drv_pm_hw_init:0 done
initialize rt_hw_spi_init:0 done
| /

RT - Thread Operating System
/ | 5.0.1 build Sep 20 2023 22:39:47
2006 - 2022 Copyright by RT-Thread team
do components initialization.
initialize rti_board_end:0 done
initialize stm32l4_hw_lptim_init:0 done
initialize finsh_system_init:0 done
msh >zephyr
zephyr_polling_init
bt_init_hci_driver
SPI_init_process device_name: spi10, spi_name: spi1, rate: 1000000, databits: 8, LSB_MSB: 1, Master_Slave: 0, CPOL: 0, CPHA: 1
SPI_init_process cs_pin_num: 1, irq_pin_num: 0
hci_driver_open, SPI_config_finish
I: (bt_hci_core)hci_init():3230: work start.
msh >prepare_event_process, step: 1
prepare_event_process, step: 2
prepare_event_process, step: 3
prepare_event_process, step: 4
prepare_event_process, step: 5
I: (bt_hci_core)hci_init_end():3205: work end.
E: (bt_smp)smp_self_test():5695: smp_self_test start
I: (bt_hci_core)bt_dev_show_info():3008: Identity: 02:80:e1:00:00:f5 (public)
I: (bt_hci_core)bt_dev_show_info():3042: HCI: version 5.2 (0x0b) revision 0x1222, manufacturer 0x0030
I: (bt_hci_core)bt_dev_show_info():3044: LMP: version 5.2 (0x0b) subver 0x0015
Bluetooth initialized
throughput_svc_init()
Advertising successfully started
I: (bt_hci_core)bt_sleep_prepare_work():4040: start
I: (bt_hci_core)bt_sleep_prepare_work():4046: end
I: (bt_hci_core)bt_sleep_wakeup_work_start():4058: start
I: (bt_hci_core)bt_sleep_wakeup_work_start():4061: end
I: (bt_hci_core)bt_sleep_wakeup_work_end():4072: start
I: (bt_hci_core)bt_sleep_wakeup_work_end():4074: end
Connected

數據傳輸測試

數據傳輸測試首先是保證傳輸的穩定性，保證沒有丟包誤碼。在保證可靠的前提下，再對數據傳輸的速率進行測試。測試包括雙工的收發速率測試和單口的傳輸速率測試。

測試傳輸的單個數據包大小為 20 字節。

這里有一個測試方案的問題，一開始使用的方案不對，測得的數據不能保證準確性(沒有保證可靠傳輸)，在社區導師的幫助下才得到了比較準確的測試結果。

測試單口傳輸速率
單口傳輸的話需要把 thoughput 例程中的發送關閉。此時由于沒有給 APP 端反饋，為了保證可靠傳輸，需要在接收處對接收的數據進行計數，并啟動一個軟件定時器，定時打印計數。將打印得到的接收字節數與 APP 端的發送字節數對比，二者相符則可以基本保證可靠傳輸。再根據打印的計數，計算傳輸速率。

exampleperipheral_throughputthroughput_service.c
關閉發送：

static void throughput_tx_ccc_cfg_changed(const struct bt_gatt_attr *attr, uint16_t value)
{
bool notif_enabled = (value == BT_GATT_CCC_NOTIFY);
// tx_enable = notif_enabled;
// 修改為
tx_enable = 0;
}
在接收處添加計數

static ssize_t data_rx(struct bt_conn *conn, const struct bt_gatt_attr *attr, const void *buf,
uint16_t len, uint16_t offset, uint8_t flags)
{
...
recv_count += len;
return len;
}
使用協議棧的軟件定時器打印計數：

struct k_timer count_work;
...
void count_timeout(struct k_timer *timer)
{
printf("count_timeout(): %dn", recv_count);
recv_count = 0;
}
...
k_timer_init(&count_work, count_timeout, NULL);
k_timer_start(&count_work, K_SECONDS(25), K_SECONDS(50)); // 25s后第一次執行 之后50s為周期執行

這里存在一個如何同步計數的問題。人點擊APP端發送的開始和停止時需要反應時間的，需要回避開始和結束。

首先是計數速率的時候，只能取不包含開始和結束的時間段內的計數來計算。

而可靠性保證的時候，并不需要在一次計數完成的時候剛好結束，往后再計數一個周期，將全部的計數結果加起來，能與APP端相符即可。

采取的方案是啟動協議棧，并在 APP 端連接后，開始連續發送測試數據包。計數的打印為 25s 后第一次執行，之后 50s 為周期執行。四次打印后結束發送，等待最后一次打印。將 5 次打印的計數求和，與APP端的發送數對比。然后取中間三次 50s 打印的字節數計算傳輸速率。

經過實際測試，APP 端 2 ms 發送間隔下，在長時間的連續發送下會產生丟包，需要將發送間隔上調至 3 ms 才能保證壓測之下沒有丟包。

20字節 間隔 2ms 傳輸持續 200s

協議棧端計數接收到 1494160 字節數據，但 APP 端發出 75046 個數據包，1500920 字節數據。

存在丟包情況。此時速率為 1494160 / 200 = 7470.8 byte/s

單個數據包大小為 20 字節，APP 端 3ms 發送間隔，測試打印：

[16:49:11.997]收←◆Connected
[16:49:26.163]收←◆count_timeout(): 17180
[16:50:16.110]收←◆count_timeout(): 213960
[16:51:06.061]收←◆count_timeout(): 211220
[16:51:56.016]收←◆count_timeout(): 212000
[16:52:45.978]收←◆count_timeout(): 57080

接收到的數據包為 17180+213960+211220+212000+57080 = 711440 字節，與APP端相符。

當前條件下的可靠傳輸速率為 (213960+211220+212000) / (50 * 3) = 4247.87 byte/s

測試雙工的收發速率

數據吞吐例程內部邏輯是將接收到的數據轉發回中心設備。在APP端保證發出和收到的字節數相同就能基本保證可靠性，然后再計數固定時間內傳輸的字節數即可得到傳輸速率。

同時收發的條件下，需要將發送間隔設置到 25ms 才能保證傳輸不丟包。

[00:11:22.697]收←◆Connected
[00:11:37.647]收←◆count_timeout(): 4280
[00:12:27.610]收←◆count_timeout(): 36400
[00:13:17.572]收←◆count_timeout(): 36400
[00:14:07.530]收←◆count_timeout(): 36320
[00:14:57.484]收←◆count_timeout(): 36360
[00:15:47.440]收←◆count_timeout(): 1900

APP端收發數相符，沒有丟包。打印的計數和為151600，與APP端相符。

速率為 (36400+36400+36320+36360)/200 = 726.95 byte/s

雙工傳輸的速率并不理想，查看傳輸時的時序圖，發現傳輸所占用的時間比例很少，協議棧有很大的優化空間。

問題

首先是從時序圖可以看到 SPI 通信口的利用率不高，有優化空間。

此外 APP 端給芯片發送數據的時候是通過 write GATT 服務進行的，寫入的時候會檢查接收緩沖區大小，如果滿了，應當等待有空閑才會發送(實際去查看APP端的日志，即使將間隔設定為 1 ms，發送的間隔也不會是 1 ms，而是會根據實際情況浮動)。這種機制下，丟包是不應該的。

這兩個問題有待之后去改進。