BLE 写操作详解：write_req 与 write_cmd

文章目录1. 协议栈层次定位1.1 协议栈层次结构1.2 ATT 层的作用2. 两种写操作的协议细节2.1 Write Request写请求2.2 Write Command写命令3. 与特性属性的对应关系3.1 对应关系总览3.2 特性属性的位定义3.3 属性组合的可能性4. 性能比较5. 常见问题与解决方案5.1 问题Write Command 发送失败如何检测5.2 问题Write Request 速度太慢5.3 问题如何确保兼容性6. 总结1. 协议栈层次定位在 BLE 协议栈中write_req和write_cmd属于 ATTAttribute Protocol层这是 BLE 协议栈中位于 L2CAP 层之上、GATT 层之下的关键层次。1.1 协议栈层次结构-------------------|应用层|← 开发者编写的应用程序-------------------|GATT层|← 特性、服务、描述符的管理-------------------|ATT层|← write_req/write_cmd 所在层次-------------------|L2CAP层|← 数据封装与复用-------------------|Link Layer|← 连接管理、广播-------------------|PHY层|←2.4GHz 射频-------------------1.2 ATT 层的作用ATT 层定义了客户端-服务器架构下的数据交互协议包括 6 种核心操作序号操作说明1请求Request客户端发送服务器(从机)必须响应2响应Response服务器对请求的回复3命令Command客户端发送服务器无需响应4通知Notification服务器发送客户端无需确认5指示Indication服务器发送客户端必须确认6确认Confirmation客户端对指示的回复2. 两种写操作的协议细节2.1 Write Request写请求操作码(opcode)0x12数据包格式--------------------------------------------|Opcode|Attribute Handle|Attribute Value||(1byte)|(2bytes)|(0-512bytes)|--------------------------------------------协议交互流程客户端手机 服务器开发板|||----Write Request-------||(opcode0x12)|||← 处理写入|---Write Response-------||(opcode0x13)|||特点可靠性必须收到响应才能进行下一次写入流量控制协议栈自动处理一次只能有一个未完成的请求错误处理服务器可以通过 Error Responseopcode0x01返回错误码最大数据长度ATT_MTU - 3 字节通常为 20-512 字节2.2 Write Command写命令操作码(opcode)0x52数据包格式-------------------------------------------|Opcode|Attribute Handle|Attribute Value||(1byte)|(2bytes)|(0-512bytes)|-------------------------------------------协议交互流程客户端手机 服务器开发板|||----Write Command-------||(opcode0x52)|||← 处理写入|(无需响应可连续发送)||||----Write Command-------||----Write Command-------|||特点高吞吐量无需等待确认可以连续发送无流量控制应用层需要自行处理流控无错误反馈写入失败无法通过协议层得知最大数据长度ATT_MTU - 3 字节同 Write Request3. 与特性属性的对应关系3.1 对应关系总览特性属性(Characteristic Properties)ATT层操作 CHAR_PROP_WRITE ←────────→ WriteRequest(0x08或0x04)(opcode0x12)CHAR_PROP_WRITE_WITHOUT_RSP ←────────→ WriteCommand(0x04或0x02)(opcode0x52)3.2 特性属性的位定义在 GATT 特性声明中属性是一个 1 字节的位掩码Bit:76543210----------------------------------------------------------|Broad-|Read|Write|Notify|Indi-|Write|Auth|Exten-||cast||without||cate|with|Signed|ded||||response|||response|Write|Prop|----------------------------------------------------------关键位说明-Bit1(0x02):Write without response-允许 Write Command-Bit2(0x04):Write-允许 Write Request-注意实际定义可能因蓝牙版本略有差异3.3 属性组合的可能性特性可以同时支持多种写入方式属性组合含义应用场景WRITE只支持可靠写入关键参数配置WRITE_WITHOUT_RSP只支持快速写入高速数据流WRITE WRITE_WITHOUT_RSP两种都支持灵活的应用需求4. 性能比较指标Write RequestWrite Command吞吐量低~10 KB/s高~100 KB/s延迟高3-10ms/包低可连续发送可靠性100%协议层确认不可靠需应用层保证流量控制协议层自动处理需应用层实现功耗较高每次都需要ACK较低减少无线通信次数并发发送只能一个接一个可以连续发送5. 常见问题与解决方案5.1 问题Write Command 发送失败如何检测解决方案实现应用层确认机制使用 Notify/Indicate 作为数据确认添加序列号超时重传机制5.2 问题Write Request 速度太慢解决方案增大 ATT_MTU通过 MTU Exchange考虑使用 Write Command 批量确认5.3 问题如何确保兼容性最佳实践在客户端读取特性属性根据支持情况选择写入方式服务器端同时支持两种写入方式增加灵活性关键数据同时使用两种方式Write Command 发送Notify 确认6. 总结理解 write_req 和 write_cmd 的区别以及它们与特性属性的对应关系对开发稳定高效的 BLE 应用至关重要1、协议层区分属于 ATT 层的两种不同操作有不同的 Opcode 和交互流程2、属性映射CHAR_PROP_WRITE对应write_reqCHAR_PROP_WRITE_WITHOUT_RSP对应write_cmd3、应用场景关键配置用 Write Request高速数据用 Write Command (如OTA)4、事件处理协议栈通过不同事件类型区分两种写入5、性能权衡可靠性 vs 吞吐量需要根据具体需求选择在实际开发中建议服务器端同时开放两种写入方式客户端根据数据特性选择合适的写入类型以达到最佳的用户体验。