你好, 1)是不是说蓝牙芯片的底层是有报文缓冲区的,APP层启动数据发送后,报文是进入缓冲区的,然后按照报文进入的先后顺序进行发送? 2)如果底层的报文缓冲区满了,该如何处理呢,先进入缓冲区的先删除? 3)如果在连接断开的情况下,我能不能继续往底层报文发送缓冲区写数据,一旦连接建立,自动按进入的先后顺序发送?缓冲区的大小可控制吗? 4)蓝牙传输本身是可靠传输?那么,底层的保证机制是SN/NESN序号,意思是不是:每发一个包,只有对端设备回了包,才会发下一个包?对应到APP层,通过gattc_cmp_evt_handler函数来处理返回的消息,但是它应该是没办法区分是哪个报文发送成功的返回消息的吧? static int gattc_cmp_evt_handler(ke_msg_id_t const msgid, struct gattc_cmp_evt const *param, ke_task_id_t const dest_id, ke_task_id_t const src_id) { switch(param->req_type) { case GATTC_NOTIFY: { //Send confirmation to APP that value was sent/not htpt_temp_send_cfm_send(param->status, HTPT_THERM_TEMP_SEND); } break;
case GATTC_INDICATE: { //Send confirmation to APP that value was sent/not htpt_temp_send_cfm_send(param->status, HTPT_CENTRAL_IND_CFM); } break; default: break; }
如果APP这层,只能通过gattc_cmp_evt_handler函数来处理返回的消息,看接收的情况。
蓝牙芯片的底层,按照数据进入的先后顺序,保证远端一定要收到才发送下一个。通过(SN/NESN序号来控制)。如果超过链路监管时间,蓝牙连接就断了。
你好,
1)是不是说蓝牙芯片的底层是有报文缓冲区的,APP层启动数据发送后,报文是进入缓冲区的,然后按照报文进入的先后顺序进行发送?
2)如果底层的报文缓冲区满了,该如何处理呢,先进入缓冲区的先删除?
3)如果在连接断开的情况下,我能不能继续往底层报文发送缓冲区写数据,一旦连接建立,自动按进入的先后顺序发送?缓冲区的大小可控制吗?
4)蓝牙传输本身是可靠传输?那么,底层的保证机制是SN/NESN序号,意思是不是:每发一个包,只有对端设备回了包,才会发下一个包?对应到APP层,通过gattc_cmp_evt_handler函数来处理返回的消息,但是它应该是没办法区分是哪个报文发送成功的返回消息的吧?
static int gattc_cmp_evt_handler(ke_msg_id_t const msgid, struct gattc_cmp_evt const *param,
ke_task_id_t const dest_id, ke_task_id_t const src_id)
{
switch(param->req_type)
{
case GATTC_NOTIFY:
{
//Send confirmation to APP that value was sent/not
htpt_temp_send_cfm_send(param->status, HTPT_THERM_TEMP_SEND);
}
break;
case GATTC_INDICATE:
{
//Send confirmation to APP that value was sent/not
htpt_temp_send_cfm_send(param->status, HTPT_CENTRAL_IND_CFM);
}
break;
default: break;
}
return (KE_MSG_CONSUMED);
}
谢谢!
蓝牙底层保证了数据传输的可靠性,有相应的重传机制,如果超出规定的时间,连接就会断开,上面应用层做相应的处理
1 .一般发往远端设备的报文处理流程如下:应用程序- > GAPC->GATTC->L2CAP层。其中L2CAP层会按照你的报文大小进行分配空间,如果空间不够,直接Assert。另外,如果远端设备因为链路超时,也会发送断开连接的指令。此时第一步即APP->GAPC这一层就走不通,因为没有连接,报文直接丢弃。
2.报文满了,就直接Assert了,蓝牙连接会断
3.蓝牙连接断开了,是发不了的。你只能控制APP层的缓冲区,可以参考DSPs的工程
4.对,没办法区分。这个只能APP层做数据索引了。