This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

关于BLE主设备如何识别那个从设备断开连接

我在用simpleBLEcenter例程模拟主设备的设备的时候,如果我连接多个设备,当我断开其中一个连接的时候,不知道BLE是如何区别是那个设备的断开的连接。

在Bluetooth specification中。蓝牙广播的时候其中包含的有自己的设备地址,但是在断开连接的时候并没有包含这些地址信息,并且在维持连接的这些empty pdu里也没有相应的设备地址。所以我不知道怎么去有针对性的把相应的设备信息从内存中清除。

请问Ti的工程师这些东西应该怎么处理?

  • wang,

    GAPCentralRole_TerminateLink()可以断开连接,里面的参数是connection handle.

    作为central,当然知道连接上的所有的peripheral的地址,但是断开连接用的是connection handle. 

    connection handle是什么呢? 其实就是connection 的序列号,第一个连接上的peripheral,得到的connection handle就是0, 第二个,就是1, 依次累加。

    在simpleBLECentral.c 中,你找到simpleBLECentralEventCB()函数,查找GAP_LINK_ESTABLISHED_EVENT,下面你就能看到 pEvent->linkCmpl.devAddr ,这个就是连接上的远程设备的地址,central就能管理远程地址。当然,底层的代码是会自动维护的。

  • Hi,Yan

    谢谢你的回复,我在做实验的时候也发现这个connection handle会自动增加,通过你的回复才明白其作用。

    还有个问题就是,connHandle会自动增加,其是否会自动减少,如果我这边有设备断开连接了,其值是否会自动减少,这是不是也是由底层自动维护的。

    我现在做实验发现。当我只有两个从设备连接的时候,如果connhandle = 1的先断开,其是可以再次连接上的,但是如果我先断开connHandle = 0 的,那这个设备就没法从新连接上了。所以我认为是不是底层判断还有一个设备连接,所以再次连接的时候会设置其connHandle为1,但是这个handle已经与前一个设备绑定了,所以就不能连接了。

    请问这个时候如何解决?

    谢谢!

  • wang,

    如果该设备连接还在,在主机端的connection handle是不会改变的。比如说你说的那个connhandle = 1的那个设备,不管connhandle = 0 的那个设备有没有断开,其connection handle不会改变,不然无法维持当前的连接。

    至于connhandle = 0的设备断开后不能再连接,理论上也应该不会。系统应该会自动分配空闲的connhandle给新连上的设备(断开再连的设备就可以认为是新连上的设备)。

    你的代码里面有什么特别的地方吗?在建立连接的时候?

  • Yan,

    我的代码里面也没有什么特别的地方,就是使用那个DISCOVERY_EVT来间隔扫描,然后把信息添加到设备信息表中,

    理论上是不是判断最新的conHandle,然后有新增的设备的时候在这个connHandle上+1,和新设备绑定,而不是从已有的设备信息数+1绑定新设备,

    如果是前一种的话,那这个问题就应该是可以解决的了,由于我没有找到程序底层是怎么生成这些connHandle的,所以对这些不太了解。

    谢谢!

  • wang,

    connHandle是底层分配的。

    在LL层代码中,有个管理连接设备的链表,分配机制就是根据这个链表,会取其中第一个空闲的来分配。这段代码在库中,你们看不到。

    就像我之前说的,如果connection handle 0的设备断开了,同时还有connection handle 1 的设备还连着,新连进来的设备,还是会被分配给connection handle 0 。

  • Yan,

    thanks,问题解决,确实是我的程序流程中出现了问题。