RT-Thread-RTT平台 zephyr_polling软件包 SPI Bluenrg2 数据传输测试RT-Thread问答社区

RTT平台 zephyr_polling软件包 SPI Bluenrg2 数据传输测试

发布于 2023-09-24 00:37:51 浏览：101 订阅该版

[tocm]

# RTT zephyr_polling SPI Bluenrg2 数据传输测试

>“开源之夏”“蓝牙HOST协议栈zephyr_polling完善” 项目个人记录
菜鸡参与项目的个人记录
项目软件包地址：[RTT_PACKAGE_zephyr_polling](https://github.com/bobwenstudy/RTT_PACKAGE_zephyr_polling)

RTT 那边的 Kconfig 配置完成，项目的基本开发内容就完成了。然后再对协议栈在 Bluenrg2 芯片上采用 SPI 作为 HCI 的数据传输进行测试。
数据传输使用的是 zephyr_polling 的 thoughput Example。

## 配置

软件包配置

![2023-09-20-22-24-11.png](https://oss-club.rt-thread.org/uploads/20230924/316f10f5c13ea1636cbc77bf354c23fd.png.webp)

## 数据传输

数据吞吐例程内部逻辑是将接收到的数据转发回中心设备。主要提供了两个 GATT 服务：write 和 notify。前者用于接收中心设备发来的数据，后者用于向连接的中心设备发送数据。

输入`zephyr`运行Example。

手机端使用 BLE调试宝(类似的BLE APP应该都行)连接设备，开启notify服务：
<img src="https://oss-club.rt-thread.org/uploads/20230924/0d9899a899890b4e811d27a463259ae0.jpg.webp" alt="th1" style="zoom:33%;" />

连续发送数据：
<img src="https://oss-club.rt-thread.org/uploads/20230924/a90d8d13c58ad88f14c4f2185d68736e.jpg.webp" alt="th2" style="zoom:33%;" />
收发数据没有丢包。

串口打印如下：

```shel
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 端的发送字节数对比，二者相符则可以基本保证可靠传输。再根据打印的计数，计算传输速率。

`example\peripheral_throughput\throughput_service.c`
关闭发送：

```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;
}
```

在接收处添加计数

```C
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;
}
```

使用协议栈的软件定时器打印计数：

```C
struct k_timer count_work;
...
void count_timeout(struct k_timer *timer)
{
    
    printf("count_timeout(): %d\n", 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 发送间隔，测试打印：

```shel
[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端相符。
<img src="https://oss-club.rt-thread.org/uploads/20230924/13331b31365a2425b80b9c79709107e8.png.webp" alt="th3" style="zoom:33%;" />

当前条件下的可靠传输速率为 (213960+211220+212000) / (50 * 3) =  4247.87 byte/s

### 测试双工的收发速率

数据吞吐例程内部逻辑是将接收到的数据转发回中心设备。在APP端保证发出和收到的字节数相同就能基本保证可靠性，然后再计数固定时间内传输的字节数即可得到传输速率。

同时收发的条件下，需要将发送间隔设置到 25ms 才能保证传输不丢包。

```shel
[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

双工传输的速率并不理想，查看传输时的时序图，发现传输所占用的时间比例很少，协议栈有很大的优化空间。
![2023-09-24-00-24-51.png](https://oss-club.rt-thread.org/uploads/20230924/550db3de230cd1ffc0128e757679466a.png.webp)

## 问题

首先是从时序图可以看到 SPI 通信口的利用率不高，有优化空间。

此外 APP 端给芯片发送数据的时候是通过 write GATT 服务进行的，写入的时候会检查接收缓冲区大小，如果满了，应当等待有空闲才会发送(实际去查看APP端的日志，即使将间隔设定为 1 ms，发送的间隔也不会是 1 ms，而是会根据实际情况浮动)。这种机制下，丢包是不应该的。

这两个问题有待之后去改进。

丢包问题：https://club.rt-thread.org/ask/article/18ea169ffe065968.html