我看不到这是怎么发生的，就像我之前提到的那样，custs1_val_ntf_req由custs1_val_ntf_req_handler（）函数处理，如果您检查此功能，它将在中央发送通知，也会分配并发送（如果不会发送消息，则成功地）CUSTS1_VAL_NTF_CFM，因此对于每个CUSTS1_VAL_NTF_REQ消息，发送CUSTS1_VAL_NTF_CFM即将发送（如果发送消息，则custs1_val_ntf_cfm将由gattc_cmp_evt_evt_handler（））发送。在CUSTS1_VAL_NTF_REQ_HANDLER（）中，该消息的分配发生结构CUSTS1_VAL_NTF_CFM填充了已更新的cfm-> handle = param-> handle（您已经从CUSTS1_VAL_NTF_REQ传递的句柄）的句柄，此值还将更新CUSTS1_ENVS1_ENVS1_ENV。ntf_enable in order to be send from the GATTC_CMP_EVT handler), so the message CUSTS1_VAL_NTF_CFM that you will receive will have as handle parameter the characteristic that you have just updated and send a notification, so if you send two CUSTS1_VAL_NTF_REQ you will receive two CUSTS1_VAL_NTF_CFM and the handle of the message retruned will be the updated characteristic. Thats why in the confirmation handler that i ve indicated above (the switch case) i am checking the handle for every CUSTS1_VAL_NTF_CFM i get. I dont see how the custs1_env and the ntf_handle/ind_handle has anything to do with it. Since those members are populated in the custs1_val_ntf_req_handler() in the case of a succesful notification send and used later on to send the confirmation message. If you paste a code about how i can replicate this, for example, in order to check, i used the ble_app_peripheral and applied the following mods.
嗨，Angelt，
由于您发送了两个通知，因此您应该收到的确认应该是两个，每个句柄都应该收到一个（一个针对您发送的不同特征的每个通知）。确认了上一张通知并不是有义务发送下一个通知，而是最安全的方法，有限的通知可以显示设备可以缓冲，并且如果该缓冲区填充，并且您会在某个时候发送通知。这些消息将存储在您的堆中，如果您继续发送通知（除了存储在堆中的通知不会将适当的值发送到您的中心的事实）您的堆最终也会填充，并且平台重置将断言。因此，发送通知的最安全方法是等待确认，以避免连词。
谢谢mt_dialog
你好mt_dialog，
感谢您的答案，但是OUT测试显示出一些不同的行为。确认的数量（成功与否）始终等于通知的数量。问题在于，当我们具有两个或多个特征具有“通知”的特征，并且我们将两个或多个通知发送给这些特征（一一一个）时，所有收到的确认都是针对最后一个通知的特征。在这种情况下，我们的逻辑是否已接收到每个特征的通知以及可以编写/通知的新数据将无效。
顺便说一句，DSP项目中对话框使用的通知方法也不适用于我们的情况下。等待所有确认不是最好的解决方案，因为保留下一个
通知并减少连接的吞吐量。
嗨，Angelt，
我不确定我是否会明白，当您一一说一句话时，我想在发送通知后，您首先等待确认消息CUSTS1_VAL_NTF_CFM，然后您将下一个特征发送下一个特征。即使您发送两个相同特征的通知，您也应该再次进行两个确认（FW应使用两个CUSTS1_VAL_NTF_CFM消息响应）。您还可以使用一个简单的项目测试它，例如BLE_APP_PERIPHERAL（）您可以使用按钮特征并通过第二计时器发送通知，并捕获不同特征的两个确认（如下所示），您可以添加该确认。Arch_set_pxact_gpio（）函数并通过智能摘要电源prodiler工具观察它，该功能应强制使用垂直红线指示通知的工具，因此每次推动后都应该获得两条线。
CASE CUSTS1_VAL_NTF_CFM：
{
struct custs1_val_ntf_cfm const *msg_param =（struct custs1_val_ntf_cfm const *）（param）;
切换（msg_param-> hander）
{
案例CUST1_IDX_ADC_VAL_1_VAL：
Arch_set_pxact_gpio（）;
休息;
案例CUST1_IDX_BUTTON_STATE_VAL：
Arch_set_pxact_gpio（）;
休息;
案例CUST1_IDX_LONG_VALUE_VAL：
休息;
默认：
休息;
}
} 休息;
谢谢mt_dialog
你好mt_dialog，
我的解释可能不正确。对不起。一一表示，我们向第一个特征发送第一个通知，并立即在不等待第一个确认的情况下立即发送第二个特征的通知，以期希望后来收到2个单独的确认，以对这两项通知进行单独的确认。是的，我们收到了这两个确认，但始终为第二/最后一个通知特征提供处理。那就是问题所在。
嗨，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，
这是我们的预期行为，但结果是不同的。同样，返回的确认是针对最后一个通知的特征。对于测试，我们精确地使用具有两个不同特征的项目“ ble_peripheral”，并具有“通知”的属性。根据我们的说法，问题在包含NTF_HANDLE/IND_HANDLE的变量“ Custs1_env”中。你怎么看？我们对吗？
嗨，Angelt，
我看不到这是怎么发生的，就像我之前提到的那样，custs1_val_ntf_req由custs1_val_ntf_req_handler（）函数处理，如果您检查此功能，它将在中央发送通知，也会分配并发送（如果不会发送消息，则成功地）CUSTS1_VAL_NTF_CFM，因此对于每个CUSTS1_VAL_NTF_REQ消息，发送CUSTS1_VAL_NTF_CFM即将发送（如果发送消息，则custs1_val_ntf_cfm将由gattc_cmp_evt_evt_handler（））发送。在CUSTS1_VAL_NTF_REQ_HANDLER（）中，该消息的分配发生结构CUSTS1_VAL_NTF_CFM填充了已更新的cfm-> handle = param-> handle（您已经从CUSTS1_VAL_NTF_REQ传递的句柄）的句柄，此值还将更新CUSTS1_ENVS1_ENVS1_ENV。ntf_enable in order to be send from the GATTC_CMP_EVT handler), so the message CUSTS1_VAL_NTF_CFM that you will receive will have as handle parameter the characteristic that you have just updated and send a notification, so if you send two CUSTS1_VAL_NTF_REQ you will receive two CUSTS1_VAL_NTF_CFM and the handle of the message retruned will be the updated characteristic. Thats why in the confirmation handler that i ve indicated above (the switch case) i am checking the handle for every CUSTS1_VAL_NTF_CFM i get. I dont see how the custs1_env and the ntf_handle/ind_handle has anything to do with it. Since those members are populated in the custs1_val_ntf_req_handler() in the case of a succesful notification send and used later on to send the confirmation message. If you paste a code about how i can replicate this, for example, in order to check, i used the ble_app_peripheral and applied the following mods.
在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-> handle = cust1_idx_button_state_val;
req_2-> length = def_cust1_button_state_char_len;
memcpy（req_2-> value＆sample_2，def_cust1_button_state_char_len）;
ke_msg_send（req_2）;
在user_peripherals.c文件中的user_catch_rest_hndl（）中，我将Arch_set_set_pxact_gpio（）放在cust1_idx_idx_adc_val_1_val和cust1_idx_idx_button_state_state_val下，以从两个更新中获得确认，即使您可以使用Pro Profiffie，也可以从两个更新中获取确认。断点这两种情况都应该发生。
谢谢mt_dialog
你好mt_dialog，
感谢您的详细答案。这是确切的示例。您是否计算每个特征的确认数（例如，2个通知，1个对第一个特征的确认和第二个特征的确认）？仅当第二个确认延迟时，一切都会像您的解释一样正常工作。请参阅函数CUSTS1_VAL_NTF_REQ_HANDLER（）中的代码。通过gatt -custs1_env.ntf_handle = param-> handle;。发送指示。使用第二个通知，可变custs1_env.ntf_handle将包含第二个特征的手柄。由于第一个确认将通过函数gattc_cmp_evt_handler（）发送，因此所有确认都将带有最后保存的句柄（第二个通知的手柄-cfm-> handle = custs1_env.ntf_handle;）custs1_env.ntf_hadle的定义是，这是最后一个手柄。
最后，在这种情况下，副作用是所有确认都是针对最后一个通知的特征，这是令人不快的。
嗨，Angelt，
对不起，您所提及的很长的帖子是有效的，我可以看到您提到的是正在发生的事情，这就是因为两个CUSTS1_VAL_NTF_REQ都将运行，并且两个PRF_SERVER_SEND_EVENT（）将执行，但custs1_env.ntf_handle = param param = param param- >句柄只能保留第二个手柄（使用断点显然是在发出延迟，我想这就是为什么我可以在断开连接之前获得两个指示），据我所知团队没有解决此问题的方法通过自定义配置文件或应用程序本身的配置文件任务），但是您可以假设第一个通知已将已完全放入缓冲区中以发送到缓冲区中。完整的和推送额外的通知主要是为了保持缓冲区以免溢出，但显然也有额外的用法。
如果您想做到这一点，您可以尝试的是更改CUSTS1_ENV结构以及处理程序CUSTS1_VAL_NTF_REQ_HANDLER（）和类似的buffer for您发送的通知以跟踪您正在等待确认的特征。执行是串行的，这意味着您首先通知任何特征，您都将获得确认。
谢谢mt_dialog
谢谢mt_dialog。
最后，我们找到了真相。我希望我的问题的答案对本论坛中的所有成员有用。我的建议是对话框半导体，以在文档中包含此特yabo国际娱乐定情况，因为UM-B-050_DA1458X_SOFTWARE_DEVEVELER'S_GUIDE_1V1.PDF，因为所有示例项目均具有两个或多个具有属性“通知或指示”的特征。
祝你今天过得愉快。
嗨，Angelt，
我向SDK团队发布了一张机票，以改善SDK的未来版本的处理，如果您发现上述任何答案有帮助，请标记为接受。
谢谢mt_dialog