【SensorTag】The second week TI蓝牙协议

ddllxxrr

【SensorTag】The second week TI蓝牙协议 [复制链接]

BLE软件共分5个部分：OSAL，HAL,the BLE Protocol Stack,profiles,和应用。

一、OSAL:不是一个绝对的操作系统，它是一个绝对循环系统，允许软件在其上面设置

要执行的事件。一个任务ID必须被建立，初始化程序必须定义，事件处理进程必须被

建立。OSAL还提供了内存管理，时间管理等附加功能。

其工作过程如图：

初始化：在主函数里必须写osal_start_system，这样系统会调osalInitTasks函数，这个函数会在各个层初始化，一个8比特ID被分配。

任务事件和事件处理：当初始化完成，系统就运行检测事件的循环，任务事件执行在一个

16比特的变量（每个任务都有）每一个比特代表一个应用的完成，如：SBP_START_DEVICE_EVT (0x0001)代表初始化完成。SYS_EVENT_MSG（0x8000）这个用来指示任务之通讯的。

堆栈管理：osal_mem_alloc函数相当于C语言的malloc函数，osal_mem_free相当于C语言的free函数。

OSAL 消息：OSAL也提供了一个系统对不同的子系统间通讯，发送和接收消息。消息可以含有任何类型并且任何长度。

发送一个OSAL消息，必须先调osal_msg_allocate函数锁定内存地址。其唯一的参数是消息的长度。一个指向缓冲的地址将要反回。如果存贮空间不可用一个空指针将被反回。发送消息将调用带有目的ID的osal_msg_send函数。

OSAL将把接收方的SYS_EVENT_MSG设为1，这导致了接收任务事件句柄功能起作用。

接收任务调osal_msg_receive接收。当接收完了就重新分配内存。

二、Hardware Abstraction Layer (HAL)：硬件抽象层：这层包括SPI和UART等通讯接口，通过修改这一层可以不用修改协议栈方面的程序。

三、BLE Protocol Stack：

BLE协议栈：TI提供了一个库文件，没有提供原码。在GAP和GATT层的一些功能可以通过应用和配置文件来实现。

协议栈包括两部分：通用访问配置文件Generic Access Profile (GAP)，通用属性配置文件Generic Attribute Profile (GATT)。

GAP通用访问配置文件，有四个角色：

广播：一个没有连接的广播。

观察：寻找广播人，但不初始化连接。

外设：一个广播者连接，做为一个从连接口连接。

中心：寻找广播者，并初始化连接；操作一个或多个连接层的连接。BLE可支持三个相同的连接。



GAP有几个参数：

1、 连接间隔

2、 潜伏时间

3、 监视溢出

Generic Attribute Profile (GATT)通用属性配置文件：

该层是BLE协议用来进得两个连接设备之间的通讯。

两个设备分别有两个角色：

GATT客户：客户端可以向服务端读写数据。

GATT服务：服务端只能收客户端的数据。

一个从设备即可以是GATT客户也可以是GATT服务。一个主设备也一样。

“字符”是一个服务端的属性，GATT定义了子函数用来发现，读出，写入属性。当一个BLE连接成功后，“字符”的值也就在GATT服务端确定。这是由于服务端有一个属性表。

属性表有以下属性：

 Handle – 这个相当于地址在表中的位置，每一个属性有唯一的地址。

 Type – 这个指示了数据代表什么，经常是蓝牙协议定义好的或用户自定的数据类型。

 Permissions – 这个是当客户端设备要处理属性时的允不允许的强制属性。

以下是几个GATT的子功能：

 Read Characteristic Value – The clientrequests to read the characteristic value at a specific

handle, and the server responds to theclient with the value (assuming that the attribute has

read permissions).

 Read Using Characteristic UUID – The client requests to read allcharacteristic values of a

certain type, and the server responds tothe client with the handles and values (assuming that

the attribute has read permissions) of allcharacteristics with matching type. The client does

not need to know the handles of thesecharacteristics.

 Read Multiple Characteristic Values – The client requests to read thecharacteristic values

of several handles in a single request, andthe server responds to the client with the values

(assuming that the attributes all have readpermissions). The client must know how to parse

the data between the differentcharacteristic values.

 Read Characteristic Descriptor – The client requests to read acharacteristic descriptor at a

specific handle, and the server responds tothe client with the descriptor value (assuming that

the attribute has read permissions).

 Discover Characteristic by UUID – The client requests to discover thehandle of a specific

characteristic by its type. The serverresponds with the characteristic declaration, containing

the handle of the characteristic value aswell as the characteristic’s permissions.

 Write Characteristic Value – The client requests to write acharacteristic value at a specific

handle to the server, and the serverresponds to the client to indicate whether the write was

successful or not.  

 Write Characteristic Descriptor – The client requests to write to acharacteristic descriptor

at a specific handle to the server, and theserver responds to the client to indicate whether the

write was successful or not.

 Characteristic Value Notification – Theserver notifies the client of a characteristic value.

The client does not need to prompt theserver for the data, nor does it need to send any

response when a notification is received,but it must first configure the characteristic to enabl

notifications. A profile defines when theserver is supposed to send the data.

bjmonsoon

学习了 谢谢