引言

随着消费类电子产品的功能日益复杂,在其中移植或固化实时操作系统已不是新鲜事了,如手机、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 三种STOP子模式的特点

从表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供电下,三种模式的典型功耗。

表2 STOP2、STOP3和WAIT模式下的功耗

μ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可以参阅文献[1]。这里只强调一下时钟节拍的选择。

为了实现时间延时和确认超时,μ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占用率、节拍频率等条件具体分析了。

因此,要选择一套合理的软硬件设置来降低功耗,就必须全盘考虑,不能仅仅局限于操作系统的角度。