Hi,
关于write的命令(wiced_bt_gatt_send_write ( conn_id, type, p_write )),有一下几点需要确认一下
1. 发送write的命令时,介于信号比较差的环境下,调用 带有 rsp 的write时(GATT_WRITE),是否有time out 之类的消息或者 write err 的消息?indication有time out 之类的消息或者err的消息吗?
2. 测试了一下write的命令(19 02 06 0D 00 01 00 2D 00 76 65 72 73 69 6F 6E 2C 30 23),第一次发送是可以的,从log上可以看到
但是,当我第二次发送该命令的时候,出来disconnect的命令,不知道是什么情况导致的(原因是3,没有在code里查到这个值是什么意思?)
3. write命令填写GATT_WRITE和GATT_WRITE_NO_RSP的时候,我发现都是有回复的,都会收到hello_client_gatt_op_comp_cb conn 1 op 3 st 0 45。我理解是GATT_WRITE_NO_RSP应该不会有这个提示出来,对吗
已解决! 转到解答。
- 标记:
- write的命令
我是使用hci_audio_gateway和hello_sensor的demo测试的,使用clientcontrol发送HCI command的方式向对端发送数据,可以正常发送和接收,没有出现断连的现象。 你可以对照demo的code检查一下你的工程吗?
1. 在你说的这种情况下,应该会触发connection timeout的情况。需要重新建立GATT连接,下面是spec中的说明:
2.从代码中可以查到错误3对应如下:
#define HCI_ERR_HW_FAILURE 0x03
但是具体产生的原因不清楚,需要进一步debug,你使如何测试的,用的那个demo?
3. NO_RSP的时候,应该是不会收到response data的。
1.内部会重传的,不需要通过timer保护。
2.我这边测试一下再给您回复。
1. 再确认一下,connect,write, indication这几个命令都会重传?
2.谢谢
请问有进展吗
是的,底层都有重传机制的。
2.我这边测试一下再给您回复。 这个问题的进展呢
我在编译你的工程时,出现了一些类型定义错误,请问你发过来的工程是否缺少了文件?我使用的SDK是6.2.1.
../../apps/customer/BTU/btu.h:584:46: error: unknown type name 'u8'
void btu_read_pulsesensor(u8 v_AddrRegister, u8 * vp_AddrData, u16 v_length);
^~
../../apps/customer/BTU/BTU.c:524:2: error: unknown type name 'U16'; did you mean 'MU16'?
U16 vl_temp = AK09970N_CTRL1_DATA;
^~~
MU16
#define u8 uint8
#define U8 uint8
#define u16 uint16
#define U16 uint16
#define u32 uint32
#define U32 uint32
#define s16 short
在types.h里加一下这个
我使用hci_audio_gateway和hello_sensor的demo进行测试。audio_gateway作为client,使用client_control.exe上位机发送连接以及写指令,使用BTSpy打印log:wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_WICED_UART);
ClientControl可以发送Write或者Write No Rsp指令:
使用BTSpy可以打印出Stack底层的log如下:
在发送Write Request(带response的写指令)和Write Command(不带response的写指令)之后,application层都可以在GATTC_OPTYPE_EXE_WRITE事件中收到response的回复。但是,底层的log显示,只有发送Write Request指令之后,ATT层才会收到ATT RECV Command的response。
底层处理的逻辑是这样的:针对不带response的写指令,都会有response事件返回;针对带response的写指令,只有当对端收到且回复response之后,才会有事件返回。
对于客户的应用,如果是write with response,请检查response之后,再进行下一次的发送。
如果是write without respons,则不需要检查response,因为这个只是发送端自己返回的事件,并不代表对端返回的response。
您是用的我的code测试的吗?我是在有回复后再发送的。而且这个reason是3,不明白HCI_ERR_HW_FAILURE是怎么会造成的。我现在就卡在这边,请尽快帮我看看
我的测试步骤如下(开机后通过串口发送命令):
1. 19 01 01 02 00 01 01(scan)
2. 19 01 03 07 00 00 88 88 88 88 74 d8(connect)
3. 19 02 06 0D 00 01 00 2D 00 76 65 72 73 69 6F 6E 2C 30 23(write)
4.等回复后再发送19 02 06 0D 00 01 00 2D 00 76 65 72 73 69 6F 6E 2C 30 23的命令
我是使用hci_audio_gateway和hello_sensor的demo测试的,使用clientcontrol发送HCI command的方式向对端发送数据,可以正常发送和接收,没有出现断连的现象。 你可以对照demo的code检查一下你的工程吗?
我的code是作为master端的,也就是说相当于你的clientcontrol。我觉得是master端的问题。如果你用工具测试,估计是测不出来的,我会用hello_client来确认一下write的这个命令。您有空也用我的代码测一下吧
Audio_gateway的demo也是作为master,clentcontrol只是作为一个HCI UART的上位机,发送HCI指令,控制连接和发送数据。Hello_client demo的配对过程设置的有问题,无法直接连接,需要参照hci_audio_gateway的代码做一些修改。