Texas Instruments CC2540/41 Bluetooth Low Energy (BLE) Software Developer's Guide

需积分: 10 51 浏览量更新于2024-07-23 收藏 2.22MB PDF 举报

"Texas Instruments CC2540/41 Bluetooth Low Energy Software Developer’s Guide" 这篇文档是关于Texas Instruments的CC2540/41蓝牙低能量（BLE）软件开发工具包的概述，同时它也作为BLE标准的入门介绍，但不替代完整的规范文档。这份指南主要针对的是软件开发者，旨在帮助他们理解和使用TI的BLE软件开发平台。 TI的CC254x系列是专为蓝牙低功耗应用设计的微控制器，适用于智能穿戴设备、物联网(IoT)设备和各种节能无线连接解决方案。 1.1 引言文档的引言部分介绍了CC2540/41芯片以及与其相关的BLE软件开发环境，强调了该平台对于理解和开发BLE应用的重要性。 1.2 BLE协议栈基础这部分简要介绍了BLE协议栈的基本结构和工作原理，包括连接、数据传输和功耗管理等核心概念。 2. 德州仪器BLE软件开发平台 2.1 配置此节讨论了不同配置选项，允许开发者根据项目需求定制硬件和软件设置。 2.2 项目开发者可以创建和管理项目，这部分解释了如何配置和组织项目的源代码和资源。 3. 软件概述 3.1 操作系统抽象层（OSAL） OSAL提供了跨平台的接口，包括任务初始化、任务事件处理、堆管理以及消息传递机制，确保软件在不同操作系统上的一致性。 3.1.1 任务初始化详述了如何启动和配置任务，以确保系统运行时的正确调度。 3.1.2 任务事件和事件处理解释了任务间通信和事件处理的机制，包括如何响应和处理来自其他任务或硬件的事件。 3.1.3 堆管理描述了内存分配和释放的管理策略，以优化内存使用并防止内存泄漏。 3.1.4 OSAL消息介绍了OSAL中的消息结构和消息传递方式，用于不同任务之间的通信。 3.2 硬件抽象层（HAL） HAL提供了与具体硬件无关的接口，使软件独立于底层硬件细节，简化了跨平台移植。 3.3 BLE协议栈 3.3.1 Generic Access Profile (GAP) GAP定义了设备发现、连接和断开连接的流程，是BLE通信的基础。 3.3.2 Generic Attribute Profile (GATT) GATT负责数据服务和特性，允许设备之间交换和存储数据。 3.3.3 使用GAP和GATT栈API 这部分指导开发者如何直接调用GAP和GATT的API，实现设备的连接、数据传输和服务发现等功能。 3.3.4 GATT服务器应用程序API 详细阐述了创建和管理GATT服务器的方法，包括服务和特性的定义和交互。 3.3.5 库文件介绍了支持这些功能的库文件，以及如何在项目中集成和使用它们。 3.4 配置文件 3.4.1 GAP外围角色配置描述了设备作为GAP外围设备的角色，如传感器或可穿戴设备。 3.4.2 GAP外围/广播者多角色配置解释了设备如何同时扮演外围设备和广播者的角色，提供更灵活的连接模式。 3.4.3 GAP中心角色配置说明了设备作为GAP中心设备（例如，智能手机或PC）的功能，用于连接和管理其他BLE设备。这份Texas Instruments CC2540/41蓝牙低能量软件开发者指南提供了全面的开发信息，涵盖了从协议栈基础到具体应用开发的各个层面，是开发基于TI CC2540/41芯片的BLE产品的宝贵资源。

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271F Version 1.3.1

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 SWRU271F Version 1.3.1

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

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271F Version 1.3.1

3.3 BLE Protocol Stack

The entire BLE protocol stack is provided as object code in a single library file (Texas Instruments

does not provide the protocol stack source code as a matter of policy). The functionality of the

GAP and GATT layers should be understood as they interact directly with the application and

profiles.

3.3.1 Generic Access Profile (GAP)

The GAP layer of the BLE Protocol Stack is responsible for handling the device’s access modes

and procedures, including device discovery, link establishment, link termination, initiation of

security features, and device configuration.

The GAP layer is always operating in one of four roles:

 Broadcaster – an advertiser that is non-connectable

 Observer – scans for advertisements, but cannot initiate connections

 Peripheral – an advertiser that is connectable, and operates as a slave in a single link-layer

connection.

 Central – scans for advertisements and initiates connections; operates as a master in a

single or multiple link-layer connections. Currently, the BLE central stack supports up to three

simultaneous connections.

The BLE specification allows for certain combinations of multiple-roles. The default setup of the

sample application is to only support the peripheral role, though source code is provided to run a

combination peripheral and broadcaster role.

In a typical Bluetooth Low Energy system, the peripheral device advertises with specific data

letting any central device know that it is a connectable device. This advertisement contains the

device address, and can contain some additional data as well, such as the device name. The

central device, upon receiving the advertisement, sends a “scan request” to the peripheral. The

peripheral responds with a “scan response”. This is the process of device discovery, in that the

central device is now aware of the peripheral device, and knows that it can form a connection with

it. The central device can then send out a request to establish a link with the peripheral device. A

connection request contains a few connection parameters:

 Connection Interval – In a BLE connection between two devices, a frequency-hopping

scheme is used, in that the two devices each send and receive data from one another on a

specific channel, then “meet” at a new channel (the link layer of the BLE stack handles the

channel switching) at a specific amount of time later. This “meeting” where the two devices

send and receive data is known as a “connection event”. Even if there is no application data

to be sent or received, the two devices will still exchange link layer data to maintain the

connection. The connection interval is the amount of time between two connection events, in

units of 1.25ms. The connection interval can range from a minimum value of 6 (7.5ms) to a

maximum of 3200 (4.0s).

Different applications may require different connection intervals. The advantage of having a

very long connection interval is that significant power is saved, since the device can sleep

most of the time between connection events. The disadvantage is that if a device has data

that it needs to send, it must wait until the next connection event.

The advantage of having a very short connection interval is that there is more opportunity for

data to be sent or received, as the two devices will connect more frequently. The

disadvantage is that more power will be consumed, since the device is frequently waking up

for connection events.

 Slave Latency – This parameter gives the slave (peripheral) device the option of skipping a

number of connection events. This gives the peripheral device some flexibility, in that if it does

not have any data to send it can choose to skip connection events and stay asleep, thus

providing some power savings. The decision is up to the peripheral device.

剩余55页未读，继续阅读

7kaifakaifa

粉丝: 0
资源: 1

Texas Instruments CC2540/41 Bluetooth Low Energy (BLE) Software ...

最新资源

Texas Instruments CC2540/41 Bluetooth Low Energy (BLE) Software ...

Texas Instruments CC2540/41 BLE Software Developer’s Guide v1.3.2

CC2540/2541开发指南

CC2540/CC2541主从一体化透传源码 V1.4

Texas Instruments CC2540/41 Bluetooth低能软件开发指南

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

CC2540/41蓝牙4.0开发指南：从入门到应用

CC2540/41蓝牙低功耗开发指南：软件与平台详解

TI CC2540/41蓝牙低功耗开发指南：构建与应用详解

TI CC2540/2541开发说明

CC2540/CC2541主从一体化透传源码（支持串口和APP,带AT命令）

最新资源