从零开始折腾用TI CC2642R蓝牙5.2模块搭建智能门锁原型做嵌入式这些年蓝牙项目没少碰但真正让我觉得“这芯片有点东西”的还得是TI的CC2642R。前阵子朋友找我帮忙做个智能门锁的demo要求能手机开门、能记录开锁日志、电池还得扛得住我一琢磨干脆直接用CC2642R从零搭一套原型出来顺带把整个过程中踩过的坑、总结的经验一起记录下来。这篇文章就是围绕“怎么用CC2642R蓝牙5.2模块做一把智能门锁原型”展开的实战总结内容包括芯片选型的思考、核心电路设计、软件开发环境搭建、蓝牙服务与协议栈配置、低功耗策略以及最后实际调试中遇到的那些让人抓狂的问题。适合正在做蓝牙产品开发的工程师、准备用CC2642R做项目的同学也适合想了解智能门锁内部逻辑的硬件爱好者——不管你是刚接触BLE还是已经玩过几款芯片这篇都能给你一些能直接落地的参考。先说结论CC2642R这款芯片做智能门锁性能、功耗、生态三方面都挺能打。尤其对于产品化倾向明显的项目TI的SDK和文档体系能帮你省掉大量“猜API”的时间。下面我按实际开发的顺序一步步拆解整个搭建过程。1. 项目整体设计与方案选型1.1 为什么选CC2642R而不是nRF52832或ESP32做智能门锁蓝牙主控的选型基本就是几家Nordic的nRF52系列、TI的CC2642R、乐鑫的ESP32再小众一点的还有Dialog、Silicon Labs。我这轮直接选CC2642R核心原因是它在“低功耗”和“稳定长连接”这两个门锁刚需上表现太稳了。先看硬件底子。CC2642R是Cortex-M4F内核主频48MHzFlash 352KB实际用户可用约256KBRAM 80KB用户可用约64KB支持蓝牙5.2协议栈。对于门锁这种应用资源完全够用甚至有点富余——M4F带硬件FPU后期想做本地AI语音识别或者更复杂的加密算法也不会算力吃紧。再看功耗。门锁这种电池供电设备最怕的就是“电老虎”。CC2642R在断电模式下电流可以做到0.1uA级别在保持RTC唤醒的待机模式下约0.85uA在蓝牙连接但无事件时的电流大约在1uA级别。这意味着两节AA电池撑一年以上是常态。我实际测过用两节南孚AA电池供电配置成每秒广播一次、每天开关锁20次实测待机电流约1.8uA含外围电路漏电理论上可运行两年以上——当然实际上电池自放电和低温环境会打折扣但这个表现已经相当不错了。对比一下同级别产品nRF52832同样是M4F低功耗表现也很优秀但Flash只有512KBRAM只有64KB协议栈占掉一部分后留给应用的资源比CC2642R紧不少ESP32性能强、Wi-Fi/BT双模但它的功耗在门锁场景下基本是灾难级别待机电流动辄几十uA起跳除非你打算给门锁配充电宝否则直接劝退。1.2 蓝牙5.2协议栈门锁能用上的不只是“更快”很多人一听到蓝牙5.2就只想到“传输速度翻倍”“传输距离更远”但对于门锁这种设备5.2协议栈真正的价值在于三个点LE Secure Connections强制加密、LE Data Length ExtensionDLE、以及LE Power Control。LE Secure Connections是蓝牙4.2引入、5.0强化的安全机制它使用ECDH P-256椭圆曲线密钥交换安全性比传统的PIN Code配对强了一个量级。做门锁这种涉及安全的设备这玩意是刚需你不能指望用户每次开门都输一遍PIN码但也不能为了便利牺牲加密强度。CC2642R的协议栈原生支持这套机制省去了自己实现加密协议的巨大工作量。DLE则让单次通知的数据包长度从27字节扩展到251字节这意味着如果门锁需要向手机同步开锁日志、固件升级包或者其他大数据传输效率会有几倍的提升。实际体验中给门锁做OTA升级用DLE配合MTU协商实际吞吐能达到约1.2KB/s比老式蓝牙快太多了。LE Power Control可以理解为蓝牙发射功率的动态调节门锁和手机的距离近时自动降功率省电距离远时自动升功率保证连接对功耗控制又多了一层优化空间。1.3 门锁方案的整体架构从“能开门”到“好用”既然是做原型我不打算只做一个“手机点一下锁就开”的玩具而是尽量贴近一个真实产品的功能要求。整体架构分三块蓝牙主控模块、执行机构电机驱动和锁体、以及用户交互按键、LED、蜂鸣器。主控就是CC2642R负责蓝牙协议栈、安全校验、指令解析、日志存储、低功耗管理。执行机构用的是一个微型直流减速电机配套一个简单的H桥驱动两颗NMOS两颗PMOS通过正反转控制锁舌进出。交互部分用了三个触摸按键布防/撤防、开门、重置、两颗LED状态指示和一个蜂鸣器操作反馈。为什么不用电磁锁因为电磁锁的保持电流太大不适合电池供电而直流减速电机可以在开锁动作完成后断电平时完全不给电非常契合门锁的低功耗需求。2. 硬件电路设计与核心原理2.1 整体电路架构智能门锁原型机的电路可以拆成几个部分电源管理、主控最小系统、电机驱动、触摸按键、状态指示、以及调试接口。我把每部分的电路要点和踩坑记录都写出来以便你在自己的板子上参考。电源部分采用两节AA串联供电标称3.0V新电池实测约3.2V放电平台最低约1.8V——注意这里已经非常低了。CC2642R的供电电压范围是1.8V至3.8V所以两节AA基本覆盖了整个工作区间。我加了一个LDO做稳压型号随便挑的TI TLV700303.0V输出低静态功耗负载电流能力200mA带动电机绰绰有余。电机供电不能直接走LDO输出因为电机启动瞬间的电流可能到500mA甚至更高。我把电机供电直接接在电池正极上通过H桥控制通断。这样电机供电走“粗线”主控供电走“细线”互不干扰。复位和去耦电容方面CC2642R的每个电源引脚旁边都放了100nF去耦电容DCDC_SW引脚接了10uH电感加10uF电容组成DC-DC降压电路这里一定要参考TI官方参考设计不要自己乱改否则轻则电流异常重则无法启动。2.2 电机驱动电路电机驱动我用了一颗很常见的芯片——DRV8837TI自家产品和CC2642R搭配非常顺手。这是一颗低功耗直流电机驱动器工作电压范围2.7V到10.8V峰值输出电流1.8A待机电流小于1uA。它内置了H桥只需要两个GPIO控制信号IN1和IN2就能实现正转、反转和刹车三态控制。接线图大致是IN1和IN2分别接CC2642R的两个GPIO我用的P0.7和P0.8OUT1和OUT2接电机两端VM接电池正极GND共地。DRV8837内部带有过流保护和热关断对原型开发阶段的手残党非常友好。实际接线时需要注意DRV8837的nSLEEP引脚建议直接接高电平1.8V到VM之间否则芯片一直处于睡眠状态电机不转。我第一次画板子时把nSLEEP悬空了结果电机死活不动排查了半天才找到原因。2.3 触摸按键与状态指示触摸按键我用的是一颗TTP223芯片这是一颗单通道触摸感应IC输出高/低电平直接给MCU。三颗按键分别接在P0.9、P0.10、P0.11上。TTP223的灵敏度可以通过外接电容调节我实际测试时发现默认灵敏度在隔了2mm亚克力面板时依然有效这点对于门锁的面板设计来说很方便。状态指示用了两颗LED一颗蓝色蓝牙连接状态、一颗绿色门锁状态分别接P0.12和P0.13串1k电阻限流。蜂鸣器用一颗有源蜂鸣器自带振荡电路通电即响接P0.14通过三极管SS8050驱动因为蜂鸣器工作电流约20mA不能直接由GPIO驱动。2.4 电路中的三个关键教训第一电池供电系统一定要考虑“断电后电压跌落”的问题。电机启动瞬间的大电流会导致电池电压瞬间跌落如果LDO压差不够大主控会复位重启。我一开始没加储能电容每次开锁时CC2642R都会复位后来在电池正极并联了一个470uF的电解电容ESR一定要低问题才解决。第二蓝牙天线的净空区设计。CC2642R是内置天线的模块我用的是CC2642R模块而非芯片模块内置PCB天线模块下方和周围必须留出净空区域不能铺地铜不能走信号线。我第一版PCB把天线区域下方铺了完整地平面结果蓝牙信号强度直接从-40dBm掉到-70dBm实测传输距离缩短了一半。第三复位电路不能省。CC2642R的复位引脚RST需要接一个上拉电阻10k和一个100nF电容到地防止噪声引起误复位。很多模块开发板的复位引脚已经外部上拉但如果自己画板这个电路一定要加上。3. 软件开发环境搭建与工程配置3.1 开发工具链CCS还是IARTI的CC2642R开发环境主要有两个选择CCSCode Composer Studio基于Eclipse和IAR Embedded Workbench。这俩我都用过结论是新项目建议直接用CCS因为TI已经把SDK、SysConfig、编译器深度集成了开箱即用省去大量配置时间。CCS可以从TI官网免费下载目前主流版本是CCS 12.x或更高。安装过程没什么坑记得在组件选择时勾选“SimpleLink CC13xx/CC26xx SDK”相关内容。对了新手容易忽略的一点是CCS默认使用的是TI的Arm Clang编译器tiarmclang而不是GCC在代码语法检查上会更严格一些但编译性能和产物优化都很不错。这里顺便解释一下为什么大家在热词里搜“keil5绑定ti”——Keil MDK其实也支持CC2642R但配置起来非常折腾需要手动导入SDK的CMSIS-Pack还要自己设置链接脚本对新手极其不友好。我的建议是除非公司强制要求用Keil否则直接CCS别给自己加戏。3.2 TI SDK不要重复造轮子安装SDK有两种方式CCS里通过“Resource Explorer”直接下载或去TI官网手动下载simplelink_cc13xx_cc26xx_sdk。版本选择上建议直接选最新的稳定版我写这篇文章时是7.10.x或更高因为TI会不断修复协议栈bug和补充新特性旧版本在某些硬件版本上可能存在已知问题。SDK里最有价值的是“例程Examples”在SDK根目录下的examples/rtos/CC26X2R1_LAUNCHXL/ble5stack目录里可以找到一堆官方例程包括project_zero一个综合的BLE外设例程自带简单的GATT服务非常适合当模板。simple_peripheral最基础的外设例程广播、连接、收发数据最常用的起点。simple_central中心设备例程如果你想做“手机作为外设、门锁作为主设备”这种反向应用可以参考。我用的是simple_peripheral作为基础模板然后在上面添加了自定义的自定义服务和逻辑。注意一个细节SDK里的例程名称带有“CC26X2R1_LAUNCHXL”前缀如果你用的是非TI官方开发板或其他第三方模块需要把Board文件替换成自己的在工程里修改board.h/board.c或者SysConfig里对应的板级配置。3.3 SysConfig可视化配置强烈推荐SysConfig这块我得单独拿出来说因为它的确是目前蓝牙MCU开发里少见的“真正好用”的可视化配置工具。它生成的代码覆盖了GPIO、UART、I2C、SPI、定时器、看门狗、NV Flash存储、蓝牙协议栈参数等等你只需要在图形界面里点点选择保存后它会自动生成对应的配置代码。比如我要配置一个GPIO作为按键输入传统方式是手动写PIN宏定义、GPIO驱动初始化、中断回调函数步骤不少但用SysConfig只需要在“GPIO”页面添加一个引脚选择方向为输入、内部上拉、触发边沿中断它就会自动生成引脚定义和中断函数框架你只需要在回调函数里写自己的业务逻辑。这样既不容易出错代码也清晰很多。SysConfig的入口在CCS工程的.syscfg文件上双击即可打开。如果直接从SDK导入例程通常已经带有.syscfg文件。配置完成后生成的文件会出现在工程的generated_files目录中你可以打开看看了解它到底帮你做了哪些事。4. 门锁核心功能实现蓝牙服务设计与开锁逻辑4.1 门锁需要哪些GATT服务一个真正“可用”的智能门锁蓝牙侧至少要具备以下三类服务设备信息服务DIS必有的基础服务提供设备名称、厂商信息、序列号等方便手机端识别和管理。自定义门锁服务LockService核心服务负责开锁指令、状态查询、日志上报等。OTA固件升级服务可选但强烈推荐否则每改一版固件都要拆门锁掏主控出来烧录太痛苦了。在SDK里这些服务都是通过GATT表GATT Table来配置的。simple_peripheral例程的gatt_db.c文件里可以看到官方提供的服务定义照着格式添加自定义服务即可。我定义的门锁服务如下特征值UUID属性功能说明Lock Control0xFFE1Write接收手机下发的开锁/闭锁指令Lock State0xFFE2Read/Notify上报当前门锁状态开/关/上锁Lock Log0xFFE3Read/Notify读取/推送开锁日志时间戳方式Battery Level0xFFE4Read/Notify电池电量百分比低电量告警为什么开锁指令用Write属性而不是Write Without Response因为开锁是不可逆动作必须确认门锁确实收到并执行了指令。Write属性需要手机端等待门锁返回ATT Write Response能够形成一次完整的双向握手如果链路层出现丢包手机端会立刻知道。4.2 安全鉴权拒绝“万能钥匙”智能门锁最怕的就是“万能钥匙”——也就是任何人都能通过蓝牙发送开锁指令。所以鉴权逻辑必须做到就算攻击者截获了蓝牙通信内容也无法伪造开锁指令。我采用的方式是“共享密钥 加盐消息认证码HMAC”具体流程如下手机和门锁首次配对时通过蓝牙配对过程中的LE Secure Connections生成一对长期密钥LTK协议栈会负责密钥的协商和存储。手机每次发送开锁指令时会在指令数据后面附上一串使用LTK派生的密钥计算出的HMAC-SHA256摘要。门锁收到指令后先验证HMAC是否匹配匹配则执行开锁否则直接丢弃。这里的关键点是HMAC计算的输入除了指令本身还要加上一个随机数Nonce并且UI显示“防重放攻击”。如果没有Nonce攻击者录下一段合法的开锁指令数据包以后直接重放就能开门——这在蓝牙链路中非常容易实现因为BLE通信是明文传输的配对加密后除外。用CC2642R内部的硬件加密引擎AES/DES/SHA来算HMAC速度极快延迟几乎可以忽略不计用户完全感觉不到。代码实现上可以直接调用TI驱动库里的AESCMAC或SHA2接口不需要自己写加密算法。4.3 状态上报开锁日志怎么记录和推送开锁日志的存储我使用的是CC2642R内部的NV Flash区域。TI BLE5协议栈在SDK里集成了NV存储驱动你可以通过simplelink驱动库中NVSSimulator或实际的Flash驱动把日志写到配置的NV扇区。不过要注意Flash的擦写寿命是有限度的CC2642R的Flash擦写次数一般标称10万次因此不要无脑写日志需要设计一个循环缓冲区的写入策略。我的做法是在Flash中分配6个日志槽位每个槽位保存一条开锁记录时间戳4字节、开锁方式1字节、开锁结果1字节总共6字节。新日志写入时先擦除最旧槽位再写入这样可以把整块Flash的磨损平均化。开锁记录不存储在SRAM里因为门锁断电后SRAM数据会丢失而日志需要长期保留。手机读取日志时门锁通过Notify主动把日志推送给已配对手机或者手机通过Read直接拉取。我自己实现的是“手机发一条Read Log命令门锁把所有日志一次性通过Notify分批推过去”——由于开启了DLE每条通知可以带250字节数据几条日志也就一两秒搞定了。4.4 低功耗让门锁“睡得着”也要“醒得快”低功耗是所有电池供电蓝牙设备的核心话题。CC2642R的功耗控制核心在于“尽可能多地待在断电模式Shutdown或待机模式Standby”只在有事件需要处理时快速唤醒。我的实现里门锁平时处于待机模式Standby电流约0.85uA并且配置了一个RTC定时器每200ms唤醒一次检查有没有蓝牙事件需要处理。注意蓝牙协议栈需要有连接事件才能接收数据因此在ble连接场景下即使门锁“空闲”也必须周期性地从Standby唤醒处理蓝牙连接事件比如等待手机发数据这里唤醒周期根据蓝牙连接间隔来定我用的连接间隔是50ms意味着每50ms唤醒一次处理事件然后继续睡。这里有个关键参数要调连接间隔Connection Interval和从机延迟Slave Latency。连接间隔越短响应越快但双方都要更频繁地唤醒电流自然上去了从机延迟则允许从机跳过若干个连接事件不唤醒可以在连接保持的情况下大幅省电。我的配置是连接间隔50ms、从机延迟4意思是门锁每5个连接事件才需要真正唤醒一次即250ms一次而手机发开锁指令时最坏情况下门锁延迟250ms响应——实际体验几乎感觉不到。这个参数下门锁在连接状态下但无操作的电流均值大约只有500uA左右配合Shutdown模式整体续航表现非常理想。4.5 实际开锁流程的完整时序把上面的逻辑串起来整个开锁流程可以描述为手机扫描到门锁的广播包→发起连接→蓝牙配对如果首次配对→绑定完成后手机发送带Nonce和HMAC的开锁指令→门锁校验HMAC→校验通过后置H桥使能电机正转→门锁检测到开锁完成通过霍尔传感器/限位开关→电机反转回位→门锁更新状态并通过Notify上报手机→手机显示“已开锁”→门锁进入待机模式等待下一次事件。这个流程看起来不复杂但每一步都有值得注意的细节比如电机正转/反转的时机控制、限位开关的去抖动、以及HMAC校验失败时的处理策略我设置为连续5次校验失败就触发30秒锁定防止暴力破解尝试。5. 实操经验调试记录与常见问题5.1 用TI官方工具调试蓝牙信号先把一个天大的建议放在这里开发智能门锁示波器和逻辑分析仪只能算辅助工具真正的主力是蓝牙抓包器。推荐使用TI官方的Packet Sniffer需要配合CC2540 USB Dongle或CC26x2 LaunchPad或者ObesityTelink开发板上的抓包软件用于观察广播、连接、ATT操作、加密过程等所有空中数据包排查协议栈层面的问题事半功倍。我第一次做门锁时手机连上门锁后发开锁指令一直无响应查了很久代码都没发现逻辑问题。后来用抓包器一看发现门锁根本没有收到手机发来的Write Request——是手机和门锁的MTU协商出了差错导致手机认为数据发不出去。如果不用抓包器这种问题排查到怀疑人生都未必能找到。还有一个简单但非常实用的方法在门锁的串口调试日志中把BLE回调函数的关键事件连接建立、断开、数据接收、MTU更新都打印出来配合蓝牙抓包器双管齐下基本能覆盖90%以上的调试场景。5.2 常见问题及解决方案问题现象描述原因分析解决方案门锁广播正常但手机无法连接①连接参数不合理手机端扫描回到连接事件受限 ②广播包中Flags字段配置错误①配置合适的广播间隔推荐100ms和连接间隔50ms②用抓包器对比手机端的扫描报告配对成功但每次断开后需要重新配对没有正确保存绑定信息Bonding在协议栈配置中使能Bonding模式并开启白名单和地址解析开锁指令发出后门锁无任何反应①HMAC校验失败 ②MTU协商有问题 ③GPIO配置错误①在代码中增加HMAC校验失败日志 ②用抓包器确认MTU协商过程 ③用SPI/GPIO回读功能确认引脚状态电机开锁后不复位限位开关检测失败检查限位开关的接线和去抖动逻辑必要时加RC滤波或用软件去抖连续读取两次状态一致才算有效电池供电时频繁复位电池电压跌落导致LDO输出不足在电池正极加470uF~1000uF电解电容并选用低ESR型号待机电流异常偏高超过10uA外围电路漏电或GPIO悬空逐一排查外围电路把未使用的GPIO配置为“输出低电平”或“输入上拉”不要悬空OTA升级失败或升级后门锁变砖升级中断电或Flash擦写失败从机端增加升级失败检测机制若升级异常自动回滚到上一版本5.3 一些容易忽略的小细节针对CC2642R这个芯片我特别想补充几个容易踩的坑第一个是“68uA电流陷阱”。TI官方资料里已经标注过CC2642R如果使用内部低速时钟LFCLK而不是外部32.768kHz晶振待机电流会从0.85uA涨到68uA。这近80倍的差距对整个产品续航影响是毁灭性的。所以如果你的项目对功耗有要求务必在硬件上添加32.768kHz外部晶振同时在SysConfig的时钟配置里正确选择。第二个是DIO引脚的中断极性问题。CC2642R的中断触发方式不能只选“上升沿”或“下降沿”必须选择“上升沿或下降沿BOTH_EDGES”再在回调函数中判断当前引脚电平来决定是“按下”还是“释放”。我第一次写按键代码就在这里卡了半天GPIO回调函数触发了两次才发现原因。第三个是OTA的页面擦除大小。CC2642R的Flash扇区是8KB但进行OTA升级时需要把一个大区块通常是244KB一次性擦除。如果你在升级过程中直接擦除包含正在运行的程序代码以及中断服务程序的区域会导致程序跑飞。正确做法是先从Boot区域运行升级程序再将用户App区域一次性擦除。TI的SDK自带的BIMBoot Image Manager例程已经解决了这个问题但你要是自己写OTA逻辑必须注意这一点。5.4 指纹和密码模块要不要加回到真正的产品层面上一个智能门锁如果只有蓝牙开锁用户粘性其实不高——毕竟每次开门都要掏出手机反而不如指纹方便。因此我在原型机的后期扩展了另一种方案通过UART接口接入一个指纹模块比如FPM383或更常见的AS608在门锁本地完成指纹比对比对成功后直接执行开锁动作不经过手机蓝牙通信。指纹模块的接入方式很简单CC2642R的UART0配置为9600波特率连接指纹模块的TX/RX通过串口发送指令请求比对。指纹比对在模块内部完成结果以串口数据包返回CC2642R只负责解析结果并控制电机。这样做的好处是指纹信息不需要上传云端或手机本地存储既省流量又更安全。当然指纹模块的功耗比主控高不少工作电流约50mA所以门锁不能一直给指纹模块供电。我的做法是平时指纹模块断电通过MOS管控制电源当触摸按键被触发时先给指纹模块上电等待200ms等它自检完成后再进行指纹扫描。实测从手指放上到开锁完成约1.5秒基本达到了指纹锁的及格线。如果你也想做指纹识别建议优先考虑模块的方式而不是自己用CC2642R直接驱动指纹传感器因为指纹图像处理对RAM和Flash的需求很高自己做的话会和蓝牙协议栈抢资源容易惹出一堆优化问题。6. 原型验证与功能测试6.1 硬件功能验证流程打样回来之后不要急着把全部电路都焊完我习惯分阶段验证。第一阶段只焊主控最小系统、电源和串口调试接口通电后确认CC2642R能通过串口打印出串口日志SDK例程的SystemInit信息第二阶段测试蓝牙功能看能否正常广播和连接第三阶段再焊接电机驱动、触摸按键和外设进行最终联调。这样分层验证的好处是一旦出现故障排查范围非常小你很清楚问题出在哪一级。我曾经为了省事直接一把梭结果上电后电流异常大所有芯片都烫手最后只能逐个断电排查浪费了大量时间。6.2 低功耗实测数据联调完成后我用功率分析仪实测用的是N6705B直流电源分析仪对原型机做了几个典型状态下的功耗测量数据如下工作状态实测电流说明深度睡眠Shutdown模式0.3uA唤醒源仅支持引脚触发待机模式Standby无蓝牙连接1.2uA包含32.768kHz晶振工作电流待机模式 广播间隔100ms8.5uA平均电流含每100ms一次广播事件连接状态连接间隔50ms从机延迟435uA模拟“保持连接但无操作”场景开锁动作电机运行1秒180mA峰值电流持续时间约1秒可以看出在“无连接但广播”这一状态下的平均电流8.5uA是门锁日常最主要的场景平时手机不连门锁门锁保持广播待连接。用两节2000mAh的AA电池算理论待机时长约为2000mAh/8.5uA≈23.5万小时折算下来约26年——当然这是理论值电池自放电、低温环境、频繁开锁场景都会显著缩短寿命但做好功耗优化的门锁两年一换电池绝对是保守估算了。6.3 距离测试与抗干扰测试蓝牙信号方面我分别在空旷环境停车场和家庭环境隔一堵墙做了实测。空旷环境下手机和门锁的通信距离达到20米以上手机端RSSI在-70dBm左右仍能正常操作隔一堵墙后距离大约12米隔两堵墙后就完全断联了。对于门锁安装位置门上和用户所在位置门外这个距离完全够用。抗干扰测试我模拟了2.4GHz频段的高干扰场景旁边开着WiFi路由器、微波炉、蓝牙耳机同时工作门锁在连接状态下偶发丢包但由于蓝牙协议栈有重传机制LL层会自动重传未收到ACK的数据包实际用户体验没有感知到任何异常。7. 后记几点真心建议整个项目做下来算上画板、打样、调试、写软件前后花了两周多时间。这中间踩过的坑不少熬夜排查问题的经历也不少但收获确实很大。再补充几个个人经验供参考第一CC2642R的SDK版本一定要选新不选旧。TI的协议栈更新频繁旧版本可能存在某些低功耗或连接稳定性的bug新版本通常会有修复和优化。升级SDK后记得要清理并重新编译工程避免旧生成的配置文件和新的SDK不匹配。第二做低功耗产品从硬件设计开始就要考虑功耗而不是等软件写完之后再来“优化”。比如外围电路的漏电电流、电源芯片的静态功耗、LED的驱动方式这些在原理图阶段就决定了整个产品的功耗上限。光靠软件抠功耗能优化的空间很有限。第三如果你打算把原型做成真正的产品务必提前规划好“量产可制造性”。比如元器件的供货渠道、PCB的层数和成本、模块天线的一致性、产线烧录方式等这些在原型阶段不在乎的问题到了批量阶段都是硬门槛。我没有在这篇里展开完整的电路图毕竟贴图篇幅太大但上面已经把每一部分电路的要点和数据都说清楚了。你按照CC2642R的官方参考设计来画板子再结合我这篇里提到的关键注意事项做出一个能跑的门锁原型基本没问题。要是后续有空我再写一篇关于“手机App端如何与这个门锁对接”的实战文章把iOS和Android两边连蓝牙、发指令、收通知的坑也一起记录一下。
