你好,
我们使用的是SDK 5.0.4的最后一个版本，我们创建了一个自定义配置文件，其中包含两个特征的特征，属性使用示例项目“ble_app_peripheral”。定期我们从外部传感器接收数据，我们使用通知更新数据库中的相应特性。除了确认之外，一切都正常工作。当我们逐个将通知发送到这两个特征时，我们仅对最后一个通知收到确认。在移动应用程序上，数据将正确更新。在收到前一封通知的确认时，是否有义务传输每个新通知？有没有办法跳过这段等待，但是要有所有期望的确认？
非常感谢您的答案。
设备：
嗨AngelT,
因为发送两个通知，所以应该收到的确认也应该是两个，每个句柄对应一个确认(每个发送的不同特征的通知对应一个确认)。不是义务后发送下一个通知确认前一个,但它的最安全的方法,有一个有限的设备可以缓冲的通知,如果缓冲区填满,你继续发送通知在某种程度上这些信息将存储在堆,如果你继续发送通知(除了存储在堆上的通知不会向中央发送正确的值)，你的堆最终也会填满，平台重置将断言。因此，发送通知的最安全方式是等待确认，以避免连接。
由于MT_dialog
你好mt_dialog，
谢谢你的回答，但我们的测试显示了一些不同的行为。确认的数量(成功或不成功)总是等于通知的数量。问题是，当我们有两个或多个带有属性“Notify”的特征时，我们向这些特征发送两个或多个通知(一个接一个)，所有收到的确认都是针对最后一个通知的特征。在这种情况下，我们的逻辑是否接收到每个特征的通知，是否可以写入/通知新数据，将不起作用。
顺便说一下，DSPS项目中Dialog所使用的通知方法在我们的例子中也不适用。等待每一次确认并不是最好的办法，因为保持下一个
通知并降低连接的吞吐量。
嗨AngelT,
我不确定我完全理解这种情况，当你说一个接一个，我想在你发送一个通知之后，你首先等待确认消息CUSTS1_VAL_NTF_CFM，然后你发送下一个相同的特征。即使你发送了两个通知给相同的特征，你也应该再次接受两个确认(fw应该用两个CUSTS1_VAL_NTF_CFM消息响应)。您还可以使用一个简单的项目来测试这一点，使用一些基础设施，如ble_app_peripheral()，您可以使用按钮特征，并通过第二个计时器发送通知，并捕捉不同特征的两个确认(如下所示)，您可以添加arch_set_pxact_gpio()函数，并通过Smart Snippets功率分析器工具观察它，该函数应该强制工具用一条垂直的红线表示通知的完成，因此您应该在每次推送后得到其中的两行。
案例CUSTS1_VAL_NTF_CFM:
｛
Struct custs1_val_ntf_cfm const *msg_param = (Struct custs1_val_ntf_cfm const *)(param);
交换机（msg_param->句柄）
｛
案例CUST1_IDX_ADC_VAL_1_VAL:
ARCH_SET_PXACT_GPIO（）;
休息;
案例cust1_dx_button_state_val：
ARCH_SET_PXACT_GPIO（）;
休息;
案例cust1_dx_long_value_val：
休息;
默认值:
休息;
｝
}打破;
由于MT_dialog
你好mt_dialog，
也许我的解释是不正确的。对不起。一个接一个意味着我们发送第一个特征的第一个通知，并立即发送第二个特征的第二个通知，而不等待第一个确认，期望稍后将收到这两个通知的两个单独的确认。是的，我们收到了这两份确认，但总是有处理第二个/最后一个通知的特征。这就是问题所在。
嗨AngelT,
正如我所提到的，即使是这样，如果检查CUSTS1_VAL_NTF_REQ的处理程序，也就是custs1_val_ntf_req_handler()函数，您也将获得对已发送的通知的两个确认，您将看到,如果通知成功分配和放置在缓冲区有CUSTS1_VAL_NTF_CFM分配和发送到应用程序,如果你发送两个通知会有两个CUSTS1_VAL_NTF_CFM,每个特征有一个更新。如果您在您的应用程序中没有看到这一点，当您获得CUSTS1_VAL_NTF_CFM时，您是否检查通知来自哪个特征，就像我在上面粘贴的开关情况一样?您是否尝试将问题复制到一个简单的示例上，如ble_app_peripheral ?如果您正在经历类似的事情，我能想到的唯一原因是您正在更新相同的特征，custs1_val_ntf_req的句柄成员在两个通知中是相同的。
由于MT_dialog
嗨mt_dialog，
这是我们所期望的行为，但结果却不同。同样的ALWAYS，返回的确认是针对最后一个通知的特征。对于测试，我们使用项目“ble_peripheral”，带有两个不同的属性“Notify”。根据我们的说法，问题是在变量“custs1_env”中，它包含ntf_handle/ind_handle。你觉得呢?我们对吧?
嗨AngelT,
我不知道如何发生这种情况，就像我提到的一样，Custs1_val_ntf_req由custs1_val_ntf_req_handler（）函数处理，如果检查这个函数它将在中央发送通知，它还将分配和发送（如果消息不发送消息成功）CUSTS1_VAL_NTF_CFM，所以对于每个CUSTS1_VAL_NTF_REQ消息，CUSTS1_VAL_NTF_CFM是发送的（如果发生成功消息，CUTTS1_VAL_NTF_CFM将由GATTC_CMP_EVT_HANDLER（）发送）））。在Custs1_val_ntf_req_handler（）中发生消息的分配时，Custs1_val_ntf_cfm填充了已更新的句柄cfm-> handle = param->句柄（您已从custs1_val_ntf_req传递的句柄，此值也将更新custs1_env.ntf_enable才能从gattc_cmp_evt处理程序发送），所以您将收到的消息custs1_val_ntf_cfm将具有句柄参数您刚刚更新和发送通知的特征，所以如果您发送两个Custs1_val_ntf_req，您将收到两个Custs1_val_ntf_cfm和消息的句柄将是更新的特性。这就是为什么在确认处理程序中，我在上面指出的（交换机盒）我正在检查每个custs1_val_ntf_cfm的句柄。我没有看到Custs1_env和NTF_Handle / Ind_Handle如何与之有关。由于这些成员在成功通知的情况下填充在Custs1_val_ntf_req_handler（）中，以后发送并在稍后发送确认消息。如果您粘贴有关如何复制此操作的代码，例如，要检查，我使用BLE_APP_PERITERAL并应用了以下MOD。
在ADC的同一计时器处理程序上发送第二个通知（第一个通知的KE_MSG_SEND（MSG）的粘贴）：
/ *第二通知* /
struct custs1_val_ntf_req* req_2 = KE_MSG_ALLOC_DYN(custs1_val_ntf_req，
TASK_CUSTS1,
TASK_APP,
custs1_val_ntf_req，
def_cust1_button_state_char_len）;
//待采样的ADC值
静态uint16_t sample_2;
sample_2 =（Sample_2 <= 0xFFFF）？（Sample_2 + 1）：0;
req_2 - > conhdl = app_env - > conhdl;
req_2 - >处理= CUST1_IDX_BUTTON_STATE_VAL;
req_2 - > = DEF_CUST1_BUTTON_STATE_CHAR_LEN长度;
memcpy（req_2->值，＆sample_2，def_cust1_button_state_char_len）;
ke_msg_send (req_2);
user_catch_rest_hndl()在user_peripherals.c文件我放在一个arch_set_pxact_gpio () CUST1_IDX_ADC_VAL_1_VAL下CUST1_IDX_BUTTON_STATE_VAL为了赶上确认从更新,即使你没有专业工具使用分析器,如果您放置了一个断点，这两种情况都应该依次发生。
由于MT_dialog
你好mt_dialog，
谢谢你的详细回答。这是一个确切的例子。你是否统计了每个特征的确认次数(例如，2个通知，1个第一个特征的确认，1个第二个特征的确认)?只有第二次确认延迟，才会像你说的那样正常工作。参见custs1_val_ntf_req_handler()函数中的代码。通过GATT - custs1_env发送指示。ntf_handle =参数- >处理;。第二个通知是变量custs1_env。Ntf_handle将包含第二个特征的句柄。因为FIRST确认将在SECOND通知之后由gattc_cmp_evt_handler()函数发送，所以所有的确认将使用最后保存的句柄(第二个通知的句柄- cfm->handle = custs1_env.ntf_handle;)根据为什么，在custs1_env的定义中。ntf_hadle is written that this is the LAST handle.
最后，在这种情况下，副作用是所有确认都是为了令人不快的最后通知特征。
嗨AngelT,
抱歉长post显然你所提到的是有效的，我可以看到你所提到的正在发生，这是因为CUSTS1_VAL_NTF_REQ将运行，两个prf_server_send_event()将执行，但custs1_env。ntf_handle =参数- >处理将只保留第二处理(使用断点显然是发布延迟,我想这就是为什么我可以得到两个信号断开前发生),据我所知,我也已经与SDK团队检查没有解决这个问题的办法,以来的当前实现SDK (GATTC_CMP_EVT消息表明succesfull放置缓冲多恩不包括通知的通知发送的特点的处理通过填充的信息概要任务的自定义概要或由应用程序本身),但是您可以假设第一个通知已经被放置到缓冲区中以便发送。完整和推送额外的通知主要是为了保持缓冲区以防止溢出，但显然也有额外的用途。
如果您想这样做，您可以尝试更改Custs1_env结构以及Handlers1_val_ntf_req_handler（）以及保留类似缓冲区的缓冲区，以便跟踪您正在进行确认的特征。执行是串行的，这意味着无论是什么特征都已首先通知您将获得确认。
由于MT_dialog
谢谢mt_dialog。
我们终于找到了真相。我希望我的问题的答案对这个论坛的所有成员都有用。我的建议是Dialog Semicondu雷竞技电竞平台ctor在文档UM-B-050_DA1458x_Software_Developer's_Guide_1v1.pdf中包含这个具体的案例，因为所有的示例项目都具有两个或两个以上的属性“通知或指示”。
祝你过得愉快。
嗨AngelT,
我已经给SDK团队开了一张票，以便在未来的SDK版本中改进处理，如果您发现上述答案有帮助，请标记为接受。
由于MT_dialog