蓝牙GATT和GAP层

1、开篇

    本篇主要介绍一下关于BLE开发过程当中必须了解的两个协议：GAP（通用访问协议）、GATT（通用属性协议）。两个协议都隶属于Host层，直接关系到应用层开发，与BLE开发人员的关系比较密切，其分别负责链接前数据广播和链接后的数据传输。

 

3、试验平台

Software Version：BLE_STACK_CC26XX_2.1.0

Hardware Version：CC2640/CC2650

IDE：IAR 7.40

4、GAP

 

    一、蓝牙低能耗技术“完成”一次链接(即扫描其它设备、创建链路、发送数据、认证和适当地结束)只需3ms。而标准蓝牙技术完成相同的链接周期须要数百毫秒。

    GAP层有4种不一样类型的广播：通用的、定向的、不可链接的以及可发现的。

    设备每次广播时，会在3个广播信道上发送相同的报文。这些报文被称为一个广播事件。除了定向报文之外，其余广播事件都可以选择20ms - 10.28s不等的间隔。一般，一个广播中的设备会每一秒广播一次。广播事件之间的时间称为广播间隔。主机能够控制该间隔。可是，设备周期性的发送广播会有一个问题：因为设备间的时钟会不一样程度的漂移，两个设备可能在很长一段时间同时广播而形成千扰。为防止选一状况的发生，在上一次广播事件发生后加入随机延时。它们发送下一个广播事件时也极可能再也不冲突。

    通用广播：通用广播是用途最广的广播方式。进行通用广播的设备可以被扫描设备扫描到，或者在接收到链接请求时做为从设备进入一个链接。通用广播能够在没有链接的状况下发出，换句话说，没有主从设备之分。

    定向广播：有时候，设备间须要快速创建链接。若是从设备想这么作，就须要进行广播。定向广播事件就是为了尽量快的创建链接。这种报文包含两个地址：广播者的地址和发起者的地址。发起设备收到发绐本身的定向广播报文后，能够当即发送链接请求做为回应。

    不可链接广播：不想被链接的设备使用不可链接广播事件。这种广播的典型应用包括设备只想广播数据，而不想被扫描或者链接。速也是惟一可用于只有发射机而没有接收机设备的广播类型。不可链接广播设备不会进入链接态，所以，它只能根据主机的要求在广播态和就绪态之间切换。

    可发现广播：最后一种广播事件是可发现广播。这种广播不能用于发起链接，但容许其余设备扫描该广播设备。这意味着该设备能够被发现，既能够广播数据，又能够响应扫描，但不能创建链接。这是一种适用于广播数据的广播形式，动态数据能够包含于广播数据之中，而静态数据能够包含于扫描响应数据之中。可发现广播不会进入链接态，而只能在中止后回到就绪态。

    如上面所述，BLE设备能够进行广播。可是，一个广播设备必须在广播中包含一些有用的数据。这意味着能够经过4种广播事件中的3种进行广播：通用广播、不可链接广播以及可发现广播。进行广播时，须要在广播报文中给数据打上标签。之因此要这么作，是由于并不是全部设备都能理解全部可能的广播数据。所以，须要给广播数据打上标签并指出其长度。每一个数据片断均起始于一个长度域，用以指示后面的类型及数据域的长度；接下来是类型域，接收机可根据其内容判断本身是否可以理解后面的数据。事例代码：

1. // GAP - Advertisement data (max size = 31 bytes, though this is
2. // best kept short to conserve power while advertisting)
3. static uint8_t advertData[] =
4. {
5. // Flags; this sets the device to use limited discoverable
6. // mode (advertises for 30 seconds at a time) instead of general
7. // discoverable mode (advertises indefinitely)
8. 0x02, // length of this data
9. GAP_ADTYPE_FLAGS,
10. DEFAULT_DISCOVERABLE_MODE | GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED,
11.  
12. // service UUID, to notify central devices what services are included
13. // in this peripheral
14. 0x03, // length of this data
15. GAP_ADTYPE_16BIT_MORE, // some of the UUID's, but not all
16. #ifdef FEATURE_OAD
17. LO_UINT16(OAD_SERVICE_UUID),
18. HI_UINT16(OAD_SERVICE_UUID)
19. #else
20. LO_UINT16(SIMPLEPROFILE_SERV_UUID),
21. HI_UINT16(SIMPLEPROFILE_SERV_UUID)
22. #endif //!FEATURE_OAD
23. };

 

5、GATT

    通用属性配置文件(GATT)在属性协议(ATT)的基础上构建，为属性协议传输和存储数据创建了一些通用操做和框架。

1）GATT定义了两个角色：服务器和客户端。

    GATT的角色并不必定与特定的GAP角色有关联，但可能由更高层级的配置文件指定。GATT和ATT不是传输专用，也能够用于BR/EDR和低耗能。可是，因为GATT和ATT用做发现服务，故必须在低耗能技术中实施。GATT服务器存储经过属性协议传输的数据，并接受GATT客户端发出的属性协议请求、指令及确认。GATT服务器发送请求回复，而若是在配置时GATT服务器发生特定事件，则会向GATT客户端异步发送指示和通知。GATT还指定GATT服务器中所载的数据格式。

    属性在当经由属性协议传输时，会被格式化为相关的服务和特性。服务可能包括许多特征。特征包括单一值和许多描述特征值的描述符。

凭借经定义的服务、特征和特征描述符架构，并不是配置文件特定的GATT客户端仍然能够遍历GATT服务器，并向用户显示特征值。特征描述符可用于显示特征值的描述符，从而可以让用户了解该值。

2）GATT配置文件层级

    GATT配置文件规格规定了交换配置文件数据的架构。此架构定义了配置文件所用的基本元素，例如服务和特征。

该层级的最高层是配置文件（profile）。配置文件由实现用例所需的一个或多个服务组成。服务由特征或有关其它服务的引用组成。每个特征包括一个值，还可能包括有关该值的可选信息。服务、特征以及特征的组件（即特征值和特征描述符）构成了配置文件数据，并所有存储在服务器的属性中。

    英文原版（摘自Core_V4.1 vol 1:6.5，p226）：The top level of the hierarchy is a profile. A profile is composed of oneor more services necessary to fulfill a use case. A service is composed of characteristicsor references to other services. Each characteristic contains a value and maycontain optional information about the value. Theservice and characteristic and the components of the characteristic (i.e.,value and descriptors) contain the profile data and are all stored in Attributes on theserver.

 

3）服务

    服务是数据和完成设备或设备的某些部分的特定功能或特征的相关行为的集合。服务可能涉及其它主要或次要服务和／或构成该服务的特征集合。

服务分为两种类型：主要服务和次要服务。主要服务提供设备的主要功能。次要服务提供设备的辅助功能，引用自该设备至少一项主要服务。

为了令早前的客户端保持向后兼容性，服务定义的其后修订仅可增长新引用的服务或可选特征。服务定义的其后修订也不得改变该服务定义先前修订的特征。

服务可能用于一个或多个配置文件，以实现特定用例。

4）特征

    特征，连同属性和有关如何访问该值的配置信息以及有关如何显示或表述该值的信息，是用于服务的值。特征定义包含特征声明、特征属性和值。它还可能包含描述该值或容许服务器配置有关特征值的描述符。

协议栈代码实现以下：

 

1. /*********************************************************************
2. * Profile Attributes - variables
3. */
4. // Simple Profile Service attribute
5. static CONST gattAttrType_t simpleProfileService = { ATT_BT_UUID_SIZE, simpleProfileServUUID };
6. // Simple Profile Characteristic 1 Properties
7. static uint8 simpleProfileChar1Props = GATT_PROP_READ | GATT_PROP_WRITE;
8. // Characteristic 1 Value
9. static uint8 simpleProfileChar1 = 0;
10. // Simple Profile Characteristic 1 User Description
11. static uint8 simpleProfileChar1UserDesp[17] = "Characteristic 1";
12.  
13.  
14. /*********************************************************************
15. * Profile Attributes - Table
16. */
17. static gattAttribute_t simpleProfileAttrTbl[SERVAPP_NUM_ATTR_SUPPORTED] =
18. {
19. // Simple Profile Service
20. {
21. { ATT_BT_UUID_SIZE, primaryServiceUUID }, /* type */
22. GATT_PERMIT_READ, /* permissions */
23. 0, /* handle */
24. (uint8 *)&simpleProfileService /* pValue */
25. },
26. // Characteristic 1 Declaration
27. {
28. { ATT_BT_UUID_SIZE, characterUUID },
29. GATT_PERMIT_READ,
30. 0,
31. &simpleProfileChar1Props
32. },
33. // Characteristic Value 1
34. {
35. { ATT_BT_UUID_SIZE, simpleProfilechar1UUID },
36. GATT_PERMIT_READ | GATT_PERMIT_WRITE,
37. 0,
38. &simpleProfileChar1
39. },
40. // Characteristic 1 User Description
41. {
42. { ATT_BT_UUID_SIZE, charUserDescUUID },
43. GATT_PERMIT_READ,
44. 0,
45. simpleProfileChar1UserDesp
46. },

5）关于句柄handle 和UUID

    Handle便是地址（记住它，类比于C语言的指针操做）

    属性句柄：一台设备能够有许多的属性，例如温度传感器可能包含温度属性、设备名称属性和电池电量属性。表面看来，经过属性类型彷佛足以判别某种属性。好比使用温度属性来获取温度，经过设备名称属性来获取设备名等。可是，若是设备包含了两种温度属性，好比一个室内温度传感器加上室外温度传感器，状况会变得怎样。这时你便没法直接读取温度传感器，而必须读取第一个或第二个温度属性。考虑到可能有任意多个温度传感器，问题将变得更加复杂。为了解决这个同题，咱们使用了一个16位的地址，也就是属性句柄。有效的句柄范围从0x0001--xFFFF。0x0000为无效句柄，不能用于寻址属性。能够根据在软硬件或嵌入式方面的背景，把句柄（Handle）相应地想象为内存地址、端口号、属性值对应的硬件寄存器地址。

    属性类型：能够被公开的数据有许许多多的类型：温度、压强、体积、距离、功率、时间、充电状态、开关状态、状态机的状态等。所公开的数据的种类称做属性类型。为了区分如此多的数据类型，一串128位的数字被用来标识属性的类型。这个惟一标识码就叫作通用惟一识别码（UUID），128位的UUID至关长，设备间为了识别数据的类型须要发送长达16个字节的数据。为了提升传输效率，蓝牙技术联盟( SIG)定义了一种称为“蓝牙UUID基数”的128位通用惟一识别码，结合一个较短的16位数使用。两者仍然遵循通用惟一识别码的分配规则，只不过在设备间传输经常使用的UUID时，只发送较短的16位版本，接收方收到后补上蓝牙的UUID基数便可。

蓝牙UUID基数以下：

00000000—0000—1000—8000—00805F9B34FB

例如要发送的16位识别码位0X2A01，完整的128位UUID即是：

00002A01—0000—1000—8000—00805F9B34FB

    由上所述，因此在协议栈代码中常常见到的都是16位的UUID而不常见128位的UUID的缘由所在，下面是官方demo的UUID，供参考。

1. // Simple Profile Service UUID
2. #define SIMPLEPROFILE_SERV_UUID 0xFFF0
3.  
4. // Key Pressed UUID
5. #define SIMPLEPROFILE_CHAR1_UUID 0xFFF1
6. #define SIMPLEPROFILE_CHAR2_UUID 0xFFF2
7. #define SIMPLEPROFILE_CHAR3_UUID 0xFFF3
8. #define SIMPLEPROFILE_CHAR4_UUID 0xFFF4
9. #define SIMPLEPROFILE_CHAR5_UUID 0xFFF5

谈到16位的UUID，一般不直接使用数值，而是冠以一个名称并加上书名号（这些UUID能够在gatt_profile_uuid.h中查看到）

0x1800 - 0x26FF用做服务类通用惟一识别码

0x2700 - 0x27FF用于标识计量单位

0x2800 - 0x28FF用于区分属性类型

0x2900 - 0x29FF用做特性描述

0x2A00- 0x7FFF用于区分特性类型

UUID，就是用来惟一识别一个特征值的ID。

handle，就是对应的attribute的一个句柄。

具体细节详见：Generic Attribute Profile (GATT)

摘抄一部分源码供参考：

1. /**
2. * GATT Service UUIDs
3. */
4. #define IMMEDIATE_ALERT_SERV_UUID 0x1802 // Immediate Alert
5. #define LINK_LOSS_SERV_UUID 0x1803 // Link Loss
6. #define TX_PWR_LEVEL_SERV_UUID 0x1804 // Tx Power
7. #define CURRENT_TIME_SERV_UUID 0x1805 // Current Time Service
8. #define REF_TIME_UPDATE_SERV_UUID 0x1806 // Reference Time Update Service
9.  
10. /**
11. * GATT Characteristic UUIDs
12. */
13. #define ALERT_LEVEL_UUID 0x2A06 // Alert Level
14. #define TX_PWR_LEVEL_UUID 0x2A07 // Tx Power Level
15. #define DATE_TIME_UUID 0x2A08 // Date Time
16. #define DAY_OF_WEEK_UUID 0x2A09 // Day of Week
17. #define DAY_DATE_TIME_UUID 0x2A0A // Day Date Time
18. #define EXACT_TIME_256_UUID 0x2A0C // Exact Time 256
19.  
20. /**
21. * GATT Unit UUIDs
22. */
23. #define GATT_UNITLESS_UUID 0x2700 // <Symbol>, <Expressed in terms of SI base units>
24. #define GATT_UNIT_LENGTH_METER_UUID 0x2701 // m, m
25. #define GATT_UNIT_MASS_KGRAM_UUID 0x2702 // kg, kg

    全部对特征值的操做，都是经过对UUID 的搜索获得对应的handle以后，经过handle来操做特征值的。对于蓝牙通讯来讲，其都是经过一个个不一样的UUID来标识区分不一样的服务，区分不一样的特性，甚至服务和特性之间的类别。

 

 

6、总结

    不知道写什么了，就这样吧，后续想到了写吧，学习BLE也不久，路还很长。路漫漫其修远兮，吾将上下而求索~~~

    PS：该死的房价。。。。啊啊啊啊啊啊。。。。

    参考：1）蓝牙技术联盟官方网站

               2）Bluetooth开发者门户

               3）Bluetooth Spec Core_V4.1

 

 

注：本文转载自https://blog.csdn.net/qq_21842557/article/details/50771077，真心是一篇好文章！