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

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位在前，即大端模式；

 

问题点8： Gaia的具体连接流程(BR/EDR)；

 

 问题点9：关于不同Gaia 版本的兼容问题；

建议在Gaia连接后，使用command ID 为0x0300的“Get API Version”确认Remote Device的最高支援Gaia 版本，然后基于不同版本来选择不同的Gaia Data格式；