1、低功耗设计概述：为什么智能音箱需要低功耗？待机模式的定义与分类

1.1 为什么智能音箱必须死磕低功耗？

说实话，我刚入行那会儿，也觉得低功耗就是个锦上添花的事。直到有一次，我负责的一款智能音箱因为待机功耗没控制好，用户反馈说「晚上充满电，第二天早上就剩60%了」。你想想看，这产品还怎么卖？

智能音箱这玩意儿，跟手机不一样。手机你一天一充，大家习惯了。但音箱呢？它是个「常驻设备」。用户希望它永远在线，随时待命。你喊一声「小爱同学」，它得立刻回应你。如果它为了省电把自己关机了，那用户体验直接归零。

所以，低功耗不是可选项，是必选项。我总结下来，核心原因就三条：

• 用户体验的底线：用户不希望频繁充电。待机功耗每降低1mA，续航可能延长好几天。
• 散热与可靠性：功耗高了，发热就大。音箱内部空间紧凑，散热不好会加速元器件老化。我见过一个项目，就是因为待机时电源管理芯片过热，导致电容鼓包。
• 法规与认证：欧美市场对待机功耗有严格限制（比如欧盟的ErP指令）。不达标，连上市资格都没有。

1.2 待机模式到底是什么？

很多人以为待机就是「关机」。其实不是。待机是一种「浅睡眠」状态——系统还在运行，只是降低了活动频率。我习惯把待机模式分成三类，这样设计起来思路更清晰：

模式名称	典型功耗	唤醒延迟	典型场景
深度待机	< 100μA	1~3秒	用户长时间不交互，比如深夜
浅度待机	1~5mA	< 100ms	用户可能在附近，随时会唤醒
语音唤醒待机	10~50mA	< 10ms	麦克风阵列持续监听，等待唤醒词

嗯，这里要注意。这三种模式不是互斥的，而是可以动态切换的。我做过一个项目，就是根据环境光传感器和加速度计来判断用户是否在附近，自动在深度待机和语音唤醒待机之间切换。

1.3 待机模式的设计原则

我个人习惯，在设计待机模式时，会先问自己三个问题：

1. 唤醒源是什么？——是按键？语音？还是定时器？不同的唤醒源决定了哪些模块必须保持供电。
2. 唤醒延迟能接受吗？——语音唤醒必须毫秒级响应，但定时上报数据可以容忍几秒延迟。
3. 哪些外设可以断电？——Wi-Fi模块、LED指示灯、音频功放，这些在待机时基本可以关掉。

1.4 低功耗设计的「三板斧」

说白了，低功耗设计就三招：

• 砍掉不必要的供电：用负载开关或PMOS管，把不用的外设彻底断电。我习惯在原理图上标注「待机断电域」和「常供电域」。
• 降低时钟频率：主控芯片在待机时，把CPU频率降到最低，甚至进入休眠模式。比如Cortex-M4的WFI指令，功耗能降一个数量级。
• 优化唤醒策略：不要一有中断就全系统唤醒。可以用一个低功耗的MCU做预处理，比如先判断是不是有效唤醒词，再决定要不要唤醒主控。

举个例子，我做过一个语音唤醒方案：

// 伪代码：低功耗语音唤醒流程
while(1) {
    // 1. 进入深度睡眠，只保留麦克风和DMA
    enter_deep_sleep();
    
    // 2. 检测到声音超过阈值，自动唤醒
    if (audio_level > THRESHOLD) {
        // 3. 启动轻量级语音识别（只识别唤醒词）
        if (detect_wake_word()) {
            // 4. 确认是唤醒词，才唤醒主系统
            wake_up_main_system();
        } else {
            // 5. 误唤醒，继续睡
            continue;
        }
    }
}

这个方案的好处是，大部分时间系统都在深度睡眠，功耗只有几十微安。只有检测到声音时才进入浅度待机，功耗升到几毫安。而真正唤醒主系统，只发生在确认唤醒词之后。

1.5 小结

低功耗设计，说白了就是「在正确的时间，给正确的模块，提供正确的电量」。不要一上来就想着把所有东西都关掉，那样反而会出问题。我建议你先画出系统的功耗状态机，明确每个状态的功耗目标和唤醒条件，然后再逐模块优化。

下一章，我会详细讲讲如何用PMU（电源管理单元）来实现这些待机模式的切换。到时候我会分享一个我踩过的坑——关于PMU的时序配置，差点让整个项目延期。嗯，到时候细说。