基于TI CC2564x平台的蓝牙低功耗ANP应用开发实战指南

1. 项目概述与ANP核心价值

在物联网和可穿戴设备爆发的今天，设备间的无缝通信变得至关重要。想象一下，你的智能手表如何实时、低功耗地接收到手机上的新邮件、未接来电或短信提醒？这背后离不开一套标准化的“语言”协议。蓝牙低功耗技术正是这套语言的基础设施，而Alert Notification Profile则是其中专门用于“通知”场景的“方言”。它定义了一个服务器（通常是手机）如何向一个客户端（如智能手表、车载显示屏）高效、可靠地传递各种警报信息，并管理新警报和未读警报的计数。

ANP的价值在于其标准化和互操作性。它不是一个TI或某个厂商的私有协议，而是由蓝牙技术联盟定义的标准Profile。这意味着，一个遵循ANP标准开发的TI CC2564x设备，可以无缝地与另一家遵循同样标准的手机或平板电脑通信，无需为每一款手机做定制化开发。对于开发者而言，这极大地降低了开发门槛和后期维护成本。TI的BLE软件栈为ANP提供了完整的API支持，将复杂的协议交互封装成清晰的函数调用，让我们可以更专注于应用逻辑本身，而非底层的射频和数据包解析。

本次实战，我们将基于TI的CC2564x蓝牙芯片平台，手把手完成一个ANP应用的开发与调试全过程。你会看到如何将两块开发板分别配置为服务器和客户端，建立连接，并模拟手机向手表发送邮件、短信等各类警报。无论你是刚接触BLE的新手，还是希望深入了解特定Profile实现细节的工程师，这篇指南都将提供从理论到实操的完整路径。

2. ANP协议深度解析与TI实现架构

2.1 ANP服务与特征剖析

要玩转ANP，首先得理解它的数据结构。在BLE的GATT架构中，一切通信都围绕“服务”和“特征”展开。ANP定义了一个名为“Alert Notification Service”的服务，其UUID为0x1811。这个服务内部包含了多个特征，每个特征负责不同的功能。

最核心的几个特征包括：

• 支持的新警报类别：一个可读的特征，客户端可以查询服务器支持哪些类型的新警报（如邮件、短信、来电等）。这就像去餐厅先看菜单，了解有什么菜可选。
• 新警报：这是一个“通知”特征。服务器可以主动向已订阅该特征的客户端发送新警报。客户端需要先“订阅”它，才能接收通知。这是警报传递的主干道。
• 未读警报状态：类似于“新警报”，但专注于未读状态的变更通知。
• 警报通知控制点：一个“可写”特征。客户端通过向这个特征写入特定的命令，来控制服务器的行为，例如“启用新邮件警报通知”或“立即通知所有未读警报”。这是客户端主动发起控制的通道。

TI的软件栈已经将这些服务、特征及其关联的权限（读、写、通知）全部实现并封装好了。我们的任务不是去从头构建这些数据包，而是学习如何通过TI提供的API，正确地注册服务、发现服务、配置特征和收发数据。

2.2 TI BLE软件栈与API设计哲学

TI的BLE协议栈是一个位于主机控制器接口之上的完整软件层。它抽象了底层射频的复杂性，提供了面向应用的、清晰的API。对于ANP，TI提供了两套交互接口：

1. 服务器端API：以ANS_为前缀，例如ANS_Initialize_Service用于注册ANP服务，ANS_Set_Supported_Categories用于设置支持的警报类别。
2. 客户端API：主要通过GATT客户端通用发现服务模块和写入控制点命令来实现。在Demo中，TI封装了一系列控制台命令（如DiscoverANS,EnableNewAlertNotifications）来简化这些操作。

其设计核心是“事件回调”机制。当远程设备（客户端）连接、写入控制点、或需要发送通知时，协议栈会通过你注册的回调函数来通知你的应用程序。你的应用代码在回调函数里处理这些事件，并做出响应。这种异步非阻塞的设计，非常适合资源有限的嵌入式设备。

理解这个架构至关重要：我们的应用代码是“被驱动”的。我们初始化服务，然后等待事件发生，再根据事件类型执行相应操作。Demo中的命令行交互，本质上是在模拟这些事件触发和响应过程。

3. 开发环境搭建与Demo运行实操

3.1 硬件准备与软件安装

要复现这个Demo，你需要准备以下硬件：

• 两块支持TI BLE协议栈的开发板：如基于CC2564模块的LAUNCHXL-CC2564C评估板，或集成该模块的MSP432、Tiva C系列开发板。两块板子型号最好相同，以减少环境变量。
• 两台电脑或一台电脑的两个USB口：用于同时连接和调试两块开发板。
• USB数据线：用于供电和串口通信。
• 软件环境：
  • Code Composer Studio或IAR Embedded Workbench：用于编译和下载代码。
  • TI的BLE-Stack SDK：确保其中包含ANP的示例工程。
  • 串口终端软件：如PuTTY、Tera Term或SecureCRT。这是与开发板交互的“控制台”。

首先，在CCS或IAR中导入ANP示例工程。通常路径在SDK的\examples\rtos\或\projects\目录下。为两块开发板分别编译相同的工程代码。这里有一个关键点：虽然代码相同，但通过后续的串口命令，我们可以将其中一块板子配置为服务器，另一块配置为客户端。

3.2 固件烧录与串口连接

将编译生成的.out或.hex文件分别烧录到两块开发板中。烧录完成后，不要急于按复位键。先用USB线将开发板连接到电脑。

打开设备管理器，找到“端口”部分。你会看到新出现的串行端口，名称可能是“XDS110 Class Application/User UART (COMx)”或“Tiva Virtual COM Port (COMx)”。记下两块板子对应的COM口号。

打开两个串口终端软件实例（例如两个PuTTY窗口），分别连接到这两个COM口。串口参数统一设置为：波特率115200（注意：对于较老的MSP430平台，可能是9600）、8位数据位、无奇偶校验、1位停止位、无流控制。

连接成功后，按下开发板上的复位按钮（通常是标有RESET或S3的按键）。此时，在终端窗口里，你应该能看到一堆初始化日志，最后出现一个命令提示符（比如CMD>）以及一个帮助菜单，列出了所有可用的命令。这表明TI的BLE协议栈和示例应用已经成功启动并运行。

至此，你的两个“空白”设备已经就绪。接下来，我们将把它们塑造成具有特定角色的通信实体。

4. 从零构建ANP通信：服务器与客户端配置

4.1 设备1：配置为ANP服务器

我们将第一个设备作为警报通知的服务器，它模拟手机的角色，是警报的发送方。

1. 注册ANS服务：在服务器设备的终端中，输入命令RegisterANS并回车。这条命令底层调用了ANS_Initialize_Service()API，告诉协议栈：“我准备提供一个警报通知服务”。成功后，会返回Successfully registered ANP service。这是所有后续操作的基础，没有注册服务，广告和连接都失去了意义。

2. 开始广播：输入命令AdvertiseLE 1并回车。参数“1”表示进行通用可连接广播。此时，开发板上的BLE指示灯应该开始闪烁，表明它正在对外广播自己的存在，宣告“我这里有ANP服务，谁要来连接？”。广播数据包中会包含ANP服务的UUID，以便客户端过滤发现。

注意：广播间隔和功率可以在工程配置中调整，但Demo通常使用默认值。在实际产品中，需要��衡广播频率（影响被发现速度和功耗）与电池续航。

现在，服务器已经准备就绪，在静静地等待客户端的连接。我们切换到第二个设备。

4.2 设备2：配置为ANP客户端

客户端设备模拟智能手表，需要主动去寻找并连接服务器。

1. 扫描设备：在客户端终端输入StartScanning。设备会开始扫描周围的BLE广播者。几秒钟后，你应该能在终端输出中看到扫描到的设备列表，其中包含服务器设备的蓝牙地址（一个类似00:1A:7D:DA:71:13的48位地址）和设备名。记下服务器设备的地址。

2. 停止扫描：找到目标后，输入StopScanning停止扫描，以节省功耗。

3. 发起连接：使用ConnectLE <蓝牙地址>命令发起连接。将<蓝牙地址>替换为你刚才记下的服务器地址。例如：ConnectLE 00:1A:7D:DA:71:13。连接成功后，终端会显示连接已建立，并且两块开发板上的连接指示灯（如果有的话）可能会常亮。

连接建立后，BLE链路层的工作就完成了。接下来，需要在应用层进行GATT服务发现，这是客户端了解服务器能力的关键一步。

5. 服务发现、配置与警报通知全流程

5.1 服务发现与能力查询

连接成功后，客户端并不知道服务器具体提供了哪些服务。因此，需要执行服务发现流程。

在客户端终端输入DiscoverANS命令。这个命令会触发GATT服务发现过程，客户端向服务器查询其提供的所有服务，并筛选出我们关心的ANP服务。发现完成后，终端会打印出“ANS Service Discovery Summary”，并列出服务器支持的警报类别特征，例如：

Supported New Alert Categories: Simple, Email, SMS Supported Unread Alert Categories: Email, Missed Call

这个列表至关重要，它告诉客户端，服务器能够处理哪些类型的警报。客户端后续的订阅和操作，都必须基于这个支持列表来进行。

5.2 客户端警报通知配置

在获知服务器能力后，客户端需要告诉服务器：“我对哪些警报感兴趣，请在有这些警报时通知我。” 这通过配置“客户端特征配置描述符”来实现。

1. 配置远程ANS：输入命令ConfigureRemoteANS 1 1。这里的两个参数分别代表“启用新警报通知”和“启用未读警报状态通知”。1表示启用，0表示禁用。这条命令为后续的订阅操作做好了准备。

2. 启用新警报通知：输入EnableNewAlertNotifications。命令执行后，通常会有一个交互式菜单，让你选择要启用的警报类别。类别用数字表示，例如：

   0 = Simple Alert 1 = E-Mail 2 = News ... 10 = All Categories

   为了测试，我们可以选择启用所有类别，输入10。这条命令会向服务器的“警报通知控制点”特征写入一个“启用新警报通知”的指令。

3. 启用未读警报通知：类似地，输入EnableUnreadAlertNotifications，同样选择10启用所有类别的未读状态通知。

至此，客户端已经完成了所有订阅设置。服务器端现在知道，这个客户端希望接收所有类型的新警报和未读状态变更通知。

5.3 模拟警报发送与接收

现在，让我们模拟手机收到新邮件的场景。

1. 服务器发送新警报：切换到服务器的终端窗口。输入命令NotifyNewAlerts 2。这里的参数2是一个位掩码。在ANP中，1代表简单警报，2代表邮件。所以NotifyNewAlerts 2表示“发送一个新邮件警报”。命令执行后，服务器会显示Sending New Alert Notification for 'category'... Success。

2. 客户端接收警报：立即查看客户端的终端。你会看到类似这样的输出：

   New Alert Status Received. Category: Email Number of New Alerts: 1

   这完美模拟了智能手表震动并显示“您有一封新邮件”的过程。这里的“警报数量”可以由服务器在发送时指定，Demo中通常默认为1。

3. 发送未读警报状态：再模拟一个场景，比如有一封未读邮件。在服务器端输入NotifyUnreadAlerts 2。客户端会收到：

   Unread Alert Status Received. Category: Email Number of Unread Alerts: 1

   这对于需要在设备上显示未读计数（如邮箱图标上的红点数字）的应用非常有用。

5.4 高级操作与状态管理

除了基本的通知，ANP还支持更精细的控制和状态查询。

• 立即通知：客户端可以命令服务器立即发送当前状态，而不用等待新事件。命令是NotifyImmediatelyNewAlerts和NotifyImmediatelyUnreadAlerts。这在客户端刚连接、需要同步最新状态时非常有用。
• 获取与设置警报状态：服务器可以主动查询或设置特定类别的警报计数。例如，GetNewAlertStatus 1可以查询当前新邮件的数量。SetNewAlertStatus 1 5 “Hello”可以将新邮件计数设置为5，并附带一个文本信息“Hello”。这允许服务器应用同步其内部状态。
• 动态修改支持类别：在设备运行中，可以通过SetSupportedNewAlertCategories命令动态改变服务器对外宣称的支持的警报类别。这增加了应用的灵活性。

6. 关键API与命令深度解读

Demo中的每个控制台命令，都对应着底层一个或多个API调用。理解这些API，是进行二次开发的基础。下面我们剖析几个最核心的：

6.1ANS_Initialize_Service- 服务的基石

这是服务器端最重要的函数。其原型为：

int ANS_Initialize_Service(unsigned int BluetoothStackID, ANS_Event_Callback_t EventCallback, unsigned long CallbackParameter, unsigned int *ServiceID);

• BluetoothStackID： 蓝牙协议栈实例ID，通常由初始化函数返回。
• EventCallback：事件回调函数指针。所有ANP相关的事件（如客户端写入控制点、读取特征请求）都会通过这个函数通知应用层。这是应用逻辑的入口。
• CallbackParameter： 传递给回调函数的用户自定义参数，可用于区分不同实例或传递上下文。
• ServiceID： 输出参数，返回注册成功的服务ID。这个ID在后续操作（如清理服务）中需要用到。

实操心得：务必妥善保存返回的ServiceID。在复杂应用中可能注册多个服务，清理时需要凭ID操作。回调函数的设计要高效，避免执行耗时操作，以免阻塞协议栈。

6.2ConfigureRemoteANS与 CCCD配置

这个Demo命令封装了GATT客户端配置“客户端特征配置描述符”的过程。CCCD是一个特殊的描述符，用于启用或禁用对某个特征的通知或指示。当客户端执行EnableNewAlertNotifications时，底层API会向服务器端“新警报”特征的CCCD写入0x0001（启用通知）。服务器端协议栈会监测到这个写入操作，并通过ANS_Event_Callback回调函数上报一个ANS_CLIENT_CONFIGURATION_EVENT类型的事件，应用层可以在此事件中得知客户端已订阅。

6.3 位掩码参数的设计

在NotifyNewAlerts和SetSupportedNewAlertCategories等命令中，参数使用的是位掩码而非简单枚举。例如，NotifyNewAlerts 3。

• 1(二进制001) 代表简单���报。
• 2(二进制010) 代表邮件警报。
• 3(二进制011) 则代表同时发送简单警报和邮件警报。

这种设计非常高效，一个16位的整数（Word_t）最多可以表示16种不同的警报类别，并且可以一次性通知多种类别的警报组合。在代码中，通常使用预定义的宏来进行位操作，例如：

#define ANS_CATEGORY_SIMPLE_ALERT (0x0001) #define ANS_CATEGORY_EMAIL (0x0002) #define ANS_CATEGORY_NEWS (0x0004) // ... if (bitmask & ANS_CATEGORY_EMAIL) { // 处理邮件警报 }

7. 实战调试技巧与常见问题排查

在实际开发中，你几乎一定会遇到各种问题。以下是我在多年开发中总结的排查清单和技巧。

7.1 连接建立失败

• 现象：ConnectLE命令执行后超时或返回错误。
• 排查步骤：
  1. 确认广播：确保服务器确实在执行AdvertiseLE 1，且LED指示灯在闪烁。
  2. 确认地址：使用StartScanning仔细核对客户端扫描到的服务器蓝牙地址，确保连接命令中的地址完全一致（包括冒号和大小写，TI命令通常不区分大小写，但最好一致）。
  3. 距离与干扰：确保两设备距离在几米内，避开大型金属物体或强烈的2.4GHz WiFi信号源。
  4. 复位与重启：有时协议栈状态异常，尝试分别复位两块开发板，从头开始流程。

7.2 服务发现失败

• 现象：DiscoverANS命令后无响应或返回错误，看不到支持的特性列表。
• 排查步骤：
  1. 确认连接：首先确认ConnectLE已成功，连接已建立。
  2. 确认服务注册：务必在服务器端先执行RegisterANS。没有注册的服务，客户端自然发现不了。
  3. 查看协议栈日志：TI的协议栈通常有更详细的内部日志输出选项（可能需要修改工程编译选项，如定义DEBUG宏）。开启日志，查看GATT发现过程中的数据包交换。

7.3 客户端收不到通知

• 现象：服务器显示发送成功，但客户端无反应。
• 排查步骤（这是最常见的问题之一）：
  1. 检查订阅：这是最关键的步骤。必须确保客户端执行了EnableNewAlertNotifications或EnableUnreadAlertNotifications并成功。可以在服务器端回调函数中打印日志，检查是否收到了客户端写入CCCD的事件。
  2. 检查类别匹配：确保服务器发送的警报类别（如NotifyNewAlerts 2是邮件），在客户端启用通知时选择了该类别（或所有类别）。如果客户端只订阅了“短信”，那么“邮件”通知是不会送达的。
  3. 连接是否中断：检查连接是否在发送前意外断开。

7.4 内存与资源管理

• 问题：长时间运行或多次连接/断开后，设备出现不稳定或死机。
• 建议：
  • 配对使用：对于每个ANS_Initialize_Service，在应用结束或需要卸载服务时，必须调用对应的ANS_Cleanup_Service，并传入正确的ServiceID。
  • 连接管理：Demo示例可能简化了连接管理。在实际产品中，需要妥善处理连接断开事件，及时释放相关资源，并可能重新进入广播状态。
  • 堆栈大小：如果是在RTOS上运行，确保分配给BLE协议栈任务和ANP应用任务的堆栈大小足够。溢出会导致各种难以预测的崩溃。

7.5 性能优化考量

• 通知频率：频繁发送通知会消耗功耗和带宽。在实际应用中，可以考虑“去抖动”或聚合策略，例如将短时间内多个同一类别的警报合并为一个，并更新计数。
• 连接参数协商：BLE连接间隔、从机延迟等参数直接影响功耗和实时性。客户端可以在连接后发起连接参数更新请求，以优化特定场景下的性能。TI协议栈提供了相应的API。
• 数据长度扩展：如果警报附带的信息较长（如长文本），确保启用BLE 4.2/5.0的“数据长度扩展”功能，以减少分包传输次数，提高效率。

通过以上步骤，你应该能够顺利完成TI BLE平台上ANP应用的搭建、运行和调试。从理解协议框架，到动手配置设备，再到深入API和排查问题，这是一个完整的嵌入式BLE应用开发缩影。掌握了ANP，你就能为智能手表、智能家居通知器、工业设备状态指示屏等产品，注入实时、低功耗的通知能力。