介绍
本篇介绍下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）
Tickless原理还是没理解
建议多用，用起来，才有更多的收获。功耗调好的同时，会加强对功耗管理的理解。
可以对比其他的OS，如linux、freertos等，了解他们的PM管理思路。比较一下功耗控制的优缺点，保证使用时，心态的平衡。
RT-Thread PM框架的设计目标
解决使用者在使用RT-Thread操作系统时，面临的功耗管理问题。
解决多外设、多线程、多场景下，功耗管理的难题。
通过管理策略，让使用者真正掌握功耗管理方法。
PM2.0测试Demo：
基于stm32l4，后期会更多平台的适配！
地址：
原作者：张世争
0
/5 
工商网监
湘ICP备2023018690号
953
淘帖
9
