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占用率、节拍频率等条件具体分析了。