企业官网建设流程全解析

1. 搞块板子之前，先把低功耗这件事想明白

嵌入式低功耗这个话题，说起来简单，做起来全是坑。我见过太多项目，硬件选型的时候拍脑袋选了颗标称休眠电流0.5微安的MCU，结果板子回来一测，整机待机电流干到800微安，电池续航直接从理论上的三年缩水到三周。问题出在哪？出在大家把“低功耗”当成了一个芯片参数，而不是一个系统工程。

你手上如果正拿着一块开发板，或者正准备画一块低功耗的板子，那这篇文章就是写给你的。不管你是刚入行的嵌入式软件工程师，还是做了几年硬件想补一补电源管理这块短板的老手，又或者是参加蓝桥杯嵌入式组、正在准备嵌入式面试八股文的同学，低功耗设计这个知识点你都绕不过去。它不像点个灯那么简单，也不像跑个RTOS那么有章可循，它更像是一门“抠细节”的手艺活。

我自己的经历比较典型。早些年做一款手持式环境监控设备，MCU用的是当时号称超低功耗的某款Cortex-M0+，传感器和无线模块也都选了低功耗型号，原理图review了三遍，PCB layout也专门注意了地平面分割。结果第一版回来，休眠电流比预期高了两个数量级。查了整整一周，最后发现是一颗LDO的使能引脚上拉电阻没处理好，在休眠状态下漏了一条通路。这件事让我彻底明白：低功耗不是选出来的，是设计出来的，是一微安一微安抠出来的。

所以这篇内容，我不打算跟你讲太多教科书上的理论，而是从“搞块板子”这个动作开始，把嵌入式低功耗开发里那些真正影响结果的关键决策、实操细节和踩坑经验，一层一层拆开来说。核心会围绕PMIC选型与配置、MCU低功耗模式管理、USB-C供电与充电设计、外设与IO的漏电控制这几个维度展开，中间会穿插nPM1300这类现代电源管理IC的实际使用思路，也会聊到像HC32L196、STC15W408AS、CH579这些常见低功耗芯片在实战中的表现差异。

你不需要有很深的电源设计背景，但最好对嵌入式系统的基本组成有个概念。我会尽量用生活化的类比把原理讲清楚，同时给出可以直接参考的配置思路和排查方法。目标只有一个：让你下次搞低功耗板子的时候，心里有谱，手里有招，不再靠运气。

2. 低功耗设计的整体思路与方案选型

2.1 为什么“低功耗”是一个系统问题而不是芯片问题

很多人一上来就问：哪颗MCU功耗最低？这个问题本身就有问题。就像你问“哪种车最省油”一样，脱离路况、载重、驾驶习惯来谈油耗，没有意义。嵌入式系统的功耗同样如此，它取决于工作模式占空比、外设开启时长、电源转换效率、漏电流路径等多个因素的综合作用。

我习惯把低功耗设计拆成四个层次来看：

• 第一层：电源路径。从电池或USB-C输入，到PMIC，再到各电压域，每一级转换都有损耗。LDO的效率约等于输出电压除以输入电压，压差越大，浪费越多。DC-DC效率高但有静态电流和开关噪声。选哪个，取决于你的输入输出压差和负载电流范围。
• 第二层：MCU与核心器件。MCU的运行功耗、休眠功耗、唤醒时间，三者需要平衡。休眠电流再低，如果唤醒一次要几十毫秒才能稳定，而你的系统每秒唤醒十次，那平均功耗照样下不来。
• 第三层：外设与IO。传感器、存储器、显示屏、指示灯，每一个都是耗电大户。更隐蔽的是IO口的漏电：一个配置不当的引脚，可能通过外部上拉或下拉电阻持续消耗电流。
• 第四层：软件行为。轮询还是中断？延时用空转还是休眠？通信协议能不能批量传输？这些软件层面的决策，对功耗的影响往往被严重低估。

把这四层都想清楚，你才能回答“这颗芯片适不适合我的低功耗场景”这个问题。否则，你只是在比较数据手册上的几个数字，而真实系统的功耗可能和这些数字毫无关系。

2.2 PMIC选型：为什么nPM1300这类器件值得关注

说到电源管理，以前很多低功耗项目是用分立器件搭的：一颗LDO给MCU，一颗DC-DC给无线模块，再加一颗充电IC管锂电池。板子上电源部分占了一大块面积，BOM表里一堆料，调试的时候还要一个个测效率、测纹波。后来集成PMIC出现，把这些功能塞进一颗芯片里，事情就简单多了。

nPM1300是Nordic出的一颗电源管理IC，我最近在几个项目里用过，感受比较深。它的定位很明确：给低功耗嵌入式系统提供一套完整的电源解决方案。里面集成了线性充电器、两个降压DC-DC、两个LDO、电量计、看门狗、系统复位等功能。你如果用nRF52或nRF53系列做低功耗蓝牙产品，这颗PMIC几乎是配套的首选。

但我想说的不是“它有多好”，而是为什么这种集成思路值得你在选型时考虑。原因有三：

第一，静态电流可控。nPM1300在运输模式下静态电流低至零点几微安级别，这对需要长期仓储、靠纽扣电池或小容量锂电供电的设备来说很关键。你如果用分立方案，光是LDO的静态电流和充电IC的待机电流加起来，就可能超过这个数。

第二，电源域管理灵活。它可以通过I2C配置每一路输出的电压和开关状态，软件上可以根据系统状态动态调整。比如MCU休眠时，把传感器那一路LDO关掉；无线模块发射时，把DC-DC切到高性能模式。这种灵活性是分立方案很难做到的。

第三，电量计集成。低功耗设备往往需要准确的电量显示，分立方案要额外加一颗电量计IC，又占面积又加成本。nPM1300内置的电量计基于电压和电流综合估算，精度对于大多数消费级产品够用。

当然，PMIC也不是没有代价。它的配置通常需要通过I2C写入寄存器，增加了软件复杂度；某些型号的封装对PCB散热要求较高；而且一旦选型确定，后期想换方案成本很大。所以我的建议是：如果你的项目对体积、待机功耗、电量显示有明确要求，且产量在千台以上，集成PMIC是值得认真评估的选项。如果是验证性项目或者产量很小，分立方案可能更灵活。

2.3 MCU低功耗模式：别只看数据手册的“典型值”

MCU是低功耗设计的核心，但数据手册上的功耗数字往往是在特定条件下测得的。比如“休眠电流0.5微安”，可能是在25摄氏度、3.0V供电、所有外设关闭、RAM保持、无IO翻转的条件下测的。你的实际系统里，温度可能到60度，电压可能3.6V，IO上还挂着传感器，这些都会让实际功耗高于标称值。

我整理了一个常见低功耗MCU的对比思路，不是具体型号推荐，而是帮你建立评估框架：

以HC32L196为例，这颗国产低功耗MCU在休眠模式下的表现不错，支持多种低功耗模式，外设丰富，适合需要LCD驱动和多个通信接口的场景。STC15W408AS则是另一类选择，它的优势在于简单、便宜、抗干扰强，适合对成本敏感且功能不复杂的低功耗应用，但它的低功耗模式相对基础，需要软件上做更多配合。CH579则集成了蓝牙，适合需要无线连接的低功耗设备，它的低功耗蓝牙协议栈在休眠调度上有一套自己的机制，用好了很省电，用不好反而费电。

选MCU的时候，我一般会问自己几个问题：系统大部分时间在做什么？是深度休眠等事件，还是周期性采集数据？唤醒后需要多快完成工作？有没有必须持续运行的外设？把这些想清楚，再去对照数据手册，才能找到真正合适的芯片。

2.4 USB-C供电与充电：便利性背后的设计细节

现在越来越多的嵌入式设备用USB-C口供电和充电，这确实方便，但USB-C不是插上就能用的。它涉及CC引脚检测、供电能力协商、充电电流管理等环节。如果你只是把USB-C的VBUS和GND引出来接到充电IC，可能会遇到一些问题：比如某些充电器不输出电，或者设备被识别为需要大电流的设备但实际供电不足。

USB-C的CC引脚用来检测连接状态和方向。对于受电设备（UFP），需要在CC1和CC2上各接一个5.1kΩ的下拉电阻到地。这样充电器才知道你是一个需要供电的设备，才会在VBUS上输出电压。如果你漏了这两个电阻，或者阻值不对，充电器可能根本不给你供电。

充电电流的设置也要注意。USB 2.0端口默认只提供500mA，USB 3.0是900mA，USB-C在没有PD协商的情况下默认也是500mA左右。如果你想用更大的电流充电，要么通过BC1.2协议检测，要么走USB PD协商。对于大多数低功耗嵌入式设备，500mA充电已经够用了，没必要为了快充增加PD协议芯片的复杂度和成本。

还有一个容易被忽略的点：充电时的系统功耗。如果你的设备在充电时还在运行，充电电流一部分要供给系统，剩下的才充进电池。如果系统功耗接近充电电流，电池可能永远充不满。所以低功耗设计要贯穿到充电场景：充电时能不能让系统进入低功耗状态？能不能暂停非必要的外设？这些都需要在软件上考虑。

3. 核心细节解析与实操要点

3.1 电源域划分：把每一微安都管起来

低功耗设计的第一步，是在原理图阶段就把电源域划分清楚。什么叫电源域？简单说，就是哪些器件共用一路电源，这路电源能不能单独开关。划分的原则是：能独立关闭的，就不要和其他常开器件绑在一起。

举个例子。一个典型的低功耗传感器节点可能包含：MCU、无线模块、传感器、指示灯、调试接口。如果所有器件都挂在同一路3.3V上，那MCU休眠时，传感器和指示灯的功耗照样在消耗。正确的做法是：

• MCU和无线模块共用一路，因为这俩通常需要同时工作；
• 传感器单独一路，采集完就关；
• 指示灯单独一路，或者干脆用IO直接驱动，不用时设为高阻；
• 调试接口的供电也要可控，量产固件里应该能彻底关掉。

nPM1300这类PMIC的好处就在这里：它有多路输出，每一路都可以通过寄存器独立控制。你在软件里根据系统状态切换电源域，比用分立MOS管搭开关电路要干净得多。

注意：电源域切换时要注意时序。先关负载，再关电源；先开电源，等稳定后再开负载。否则可能出现器件通过IO口反向供电的情况，导致关不干净。

3.2 IO口漏电：那些看不见的微安

IO口漏电是低功耗设计里最隐蔽的坑之一。一个引脚配置不当，可能产生几十甚至几百微安的漏电流，而你在原理图上完全看不出来。

常见的IO漏电场景有几种：

第一种：输出高电平驱动外部下拉电阻。比如某个使能引脚，外部有个10kΩ下拉到地，MCU输出高电平时，这个引脚就在持续消耗3.3V除以10kΩ等于330微安的电流。如果这个使能信号在休眠时不需要保持高电平，就应该在休眠前把它设为低电平或者高阻输入。

第二种：输入引脚浮空。CMOS输入引脚如果悬空，内部反相器可能处于线性区，导致电源到地之间出现直通电流。虽然现代MCU大多有内部弱上拉或弱下拉，但为了保险，未使用的引脚应该配置为输出低电平或者使能内部上下拉。

第三种：IO口电压高于供电电压。如果某个器件在MCU断电时仍然有信号输入到MCU的IO口，电流会通过IO口的ESD保护二极管倒灌进MCU的电源网络。这种情况在有多路电源的系统中很常见，解决方法是确保断电顺序正确，或者在IO口串联限流电阻。

第四种：复用功能引脚的默认状态。有些MCU的引脚在上电复位后默认是某种复用功能，可能带有内部上拉或下拉。如果你没注意，这些引脚可能在你不希望的状态下消耗电流。建议在初始化代码里，把所有未使用引脚明确配置为最低功耗状态。

我自己的习惯是，在固件里写一个GPIO_LowPowerInit()函数，把所有IO口根据实际使用情况逐一配置，而不是依赖复位默认值。这个函数在进入低功耗模式前也会调用，确保没有引脚处于中间状态。

3.3 低功耗模式配置：从Run到Deep Sleep的每一步

不同MCU的低功耗模式名称和数量不一样，但大体上可以分成几类：运行模式、睡眠模式、深度睡眠模式、待机模式、关机模式。越往后功耗越低，但唤醒后需要重新初始化的内容也越多。

以常见的Cortex-M系列为例，WFI（Wait For Interrupt）和WFE（Wait For Event）指令可以让内核进入睡眠。但内核睡了不代表系统功耗就低了，还要看外设时钟有没有关、电压调节器有没有切到低功耗模式、Flash有没有断电。

我一般会按照这个顺序来配置低功耗：

1. 关闭不需要的外设时钟。在进入低功耗前，把ADC、SPI、I2C、UART等外设的时钟全部关掉。有些MCU的低功耗模式会自动关外设时钟，但手动关更保险。
2. 配置唤醒源。确定哪些事件能把系统唤醒：RTC定时、外部中断、比较器输出等。把不用的唤醒源关掉，避免误唤醒。
3. 设置IO状态。按照上一节说的方法，把所有IO配置到不耗电的状态。
4. 切换电压调节器模式。很多MCU有内部LDO或DC-DC，低功耗模式下可以切到低功耗模式，牺牲一些性能换更低的静态电流。
5. 关闭Flash和RAM供电。如果低功耗模式支持，可以把不保持的RAM区域和Flash断电。但要注意，唤醒后需要重新初始化这些区域。
6. 执行WFI或进入特定低功耗模式。

唤醒后的处理同样重要。唤醒源触发后，系统不会自动恢复到休眠前的状态，你需要重新配置时钟、重新初始化外设、恢复IO状态。这个过程越快，平均功耗越低。所以唤醒后的初始化代码要精简，只做必要的事情。

实操心得：我习惯在低功耗模式切换前后加一个GPIO翻转，用示波器抓这个引脚，就能直观看到系统在休眠和运行之间切换的时间比例。这个比例乘以运行功耗加上休眠功耗，就是系统的平均功耗。优化的时候，先看这个比例合不合理，再去看具体哪个环节耗电。

3.4 外设功耗管理：传感器、存储器和显示屏

MCU之外的器件，功耗管理同样重要。传感器通常有连续测量、单次测量、休眠几种模式。连续测量功耗最高但响应最快，单次测量折中，休眠最省电但唤醒需要时间。选择哪种模式，取决于你的采样频率和响应要求。

我做过一个环境监测项目，一开始用温湿度传感器做连续测量，电流大约200微安。后来改成每10秒单次测量一次，测量时间20毫秒，平均电流降到不到1微安。就这么一个改动，电池寿命从三个月延长到两年。

存储器的功耗也容易被忽略。EEPROM和Flash在写入时功耗较高，但待机功耗很低。铁电存储器（FRAM）写入功耗低、速度快，但成本高。如果数据写入不频繁，用Flash就够了；如果需要频繁记录且对功耗敏感，FRAM值得考虑。

显示屏是另一个耗电大户。段码LCD功耗很低，适合常显场景；OLED在显示深色内容时功耗低，但显示白色内容时功耗高；电子墨水屏只在刷新时耗电，显示静态内容时几乎不耗电，但刷新速度慢。选显示屏的时候，要把显示内容和刷新频率一起考虑。

3.5 通信协议与功耗的权衡

无线通信往往是低功耗系统里最耗电的环节。蓝牙、LoRa、Zigbee、Wi-Fi，每种协议的功耗特性不同，适用场景也不同。低功耗蓝牙适合短距离、小数据量、间歇性传输；LoRa适合远距离、极低数据率；Wi-Fi功耗高，适合有稳定供电的场景。

以低功耗蓝牙为例，连接间隔（Connection Interval）是影响功耗的关键参数。间隔越短，响应越快，但功耗越高；间隔越长，功耗越低，但延迟越大。对于不需要实时响应的传感器，可以把连接间隔设到几百毫秒甚至几秒，功耗能降一个数量级。

CH579这类集成蓝牙的MCU，在协议栈层面有一套低功耗调度机制。你需要理解它的广播间隔、连接间隔、从机延迟这几个参数的含义，才能配置出适合自己场景的低功耗方案。从机延迟（Slave Latency）允许从机跳过若干个连接事件不响应，如果传感器数据变化不快，适当增大从机延迟可以显著省电。

注意：增大连接间隔和从机延迟会降低通信实时性。如果你的应用有实时控制需求，比如遥控器或游戏手柄，就不能一味追求低功耗。这里需要根据具体场景做权衡。

4. 实操过程与核心环节实现

4.1 硬件设计检查清单：画板子前逐条过一遍

在投板之前，我通常会拿一份低功耗检查清单逐条核对。这份清单是踩了无数坑之后总结出来的，分享给你：

电源部分：

• 每一路电源的静态电流是否确认过？LDO的静态电流是多少？DC-DC的静态电流是多少？
• 电源使能引脚是否有明确的上拉或下拉？会不会在MCU未初始化时处于不确定状态？
• 电池和USB-C同时存在时，电源路径如何切换？有没有防倒灌设计？
• 充电电流是否可配置？默认值是否适合你的电池容量？

MCU部分：

• 所有未使用引脚是否都有明确的处理方式？悬空、上拉、下拉还是输出低？
• 调试接口（SWD/JTAG）在量产固件中能否彻底关闭？
• 外部晶振在低功耗模式下是否停止？如果停止，唤醒后能否快速起振？
• 复位引脚是否有外部上拉？上拉阻值是否过大导致抗干扰能力下降？

外设部分：

• 每个外设的供电是否可控？有没有独立电源域？
• 外设的使能引脚、片选引脚在休眠时的状态是否确定？
• IO口电压是否始终低于MCU供电电压？有没有倒灌风险？
• 上拉/下拉电阻的阻值是否合理？太大容易受干扰，太小耗电。

连接器与接口：

• USB-C的CC引脚是否有5.1kΩ下拉？
• 调试串口在休眠时是否会产生漏电？
• 外部连接器的引脚在悬空时会不会引入漏电？

这份清单看起来琐碎，但每一条都对应着真实的功耗问题。我建议你在原理图定稿前，至少花半天时间逐条确认。

4.2 软件低功耗框架：状态机与事件驱动

低功耗系统的软件架构，我强烈推荐事件驱动+状态机的模式。不要用一个大循环轮询所有事情，那样CPU永远在跑，功耗下不来。

基本思路是：系统有一个主状态机，定义几个状态，比如初始化、采集、处理、通信、休眠。每个状态执行必要的操作，然后根据事件决定下一个状态。没有事件时，系统进入休眠，等待中断唤醒。

一个简化的框架大概是这样：

typedef enum { STATE_INIT, STATE_ACQUIRE, STATE_PROCESS, STATE_TRANSMIT, STATE_SLEEP } SystemState_t; SystemState_t currentState = STATE_INIT; void System_Loop(void) { switch (currentState) { case STATE_INIT: Hardware_Init(); currentState = STATE_ACQUIRE; break; case STATE_ACQUIRE: Sensor_PowerOn(); Sensor_ReadData(); Sensor_PowerOff(); currentState = STATE_PROCESS; break; case STATE_PROCESS: Data_Process(); if (NeedTransmit()) { currentState = STATE_TRANSMIT; } else { currentState = STATE_SLEEP; } break; case STATE_TRANSMIT: Radio_PowerOn(); Radio_SendData(); Radio_PowerOff(); currentState = STATE_SLEEP; break; case STATE_SLEEP: Prepare_Sleep(); Enter_LowPowerMode(); // 唤醒后从这里继续 currentState = STATE_ACQUIRE; break; } }

这个框架的关键在于：每个状态只做必要的事，做完就切走。休眠状态是默认状态，其他状态都是短暂的过渡。这样CPU大部分时间在休眠，平均功耗自然就低了。

实际项目中，状态机会更复杂，可能需要处理多个事件源、超时、错误恢复等。但核心思想不变：让CPU尽可能多地待在休眠状态，让事件驱动系统运转。

4.3 功耗测量与调试：没有测量就没有优化

低功耗开发最忌讳的就是“我觉得”。你觉得休眠电流应该很低，你觉得这个外设已经关了，你觉得IO配置没问题。实际上，只有测量才能告诉你真相。

测量低功耗系统的电流，普通万用表往往不够用。因为休眠电流可能只有几微安，而唤醒时的瞬态电流可能几十毫安，万用表的量程和采样率都跟不上。你需要一台能测微安级电流、同时有足够带宽捕捉瞬态的设备。

如果手头没有专业设备，可以用一个简单的方法：在电源路径上串联一个采样电阻，用示波器测电阻两端的电压。采样电阻的阻值要选得合适：太大影响系统供电，太小信号太弱。对于微安级电流，可以用1kΩ电阻，这样1微安对应1毫伏，示波器能看清。但要注意，1kΩ电阻在毫安级电流下会产生较大压降，可能影响系统工作。所以这个方法适合在确认系统能正常工作的前提下，分段测量。

我自己的调试流程一般是：

1. 先测整机静态电流。系统进入最深休眠模式，所有外设关闭，测总电流。这个值应该接近你理论计算的休眠电流之和。
2. 如果偏高，逐路排查。断开某一路电源，看电流变化。变化大的那一路就是问题所在。
3. 再测各工作状态的电流。采集时多少？通信时多少？计算平均功耗。
4. 对比理论值。如果实测和理论差距大，检查IO配置、外设时钟、电源域开关。

实操心得：我习惯在板子上留几个跳线帽或者0欧姆电阻，专门用来断开某一路电源测电流。调试阶段这很方便，量产时焊上就行。如果板子面积允许，还可以留一个电流测试点，串联采样电阻用。

4.4 电池选型与续航估算：别让理论值骗了你

电池选型直接影响用户体验。容量、尺寸、放电特性、自放电率、温度特性，都要考虑。锂聚合物电池能量密度高，但低温性能差；锂亚硫酰氯电池自放电率极低，适合微安级长期供电，但放电电流小；碱性电池便宜易得，但容量和放电特性一般。

续航估算的公式很简单：续航时间 = 电池容量 / 平均电流。但这里的平均电流要算准，不能只用休眠电流。正确的算法是：

平均电流 = (运行电流 × 运行时间 + 休眠电流 × 休眠时间) / 总周期

举个例子。假设系统每60秒唤醒一次，唤醒后运行200毫秒，运行电流5毫安，休眠电流5微安。那么：

• 运行时间占比：0.2秒 / 60秒 = 0.00333
• 休眠时间占比：59.8秒 / 60秒 = 0.99667
• 平均电流 = 5mA × 0.00333 + 0.005mA × 0.99667 ≈ 0.0167mA + 0.005mA ≈ 0.0217mA

如果电池容量是1000mAh，理论续航约46000小时，约5.3年。但实际中还要考虑电池自放电、温度影响、电源转换效率等因素，打个七折比较稳妥。

注意：电池的自放电率往往被忽略。锂聚合物电池的自放电率大约每月2%到5%，一年下来就是24%到60%。如果你的设备设计续航是五年，自放电可能比系统功耗还大。这种情况下，要么选低自放电的电池类型，要么在软件上做电量补偿。

5. 常见问题与排查技巧实录

5.1 休眠电流偏高的排查思路

休眠电流偏高是最常见的问题。我整理了一个排查顺序，从可能性最高的原因开始：

这个顺序不是绝对的，但按照“从软件到硬件、从明显到隐蔽”的原则来排查，效率比较高。

5.2 唤醒失败或唤醒后死机

低功耗系统另一个常见问题是唤醒失败。系统进入休眠后，外部事件来了，但系统没反应，或者唤醒了但跑飞了。

唤醒失败的原因通常有几个：

• 唤醒源配置错误。比如你想用外部中断唤醒，但中断触发边沿设错了，或者中断优先级配置有问题。
• 休眠模式选得太深。有些低功耗模式会关闭某些时钟或电源域，导致唤醒源本身也失效了。比如用RTC唤醒，但休眠时把RTC时钟也关了，那肯定醒不来。
• 唤醒后的初始化不完整。系统从深度休眠唤醒后，时钟、电源、外设状态都变了，如果初始化代码没覆盖到，就可能死机。

我的经验是：每次修改低功耗配置后，都要做完整的唤醒测试。不要只测一次，要反复唤醒几百次，看有没有偶发失败。有些问题是概率性的，比如电源时序在特定条件下才出问题。

5.3 通信距离变短或数据丢失

低功耗设计有时会影响无线通信性能。比如为了省电，把无线模块的发射功率调低了，通信距离自然就短了。或者为了降低功耗，把接收窗口缩短了，导致数据包丢失。

这类问题的排查思路是：先确认功耗优化措施是否影响了通信参数。发射功率、接收灵敏度、天线匹配、通信间隔，这些参数和功耗直接相关。如果通信出问题，先看这些参数有没有被改动。

另一个可能的原因是电源噪声。低功耗模式下，电源可能切换到低功耗调节器，输出纹波变大，影响射频性能。如果发现休眠唤醒后通信质量下降，可以测一下电源纹波，必要时在射频供电引脚上加滤波电容。

5.4 电池电量显示不准

电量计是低功耗设备的重要功能，但做准不容易。电池电压和剩余电量不是线性关系，而且受温度、放电电流、电池老化影响。

nPM1300内置的电量计基于电压和电流综合估算，比单纯测电压要准。但即便如此，也需要在软件上做校准。我的做法是：

• 在实验室做几次完整的充放电循环，记录电压、电流、温度、剩余电量的对应关系；
• 把这些数据拟合成曲线，写入固件；
• 在实际使用中，根据电压和电流查表估算电量；
• 定期在满充和放空时校准，修正累积误差。

对于成本敏感的产品，如果不需要精确电量显示，可以用简单的电压阈值法：高于4.0V显示满电，3.7V显示中等，3.5V显示低电，3.3V以下显示需要充电。虽然不准，但用户能看懂就行。

5.5 常见问题速查表

这张表可以贴在工位上，遇到问题先对照排查，能省不少时间。

6. 一些个人体会和后续可以折腾的方向

低功耗设计这件事，做久了会发现它不只是技术问题，更是一种思维方式。你会开始关注每一个微安的去向，会习惯性地问“这个操作能不能放到休眠前做”“这个外设能不能晚点开早点关”“这个数据能不能攒一批再发”。这种思维方式一旦形成，你做出来的产品自然就省电。

我自己的经验是，低功耗优化永远没有“完成”的时候。第一版做到休眠电流10微安，觉得不错了；后来发现某个IO配置改一下能降到5微安；再后来发现换个LDO又能降2微安。每一次优化可能只省几微安，但积累起来就是续航从一年到三年的差别。

后续如果想继续深入，有几个方向可以折腾：一是研究MCU的低功耗定时器和自动唤醒机制，让系统在休眠时也能定时采集，进一步降低CPU参与；二是尝试能量采集技术，用太阳能、振动、温差给设备供电，彻底摆脱电池更换；三是把嵌入式AI和低功耗结合，在本地做简单推理，减少无线传输次数，从而降低整体功耗。

搞块板子容易，把低功耗做好不容易。但正是这种不容易，让这件事值得做。