1. 拆开 PHY6270 这个标题一颗蓝牙 LE 6.1 超低功耗 SoC 到底卖给谁PHY6270 这个型号第一次出现在我桌面上是同组一个做工业传感器的兄弟发来的配文就一句这颗蓝牙 LE 6.1 超低功耗系统级芯片能不能扛住电池供电的端侧 AI 视觉模块。这两年被问类似问题的频率明显变高了原因也不复杂以前一颗 BLE SoC 只要负责把几个温度、湿度字节发出去就算交差现在甲方动不动就要在端点上加摄像头、加推理、加本地判断还得继续用纽扣电池供电三年不换。PHY6270 这类产品就是冲着这个矛盾来的。先说清楚它是什么。从型号命名和定位看这是一颗把 MCU 内核、蓝牙 LE 射频收发器、电源管理单元、Flash/RAM 和一堆外设集成在单硅片上的系统级芯片主打指标是超低功耗和蓝牙 LE 6.1。系统级的意思是你不需要再外挂一颗 MCU 加一颗射频芯片省掉的不只是 BOM 成本更重要的是省掉了两颗芯片之间那几条走线带来的功耗与调试麻烦。它面向的典型场景是那种插电不方便、换电池更不方便但又要长期在线、偶尔还要跑点轻量智能算法的设备。1.1 从型号命名方式看这颗芯片的产品定位大多数做低功耗无线的厂商命名习惯都差不多字母前缀代表产品家族或者工艺平台中间数字大致对应系列代际末尾数字区分存储容量或者封装。PHY6270 这种四位数字的写法通常意味着它在同一个家族里属于中高配Flash 大概率在 512KB 到 1MB 这个区间RAM 在 128KB 到 256KB 之间因为要跑端侧 AIRAM 太小根本放不下模型权重和图像缓冲区。这个定位很关键。如果你只是做个蓝牙温湿度计用不着这种规格的芯片多花的钱和多余的静态功耗都是浪费但你要在端点上做图像差分、做简单的人形检测、做异常振动识别那 RAM 和算力就是硬门槛省不得。我一般建议团队在选型时先问三个问题最大模型多大、单次推理最长多少毫秒、平均电流预算多少微安。这三个数字定了芯片档次基本就定了剩下的才是比价。1.2 超低功耗是设计目标不是参数表上的一个数字很多新人看数据手册看到睡眠电流 1.2µA就以为整机功耗就这么点这是最常见的误解。数据手册标的睡眠电流是在特定条件下测出来的某个电源模式、某些外设关闭、IO 保持特定状态、电压和温度都在典型值。你的板子上只要有一个 IO 悬空、上拉电阻没关、LDO 静态电流偏大实测就可能是它的几十倍。我在实际项目里见过太多次这种情况芯片手册写 1.5µA板子实测 180µA查了两天才发现是调试串口的电平转换芯片在漏电。所以超低功耗这四个字一半是芯片本身的功劳另一半完全取决于你的硬件设计和固件写法。PHY6270 这类芯片的价值是它把能做到的部分给足了比如多级电源域、可关闭的 RAM 保持区、自动切换的 DC-DC、射频收发时按需上电剩下的你能不能吃到看本事。1.3 什么项目该选它什么项目最好别碰我自己的判断标准很直接。适合用的电池供电、数据上报频率低秒级到分钟级、偶尔需要本地推理、对体积敏感、对成本不是极度敏感。不适合用的需要持续音频流传输、需要毫秒级硬实时闭环控制、需要大模型本地运行、对价格敏感到每分钱都要抠的量产消费电子。特别提醒一句端侧 AI 视觉模块这个方向坑不在无线在图像。很多人一开始把精力全花在蓝牙功耗调优上把平均电流从 40µA 压到 15µA结果发现摄像头一开平均电流直接跳到 900µA前面那些工作几乎白做。这个账我后面会详细算。2. 蓝牙 LE 6.1 落到板子上要关心的三件事规范版本号这件事工程上和宣传上的意义不太一样。厂商说支持蓝牙 LE 6.1对采购来说是卖点对你来说要拆成三个问题芯片的射频和协议栈固件是否真的实现了 6.1 里那些新特性、这些新特性对你的功耗曲线是正贡献还是负贡献、以及你能不能只挑其中一部分用。我见过不少项目明明用的是最基础的 1M PHY 加传统广播一样跑得很好规范版本高只是保证了向下兼容和未来可升级。蓝牙核心规范 6.0 那一版引入的东西里对工程影响最大的应该是信道探测Channel Sounding它让两颗设备之间可以做厘米级测距这对资产追踪、防丢器、无钥匙进入这类场景意义很大。6.1 在此基础上继续演进常见的关注点集中在隐私地址的随机化刷新策略、信道探测在精度和功耗之间的折中以及低占空比连接下的调度优化。具体的条款细节请以官方发布的规范文档为准我这里只讲落到代码和板子上会碰到什么。提示不要为了支持新版本而盲目开启新特性。信道探测要跑多次测量射频活动时间会明显增加如果你的产品不需要测距开着它就是白白耗电。2.1 规范演进里跟功耗真正相关的部分真正影响你电池寿命的从来不是版本号是射频占空比。射频收发时的电流量级在 4mA 到 8mA 之间具体看发射功率和接收增益而深睡眠电流在微安甚至亚微安量级。这两者差了三四个数量级所以任何射频多开 1 毫秒的改动都要拿计算器算一遍。举个例子假设你的设备每秒连接一次、每次连接事件射频活动 2 毫秒、射频期间平均电流 6mA那么射频带来的平均电流是 6mA × 2ms ÷ 1000ms 12µA。如果深睡眠电流是 2µA你的总平均电流大约 14µA。现在你把连接间隔从 1 秒改成 500 毫秒射频平均电流翻倍到 24µA总电流变成 26µA续航直接砍掉一半多。而如果你把连接间隔改成 5 秒射频平均电流降到 2.4µA总电流约 4.4µA续航能拉到三年以上。这就是为什么低功耗项目里连接参数是第一个要谈的东西而不是最后一个。2.2 连接间隔、从机延迟与 MTU 的定量影响从机延迟Slave Latency是低功耗设计里最容易被忽略的一个参数。它的作用是让从机在若干个连接事件里不回包只要主机没数据给你你就可以一直睡。假设连接间隔 100 毫秒、从机延迟 9意味着你最多可以连续跳过 9 个连接事件也就是 1 秒内只醒一次。这个参数对平均电流的影响比单纯拉长连接间隔更细腻因为它保留了必要时快速响应的能力。MTU 和包个数同样重要。每次连接事件里射频开多久取决于你要发多少数据。如果每包有效载荷 20 字节、每次要传 100 字节那就是 5 个包加上握手开销但如果你把 MTU 协商到 247 字节可能两三个包就发完了射频时间直接缩短一半。我一般的做法是先把 MTU 提到协议栈允许的较大值再用实际数据量反推包数最后拿功耗分析仪验证一遍把理论值和实测值对齐。2.3 广播、扩展广播与周期性广播的占空比选择传统广播有个硬伤单包最多 31 字节包大一点就得拆到扩展广播或者扫描响应里。扩展广播的好处是可以带更多数据、可以只发在数据信道、可以配合周期性广播。但代价是单次广播事件的射频时间变长了如果广播间隔不变平均电流反而会上升。我的经验是这样数据量小于 20 字节、只需要被手机扫到用传统广播配 1 秒到 2 秒间隔就够了数据量在 100 字节以上、需要多个接收方同时拿数据用扩展广播配周期性广播把广播间隔拉到 5 秒甚至更久让接收方自己去同步。这里面没有标准答案得拿你的实际数据量和接收方数量去试。有条件的直接上功耗分析仪跑一遍比看文档猜快得多。3. 电池能撑几年先算清楚能量预算再动手画板做电池供电产品我最怕听到的一句话是先画板子功耗后面再优化。功耗是设计出来的不是调试出来的。你应该在原理图评审之前就把能量预算表做出来每个模块每段时间占多少加起来能不能落在目标内。这张表做得越细后面返工越少。做预算的方法其实很朴素把设备的工作过程拆成几个状态每个状态测出电流和持续时间加权平均。下面我用一个典型场景完整算一遍你可以直接套这个模板。3.1 平均电流的拆项估算法假设一个用 PHY6270 做的电池供电视觉模块工作模式是这样的每 5 秒被 PIR 传感器唤醒一次摄像头采集一帧 QVGA 灰度图做一次轻量推理判断有没有目标然后把结果通过 BLE 上报。具体参数深睡眠1.8µA占绝大部分时间图像采集加推理平均 32mA持续 28ms每 5 秒一次BLE 连接上报平均 5.5mA持续 2.2ms每 1 秒一次PIR 与外围常开电路2.5µA逐项算平均电流图像与推理32mA × 28ms ÷ 5000ms 0.179mA 179µA。BLE 上报5.5mA × 2.2ms ÷ 1000ms 12.1µA。深睡眠与外围1.8 2.5 4.3µA。合计179 12.1 4.3 195.4µA。按 CR2032 标称 220mAh 可用容量实际扣除自放电和内阻损耗保守按 180mAh 算续航是 180 ÷ 0.1954 ≈ 921 小时约 38 天。这个结果对很多场景是不够的。现在做两个优化第一把推理触发从每 5 秒一次改成PIR 触发才采集且两次采集间隔至少 30 秒第二把 BLE 上报改成事件驱动平时不保持连接用广播方式每 10 秒发一次状态。重算图像与推理32mA × 28ms ÷ 30000ms 0.0299mA 29.9µA。BLE 广播传统广播单次射频约 1.1ms、平均 6mA间隔 10 秒6 × 1.1 ÷ 10000 0.66µA。深睡眠与外围4.3µA。合计约 34.9µA。续航变成 180 ÷ 0.0349 ≈ 5158 小时约 215 天七个月。你看同样是这颗芯片同样是这个功能光是把采集频率和连接方式这两件事重新设计续航差出五倍多。这就是为什么我坚持先算账。3.2 电源域与 DC-DC 的取舍很多人有误区觉得 DC-DC 一定比 LDO 省电。在重载下确实如此DC-DC 效率能到 85% 以上LDO 只有输出电压除以输入电压那点比率。但在轻载下DC-DC 的开关损耗和静态电流占比会上升效率可能掉到 40% 以下这时候 LDO 反而更划算。PHY6270 这类芯片一般会提供几种供电模式内置 DC-DC、内置 LDO、或者两者自动切换。我的做法是实测三条曲线——深睡眠电流、射频峰值电流、采集与推理时的平均电流——然后决定用哪种。通常的选择是射频和计算阶段用 DC-DC深睡眠阶段让芯片自己切到低静态电流的通路。如果芯片不支持自动切换就要看你的工作占空比占空比极低的场景用 LDO 反而更好。还有一点容易被忽略外设的供电域。摄像头、传感器、上拉电阻这些能单独用一路 GPIO 控制的负载开关供电就一定要单独控。我在一个项目里把摄像头的供电直接挂在常开电源上结果待机电流多了 60µA换成一个静态电流 0.1µA 的负载开关之后问题立刻解决。这个改动成本不到一毛钱收益却是整机续航翻倍。3.3 睡眠等级、唤醒源与深睡电流的真相深睡电流实测偏大原因通常就那几个我按出现频率排一下未使用的 GPIO 悬空或者被外部拉出漏电流、调试接口没关、外部 Flash 或传感器没进休眠、上拉/下拉电阻没关、负载开关静态电流大、晶体振荡器起振电路一直在工作。GPIO 这个最典型。芯片睡眠时引脚如果是输入悬空状态输入级的施密特触发器可能处于中间电平导致内部振荡和漏电实测能多出几十微安。正确做法是把所有未使用的引脚配成输出低或者带上拉的输入具体看你的原理图用在通信上的引脚睡眠前要配置成不会让外部器件灌电流的状态。唤醒源也要精打细算。RTC 定时唤醒最省其次是低频比较器或者 PIR 这类外部中断最费的是高频 ADC 持续采样。如果你发现设备平均电流比估算的高不少先去看唤醒源是不是太频繁或者唤醒后有没有把该关的外设全关掉。4. 端侧 AI 视觉模块的低功耗解法不是把模型变小这么简单这两年端侧 AI 视觉这个词被用得很泛从手机上的实时美颜到门铃上的人形检测都算。但电池供电的端点 AI和插电设备完全是两个游戏规则。插电设备你只需要考虑算力和延迟电池设备你要在算力、延迟、功耗三个维度里找一个可行点而且这个点往往比你想的要保守得多。我在实际项目里的体会是端侧视觉的功耗八成在图像采集一成在推理一成在数据传输。很多人上来就研究怎么把模型量化到 int8、怎么做剪枝这些都做对了也就省下那 10% 里的一部分真正的大头没动。4.1 图像采集才是功耗大头一颗 QVGA 分辨率的灰度摄像头加上驱动电路和模拟前端工作时电流通常在 15mA 到 40mA 之间具体看帧率和接口。CMOS 图像传感器的功耗大致和帧率、分辨率成正比和接口类型也有关系并口比 SPI 快但耗电更多DVP 并口在低分辨率下反而更省。假设你的采集加传输加预处理总共 30mA、耗时 25ms那么每次采集消耗的能量是 30mA × 25ms 0.75mA·s。如果每 5 秒采一次平均 150µA如果每 30 秒采一次平均 25µA如果每 5 分钟采一次平均只有 2.5µA。所以对于视觉端点第一优先级永远是降低采集频率而不是降低单次采集功耗。我当时为了把单次采集从 30mA 降到 22mA换了传感器、改了驱动时序折腾了两周收益只有 27%后来把采集策略从定时改成事件触发收益是 80%。哪个更值一目了然。4.2 算力与模型匹配的几种常见组合在 PHY6270 这类带 MCU 内核加轻量加速单元的芯片上跑视觉推理模型规模必须卡得很死。我见过的能跑通的组合大概是这几种几十 KB 的极简 CNN 做二分类有人/没人一百多 KB 的轻量主干网络做简单目标框或者干脆不上神经网络用图像差分加形态学处理做运动检测功耗最低但误报率也最高。量化的必要性不用多说fp32 换 int8 通常能省下四分之三的模型体积和一半以上的推理时间精度损失在简单任务上一般能控制在两三个百分点。要注意的是量化要和你的训练数据分布匹配如果现场光照条件和你训练集差别大量化后的精度掉得会比 fp32 明显这时候宁可牺牲一点速度也要在片上做一次极简的归一化和白平衡。还有一个技巧把推理任务按粗筛 精判两级拆。第一级用极低分辨率的图像比如 32×32和极小的模型筛掉绝大部分无目标帧只有筛出候选才唤醒第二级做全分辨率推理。这样大部分帧的能耗在第一级就终结了平均功耗能降不少。4.3 事件触发与分级唤醒策略我实际用下来最有效的架构是三级唤醒第一级是超低功耗的模拟或简单数字检测比如 PIR、加速度计阈值中断、或者一个低功耗比较器盯着图像传感器的某一行输出。这一级常开电流控制在 3µA 以内。第二级是采集加轻量推理只在第一级触发后启动跑几十毫秒判断要不要上报。第三级是无线传输只有第二级给出肯定结果才建立连接或者发广播。这个架构的关键是每一级都要有提前退出的判断不能一条路走到黑。我见过一个设计摄像头采完了才发现内存不够、又去压缩、又去重传单次事件拖了两百多毫秒电流全浪费在半路上。合理的做法是在采集阶段就用 DMA 直接把数据搬进推理缓冲区中间不做多余的拷贝。5. 硬件落地从原理图到天线的关键细节功耗预算算完、策略定了接下来是硬件。这个阶段犯的错后期要用固件去补补得很痛苦。我把几个最容易出问题的点列一下。5.1 供电网络与去耦布局射频芯片的供电最忌讳的是走线太长、去耦电容离引脚太远。PHY6270 这类芯片的手册里通常会给出推荐的去耦网络一般是一大一小两颗电容并联容值从几十皮法到几微法不等。我建议严格按照参考设计放位置就在引脚旁边过孔尽量短。另外射频电源和数字电源要分开走中间用磁珠或者电感隔离地平面要完整。有些设计为了省空间把地平面切成几块结果射频灵敏度直接掉几分贝发射功率也上不去最后只能靠提高发射功率弥补功耗反而更高。5.2 时钟源选择与射频走线时钟源是个典型的成本与功耗权衡点。外部 32.768kHz 晶体精度高、功耗低但占 PCB 面积、加 BOM 成本内部 RC 振荡器省事但精度差、温漂大睡眠唤醒的时间误差可能到百分之几对低占空比连接来说这意味着你要更频繁地提前唤醒同步反而更耗电。我的选择是如果产品需要长时间保持连接或者做精确的时间同步用外部晶体如果只是周期性广播几个字节内部 RC 加校准够了。射频走线方面从芯片到天线要尽量短、尽量直、阻抗严格控在 50 欧姆中间不要有过孔更不要走直角。这些是老生常谈但每年还是能看到有人栽在上面。5.3 天线匹配与实测调优天线匹配网络的元件值一定要拿网络分析仪实测调不要照抄参考设计。因为你的板子尺寸、地平面大小、外壳材质都和参考板不一样匹配点会漂。我一般先按参考值贴上然后用矢量网络分析仪看回波损耗微调电容电感把谐振点调到目标频段中心。调完之后还要测实际通信距离和发射电流。有时候匹配好了、距离够了但发射电流偏大说明发射功率设太高了把功率降一档两级通信距离可能只差几米功耗却能省下不少。这个取舍在电池产品里非常值得。6. 固件实操低功耗软件架构怎么搭硬件只能决定下限能不能把功耗压到预算内最终还是看固件。我这些年最大的教训就是低功耗固件不是把能关的都关掉而是让每个模块只在真正需要的时候存在。6.1 事件驱动主循环与 tickless 调度最忌讳的是写一个 while(1) 里带 delay 的轮询主循环。哪怕 delay 里进了低功耗模式系统滴答定时器在跑你也永远睡不深。正确做法是用事件驱动加 tickless 调度没有事件时系统直接进最深睡眠有中断或者定时器到期才醒来。实现上要注意两点。第一所有外设的中断都要能在唤醒后正确恢复上下文尤其是 DMA 传输中途被睡眠打断的情况。第二睡眠前要有一份完整的关停清单把所有不需要的外设时钟、外设电源、IO 状态都处理一遍这份清单最好写成函数每次进睡眠前调用不要散在各处。6.2 协议栈参数配置代码示例下面这段是典型的连接参数配置思路用的是通用 BLE 协议栈的接口风格你在 PHY6270 上应该能找到对应的 API函数名可能不同但逻辑一致。/* 低功耗连接参数配置示例逻辑通用具体 API 请对照芯片 SDK */ #define CONN_INTERVAL_MIN 800 /* 单位 1.25ms即 1000ms */ #define CONN_INTERVAL_MAX 960 /* 即 1200ms给一点协商余量 */ #define SLAVE_LATENCY 4 /* 最多跳过 4 个连接事件 */ #define SUPERVISION_TIMEOUT 600 /* 单位 10ms即 6s必须满足 (1 latency) * interval * 2 timeout */ static void ble_conn_params_set(void) { ble_gap_conn_params_t params { .min_conn_interval CONN_INTERVAL_MIN, .max_conn_interval CONN_INTERVAL_MAX, .slave_latency SLAVE_LATENCY, .conn_sup_timeout SUPERVISION_TIMEOUT, }; /* 协商失败要用兜底参数否则连接会被对端断开 */ uint32_t err sd_ble_gap_ppcp_set(params); if (err ! NRF_SUCCESS) { /* 打印错误码走默认参数继续跑别让设备卡在这里 */ log_error(ppcp set failed: %lu, err); } } /* 数据传输完成后的主动断开策略不用保持长连接 */ static void report_then_disconnect(const uint8_t *data, uint16_t len) { send_notification(data, len); /* 等待发送完成回调再延迟一小段时间断开避免丢包 */ schedule_disconnect_after(50); }这段代码里有两个点值得展开。第一监管超时Supervision Timeout必须大于 (1 从机延迟) × 连接间隔 × 2否则主机会认为你失联并断开连接这是规范里的要求不是建议值。第二对于事件驱动的低功耗设备用上报完就断开的策略比一直保持连接省电得多代价是每次上报要重新建立连接的握手时间。如果你的上报频率低于每分钟一次断开是划算的高于每秒一次保持连接更划算。这个拐点可以用实测数据画出来。6.3 外设、DMA 与 GPIO 的低功耗用法DMA 在低功耗设计里经常被低估。用 DMA 搬数据CPU 可以在搬运期间睡觉比 CPU 轮询拷贝省得多。图像数据、串口收发、SPI 读写都应该优先考虑 DMA。GPIO 的处理前面提过这里补充一点睡眠前把所有输出引脚设成低电平除非外部电路需要高电平保持。如果外部有一个需要高电平使能的负载开关那就要看这个开关是不是必须常开能不能改成低电平使能。我有一次为了这个专门让硬件同事把负载开关从高使能改成低使能固件这边睡眠电流立刻降了 40µA。7. 功耗实测与排查从 200µA 降到 3µA 的完整过程理论算得再漂亮不实测都是空的。而实测这件事方法不对的话你测出来的数字可能完全是错的。7.1 测量方法和常见测量误差测微安级电流普通万用表基本没用因为它自身的分流和量程切换会干扰被测电路。正确的做法是用专门的功耗分析仪比如带高动态范围的电源分析设备量程要能覆盖从亚微安到几十毫安采样率至少几千赫兹能抓到射频那几毫秒的脉冲。测量时有两个坑。第一供电要用分析仪供电不要用电池再串个采样电阻因为采样电阻上的压降会让芯片工作在非正常电压测出来的电流没有意义。第二要注意分析仪的采样率和触发设置如果你的射频脉冲只有 1 毫秒而采样率只有 100Hz那你抓到的峰值是完全不准的平均值也会偏。我一般会做三次测量一次看整体平均电流一次触发抓单次射频事件看峰值和时长一次拉长时间轴看有没有周期性的异常唤醒。第三个最重要很多漏电问题都是靠长时间轴上的小毛刺发现的。7.2 常见问题速查表下面这张表是我这些年攒下来的遇到睡眠电流超标的时候按顺序排查命中率很高。现象最可能的原因排查方法处理方式深睡电流几十微安未使用 GPIO 悬空逐个把 IO 配成输出低观察电流变化睡眠前统一配置 IO 状态电流呈周期性尖峰协议栈定时器或 RTC 唤醒过于频繁拉长时间轴看尖峰间隔拉长定时周期或关闭不用的后台任务睡眠电流比手册高一个数量级调试接口未关闭对照参考设计检查 SWD/JTAG 引脚量产固件禁用调试接口待机电流随温度变化外部传感器或 Flash 未进休眠断开外设供电单独测主控用负载开关控外设供电平均电流比计算值高 30% 以上射频参数配置不当抓单次连接事件看射频时长提高 MTU、减少包数、优化连接间隔唤醒后电流不回落外设时钟未关或 DMA 未释放检查唤醒后的关停清单补全关停流程加断言检查电池电压下降后续航急剧变差DC-DC 在低电压下效率下降在不同电压点分别测电流切换到 LDO 模式或调整工作电压注意排查顺序建议从静态到动态。先在完全不工作的状态下测深睡电流确认它达标了再依次打开射频、外设、计算逐层叠加。反过来做的话问题是叠加的你很难定位是哪一层带来的。7.3 一次真实的优化迭代记录说个具体项目。板子回来第一次测平均电流 210µA预算是 40µA差了五倍多。第一步测纯深睡得到 165µA说明问题主要不在射频和计算在静态部分。先把未使用的 GPIO 全配成输出低电流降到 118µA。再看原理图发现调试串口的电平转换芯片是常供电的加了一个负载开关降到 62µA。继续查发现外部 Flash 的片选引脚睡眠时是浮空的Flash 自己进了某种半休眠状态在漏电把片选拉高之后降到 21µA。最后发现是负载开关的使能脚上有一个 100k 上拉电阻一直有 3µA 左右的漏电流把它改成由 GPIO 推挽驱动最终深睡电流 3.2µA。整个过程花了两天改了四个地方其中三个在硬件上。这件事让我后来养成一个习惯原理图评审的时候我会拿着红笔把所有常供电的节点圈出来一个一个问它为什么必须常供电。能改的当场改改不了的在固件里想办法。这个习惯帮我省掉了很多后期的调试时间。8. 选型与项目落地的一些个人经验聊到这儿如果你正在选一颗类似的芯片或者手上已经在用 PHY6270 做方案我再补一些选型和落地上的想法。8.1 选型时我实际会看的几组参数关注维度具体指标我的底线参考值说明静态功耗深睡电流小于 3µA越低越好但要看测试条件射频功耗发射峰值电流0dBm 时小于 8mA直接影响占空比功耗存储Flash / RAM512KB / 128KB 起要跑视觉推理建议翻倍算力是否带加速单元有优于无决定推理时间进而决定能耗协议栈是否支持连接参数灵活配置必须有些协议栈把参数写死了电源管理是否支持多级电源域必须决定了你能关掉多少东西开发支持SDK 与参考设计完整度有实测功耗数据没有功耗数据的要谨慎这张表里的底线参考值是经验值不是硬标准你要结合自己的场景调整。但有一条我想强调协议栈能不能灵活配置连接参数这一条极其重要。我见过一些芯片协议栈把连接间隔的调整接口封得很死或者干脆只能在初始化时设定一次这种芯片做低功耗产品会非常痛苦宁可换一颗也不要将就。8.2 踩过的坑和给你的几条建议第一条不要在项目后期才做功耗优化。功耗预算是设计输入不是验收指标。我参与过的一个项目早期没人管功耗产品定义的时候写电池续航一年以上等到样机出来发现只能撑三周这时候再改硬件要重做、结构要改、认证要重来成本是早期做的几十倍。第二条一定要做功耗回归测试。固件版本迭代的时候很容易不小心引入一个常开的定时器或者忘了关的外设平均电流就从 20µA 变成 200µA而功能测试完全测不出来。我的做法是每次持续集成就跑一次自动化的功耗采样超过阈值就报警成本很低但很管用。第三条把端侧 AI 的触发逻辑设计得保守一点。很多团队为了追求灵敏度把触发阈值调得很低结果设备一天触发几千次功耗自然下不来。实际上用户的真实需求往往是别漏掉重要事件就行而不是每一次都抓到。我在一个项目里把触发阈值调高了一档漏检率从 0.5% 升到 1.2%但平均电流降了 60%客户最后选的是后者。第四条关于蓝牙 LE 6.1 的新特性我的态度是能不用就不用除非它解决的是你当前确实存在的痛点。新技术意味着新的协议栈版本、新的兼容性测试、新的功耗不确定性。成熟产品线里稳定和低功耗永远比支持最新版本更值钱。最后说个我自己的体会做这类超低功耗系统级芯片的项目最核心的能力不是写代码也不是画板子是拆解和量化。你得能把一个模糊的需求拆成一段段可以测量、可以比较的电流和时间然后一项一项去谈、去试、去验证。PHY6270 也好别的芯片也好工具和参数都是死的能把这套方法论跑通的人换任何平台都能做出续航靠谱的产品。 
长河君 · 2026/9/18 9:57:39 · 阅读 1.2k PHY6270蓝牙LE 6.1超低功耗SoC：端侧AI视觉模块功耗设计
1. 拆开 PHY6270 这个标题一颗蓝牙 LE 6.1 超低功耗 SoC 到底卖给谁PHY6270 这个型号第一次出现在我桌面上是同组一个做工业传感器的兄弟发来的配文就一句这颗蓝牙 LE 6.1 超低功耗系统级芯片能不能扛住电池供电的端侧 AI 视觉模块。这两年被问类似问题的频率明显变高了原因也不复杂以前一颗 BLE SoC 只要负责把几个温度、湿度字节发出去就算交差现在甲方动不动就要在端点上加摄像头、加推理、加本地判断还得继续用纽扣电池供电三年不换。PHY6270 这类产品就是冲着这个矛盾来的。先说清楚它是什么。从型号命名和定位看这是一颗把 MCU 内核、蓝牙 LE 射频收发器、电源管理单元、Flash/RAM 和一堆外设集成在单硅片上的系统级芯片主打指标是超低功耗和蓝牙 LE 6.1。系统级的意思是你不需要再外挂一颗 MCU 加一颗射频芯片省掉的不只是 BOM 成本更重要的是省掉了两颗芯片之间那几条走线带来的功耗与调试麻烦。它面向的典型场景是那种插电不方便、换电池更不方便但又要长期在线、偶尔还要跑点轻量智能算法的设备。1.1 从型号命名方式看这颗芯片的产品定位大多数做低功耗无线的厂商命名习惯都差不多字母前缀代表产品家族或者工艺平台中间数字大致对应系列代际末尾数字区分存储容量或者封装。PHY6270 这种四位数字的写法通常意味着它在同一个家族里属于中高配Flash 大概率在 512KB 到 1MB 这个区间RAM 在 128KB 到 256KB 之间因为要跑端侧 AIRAM 太小根本放不下模型权重和图像缓冲区。这个定位很关键。如果你只是做个蓝牙温湿度计用不着这种规格的芯片多花的钱和多余的静态功耗都是浪费但你要在端点上做图像差分、做简单的人形检测、做异常振动识别那 RAM 和算力就是硬门槛省不得。我一般建议团队在选型时先问三个问题最大模型多大、单次推理最长多少毫秒、平均电流预算多少微安。这三个数字定了芯片档次基本就定了剩下的才是比价。1.2 超低功耗是设计目标不是参数表上的一个数字很多新人看数据手册看到睡眠电流 1.2µA就以为整机功耗就这么点这是最常见的误解。数据手册标的睡眠电流是在特定条件下测出来的某个电源模式、某些外设关闭、IO 保持特定状态、电压和温度都在典型值。你的板子上只要有一个 IO 悬空、上拉电阻没关、LDO 静态电流偏大实测就可能是它的几十倍。我在实际项目里见过太多次这种情况芯片手册写 1.5µA板子实测 180µA查了两天才发现是调试串口的电平转换芯片在漏电。所以超低功耗这四个字一半是芯片本身的功劳另一半完全取决于你的硬件设计和固件写法。PHY6270 这类芯片的价值是它把能做到的部分给足了比如多级电源域、可关闭的 RAM 保持区、自动切换的 DC-DC、射频收发时按需上电剩下的你能不能吃到看本事。1.3 什么项目该选它什么项目最好别碰我自己的判断标准很直接。适合用的电池供电、数据上报频率低秒级到分钟级、偶尔需要本地推理、对体积敏感、对成本不是极度敏感。不适合用的需要持续音频流传输、需要毫秒级硬实时闭环控制、需要大模型本地运行、对价格敏感到每分钱都要抠的量产消费电子。特别提醒一句端侧 AI 视觉模块这个方向坑不在无线在图像。很多人一开始把精力全花在蓝牙功耗调优上把平均电流从 40µA 压到 15µA结果发现摄像头一开平均电流直接跳到 900µA前面那些工作几乎白做。这个账我后面会详细算。2. 蓝牙 LE 6.1 落到板子上要关心的三件事规范版本号这件事工程上和宣传上的意义不太一样。厂商说支持蓝牙 LE 6.1对采购来说是卖点对你来说要拆成三个问题芯片的射频和协议栈固件是否真的实现了 6.1 里那些新特性、这些新特性对你的功耗曲线是正贡献还是负贡献、以及你能不能只挑其中一部分用。我见过不少项目明明用的是最基础的 1M PHY 加传统广播一样跑得很好规范版本高只是保证了向下兼容和未来可升级。蓝牙核心规范 6.0 那一版引入的东西里对工程影响最大的应该是信道探测Channel Sounding它让两颗设备之间可以做厘米级测距这对资产追踪、防丢器、无钥匙进入这类场景意义很大。6.1 在此基础上继续演进常见的关注点集中在隐私地址的随机化刷新策略、信道探测在精度和功耗之间的折中以及低占空比连接下的调度优化。具体的条款细节请以官方发布的规范文档为准我这里只讲落到代码和板子上会碰到什么。提示不要为了支持新版本而盲目开启新特性。信道探测要跑多次测量射频活动时间会明显增加如果你的产品不需要测距开着它就是白白耗电。2.1 规范演进里跟功耗真正相关的部分真正影响你电池寿命的从来不是版本号是射频占空比。射频收发时的电流量级在 4mA 到 8mA 之间具体看发射功率和接收增益而深睡眠电流在微安甚至亚微安量级。这两者差了三四个数量级所以任何射频多开 1 毫秒的改动都要拿计算器算一遍。举个例子假设你的设备每秒连接一次、每次连接事件射频活动 2 毫秒、射频期间平均电流 6mA那么射频带来的平均电流是 6mA × 2ms ÷ 1000ms 12µA。如果深睡眠电流是 2µA你的总平均电流大约 14µA。现在你把连接间隔从 1 秒改成 500 毫秒射频平均电流翻倍到 24µA总电流变成 26µA续航直接砍掉一半多。而如果你把连接间隔改成 5 秒射频平均电流降到 2.4µA总电流约 4.4µA续航能拉到三年以上。这就是为什么低功耗项目里连接参数是第一个要谈的东西而不是最后一个。2.2 连接间隔、从机延迟与 MTU 的定量影响从机延迟Slave Latency是低功耗设计里最容易被忽略的一个参数。它的作用是让从机在若干个连接事件里不回包只要主机没数据给你你就可以一直睡。假设连接间隔 100 毫秒、从机延迟 9意味着你最多可以连续跳过 9 个连接事件也就是 1 秒内只醒一次。这个参数对平均电流的影响比单纯拉长连接间隔更细腻因为它保留了必要时快速响应的能力。MTU 和包个数同样重要。每次连接事件里射频开多久取决于你要发多少数据。如果每包有效载荷 20 字节、每次要传 100 字节那就是 5 个包加上握手开销但如果你把 MTU 协商到 247 字节可能两三个包就发完了射频时间直接缩短一半。我一般的做法是先把 MTU 提到协议栈允许的较大值再用实际数据量反推包数最后拿功耗分析仪验证一遍把理论值和实测值对齐。2.3 广播、扩展广播与周期性广播的占空比选择传统广播有个硬伤单包最多 31 字节包大一点就得拆到扩展广播或者扫描响应里。扩展广播的好处是可以带更多数据、可以只发在数据信道、可以配合周期性广播。但代价是单次广播事件的射频时间变长了如果广播间隔不变平均电流反而会上升。我的经验是这样数据量小于 20 字节、只需要被手机扫到用传统广播配 1 秒到 2 秒间隔就够了数据量在 100 字节以上、需要多个接收方同时拿数据用扩展广播配周期性广播把广播间隔拉到 5 秒甚至更久让接收方自己去同步。这里面没有标准答案得拿你的实际数据量和接收方数量去试。有条件的直接上功耗分析仪跑一遍比看文档猜快得多。3. 电池能撑几年先算清楚能量预算再动手画板做电池供电产品我最怕听到的一句话是先画板子功耗后面再优化。功耗是设计出来的不是调试出来的。你应该在原理图评审之前就把能量预算表做出来每个模块每段时间占多少加起来能不能落在目标内。这张表做得越细后面返工越少。做预算的方法其实很朴素把设备的工作过程拆成几个状态每个状态测出电流和持续时间加权平均。下面我用一个典型场景完整算一遍你可以直接套这个模板。3.1 平均电流的拆项估算法假设一个用 PHY6270 做的电池供电视觉模块工作模式是这样的每 5 秒被 PIR 传感器唤醒一次摄像头采集一帧 QVGA 灰度图做一次轻量推理判断有没有目标然后把结果通过 BLE 上报。具体参数深睡眠1.8µA占绝大部分时间图像采集加推理平均 32mA持续 28ms每 5 秒一次BLE 连接上报平均 5.5mA持续 2.2ms每 1 秒一次PIR 与外围常开电路2.5µA逐项算平均电流图像与推理32mA × 28ms ÷ 5000ms 0.179mA 179µA。BLE 上报5.5mA × 2.2ms ÷ 1000ms 12.1µA。深睡眠与外围1.8 2.5 4.3µA。合计179 12.1 4.3 195.4µA。按 CR2032 标称 220mAh 可用容量实际扣除自放电和内阻损耗保守按 180mAh 算续航是 180 ÷ 0.1954 ≈ 921 小时约 38 天。这个结果对很多场景是不够的。现在做两个优化第一把推理触发从每 5 秒一次改成PIR 触发才采集且两次采集间隔至少 30 秒第二把 BLE 上报改成事件驱动平时不保持连接用广播方式每 10 秒发一次状态。重算图像与推理32mA × 28ms ÷ 30000ms 0.0299mA 29.9µA。BLE 广播传统广播单次射频约 1.1ms、平均 6mA间隔 10 秒6 × 1.1 ÷ 10000 0.66µA。深睡眠与外围4.3µA。合计约 34.9µA。续航变成 180 ÷ 0.0349 ≈ 5158 小时约 215 天七个月。你看同样是这颗芯片同样是这个功能光是把采集频率和连接方式这两件事重新设计续航差出五倍多。这就是为什么我坚持先算账。3.2 电源域与 DC-DC 的取舍很多人有误区觉得 DC-DC 一定比 LDO 省电。在重载下确实如此DC-DC 效率能到 85% 以上LDO 只有输出电压除以输入电压那点比率。但在轻载下DC-DC 的开关损耗和静态电流占比会上升效率可能掉到 40% 以下这时候 LDO 反而更划算。PHY6270 这类芯片一般会提供几种供电模式内置 DC-DC、内置 LDO、或者两者自动切换。我的做法是实测三条曲线——深睡眠电流、射频峰值电流、采集与推理时的平均电流——然后决定用哪种。通常的选择是射频和计算阶段用 DC-DC深睡眠阶段让芯片自己切到低静态电流的通路。如果芯片不支持自动切换就要看你的工作占空比占空比极低的场景用 LDO 反而更好。还有一点容易被忽略外设的供电域。摄像头、传感器、上拉电阻这些能单独用一路 GPIO 控制的负载开关供电就一定要单独控。我在一个项目里把摄像头的供电直接挂在常开电源上结果待机电流多了 60µA换成一个静态电流 0.1µA 的负载开关之后问题立刻解决。这个改动成本不到一毛钱收益却是整机续航翻倍。3.3 睡眠等级、唤醒源与深睡电流的真相深睡电流实测偏大原因通常就那几个我按出现频率排一下未使用的 GPIO 悬空或者被外部拉出漏电流、调试接口没关、外部 Flash 或传感器没进休眠、上拉/下拉电阻没关、负载开关静态电流大、晶体振荡器起振电路一直在工作。GPIO 这个最典型。芯片睡眠时引脚如果是输入悬空状态输入级的施密特触发器可能处于中间电平导致内部振荡和漏电实测能多出几十微安。正确做法是把所有未使用的引脚配成输出低或者带上拉的输入具体看你的原理图用在通信上的引脚睡眠前要配置成不会让外部器件灌电流的状态。唤醒源也要精打细算。RTC 定时唤醒最省其次是低频比较器或者 PIR 这类外部中断最费的是高频 ADC 持续采样。如果你发现设备平均电流比估算的高不少先去看唤醒源是不是太频繁或者唤醒后有没有把该关的外设全关掉。4. 端侧 AI 视觉模块的低功耗解法不是把模型变小这么简单这两年端侧 AI 视觉这个词被用得很泛从手机上的实时美颜到门铃上的人形检测都算。但电池供电的端点 AI和插电设备完全是两个游戏规则。插电设备你只需要考虑算力和延迟电池设备你要在算力、延迟、功耗三个维度里找一个可行点而且这个点往往比你想的要保守得多。我在实际项目里的体会是端侧视觉的功耗八成在图像采集一成在推理一成在数据传输。很多人上来就研究怎么把模型量化到 int8、怎么做剪枝这些都做对了也就省下那 10% 里的一部分真正的大头没动。4.1 图像采集才是功耗大头一颗 QVGA 分辨率的灰度摄像头加上驱动电路和模拟前端工作时电流通常在 15mA 到 40mA 之间具体看帧率和接口。CMOS 图像传感器的功耗大致和帧率、分辨率成正比和接口类型也有关系并口比 SPI 快但耗电更多DVP 并口在低分辨率下反而更省。假设你的采集加传输加预处理总共 30mA、耗时 25ms那么每次采集消耗的能量是 30mA × 25ms 0.75mA·s。如果每 5 秒采一次平均 150µA如果每 30 秒采一次平均 25µA如果每 5 分钟采一次平均只有 2.5µA。所以对于视觉端点第一优先级永远是降低采集频率而不是降低单次采集功耗。我当时为了把单次采集从 30mA 降到 22mA换了传感器、改了驱动时序折腾了两周收益只有 27%后来把采集策略从定时改成事件触发收益是 80%。哪个更值一目了然。4.2 算力与模型匹配的几种常见组合在 PHY6270 这类带 MCU 内核加轻量加速单元的芯片上跑视觉推理模型规模必须卡得很死。我见过的能跑通的组合大概是这几种几十 KB 的极简 CNN 做二分类有人/没人一百多 KB 的轻量主干网络做简单目标框或者干脆不上神经网络用图像差分加形态学处理做运动检测功耗最低但误报率也最高。量化的必要性不用多说fp32 换 int8 通常能省下四分之三的模型体积和一半以上的推理时间精度损失在简单任务上一般能控制在两三个百分点。要注意的是量化要和你的训练数据分布匹配如果现场光照条件和你训练集差别大量化后的精度掉得会比 fp32 明显这时候宁可牺牲一点速度也要在片上做一次极简的归一化和白平衡。还有一个技巧把推理任务按粗筛 精判两级拆。第一级用极低分辨率的图像比如 32×32和极小的模型筛掉绝大部分无目标帧只有筛出候选才唤醒第二级做全分辨率推理。这样大部分帧的能耗在第一级就终结了平均功耗能降不少。4.3 事件触发与分级唤醒策略我实际用下来最有效的架构是三级唤醒第一级是超低功耗的模拟或简单数字检测比如 PIR、加速度计阈值中断、或者一个低功耗比较器盯着图像传感器的某一行输出。这一级常开电流控制在 3µA 以内。第二级是采集加轻量推理只在第一级触发后启动跑几十毫秒判断要不要上报。第三级是无线传输只有第二级给出肯定结果才建立连接或者发广播。这个架构的关键是每一级都要有提前退出的判断不能一条路走到黑。我见过一个设计摄像头采完了才发现内存不够、又去压缩、又去重传单次事件拖了两百多毫秒电流全浪费在半路上。合理的做法是在采集阶段就用 DMA 直接把数据搬进推理缓冲区中间不做多余的拷贝。5. 硬件落地从原理图到天线的关键细节功耗预算算完、策略定了接下来是硬件。这个阶段犯的错后期要用固件去补补得很痛苦。我把几个最容易出问题的点列一下。5.1 供电网络与去耦布局射频芯片的供电最忌讳的是走线太长、去耦电容离引脚太远。PHY6270 这类芯片的手册里通常会给出推荐的去耦网络一般是一大一小两颗电容并联容值从几十皮法到几微法不等。我建议严格按照参考设计放位置就在引脚旁边过孔尽量短。另外射频电源和数字电源要分开走中间用磁珠或者电感隔离地平面要完整。有些设计为了省空间把地平面切成几块结果射频灵敏度直接掉几分贝发射功率也上不去最后只能靠提高发射功率弥补功耗反而更高。5.2 时钟源选择与射频走线时钟源是个典型的成本与功耗权衡点。外部 32.768kHz 晶体精度高、功耗低但占 PCB 面积、加 BOM 成本内部 RC 振荡器省事但精度差、温漂大睡眠唤醒的时间误差可能到百分之几对低占空比连接来说这意味着你要更频繁地提前唤醒同步反而更耗电。我的选择是如果产品需要长时间保持连接或者做精确的时间同步用外部晶体如果只是周期性广播几个字节内部 RC 加校准够了。射频走线方面从芯片到天线要尽量短、尽量直、阻抗严格控在 50 欧姆中间不要有过孔更不要走直角。这些是老生常谈但每年还是能看到有人栽在上面。5.3 天线匹配与实测调优天线匹配网络的元件值一定要拿网络分析仪实测调不要照抄参考设计。因为你的板子尺寸、地平面大小、外壳材质都和参考板不一样匹配点会漂。我一般先按参考值贴上然后用矢量网络分析仪看回波损耗微调电容电感把谐振点调到目标频段中心。调完之后还要测实际通信距离和发射电流。有时候匹配好了、距离够了但发射电流偏大说明发射功率设太高了把功率降一档两级通信距离可能只差几米功耗却能省下不少。这个取舍在电池产品里非常值得。6. 固件实操低功耗软件架构怎么搭硬件只能决定下限能不能把功耗压到预算内最终还是看固件。我这些年最大的教训就是低功耗固件不是把能关的都关掉而是让每个模块只在真正需要的时候存在。6.1 事件驱动主循环与 tickless 调度最忌讳的是写一个 while(1) 里带 delay 的轮询主循环。哪怕 delay 里进了低功耗模式系统滴答定时器在跑你也永远睡不深。正确做法是用事件驱动加 tickless 调度没有事件时系统直接进最深睡眠有中断或者定时器到期才醒来。实现上要注意两点。第一所有外设的中断都要能在唤醒后正确恢复上下文尤其是 DMA 传输中途被睡眠打断的情况。第二睡眠前要有一份完整的关停清单把所有不需要的外设时钟、外设电源、IO 状态都处理一遍这份清单最好写成函数每次进睡眠前调用不要散在各处。6.2 协议栈参数配置代码示例下面这段是典型的连接参数配置思路用的是通用 BLE 协议栈的接口风格你在 PHY6270 上应该能找到对应的 API函数名可能不同但逻辑一致。/* 低功耗连接参数配置示例逻辑通用具体 API 请对照芯片 SDK */ #define CONN_INTERVAL_MIN 800 /* 单位 1.25ms即 1000ms */ #define CONN_INTERVAL_MAX 960 /* 即 1200ms给一点协商余量 */ #define SLAVE_LATENCY 4 /* 最多跳过 4 个连接事件 */ #define SUPERVISION_TIMEOUT 600 /* 单位 10ms即 6s必须满足 (1 latency) * interval * 2 timeout */ static void ble_conn_params_set(void) { ble_gap_conn_params_t params { .min_conn_interval CONN_INTERVAL_MIN, .max_conn_interval CONN_INTERVAL_MAX, .slave_latency SLAVE_LATENCY, .conn_sup_timeout SUPERVISION_TIMEOUT, }; /* 协商失败要用兜底参数否则连接会被对端断开 */ uint32_t err sd_ble_gap_ppcp_set(params); if (err ! NRF_SUCCESS) { /* 打印错误码走默认参数继续跑别让设备卡在这里 */ log_error(ppcp set failed: %lu, err); } } /* 数据传输完成后的主动断开策略不用保持长连接 */ static void report_then_disconnect(const uint8_t *data, uint16_t len) { send_notification(data, len); /* 等待发送完成回调再延迟一小段时间断开避免丢包 */ schedule_disconnect_after(50); }这段代码里有两个点值得展开。第一监管超时Supervision Timeout必须大于 (1 从机延迟) × 连接间隔 × 2否则主机会认为你失联并断开连接这是规范里的要求不是建议值。第二对于事件驱动的低功耗设备用上报完就断开的策略比一直保持连接省电得多代价是每次上报要重新建立连接的握手时间。如果你的上报频率低于每分钟一次断开是划算的高于每秒一次保持连接更划算。这个拐点可以用实测数据画出来。6.3 外设、DMA 与 GPIO 的低功耗用法DMA 在低功耗设计里经常被低估。用 DMA 搬数据CPU 可以在搬运期间睡觉比 CPU 轮询拷贝省得多。图像数据、串口收发、SPI 读写都应该优先考虑 DMA。GPIO 的处理前面提过这里补充一点睡眠前把所有输出引脚设成低电平除非外部电路需要高电平保持。如果外部有一个需要高电平使能的负载开关那就要看这个开关是不是必须常开能不能改成低电平使能。我有一次为了这个专门让硬件同事把负载开关从高使能改成低使能固件这边睡眠电流立刻降了 40µA。7. 功耗实测与排查从 200µA 降到 3µA 的完整过程理论算得再漂亮不实测都是空的。而实测这件事方法不对的话你测出来的数字可能完全是错的。7.1 测量方法和常见测量误差测微安级电流普通万用表基本没用因为它自身的分流和量程切换会干扰被测电路。正确的做法是用专门的功耗分析仪比如带高动态范围的电源分析设备量程要能覆盖从亚微安到几十毫安采样率至少几千赫兹能抓到射频那几毫秒的脉冲。测量时有两个坑。第一供电要用分析仪供电不要用电池再串个采样电阻因为采样电阻上的压降会让芯片工作在非正常电压测出来的电流没有意义。第二要注意分析仪的采样率和触发设置如果你的射频脉冲只有 1 毫秒而采样率只有 100Hz那你抓到的峰值是完全不准的平均值也会偏。我一般会做三次测量一次看整体平均电流一次触发抓单次射频事件看峰值和时长一次拉长时间轴看有没有周期性的异常唤醒。第三个最重要很多漏电问题都是靠长时间轴上的小毛刺发现的。7.2 常见问题速查表下面这张表是我这些年攒下来的遇到睡眠电流超标的时候按顺序排查命中率很高。现象最可能的原因排查方法处理方式深睡电流几十微安未使用 GPIO 悬空逐个把 IO 配成输出低观察电流变化睡眠前统一配置 IO 状态电流呈周期性尖峰协议栈定时器或 RTC 唤醒过于频繁拉长时间轴看尖峰间隔拉长定时周期或关闭不用的后台任务睡眠电流比手册高一个数量级调试接口未关闭对照参考设计检查 SWD/JTAG 引脚量产固件禁用调试接口待机电流随温度变化外部传感器或 Flash 未进休眠断开外设供电单独测主控用负载开关控外设供电平均电流比计算值高 30% 以上射频参数配置不当抓单次连接事件看射频时长提高 MTU、减少包数、优化连接间隔唤醒后电流不回落外设时钟未关或 DMA 未释放检查唤醒后的关停清单补全关停流程加断言检查电池电压下降后续航急剧变差DC-DC 在低电压下效率下降在不同电压点分别测电流切换到 LDO 模式或调整工作电压注意排查顺序建议从静态到动态。先在完全不工作的状态下测深睡电流确认它达标了再依次打开射频、外设、计算逐层叠加。反过来做的话问题是叠加的你很难定位是哪一层带来的。7.3 一次真实的优化迭代记录说个具体项目。板子回来第一次测平均电流 210µA预算是 40µA差了五倍多。第一步测纯深睡得到 165µA说明问题主要不在射频和计算在静态部分。先把未使用的 GPIO 全配成输出低电流降到 118µA。再看原理图发现调试串口的电平转换芯片是常供电的加了一个负载开关降到 62µA。继续查发现外部 Flash 的片选引脚睡眠时是浮空的Flash 自己进了某种半休眠状态在漏电把片选拉高之后降到 21µA。最后发现是负载开关的使能脚上有一个 100k 上拉电阻一直有 3µA 左右的漏电流把它改成由 GPIO 推挽驱动最终深睡电流 3.2µA。整个过程花了两天改了四个地方其中三个在硬件上。这件事让我后来养成一个习惯原理图评审的时候我会拿着红笔把所有常供电的节点圈出来一个一个问它为什么必须常供电。能改的当场改改不了的在固件里想办法。这个习惯帮我省掉了很多后期的调试时间。8. 选型与项目落地的一些个人经验聊到这儿如果你正在选一颗类似的芯片或者手上已经在用 PHY6270 做方案我再补一些选型和落地上的想法。8.1 选型时我实际会看的几组参数关注维度具体指标我的底线参考值说明静态功耗深睡电流小于 3µA越低越好但要看测试条件射频功耗发射峰值电流0dBm 时小于 8mA直接影响占空比功耗存储Flash / RAM512KB / 128KB 起要跑视觉推理建议翻倍算力是否带加速单元有优于无决定推理时间进而决定能耗协议栈是否支持连接参数灵活配置必须有些协议栈把参数写死了电源管理是否支持多级电源域必须决定了你能关掉多少东西开发支持SDK 与参考设计完整度有实测功耗数据没有功耗数据的要谨慎这张表里的底线参考值是经验值不是硬标准你要结合自己的场景调整。但有一条我想强调协议栈能不能灵活配置连接参数这一条极其重要。我见过一些芯片协议栈把连接间隔的调整接口封得很死或者干脆只能在初始化时设定一次这种芯片做低功耗产品会非常痛苦宁可换一颗也不要将就。8.2 踩过的坑和给你的几条建议第一条不要在项目后期才做功耗优化。功耗预算是设计输入不是验收指标。我参与过的一个项目早期没人管功耗产品定义的时候写电池续航一年以上等到样机出来发现只能撑三周这时候再改硬件要重做、结构要改、认证要重来成本是早期做的几十倍。第二条一定要做功耗回归测试。固件版本迭代的时候很容易不小心引入一个常开的定时器或者忘了关的外设平均电流就从 20µA 变成 200µA而功能测试完全测不出来。我的做法是每次持续集成就跑一次自动化的功耗采样超过阈值就报警成本很低但很管用。第三条把端侧 AI 的触发逻辑设计得保守一点。很多团队为了追求灵敏度把触发阈值调得很低结果设备一天触发几千次功耗自然下不来。实际上用户的真实需求往往是别漏掉重要事件就行而不是每一次都抓到。我在一个项目里把触发阈值调高了一档漏检率从 0.5% 升到 1.2%但平均电流降了 60%客户最后选的是后者。第四条关于蓝牙 LE 6.1 的新特性我的态度是能不用就不用除非它解决的是你当前确实存在的痛点。新技术意味着新的协议栈版本、新的兼容性测试、新的功耗不确定性。成熟产品线里稳定和低功耗永远比支持最新版本更值钱。最后说个我自己的体会做这类超低功耗系统级芯片的项目最核心的能力不是写代码也不是画板子是拆解和量化。你得能把一个模糊的需求拆成一段段可以测量、可以比较的电流和时间然后一项一项去谈、去试、去验证。PHY6270 也好别的芯片也好工具和参数都是死的能把这套方法论跑通的人换任何平台都能做出续航靠谱的产品。