RT-Thread-RT-Thread PM组件2.0更新版 -- 介绍RT-Thread问答社区

RT-Thread PM组件2.0更新版 -- 介绍

发布于 2021-12-18 13:28:01 浏览：2618 订阅该版

[tocm]

[RT-Thread 电源管理与功耗调优系列 - 目录](https://club.rt-thread.org/ask/article/3419.html)

[RT-Thread PM组件2.0更新版 -- 使用指南](https://club.rt-thread.org/ask/article/3323.html)

[RT-Thread PM组件2.0更新版 -- 介绍](https://club.rt-thread.org/ask/article/3244.html)

[RT-Thread PM框架使用答疑 -- 01](https://club.rt-thread.org/ask/article/3198.html)

[RT-Thread PM框架使用答疑 -- 01](https://club.rt-thread.org/ask/article/3201.html)

[RT-Thread PM2.0 应用 -- 平台适配篇](https://club.rt-thread.org/ask/article/2517.html)

[RT-Thread IDLE线程栈过小引起的调试异常](https://club.rt-thread.org/ask/article/292.html)

[RT-Thread 使能PM组件](https://club.rt-thread.org/ask/article/2287.html)

[实践：RT-Thread PM管理实战 系列](https://club.rt-thread.org/ask/article/2282.html)

[进阶：RT-Thread精通PM功耗调优 系列](https://club.rt-thread.org/ask/article/2296.html)

[上手：产品功耗管理与调优经验分享 系列](https://club.rt-thread.org/ask/article/2707.html)

## 前言
- RT-Thread PM2.0组件大概是2020.12.31更新，距今将近一年，PM2.0当时更新的主要是功耗管理思想方面，并增加了一些功耗管理的经验分享教程
- 经过近两年的基于RT-Thread功耗管理经验，近期更新了RT-Thread PM2.0组件，算是对PM2.0的丰富与补充
- 更新PM框架的动机是让RT-Thread PM框架使用起来更简单、方便、易用
- 此次更新以【扩展】的方式，通过增加新的PM API的方式，让用户电源管理起来更【得心应手】，降低开发和使用难度。

## 为何更新
- RT-Thread PM2.0组件继承了老版本框架的【引用计数】【主动睡眠】思想，虽然引入了【PM模块化】、【被动睡眠】等思想，但毕竟这种【藕断丝连】的依赖关系，依旧会造成PM2.0框架实际项目使用起来弊端多多。
- 【PM模块化】没有独立模块化，只是增加了【module id】，虽然可以在功耗的管理中能标识睡眠模式谁请求的、谁造成了睡眠计数的增加，谁引起了【无法睡眠】，但是【引用计数】没有模块独立化，造成其他模块可以多次或【全部释放】某个【睡眠模式】，从而【释放了】其他模块请求的【睡眠模式】。
- 【tickless】低功耗运行的基础是进入深睡眠，降低频繁的唤醒，从而降低功耗。既然要【深睡眠】，如果系统的所有定时器都正常的工作，如何保证【深睡眠】的质量呢？
> 假如系统有50个定时器，如果进入【深睡眠】时这50个定时器依旧可以工作，那么在【tickless】模式下，这会形成【木桶效应】，即有一个【10ms】或更短周期的定时器存在，就会造成【系统】频繁的进入退出睡眠，这种情况下睡眠模式频繁切换引起的【额外功耗开销】会很大。
- 大部分情况下我们只希望极少的定时器工作在【深睡眠模式】，其他的定时器可以暂时【冻结】，等系统唤醒后再继续工作即可。手动管理各个定时器的开关与处理唤醒，无疑是一件【很头疼】的事情。
- PM2.0接口使用起来不够灵活，用户要时时刻刻查看PM的头文件，识记各个电源模式，必须很小心的【成对请求与释放】，才能保证PM框架正常运行。
- 以上弊端在较大项目的【功耗管理】中带来了较大的问题，增加了功耗管理难度，用户更希望PM框架更简单易用，无须牢记某些【规则】，遇到问题更能【快速定位与解决】
- 因此实践中得来的经验促使PM2.0框架持续完善与更新。

## PM2.0【年更版】特点
- 新增PM API接口，通过【扩展】【新增】的方式，让用户使用新的更易用的PM API接口，轻松使用【PM框架】，应对各种功耗管理难题。
- 增加lptimer管理框架，管理用户低功耗【深睡眠】模式下的定时器，优化【tickless】运行功耗
- 【PM模块化】优化，新增的PM API，各个PM模块独立的请求与释放，不再使用【引用计数】，请求释放不再【影响】其他的PM模块。

## 从【主动睡眠】到【被动睡眠】
- 很晚了一家人要准备睡觉了，一家人都躺在【床上】，才能【关灯睡觉】。
- 每个孩子上床可以睡在不同的【床位】，妈妈通过数床上的人数，如果【人数齐了】，就【关灯睡觉】，这是【引用计数】的思想。
- 妈妈下发【睡眠命令】，假如有几个孩子玩耍不上床睡觉，此时妈妈不能【关灯】，要等所有孩子都上床后，才能【关灯睡觉】，这是【主动睡眠】方式。
- 妈妈给每个孩子【取个名字】或【编号】，如果某个孩子没有上床睡觉，妈妈可以很容易的知道是哪个孩子没有上床，这个是【模块化思想】
- 妈妈给每个孩子一个【床位】，每个孩子只能睡在自己的【床位】，妈妈发现所有孩子都在自己的【床位】上，就【关灯睡觉】，如果发现某个【床位】空着，暂时不【关灯睡眠】，等所有【床位】都满了才会【关灯睡眠】，这是【被动睡眠】思想。
- 目前PM2.0更新版的整体思想是：【模块化】、【被动睡眠】，不建议使用【引用计数】。
- 新增的PM API不再采用【引用计数】
- 上版本的带引用计数的API依旧保留，但推荐使用新增的PM API。

## 模块化就无须计数
- 既然PM睡眠拆分成了各个电源子模块，如KEY、LCD、TP等等，计数就不再需要了，各个模块只需要在工作的时候简单的请求、退出的时候释放即可。
- PM子模块的独立请求与释放不影响其他PM子模块的请求与释放。
- 如果某个模块只请求不释放造成系统无法睡眠，可以通过调试打印出【睡眠请求列表】，查看是哪个模块请求造成的。

## 被动睡眠利于问题定位
- 被动睡眠的主要思想是：当所有模块都空闲了，请求的模式都释放了，系统才能进入【深睡眠】。
- 系统睡眠时无须再【主动】告知其他模块系统要睡眠了，无须通知各个业务做好睡眠准备等，每个PM子模块管理好自己即可。
- 被动睡眠如果【失败】，系统处于不正确的工作模式，此时通过打印出模块请求列表，即可轻松定位是哪个PM子模块引起的。

## 低功耗定时器管理
- 系统大部分的工作往往都是【定时】、【中断】、【轮询】触发的。
- 大的项目定时器用的很多，有周期很短的定时器，有周期较长的定时器。
- 大部分定时器开启后很少主动去关闭
- 大部分【深睡眠】场景，都希望只运行几个特殊的【定时】任务。
- 如何让【运行模式】下的普通定时器，在进入【深睡眠】后不工作，即不频繁唤醒系统呢？
- 如何让某些【特殊定时器】，可以【全天候】工作，即可以在【运行】与【深睡眠】下都可以工作呢？
- PM2.0 更新版，增加了【低功耗定时器lptimer】的管理功能，目的是让系统【深睡眠】睡的【更香】，功耗更容易控制

## 小结
- RT-Thread PM框架的【完善】与【更新】离不开大家的使用、建议、经验分享。
- RT-Thread PM框架，会不断的完善与更新，发挥其【价值】，帮助用户解决功耗管理问题
- 希望大家多多提出宝贵的建议、想法，分享电源管理的经验，让PM框架持续更新优化