TI CC2540/41 Bluetooth低功耗软件开发者指南V1.2概述

4星 · 超过85%的资源需积分: 10 170 浏览量更新于2024-07-28 收藏 629KB PDF 举报

"TI CC2540/41 Bluetooth Low Energy Software Developer's Guide V1.2" TI的CC2540/41 Bluetooth Low Energy (BLE) 软件开发者指南V1.2版是针对使用TI CC2540和CC2541芯片进行蓝牙低功耗应用开发的重要参考资料。该文档旨在帮助开发者理解并利用TI提供的软件开发平台，包括协议栈、操作系统抽象层、硬件抽象层以及各种配置和项目设置。文档首先介绍了BLE协议栈的基础知识，包括蓝牙低功耗技术的基本概念。接着，详细阐述了TI的BLE软件开发平台，其中： 1. 配置部分涵盖了不同的系统设置选项，以适应不同应用场景的需求。 2. 操作系统抽象层（OSAL）提供了一个与具体操作系统无关的接口，使得软件可以跨多个操作系统平台运行。它包括任务初始化、任务事件和事件处理、堆管理器以及OSAL消息机制。 - 任务初始化是创建和配置任务的过程，确保在系统启动时正确设置各个任务。 - 任务事件和事件处理是OSAL的核心部分，允许任务之间通过事件进行通信和同步。 - 堆管理器负责内存分配和释放，优化内存使用。 - OSAL消息系统则用于任务间的异步通信。 3. 硬件抽象层（HAL）是硬件与软件之间的接口，它隐藏了底层硬件细节，使开发者能够更专注于应用程序逻辑而不是具体的硬件操作。 4. 软件概述部分深入探讨了BLE协议栈，包括： - Generic Access Profile (GAP) 是BLE设备发现、连接和安全性的基础，定义了设备如何进入发现模式、建立连接以及管理连接参数。 - Generic Attribute Profile (GATT) 是BLE数据传输的核心，提供了服务、特性和属性的概念，使得数据在设备间有序传输。 - 使用GAP和GATT的API，开发者可以创建和管理BLE设备的角色和服务。 - GATT服务器应用API允许开发者定义和实现自定义服务。 - 库文件部分列出了支持这些功能的具体库文件。 5. 最后，文档提到了各种配置文件，如GAP外围角色、GAP外围/广播者多角色、GAP中心角色、GAP绑定管理器、简单GATT配置文件和简单密钥GATT配置文件，这些配置文件提供了预定义的角色和功能，便于快速开发。此开发者指南对于那些希望在TI CC2540/41芯片上构建高效、节能的BLE应用的开发者来说，是一份非常宝贵的资源，它详细地指导了从基础到高级的整个开发过程。

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271B Version 1.2

2.4 Projects

The SimpleBLEPeripheral project consists of sample code that demonstrates a very simple

application in the single-device configuration. It can be used as a reference for developing a slave

/ peripheral application.

The SimpleBLECentral project is similar, in that it demonstrates a simple master / central

application in the single-device configuration, and can be used as a reference for developing

master / central applications.

The HostTestRelease project is used to build the BLE network processor software for the

CC2540/41. It contains configurations for both master and slave roles.

Several other sample projects are included in the BLE development kit, implementing various

profiles and demo applications. More information on these projects can be found in [5]

3 Software Overview

Software developed using the BLE 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.2\.

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.

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 ord

er 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

Page 9 of 49

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271B Version 1.2

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 compl

etes 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

OSAL provid

es 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.

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

Page 10 of 49

剩余49页未读，继续阅读

weitebb

粉丝: 0
资源: 1

TI CC2540/41 Bluetooth低功耗软件开发者指南V1.2概述

TI_BLE_Software_Developer's_Guide

CC2640_BLE_Software_Developer's_Guide.pdf

ble软件开发指南

ti_ble_vendor_specific_hci_guide.pdf

ti_simplelink_cc13x0_sdk下载

__TI_ISR_TRAP；是什么意思？

TI CC2540/CC2541

$ti_yestday_format

typedef ti_sysbios_knl_Task_Object* ti_sysbios_knl_Task_Handle;

最新资源