简介CC2540流水灯是基于德州仪器CC2540蓝牙微控制器的经典嵌入式入门示例面向物联网开发者和单片机初学者用于理解GPIO输出控制、定时器中断以及BLE芯片的基础开发流程。资源共13个文件压缩包仅20KB包含IAR工程文件、C语言源码、hex固件及编译调试辅助文件已有407人学习。包内除可直接构建的main.c外还带有d51、r51等编译中间产物和调试配置文件可在IAR for 8051环境中快速打开、编译并下载到开发板。通过此工程既可熟悉8051内核的寄存器操作也能学习如何利用定时器中断精确控制LED亮灭节奏最终实现多个LED依次点亮的流动效果。对于初次接触CC2540或低功耗蓝牙应用的读者是一份轻量而完整的起步模板有助于后续扩展到传感器采集、蓝牙通信等更复杂的物联网项目。1. CC2540流水灯一块蓝牙芯片背后的裸机控制逻辑远不止“让灯轮流亮”拿到一份CC2540流水灯的资料包很多人以为就是简单跑个GPIO翻转实际上这颗芯片内部是8051内核外设配置和STC、51单片机差异非常大。CC2540集成了BLE 4.0协议栈真正的难点不在“灯亮”而在“寄存器配置”和“中断事件处理”之间的衔接。这份资源我能用起来核心在于它把最小系统、时钟配置、GPIO方向选择、延时机制都串了起来适合正在入门蓝牙嵌入式开发、想从按键控制过渡到无线控制的开发者。如果你只盯着“流水灯”三个字会漏掉整包资源里最有价值的协议栈联动部分。2. GPIO与外设复用先搞清P0/P1口的寄存器再谈灯会不会亮2.1 最小系统上电后的第一件事确认时钟与复位状态拿到CC2540开发板别急着写流水灯代码。这颗芯片上电默认跑内部16MHz RC振荡器但如果你画的板子外部接了32MHz晶振代码里没做时钟切换外设频率会有偏差。虽然GPIO翻转这事儿对时钟不敏感可一旦你后面要加定时器做精准延时时钟源没切对延时时间差得离谱。我一般会先读CLKCONCMD和CLKCONSTA两个寄存器确认当前时钟源。CLKCONCMD.OSC位决定了主时钟源选择置1用32MHz外部晶振置0用16MHz内部RC。默认值是0也就是跑内部振荡器。如果你在板上放了32MHz晶振希望走外部时钟需要按顺序操作CLKCONCMD ~0x40; /* 选择32MHz外部晶振 */ while (CLKCONSTA 0x40); /* 等待切换完成 */ CLKCONCMD ~0x38; /* 将系统主时钟切换到32MHz */这段代码第一行只是“请求”切换并不是立刻生效。第二行的while是在等状态寄存器CLKCONSTA确认切换成功。第三行才把CPU主时钟、外设时钟全部指到32MHz通道上。如果不做这个等待直接操作外设时钟分频倒也不会让灯不亮但定时器的 tick 数值全都会偏掉。踩过一次这个坑之后我每份代码开头都会先打印CLKCONSTA的值确认处于稳定状态再往下走。还有个容易被人忽略的点CC2540的复位源包括上电复位、外部引脚复位、看门狗复位和时钟丢失复位。拿到的板子如果焊了复位按钮引脚低电平有效上电瞬间RC延时电路没配好会导致芯片反复复位。最常见的现象是灯闪一下又灭但代码逻辑没问题。建议直接看RESETF寄存器它会在复位后记录复位原因0x00是上电复位0x02是看门狗复位。如果读到0x02就得去查喂狗代码是否放在了延时循环里。2.2 P0/P1口的方向与功能选择寄存器决定了你的灯“听不听话”CC2540的GPIO口不像标准51单片机那样直接操作P0、P1、P2寄存器就行。它多了一层复用逻辑每个IO口默认被分配到特定的外设功能。P1口的P1_0和P1_1默认就是UART0的RX和TX如果你把LED接在这两个脚上又不改SEL寄存器写电平根本没反应因为引脚已经被外设占用了。控制引脚方向的核心寄存器是P0DIR、P1DIR、P2DIR对应每一位写1是输出写0是输入。但在此之前必须先设置P0SEL、P1SEL、P2SEL把引脚从外设功能切换到普通GPIO功能。以推挽输出点亮一颗LED为例P1SEL ~0xC0; /* P1_6和P1_7切换到GPIO功能 */ P1DIR | 0xC0; /* P1_6、P1_7设为输出方向 */ P1_6 0; /* 推挽输出低电平点亮LED */ P1_7 1; /* P1_7输出高电平关断LED */这里最关键的是P1SEL ~0xC0这一行。0xC0对应二进制11000000也就是P1_6和P1_7两位。如果不把这两位清零引脚仍然属于调试模块或外设GPIO输出寄存器操作无效。P1DIR | 0xC0是让这两位变成输出模式方向配置必须在SEL配置之后。还有一类常见接法是LED接在P0口例如P0_0到P0_3接了四个LED。注意P0_0在CC2540上同时是模拟比较器AIN0输入引脚如果你只是做GPIO用需要把P0SEL相应位清零如果有模拟输入需求才置1。这个细节非常容易翻车因为P0SEL默认值并非全零部分位在上电时会根据复位类型有不同初始值所以不能用“默认就是GPIO”来安慰自己。2.3 点亮一个LED就能验证整个GPIO通路是否正常拿到别人的CC2540流水灯源码第一件事不是全工程编译烧录而是先把所有外设功能全卸掉写一个点灯单测。我会单独建一个IAR工程只做三件事配置LED引脚为GPIO输出、写一次电平、延时后再翻转。这样能快速判断硬件连接和寄存器配置是否一致。#include ioCC2540.h void main(void) { P1SEL ~0xC0; P1DIR | 0xC0; P1_6 0; while(1) { P1_6 !P1_6; delay_software(1000); } }如果这个代码编译烧录后灯能稳定闪烁说明GPIO通路完全正常后面流水灯起不来就一定是逻辑或复用配置问题。如果灯不亮先拿万用表量LED两端电压判断是没电平输出还是电平被拉低。CC2540的GPIO驱动能力有限大约能提供4mA左右的灌电流和2mA左右的拉电流如果你直接把LED串电阻接到VCC和GPIO之间靠引脚即电流点亮LED亮度会暗得离谱。正确做法是LED阴极接GPIO阳极通过限流电阻接VCC让引脚低电平导通也就是灌电流方式。3. 流水灯核心逻辑延时、状态轮换与裸机循环的配合3.1 查表法还是移位法两种思路的代码差异和适用边界流水灯的基本逻辑就是让一组LED按固定顺序点亮和熄灭。在CC2540裸机环境下实现方式大体两种查表法和移位法。查表法是把每一帧要亮的灯状态编码成一个uint8数组循环遍历输出到P1口移位法是对一个初始值不断左移配合或运算补位。查表法的优点是好理解、便于停在一个特定状态比如“只亮第三颗灯”可以直接查表index2。缺点是改流水节奏需要改表。移位法的优点是代码短适合做连续流动uint8 state 0x01; while (1) { P1 (P1 0x3F) | (state 0xC0); state state 1; if (state 0x00) state 0x01; delay_ms(200); }这里解释一下P1 (P1 0x3F) | (state 0xC0)的含义。P1寄存器低位可能还接了其他功能比如UART调试、按键输入等所以不能直接整体赋值否则会打扰其他引脚配置。0x3F是保留低6位不变高两位用state来接管。当state左移到高位溢出变成0时用if语句重新赋回0x01形成循环。如果你把LED接在P0口只要把P1整体换成P0即可但注意P0口的低两位默认可能用于UART调试。如果调试串口也走P0口你就得认真规划哪些LED接高位哪些接低位。这块原资源里给出的做法是四颗LED全接P1.4到P1.7我试过这个方案最大的好处是可以整体操作高四位不受低四位外设干扰。3.2 延时函数的三个深坑空循环、中断偏移、编译器优化裸机流水灯最容易被忽视的是延时函数本身。标准51单片机教程里的延时函数直接写个空循环就能用但CC2540的IAR编译器优化等级一开这种延时函数会被整个删掉。因为空循环没有副作用编译器认为它是死代码直接不生成汇编指令。解决方法是给循环变量加volatile修饰void delay_software(volatile uint16 ms) { volatile uint16 i; while (ms--) { for (i 0; i 16000; i); } }volatile告诉编译器i每次都要从内存重新读取不能优化掉循环体。但volatile只解决“循环不被删”的问题不解决“延时准不准”的问题。16000这个数在不同时钟频率下的循环耗时不一样如果你用内部16MHz RC和一个用32MHz外部晶振的板子对比同样代码时长差一倍。这就是很多人“明明按教程写延时灯却闪得飞快”的原因之一。第二个坑是中断偏移。如果你的工程里同时开了定时器中断或BLE协议栈事件延时函数执行到一半会被中断打断空循环计时只算了CPU忙等的时间没算中断服务程序消耗的时间。在普通流水灯里这点误差无所谓但如果你在后一阶段用延时做无线射频数据发送间隔计时误差会被协议栈放大。我的习惯是延时超过10ms就改用定时器不用空循环。3.3 中断做流水方向切换轮询状态机的关键一步按键切换流水方向是这类资源的常见扩展功能。CC2540的按键检测如果不做防抖一次按下会被识别成两三次触发流水方向变得神经质。处理办法是在GPIO中断服务函数里加软件延时消抖#pragma vector P1INT_VECTOR __interrupt void P1_ISR(void) { if (P1IFG 0x01) { /* 检测P1_0中断标志 */ delay_software(20); /* 消抖 */ if (P1_0 0) { direction !direction; } P1IFG 0x00; /* 清除中断标志 */ } }注意P1IFG必须在退出中断前清零否则同一中断会反复触发。清零前要先读一遍引脚电平因为消抖延时期间如果按键已经释放说明只是抖动不需要翻转方向。direction变量建议用volatile定义因为它在主循环和中断函数里同时被访问不修饰的话编译器可能把它缓存成寄存器副本导致主循环永远读到旧值。如果你想在主循环里轮询按键状态而不开中断那么需要关注按键上下拉的配置。CC2540的P1口内部有可编程上拉或下拉电阻配置在P1INP寄存器位是PULLUP。如果按键一端接GND另一端接P1_0就要设P1INP的对应位为0使能上拉接VCC则相反。很多人忘记配置这个内部上下拉按键悬空时电平随机抖动轮询结果完全不可信。4. 从按键到手机在BLE协议栈里加一个特征值控制灯的开关4.1 SimpleBLEPeripheral工程中要改的核心文件是哪个纯裸机流水灯说到底只是热身CC2540的价值在于无线控制。资源包里一般会给出一个基于TI BLE协议栈的工程通常是SimpleBLEPeripheral的变体。第一次打开这个工程最大的心理冲击是文件非常庞杂光协议栈库就占了一半以上空间。你真正要改的其实是自己对业务逻辑的那一层也就是simple_peripheral.c以及外设驱动文件。BLE协议栈跑起来之后主循环的控制权不再归你而是由协议栈的任务调度器管理。你不能把while(1)流水灯随便扔进main函数因为协议栈本身的link layer任务、密钥分发任务都靠同一个循环驱动。正确方式是把流水灯逻辑放在一个周期性事件里每次事件触发跑一轮刷新跑完立刻返回让出CPU。在simple_peripheral.c里每位外设状态都由simpleProfile_WriteAttrCB这个回调函数接收。手机App往特征值写数据时这个函数会被调用。你需要在里面判断paramID如果是自己定义的LED控制特征值就解析收到的字节写入对应的GPIOstatic bStatus_t simpleProfile_WriteAttrCB(uint16 connHandle, gattAttribute_t *pAttr, uint8 *pValue, uint16 len, uint16 offset) { if (pAttr-type.len 2 pAttr-type.uuid SIMPLEPROFILE_CHAR1_UUID) { if (len 1) { led_state pValue[0]; update_led_output(led_state); } } return SUCCESS; }pValue是手机端发过来的数据指针len是数据长度。判断len 1是为了防止App发送多字节数据时你把广播地址或其他信息误当灯控指令。update_led_output这个函数是我自己写的它根据led_state变量的值直接改写P1口输出比如0x01亮第一颗0x03亮前两颗。这里的参数说明就是你在上位机定义的通信协议如果不跟App端约定好后面联调必然对不上。4.2 协议栈事件驱动的流水灯把延时改成事件轮询裸机流水灯用delay_ms非常自然但协议栈环境下一旦调用长时间阻塞延时协议栈的RF收发任务会被卡住轻则手机蓝牙连接断开重则芯片看门狗复位。所以进入协议栈后流水灯的刷新必须改成“非阻塞”模式。我给出的替代方案是用一个软件计时器每200ms触发一次协议栈事件事件内翻转一次LED状态。具体做法是设置OSAL回调函数初始化时调用osal_set_event注册定时器uint8 SimpleBLEPeripheral_ProcessEvent(uint8 task_id, uint16 events) { if (events SBP_LED_FLOW_EVT) { led_index; if (led_index 4) led_index 0; update_led_output(1 led_index); osal_start_timerEx(task_id, SBP_LED_FLOW_EVT, 200); return (events ^ SBP_LED_FLOW_EVT); } return 0; }这里的关键是osal_start_timerEx必须在事件处理函数内部重新调用一次因为OSAL定时器是单次触发的触发完就失效。200这个数字是毫秒控制流水灯切换速度。如果你想做到流水灯快慢由手机App动态调节把200改成从特征值里读出来的变量就行。4.3 联调阶段为什么手机App写入没反应这个阶段最容易出现的问题不是硬件而是服务发现缓存。手机第一次连接CC2540时系统会做GATT服务发现把UUID表缓存到本地。如果之后烧录了修改过特征值UUID的新固件手机端缓存没刷新App依然按旧UUID去找写入就找不到对应特征值。解决手段是连接后先执行一次服务发现刷新或者调低BLE协议栈广播间隔让设备重连。在Android端每次连接前调用BluetoothGatt.discoverServices()是必须的。如果你在调试中发现App连接很快但写入毫无反应八成是服务发现失败而不是GPIO配置问题。我一般会在写入前用抓包工具看一眼协议栈回包状态如果返回值是0x03Invalid UUID那就是UUID对不上如果返回值是0x01Invalid Handle说明code里找特征值的句柄方式不对要去检查simpleProfile_WriteAttrCB里判断的条件。5. 避坑实录五个让流水灯“装死”的典型翻车点5.1 用CC Debugger烧录时连不上目标板现象点击IAR的Download按钮后提示“CC2550-ID mismatch”或“Target reset failed”但板子确确实实上电了。原因CC2540的Debug口默认是P2_1和P2_2和普通按键、LED占用的口线没有冲突但烧录时序需要DC-DC电压稳定。如果开发板供电用的是USB转串口模块的3.3V而这个模块本身带载能力弱芯片在烧录复位瞬间电流陡增电压塌陷导致调试器握手失败。解决我通常在烧录时把板子上其余外设的电源断掉只保留CC2540最小系统的电源。具体到操作上把LED的限流电阻一侧从VCC断开或者用跳线帽把LED电源隔开。烧录成功后重新上电再接LED。如果还连不上检查CC Debugger连接器的排线方向是否接反这个比你想的更常见。5.2 LED亮度异常但波形逻辑是对的现象灯能亮能灭但亮度比直接接3.3V时差很多或者有的灯微亮、有的灯不亮。原因CC2540的GPIO输出高电平驱动能力很弱如果你把LED阳极直接接GPIO阴极经电阻到GND靠引脚拉电流点亮高电平驱动最多提供2mA左右。四颗LED同时亮时总电流可能超过GPIO规格电压被拉低灯自然暗。解决统一改成灌电流方式LED阳极接3.3V限流电阻接LED阴极阴极接GPIO。GPIO输出低电平时形成通路。每颗LED限流电阻取330Ω到470Ω之间电阻太小会超出GPIO最大灌电流规格太大灯亮度不足。5.3 IAR优化等级开到High流水灯完全不动现象Debug模式下流水灯正常一选择Release模式烧录进去灯永远停留在某一个状态不循环。原因编译器把主循环里的延时循环识别为无副作用的纯计算在High优化等级下直接整段删掉。如果用了移位法优化器还会把P1的读改写操作合并成一次写入但你的本意是先读后改中间插了延时被优化后时序全乱。解决所有延时循环变量必须加volatile在IAR工程选项里把涉及GPIO操作的函数末尾加#pragma optimizenone或者干脆把流水灯刷新逻辑改成定时器中断触发。从那以后我每次在CC2540上写裸机循环都先看一眼生成的汇编文件确认循环没被优化掉。5.4 加了BLE协议栈之后灯反而乱跳现象纯裸机工程流水灯正常把同样逻辑搬进SimpleBLEPeripheral后灯的切换顺序变得无规律有时两分钟后完全停住。原因裸机工程自己写的while循环里负责所有时序而协议栈工程里系统主循环由多个任务共享。如果你在主循环里写了while(1)无限等待协议栈任务无法获得CPU时间RF收发和GATT事件全被卡住。如果停在某个事件里无法返回整个系统就像死机。解决流水灯只能是周期事件不能是死循环。把状态推进放在SimpleBLEPeripheral_ProcessEvent里用osal_start_timerEx交替注册事件触发。主函数里不要出现任何不会返回的循环结构。协议栈事件之间要避免长代码路径单个事件处理函数不要超过几毫秒。5.5 看门狗复位导致的“半小时崩一次”现象流水灯运行十几分钟到半小时后自动重启重启后正常运行但没有规律。原因如果代码里使能了看门狗而无限循环里没有喂狗CC2540会认为系统异常强制复位。流水灯这种纯CPU等待型任务喂狗指令必须放在延时循环里或者定时器中断里否则两次喂狗间隔超过看门狗超时时间。解决如果不需要看门狗直接在初始化代码里注释掉WatchDogEnable调用。如果需要保活在延时函数的循环体里每跑一次就WDT喂一次。要注意喂狗操作本身也耗时放在消耗型循环里会让实际延时长于预期测准后要微调延时计数器的值。6. 进阶把流水灯改成呼吸灯并顺手压掉待机电流流水灯跑通只算入门CC2540真正值得投入精力的是低功耗和PWM外设。我在拿到这份资源之后做的第一件事是先把纯裸机的吉尔LED逻辑移植到定时器1的PWM输出上。CC2540定时器1支持3对比较输出通道P1_0到P1_6可以复用为PWM信号。BR呼吸灯效果的本质就是让PWM占空比从0缓慢升到100再降回来。如果你要把LED接到P1_6做PWM呼吸灯对应的寄存器配置是P1SEL | 0x40; /* P1_6切换到外设功能 */ P1DIR | 0x40; /* 设置为输出 */ T1CCTL2 0x04; /* 选择比较输出模式通道2 */ T1CC2 0; /* 初始占空比0 */ T1CTL 0x02; /* 定时器1启动系统时钟分频自由运行模式 */T1CCTL2的0x04具体是把通道2设为比较输出模式引脚产生匹配脉冲。T1CC2就是比较值这个值决定了占空比。呼吸灯的核心循环就是不断改变T1CC2这个寄存器uint16 pwm_val 0; while (1) { for (pwm_val 0; pwm_val 1000; pwm_val 20) { T1CC2 pwm_val; delay_software(30); } for (pwm_val 1000; pwm_val 0; pwm_val - 20) { T1CC2 pwm_val; delay_software(30); } }这比原先逐位翻转GPIO的方式平滑得多CPU始终处于UFREE运行状态但每步只改一个寄存器不会有流水灯那种“一个周期三四个GPIO翻转操作导致的不连续感”。pwm_val的步长20决定了呼吸切换速度步长越大变化越明显越小越平滑。这里T1CC2比较值如果是10位PWM模式最大可以到1023建议范围控制在0到1000之间避免边界溢出导致灯突然全亮。呼吸灯的频率定在多少合适取决于你的场景。如果是桌面氛围灯周期建议在2到4秒之间完整完成一亮一灭如果是用来调试BLE连接状态指示灯周期要缩短到1秒以内否则你无法从灯的缓慢变化中分辨协议栈是否正常工作。我一般用一个全局变量保存目标占空比中断里通过增量调节逼近目标值。最后说说功耗。CC2540在PM2模式下电流可以低到微安级别但LED全亮时可能拉到十几毫安。如果你做的是纽扣电池供电的BLE灯控设备每轮流水结束后让系统进入PM2用定时器唤醒比灯一直轮询省电得多。PM2模式下只有定时器和复位和唤醒模块在跑我的习惯是在流水灯完成一个循环后调用POWER_MODE_ENABLE等定时器溢出再自动唤醒。注意PM2模式下GPIO保持输出状态如果你在睡眠前把LED电平写成高电平停下时会有一颗灯常亮这个行为在低功耗场景里必须刻意处理。从那以后我每次写完灯效逻辑都会强制走一遍“待机电流实测”这个流程确认没有哪颗灯在偷偷耗电。希望帮到你。本文还有配套的精品资源点击获取