从零开始折腾：用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内核，主频48MHz，Flash 352KB（实际用户可用约256KB），RAM 80KB（用户可用约64KB），支持蓝牙5.2协议栈。对于门锁这种应用，资源完全够用，甚至有点富余——M4F带硬件FPU，后期想做本地AI语音识别或者更复杂的加密算法，也不会算力吃紧。

再看功耗。门锁这种电池供电设备，最怕的就是“电老虎”。CC2642R在断电模式下电流可以做到0.1uA级别，在保持RTC唤醒的待机模式下约0.85uA，在蓝牙连接但无事件时的电流大约在1uA级别。这意味着两节AA电池撑一年以上是常态。我实际测过，用两节南孚AA电池供电，配置成每秒广播一次、每天开关锁20次，实测待机电流约1.8uA（含外围电路漏电），理论上可运行两年以上——当然实际上电池自放电和低温环境会打折扣，但这个表现已经相当不错了。

对比一下同级别产品：nRF52832同样是M4F，低功耗表现也很优秀，但Flash只有512KB，RAM只有64KB，协议栈占掉一部分后留给应用的资源比CC2642R紧不少；ESP32性能强、Wi-Fi/BT双模，但它的功耗在门锁场景下基本是灾难级别，待机电流动辄几十uA起跳，除非你打算给门锁配充电宝，否则直接劝退。

1.2 蓝牙5.2协议栈：门锁能用上的不只是“更快”

很多人一听到蓝牙5.2就只想到“传输速度翻倍”“传输距离更远”，但对于门锁这种设备，5.2协议栈真正的价值在于三个点：LE Secure Connections强制加密、LE Data Length Extension（DLE）、以及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 TLV70030（3.0V输出，低静态功耗），负载电流能力200mA，带动电机绰绰有余。

电机供电不能直接走LDO输出，因为电机启动瞬间的电流可能到500mA甚至更高。我把电机供电直接接在电池正极上，通过H桥控制通断。这样电机供电走“粗线”，主控供电走“细线”，互不干扰。复位和去耦电容方面，CC2642R的每个电源引脚旁边都放了100nF去耦电容，DCDC_SW引脚接了10uH电感加10uF电容组成DC-DC降压电路，这里一定要参考TI官方参考设计，不要自己乱改，否则轻则电流异常，重则无法启动。

2.2 电机驱动电路

电机驱动我用了一颗很常见的芯片——DRV8837（TI自家产品，和CC2642R搭配非常顺手）。这是一颗低功耗直流电机驱动器，工作电压范围2.7V到10.8V，峰值输出电流1.8A，待机电流小于1uA。它内置了H桥，只需要两个GPIO控制信号（IN1和IN2）就能实现正转、反转和刹车三态控制。

接线图大致是：IN1和IN2分别接CC2642R的两个GPIO（我用的P0.7和P0.8），OUT1和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还是IAR？

TI的CC2642R开发环境主要有两个选择：CCS（Code 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文件里可以看到官方提供的服务定义，照着格式添加自定义服务即可。我定义的门锁服务如下：

为什么开锁指令用Write属性而不是Write Without Response？因为开锁是不可逆动作，必须确认门锁确实收到并执行了指令。Write属性需要手机端等待门锁返回ATT Write Response，能够形成一次完整的双向握手；如果链路层出现丢包，手机端会立刻知道。

4.2 安全鉴权：拒绝“万能钥匙”

智能门锁最怕的就是“万能钥匙”——也就是任何人都能通过蓝牙发送开锁指令。所以鉴权逻辑必须做到：就算攻击者截获了蓝牙通信内容，也无法伪造开锁指令。

我采用的方式是“共享密钥 + 加盐消息认证码（HMAC）”，具体流程如下：

1. 手机和门锁首次配对时，通过蓝牙配对过程中的LE Secure Connections生成一对长期密钥（LTK），协议栈会负责密钥的协商和存储。
2. 手机每次发送开锁指令时，会在指令数据后面附上一串使用LTK派生的密钥计算出的HMAC-SHA256摘要。
3. 门锁收到指令后，先验证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）或者Obesity（Telink开发板上的抓包软件），用于观察广播、连接、ATT操作、加密过程等所有空中数据包，排查协议栈层面的问题事半功倍。

我第一次做门锁时，手机连上门锁后发开锁指令一直无响应，查了很久代码都没发现逻辑问题。后来用抓包器一看，发现门锁根本没有收到手机发来的Write Request——是手机和门锁的MTU协商出了差错，导致手机认为数据发不出去。如果不用抓包器，这种问题排查到怀疑人生都未必能找到。

还有一个简单但非常实用的方法：在门锁的串口调试日志中，把BLE回调函数的关键事件（连接建立、断开、数据接收、MTU更新）都打印出来，配合蓝牙抓包器双管齐下，基本能覆盖90%以上的调试场景。

5.2 常见问题及解决方案

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自带的BIM（Boot 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直流电源分析仪）对原型机做了几个典型状态下的功耗测量，数据如下：

可以看出，在“无连接但广播”这一状态下的平均电流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两边连蓝牙、发指令、收通知的坑也一起记录一下。