一种利用实时时钟降低嵌入式系统功耗的方法
[导读] 众所周知，低功耗已经是衡量一个嵌入式系统的重要指标。而作为嵌入式系统的核心，嵌入式CPU的功耗则对整个系统起着重要的作用。
关键词：eCos实时时钟飞思卡尔ARM
1.嵌入式CPU低功耗模式介绍
众所周知，低功耗已经是衡量一个嵌入式系统的重要指标。而作为嵌入式系统的核心，嵌入式CPU的功耗则对整个系统起着重要的作用。当前流行的嵌入式系统CPU，基本都提供低功耗特性。一般而言，当嵌入式CPU都会有工作模式与低功耗模式，而低功耗模式又可进一步分为空闲模式，休眠模式，睡眠模式等。进入低功耗模式后，CPU的功耗会降低很多。而外部中断发生时，可以将CPU唤醒。一个嵌入式系统运行起来后，当系统进入idle状态时，就可以让CPU进入低功耗模式，而当外部中断发生时，再唤醒CPU，重新回到工作模式。让CPU尽可能多的处于低功耗模式，可以大大降低系统的功耗。然而，即使系统处于idle而且没有别的工作要做，系统实时时钟的中断，也会不停的唤醒CPU，从而增加系统功耗。因此，可以考虑对系统实时时钟的中断进行修改，从而减少对系统功耗的影响。
2．系统实时时钟与功耗的关系分析
在目前的嵌入式系统中，系统实时时钟一般是一个硬件循环计数器。当硬件计数器计到一定数值时会向CPU发出中断。系统实时时钟是现代多任务嵌入式操作系统的重要组成部分，因此我们需要先讨论一下嵌入式操作系统与系统实时时钟的关系。当今的嵌入式操作系统一般都支持多任务，优先级和时间片调度。当嵌入式OS运行起来后，一般都有一个IDLE任务，它的优先级最低，而其他任务的优先级都应该比它高。在优先级调度机制中，只有当系统中其他高优先级任务都处于阻塞状态时，它才有机会运行。时间片调度机制只对同优先级的任务有效。也就是说，不同优先级的任务之间是不会按时间片调度轮转的，而是按优先级来调度的。因此当系统进入IDLE任务时，可以认为系统中没有工作要CPU来做，系统为idle状态。当时间片调度机制开启后，嵌入式OS就会根据时间片来调度任务。也就是当一个时间片用完后，要运行调度器来决定下一个时间片的归属。时间片的基本单位是系统tick，而系统tick是以系统实时时钟为基础的。当系统实时时钟中断产生时，CPU会将系统tick加1。每当系统tick增加n（一个时间片）时，嵌入式OS将启用调度器进行时间片调度。因此，当时间片调度机制开启后，就需要系统tick的实时更新和调度器的定时运行，也就需要实时时钟中断以很高的频率定时产生。如果关闭时间片调度机制，则任务之间只需要按照优先级来调度，这样就不需要计算时间片，也就是系统tick不用实时更新，实时时钟的中断不必以很高的频率产生，调度器也不用定时运行。这样就有可能考虑延长实时时钟的中断间隔。同时调度器不需要进行时间片调度，可以节省系统开销。但关闭时间片调度后，系统就只有优先级调度。这就要求系统的所有任务要主动阻塞，而不要期待调度器把同优先级的其他任务调度出CPU而让自己运行。在目前流行的嵌入式操作系统中，一般都提供了很多主动阻塞的机制，因此要做到这一点并不难。延长实时时钟的中断间隔，可以让CPU长期处于低功耗状态，直到有设备中断唤醒CPU。这样将大大减低系统在空闲时的功耗。延长实时时钟中断间隔后，需要考虑的问题有两个，一是系统tick，另一个是系统delay。系统tick是实时时钟和操作系统之间的接口，操作系统与时间相关的模块和API，基本都是基于tick的。在一般系统中，实时时钟的中断是每个tick一次。因此tick是操作系统最小的计时单位。延长实时时钟中断间隔后，系统tick就会长时间不增加，因此怎样保证系统tick的准确性，就是最基本的问题。解决了tick的准确性，就可以隔离实时时钟对操作系统的影响。系统delay是操作系统一种重要的阻塞机制，它主要用于让一个任务主动让出CPU一段时间。一般系统delay是基于系统实时时钟的，系统delay的基本单位就是tick。当调用delay时，API函数会首先得到当前系统tick，然后加上需要delay的时间，形成一个未来的delay时间点，再将任务挂到系统的delay队列上。因此delay队列上的所有任务都对应一个自己的delay时间点。当系统tick超过某个任务的delay时间点时，该任务就应该醒来。这就需要实时时钟的中断来唤醒CPU，并运行调度器让delay的任务重新进入就绪队列。如果实时时钟中断间隔延长，系统tick就会很长时间不增加，就很难保证delay的准确性。同时delay时间到达后，也无法唤醒任务。要保证系统tick的准确性，就要求每次主动获得系统tick时，需要通过实时时钟硬件计数器的值计算出当前的系统tick。同时，需要保证主动获取和实时时钟中断之间的同步。而对于系统delay，则需要修改硬件计数器的计数值，使其为系统delay队列上的最小delay时间点的delay时间。这样可以利用硬件计数器来准确控制delay的准确性，并且利用中断来及时调度任务。
3．在I.MX51上的解决方案：
ECOS是一款优秀的轻量级嵌入式操作系统，它的内核微小，紧凑，支持多任务，优先级和时间片调度机制。飞思卡尔的多媒体芯片i.mx51基于ARM Cortex-A8核，具有很高的性能，同时支持了ARM提供的低功耗功能。ARM提供低功耗模式，即睡眠模式。ARM执行指令WFI后，会进入睡眠状态。在睡眠模式下，ARM的时钟被关闭，ARM只消耗极低的功耗来维护自身的状态，即启用SRPG（State retaining power gate）。当有中断发生时，ARM会被唤醒，恢复时钟，重新开始执行。MX51提供了多个硬件计数器，本文采用其中的GPT作为实时时钟。GPT是一个循环计数器，可以设置最大为0xffffffff的计数值，每个时钟计数值减1，当计数值减到0时触发中断，时钟为32KHz。GPT的计数值可以在任意时刻被ARM读取，读取是不影响计数的。当IDLE任务运行时，IDLE就执行WFI指令，让ARM进入低功耗模式。如果有设备产生中断，ARM就会被唤醒，处理中断以及所需的任务调度，任务运行。基于前面的分析，本文对ECOS的时间片调度和实时时钟系统进行了修改。对于时间片调度机制，在ECOS的配置文件中将其关闭。对于实时时钟，则延长了它的中断间隔。系统tick在两种情况下会被更新，一种是当调用ECOS API去读系统tick的时候，另一种就是GPT产生中断。当ECOS启动后，将GPT的计数值设为最大，这样GPT就需要很长时间才会产生一次中断。在这期间，系统tick只会在ECOS API主动读取时才会更新。系统tick的更新是通过读取硬件计数器的计数值计算出来的。在ECOS系统的实时时钟类中增加一个变量pre_hardware_count用于记录上一次读取的硬件计数器的值。当每次系统API读取tick时，当前硬件计数器的值与上一次读取时硬件计数器的值的差值就是两次读取之间已经过去的tick数。当实时时钟产生中断时，即硬件计数器计到0，将此变量清零。这样，就可以保证每次读取系统tick 时，能得到一个准确的系统tick值。当有任务要主动延时一段时间，即调用系统delay API时。ECOS的API函数会计算出该任务的delay时间点，然后将该任务挂入系统delay队列。然后遍历系统delay队列，找出队列中的最小delay时间点，把该delay时间点对应的delay时间写入GPT，让GPT来控制delay时间。delay时间到后，GPT会产生中断，ECOS将中断处理程序分为两部分，ISR和DSR。在ISR中将硬件计数器设为最大值。然后在DSR中增加系统tick，将超时的任务重新挂入就绪队列，并且再次找出系统delay队列上的最小delay时间点，写入硬件计数器。如果系统delay队列为空，则不对硬件计数器再进行操作，保持ISR 中写入的最大值。最后ECOS会运行调度器，如果超时的任务具有最高优先级，那么它就会得到运行，也就是醒过来。这样也就可以保证系统delay的准确性与及时性。下图是修改后实时时钟后系统tick， delay以及调度器相关的流程图。
下图是修改后实时时钟后系统tick， delay以及调度器相关的流程图。
下面是在飞思卡尔公司i.mx51上的实验数据。
可以看出，修改了时间片调度和实时时钟后，不论ARM工作在哪个电压点，系统IDLE时的功耗降低了差不多10倍。因此，延长实时时钟中断间隔能极大的降低系统功耗。
4．其他系统的类似方法
当前流行的嵌入式操作系统Linux和WinCE也都在讨论修改系统实时时钟中断方式以求降低系统功耗。对于Linux系统，有一个Less Watts项目，实现tickless idle，即无tick的idle，其实就是修改实时时钟的中断方式。WinCE则提供了可变系统时钟节拍Variable Tick Scheduler，在进入idle状态前改变系统时钟节拍，这样在预期的时间段里，idle状态不会被无谓的系统时钟中断唤醒。
5．结论
可以看出，通过修改实时时钟中断方式，可以使CPU在idle状态下长时间处于低功耗模式，极大的降低系统功耗。而且当前流行的嵌入式操作系统都在积极的探讨此方法。相信今后这项功能会成为嵌入式操作系统必备的一个功能。
没想到差别这么大 感觉意义不大，真要求低功耗，电流肯定要降到更小，而且一般也不会考虑上OS。
既然用上OS了，就别计较那一点点电流了。 xjmlfm1 发表于 2014-9-21 10:22
感觉意义不大，真要求低功耗，电流肯定要降到更小，而且一般也不会考虑上OS。
既然用上OS了，就别计较那一 ...
首先用OS是因为你裸奔达不到那样的功能要求，低功耗是在能达到功能要求的基础上做到最小功耗。苹果的工业设计在全球也算是领先的了，为啥做出的手表还只能待机一天呢？在没有解决电池的储能问题前，低功耗的路还很长。 步之道 发表于 2014-9-21 12:43
首先用OS是因为你裸奔达不到那样的功能要求，低功耗是在能达到功能要求的基础上做到最小功耗。苹果的工业 ...
在实际开发过程中，苹果离我们还是比较遥远的。
我们不会去做苹果那样的产品，所以一般也不会有那么苛刻的要求。
常见的低功耗产品，一般也就是带个段位屏显示，再测个温什么的，顶多再加个无线通信模块，这类产品，一般是不需要上OS的。
但是在这类产品中，对电流的要求却很苛刻，能降低1uA，就一定要想办法降下来。 ti 的cc2540 运行BLE 的操作系统就是在空闲的时候用32K的时钟运行，达到低功耗的目的，， xjmlfm1 发表于 2014-9-21 16:13
在实际开发过程中，苹果离我们还是比较遥远的。
我们不会去做苹果那样的产品，所以一般也不会有那么苛刻 ...
手持设备里有很多用到LCD/OLED显示屏的，这些设备大多数都有OS，这样的应用场景很多，你说的手持加个数码管那些还用不到os不在讨论范围内. xjmlfm1 发表于 2014-9-21 16:13
在实际开发过程中，苹果离我们还是比较遥远的。
我们不会去做苹果那样的产品，所以一般也不会有那么苛刻 ...
别自己蒙上眼睛，不看外面的世界。
想想，如果你能做苹果那样的产品，薪水至少是现在的10倍，有诱惑吧？ 值得学些。 wingerchen 发表于 2014-9-21 19:07
别自己蒙上眼睛，不看外面的世界。
想想，如果你能做苹果那样的产品，薪水至少是现在的10倍，有诱惑吧？ ...
着实，这话我本来想告诉刚刚那位坛友的，就是有很多人觉的自己不能做，然后就原地踏步了，我们尽管现在做不了，但是我们可以朝那个方向努力。哪怕只有一点点的进步。就算山寨也能山寨的很有创意。。。 轻风 发表于 2014-9-21 16:50
ti 的cc2540 运行BLE 的操作系统就是在空闲的时候用32K的时钟运行，达到低功耗的目的，， ...
TI的东西一直都很好，就是价格不太喜人，哈哈 LZ是在写论文吗 majialou 发表于 2014-9-21 20:34
LZ是在写论文吗
不是，只是看到这篇文章有感，和大家一起探讨一下基于OS下的低功耗。 以前没考虑到这一点，想一想从睡眠中醒来再时钟起动，时间也不短呢。学习了。 stm32f10x系列的mcu，进入低功耗睡眠后，实际电流还是比较大，也就是外设电流是比较大的，不过在cortex-A8这种级别的处理器上，结果就不同了，估计外设没有mcu丰富了。。。。进入低功耗有个很大的好处就是抗干扰会好不少，不容易跑飞啊哈哈 divineliu 发表于 2014-9-21 22:03
以前没考虑到这一点，想一想从睡眠中醒来再时钟起动，时间也不短呢。学习了。 ...
其实睡眠是一种很有效的降低功耗的方式，只是唤醒后需要将所有的进程都加载进来，难免有点慢。 myxiaonia 发表于 2014-9-21 22:19
stm32f10x系列的mcu，进入低功耗睡眠后，实际电流还是比较大，也就是外设电流是比较大的，不过在cortex-A8 ...
如果功耗过高，在手持设备上就是个灾难。 这个方法还是有意义的，就是要修改系统内核，如果系统更新了，还要再修改，再更新了，又要修改。。。这样就有点麻烦了 新版freertos上已经实现低功耗功能，就是通过修改delay实现，计算好下次唤醒时间后进入待机模式， cpu可以通过时间到的定时中断或者外部触发中断唤醒 liwei_jlu 发表于 2014-9-21 23:52
新版freertos上已经实现低功耗功能，就是通过修改delay实现，计算好下次唤醒时间后进入待机模式， cpu可以 ...
如果是这样的话，rtx也是支持的 学习一下 学习了。多些其它RTOS例子就好了。 liwei_jlu 发表于 2014-9-21 23:52
新版freertos上已经实现低功耗功能，就是通过修改delay实现，计算好下次唤醒时间后进入待机模式， cpu可以 ...
和LZ文章说的方法是一样的，不是吗？
主要是还要维持正确的时钟计数。 wingerchen 发表于 2014-9-21 19:07
别自己蒙上眼睛，不看外面的世界。
想想，如果你能做苹果那样的产品，薪水至少是现在的10倍，有诱惑吧？ ...
飞卡的低功耗最的很好，降低了不少。具体英用不用回了 这篇文章写的有研究价值，很少有人去研究用这种方法去降低功耗。 xjmlfm1 发表于 2014-9-21 10:22
感觉意义不大，真要求低功耗，电流肯定要降到更小，而且一般也不会考虑上OS。
既然用上OS了，就别计较那一 ...
同意，真要低功耗，肯定之前就不会上OS，这种低能低多少，根本没有意义
低功耗作为首要要求的就不会是这种方案
wingerchen 发表于 2014-9-21 19:07
别自己蒙上眼睛，不看外面的世界。
想想，如果你能做苹果那样的产品，薪水至少是现在的10倍，有诱惑吧？ ...
作出什么样的产品跟拿多少钱关系真心不大，尤其在国内这种环境下
ccrt 发表于 2014-9-23 08:34
同意，真要低功耗，肯定之前就不会上OS，这种低能低多少，根本没有意义
低功耗作为首要要求的就不会是这 ...
如果你有一个手持产品用到多进程处理，怎么解决呢？不上OS，裸跑？目前产品上上os的很多，就举个简单的例子，国产山寨平板，大多数续航不长，用户体验不好，同样是win8.1系统，为什么没有微软的pro3做的好呢？大家都是成年人，考虑问题不很片面，就是因为os的功耗高，手持设备上都不用了。裸跑在低端产品上用用就算了，你看到哪个高端产品没有用系统。 步之道 发表于 2014-9-23 08:56
如果你有一个手持产品用到多进程处理，怎么解决呢？不上OS，裸跑？目前产品上上os的很多，就举个简单的例 ...
可能是因为我们理解低功耗的概念不同吧，
我说的低功耗是首先功耗是首要解决的问题，手持设备对低功耗的需求没有那么强烈吧。这种情况设计的时候肯定不会上OS
落跑能解决你所谓的多进程处理的方法多得很，当然代价是研发成本，另外这种需求也很少
讨论问题就讨论问题呗，别什么成年人啦，电子行业大的很，需求特殊的也多的很，解决方法也不少，没有必要扣帽子嘛
ccrt 发表于 2014-9-23 09:06
可能是因为我们理解低功耗的概念不同吧，
我说的低功耗是首先功耗是首要解决的问题，手持设备对低功耗的 ...
同样也同意你的观点
楼主说的也不是全无道理，只是有些片面。
楼主始终以苹果的手表，国产的PAD为例，可现在说的是飞思的M3系列的片子，显然它没法做PAD。
国产的PAD，包括国产的手机，确实需要降功耗，不可否认，但这些产品离我们普通的开发人员，还是有距离的。
相信在华为、中兴、小米做开发的，没有多少混这个论坛的吧，普通人，除了刚毕业的大学生，以后进入这个行业的可能性也不大。
所以一开始就说，楼主发的这帖子意义不大，因为一般人用不上。
相信坛里的大多数人，都是做工业上的产品，工业上的产品，如果要求低功耗，基本上不太可能上OS。 非常好的想法，适当降低实时钟的中断频率，但是带来另一个问题得考虑进去：基于该时钟节拍的就得小心了，得做相应的调整 今天又学习了一个不错的降低功耗的方法，谢谢分亨。 学习 .
页:
[1]