TI中文支持网
TI专业的中文技术问题搜集分享网站

关于匹配和绑定中导致断开在广播延时的问题

请教一下:

uint32 passkey = 0; // passkey "000000"// passkey "000000",密钥 uint8 pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;//配对模式,配置成等待主机的配对请求 // uint8 pairMode =GAPBOND_PAIRING_MODE_INITIATE;
uint8 mitm = TRUE;
uint8 ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
uint8 bonding = TRUE;
GAPBondMgr_SetParameter( GAPBOND_DEFAULT_PASSCODE, sizeof ( uint32 ), &passkey );
GAPBondMgr_SetParameter( GAPBOND_PAIRING_MODE, sizeof ( uint8 ), &pairMode );
GAPBondMgr_SetParameter( GAPBOND_MITM_PROTECTION, sizeof ( uint8 ), &mitm );
GAPBondMgr_SetParameter( GAPBOND_IO_CAPABILITIES, sizeof ( uint8 ), &ioCap );
GAPBondMgr_SetParameter( GAPBOND_BONDING_ENABLED, sizeof ( uint8 ), &bonding );
}

从机发起的绑定和匹配,要把pairmode的参数改为红色字体部分,但是我发现,改为这样,当蓝牙从连接到断开的过程中,static void peripheralStateNotificationCB( gaprole_States_t newState )函数不能马上反应断开的状态,而是要延时一段时间才反应过来。而吧pairmode改为黑色字体部分时,同样的过程,static void peripheralStateNotificationCB( gaprole_States_t newState )能马上反应断开的状态,请问这是什么原因造成的?如果我要匹配和绑定,怎样才能解决上述的延时问题?急!急! 

Yan:

waiting,

你是连上立马断开?

改成你的红字的话,从设备会主动发起配对请求。

黑字的话,如果是iOS设备,或者一些其他设备,都不会来和你配对的,你连接过程自然会快一些。

waiting:

回复 Yan:

是这样子了,如果是黑字部分,断开后马上可以回到广播状态,但是红字部分,断开后要过一段时间才会进入广播状态,这个我是通过回调函数打印出来观察的。就是不明白这是什么回事?

赞(0)
未经允许不得转载:TI中文支持网 » 关于匹配和绑定中导致断开在广播延时的问题
分享到: 更多 (0)