TI CC2650 LaunchPad开发板开箱与低功耗物联网开发实战

1. 从开箱到上电：CC2650 LaunchPad初印象

刚拿到TI的CC2650 LaunchPad开发板时，第一感觉是它比想象中要“精致”不少。这块板子属于TI LaunchPad家族，主打的就是一个“开箱即用”，目标很明确：让你能以最低的学习成本，快速上手这颗功能强大的CC2650无线MCU。板子整体布局紧凑，红黑配色加上醒目的TI logo，典型的工程师风格。随板附赠的是一根标准的Micro-USB线，插上电脑就能供电兼调试，省去了额外找电源的麻烦，对于我这种喜欢桌面整洁、讨厌线缆缠绕的人来说，这个设计非常友好。

板子的核心，自然是那颗CC2650芯片。它可不是普通的单片机，而是一颗集成了ARM Cortex-M3应用处理器、超低功耗传感器控制器和2.4GHz射频前端的“三合一”无线MCU。这意味着你在一块芯片上，就能同时处理应用程序、管理传感器数据、并运行蓝牙低功耗（BLE）或IEEE 802.15.4（如Zigbee、Thread）协议栈。这种高度集成对于物联网终端设备的设计至关重要，能显著减小PCB面积、降低整体BOM成本和功耗。板载的8Mbit串行闪存（标记为“Serial flash for data storage”）为存储用户程序、无线协议栈配置文件或传感器日志数据提供了充足的空间，不用再外挂Flash芯片，对快速原型开发非常有利。

板子正面最显眼的是那个40针的双排母座，也就是BoosterPack扩展接口。这是TI LaunchPad生态系统的精髓所在。它定义了一套物理和电气接口标准，意味着市面上有海量的、功能各异的BoosterPack插件模块（比如OLED屏幕、环境传感器、电机驱动等），只要符合这个标准，就能像拼乐高一样直接插在LaunchPad上使用，极大扩展了开发板的功能。两个用户按键（BTN-1和BTN-2）被特意设计在板子两侧，而不是集中在中间，这个细节很贴心。当你堆叠了BoosterPack之后，中间的按键很可能被挡住，而侧面的按键依然可以轻松按到，体现了设计时对实际使用场景的考量。红绿两颗LED是最基础的调试和状态指示工具。旁边有几个关键的跳线帽，比如连接LED的跳线，默认是短接的，如果你需要将这两个GPIO引脚用于其他功能（比如驱动外部设备），拔掉跳线帽就能将其与LED断开，非常灵活。

板子背面集成了XDS110调试器，这是TI自家的低成本调试探针。它通过USB与电脑通信，为板载的CC2650 MCU提供JTAG/SWD调试接口和UART串口通信（俗称“打印输出”）功能。也就是说，你不需要额外购买昂贵的JTAG调试器，一根USB线就解决了供电、程序下载、调试和串口通信所有问题，真正实现了“一站式”开发体验。板载天线区域设计也值得一说，它采用了一个倒F型（IFA）PCB天线，对于2.4GHz频段来说，这种天线在有限空间内能提供不错的性能。旁边还预留了一个天线连接器焊盘和一个匹配电阻的空位（“Solder one resistor here to use external antenna”），如果你对射频性能有更高要求，或者产品外壳对天线有屏蔽，可以很方便地通过焊接一个0欧姆电阻，切换到外接天线接口，连接增益更高的外部天线。

提示：首次使用前，建议先检查一下板子背面或丝印上是否有版本号（如Rev 1.1）。不同版本的LaunchPad在细节上可能有差异，比如早期版本可能需要先升级固件才能完美兼容手机App。最稳妥的方法是，无论什么版本，都先访问TI官方提供的入门链接（dev.ti.com/launchxl-cc2650）查看最新的入门指南。

2. 核心硬件深度解析：不只是引脚，更是系统设计思路

拿到开发板，不能只停留在“点亮LED”的层面。理解其硬件设计，尤其是资源分配和接口规划，对于后续开发复杂应用、排查硬件相关问题至关重要。CC2650 LaunchPad的硬件可以看作几个功能模块的有机组合：核心MCU最小系统、调试与编程接口、电源管理、射频前端以及扩展接口。

2.1 CC2650 MCU：一颗芯片，多重角色

CC2650的架构是它强大能力的基石。其核心是一个运行频率高达48MHz的ARM Cortex-M3内核，负责运行用户应用程序和主要的协议栈处理（如蓝牙协议栈中的GATT层、连接管理）。除此之外，它还有一个独立的、超低功耗的ARM Cortex-M0内核，专门用于管理射频收发器的底层操作（物理层、链路层），这种双核架构使得射频任务和应用任务可以相对独立，提高了系统响应效率和实时性。

最值得一提的是它的传感器控制器（Sensor Controller）。这是一个可编程的超低功耗协处理器，即使在主Cortex-M3内核和射频部分都处于深度睡眠状态时，它也能保持运行。传感器控制器可以独立地周期性地采样ADC、读取I2C/SPI传感器数据、处理简单的算法（如阈值比较），只有在满足特定条件（如数据超过阈值）时，才唤醒主处理器。这个特性对于依赖电池供电、需要长时间监测的物联网传感器节点来说是革命性的，可以轻松实现微安级甚至纳安级的平均功耗。

在射频方面，CC2650支持多协议并发。它内置的2.4GHz射频收发器符合蓝牙5.0低功耗（BLE）和IEEE 802.15.4（Zigbee 3.0， Thread， 6LoWPAN等）标准。实际上，通过TI的软件栈，你可以在同一芯片上动态切换或同时运行不同的协议（需要协议栈支持），这为构建多模网关或需要兼容不同生态系统的设备提供了硬件基础。射频输出功率可编程，最高可达+5dBm，接收灵敏度在BLE 1Mbps模式下可达-97dBm，提供了不错的链路预算和通信距离。

2.2 40针BoosterPack接口：生态扩展的桥梁

BoosterPack接口的40个引脚并非随意排列，而是遵循了TI定义的一套“标准”。这个标准规定了电源引脚（3.3V， 5V， GND）、常用通信总线（UART， I2C， SPI）和模拟输入引脚的位置。这样做的好处是，任何一个符合标准的BoosterPack，其电源、地线和主要数据线的物理位置都是固定的，保证了电气兼容性和插接的便利性。

然而，正如资料中提到的“NOTE: Some LaunchPads & BoosterPacks do not comply 100% with the standard”，这个标准并非百分百强制，不同型号的LaunchPad和BoosterPack可能会有细微调整。因此，在实际堆叠模块前，一定要用TI提供的在线兼容性检查工具（dev.ti.com/bpchecker）进行核对，或者仔细对比双方的数据手册引脚定义表，避免因引脚功能冲突导致模块损坏或功能异常。

我们详细看一下这个引脚图（Pin map）透露的信息。引脚被分为J1， J2， J3， J4四个区域。以J1和J2（通常位于板子一侧）为例，这里集中了主要的数字IO、模拟输入和通信接口。例如，DIO_23， DIO_22等是通用的GPIO，旁边标注了“GPIO”和“(!)”，这个叹号表示该引脚具备中断能力，这对于需要快速响应外部事件（如按键、传感器触发）的应用非常重要。A0到A7是模拟输入通道，连接到了CC2650内部的12位ADC，可以用于读取电位器、光敏电阻等模拟传感器的值。

通信接口方面，UART的TXD和RXD引脚被引出，方便连接GPS、蓝牙串口模块等设备。I2C总线的SCL和SDA引脚也明确标出，I2C是连接各类传感器（温湿度、气压、加速度计）最常用的总线之一。SPI总线的四个信号（CLK， MOSI， MISO， CS）也被预留，用于驱动显示屏、无线模块或高速AD/DA转换器。特别需要注意的是，引脚图上还标注了“SPI CS Wireless”和“SPI CS Display”，这暗示了在TI的软件框架或示例中，可能��经为无线芯片和显示模块预定义了片选引脚，在编程时可以优先使用这些建议的引脚，以保持与示例代码和驱动库的一致性。

2.3 电源与调试子系统：稳定运行的保障

LaunchPad的电源设计考虑了多种场景。默认情况下，通过Micro-USB接口供电，电压为5V。板载的XDS110调试器部分和CC2650目标MCU部分通过跳线帽隔离。XDS110内部包含一个LDO，将5V转换为3.3V供给CC2650。板子上有两个关键的电源跳线：“Jumper for Internal(USB) Power”和“Jumper for External Power”。如果你想使用外部的3.3V或5V电源（比如电池）为CC2650供电，就需要断开USB电源跳线，连接外部电源跳线，并将外部电源连接到对应的“Connector for external 3V/5V power”端子。这种设计让你可以轻松测试设备在电池供电下的实际功耗和运行情况。

XDS110调试器是开发体验流畅的关键。它不仅仅是一个JTAG调试器，还集成了USB转串口（UART）的功能。在电脑上，你会看到两个虚拟COM端口：一个用于调试器的固件升级和管理（通常很少用到），另一个就是连接CC2650 UART0的串口，用于打印程序日志、进行命令行交互。在Code Composer Studio（CCS）或IAR等IDE中，选择XDS110作为调试器，就可以实现单步调试、断点、查看变量、寄存器等高级调试功能，这对于排查复杂的程序逻辑问题不可或缺。

注意：在进行功耗测量时，务必小心。如果你想精确测量CC2650核心的电流消耗，需要断开为CC2650供电的跳线，将电流表串联进供电回路。同时，要意识到XDS110调试器本身也会消耗一定的电流（通常几个mA）。对于追求极致低功耗的应用，在最终产品设计中，需要移除调试器部分，仅使用CC2650的最小系统，并通过优化的软件策略（如充分利用传感器控制器、合理的睡眠模式）来降低功耗。

3. 软件开发环境搭建与第一个项目

硬件熟悉之后，下一步就是让芯片“动”起来。TI为CC2650提供了非常丰富的软件支持，从专业的集成开发环境（IDE）到开源的命令行工具链，再到海量的示例代码和文档。

3.1 工具链选型：CCS vs IAR vs GNU

对于初学者和大多数开发者，我首推TI自家的Code Composer Studio (CCS)。它是一个基于Eclipse的IDE，对TI的MCU产品线支持最为原生和完整。其优点在于与TI软件生态无缝集成：TI Resource Explorer（一个内置的示例代码浏览器和下载器）、TI RTOS（实时操作系统）配置工具、功耗估算工具等都直接集成在CCS中。安装CCS时，记得选择安装“SimpleLink CC13x0/CC26x0 SDK”，这个SDK包含了所有必要的驱动程序、协议栈（BLE， Zigbee等）、RTOS内核以及大量的示例项目，是开发的基础。CCS的社区版（免费）有16KB的代码大小限制，但对于CC2650的多数学习和原型开发来说，完全够用。

IAR Embedded Workbench是另一个业界知名的专业IDE，以其优秀的代码优化能力著称，生成的代码体积小、效率高，在商业产品开发中应用广泛。但它是商业软件，需要付费授权。对于学生或预算有限的个人开发者，CCS是更实惠的选择。

对于喜欢开源和命令行控制的硬核开发者，可以选择GNU工具链（arm-none-eabi-gcc）配合Makefile或CMake进行构建，并使用OpenOCD或pyOCD通过XDS110进行调试和烧录。这种方式灵活性最高，但对开发者的工具链配置和调试技能要求也更高。TI官方也提供了基于GCC的示例和部分支持。

我的建议是，先从CCS开始。它的图形化界面、集成的资源管理器和一键导入示例项目的功能，能让你快速建立感性认识，把精力集中在应用逻辑本身，而不是环境配置上。

3.2 获取并导入第一个示例工程

安装好CCS和SimpleLink SDK后，最快上手的办法就是运行一个示例程序。打开CCS，选择“View” -> “TI Resource Explorer”。在Resource Explorer中，你可以像浏览网页一样，导航到你的SDK版本（例如 SimpleLink CC13x0 CC26x0 SDK），然后找到“Examples” -> “Development Tools” -> “LAUNCHXL-CC2650”。这里你会看到一堆示例，从最简单的“blinky”（闪烁LED）到复杂的“simple_peripheral”（蓝牙外设示例）。

我们以“blinky”为例。找到它，点击旁边的“Import”按钮，CCS会自动为你创建一个包含所有源文件、配置文件和编译设置的新工程。导入后，在项目浏览器中右键点击工程名，选择“Build Project”进行编译。如果一切顺利，控制台会显示编译成功的信息。

接下来是下载和调试。用USB线连接LaunchPad和电脑。确保板子上给CC2650供电的跳线是连接状态。在CCS中，点击工具栏上的“Debug”按钮（那个小虫子图标）。CCS会自动编译（如果代码有改动）、连接XDS110调试器、将程序下载到CC2650的Flash中，并跳转到调试界面。在调试界面，你可以点击“Resume”（F8）让程序全速运行。这时，你应该能看到LaunchPad上的红色或绿色LED开始有规律地闪烁。恭喜，你的第一个程序跑起来了！

让我们简单看一下“blinky”的核心代码（通常位于main.c或*.c文件中）。它一般会包含以下步骤：

1. 初始化板级支持包（BSP）：调用Board_init()函数，这个函数会根据你选择的开发板型号（LAUNCHXL-CC2650），初始化板上定义的LED、按键等外设的GPIO配置。
2. 配置GPIO引脚：虽然BSP初始化了，但示例中通常会再次明确地将LED对应的引脚设置为输出模式。
3. 进入主循环：在一个while(1)死循环中，先设置LED引脚为高电平（点亮），调用Task_sleep()或Clock_delay()函数延时一段时间，然后设置引脚为低电平（熄灭），再延时，如此循环。

通过这个简单的过程，你实际上已经接触了CCS工程的基本结构、编译下载流程和最基本的GPIO操作。这是所有嵌入式开发的第一步。

3.3 使用手机App快速体验无线功能

TI提供了一个非常酷的“捷径”，让你不写一行代码就能体验CC2650的蓝牙功能，那就是SimpleLink Starter手机App（资料中提到的LaunchPad App）。这个App适用于iOS和Android。

操作步骤如下：

1. 确保你的LaunchPad是Rev 1.2或更高版本，或者如果是Rev 1.1，按照提示先去TI官网通过USB升级固件。
2. 用USB线给LaunchPad供电（连接电脑或充电宝都可以）。
3. 在手机上安装并打开SimpleLink Starter App。
4. 按下LaunchPad上右侧的BTN-2按钮。此时，板载的绿色LED会开始闪烁，这表明CC2650正在以蓝牙低功耗外设模式广播。
5. 在手机的App设备列表中，你应该能看到一个名为“CC2650 LaunchPad”或类似的设备，点击连接。
6. 连接成功后，App界面会变成“LaunchPad任务控制中心”。在这里，你可以实时看到两个按键（BTN-1， BTN-2）的按下状态，可以点击屏幕上的虚拟按钮来控制板载的红色和绿色LED的亮灭，甚至可以向LaunchPad的串口发送数据。

这个演示背后，是LaunchPad上已经预烧录了一个完整的蓝牙低功耗外设固件。它实现了标准的GATT服务，其中包含了LED控制、按键状态通知、串口数据传输等特征值（Characteristic）。手机App作为中心设备（Client），通过读写这些特征值来实现与LaunchPad的交互。这个过程让你直观地理解了BLE应用的基本模型：外设提供数据和服务，中心设备进行发现、连接和交互。

实操心得：这个手机App演示非常适合在项目初期向非技术人员（如产品经理、客户）展示创意原型。你可以在几分钟内搭建一个通过手机控制硬件或读取传感器数据的演示，极大地降低了沟通成本。同时，它也揭示了TI软件栈的强大之处——许多基础的协议栈和驱动功能已经封装好，开发者可以更专注于应用层逻辑。

4. 深入协议栈开发：构建一个自定义的BLE外设

玩转了手机App演示，下一步就是自己动手，从零开始构建一个具有自定义功能的蓝牙低功耗外设。我们将基于TI SimpleLink SDK中的simple_peripheral示例进行修改，创建一个能够通过手机读取板载温度传感器（CC2650内部有温度传感器）数据的外设。

4.1 理解BLE GATT数据模型

在动手编码前，必须理解BLE通信的核心——GATT（通用属性协议）。你可以把GATT理解为一个在蓝牙设备上运行的微型数据库。这个数据库由多个服务（Service）组成，每个服务代表一个独立的功能（比如电池服务、设备信息服务、自定义的温度读取服务）。每个服务下面包含一个或多个特征值（Characteristic），特征值是实际承载数据的基本单元。每个特征值包含一个数值（Value），以及一组属性（Properties）（如可读、可写、可通知）和描述符（Descriptor）（如客户端特征值配置描述符CCCD，用于启用/禁用通知）。

我们的目标就是创建一个自定义的“温度服务”，里面包含一个“温度读数特征值”。手机App可以读取（Read）这个特征值来获取当前温度，或者我们也可以让LaunchPad在温度变化时，自动向手机发送通知（Notify）。

4.2 修改simple_peripheral示例工程

在TI Resource Explorer中找到并导入simple_peripheral示例工程。这个工程已经实现了一个完整的外设框架，包括设备广播、连接管理、GAP（通用访问配置文件）和GATT事件处理。我们需要做的是在其中添加自定义的服务和特征。

首先，需要定义我们自定义服务的UUID。UUID是一个128位的唯一标识符。蓝牙技术联盟（SIG）定义了一些标准的16位或32位短UUID（如电池服务是0x180F）。对于自定义服务，我们必须使用128位的UUID，通常以0xFFE0，0xFFE1等作为基础，或者自己生成一个。

在SDK中，GATT相关的定义通常放在一个专门的头文件和应用层源文件中。我们以simple_peripheral工程为例，需要在相应的位置（比如simple_peripheral.c和simple_peripheral.h）添加代码。

步骤一：定义UUID和属性句柄在头文件中定义我们服务的UUID和特征值的UUID，以及用于存储特征值句柄的变量。

// 自定义温度服务UUID (128-bit, 可自定义，这里是一个示例) #define TEMP_SERV_UUID 0xFFE0 // 自定义温度读数特征值UUID #define TEMP_READ_CHAR_UUID 0xFFE1 // 用于存储特征值句柄的全局变量 static uint16_t tempReadCharHandle = 0;

步骤二：添加服务到GATT表GATT表是一个数组，定义了服务、特征值和描述符的结构。我们需要在现有的GATT表末尾添加我们的自定义服务。这通常在simple_peripheral.c中的一个名为*_attTable的数组中进行。添加的内容大致如下：

// 温度服务声明（主服务） PRIMARY_SERVICE_UUID128, {TEMP_SERV_UUID_BYTES}, // 128位UUID的字节数组形式 // 温度读数特征值声明 CHARACTER_UUID128, {TEMP_READ_CHAR_UUID_BYTES}, (GATT_PROP_READ | GATT_PROP_NOTIFY), // 属性：可读、可通知 0, // 权限（暂不设置） &tempReadCharHandle, // 句柄指针，系统会自动赋值 NULL, // 初始值设为NULL，动态更新 // 客户端特征值配置描述符（CCCD）声明，用于启用/禁用通知 DESCRIPTOR_UUID128, {GATT_CLIENT_CHAR_CFG_UUID_BYTES}, (GATT_PROP_READ | GATT_PROP_WRITE), 0, NULL, NULL

注意：这里的*_BYTES需要你将16进制的UUID转换为大端序的字节数组。例如，0xFFE0对应的128位完整UUID可能是0xFFE0xxxx-...，你需要按照TI的格式定义好。

步骤三：实现温度读取和更新逻辑

1. 初始化：在应用初始化函数中，启动CC2650内部的ADC，配置为读取温度传感器通道。TI的驱动库提供了ADCBuf或ADC模块的API，可以方便地完成配置。
2. 读取温度：编写一个函数，触发ADC单次转换，读取原始ADC值，然后根据芯片数据手册中的公式，将ADC值转换为摄氏温度。CC2650的内部温度传感器精度一般，适合监测芯片结温变化，不适合做高精度环境温度测量。
3. 更新特征值：当温度读取完成后，需要调用GATT层的API（如GATT_UpdateCharValue）来更新我们之前定义的tempReadCharHandle特征值。如果手机的CCCD已经设置了通知（Notify）使能，这个更新操作会自动触发一个通知（Notification）发送给手机。
4. 定时触发：为了模拟周期性上报，可以创建一个软件定时器（利用TI-RTOS的Clock模块或Timer模块），每隔几秒执行一次“读取温度->更新特征值”的操作。
5. 处理写CCCD请求：当手机App想要启用或禁用温度通知时，它会向CCCD描述符写入0x0001或0x0000。我们需要在GATT写事件回调函数中，捕获对这个CCCD的写操作，并记录通知状态，以便在温度更新时决定是否发送通知。

4.3 使用手机App进行测试

编译并下载修改后的程序到LaunchPad。打开手机上的BLE调试App（如TI的SimpleLink Starter，或者更通用的“nRF Connect”、“LightBlue”等）。扫描设备，找到你的LaunchPad并连接。在服务列表中，你应该能看到除了标准服务（如设备信息服务）外，还有一个以你自定义的UUID标识的服务。点开这个服务，能看到里面的温度读数特征值。

你可以尝试“读取”该特征值，手机App会发起一个读请求，LaunchPad会响应当前的温度值。你还可以尝试在特征值的CCCD上“启用通知”，然后观察手机App是否会定期收到LaunchPad发来的温度更新数据。

常见问题排查：

1. 手机扫描不到设备：检查程序是否成功运行（LED有无指示），确认广播参数（广播间隔、广播数据）设置正确。可以用手机上的通用BLE扫描工具先看看是否有任何广播设备。
2. 连接后找不到自定义服务：检查自定义服务的UUID是否正确添加到GATT表中，并且格式（字节序、长度）是否正确。确保GATT表没有超出芯片内存限制。
3. 读取特征值失败或返回错误数据：检查特征值的属性（Properties）是否包含了GATT_PROP_READ。在读取回调函数中，确保正确填充了要返回的数据和长度。
4. 通知无法正常工作：首先确认手机端是否成功写入了CCCD（启用通知）。在LaunchPad端，检查写CCCD的事件是否被正确处理，通知状态标志位是否被正确设置。在调用GATT_UpdateCharValue更新特征值时，确保传入的句柄connHandle是当前活跃连接的句柄。

通过这个实践，你不仅实现了一个具体的功能，更重要的是走通了BLE外设开发的完整流程：从GATT数据模型设计，到服务/特征值添加，再到数据更新和事件处理。这套模式可以扩展到任何其他传感器或执行器。

5. 低功耗设计与功耗优化实战

CC2650的核心优势之一就是低功耗。但对于新手来说，即使使用了低功耗芯片，写出来的程序功耗也可能居高不下。要让设备真正实现长达数年的电池续航���必须在软件和硬件层面进行精心设计。

5.1 CC2650的电源模式

CC2650支持多种电源模式，功耗从高到低依次为：

• 主动模式（Active）：所有模块全速运行，功耗最高（mA级）。
• 空闲模式（Idle）：CPU暂停，但外设和内存保持供电，可被中断唤醒。
• 待机模式（Standby）：仅保持部分内存（RAM）内容，CPU和大多数外设断电。唤醒时间较短（约100μs）。
• 关机模式（Shutdown）：仅实时时钟（RTC）和少量逻辑电路供电，功耗最低（nA级）。唤醒后程序从复位开始执行。

我们的目标就是让设备在大部分时间处于最深的睡眠模式（通常是待机模式），仅在需要处理任务（如采集传感器数据、进行无线通信）时短暂唤醒到主动模式，处理完毕后立即返回睡眠。

5.2 利用传感器控制器实现超低功耗采样

这是CC2650的“杀手锏”。传感器控制器可以独立于主CPU和射频系统运行。我们可以配置传感器控制器以极低的功耗（微安级）周期性地唤醒，采样ADC（读取温度、光照等），并进行简单的判断（例如，温度是否超过阈值？）。只有满足条件时，它才通过中断唤醒主CPU。

TI提供了Sensor Controller Studio（SCS）这个图形化工具来配置和编程传感器控制器。你不需要写复杂的汇编代码，而是通过拖拽功能块（ADC采样、比较器、定时器、I2C读写等）并设置参数来生成代码。SCS会生成一个头文件（.c和.h），你只需要将其添加到你的CCS工程中，并在主程序里调用初始化函数和启动函数即可。

一个典型场景：每10秒测量一次内部温度，仅当温度超过30°C时，唤醒主CPU，并通过BLE通知手机。

1. 在SCS中，创建一个任务（Task）。
2. 添加一个“定时器”块，设置为10秒间隔。
3. 添加一个“ADC采样”块，连接到内部温度传感器通道。
4. 添加一个“比较”块，判断ADC转换结果（或计算后的温度值）是否大于阈值。
5. 如果大于阈值，添加一个“唤醒主机”块，并可以设置一个输出事件标志。
6. 在CCS主程序中，初始化SCS生成的任务。在主循环或空闲任务中，检查传感器控制器设置的事件标志。一旦标志被置位，说明温度超限，主CPU被唤醒，此时可以读取传感器控制器准备好的数据，并通过BLE发送通知，然后再次进入睡眠。

通过这种方式，主CPU和射频系统99%的时间都在深度睡眠，平均功耗可以降低到10微安以下。

5.3 软件层面的功耗优化技巧

除了利用硬件特性，软件编写习惯也极大影响功耗：

• 外设管理：不使用的外设模块（如UART， SPI， I2C， ADC）一定要关闭其时钟和电源。在TI驱动库中，通常有对应的*_close()或*_deinit()函数。
• GPIO配置：未使用的GPIO引脚应配置为输出低电平或带上拉/下拉的输入模式，避免浮空引起漏电流。对于驱动LED的引脚，在LED熄灭时，最好将其设置为输入模式或输出低电平（如果LED是低电平点亮），而不是输出高阻态。
• 避免忙等待（Busy-wait）：绝对不要在循环中使用for(i=0; i<100000; i++)这样的空循环来延时。这会阻止CPU进入低功耗模式。必须使用TI-RTOS提供的睡眠函数（如Task_sleep()）或定时器中断。
• 合理规划任务：在TI-RTOS中，将不同实时性要求的任务分配到不同的优先级。对于周期性任务，使用Clock模块或定时器来触发，任务执行完毕后立即挂起或删除，让系统有机会进入空闲状态，从而触发低功耗模式。
• 降低射频活动：在满足应用需求的前提下，尽量增加广播间隔（Advertising Interval）或连接间隔（Connection Interval）。更长的间隔意味着射频收发器更频繁地睡眠。在通信间隙，确保协议栈也进入了相应的低功耗状态。

5.4 功耗测量实践

优化效果需要用数据说话。测量LaunchPad的整板功耗时，需要断开为CC2650供电的跳线（通常是标有“3V3”的跳线），将高精度数字万用表（电流档）串联到供电回路中。为了准确测量不同模式下的电流，万用表需要具备“峰值保持”或“数据记录”功能，或者使用更专业的功耗分析仪（如TI的EnergyTrace技术，在CCS中集成，但需要特定硬件支持）。

一个简单的测试方法是：

1. 编写一个最简单的程序：初始化后，立即调用进入深度睡眠的函数（如Power_shutdown()或让系统进入空闲状态）。
2. 测量此时的电流，这接近芯片的静态睡眠电流。
3. 然后编写一个周期性唤醒（比如每秒一次，唤醒后点灯10ms再睡）的程序，测量平均电流。
4. 最后，测试在BLE连接状态下，不同连接间隔下的平均电流。

通过对比这些数据，你可以量化你的优化措施带来的收益。例如，从忙等待延时切换到RTOS任务睡眠，平均电流可能会从几百微安下降到几十微安；启用传感器控制器进行周期性采样，相比主CPU周期性唤醒采样，功耗可能再降低一个数量级。

注意事项：功耗优化是一个系统工程，需要权衡性能、响应时间和功耗。没有“最优解”，只有针对特定应用场景的“最合适解”。在项目初期就建立功耗测量习惯，设定明确的功耗预算，并在开发过程中持续监控，是确保产品达到预期续航能力的关键。