写入BLE特征时出现ERROR_GATT_WRITE_REQUEST_BUSY错误的原因及关联

这个问题的核心是Notify和Write操作共享BLE ATT层的传输资源与GATT事务处理能力，二者的冲突并非功能上的直接排斥，而是底层传输机制的时序和带宽竞争导致的，具体原因可以拆解为几点：

• Notify的异步推送抢占传输时隙：Notify是从设备主动向中心设备推送数据，属于异步发起的GATT操作，不需要中心设备的请求。当Notify频繁发送时，会占用链路层的传输带宽和ATT层的处理时隙，而你采用的顺序写入没有队列缓冲，前一个Write请求还没等ATT层处理完，下一个就已经发起，此时如果ATT层正忙于处理Notify数据包，就会返回ERROR_GATT_WRITE_REQUEST_BUSY错误。

• GATT层的并发操作限制：绝大多数BLE栈对同一连接下的GATT事务并发数有严格限制（通常是同一时间只能处理一个主动请求类操作）。Notify的推送虽然是从设备发起，但也会占用GATT层的事务处理槽位，当Notify事务正在进行时，中心设备发起的Write请求就会因槽位被占而触发繁忙错误。

• 链路层的数据包排队影响：即使Notify不需要应用层ACK，链路层仍会对其数据包进行调度和传输处理。当链路层队列被Notify数据包占满时，新的Write请求数据包无法进入队列，GATT层会检测到链路层繁忙，返回对应的错误码。

可行的解决方向： #

• 给顺序Write加事务等待逻辑：不需要复杂队列，但必须确保前一个Write操作的GATT回调（成功/失败）返回后，再发起下一个Write请求，让ATT层有足够时间处理完当前事务，避免和Notify抢资源。
• 限制Notify的发送频率：如果Notify推送的是高频数据，做一下节流处理——比如合并小数据包、降低推送频率，减少对传输通道的持续占用。
• 调整BLE栈配置参数：部分BLE SDK允许配置ATT层的队列长度或GATT事务并发数，适当调大这些参数可以提升对并发操作的容忍度。
• 在Notify逻辑中避让Write操作：在Notify的发送代码里，增加一个状态检测——如果当前有Write操作正在执行，暂时暂停Notify推送，等Write完成后再恢复。

内容的提问来源于stack exchange，提问作者Harry