RT-Thread-RT-Thread精通PM功耗调优 - Tickless篇RT-Thread问答社区

RT-Thread精通PM功耗调优 - Tickless篇

发布于 2020-11-27 09:27:24 浏览：2087 订阅该版

[tocm]

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

[RT-Thread精通PM功耗调优 - 思想篇](https://club.rt-thread.org/ask/article/2296.html)

[RT-Thread精通PM功耗调优 - lptimer篇](https://club.rt-thread.org/ask/article/2300.html)

[RT-Thread精通PM功耗调优 - 引脚篇](https://club.rt-thread.org/ask/article/2304.html)

[RT-Thread精通PM功耗调优 - 线程篇](https://club.rt-thread.org/ask/article/2305.html)

[RT-Thread精通PM功耗调优 - 外设篇](https://club.rt-thread.org/ask/article/2307.html)

[RT-Thread精通PM功耗调优 - Tickless篇](https://club.rt-thread.org/ask/article/2324.html)

[RT-Thread精通PM功耗调优 - 专用LOG篇](https://club.rt-thread.org/ask/article/2338.html)

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

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

[应用：PM组件应用与经验分享 系列](https://club.rt-thread.org/ask/article/292.html)

## 背景

* 让别人的思想装到自己的脑袋里，这不仅需要威逼利诱，还需要讲清楚原理。喜欢才能接受。

* 功耗基本的调试手段，估计前面讲了很多，或许只有少数人群可以接受。

* 更有极少的人，了解了整个功耗管理的体系、原理，愿意接受这样的【安排】。

* 这里的功耗调优思路，其实只是解决功耗问题的一种思路，并不是框架。

* 解决问题，自古以来，都是千奇百怪，秒在【奇】。

## 介绍

* 本篇介绍下Tickless的工作原理。

* Tickless 可以理解为：tick-less，tick or little tick。

* tick定时器主要指系统的脉搏，如systick，滴答定时器。好比是人的心脏产生的脉搏，不能停。

* 人在运动的时候，心脏跳的很厉害，心率提高到如120Hz/min，人在空闲休息的时候，心率也变慢了，如60Hz/min。

* 除了人类，其他动物，也有调节心率的能力。

* 如果嵌入式产品，在【繁忙的时候】，提供较高的tick频率，如（间隔1ms） 1000Hz，而在空闲或是睡眠的情况下，tick频率降低，如(1S一次）1Hz，是不是这样，会降低功耗呢。答案是肯定的。

## 繁忙与空闲的判断

* 如果能拿到当前系统是否繁忙的标志，那么，就可以让下一个或几个tick中断，不产生。【如拿到下一次调度的timeout】。

* 紧急事件，如串口通信、按键中断、alarm事件、周期性的定时事件，可以打断MCU，让MCU唤醒并投入到工作中。

* 有一些RTOS，通过获取下一个调度的timeout，通过timeout的长短，减少tick的产生，移除部分tick，并采取不同的睡眠策略。如timeout很长，则进入深睡眠，timeout很短，进入轻睡眠或不睡眠。

* 紧急的处理任务（非中断），需要【主动请求】PM，根据任务的运行情况，执行不同的睡眠策略。

## RT-Thread的Tickless实现思路

* 在进入SLEEP睡眠时，开启lptimer（低功耗定时器，用于睡眠时的唤醒），拿到当前系统的最近的定时器timeout。判断是否即将超时。若即将超时，则不睡眠，否则，原系统的（如systick）定时器，更换为Lptimer，定时器的超时时间（剩余的），设置到lptimer，进入睡眠。

* 进入睡眠后，系统等待lptimer定时业务超时中断或其他唤醒事件中断的到来。

* 等待（睡眠）期间，无Tick产生。

* 被唤醒后，把lptimer切回原有的（如systick）定时器，更新tick（时钟补偿），恢复现场，处理唤醒业务。

* 唤醒业务处理完，再次进入睡眠，电源模式切换循环运行。

## Tickless在哪里执行？

* 在idle线程执行。

* 换为其他的线程，也可以，但要考虑的更多，如线程间的同步等。

* idle线程的优势为，能感知其他线程空闲与否，并且随意被抢占，保证正常的业务持续、正常的执行。

* 手动创建PM管理线程，你也需要设置较低的线程优先级，等其他线程空闲下来或挂起后，再睡！！否则，你是以【睡眠优先】，而不是【业务优先】，设计功耗。

## 为何不能一直使用lptimer作为tick源？

* 既然开启了lptimer，为何不把系统的tick，用lptimer代替，切来切去，会产生切换开销！

* 可以的，如果MCU支持这样的timer，可以唤醒深睡眠，并且是32位（或64位）的。

* 如果没有，先这样用！要结合现实。

## 睡眠模式的决策

* RT-Thread PM框架，采用【主动请求式】的方法，处理紧急的业务操作。

* 业务操作，为了在较高的睡眠模式下工作，需要主动请求较高的睡眠模式（如：不睡眠）。

* 如果业务很重要，包括一些软业务（运行期间不产生中断，如算法执行），这时可以请求【不睡眠】。

* 如果业务要实时按时完成，你不进入任何系统睡眠模式，保证高速的快速运行并完成，这时需要主动请求【不睡眠】。

* PM框架收到多个睡眠模式，会决策采用最高功耗的睡眠模式执行，满足所有业务的需求。

* PM框架没收到任何请求，会决策采用最低功耗的睡眠模式执行（如DeepSleep）。

## 开启PM框架，但不主动请求睡眠模式，框架还能工作吗？

* 系统会默认进入深睡眠，运行在Tickless模式下。PM初始化时可以配置深睡眠的模式，默认为DEEPSLEEP模式，可以根据实际需求，配置为其他模式，如轻睡眠模式。

* 中断式的业务，基本能运行。

* 定时的业务，可以正常运行。

* 软业务（消息队列、软件查询的，如软件I2C，算法运行等），可能会有被睡眠打断的风险。（此时需要考虑主动请求不睡眠）

## RT-Thread 请求【不睡眠】，必须在每个线程里添加吗？

* 理论上不需要全部，只需要处理特殊的实时操作业务。

* 大部分的业务，因为本身有中断、timer等唤醒源，会按时执行。

* 请求后，处理业务，处理后，需要释放请求。

## PM2.0框架新特点：

* 增加模块ID的标识，保证业务正常执行的同时，让功耗管理更加的方便，清楚哪些业务频繁的执行，功耗点在哪里。

* 增加【延迟睡眠】的功能，开机初始化，这时，需要保证系统正常的初始化，期间，不执行任何睡眠。如LCD刷屏，你可以在收到刷屏指令后，延时指定时间睡眠，保证刷屏显示正常。（延迟睡眠，非软件延时）

* 更新了一系列使用教程与应用笔记，基本兼容上版的框架，用起来，可能更清楚些。

* PM2.0是伴随目前这个几个应用文档开发的。

## RT-Thread PM 睡眠的深度的决策算法

* 执行请求中最高功耗的睡眠模式

* 没有任何请求，默认最低功耗模式（DEEPSLEEP）

<br>

| 决策模式 | MODE_NONE | MODE_IDLE | MODE_LIGHT
| ---- | :----: | :----: | :----: |
|MODE_NONE |1|X|X|
|MODE_IDLE |0|1|X|
|MODE_LIGHT|0|0|1|
|MODE_DEEP |0|0|0|

<br>

## Tickless原理还是没理解

* 建议多用，用起来，才有更多的收获。功耗调好的同时，会加强对功耗管理的理解。

* 可以对比其他的OS，如linux、freertos等，了解他们的PM管理思路。比较一下功耗控制的优缺点，保证使用时，心态的平衡。

## RT-Thread PM框架的设计目标

* 解决使用者在使用RT-Thread操作系统时，面临的功耗管理问题。

* 解决多外设、多线程、多场景下，功耗管理的难题。

* 通过管理策略，让使用者真正掌握功耗管理方法。

## PM2.0测试Demo：

* 基于stm32l4，后期会更多平台的适配！

* 地址：

```c
https://gitee.com/zhangsz0516/rtt_pm2。
https://gitee.com/zhangsz0516/rtt_pm_log
```

* 使用方法：详细阅读本系列相关的文档。

回到
底部

RT-Thread精通PM功耗调优 - Tickless篇

关于作者

张世争

相关文章

热门标签

本月文章贡献

RT-Thread精通PM功耗调优 - Tickless篇

关于作者

张世争

相关文章

推荐文章

热门标签

本月问答贡献

本月文章贡献