第1章：PM Framework核心数据结构解析
各位同学，今天我们来聊聊NuttX电源管理框架里最核心的几个数据结构。说实话，这部分内容看起来有点枯燥，但它是整个PM子系统的基石。我在做低功耗项目时，就因为对这几个结构体理解不够深，踩过不少坑。
1.1 pm_global_s结构体：全局状态管家
先看全局结构体。它管理着整个系统的电源状态。
struct pm_global_s
{
struct pm_domain_s domain[CONFIG_PM_NDOMAINS];
mutex_t lock;
sem_t wait;
uint32_t wake_count;
};
这个结构体不大，但每个字段都很关键。我一个个说。
domain数组：系统可以有多个电源域。比如CPU核心是一个域，外设是另一个域。CONFIG_PM_NDOMAINS这个宏决定了最大域数量。我建议你根据实际硬件来配置，别贪多。
lock互斥锁：多线程环境下，状态切换必须加锁。我曾经遇到过不加锁导致两个任务同时切换状态，系统直接挂掉的情况。嗯，血的教训。
wait信号量：当系统要进入睡眠时，需要等待所有任务就绪。这个信号量就是干这个的。
wake_count：唤醒计数器。每次唤醒加1，防止重复唤醒。说白了就是个防抖机制。
重要提示：pm_global_s是单例的，整个系统只有一个实例。你可以在任何地方通过pm_globals这个全局变量访问它。
1.2 pm_domain_s结构体：域级别的状态管理
接下来看域结构体。每个电源域都有自己的状态机。
struct pm_domain_s
{
struct pm_state_s state[PM_COUNT];
uint8_t cur_state;
uint8_t prev_state;
uint32_t state_time[PM_COUNT];
uint32_t domain_id;
sq_queue_t callback_list;
};
这里有几个设计细节，我重点讲一下。
state数组：每个域有多个状态。PM_COUNT定义了状态数量，通常是4个（NORMAL、IDLE、STANDBY、SLEEP）。每个状态都对应一个pm_state_s结构体。
cur_state和prev_state：当前状态和上一个状态。为什么要记录上一个状态？因为状态回退时需要知道从哪来。我在做音频播放器时，就利用这个实现了快速唤醒。
state_time数组：记录每个状态的累计运行时间。这个数据对功耗分析很有用。你可以用它来算平均功耗。
domain_id：域编号。从0开始。我个人习惯把CPU域设为0，外设域设为1。
callback_list：回调函数队列。当状态发生变化时，会通知注册的回调。这个设计很巧妙，实现了观察者模式。
小技巧：回调函数的注册顺序会影响执行顺序。我建议把关键任务（比如保存寄存器）放在前面。
1.3 pm_state_s结构体：状态描述符
这个结构体描述了一个具体的电源状态。
struct pm_state_s
{
enum pm_state_e state;
uint32_t min_time;
uint32_t max_time;
uint32_t enter_latency;
uint32_t exit_latency;
uint32_t power_consumption;
};
每个字段都有它的意义。
state：状态枚举值。NORMAL=0，IDLE=1，STANDBY=2，SLEEP=3。数值越大，功耗越低。
min_time和max_time：这个状态允许的最短和最长时间。为什么要限制？因为有些状态进入和退出有开销。如果只待1ms就退出，那还不如不进去。
enter_latency和exit_latency：进入和退出的延迟。这两个值很关键。我做过一个项目，SLEEP状态的退出延迟是5ms，但业务要求响应时间不超过3ms。最后只能放弃SLEEP状态，改用STANDBY。
power_consumption：该状态下的功耗。单位是微瓦。这个值通常来自芯片手册。
注意：min_time必须大于enter_latency + exit_latency。否则进入这个状态反而更耗电。我曾经就犯过这个错误，调试了整整两天才发现。
1.4 状态机定义与转换
好了，结构体看完了。现在说说状态机怎么转。
NuttX的PM状态机是一个线性模型。状态只能逐级切换，不能跳级。比如从NORMAL只能到IDLE，不能直接到SLEEP。
enum pm_state_e
{
PM_NORMAL = 0,
PM_IDLE,
PM_STANDBY,
PM_SLEEP,
PM_COUNT
};
状态转换的规则是这样的：
- 降级：NORMAL → IDLE → STANDBY → SLEEP。每次降一级。
- 升级：SLEEP → STANDBY → IDLE → NORMAL。也是每次升一级。
- 强制转换：特殊情况可以跳级。比如收到紧急中断，直接从SLEEP回到NORMAL。
为什么会设计成线性模型？你想想看，如果允许随意跳转，状态机的复杂度会成倍增加。而且硬件上，很多外设的恢复也需要逐级进行。
状态转换的触发条件主要有三种：
- 空闲检测：系统空闲时间超过阈值，自动降级。
- 中断唤醒：外设中断触发，系统升级。
- 应用请求：应用程序主动调用PM接口请求状态变更。
我记得有一次做物联网网关，设备在SLEEP状态下收到网络数据包。按照正常流程，应该先升到STANDBY，再升到IDLE，最后到NORMAL。但网络协议栈要求快速响应，我只好用了强制转换，直接从SLEEP跳到NORMAL。嗯，这个优化让响应时间从15ms降到了3ms。
核心要点：状态转换的核心函数是pm_changestate()。它会遍历所有域，检查每个域是否可以转换。只有所有域都同意，状态才会真正改变。
最后说一个避坑指南。我曾经在状态转换的回调函数里调用了pm_changestate()，结果造成了递归调用，栈溢出了。所以记住：回调函数里不要做状态转换操作。如果确实需要，用工作队列延迟执行。
好了，这一章的内容就到这里。数据结构是PM框架的骨架，理解了它们，后面的内容就好办了。下一章我们讲PM框架的初始化流程，到时候会看到这些结构体是怎么被创建和配置的。