2026/9/18 4:22:01
FEATURED · 精选文章 
1. 墨水屏的功耗账本静态几乎为零动态才是大头拿到功耗极低的电子墨水屏还支持 WiFiBLE 双无线连接这个题目时很多人第一反应是墨水屏本身就省电加上无线就更香了。这个理解只对了一半。真正做过这类产品的人会发现墨水屏的省电优势其实建立在一种非常特殊的物理机制上而一旦叠加了双无线省电的锅就从屏幕转移到了射频和系统睡眠策略上。我前后做过三个墨水屏类的项目从最早的电子价签到后来的桌面信息牌踩过的坑足够写一本小册子。这篇就把墨水屏 WiFi BLE 这套组合的功耗逻辑、共存细节和实操参数一次性讲透。适合阅读这篇的人包括正在规划低功耗显示终端的硬件工程师、写嵌入式固件的开发者、以及想自己动手做一个一年不用充电的桌面小屏的爱好者。无论你手上是 ESP32 系列、还是 nRF52 系列、还是双芯片架构下面的账本算法和参数取舍都能直接套用。1.1 双稳态显示像素断电后自己记住状态墨水屏和 LCD、OLED 最本质的区别在于它的像素是双稳态的。微胶囊里的黑白带电粒子在电场作用下移动到顶部或底部之后撤掉电场粒子依然停在那里——因为它靠的是范德华力和内部粘滞介质的束缚而不是靠持续供电维持状态。这个特性带来的直接后果是显示静态画面时屏幕的功耗真的是 0不是接近 0是字面意义上的零电流。LCD 背光要一直亮OLED 每个像素要一直维持驱动电流而墨水屏画完就可以彻底断掉驱动电路连驱动 IC 的升压电路都关掉。所以当你看到某款墨水屏标签号称电池能用五年它的算法逻辑大致是这样的屏幕静态功耗0主控睡眠功耗530µA射频待机功耗按策略不同几十µA 到几百µA刷新瞬间的功耗被刷新次数摊薄到几乎可忽略关键就在第三行。墨水屏只是把屏幕这一项从功耗预算里删掉了剩下的账还是要 MCU 和无线来还。很多人做方案时被墨水屏省电这个印象带偏把所有精力放在选屏上结果板子做出来待机 300µA一年都撑不到回头一看是 LDO 静态电流和上拉电阻在偷电。1.2 一次刷新到底花掉多少毫安时我们算一笔具体的账。以常见的 2.13 寸 122×250 单色屏SSD1680 驱动为例一次全屏刷新full refresh的大致波形是这样的升压电路先把电压泵到 ±15V 左右然后按照波形 LUT 逐行驱动整个过程约 1.82.2 秒。在这两秒里3.3V 侧的瞬时电流大约 1020mA峰值可能冲到 30mA取决于屏尺寸和升压电容。那么一次刷新的电量消耗是20mA × 2.0s 40mA·s 40 / 3600 mAh ≈ 0.011 mAh假设你是一个桌面日历每天刷新 4 次早中晚加一次状态更新0.011 mAh × 4 0.044 mAh/天一颗 CR2477 纽扣电池容量约 1000mAh光刷屏能撑1000 / 0.044 ≈ 22727 天这就是墨水屏省电的底气——刷屏本身根本不是瓶颈你可以把刷新次数提高十倍账面上依然毫无压力。但有几个坑必须注意局部刷新partial refresh比全刷省但不是线性关系。局部刷新的耗电主要来自升压电路的建立和若干行的驱动面积小了但固定开销还在。实测同一块 2.13 寸屏全刷 2.0s 约 20mA局部刷新 0.4s 约 18mA——时间短了 5 倍电流几乎没变因为大头是升压和固定时序。不刷新的部分不是免费的。如果你连续做几十次局部刷新会出现残影ghosting必须定期插一次全刷清屏。三色屏黑白红的刷新时间是灾难级的。同样尺寸可能需要 1520 秒瞬时电流也更高如果你的场景需要红色告警功耗预算要重新算。1.3 温度补偿与波形 LUT最容易被忽略的隐形开销这一条是新手最容易翻车的地方。墨水屏的驱动波形不是固定的它是温度相关的。驱动 IC 内部一般会存好几组波形 LUT按照温度区间切换比如 010℃、1025℃、2540℃ 各一套。原因是低温下粒子运动变慢需要更多帧、更长的高压时间来推动否则就会出现刷新不干净、对比度下降的问题。问题来了大部分驱动 IC 自己不带温度传感器。你得外挂一颗 I2C 温度传感器比如常见的低功耗数字温度传感器待机电流 1µA 以内在每次刷新前读一次温度然后选择对应的 LUT 或者调整波形参数。如果省略这一步会发生什么我实测过在 5℃ 的房间里用常温 LUT 刷同一张图黑白对比明显变差而且刷新后残留半透明的旧画面。更麻烦的是在 0℃ 以下某些屏会直接刷新失败画面停在中间状态。外挂温度传感器的代价很小——一颗 1µA 静态电流的传感器一天被读 4 次每次读 5ms摊下来电流贡献约 0.0000002mA可以完全忽略。这个成本一定要花。另外还有一个隐形成本如果你需要频繁读温度就不要让传感器一直上电。用 MOS 管控制传感器的电源读完就断可以避免它在待机时持续消耗。不过要注意很多数字传感器上电后需要 12ms 的稳定时间别读太急。2. WiFi 与 BLE 同时存在的必要性不是堆料是分工很多第一次接触这类方案的人会问既然有 WiFi 了为什么还要 BLE反过来既然 BLE 够省电为什么还要 WiFi 这个问题问得很到位。答案不是两个都要更牛逼而是两者承担的职责完全不同单独任何一个都会导致方案在某个维度上崩掉。2.1 BLE 做常驻哨兵低占空比的近场唤醒BLE 的角色是永远在线但极低占空比的监听者。一个典型的 BLE 广播配置广播间隔 1000ms发射功率 0dBm在 37/38/39 三个广播信道上轮流发送。每次广播事件的总射频开启时间大约 11.5ms峰值电流取决于芯片nRF52840 在 0dBm 发射时约 4.6mA广播事件加上唤醒开销1 秒间隔下的平均电流可以做到2560µA含 System ON 睡眠。ESP32-C3 的 BLE 峰值电流高得多广播瞬时可能到 2030mA1 秒间隔的平均电流大概在120350µA。这个差距解释了为什么追求极致待机的方案会用 nRF52 系列来做 BLE 侧。BLE 在这里的具体工作有三件被手机发现。手机 App 扫描到广播建立连接把要显示的内容图片、日程、天气推过来。被固定网关发现。在电子价签场景里货架上的基站周期性扫描广播里携带标签 ID基站决定要不要给它推新价格。唤醒主控。这是最关键的一条。BLE 侧收到有新内容的信号后拉高一个 GPIO把深度睡眠中的主控叫醒主控再去开 WiFi 干活。BLE 广播的另一个好处是不需要配对就能被发现。你可以把部分信息直接塞进广播报文里比如 31 字节的广播数据里放设备状态、电量、当前显示页号手机扫一下就能看到连连接都不需要建立功耗又低了一截。2.2 WiFi 做搬运工一次性把图和字全拉下来WiFi 的价值在于吞吐量和直达性。一张 800×480 的黑白图1 位色深未压缩是 48000 字节压缩后大概 815KB如果带灰度或者多色可能上百 KB。用 BLE 传 15KB在 1M PHY、连接间隔 30ms 的条件下考虑到协议开销和丢包重传实际有效速率往往只有 515KB/s传完要好几秒甚至十几秒。而 WiFi 一旦连上几秒钟内把 100KB 拉下来毫无压力。更重要的是WiFi 可以直接访问 HTTP 接口、MQTT 服务器不需要中间网关。BLE 要上网必须有手机或网关做代理这在很多场景里是硬伤——你不可能要求用户的手机一直开着 App。WiFi 可以跑 TLS。内容来源如果有鉴权要求BLE 那条链路要么依赖手机的凭证要么协议自己做加密都更麻烦。WiFi 的会话是短促爆发型的。连上、DHCP、拉数据、断开整个过程 610 秒平均电流 80120mA算下来的电量消耗大概 0.150.3mAh。每天做 4 次一天 1mAh 左右1000mAh 的电池能撑三年。2.3 只留一种无线会怎样两种失败方案复盘方案 A只留 BLE。表面上待机电流极低能到 30µA 级别一年耗电只有 0.26mAh × 365 ≈ 95mAh非常漂亮。但问题是内容从哪来如果依赖手机 App用户必须每次手动靠近、打开 App、等待传输。在桌面日历这类场景里用户希望我早上起来它自己就更新了纯 BLE 做不到。如果加网关成本直接翻倍而且网关还得一直上电。方案 B只留 WiFi。那就要面对一个残酷的数字ESP32 保持 WiFi 连接、开启 Modem-sleep、DTIM3 的情况下平均电流约 12mA。1000mAh 电池1000mAh / 1.5mA ≈ 666 小时 ≈ 27 天一个月一充这已经不能叫功耗极低了。就算把 DTIM 调到 10降到 0.5mA 左右也就撑 80 天。而且 WiFi 常连还带来一个问题路由器侧会维护大量长连接网络环境一变换 SSID、密码、路由器重启就要重新配网用户体验很差。双无线的真正价值就在这里BLE 用极低的成本维持永远可被唤醒WiFi 只在真正需要搬数据的那几秒里被点亮。两者是串联关系不是并联关系。想明白这一点整个低功耗架构的设计思路就通了。无线方式典型平均电流适合承担的任务不适合承担的任务BLE 广播1s 间隔25350µA 视芯片常驻监听、近场发现、唤醒信号、小数据配置大文件传输、直接访问互联网BLE 已连接1s 间隔30200µA参数下发、固件小补丁、状态回传图片传输、长时间数据流WiFi 已连接Modem-sleepDTIM312mA需要长连接推送的场景如 MQTT电池供电、追求年级别续航WiFi 按需连接每次 610s摊薄后 0.05mA大内容下载、HTTPS 拉取、OTA需要毫秒级响应的场景3. 单天线共存WiFi 和 BLE 抢频段的那些细节WiFi 工作在 2.4GHz 的 113 信道BLE 在 2.4022.480GHz 的 40 个信道上跳频其中 37/38/39 是广播信道。两者物理上共享同一段频谱如果共用一个天线就必须分时使用。3.1 时分复用的底层逻辑与仲裁机制单芯片双模方案比如 ESP32 系列、部分 Combo 芯片内部有一个共存仲裁器大致逻辑是射频前端只有一套任何时刻只能有一个协议在用。BLE 的事件广播、连接事件有严格的时间窗要求错过就可能丢包或断连。WiFi 的收发相对宽松一些但 beacon 接收也有周期约束。仲裁器会给 BLE 更高的优先级因为 BLE 的时间窗更紧WiFi 的发送被推迟。这就导致一个现象当 BLE 连接间隔设置得比较密同时 WiFi 在传大文件时WiFi 的吞吐会明显下降。我实测过一组数据用某款 ESP32 系列芯片BLE 连接间隔 30ms同时跑 WiFi TCP 下载BLE 连接间隔WiFi 吞吐无 BLEWiFi 吞吐BLE 同时连接下降幅度关闭 BLE12.5 Mbps——100ms12.5 Mbps10.8 Mbps-14%30ms12.5 Mbps7.2 Mbps-42%15ms12.5 Mbps4.1 Mbps-67%结论很直白如果你的方案是单芯片 单天线就不要让 BLE 和 WiFi 同时高强度工作。正确做法是错开——BLE 负责唤醒唤醒后先断开 BLE 连接或者把连接间隔临时拉大到 500ms 以上再开 WiFi 拉数据数据拉完关 WiFi恢复 BLE 连接。如果你真的需要两者并存且都要性能那就上双天线 外部共存信号coexistence或者干脆用双芯片架构让 BLE 和 WiFi 跑在两颗芯片上各自独立天线。前者成本增加有限后者增加更多但架构更干净。3.2 连接间隔、广播间隔与信道避让的参数取值参数不是随便填的下面这几个取值是我反复调过的经验值BLE 广播间隔8001200ms。低于 500ms功耗上升明显但发现速度提升有限高于 2000ms手机扫描时可能等好几秒才看到设备体验变差。1000ms 是个很好的平衡点。BLE 连接间隔连接态用 100500ms空闲时用 10002000ms。可以用连接参数更新请求Connection Parameter Update动态调整。手机侧通常有最小间隔限制iOS 上常见的最小值是 15ms但你不该用那么小。Slave Latency能开就开。从设备延迟slave latency允许从机跳过若干个连接事件不应答。设 slave latency 4、连接间隔 200ms意味着从机实际每 1 秒才醒一次。这个参数对功耗的影响比连接间隔还大。WiFi DTIM按需设置。DTIM 越大设备醒来越少越省电但下行数据的延迟越大。按需连接的方案里DTIM 意义不大因为连接时间本来就短。WiFi 信道避让尽量让路由器避开 BLE 广播信道所在的频段。BLE 的 37/38/39 分别对应 2402、2426、2480MHz大致落在 WiFi 的 1 信道尾部和 13 信道附近。如果你的 AP 可以固定信道选 6 或者 11 会稍微好一点点虽然提升有限但聊胜于无。有一个细节很多人不知道BLE 的连接事件里如果从机在若干个事件里都没数据要发它会直接关闭射频进入睡眠。所以你在固件里应该尽量避免在连接态下无意义地周期性发心跳包那会让功耗翻好几倍。3.3 实测数据共存前后的丢包与功耗对比我把两组配置跑了一遍用同样的硬件、同样的 1000mAh 电池模型持续 24 小时配置BLE 广播平均电流WiFi 会话次数/天单次会话耗电日耗电合计预估续航单芯片BLE 广播 1s WiFi 按需约 180µA4 次0.25mAh4.32 1.0 5.32mAh约 188 天双芯片BLE 端 1s 广播主控断电约 45µA4 次0.25mAh1.08 1.0 2.08mAh约 480 天单芯片WiFi 常连 DTIM3—常连—36mAh约 27 天注意上表的电流数字是基于常见芯片的实测区间给出的参考值具体到你的板子会因为 LDO、外围器件、天线效率而上下浮动务必以实测为准。表格的意义在于对比量级而不是绝对值。这张表最值得琢磨的地方是双芯片方案把日耗电从 5.32mAh 压到 2.08mAh续航翻了 2.5 倍但成本增加了一颗 BLE SoC 和一小块 PCB 面积。这个取舍在量产里面很常见——如果你的产品定位是三年免维护那 2.5 倍的续航差距就是决定性的。4. 固件层低功耗设计把电流压到微安级的四步硬件给了你一个 30µA 的地板固件做不好照样待机 500µA。下面是我总结的一套实操路径。4.1 分级睡眠从 Modem-sleep 到 Deep-sleep 的取舍低功耗不是只有醒和睡两种状态而是一个阶梯模式保留什么唤醒源典型电流唤醒时间Active全部外设、CPU 全速—2080mA—Light-sleepRAM 保持、外设时钟可关任意中断0.31mA含 BLE 活动 1msDeep-sleepRTC 域 少量 RTC RAMRTC 定时器、RTC GPIO、触摸530µA几毫秒到几百毫秒Hibernation / System OFF极少量寄存器复位、特定引脚 1µA相当于重新启动选择逻辑很简单BLE 广播期间必须用 Light-sleep因为要保持射频和定时器工作。不需要 BLE 的时间段比如晚上 23:00 到早上 06:00可以彻底进 Deep-sleep只留 RTC 定时器在早上把自己叫醒。这一招能省掉近一半的日均功耗。只有在需要搬运数据的那几秒才进 Active。一个容易忽略的点Deep-sleep 唤醒后很多外设状态会丢失比如 SPI 配置、屏幕驱动 IC 的寄存器。如果你每次醒来都要重新初始化屏幕驱动那几十毫秒的初始化就有意义了。我的做法是把屏幕状态和当前显示内容记在 RTC RAM 里醒来先判断内容没变就不刷屏只做网络同步。4.2 一次完整唤醒链路的时序拆解下面这段是伪代码式的时序你可以对照自己的固件检查有没有多余的步骤[BLE 广播中Light-sleep] ↓ 收到连接请求或私有广播指令 [BLE 连接建立] ↓ 手机/网关下发 { need_sync: true, url: ... } [从机应答记录任务] ↓ 断开发射拉高 GPIO 唤醒主控 [主控从 Deep-sleep 唤醒约 150ms 启动] ↓ 初始化 SPI、屏幕驱动读 RTC RAM 判断是否需要刷屏 [打开 WiFi 电源连接 AP] ↓ 连接 DHCP ≈ 2.54s [HTTPS 拉取内容 ≈ 13s视内容大小] ↓ 校验、写 Flash 缓存 [驱动墨水屏刷新 ≈ 0.42s] ↓ 关闭 WiFi 电源主控回到 Deep-sleep [BLE 恢复广播]整个链路的关键优化点有三个不要每次唤醒都重连 WiFi。把 SSID、密码、甚至 IP 配置存起来如果 AP 没变、信号还在直接连接能省掉 DHCP 的 12 秒。更进一步如果只是拉一小段数据可以用静态 IP 跳过 DHCP。内容要缓存。拉到新内容先写 SPI Flash刷屏从 Flash 读。这样即使刷屏过程中断电重启后还能恢复上一个画面也不会白跑一次网络。把 BLE 和 WiFi 的时间段彻底错开。前面算过单天线共存时 WiFi 吞吐会掉 40% 以上而 WiFi 在线时间越长平均电流越高。错开之后WiFi 那几秒能跑满速率。4.3 双芯片架构让 BLE 协处理器替主控值班如果你的产品需要年级别续航我强烈建议考虑双芯片方案。分工是这样的BLE 芯片如低功耗 BLE SoC常驻运行负责广播、连接、收指令、控制主控电源。它只在收到任务时才把主控拉起来平时主控的电源是被 MOS 管切断的静态电流接近 0。主控芯片如带 WiFi 的 MCU平时完全断电醒来后做 WiFi 通信和屏幕刷新。这样做的直接收益是待机电流由 BLE 芯片决定而不是由带 WiFi 的芯片决定。前面那张表已经说明了差距45µA vs 180µA日耗电差 3 倍多。代价也是很实在的硬件成本增加一颗 SoC、一颗晶振、一套电源域。固件复杂度上升两个芯片之间的通信协议要设计好推荐用 UART 简单的帧协议或者 SPI 中断引脚。PCB 面积变大如果你的产品是 30mm × 40mm 的标签可能放不下。判断标准如果目标是 1 年以内续航单芯片方案足够如果目标 2 年以上或者电池容量小于 400mAh双芯片方案更划算。5. 硬件侧的低功耗细节漏电往往比工作电流更致命固件再优化硬件漏电也能把一切努力抹平。我见过最夸张的案例固件待机电流 15µA整机测出来 380µA最后发现是 USB 转串口芯片没断电。5.1 供电架构与电池选型先选电池再设计供电顺序不能反。电池类型标称容量特点适用场景CR2450 纽扣约 600mAh便宜、体积小、不可充电子价签、极简信息牌CR2477 纽扣约 1000mAh容量大、厚度增加需要长续航的标签两节 AAA约 1000mAh可用易更换、体积大桌面设备、可维护场景锂聚合物 500mAh约 500mAh可充电、放电曲线平缓需要频繁刷新的场景锂亚硫酰氯约 20002600mAh自放电极低、脉冲电流弱超长待机但要注意瞬时电流能力锂亚硫酰氯Li-SOCl2这条要特别说一下它的自放电率极低每年 1% 以内理论上非常适合这类设备但它的脉冲放电能力弱墨水屏刷新时瞬间要 30mA可能会把电压拉垮导致复位。如果要用必须在旁边并一颗大电容做缓冲或者选脉冲型如带 HPC 混合层电容的型号。供电架构上主流做法是电池 → 超低静态电流 LDO → 3.3V 主电源 ├─→ 常开域BLE 芯片若有、RTC └─→ 受控域屏幕驱动、传感器、USB 芯片MOS 管控制LDO 的静态电流一定要看数据手册的Ground Current / Quiescent Current这一项不是看 Dropout。常见的超低静态 LDO静态电流可以做到 25nA 到 1µA 级别。如果你随手选了一颗 5mA 静态电流的型号那待机功耗直接从微安级跳到毫安级前面的所有努力全都白费。5.2 那些把待机电流从 30µA 拉到 300µA 的元凶下面这份排查清单是我用血泪换来的建议直接收藏第一类通信芯片的隐性功耗。USB 转串口芯片是重灾区某些型号工作电流就有几毫安就算不插 USB 也在耗电。量产板上一定要用 MOS 管或者干脆不装调试用飞线解决。第二类上拉电阻的反向漏电。I2C 总线上有 4.7kΩ 上拉到 3.3V 的电阻如果从设备的电源被 MOS 管切断了电流就会通过上拉电阻倒流进芯片的 IO 保护二极管形成一条持续的漏电通路。4.7kΩ 上的电流(3.3V - 0.6V) / 4.7kΩ ≈ 0.57mA这已经比整机待机电流大 20 倍了。解决办法把上拉电阻改到 100kΩ代价是速率下降400kHz 高速 I2C 可能不适用或者把上拉电阻的供电也接到受控电源域上。第三类MOS 管的栅极浮空。用 MOS 管做电源开关时如果控制 IO 在 MCU 睡眠后变成高阻态栅极电压不确定MOS 管可能处于半导通状态那漏的就是一大片。控制 IO 要配置成推挽输出并保持低电平或者加一颗 100kΩ 下拉电阻。第四类墨水屏的未使用引脚。屏幕不刷新的时候驱动 IC 的 SPI 引脚、BUSY 引脚如果没有明确处理可能通过屏内部的保护结构漏电。建议在睡眠前把 SPI 引脚配置成低电平输出或高阻BUSY 引脚的上拉如果必须加选大阻值。第五类传感器和 RTC。有些温度传感器、加速度计在默认配置下是周期采样模式静态电流能到 50100µA。上电后第一件事就是把它们配置成单次测量模式One-Shot测完自动回睡眠。6. 落地场景差异电子价签、桌面信息牌、电子日历不是一套参数同一个硬件平台换个场景参数就得重调。下面是我做过的三类场景的差异总结。6.1 电子价签刷新少、延迟容忍度高电子价签的特点非常鲜明一天可能只刷 15 次而且晚几秒钟刷新完全无所谓。这类产品的设计重点不是快而是省和可靠。广播间隔可以放到 2000ms 甚至更长因为价签不需要被手机发现只需要被基站扫到。显示内容以数字和简单文字为主可以用局部刷新一次 300500ms。网络策略上很多方案干脆不用 WiFi用 2.4GHz 私有协议或者 BLE 网关因为数据量小几十字节BLE 完全够用。但我在这个场景踩过一个坑基站和价签的时钟不同步导致的广播丢包。如果几百个标签的广播间隔完全相同它们在时间上会持续对齐某些信道会周期性拥塞。解决办法是给每个标签的广播间隔加一个随机抖动比如 1000ms ± 150ms让广播事件在时间上打散。这个改动几乎没有成本但能显著提升首次扫描成功率。6.2 桌面信息牌刷新频繁、要能局部刷新桌面信息牌是个人用户最爱做的形态——显示天气、日程、股票、待办事项。这类设备的刷新频率高得多可能每 15 分钟到 1 小时就要更新一次而且内容里有图表、小图标需要灰度或者至少是细腻的抖动处理。关键差异刷新频率高意味着残影问题突出。我的做法是每 8 次局部刷新插一次全刷或者干脆按时间算每 6 小时全刷一次清底。WiFi 会话次数多。每天 24 次会话每次 0.25mAh一天就是 6mAh1000mAh 电池只能撑 166 天。这时候要么降低刷新频率要么把内容源合并——一次拉取多个信息源的数据减少会话次数。考虑用长连接换短连接。如果刷新频率高到每 15 分钟一次那不如保持 WiFi 连接但把 DTIM 调到最大。1mA × 24h 24mAh/天比 24 次短会话的 6mAh 差很多所以还是短连接更优。这个结论在我实测之前是反直觉的但数字不会骗人。6.3 电子日历/待办屏日更一次的网络策略这类产品最极端一天只刷一次续航可以做到非常夸张。设计上的自由度和特殊注意点可以把 WiFi 彻底断电。用 RTC 定时器每天早上 7:00 唤醒主控重连 WiFi拉数据刷屏然后回到 Deep-sleep。系统里根本没有保持在线这个概念。配网怎么办只能是首次配网或者网络变化时通过 BLE 把 SSID 和密码写进去。所以 BLE 侧要保留一个配网模式的入口比如长按按键 3 秒后进入广播 可连接状态。时区与夏令时。这是个软件问题但很容易翻车。RTC 只走 UTC本地时间靠时区偏移换算。如果时区规则变了有些地区会调整夏令时你得有个机制能通过 BLE 或 WiFi 更新时区表。这类产品的实测数据日耗电 1.5mAh 左右1000mAh 电池可以撑 600 天以上接近两年。如果换成双芯片架构能上到 1000 天以上。7. 调试与量产验证怎么把功耗数字测准最后聊聊测量和验证。这一块看着简单实际上巨大比例的团队在这里得到过错误的数字并基于错误数字做了错误决策。7.1 用万用表测不出真实功耗的原因普通万用表的电流档有两个致命问题采样率太低。大部分手持表的刷新率只有每秒几次而 BLE 广播的电流是1ms 高、999ms 低的脉冲。它会看到一个平均值但那个平均值可能因为采样窗口对齐问题而严重失真。内阻太大。万用表电流档的取样电阻可能有几欧姆到几十欧姆在 100mA 峰值时会产生显著的压降导致设备欠压复位或者行为异常。你测到的其实是一个被万用表影响过的系统。我的建议方案短时间高精度测量用带高采样率至少 10kHz的电流探头或专业功耗分析仪能看清每个脉冲的形状。长时间平均测量用一颗大电容比如 1000µF并联在电池两端万用表串在电池和电路之间电容起到积分器的作用能把脉冲电流平滑成接近真实的平均值。这个方法精度有限但非常便宜适合做长期的趋势观察。替代方案用库仑计芯片自带电流累加器做长时间电量统计直接读累计电荷比读瞬时电流可靠得多。7.2 一套可复现的功耗验收流程我在项目里固定跑这套流程每次固件修改后都要重跑步骤操作观察指标合格标准1拔掉所有调试线只留电池静态电流 30µA2关闭 BLE 广播只留 RTC深度睡眠电流 15µA3打开 BLE 广播1s 间隔平均电流 200µA单芯片/ 60µA双芯片4触发一次完整的 WiFi 同步 刷屏过程总电荷 0.4mAh5连续 24 小时跑真实业务逻辑累计电量与预估误差 20%6静置 72 小时不触发任何任务累计电量 0.5mAh/天第 6 步特别重要它能暴露定时器泄漏这类问题——比如某个任务忘了关每隔几秒就醒一次。7.3 上线前必须跑的三类异常场景功能和功耗都调好之后还要跑异常场景因为现场环境远比实验室恶劣第一类WiFi 连接失败。把 AP 关机或者把 SSID 改错观察设备是否会在重试里无限循环。必须有超时和退避机制——重试 3 次失败就放弃进入低功耗等待下一个周期再试。我见过一个固件因为没做退避在 AP 宕机时每 2 秒重连一次一天就把电池耗去一半。第二类BLE 连接被异常断开。手机走到范围外、或者 App 被杀BLE 连接会以各种方式断开。要确保断开事件能正确回收资源、恢复广播而不是卡在某个中间状态等死。第三类低温和高温。墨水屏在低温下刷新变慢电池在低温下内阻升高、可用容量下降。如果产品要在户外使用最好在 -10℃ 和 50℃ 各跑一遍完整流程看看有没有刷新失败、有没有因为电压跌落而复位。提示低功耗设备的现场故障八成不是硬件坏了而是某个状态机卡住了。养成习惯给每个状态加一个看门狗超时卡住就无条件复位回初始态。这条经验帮我救回过不止一个已经发到客户手上的项目。最后分享一个我自己一直在用的小技巧在固件里留一个功耗诊断模式通过 BLE 触发后设备会把最近 24 小时的唤醒次数、每次唤醒的原因、累计联网时间、刷屏次数打包回传。这个数据在排查现场问题时比任何串口日志都有用因为它不需要拆机、不需要夹具只要一台手机就能拿到设备的工作履历。我在第二个项目里加上这个功能之后现场问题的定位时间从平均两天缩短到了半小时强烈建议你也在设计初期就把这个埋点留出来。
墨水屏+WiFi+BLE双无线低功耗设计：功耗账本与工程实践
1. 墨水屏的功耗账本静态几乎为零动态才是大头拿到功耗极低的电子墨水屏还支持 WiFiBLE 双无线连接这个题目时很多人第一反应是墨水屏本身就省电加上无线就更香了。这个理解只对了一半。真正做过这类产品的人会发现墨水屏的省电优势其实建立在一种非常特殊的物理机制上而一旦叠加了双无线省电的锅就从屏幕转移到了射频和系统睡眠策略上。我前后做过三个墨水屏类的项目从最早的电子价签到后来的桌面信息牌踩过的坑足够写一本小册子。这篇就把墨水屏 WiFi BLE 这套组合的功耗逻辑、共存细节和实操参数一次性讲透。适合阅读这篇的人包括正在规划低功耗显示终端的硬件工程师、写嵌入式固件的开发者、以及想自己动手做一个一年不用充电的桌面小屏的爱好者。无论你手上是 ESP32 系列、还是 nRF52 系列、还是双芯片架构下面的账本算法和参数取舍都能直接套用。1.1 双稳态显示像素断电后自己记住状态墨水屏和 LCD、OLED 最本质的区别在于它的像素是双稳态的。微胶囊里的黑白带电粒子在电场作用下移动到顶部或底部之后撤掉电场粒子依然停在那里——因为它靠的是范德华力和内部粘滞介质的束缚而不是靠持续供电维持状态。这个特性带来的直接后果是显示静态画面时屏幕的功耗真的是 0不是接近 0是字面意义上的零电流。LCD 背光要一直亮OLED 每个像素要一直维持驱动电流而墨水屏画完就可以彻底断掉驱动电路连驱动 IC 的升压电路都关掉。所以当你看到某款墨水屏标签号称电池能用五年它的算法逻辑大致是这样的屏幕静态功耗0主控睡眠功耗530µA射频待机功耗按策略不同几十µA 到几百µA刷新瞬间的功耗被刷新次数摊薄到几乎可忽略关键就在第三行。墨水屏只是把屏幕这一项从功耗预算里删掉了剩下的账还是要 MCU 和无线来还。很多人做方案时被墨水屏省电这个印象带偏把所有精力放在选屏上结果板子做出来待机 300µA一年都撑不到回头一看是 LDO 静态电流和上拉电阻在偷电。1.2 一次刷新到底花掉多少毫安时我们算一笔具体的账。以常见的 2.13 寸 122×250 单色屏SSD1680 驱动为例一次全屏刷新full refresh的大致波形是这样的升压电路先把电压泵到 ±15V 左右然后按照波形 LUT 逐行驱动整个过程约 1.82.2 秒。在这两秒里3.3V 侧的瞬时电流大约 1020mA峰值可能冲到 30mA取决于屏尺寸和升压电容。那么一次刷新的电量消耗是20mA × 2.0s 40mA·s 40 / 3600 mAh ≈ 0.011 mAh假设你是一个桌面日历每天刷新 4 次早中晚加一次状态更新0.011 mAh × 4 0.044 mAh/天一颗 CR2477 纽扣电池容量约 1000mAh光刷屏能撑1000 / 0.044 ≈ 22727 天这就是墨水屏省电的底气——刷屏本身根本不是瓶颈你可以把刷新次数提高十倍账面上依然毫无压力。但有几个坑必须注意局部刷新partial refresh比全刷省但不是线性关系。局部刷新的耗电主要来自升压电路的建立和若干行的驱动面积小了但固定开销还在。实测同一块 2.13 寸屏全刷 2.0s 约 20mA局部刷新 0.4s 约 18mA——时间短了 5 倍电流几乎没变因为大头是升压和固定时序。不刷新的部分不是免费的。如果你连续做几十次局部刷新会出现残影ghosting必须定期插一次全刷清屏。三色屏黑白红的刷新时间是灾难级的。同样尺寸可能需要 1520 秒瞬时电流也更高如果你的场景需要红色告警功耗预算要重新算。1.3 温度补偿与波形 LUT最容易被忽略的隐形开销这一条是新手最容易翻车的地方。墨水屏的驱动波形不是固定的它是温度相关的。驱动 IC 内部一般会存好几组波形 LUT按照温度区间切换比如 010℃、1025℃、2540℃ 各一套。原因是低温下粒子运动变慢需要更多帧、更长的高压时间来推动否则就会出现刷新不干净、对比度下降的问题。问题来了大部分驱动 IC 自己不带温度传感器。你得外挂一颗 I2C 温度传感器比如常见的低功耗数字温度传感器待机电流 1µA 以内在每次刷新前读一次温度然后选择对应的 LUT 或者调整波形参数。如果省略这一步会发生什么我实测过在 5℃ 的房间里用常温 LUT 刷同一张图黑白对比明显变差而且刷新后残留半透明的旧画面。更麻烦的是在 0℃ 以下某些屏会直接刷新失败画面停在中间状态。外挂温度传感器的代价很小——一颗 1µA 静态电流的传感器一天被读 4 次每次读 5ms摊下来电流贡献约 0.0000002mA可以完全忽略。这个成本一定要花。另外还有一个隐形成本如果你需要频繁读温度就不要让传感器一直上电。用 MOS 管控制传感器的电源读完就断可以避免它在待机时持续消耗。不过要注意很多数字传感器上电后需要 12ms 的稳定时间别读太急。2. WiFi 与 BLE 同时存在的必要性不是堆料是分工很多第一次接触这类方案的人会问既然有 WiFi 了为什么还要 BLE反过来既然 BLE 够省电为什么还要 WiFi 这个问题问得很到位。答案不是两个都要更牛逼而是两者承担的职责完全不同单独任何一个都会导致方案在某个维度上崩掉。2.1 BLE 做常驻哨兵低占空比的近场唤醒BLE 的角色是永远在线但极低占空比的监听者。一个典型的 BLE 广播配置广播间隔 1000ms发射功率 0dBm在 37/38/39 三个广播信道上轮流发送。每次广播事件的总射频开启时间大约 11.5ms峰值电流取决于芯片nRF52840 在 0dBm 发射时约 4.6mA广播事件加上唤醒开销1 秒间隔下的平均电流可以做到2560µA含 System ON 睡眠。ESP32-C3 的 BLE 峰值电流高得多广播瞬时可能到 2030mA1 秒间隔的平均电流大概在120350µA。这个差距解释了为什么追求极致待机的方案会用 nRF52 系列来做 BLE 侧。BLE 在这里的具体工作有三件被手机发现。手机 App 扫描到广播建立连接把要显示的内容图片、日程、天气推过来。被固定网关发现。在电子价签场景里货架上的基站周期性扫描广播里携带标签 ID基站决定要不要给它推新价格。唤醒主控。这是最关键的一条。BLE 侧收到有新内容的信号后拉高一个 GPIO把深度睡眠中的主控叫醒主控再去开 WiFi 干活。BLE 广播的另一个好处是不需要配对就能被发现。你可以把部分信息直接塞进广播报文里比如 31 字节的广播数据里放设备状态、电量、当前显示页号手机扫一下就能看到连连接都不需要建立功耗又低了一截。2.2 WiFi 做搬运工一次性把图和字全拉下来WiFi 的价值在于吞吐量和直达性。一张 800×480 的黑白图1 位色深未压缩是 48000 字节压缩后大概 815KB如果带灰度或者多色可能上百 KB。用 BLE 传 15KB在 1M PHY、连接间隔 30ms 的条件下考虑到协议开销和丢包重传实际有效速率往往只有 515KB/s传完要好几秒甚至十几秒。而 WiFi 一旦连上几秒钟内把 100KB 拉下来毫无压力。更重要的是WiFi 可以直接访问 HTTP 接口、MQTT 服务器不需要中间网关。BLE 要上网必须有手机或网关做代理这在很多场景里是硬伤——你不可能要求用户的手机一直开着 App。WiFi 可以跑 TLS。内容来源如果有鉴权要求BLE 那条链路要么依赖手机的凭证要么协议自己做加密都更麻烦。WiFi 的会话是短促爆发型的。连上、DHCP、拉数据、断开整个过程 610 秒平均电流 80120mA算下来的电量消耗大概 0.150.3mAh。每天做 4 次一天 1mAh 左右1000mAh 的电池能撑三年。2.3 只留一种无线会怎样两种失败方案复盘方案 A只留 BLE。表面上待机电流极低能到 30µA 级别一年耗电只有 0.26mAh × 365 ≈ 95mAh非常漂亮。但问题是内容从哪来如果依赖手机 App用户必须每次手动靠近、打开 App、等待传输。在桌面日历这类场景里用户希望我早上起来它自己就更新了纯 BLE 做不到。如果加网关成本直接翻倍而且网关还得一直上电。方案 B只留 WiFi。那就要面对一个残酷的数字ESP32 保持 WiFi 连接、开启 Modem-sleep、DTIM3 的情况下平均电流约 12mA。1000mAh 电池1000mAh / 1.5mA ≈ 666 小时 ≈ 27 天一个月一充这已经不能叫功耗极低了。就算把 DTIM 调到 10降到 0.5mA 左右也就撑 80 天。而且 WiFi 常连还带来一个问题路由器侧会维护大量长连接网络环境一变换 SSID、密码、路由器重启就要重新配网用户体验很差。双无线的真正价值就在这里BLE 用极低的成本维持永远可被唤醒WiFi 只在真正需要搬数据的那几秒里被点亮。两者是串联关系不是并联关系。想明白这一点整个低功耗架构的设计思路就通了。无线方式典型平均电流适合承担的任务不适合承担的任务BLE 广播1s 间隔25350µA 视芯片常驻监听、近场发现、唤醒信号、小数据配置大文件传输、直接访问互联网BLE 已连接1s 间隔30200µA参数下发、固件小补丁、状态回传图片传输、长时间数据流WiFi 已连接Modem-sleepDTIM312mA需要长连接推送的场景如 MQTT电池供电、追求年级别续航WiFi 按需连接每次 610s摊薄后 0.05mA大内容下载、HTTPS 拉取、OTA需要毫秒级响应的场景3. 单天线共存WiFi 和 BLE 抢频段的那些细节WiFi 工作在 2.4GHz 的 113 信道BLE 在 2.4022.480GHz 的 40 个信道上跳频其中 37/38/39 是广播信道。两者物理上共享同一段频谱如果共用一个天线就必须分时使用。3.1 时分复用的底层逻辑与仲裁机制单芯片双模方案比如 ESP32 系列、部分 Combo 芯片内部有一个共存仲裁器大致逻辑是射频前端只有一套任何时刻只能有一个协议在用。BLE 的事件广播、连接事件有严格的时间窗要求错过就可能丢包或断连。WiFi 的收发相对宽松一些但 beacon 接收也有周期约束。仲裁器会给 BLE 更高的优先级因为 BLE 的时间窗更紧WiFi 的发送被推迟。这就导致一个现象当 BLE 连接间隔设置得比较密同时 WiFi 在传大文件时WiFi 的吞吐会明显下降。我实测过一组数据用某款 ESP32 系列芯片BLE 连接间隔 30ms同时跑 WiFi TCP 下载BLE 连接间隔WiFi 吞吐无 BLEWiFi 吞吐BLE 同时连接下降幅度关闭 BLE12.5 Mbps——100ms12.5 Mbps10.8 Mbps-14%30ms12.5 Mbps7.2 Mbps-42%15ms12.5 Mbps4.1 Mbps-67%结论很直白如果你的方案是单芯片 单天线就不要让 BLE 和 WiFi 同时高强度工作。正确做法是错开——BLE 负责唤醒唤醒后先断开 BLE 连接或者把连接间隔临时拉大到 500ms 以上再开 WiFi 拉数据数据拉完关 WiFi恢复 BLE 连接。如果你真的需要两者并存且都要性能那就上双天线 外部共存信号coexistence或者干脆用双芯片架构让 BLE 和 WiFi 跑在两颗芯片上各自独立天线。前者成本增加有限后者增加更多但架构更干净。3.2 连接间隔、广播间隔与信道避让的参数取值参数不是随便填的下面这几个取值是我反复调过的经验值BLE 广播间隔8001200ms。低于 500ms功耗上升明显但发现速度提升有限高于 2000ms手机扫描时可能等好几秒才看到设备体验变差。1000ms 是个很好的平衡点。BLE 连接间隔连接态用 100500ms空闲时用 10002000ms。可以用连接参数更新请求Connection Parameter Update动态调整。手机侧通常有最小间隔限制iOS 上常见的最小值是 15ms但你不该用那么小。Slave Latency能开就开。从设备延迟slave latency允许从机跳过若干个连接事件不应答。设 slave latency 4、连接间隔 200ms意味着从机实际每 1 秒才醒一次。这个参数对功耗的影响比连接间隔还大。WiFi DTIM按需设置。DTIM 越大设备醒来越少越省电但下行数据的延迟越大。按需连接的方案里DTIM 意义不大因为连接时间本来就短。WiFi 信道避让尽量让路由器避开 BLE 广播信道所在的频段。BLE 的 37/38/39 分别对应 2402、2426、2480MHz大致落在 WiFi 的 1 信道尾部和 13 信道附近。如果你的 AP 可以固定信道选 6 或者 11 会稍微好一点点虽然提升有限但聊胜于无。有一个细节很多人不知道BLE 的连接事件里如果从机在若干个事件里都没数据要发它会直接关闭射频进入睡眠。所以你在固件里应该尽量避免在连接态下无意义地周期性发心跳包那会让功耗翻好几倍。3.3 实测数据共存前后的丢包与功耗对比我把两组配置跑了一遍用同样的硬件、同样的 1000mAh 电池模型持续 24 小时配置BLE 广播平均电流WiFi 会话次数/天单次会话耗电日耗电合计预估续航单芯片BLE 广播 1s WiFi 按需约 180µA4 次0.25mAh4.32 1.0 5.32mAh约 188 天双芯片BLE 端 1s 广播主控断电约 45µA4 次0.25mAh1.08 1.0 2.08mAh约 480 天单芯片WiFi 常连 DTIM3—常连—36mAh约 27 天注意上表的电流数字是基于常见芯片的实测区间给出的参考值具体到你的板子会因为 LDO、外围器件、天线效率而上下浮动务必以实测为准。表格的意义在于对比量级而不是绝对值。这张表最值得琢磨的地方是双芯片方案把日耗电从 5.32mAh 压到 2.08mAh续航翻了 2.5 倍但成本增加了一颗 BLE SoC 和一小块 PCB 面积。这个取舍在量产里面很常见——如果你的产品定位是三年免维护那 2.5 倍的续航差距就是决定性的。4. 固件层低功耗设计把电流压到微安级的四步硬件给了你一个 30µA 的地板固件做不好照样待机 500µA。下面是我总结的一套实操路径。4.1 分级睡眠从 Modem-sleep 到 Deep-sleep 的取舍低功耗不是只有醒和睡两种状态而是一个阶梯模式保留什么唤醒源典型电流唤醒时间Active全部外设、CPU 全速—2080mA—Light-sleepRAM 保持、外设时钟可关任意中断0.31mA含 BLE 活动 1msDeep-sleepRTC 域 少量 RTC RAMRTC 定时器、RTC GPIO、触摸530µA几毫秒到几百毫秒Hibernation / System OFF极少量寄存器复位、特定引脚 1µA相当于重新启动选择逻辑很简单BLE 广播期间必须用 Light-sleep因为要保持射频和定时器工作。不需要 BLE 的时间段比如晚上 23:00 到早上 06:00可以彻底进 Deep-sleep只留 RTC 定时器在早上把自己叫醒。这一招能省掉近一半的日均功耗。只有在需要搬运数据的那几秒才进 Active。一个容易忽略的点Deep-sleep 唤醒后很多外设状态会丢失比如 SPI 配置、屏幕驱动 IC 的寄存器。如果你每次醒来都要重新初始化屏幕驱动那几十毫秒的初始化就有意义了。我的做法是把屏幕状态和当前显示内容记在 RTC RAM 里醒来先判断内容没变就不刷屏只做网络同步。4.2 一次完整唤醒链路的时序拆解下面这段是伪代码式的时序你可以对照自己的固件检查有没有多余的步骤[BLE 广播中Light-sleep] ↓ 收到连接请求或私有广播指令 [BLE 连接建立] ↓ 手机/网关下发 { need_sync: true, url: ... } [从机应答记录任务] ↓ 断开发射拉高 GPIO 唤醒主控 [主控从 Deep-sleep 唤醒约 150ms 启动] ↓ 初始化 SPI、屏幕驱动读 RTC RAM 判断是否需要刷屏 [打开 WiFi 电源连接 AP] ↓ 连接 DHCP ≈ 2.54s [HTTPS 拉取内容 ≈ 13s视内容大小] ↓ 校验、写 Flash 缓存 [驱动墨水屏刷新 ≈ 0.42s] ↓ 关闭 WiFi 电源主控回到 Deep-sleep [BLE 恢复广播]整个链路的关键优化点有三个不要每次唤醒都重连 WiFi。把 SSID、密码、甚至 IP 配置存起来如果 AP 没变、信号还在直接连接能省掉 DHCP 的 12 秒。更进一步如果只是拉一小段数据可以用静态 IP 跳过 DHCP。内容要缓存。拉到新内容先写 SPI Flash刷屏从 Flash 读。这样即使刷屏过程中断电重启后还能恢复上一个画面也不会白跑一次网络。把 BLE 和 WiFi 的时间段彻底错开。前面算过单天线共存时 WiFi 吞吐会掉 40% 以上而 WiFi 在线时间越长平均电流越高。错开之后WiFi 那几秒能跑满速率。4.3 双芯片架构让 BLE 协处理器替主控值班如果你的产品需要年级别续航我强烈建议考虑双芯片方案。分工是这样的BLE 芯片如低功耗 BLE SoC常驻运行负责广播、连接、收指令、控制主控电源。它只在收到任务时才把主控拉起来平时主控的电源是被 MOS 管切断的静态电流接近 0。主控芯片如带 WiFi 的 MCU平时完全断电醒来后做 WiFi 通信和屏幕刷新。这样做的直接收益是待机电流由 BLE 芯片决定而不是由带 WiFi 的芯片决定。前面那张表已经说明了差距45µA vs 180µA日耗电差 3 倍多。代价也是很实在的硬件成本增加一颗 SoC、一颗晶振、一套电源域。固件复杂度上升两个芯片之间的通信协议要设计好推荐用 UART 简单的帧协议或者 SPI 中断引脚。PCB 面积变大如果你的产品是 30mm × 40mm 的标签可能放不下。判断标准如果目标是 1 年以内续航单芯片方案足够如果目标 2 年以上或者电池容量小于 400mAh双芯片方案更划算。5. 硬件侧的低功耗细节漏电往往比工作电流更致命固件再优化硬件漏电也能把一切努力抹平。我见过最夸张的案例固件待机电流 15µA整机测出来 380µA最后发现是 USB 转串口芯片没断电。5.1 供电架构与电池选型先选电池再设计供电顺序不能反。电池类型标称容量特点适用场景CR2450 纽扣约 600mAh便宜、体积小、不可充电子价签、极简信息牌CR2477 纽扣约 1000mAh容量大、厚度增加需要长续航的标签两节 AAA约 1000mAh可用易更换、体积大桌面设备、可维护场景锂聚合物 500mAh约 500mAh可充电、放电曲线平缓需要频繁刷新的场景锂亚硫酰氯约 20002600mAh自放电极低、脉冲电流弱超长待机但要注意瞬时电流能力锂亚硫酰氯Li-SOCl2这条要特别说一下它的自放电率极低每年 1% 以内理论上非常适合这类设备但它的脉冲放电能力弱墨水屏刷新时瞬间要 30mA可能会把电压拉垮导致复位。如果要用必须在旁边并一颗大电容做缓冲或者选脉冲型如带 HPC 混合层电容的型号。供电架构上主流做法是电池 → 超低静态电流 LDO → 3.3V 主电源 ├─→ 常开域BLE 芯片若有、RTC └─→ 受控域屏幕驱动、传感器、USB 芯片MOS 管控制LDO 的静态电流一定要看数据手册的Ground Current / Quiescent Current这一项不是看 Dropout。常见的超低静态 LDO静态电流可以做到 25nA 到 1µA 级别。如果你随手选了一颗 5mA 静态电流的型号那待机功耗直接从微安级跳到毫安级前面的所有努力全都白费。5.2 那些把待机电流从 30µA 拉到 300µA 的元凶下面这份排查清单是我用血泪换来的建议直接收藏第一类通信芯片的隐性功耗。USB 转串口芯片是重灾区某些型号工作电流就有几毫安就算不插 USB 也在耗电。量产板上一定要用 MOS 管或者干脆不装调试用飞线解决。第二类上拉电阻的反向漏电。I2C 总线上有 4.7kΩ 上拉到 3.3V 的电阻如果从设备的电源被 MOS 管切断了电流就会通过上拉电阻倒流进芯片的 IO 保护二极管形成一条持续的漏电通路。4.7kΩ 上的电流(3.3V - 0.6V) / 4.7kΩ ≈ 0.57mA这已经比整机待机电流大 20 倍了。解决办法把上拉电阻改到 100kΩ代价是速率下降400kHz 高速 I2C 可能不适用或者把上拉电阻的供电也接到受控电源域上。第三类MOS 管的栅极浮空。用 MOS 管做电源开关时如果控制 IO 在 MCU 睡眠后变成高阻态栅极电压不确定MOS 管可能处于半导通状态那漏的就是一大片。控制 IO 要配置成推挽输出并保持低电平或者加一颗 100kΩ 下拉电阻。第四类墨水屏的未使用引脚。屏幕不刷新的时候驱动 IC 的 SPI 引脚、BUSY 引脚如果没有明确处理可能通过屏内部的保护结构漏电。建议在睡眠前把 SPI 引脚配置成低电平输出或高阻BUSY 引脚的上拉如果必须加选大阻值。第五类传感器和 RTC。有些温度传感器、加速度计在默认配置下是周期采样模式静态电流能到 50100µA。上电后第一件事就是把它们配置成单次测量模式One-Shot测完自动回睡眠。6. 落地场景差异电子价签、桌面信息牌、电子日历不是一套参数同一个硬件平台换个场景参数就得重调。下面是我做过的三类场景的差异总结。6.1 电子价签刷新少、延迟容忍度高电子价签的特点非常鲜明一天可能只刷 15 次而且晚几秒钟刷新完全无所谓。这类产品的设计重点不是快而是省和可靠。广播间隔可以放到 2000ms 甚至更长因为价签不需要被手机发现只需要被基站扫到。显示内容以数字和简单文字为主可以用局部刷新一次 300500ms。网络策略上很多方案干脆不用 WiFi用 2.4GHz 私有协议或者 BLE 网关因为数据量小几十字节BLE 完全够用。但我在这个场景踩过一个坑基站和价签的时钟不同步导致的广播丢包。如果几百个标签的广播间隔完全相同它们在时间上会持续对齐某些信道会周期性拥塞。解决办法是给每个标签的广播间隔加一个随机抖动比如 1000ms ± 150ms让广播事件在时间上打散。这个改动几乎没有成本但能显著提升首次扫描成功率。6.2 桌面信息牌刷新频繁、要能局部刷新桌面信息牌是个人用户最爱做的形态——显示天气、日程、股票、待办事项。这类设备的刷新频率高得多可能每 15 分钟到 1 小时就要更新一次而且内容里有图表、小图标需要灰度或者至少是细腻的抖动处理。关键差异刷新频率高意味着残影问题突出。我的做法是每 8 次局部刷新插一次全刷或者干脆按时间算每 6 小时全刷一次清底。WiFi 会话次数多。每天 24 次会话每次 0.25mAh一天就是 6mAh1000mAh 电池只能撑 166 天。这时候要么降低刷新频率要么把内容源合并——一次拉取多个信息源的数据减少会话次数。考虑用长连接换短连接。如果刷新频率高到每 15 分钟一次那不如保持 WiFi 连接但把 DTIM 调到最大。1mA × 24h 24mAh/天比 24 次短会话的 6mAh 差很多所以还是短连接更优。这个结论在我实测之前是反直觉的但数字不会骗人。6.3 电子日历/待办屏日更一次的网络策略这类产品最极端一天只刷一次续航可以做到非常夸张。设计上的自由度和特殊注意点可以把 WiFi 彻底断电。用 RTC 定时器每天早上 7:00 唤醒主控重连 WiFi拉数据刷屏然后回到 Deep-sleep。系统里根本没有保持在线这个概念。配网怎么办只能是首次配网或者网络变化时通过 BLE 把 SSID 和密码写进去。所以 BLE 侧要保留一个配网模式的入口比如长按按键 3 秒后进入广播 可连接状态。时区与夏令时。这是个软件问题但很容易翻车。RTC 只走 UTC本地时间靠时区偏移换算。如果时区规则变了有些地区会调整夏令时你得有个机制能通过 BLE 或 WiFi 更新时区表。这类产品的实测数据日耗电 1.5mAh 左右1000mAh 电池可以撑 600 天以上接近两年。如果换成双芯片架构能上到 1000 天以上。7. 调试与量产验证怎么把功耗数字测准最后聊聊测量和验证。这一块看着简单实际上巨大比例的团队在这里得到过错误的数字并基于错误数字做了错误决策。7.1 用万用表测不出真实功耗的原因普通万用表的电流档有两个致命问题采样率太低。大部分手持表的刷新率只有每秒几次而 BLE 广播的电流是1ms 高、999ms 低的脉冲。它会看到一个平均值但那个平均值可能因为采样窗口对齐问题而严重失真。内阻太大。万用表电流档的取样电阻可能有几欧姆到几十欧姆在 100mA 峰值时会产生显著的压降导致设备欠压复位或者行为异常。你测到的其实是一个被万用表影响过的系统。我的建议方案短时间高精度测量用带高采样率至少 10kHz的电流探头或专业功耗分析仪能看清每个脉冲的形状。长时间平均测量用一颗大电容比如 1000µF并联在电池两端万用表串在电池和电路之间电容起到积分器的作用能把脉冲电流平滑成接近真实的平均值。这个方法精度有限但非常便宜适合做长期的趋势观察。替代方案用库仑计芯片自带电流累加器做长时间电量统计直接读累计电荷比读瞬时电流可靠得多。7.2 一套可复现的功耗验收流程我在项目里固定跑这套流程每次固件修改后都要重跑步骤操作观察指标合格标准1拔掉所有调试线只留电池静态电流 30µA2关闭 BLE 广播只留 RTC深度睡眠电流 15µA3打开 BLE 广播1s 间隔平均电流 200µA单芯片/ 60µA双芯片4触发一次完整的 WiFi 同步 刷屏过程总电荷 0.4mAh5连续 24 小时跑真实业务逻辑累计电量与预估误差 20%6静置 72 小时不触发任何任务累计电量 0.5mAh/天第 6 步特别重要它能暴露定时器泄漏这类问题——比如某个任务忘了关每隔几秒就醒一次。7.3 上线前必须跑的三类异常场景功能和功耗都调好之后还要跑异常场景因为现场环境远比实验室恶劣第一类WiFi 连接失败。把 AP 关机或者把 SSID 改错观察设备是否会在重试里无限循环。必须有超时和退避机制——重试 3 次失败就放弃进入低功耗等待下一个周期再试。我见过一个固件因为没做退避在 AP 宕机时每 2 秒重连一次一天就把电池耗去一半。第二类BLE 连接被异常断开。手机走到范围外、或者 App 被杀BLE 连接会以各种方式断开。要确保断开事件能正确回收资源、恢复广播而不是卡在某个中间状态等死。第三类低温和高温。墨水屏在低温下刷新变慢电池在低温下内阻升高、可用容量下降。如果产品要在户外使用最好在 -10℃ 和 50℃ 各跑一遍完整流程看看有没有刷新失败、有没有因为电压跌落而复位。提示低功耗设备的现场故障八成不是硬件坏了而是某个状态机卡住了。养成习惯给每个状态加一个看门狗超时卡住就无条件复位回初始态。这条经验帮我救回过不止一个已经发到客户手上的项目。最后分享一个我自己一直在用的小技巧在固件里留一个功耗诊断模式通过 BLE 触发后设备会把最近 24 小时的唤醒次数、每次唤醒的原因、累计联网时间、刷屏次数打包回传。这个数据在排查现场问题时比任何串口日志都有用因为它不需要拆机、不需要夹具只要一台手机就能拿到设备的工作履历。我在第二个项目里加上这个功能之后现场问题的定位时间从平均两天缩短到了半小时强烈建议你也在设计初期就把这个埋点留出来。 
