嵌入式低功耗开发

不知从什么时候开始，随便做个什么电子产品，至少是电池供电的，都要求低功耗特性了。好在市面上随便什么芯片都敢在自己的数据手册的第一页赫然写着低功耗。究竟怎样算低功耗?小于5mA?小于1ms?小于100uA?离开了应用场合，似乎数值也失去了单纯的意义，总之越小越好。但感觉上，能用水果点亮的应用应该就是低功耗了吧。

认真说来，有点怀念当年随便一个应用500mA，芯片微微发烫，用手一摸只要还能放得住就大手一挥“没问题”的时代了。最近总是和uA打交道，超过100uA，周围的人脸色就不好看了，好容易达到了传说中的20uA以内，也会觉得沾沾自喜，哎……uA啊……情何以堪啊，伤不起啊……

久病成医，渐渐的也就有了一些心得，似乎低功耗开发的过程也可以一板一眼，按部就班，似乎不单纯是一些零散的“看情况而定”“只可意会”的东西了。于是忍不住，将这些似是而非的步骤记录下来，以箪初来者。

事半功倍还是事倍功半——思路决定成败

“肚子饿的时候，睡着了也就不觉得饿了……于是乎，难得的双休日宅在家中补觉，往往也就一天只吃一餐饭了”——技术宅人_大体如此。

应该没有人能在梦游的时候干活吧?所以，平常工作的时候，饭还是要吃的。休眠和干活应该是一对矛盾体。于是乎，芯片数据手册上那些“小的出奇”的休眠功耗，似乎大部分时候只是用来摆设的;而工作功耗才是实实在在的东西。有时候，为了体现所谓的低功耗，还要在应用中设计一种所谓的低功耗模式——当系统确认没有事情可做一段时间以后就干脆回家睡觉了——这大体就是现在市面上常见的低功耗应用的某种程度上的现状吧。于是乎，降低工作频率这种“马儿跑，马儿不吃草”的逻辑，就成为降低正常工作模式下系统功耗的常规选择。苦啊……多少人在工作频率和功耗间纠结……又有多少功能实现的本身对对频率拥有最低要求……苦啊——我说的是写代码的程序员。

说起来，降低功耗似乎是一个软件和硬件协同工作才能解决的问题。比如AD采样时候的分压电阻，如果直接接了地，那么就会一直消耗电流，如果通过一个IO口来控制其接地的方式，只在需要采样的时候接地，采样完成以后就悬浮或者拉高，就可以将这部分开销降低的最小。

显然，将低功耗完全化作硬件设计的工作或者软件设计的工作都是不合适的。

 

 

从硬件角度来说，找到所有可能的消耗电流的回路，一一确定哪些是可以通过软件控制的方式来优化功耗的，哪些是不可避免的，并给程序的编写人员提供一个所有IO口状态对功耗影响的关系(通常用简单的表格说明一下高电平会怎样，低电平会怎样，悬浮会怎样就足够了，并不需要精细到具体的数值。)做到这一点，基本上硬件的工作就告完成，剩下的就是软件开发人员的发挥空间。而基于软件的功耗降低策略，正是本文所要讨论的重点。

说到软件功耗优化，说简单也简单，说复杂也复杂。简单总结过来就是：应用模块化、功能任务化、任务周期化、功耗自理化、休眠一票否决化。还不够简单?再浓缩就是：能休眠就休眠，怎么休眠投票选。呵呵……估计简单过头了，失去了信息量，下面将这几个方面一一展开：

1、应用模块化、功能任务化、任务周期化

一个具体的应用，通常由很多子功能，子任务组成。对嵌入式系统软件构架有所了解的人更能理解：一个应用是由对若干服务(servie)的调用实现的。这里服务可以是硬件服务，比如AD采样，比如串口通讯，比如外中断触发，比如定时器服务;也可以是软件服务，比如各种通讯协议栈，FAT文件系统，队列，软件滤波等等。一个服务通常实现一个或多个功能(好的任务划分不会让一个服务包含多于2种以上不相关的功能)。简单的功能，比如CRC校验这样函数进去函数出来基本上可以立即获得结果的，我就不说了;复杂的功能最好都使用任务的方式来实现。说到任务，就要牵涉到操作系统、调度器或者干脆是简单的状态机了。总之，可以将任务的实现理解为一个流程。既然是流程，那么任务所要做的工作就是周期性的。举例来说，AD采样任务由至少3个步骤组成：通道选择和启动采样，采样以及等待采样完成，数据的处理。这样三个步骤共同组成了一个任务周期，当三个步骤完成以后，我们可以认为一个周期结束了。再举一个例子，I2C通讯，一个完整的数据包的发送通常包含了若干的状态，这一系列状态构成了一个任务，当最后一个状态(或者某些异常退出状态)结束后，一个任务周期就结束了。

总结来说，应用模块化，功能任务化，任务周期化的最终目的就是任务周期化。只有实现了周期化，一件事情才有始有终。有始有终，就可以根据需要发放“工资”，避免浪费。而做到任务周期化的最常见办法就是通过模块化的服务将功能独立出来从而便于管理，便于找到一件事情的开头和结尾。

找到不拉马的士兵，是功耗管理的起点。而做到这一点，是需要对嵌入式系统拥有全局的概念，需要有基于模块化开发，面向服务和接口开发的经验的。经验的积累和全局的概念，是最复杂的一个部分。

2、功耗自理化、休眠一票否决化

一旦实现了任务周期化，也就等于将整个系统分成了很多周期性工作的小任务，他们可能看起来是交错的、并行的或者毫无先后关系的，但从本质上说，每个小任务只要关心自己的起始和中止就好了。系统的功耗管理最后就化简为每个任务的功耗管理——只要每个任务做到了功耗最小，那么系统整体在一个有效的协调方式下，就能做到功耗最小。

根据上面的描述，基于任务的功耗管理实际上就被人为的分成两个部分：微观角度任务自身的功耗管理和宏观角度多任务休眠的协调。

我们先从微观来看。一个任务，首先肯定能独立完成自己的功能，这一点看似不起眼，其实很关键，他保证了任务中所有的步骤都是确定的，都是“自己说了算的”，对外界来说“都是黑盒子”的——简而言之就是“自治”的。在这一基础上，如果要求任务满足低功耗的要求，不外乎以下几种情形：

1)任务执行的过程中，是不允许休眠的，因此任务的开头和结尾处要设置标志——告知协调系统，“只要我还没有说OK就不允许休眠”“人在任务在”;

2)任务执行的过程中，某一些阶段允许休眠，而另外一些步骤是不允许休眠的;如果我们将 “不允许休眠”看作是休眠的最低等级，那么根据功耗的大小，休眠可以由低到高分为若干各等级。这种情况下，我们可以修改上面的定义为：任务的执行过程中，不同阶段允许不同的休眠等级。

3)任务执行的过程中，不在乎是否有休眠。

显然，如果这三类任务同时存在于系统中，第三类任务基本上是“空气”可以无视的，而第一种任务是相当霸道的，只要他在执行，就根本不允许休眠;对于第二类任务，即完成了任务，又兼顾了休眠，是一个值得表扬的“好同志”。我们在系统任务设计的时候，应该尽可能编写后两类任务，而避免或者尝试拆分第一类任务。

从宏观角度来看，任意时刻，可能有多个任务同时在执行，因此每个任务对休眠的需求都是不同的。如果要设立一个协调机制，该怎么办呢?难道这个协调机制需要了解每个任务的细节，然后“智能”的找到合适的时间点使用合适的等级来休眠么?太繁杂了吧?其实很简单，让每个任务都选派一个代表来开会好了——每次这个协调机构想休眠了，就召集所有的代表投票，大家每个人提供一个自己觉得能够容忍的最高休眠等级，最后会议的仲裁者从这些投票中找到一个最小的休眠等级——也就是水桶的最矮一环作为“会议共识”，然后进入相应的休眠等级。显然，如果有人投了“不休眠”得票，仲裁就只能无奈的选择放弃休眠。所以，每一个“任务”都应该是一个负责的任务，而不能因为一己私利，为了保证自己任务的执行就草率的选择自己在执行的期间“不允许休眠”。正确的做法就是，每个任务都应该根据自己的不同步骤及时的更新自己对休眠的容忍度，从而保证开会的时候，能够达成有意义的结果。

总结来说，如果每一个做事的人都很负责任，任务的划分又很合理，那么通过这种协商机制，体统自然就不存在“不拉马的士兵”，也能做到“能休眠时就休眠”了。这种情况下，芯片数据手册上那些休眠的功耗数字对你就有了实实在在的意义。怎么样?如果你已经领悟到了，就偷着乐吧。如果你还不知道如何具体去实现这些步骤，别着急，随后的章节我们一一为您展开。

低功耗设计第一步：自底向上，顺藤摸瓜

假想一下，现在有一个新的项目放在你的手上，具体的项目需求包含了AD多通道数据采样，AD采样后数据的处理(较为复杂)，同时还要支持I2C通讯，I2C的通讯协议较为复杂。这样一个设备必须做到功耗最低。应对这样一个需求，如果已经有一个建议的芯片，比如AVR Mega或者Tiny我们应该怎么做呢?

"先搞清楚我们是怎么睡的"

第一步，查阅数据手册，找到可被唤醒的最大休眠模式，编写一个测试工程——按照数据手册所说的要求，实现一个纯粹的什么都不做的休眠模式，同时，关闭所有能关闭的功耗——比如掐断某些外设的时钟，比如正确设置IO口状态。这样我们就获得了一个极限功耗，也就是正常情况下你通过系统设计可以无限接近的一个功耗。

这个时候，你需要的是，根据硬件设计工程师提供的IO口设置建议配置IO状态，以获得一个子人为的最低功耗。下载代码到目标电路，测量功耗。如果将电路板上无法优化的固有功耗——比如某些固定消耗电流的电阻功耗——消除以后，仍然没有达到数据手册上所说的对应休眠模式下的最大值时，你就要找硬件设计的兄弟喝茶了，两个人一起同时从硬件的角度和软件的角度找原因。直到我们获得一个满意的可自行唤醒的“纯休眠功耗”。

这个过程非常关键，他直接决定了日后你能达到的最好效果。多花费一点时间是值得的，因为在这一过程中，你能非常细微的“初步”了解到哪些外设和配置影响功耗，如何影响，有多大的影响。千里之行始于足下，多花点时间，值!

切忌，做软件的同学不要一口咬定说问题一定出在硬件设计上。举一个例子：我在这个步骤地时候，始终达不到数据手册上标注的休眠模式下的最大允许功耗，而根据数据手册，我认为我已经将所有能关断的外设都关闭了。于是我开始联系IC设计部门抱怨。最后的结果是，有一个外设使用了不同于CPU的独立时钟——也就是可以理解为异步时钟，在这种情况下，CPU对他的寄存器设置需要一定的时钟周期才能完成同步。而我在系统中简单的设置寄存器将其“关闭”后立即就去休眠了，可想而知由于没有等待异步始终同步，也就是这个操作还没有生效，我就去休眠了，这个外设还处于开启状态，功耗自然居高不下。哎……脸红啊……

"再搞清楚我们是怎么醒的"

第二步，确认系统的脉搏。所谓确认系统的脉搏就是要总体审查整个应用的工作方式，找到一个系统时钟的最大节拍，并根据这一要求确认芯片所使用的唤醒源。也许很多人都有使用定时器溢出中断或者比较匹配中断产生一个系统毫秒级时钟的习惯，然而，除使用外部手表晶振的RTC或者异步时钟源的定时器以外，普通定时器的正常工作都需要系统主时钟提供时钟源，这是我们所追求的低功耗模式所不允许的。有时候仔细想一想，一个毫秒级别的系统时钟真的是必须的么?

在AVR中，在低功耗模式下能提供系统时钟的通常就是看门狗了，通过设置，看门狗能够以一个固定的时间间隔(16ms / 32ms / 64ms / 128ms)将系统从最大的休眠模式下唤醒。因此在那些必须要用到系统节拍的应用中，如果16ms是你所需系统节拍周期的约数，你就可以考虑采用看门狗来提供一个并不是那么准确但是非常稳定的时钟源;否则你就要面对以下的选择：

a. 我的系统工作模式决定了我必须要一个小于16ms的系统时钟;那么整个设计是否允许使用外部时钟源给异步定时器(Timer2的异步模式)或者某些专门的RTC提供时钟源——这些外设通常支持将系统从最大的休眠模式下唤醒，就像看门狗做到的那样。

b. 如果我的系统不允许增加外部时钟源，系统是否允许通过外部触发的模式来工作——也就是通过外中断或者引脚电平变化中断来唤醒系统，并开始一次工作流程，完成后系统再次陷入永久睡眠。

c. 如果以上都不行，你可以考虑换芯片或者修改系统的需求的——至少系统需求在功耗的部分需要做一些妥协。

以上“确认系统脉搏”的步骤实际上是一个“例子”——系统设计的例子，或者说系统工作模式设计的例子，这是一个系统构架师或者说像我这样“自觉的”系统构架师应该要认真学会并经常实践的工作。一个笼统而完整的描述如下：

1) 对一块目标芯片进行调查和确认：确认其所有的休眠模式，以及对应休眠模式关闭的时钟源，这些时钟源涉及到的外设——巧妇难为无米之炊，这一步首先搞清楚系统设计的时候手上有哪些材料。

2)研究具体应用的需求，明确系统的工作模式(以采样类的模式来说就是采样，休息，再采样，再休息，整个系统是一个状态机并以采样事件作为驱动;采样不仅提供信息，也提供系统的脉搏。即便这类系统还涉及到LCD刷新或者I2C/串口通讯，由于信息的本源是采样，因此采样周期本身决定了信息的有效性，那么LCD的刷新周期，或者通讯的缓冲跟新周期没有理由必须大于采样的更新周期)。在这一前提下，明确系统对唤醒源以及唤醒模式的需求，由此便确定了系统的基础休眠模式，进一步说，比较这一基础休眠模式功耗和应用所需的功耗，便可给出系统设计的一个初步评估结果。有时候甚至能给出一些系统功耗的直接预期数据。

举例来说：

假如通过评估，我们发现“实现应用所涉及到的外设”可以将系统从某个最大允许的SLEEP模式唤醒(例如Power-Save Mode)，则这个SLEEP模式就是基础Sleep模式，我们评估系统功耗的方法就是估算，在完成一次任务的情况下(任务节拍)，sleep所占的时间是百分之几，系统工作的时间是百分之几(active time)，然后用下面的公式就可以估算出系统的正常功耗：

Equation A: normal power-consumption = sleep consumption * sleep time(%) + active consumption * active time(%) 3)根据研究报告，讨论系统的可行性。如果不可行，则根据已经明确的系统工作模式，对应的唤醒源要求重新选择芯片，并返回步骤1)。如果可行，则可以进行后续的设计。

Figure 1.1 一个能体现低功耗节拍设计的系统状态图

 

 

 

 

这种系统设计模式看似有点本末倒置——还没有搞清楚需求就已经把芯片定了——实际上，这种方式非常符合我们通常的开发模式：先有了一个初步的概念或者备选芯片方案，这些方案可能来自一个已有的方案，一个已有方案的兼容方案，一个老板或者老员工/经验者提出的方案——总之有了一个基础或者说原形，我们开始调查和研究具体低功耗的可行性，并形成了一个研究报告，这一报告将直接指导下一步的行为：由于需求非常明确，我们可以决定是否更换芯片或者直接进入下一步的开发。上面三个步骤实际上形成了一个LOOP，这一loop其实来自于“快速原型法”这一古老的“敏捷”开发模式自然，规范，高效。

完成了以上两个步骤，可以说这一阶段就结束了，至此我们对系统的关键性能数据已经成竹在胸：系统最低能实现多大的功耗;外设某些敏感的参数设置将如何影响功耗——当我们需要在外设性能和功耗之间做妥协和权衡的时候这些信息就将发挥巨大的作用;我们甚至对系统外来如何工作，或者说系统最基本的问题：“时间问题，整个复杂的多米诺骨牌是从哪里被什么推倒第一张牌的”大致有了了解。我们甚至知道，如果不出意外系统将会达到怎样的功耗。

简单说，我们已经知道系统是能够实现的，功耗会在什么范围也是大体有所概念的。万事俱备，只欠东风。欲知后事，请听下回分解。

本小结的一个附录：试探功耗底限的系统配置方式——分享一些实实在在的经验

A. 对AVR来说，不用的引脚怎么办?

>> 如果这个引脚属于ADC采样引脚

i) 通过DIDRn寄存器关闭对应引脚的数字输入，这个时候PINX对应位将永远读取到0

ii)通过DDRx和PORTx寄存器将对应的引脚设置为输入，“关闭”上拉电阻

>> 如果这个引脚是普通的GPIO

官方推荐的方式是给这个引脚一个确定的电平，比如：

i) 通过DDRx和PORTx寄存器将对应的引脚设置为输入状态，并“开启”上拉电阻

ii)通过DDRx和PORTx寄存器将对应的引脚设置为输出状态，并输出低电平，PCB设计上，将该引脚接地。

>> 如果这个引脚是RESET引脚当电路要求保证稳定的情况下尽可能简化，同时，VCC电压在上电时刻电压升高速度不会很缓慢，则接外部上拉电阻到VCC，这样虽然对功耗影响不大，但是可以适当提高一点抗干扰性。

>> 如果这个引脚是扩展的ADC引脚基本可以不管，或者接地。

B. 对AVR来说，需要使用的引脚怎么办?

>> 如果这个引脚是开漏输出/线与输入的引脚，比如TWI，同时需要与外部设备连接，而这一连接是允许拔插的

i) 如果逻辑上允许，接下拉电阻。

ii)如果是外中断引脚或者因脚电平变化中断引脚，避免悬浮，相比上拉来说，尽可能选择下拉。这样设置的目的是避免不确定电平经常将系统唤醒。选择下拉的原因是将高电平的选择权力交给外部设备，同时更倾向于盗电(^_^)。

>> 对于ADC引脚

i) 如果永远不会用于数字信号的输入用途，请参考空闲引脚的处理方式。

ii)如果需要用作数字信号的输入用途，请在通过PINx读取电平前，通过DIDRn寄存器打开对应引脚的数字输入，并插入两个NOP后读取电平，完成读取后，立即关闭数字输入功能。

>> 对于控制信号引脚

i) 直接驱动LED总是悲剧的开始，别忘记加入限流电阻，尽可能使用高亮LED。

ii)如果非要输出电平的控制信号，请认真考量有没有漏出电流的可能，如果有，请尽可能在不需要输出控制信号的情况下，将IO口处理为无电流漏出的状态(或最小小电流漏出的状态，关于出还是入的语言文字问题，你懂的)，具体状态图应该由硬件设计人员给建议。总原则就是按需分配。

C. 说说PRR寄存器

>> 如果某个外设的供电通过PRR寄存器的设置被掐断了

i) 除非特殊说明，否则这个外设的所有寄存器都是无法正确读写的

ii)如果在外设供电关闭前，外设的中断标志没有被清零;或者说正在执行这个中断处理程序的时候该外设被断电了，则中断标志不会被清除。表现症状就是中断持续被触发。其实想想很简单，参考i)就知道了。

iii) 很多时候，关闭定时器这样的外设并不能减少多少功耗，基本上都是小于5uA的。经验上关闭那些和模拟特性相关度较大，或者拥有独立相关的时钟源的模块，通常会减少不小的功耗。

iv) 谨慎使用该功能，除非你认真阅读了数据手册。这也是很多人所谓休眠醒不过来或者工作不正常的主要原因之一。

D. 说说工作频率

>> 在正常的工作模式下，频率越高功耗越高。

i) 推论1：对于同样一个工作，频率越高，完成该工作的时间越短

ii)推论2：根据Equation A，对于同样一个工作，Active的时间越短，则Sleep的时间越长。

>> 假设频率翻倍，功耗增加4倍，则:

i) 推论3：通常Sleep功耗至少为某一个频率功耗的4分之一甚至更大。当频率翻倍的时候，工作时间缩短一半，假设功率翻倍时功耗为4倍，则Active部分的实际功率翻倍(50% * 4);同时，节省出来的时间成为Sleep功耗，此时，系统的功耗变化为：

假设频率翻倍前的Active功耗认作 C，工作时间为T，则：翻倍前Active部分的功耗为 C * T频率翻倍后，Active的功耗为 4C，工作时间为 T/2;同时，假设Sleep的功耗为 C/4，则翻倍后的实际功耗为4C * (T/2) + (C/4) * (T/2) = 4.25C * T / 2 = 2.125 (C * T)可见频率翻倍后实际功率为增加前的2.125倍。显然从功耗的角度来说并不划算。

但请注意，Sleep功耗通常远远小于这里的1/4，以ATmega88为例，1MHz VCC = 2V的情况下最大功耗是550uA，而Sleep模式(Power-down VCC=3V)最大功耗是15uA，差不多36倍。在这种情况下，显然频率翻倍，功耗接近2倍。

有意思的是，如果对以上公式进行迭代，你会发现，频率越翻倍，Sleep功耗和翻倍前的Active功耗差距越大。也就是说基本上每次翻倍，功耗基本上可以认为是翻倍的。同时频率增高带来的好处却是运算速度每次都翻倍的。从这个角度来说，是否频率越高越好呢?(速度快，功耗增加小)。再联系到那些与外部引脚操作直接相关的功耗，频率越高，外部引脚操作中可控的功耗部分就小(请联系前面AD的例子)，那么从这个角度来说，似乎功耗还会减小一些。

再次强调，以上结论建立在工作完成后立即休眠的工作模式下，同时Sleep模式的功耗必须远远小于Active功耗(通常8~10倍)，使用外部时钟源，以及晶体振荡器所需的额外功耗，及从休眠中唤醒时时钟稳定期间所需功耗都未作考虑。

>> 实际上，MCU的功耗分为两个部分，一个与频率有关，一个与工作电压有关，即

E = E(V) + E(f)

当频率翻倍时，影响的只是E(f)，而这部分功耗并不会最终导致4倍的功耗，其值往往在2倍甚至更低。在这种情况下，Sleep+Active的工作模式会带来更低的功耗。证明略。

>> 通常，我们测量功耗的方式就是测量电流

i) 推论4：在非积分式功耗测定方式中，如果工作频率越高，则Sleep时间越长，在电流测量的时候，Active电流越接近于“毛刺”，这就导致了频率越高，功耗越低的假象。因为大部分的电流采样点都落在了Sleep上。

ii)推论5：采用积分式功耗测定方法才能正确的测定实际功耗。当然，如果你想骗骗普通客户，高精度电流表的电流结果(甚至是平均电流)都将反馈给你一个“非常理想的结果”。

低功耗设计第二步：让我们来下棋，很大很大的一盘棋

通过上一节的讨论，假设在您的设计中对应的步骤已经完成，则我们至少获得了以下信息和结果：

一个极限功耗

一个可行的系统工作模式(满足应用需求同时兼顾低功耗的系统节拍)

当使用2中提及的系统工作模式时，通过公式计算获得的理论系统功耗(系统正常工作下的功耗)

显然，万事俱备，只欠东风，就只剩下具体实现了。别着急，我们先来搞清楚几个定义。

a. 普通工作模式(Normal Mode / Active Mode)

这里的普通工作模式是指能够实现正常系统功能的模式，在这种模式下，MCU并非一直处于工作状态，而是根据前面一章提到的功耗公式，结合了Active和Sleep两种MCU状态的模式。简而言之，一个保证了应用基本功能的同时能休眠就休眠的工作模式。

b. 低功耗模式(Idle Mode / Sleep Mode)

这里所说的低功耗模式是指根据用户的应用需求，在用户指定或者系统自动侦测满足某些特定条件的情况下，尽可能关闭不需要的功能，仅保留某些应用必须的任务以降低功耗为目的的模式。(例如一段时间没有用户操作就关闭LCD和LED背光)

总结来说，这里的普通工作模式和低功耗模式都不直接对应MCU提供的Active和Sleep模式，而是两个根据用户功能需求定义的具有不同功能配置的功耗模式。他们可能都牵涉到MCU的Active和Sleep状态。明确了这两个定义，我们后续讨论中牵涉到的很多说法才不会混淆。

2.1 工欲善其事，必先利其器

在实践低功耗系统设计前，我们必须要有一个有效的手段来检测或者说观察系统当前的工作模式，通俗的说就是要能够随时知道系统什么时候工作，什么时候休眠，并且最好能够准确的知晓工作和休眠的时间比例。对于缺乏高精度电流表的场合来说，这种观测手段就更为重要了。

简而言之，我们需要一种实时追踪(trace)系统功耗模式的调试(Debug)手段。既然是实时追踪，意味着断点、单步这种常见的手段是不行的，系统必须保证处于正常的非间断工作状态下。同时，作为Debug，必须能够准确显示休眠和工作的状态，并能够将这些信息保存下来，大家可以在脑海里想像有这么一个类似地震记录仪的设备，一直不停的在纸带上记录着功耗变化的信息。说的这么复杂，其实做起来很简单。Debug阶段，我们关系的是系统如何休眠的，其实际功耗可能由于Debug手段的存在而并不准确，但这一信息已经足够了，因为在随后的检测中，我们可以生成一个release版本(移除了debug相关的代码)直接通过电流表检验系统功耗。Code 2.1就是一个很好的例子。代码在休眠前在某一个信号引脚上输出高电平，在退出休眠模式后输出低电平。此时，借助示波器或者逻辑分析仪的帮助，我们就可以记录并检测系统的功耗模式，甚至根据数据手册提供的Active电流和Sleep电流计算出一个非常接近实际结果的理论_功耗。

Code 2.1 一个Tiny下进入Sleep模式的代码例子

static void enter_sleep_mode(uint8_t chLevel) { /*! brief sleep mode select bits *! MODE SM2 SM1 SM0 *! idle 0 0 0 *! ADC Noise Reduction 0 0 1 *! Power-save 0 1 1 *! Power-off 1 0 0 */ static FLASH uint8_t c_chSleepLevel[] = { ((0x00 << SM0) | _BV(SE)), ((0x01 << SM0) | _BV(SE)), ((0x02 << SM0) | _BV(SE)), ((0x03 << SM0) | _BV(SE)) }; uint8_t chSleepMode = c_chSleepLevel[chLevel] /* | _BV(SE)*/; SAFE_ATOM_CODE( MCUCR = (MCUCR & ~(_BV(SM0) | _BV(SM1) | _BV(SE))) | chSleepMode; ENABLE_GLOBAL_INTERRUPT(); //! enable interrupt set_signal_a(); //! 即将进入sleep前将信号引脚置高 __sleep(); //! sleep //!< clear sleep control register MCUCR &= ~(_BV(SM0) | _BV(SM1) | _BV(SE)); clear_signal_a(); //!< 退出sleep模式后将信号引脚拉低 ) } 有了这样一个手段，我们就能很方便的进行实时调试，设计出“能休眠就休眠”的好算法。这也是我们后续讨论的基础。

Figure 2.1 一个可能的系统功耗模式监测的样例