在我们的自定义个人资料中，我们具有客户/中央设备在空中编写的特征。此特性在用户_custs1_def.h中定义为具有254个char_len（这是应成为的最大尺寸）。在测试中，我们发现，只要新的书面值的长度或比以前的书面值较短，那么一切都可以正常工作。但是，如果新值比以前的书面值更长（即使新值仍然比初始char_len短得多），则写入失败，系统开始行为不稳定。例如，经过更长的写入此特征后，该特征再也无法在空中读取，并且与客户的连接变得不稳定。
看来，在编写更长的字符串时，custs1_task.c中的gattc_write_req_ind_handler（）函数从未被调用，因此在代码中的这一点之前发生了问题。
我们如何实现所需的功能？也就是说，无论该特征的当前内容如何，都可以从客户那里获得任何价值（最多254个字节）的可写特征？
设备：
嗨，Mkelwood，
似乎比以前的书面价值编写更大的特征价值不是问题，我无法复制它。您能否请您查看DSPS应用程序，在其中我们可以在DSP中编写247个字节的数据>在DSP中，您可以拥有想要拥有的功能，因此请检查该项目中的特征是如何实现的。
谢谢，pm_dialog
你好pm_dialog，
感谢您的答复。我还有一些其他信息。我对这个问题的最初结论是不正确的。并不比以前的写作更长的写作。相反，它的写作比（MTU -3）字节更长，这些字节需要写入长的特征值过程（蓝牙规格5.0 vol 3 part g第4.9.4节）。
我已经连接了显示问题的OTA捕获文件的屏幕截图。DA14585是从属（GATT服务器）设备。目标特征具有53。连接和发现后，我为特征的特征写了一个短（小于mTU -3）的值，该值成功（请参阅帧4468和4473）。我读回正确的值（帧6926和6932）。然后，我尝试编写一个长21个字节的值（比MTU -3多）。GATT客户端发送准备书面请求（框架7334，突出显示的帧），并且DA14585没有响应。现在，奴隶被打破了反应。
我已经尝试将目标特性权限设置为write_req和write_command。随附的捕获是带有write_req权限。使用write_command，GATT客户端不会让我为特征写一个长的价值（它抱怨不好的论点）。
所以我现在的问题是，为什么写入长的特征价值过程不起作用？为什么DA14585不以准备写作响应响应？我是否需要做任何特别的事情来支持从GATT服务器端进行编写/执行写序列的准备？
谢谢你的帮助！
我更新为SDK 6.0.10.511;写长特征价值的问题仍然存在。该设备无法响应中央的准备写请求，并且该设备无反应，直到断开/重新连接为止。
嗨，Mkelwood，
如果您不使用或不想交换MTU，则应在SDK的BLE_APP_PERIPHERAL示例中实现写入长特征值作为实现。请看一下SDK的这个示例。如果要编写的特征值的长度大于20个字节，则将触发USER_CATCH_REST_HNDL（）函数中的user_svc1_long_val_val_t_info_req_handler（）。如果长度小于20字节，则将执行user_svc1_long_val_vr_ind_handler（）。因此，如果您要在没有MTU交换的情况下发送20个字节以上，则应执行与BLE_APP_PERIPHERAL示例的User_svc1_long_val_val_t_info_req_handler（）函数相同的实现。既然您这样做，主人将发送“准备写作请求”，而从属将以“准备写作响应”的方式响应。否则，如果您想执行简单的写请求并发送20个字节以上，则应增加MTU尺寸。
谢谢，pm_dialog
谢谢PM_Dialog提供此信息！我按照您的建议实现了att_info_req_handler代码，这解决了写入长的特征值问题。接收到执行写命令后，仍然调用WR_IND_HANDLER；这是预期的和首选的行为。
我永远不会猜测att_info_req_handler是使编写长度特征有效的代码。即使在BLE_APP_PERIPHERAL应用程序中看到代码，我也不会在此和准备写/执行写序列之间建立连接。我找不到对话框或里维埃拉波文档中任何地方的文档。我希望有一些关于这些更晦涩的回调的文档。
嗨，Mkelwood，
很高兴您弄清楚了您的问题。
谢谢，pm_dialog