TI CC254x BLE软件开发详解

4星 · 超过85%的资源需积分: 9 70 浏览量更新于2024-07-26 收藏 2.2MB PDF 举报

"BLE软件开发指南" 本指南详细介绍了在Texas Instruments CC2540/41芯片上进行蓝牙低功耗(BLE)软件开发的方法。BLE ZStack是TI提供的一个全面的软件框架，用于简化BLE协议栈的实现。文档版本为v1.3，涵盖了从基础概念到实际应用的各种知识点。 1. **概述** - **介绍**：这部分简要介绍了BLE技术以及TI的BLE软件开发平台，为开发者提供了一个初步的理解。 - **BLE协议栈基础**：解释了BLE协议栈的基本组成和工作原理，包括连接、数据传输和能量效率等方面。 2. **德州仪器BLE软件开发平台** - **配置**：详细阐述了如何配置开发环境，包括硬件和软件设置，以便于开发者根据项目需求定制。 - **项目**：讨论了项目结构，说明了如何组织和管理代码，以及如何创建和运行BLE应用程序。 3. **软件概览** - **操作系统抽象层(OSAL)**：OSAL提供了任务初始化、事件处理、内存管理和消息传递等服务，使得软件开发与具体的操作系统解耦。 - **Task Initialization**：描述了如何启动和管理任务。 - **Task Events and Event Processing**：详细讲解了任务事件的处理机制。 - **Heap Manager**：讨论了内存分配和释放策略。 - **OSAL Messages**：介绍了OSAL中的消息传递机制。 - **硬件抽象层(HAL)**：HAL为开发者提供了与硬件交互的接口，屏蔽了底层硬件的复杂性。 - **BLE协议栈**：包括BLE协议栈的主要组件，如GAP和GATT。 - **Generic Access Profile (GAP)**：GAP定义了设备如何发现、连接和断开连接，包括设备的角色和模式。 - **Generic Attribute Profile (GATT)**：GATT是BLE中的数据服务和特性的标准框架。 - **使用GAP和GATT Stack API**：讲解如何通过API进行GAP和GATT功能的调用。 - **GATT Server Application API**：介绍了创建和管理服务器端GATT服务的API。 - **库文件**：列出了用于BLE开发的关键库文件及其作用。 4. **配置文件** - **配置文件**：讨论了配置文件的作用，如何配置设备的角色（如外围设备、中心设备）和其他参数。 5. **配置文件** - **GAP Peripheral Role Profile**：详细介绍了作为外围设备的角色配置和操作。 - **GAP Peripheral/Broadcaster Multi-Role Profile**：涵盖了同时作为外围设备和广播者的多角色配置。 - **GAP Central Role Profile**：解释了作为中心设备的角色配置和连接管理。此指南是针对TI CC2540/41 BLE开发的宝贵资源，涵盖了从基本概念到高级应用的各个方面，对于希望深入了解和开发BLE应用的工程师来说非常有价值。通过深入学习和实践，开发者可以有效地利用TI的BLE软件栈来创建高效能、低功耗的蓝牙产品。

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271D Version 1.3

3 Software Overview

Software developed using the BLE software development kit consists of five major sections: the

OSAL, HAL, the BLE Protocol Stack, profiles, and the application. The BLE protocol stack is

provided as object code, while the OSAL and HAL code is provided as full source. In addition,

three GAP profiles (peripheral role, central role, and peripheral bond manager) are provided, as

well as several sample GATT profiles and applications.

All path and file references in this document assume that the BLE development kit software has

been installed to the default path: C:\Texas Instruments\BLE-CC254X-1.3\.

Note. In this section, the SimpleBLEPeripheral project will be used as a reference; however all

of the BLE projects included in the development kit will have a similar structure.

3.1 Operating System Abstraction Layer (OSAL)

The BLE protocol stack, the profiles, and all applications are all built around the Operating System

Abstraction Layer (OSAL). The OSAL is not an actual operating system (OS) in the traditional

sense, but rather a control loop that allows software to setup the execution of events. For each

layer of software that requires this type of control, a task identifier (ID) must be created, a task

initialization routine must be defined and added to the OSAL initialization, and an event

processing routine must be defined. Optionally, a message processing routine may be defined as

well. Several layers of the BLE stack, for example, are OSAL tasks, with the LL being the highest

priority (since it has very strict timing requirements).

In addition to task management, the OSAL provides additional services such as message

passing, memory management, and timers. All OSAL code is provided as full source.

Figure 5: OSAL task loop

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271D Version 1.3

Note: The OSAL is capable of providing many more services than are covered in this guide,

including message management, timer management, and more; however for many applications

this level of depth is not required. This guide should serve as an introduction to the basic

framework of the OSAL.

Additional information on the OSAL can be found in [1]:

3.1.1 Task Initialization

In order to use the OSAL, at the end of the main function there should be a call to

osal_start_system. This is the OSAL routine that starts the system, and which will call the

osalInitTasks function that is defined by the application. In the SimpleBLEPeripheral project, this

function can be found in the file OSAL_SimpleBLEPeripheral.c.

Each layer of software that is using the OSAL must have an initialization routine that is called from

the function osalInitTasks. Within this function, the initialization routine for every layer of software

is called. As each task initialization routine is called, an 8-bit “task ID” value is assigned to the

task. Note that when creating an application, it is very important that it be added to the end of the

list, such that it has a higher task ID than the others. This is because the priority of tasks is

determined by the task ID, with a lower value meaning higher priority. It is important that the

protocol stack tasks have the highest priority in order to function properly. Such is the case with

the SimpleBLEPeripheral application: its initialization function is SimpleBLEPeripheral_Init, and

it has the highest task ID and therefore the lowest priority.

3.1.2 Task Events and Event Processing

After the OSAL completes initialization, it runs the executive loop checking for task events. This

loop can be found in the function osal_start_system in the file OSAL.c. Task events are

implemented as a 16-bit variable (one for each task) where each bit corresponds to a unique

event. The definition and use of these event flags is completely up to the application.

For example, the SimpleBLEPeripheral application defines a flag in simpleBLEPeripheral.h:

SBP_START_DEVICE_EVT (0x0001), which indicates that the initial start has completed, and

the application should begin. The only flag value which is reserved and cannot be defined by the

application is 0x8000, which corresponds to the event SYS_EVENT_MSG (this event is used for

messaging between tasks, which is covered in section 3.1.3).

When the OSAL detects an event for a task, it will call that task‟s event processing routine. The

layer must add its event processing routine to the table formed by the array of function pointers

called tasksArr (located in OSAL_SimpleBLEPeripheral.c in the example). You will notice that

the order of the event processing routines in tasksArr is identical to the order of task ID‟s in the

osalInitTasks function. This is required in order for events to be processed by the correct

software layer.

In the case of the SimpleBLEPeripheral application, the function is called

SimpleBLEPeripheral_ProcessEvent. Note that once the event is handled and if it is not

removed from the event flag, the OSAL will continue to call the task‟s process event handler. As

can be seen in the SimpleBLEPeripheral application function

SimpleBLEPeripheral_ProcessEvent, after the START_DEVICE_EVT event occurs, it returns

the 16-bit events variable with the SBP_START_DEVICE_EVT flag cleared.

It is possible for any layer of the software to set an OSAL event for any other layer, as well as for

itself. The simplest way to set up an OSAL event is to use the osal_set_event function (prototype

in OSAL.h), which immediately schedules a new event. With this function, you specify the task ID

(of the task that will be processing the event) and the event flag as parameters.

Another way to set an OSAL event for any layer is to use the osal_start_timerEx function

(prototype in OSAL_Timers.h). This function operates just like the osal_set_event function. You

select task ID of the task that will be processing the event and the event flag as parameters;

however for a third parameter in osal_start_timerEx you input a timeout value in milliseconds.

The OSAL will set a timer, and the specified event will not get set until the timer expires.

3.1.3 Heap Manager

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271D Version 1.3

OSAL provides basic memory management functions. The osal_mem_alloc function serves as a

basic memory allocation function similar to the standard C malloc function, taking a single

parameter determining the number of bytes to allocate, and returning a void pointer. If no memory

is available, a NULL pointer will be returned. Similarly, the osal_mem_free function works similar

to the standard C free function, freeing up memory that was previously allocated using

osal_mem_alloc.

The pre-processor define INT_HEAP_LEN is used to reserve memory for dynamic allocation.

To see how much memory you typically need, you can set the pre-processor define

OSALMEM_METRICS=TRUE in the project options. After a stress test of the application where

you send as many messages, have as many clients as you will in the worst case, remembering to

use bonding and encryption during the test if that‟s applicable, you can look at the value of the

variable memMax in OSAL_Memory.c to see how much memory was ever allocated at the same

time. This figure could be used as a guideline for lowering INT_HEAP_LEN if necessary, but

thorough testing is needed, as the heap is used by the BLE stack.

3.1.4 OSAL Messages

OSAL also provides a system for different subsystems of the software to communicate with each

other by sending or receiving messages. Messages can contain any type of data and can be any

size. To send an OSAL message, first the memory must be allocated by calling the

osal_msg_allocate function, passing in the length of the message as the only parameter. A

pointer to a buffer containing the allocated space will be returned (you do not need to use

osal_mem_alloc when using osal_msg_allocate). If no memory is available, a NULL pointer will

be returned. You can then copy the data into the buffer. To send the message, the

osal_msg_send should be called, with the destination task for the message indicated as a

parameter.

The OSAL will then signal the receiving task that a message is arriving by setting the

SYS_EVENT_MSG flag for that task. This causes the receiving task‟s event handler function to

be called. The receiving task can then retrieve the data by calling osal_msg_receive, and can

process accordingly based on the data received. It is recommended that every OSAL task have a

local message processing function (the simpleBLEPeripheral application‟s message processing

function is simpleBLEPeripheral_ProcessOSALMsg) that decides what action to take based on

the type of message received. Once the receiving task has completed processing the message, it

must deallocate the memory using the function osal_msg_deallocate (you do not need to use

osal_mem_free when using osal_msg_deallocate).

3.2 Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer (HAL) of the CC2540/41 software provides an interface of

abstraction between the physical hardware to and the application and protocol stack. This allows

for the development of new hardware (such as a new PCB) without making changes to the

protocol stack or application source code. The HAL includes software for the SPI and UART

communication interfaces, ADC, keys, and LED‟s etc. The HAL drivers that are provided support

the following hardware platforms:

 SmartRF05EB + CC2540EM

 SmartRF05EB + CC2541EM

 CC2540 Keyfob

 CC2541 Keyfob

 CC2541 SensorTag

 CC2540 USB Dongle

When developing with a different hardware platform, it might be necessary to modify the HAL

source for compatibility.

More information on the HAL API can be found in [2].

剩余52页未读，继续阅读

mysky12349

粉丝: 1
资源: 23

TI CC254x BLE软件开发详解

TI CC2540/41 Bluetooth Low Energy软件开发指南

CC2540芯片BLE4.0软件开发指南

TI CC254x BLE软件开发全面解析

ble软件开发指南

泰凌 Kite BLE SDK 开发指南.pdf

TI CC2540BLE软件开发帮助

泰凌TLSR826x BLE SDK开发指南

使用堆管理与BLE应用开发指南

CC2640 BLE软件开发：低功耗特性与平台指南

CC2640 BLE软件开发者指南中文翻译

最新资源