μC/OS-II内核扩展接口的低功耗模式
发布时间：2010-9-1 09:07
发布者：techshare
|
随着消费类电子产品的功能日益复杂，在其中移植或固化实时操作系统已不是新鲜事了，如手机、PDA等等。对于该类产品，低功耗特性往往占有举足轻重的地位。如何在操作系统层面上，尽量降低系统功耗，是一个值得探讨的问题。一般来说，嵌入式CPU都具有低功耗的工作模式，如果在任务调度的空闲时间，使CPU进入这种模式，就能大幅度降低系统功耗。 本文以嵌入式实时操作系统μC/OS-II在飞思卡尔8位单片机HCS08GT60上的移植为例，详细讨论如何利用μC/OS-II给出的内核扩展接口，实现一个低功耗的嵌入式实时系统；进一步分析如何选择一种合适的低功耗模式。μC/OS-II是一种可移植、可固化、可裁剪的可剥夺型多任务内核。由于其源码公开、注释详尽、内核设计概念清晰，已成为世界上学习和使用频率较高的实时操作系统。2000年7月，μC/OS-II V2.52通过了美国航空航天管理局的安全认证，其可靠性得到了进一步的验证。利用任务调度的空闲时间使CPU进入低功耗模式，以降低系统功耗这一思想在μC/OS-II内核设计之初就被注意到了。为此设计者特意留出了相应的内核扩展接口。用户可以利用此接口，实现一个实时的低功耗系统。 1 利用空闲任务扩展接口使CPU进入低功耗模式 实现μC/OS-II低功耗特性的方法很简单：用户可以利用μC/OS-II中空闲任务的扩展接口，使系统在空闲状态下进入某种低功耗模式，降低系统功耗；同时利用RTI信号作为时钟节拍，周期性地唤醒CPU。CPU被唤醒之后，将执行节拍中断服务程序，重新判断是否有任务处于就绪态。如果有，就执行该任务；如果没有，则重复上面的过程。 μC/OS-II最多可以管理64个任务，并为每一个任务分配一个不同的优先级。每一个任务有五种可能的状态——睡眠态、就绪态、运行态、等待态和中断服务态。μC/OS-II属于可剥夺型内核，也就是说，μC/OS-II总是运行进入就绪状态的优先级最高的任务。一旦优先级高的任务进入就绪态，就可以将CPU从低优先级任务中抢过来。 在μC/OS-II初始化时，会建立一个优先级最低的任务——空闲任务，在没有任务进入就绪态的时候，空闲任务就会开始运行。空闲任务会调用一个函数——OSTaskIdleHook()。这是留给用户使用的内核扩展接口。空闲任务实际上并没有什么事情可做①，只是一个等待中断的无限循环。因此用户可以利用OSTaskIdleHook()，使CPU进入低功耗模式。 ① 事实上，空闲任务可以为统计任务提供一个计数，用以统计CPU的利用率，但该工作完全可以在改动OSTaskIdleHook()之前运行。 用户不必担心整个内核因为系统进入低功耗模式而停止运行。因为HCS08GT60允许RTI时钟周期性地将CPU唤醒。唤醒之后的系统会和遇到节拍中断一样，进入OSTickISR()中断服务程序，查看是否有任务进入了就绪态。如果还没有，就再次进入低功耗模式。对于HCS08GT60，允许RTI时钟的低功耗模式有WAIT模式、STOP2模式和STOP3模式三种，其功耗、系统恢复时间、唤醒中断源等各不相同。下面介绍如何选择一种合适的低功耗模式。 2 选择合适的低功耗模式 2.1 HCS08GT60的低功耗模式 考虑到后面的讨论要涉及到具体的低功耗模式，所以首先介绍一下单片机HCS08GT60的低功耗特性。HCS08GT60属于飞思卡尔（原Motorola）HCS08系列单片机。该系列单片机的低功耗特性很突出；工作电压可以在1.8"3.6 V之间选择，有WAIT和STOP两种低功耗模式。STOP模式可细分为STOP3、STOP2和STOP1三种，功耗依次降低。WAIT模式下， CPU停止运行，但其他外围模块并不断电，因此，系统随时可以响应各种中断。HCS08GT60的三种STOP模式如表1所列。  从表1可以看出，在STOP1模式中，唤醒CPU只能通过IRQ中断或复位信号，由于无法提供时钟节拍，内核的任务调度无法实现；而在STOP2和STOP3中，RTI都可以作为系统的唤醒中断源，内核可以使用RTI作为时钟节拍。 STOP2模式与STOP3模式相比功耗更低；但是，STOP2模式下I/O寄存器是关闭的，必须在进入模式之前将I/O寄存器的值保存在RAM中，而在唤醒之后再从RAM拷贝到I/O寄存器。唤醒STOP2可以使用IRQ、复位信号和RTI。STOP3模式下，RAM和I/O寄存器内容将保持。另外，除STOP2模式允许的唤醒中断源外，还允许键盘中断唤醒CPU。 2.2 实时性、中断源和功耗影响低功耗模式的选择有三个主要因素：功耗、中断源和实时性 (1)功耗 前文中已经提到，适用于μC/OS-II的低功耗模式（即允许RTI唤醒）有三种：WAIT模式、STOP3模式和STOP2模式。系统在这三种模式下的功耗逐渐降低。表2列出了3.12 V供电下，三种模式的典型功耗。  μC/OS-II为用户提供了一个统计任务，用以计算CPU的利用率，并保存在变量OSCPUUsage（%）中。用户可以在加入低功耗处理前②，使用统计任务计算出CPU利用率，从而粗略地估算出系统的功耗。 ② 计算必须在改动OSTaskIdleHook()之前进行，因为一旦系统进入任何一种低功耗模式，空闲任务将不能给变量OSIdleCtr继续加1。 假设系统正常运行时，消耗电流为1 mA，CPU利用率是1%，则以下是选择三种不同低功耗模式后的消耗电流。 STOP2: 1 mA×1%+890 nA×99％=10.881 μA,系统功耗降低98.9%。 STOP3③: 1 mA×1％+14.5 μA×99％=24.355 μA，系统功耗降低97.6%。③ 使用以32 kHz晶振为时钟源的RTI。 WAIT: 1 mA×1％+560 μA×99％=564.4 μA，系统功耗降低43.6%。 系统功耗当然越小越好，但当考虑到其他因素时，系统功耗就未必能够达到最低了。 (2) 中断源 系统用到的中断源限制了低功耗模式的使用。为了保证μC/OS-II正常运行，系统所用到的中断必须能够唤醒处于低功耗模式下的CPU。 WAIT模式虽然功耗较大，但能够响应任何中断源；STOP3模式下，系统保留了RTI、IRQ、KBI和复位作为唤醒中断；而在STOP2模式下，只有IRQ、复位和RTI可以唤醒系统。 (3) 实时性 毫无疑问，使CPU进入低功耗模式会减弱系统的实时性。这种减弱来自于两个方面，一是使中断响应时间变长；二是使响应的时间变得不易预测。 系统从低功耗模式中被唤醒后，时钟往往需要一段时间稳定，有时候还需要软件做内核运行环境的恢复工作（如STOP2下的寄存器恢复），中断的响应时间就被拉长了。同时，由于时钟恢复的时间和供电电压、时钟源、环境温度都有密切的关系，实际上不可能给出一个准确的恢复时间，中断响应的时间也就变得不易预测了。在实时系统中，响应时间的不可预测往往比响应得慢更为致命，一个响应速率时快时慢的系统只能以最坏的情况作估计。所幸的是，大多数低功耗应用（如手机、PDA等）都不是硬实时系统，换句话说，并没有一个绝对的响应时间限制。大多数情况下，采用低功耗处理所带来的实时性减弱可以被忍受。 WAIT模式对响应时间影响最小。由于没有停止系统时钟，WAIT模式对中断的响应基本都是同步的。 STOP3模式恢复的时间和时钟设置关系很大。除了FBE时钟方案外(使用外时钟、不使用锁相环)，恢复时间都在100 μs左右。如果采用FBE，恢复时间就和晶振频率密切相关了。一般32 kHz晶振需要180～300 ms恢复稳定，假如在STOP3模式下将晶振保持打开，则只需要2.42 ms。 STOP2模式的恢复时间在50 μs④左右。但是，因为需要将在RAM中保存的I/O寄存器恢复，可能另外还需要几十个指令周期。④以上恢复时间均为实测值。 表面上STOP2的恢复时间比STOP3的恢复时间短，但是考虑到进入STOP2之后RTI时钟源会从外部晶振调整为内部晶振，最多可能与实际系统相差1个时钟节拍。 3 μC/OS-II在HCS08GT60上的移植 μC/OS-II的95％代码是由ANSI C写成的，具有很好的移植性。如何移植μC/OS-II可以参阅文献。这里只强调一下时钟节拍的选择。为了实现时间延时和确认超时，μC/OS-II需要系统提供一个10～100 Hz的周期性信号。我们选择实时时钟中断（RTI）作为μC/OS-II的时钟。这主要是考虑在HCS08GT60处于WAIT或者STOP2/3模式下，RTI仍然可以作为唤醒系统的中断源。需要注意，在运行和等待模式下，RTI的时钟只能由外部晶振提供；在STOP3模式下，RTI时钟可以由外部晶振或是内部晶振提供；在STOP2模式下，RTI只能由内部时钟提供。为了尽量不改动时钟源，建议使用1个32.768 kHz的外部晶振提供系统时钟和RTI时钟，在运行、WAIT和STOP3模式下，RTI的时钟源始终不变;而在STOP2模式下，用户只能使用内部时钟发生器提供的RTI时钟源。 4 结论 仔细分析1个低功耗实时系统会发现,有很多因素左右着系统功耗，各因素之间往往会相互影响，相互制约。例如，为了保证实时性，尽量不改动时钟设置，使用了32.768 kHz的外部晶振作为RTI时钟源，并利用锁相环将该频率升高，作为系统总线时钟。从操作系统角度分析，CPU可以进入低功耗模式，系统功耗降低了。但是，因为使用了锁相环，也会给系统带来额外的功耗。对于一个实际系统，这种做法到底是提高还是降低了系统功耗，只能通过CPU占用率、节拍频率等条件具体分析了。因此，要选择一套合理的软硬件设置来降低功耗，就必须全盘考虑，不能仅仅局限于操作系统的角度。 |
网友评论