本章分别测试了 TI CC2640R2F LaunchPad 和 LECONIOT CC2640R2F Evaluation Board开发板吞吐量,并提供了两个例程供大家参考测试,分别是 ble5_throughput_peripheral
和 ble5_throughput_central
。文末附对应测试程序下载链接。
该工程中进行了一些修改以方便进行吞吐量测试:
使用 USB 连接 CC2640R2F Evaluation Board ,确保跳线帽正确连接,如下图所示:
基本思想是不断发送 GATT 通知,尽可能减少开销,尽可能减少停机时间。
以下参数在增加吞吐量时必须加以考虑:
有关最大传输单元(ATT_MTU)的说明,请参见 LE Data Length Extension 和 Logical Link Control and Adaptation Layer Protocol (L2CAP)。
这里定义 6 个Tx缓冲区,每个缓冲区 251 字节。用户应用程序应根据自身堆栈情况进行分配。如果没有足够的堆栈,可以减少 MAX_NUM_PDU
,但这样可能导致吞吐量的损失。实际使用中的最坏情况是 MAX_NUM_PDU
和 MAX_PDU_SIZE
的乘积,即缺乏堆栈时能减少的最大值。设计人员应该根据设备的可用内存来平衡这些参数。
#define MAX_NUM_PDU 6
#define MAX_PDU_SIZE 251
注意:最好在 options->C/C++ Compiler->Defined symbols 里进行修改。
注意:MTU 更新过程在连接之后主机自动发起和从机进行协商。选择双方支持最大 MTU。
这里使用 2M PHY,使每个连接事件期间从 PHY 发送的数据增加一倍(需要连接之后通过按键菜单自行选择)。
在蓝牙 4.2 规范中允许控制器发送最多 251 个字节的单个数据包,这与以前的 27 个字节相比大大增加了吞吐量,此功能称为数据长度拓展。有关这方面详细介绍请参考 LE Data Length Extension 以及 BLE 一次能传多少数据( ATT_MTU 设置/LE Data 扩展)。
下面的 PDU 更新过程的代码片段可以在 throughput_peripheral.c
文件中找到
//examples\rtos\CC2640R2_LAUNCHXL\ble5apps\throughput_peripheral\src\app\throughput_peripheral.c SimpleBLEPeripheral_doSetDLEPDU line 1213
bool SimpleBLEPeripheral_doSetDLEPDU(uint8 index)
{
switch (index)
{
case 0:
txOctets = DEFAULT_PDU_SIZE;
txTime = DEFAULT_TX_TIME;
break;
case 1:
txOctets = DLE_MAX_PDU_SIZE;
txTime = DLE_MAX_TX_TIME;
break;
}
HCI_LE_SetDataLenCmd(connectionHandle, txOctets, txTime);
}
根据前后处理数量,控制器需要 2-3ms 来准备下一个连接事件,因此更长的连接间隔可以提高吞吐量。由于使用 notify 方式传输,增加连接间隔意味着连接事件减少。此示例将使用 100ms 的连接间隔,在实际情况下增加连接间隔有着明显的缺点:由于射频干扰导致的连接事件将大大降低吞吐量。因此用户需要根据所需吞吐量进行权衡,当连接间隔大于 100ms 后,吞吐量将不会增加。
这段代码设计能保证队列中始终有需要发送的数据,避免在通知开始时处于饥饿状态。
//examples\rtos\CC2640R2_LAUNCHXL\ble5apps\throughput_peripheral\src\app\throughput_peripheral.c SimpleBLEPeripheral_blastData line 1329
static void blastData()
{
uint16 len = MAX_PDU_SIZE-7;
attHandleValueNoti_t noti;
bStatus_t status;
noti.handle = 0x1E;
noti.len = len;
while(1)
{
//attempt to allocate payload
noti.pValue = (uint8 *)GATT_bm_alloc( 0, ATT_HANDLE_VALUE_NOTI, GATT_MAX_MTU, &len );
if ( noti.pValue != NULL ) //if allocated
{
//place index
noti.pValue[0] = (msg_counter >> 24) & 0xFF;
noti.pValue[1] = (msg_counter >> 16) & 0xFF;
noti.pValue[2] = (msg_counter >> 8) & 0xFF;
noti.pValue[3] = msg_counter & 0xFF;
status = GATT_Notification( 0, ¬i, 0 ); //attempt to send
if ( status != SUCCESS ) //if noti not sent
{
GATT_bm_free( (gattMsg_t *)¬i, ATT_HANDLE_VALUE_NOTI );
}
else //noti sent, increment counter
{
msg_counter++;
}
}
else
{
//bleNoResources
asm("NOP");
}
}
}
本代码仅为最大吞吐量测试,在实际应用中,由于其他处理需求,应用程序可能无法维持此吞吐量(例如必须通过串口传输有效数据负载)。此外 blastData
函数最大限度的增加了数据的排队,因此 GATT_Notification
会返回非 SUCCESS 状态,例如队列已满时的 blePending
。Tx 队列的深度由 MAX_NUM_PDU
决定。
主机和从机的有效数据载荷已经被优化为 251 字节,这是吞吐量的最大值。由于 ATT 和 L2CAP 级别的开销,并不是所有 251 个字节都可以用作应用程序数据,这是蓝牙规范所必须的。对 ATT 和 L2CAP 的简要说明如下:
所有 ATT 通知包具有标识
发送通知的属性的操作码和句柄所需的 3 字节头。
发送 ATT 通知有 3 字节开销。
在 L2CAP 层,需要类似的开销来设置分组的长度
和适当的信道标识符(CID)。
这些字段中的每一个都是 16 位( 2 字节),导致 4 个字节的 L2CAP 开销。
结合 L2CAP 和 ATT 数据包开销产生:
TOTAL_PACKET_OVERHEAD = 7 bytes
分别对 PDU 为 27 Bytes 和 251 Bytes 以及 PHY 为 1 Mbps、2 Mbps、Coded:S2、Coded:S8.模式进行测试。下面给出表格方便查阅。
TI CC2640R2F LaunchPad
模式 | 1 Mbps | 2 Mbps | Coded:S2 | Coded:S8 |
27 Bytes | 288.896 (kb/s) | 390.400 (kb/s) | 101.504 (kb/s) | 29.280 (kb/s) |
251 Bytes | 780.800 (kb/s) | 1366.400 (kb/s) | 175.680 (kb/s) | 58.560 (kb/s) |
模式 | 1 Mbps | 2 Mbps | Coded:S2 | Coded:S8 |
27 Bytes | 288.896 (kb/s) | 390.400 (kb/s) | 101.504 (kb/s) | 29.280 (kb/s) |
251 Bytes | 780.800 (kb/s) | 1366.400 (kb/s) | 175.680 (kb/s) | 58.560 (kb/s) |
可以看出我们的开发板和 TI CC2640R2F LaunchPad在不同模式下速率是一致的。读者可以自行下载例程测试。下图展示了在 2 Mbps/251bytes 模式下的传输速率。
下载 BLE Throughput 测试例程.
注意:需要配合 CC2640RF SDK使用,本文使用的是
simplelink_cc2640r2_sdk_1_35_00_33
。文件解压后放在该 SDK 同级目录,即 C:\ti。
文章所有代码、工具、文档开源。加入我们QQ群 591679055获取更多支持,共同研究CC2640R2F&BLE5.0。