TI CC2540BLE协议栈开发指南

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

"TI CC2540BLE软件开发帮助，适用于CC254x系列，包含协议栈介绍和相关解释的英文版开发指南，版本1.3.1，由Texas Instruments发布。" TI的CC2540蓝牙低能量（Bluetooth Low Energy, BLE）软件开发者指南是一个详细的参考资料，旨在帮助开发者在TI的CC254x系列芯片上进行BLE应用的软件开发。此指南覆盖了协议栈的基础知识、开发平台、软件架构以及各种组件和接口的详细说明。 1. **概述** - **简介**：提供了一个对BLE技术以及TI提供的开发工具的基本介绍。 - **BLE协议栈基础**：解释了BLE协议栈的基本结构和功能，是理解BLE通信核心的关键。 2. **德州仪器BLE软件开发平台** - **配置**：涵盖了开发环境的设置和配置选项，以适应不同项目的需求。 - **项目**：详细介绍了如何创建和管理项目，以便在开发过程中有效地组织代码和资源。 3. **软件概述** - **操作系统抽象层（OSAL）**：提供了一种跨平台的抽象层，使得开发者可以专注于应用逻辑而不是底层操作系统细节。OSAL包括任务初始化、事件处理、堆管理以及消息系统。 - **硬件抽象层（HAL）**：隐藏了硬件的具体实现，为开发者提供了统一的API来与CC254x芯片进行交互。 - **BLE协议栈**：深入解析了BLE协议栈，包括： - **Generic Access Profile (GAP)**：定义了设备发现、连接和断开的流程。 - **Generic Attribute Profile (GATT)**：负责数据传输和服务发现，是BLE应用的核心部分。 - **使用GAP和GATT栈API**：解释了如何通过API来控制和操作GAP和GATT栈。 - **GATT服务器应用API**：介绍了创建和管理GATT服务器的方法。 - **库文件**：列出了相关库文件的作用和用法。 4. **配置文件** - **配置文件**：讨论了配置文件的结构和用途，它们用于定制BLE设备的行为。 5. **配置文件** - **配置文件**：讨论了配置文件的结构和用途，它们用于定制BLE设备的行为。 - **GAP外围角色配置文件**：详述了GAP作为外围设备的角色，如广告和连接模式。 - **GAP外围/广播者多角色配置文件**：支持设备同时作为外围设备和广播者。 - **GAP中心角色配置文件**：解释了GAP作为中心设备（连接其他外围设备）的功能。该指南对于开发者来说是一个宝贵的资源，它不仅涵盖了CC254x系列芯片的基本使用，还提供了关于BLE协议栈和应用开发的深入理解，有助于开发者快速构建高效的BLE应用。

TI CC254x Bluetooth Low Energy Software Developer’s Guide SWRU271D 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 SWRU271D 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].

剩余54页未读，继续阅读

VVaass

粉丝: 0
资源: 2

TI CC2540BLE协议栈开发指南

TI CC2540 BLE4.0低功耗蓝牙射频数据手册翻译概览

TI CC254x BLE软件开发全面解析

TI CC254x BLE软件开发详解

CC2540 BLE stack 1.3.1

cc2540BLE入门教程

TI CC2540/2541开发说明

TI BLE 软件开发必读

CC2540 BLE 蓝牙4.0开发板学习资料

TICC2541或者CC2540工程BLE-CC254x-1.4.0.rar

TI_BLE_Sample_Applications_Guide_cc2541_Cc2540_ble_DEMO_

最新资源