BC5-MM、CSR867x的DFU更新流程之八：Gaia的理解与使用

YingbinLi 蓝牙

于 2021-08-02 17:38:05 发布

阅读量1.3k

点赞数

分类专栏： BT SOC

本文链接：https://blog.csdn.net/YingbinLi/article/details/119327839

版权

BT SOC 专栏收录该内容

13 篇文章 6 订阅

订阅专栏

Gaia的理解与使用

在OTA 升级中，其通过Gaia进行数据传送；本文将讨论Gaia的相关问题点；

问题点1：Gaia是什么？

Gaia 是CSR 制定的一个上层使用协议，其在BR/EDR 基于RFCOMM，可以理解为一个特别UUID的SPP；

Gaia 的UUID是00001107-D102-11E1-9B23-00025B00A5A5；

SPP 的UUID是00001101-0000-1000-8000-00805F9B34FB；

Gaia 其自定义了相关command，可以实现特定功能，如问询电池电量、版本号等；同时其也用于OTA中进行数据传送(但不解析数据)；

问题点2：Gaia的实现方式；

在经典蓝牙(BR/EDR)中，GAIA 分为RFCOMM and SPP两种方式，一般用在Android；

Gaia 也可以通过BLE 使用，具体体现在IOS中；

问题点3：Gaia 走SPP 和RFCOMM的区别；

Gaia 走frcomm，直接注册UUID“00001107-D102-11E1-9B23-00025B00A5A5”；
而如果走SPP，其注册标准SPP UUID“00001101-0000-1000-8000-00805F9B34FB”，即其真的在使用SPP进行通讯，但数据格式基于Gaia定义；

问题点4：Gaia的数据格式及command定义(V3之前的数据格式)；

讨论到Gaia的数据格式，有一点非常重要的是：gaia data format的分水岭是V3；

V3之前的格式,要注意BR/EDR 和BLE下的gaia 格式差异：

这里的“Length”表示实际playload长度，如果为0即表示没有playload;
“Check ”栏位实际就是“checksum”；
Gaia 的command 需要有ACK 回复表示其收到有效数据，其体现在Command ID 的最高位设置为1；同时playload 的第1个byte 通常表示状态值；

问题点5: Gaia V3格式定义;

数据格式最大的变化在于“Common ID”栏位，在V3之前，“Common ID”栏位独立表示一个command ，而在V3中，其使用bit组合形式形成3部分；

Feature ID: Feature-specific unique identifier
PDU Type
Command: 00
Notification: 01
Response: 10
Error: 11
PDU Specific ID: Feature-specific command ID. These are only unique within the Feature

需注意V3中Flags bit1 位设置为1 的为Length栏位延伸的功能；

V3中明确了手机端和Device 端的command 差异，同时强调了PDU type的执行方向;

问题点6：Gaia的单次packet最大发送size；

BLE 时最大为20Byte；BR/EDR时最大为254Byte。

问题点7：Gaia的packet中，数据大于8bit时的大小端定义；

在文档《BC-211724》中提到：
“Numeric fields longer than 8 bits are packed with the most
significant octet first. Textual strings are encoded using UTF-8.”
即高8位在前，即大端模式；