不知從什么時候開始，隨便做個什么電子產(chǎn)品，至少是電池供電的，都要求低功耗特性了。好在市面上隨便什么芯片都敢在自己的數(shù)據(jù)手冊的第一頁赫然寫著低功耗。究竟怎樣算低功耗？小于5mA？小于1ms？小于100uA？離開了應(yīng)用場合，似乎數(shù)值也失去了單純的意義，總之越小越好。但感覺上，能用水果點亮的應(yīng)用應(yīng)該就是低功耗了吧。

認真說來，有點懷念當(dāng)年隨便一個應(yīng)用500mA，芯片微微發(fā)燙，用手一摸只要還能放得住就大手一揮“沒問題”的時代了。最近總是和uA打交道，超過100uA，周圍的人臉色就不好看了，好容易達到了傳說中的20uA以內(nèi)，也會覺得沾沾自喜，哎……uA啊……情何以堪啊，傷不起啊……

久病成醫(yī)，漸漸的也就有了一些心得，似乎低功耗開發(fā)的過程也可以一板一眼，按部就班，似乎不單純是一些零散的“看情況而定”“只可意會”的東西了。于是忍不住，將這些似是而非的步驟記錄下來，以簞初來者。

事半功倍還是事倍功半——思路決定成敗

“肚子餓的時候，睡著了也就不覺得餓了……于是乎，難得的雙休日宅在家中補覺，往往也就一天只吃一餐飯了”——技術(shù)宅人_大體如此。

應(yīng)該沒有人能在夢游的時候干活吧？所以，平常工作的時候，飯還是要吃的。休眠和干活應(yīng)該是一對矛盾體。于是乎，芯片數(shù)據(jù)手冊上那些“小的出奇”的休眠功耗，似乎大部分時候只是用來擺設(shè)的；而工作功耗才是實實在在的東西。有時候，為了體現(xiàn)所謂的低功耗，還要在應(yīng)用中設(shè)計一種所謂的低功耗模式——當(dāng)系統(tǒng)確認沒有事情可做一段時間以后就干脆回家睡覺了——這大體就是現(xiàn)在市面上常見的低功耗應(yīng)用的某種程度上的現(xiàn)狀吧。于是乎，降低工作頻率這種“馬兒跑，馬兒不吃草”的邏輯，就成為降低正常工作模式下系統(tǒng)功耗的常規(guī)選擇?？喟　嗌偃嗽诠ぷ黝l率和功耗間糾結(jié)……又有多少功能實現(xiàn)的本身對對頻率擁有最低要求……苦啊——我說的是寫代碼的程序員。

說起來，降低功耗似乎是一個軟件和硬件協(xié)同工作才能解決的問題。比如AD采樣時候的分壓電阻，如果直接接了地，那么就會一直消耗電流，如果通過一個IO口來控制其接地的方式，只在需要采樣的時候接地，采樣完成以后就懸浮或者拉高，就可以將這部分開銷降低的最小。

顯然，將低功耗完全化作硬件設(shè)計的工作或者軟件設(shè)計的工作都是不合適的。

從硬件角度來說，找到所有可能的消耗電流的回路，一一確定哪些是可以通過軟件控制的方式來優(yōu)化功耗的，哪些是不可避免的，并給程序的編寫人員提供一個所有IO口狀態(tài)對功耗影響的關(guān)系（通常用簡單的表格說明一下高電平會怎樣，低電平會怎樣，懸浮會怎樣就足夠了，并不需要精細到具體的數(shù)值。）做到這一點，基本上硬件的工作就告完成，剩下的就是軟件開發(fā)人員的發(fā)揮空間。而基于軟件的功耗降低策略，正是本文所要討論的重點。

說到軟件功耗優(yōu)化，說簡單也簡單，說復(fù)雜也復(fù)雜。簡單總結(jié)過來就是：應(yīng)用模塊化、功能任務(wù)化、任務(wù)周期化、功耗自理化、休眠一票否決化。還不夠簡單？再濃縮就是：能休眠就休眠，怎么休眠投票選。呵呵……估計簡單過頭了，失去了信息量，下面將這幾個方面一一展開：

1、應(yīng)用模塊化、功能任務(wù)化、任務(wù)周期化

一個具體的應(yīng)用，通常由很多子功能，子任務(wù)組成。對嵌入式系統(tǒng)軟件構(gòu)架有所了解的人更能理解：一個應(yīng)用是由對若干服務(wù)（servie）的調(diào)用實現(xiàn)的。這里服務(wù)可以是硬件服務(wù)，比如AD采樣，比如串口通訊，比如外中斷觸發(fā)，比如定時器服務(wù)；也可以是軟件服務(wù)，比如各種通訊協(xié)議棧，F(xiàn)AT文件系統(tǒng)，隊列，軟件濾波等等。一個服務(wù)通常實現(xiàn)一個或多個功能（好的任務(wù)劃分不會讓一個服務(wù)包含多于2種以上不相關(guān)的功能）。簡單的功能，比如CRC校驗這樣函數(shù)進去函數(shù)出來基本上可以立即獲得結(jié)果的，我就不說了；復(fù)雜的功能最好都使用任務(wù)的方式來實現(xiàn)。說到任務(wù)，就要牽涉到操作系統(tǒng)、調(diào)度器或者干脆是簡單的狀態(tài)機了?？傊梢詫⑷蝿?wù)的實現(xiàn)理解為一個流程。既然是流程，那么任務(wù)所要做的工作就是周期性的。舉例來說，AD采樣任務(wù)由至少3個步驟組成：通道選擇和啟動采樣，采樣以及等待采樣完成，數(shù)據(jù)的處理。這樣三個步驟共同組成了一個任務(wù)周期，當(dāng)三個步驟完成以后，我們可以認為一個周期結(jié)束了。再舉一個例子，I2C通訊，一個完整的數(shù)據(jù)包的發(fā)送通常包含了若干的狀態(tài)，這一系列狀態(tài)構(gòu)成了一個任務(wù)，當(dāng)最后一個狀態(tài)（或者某些異常退出狀態(tài)）結(jié)束后，一個任務(wù)周期就結(jié)束了。

總結(jié)來說，應(yīng)用模塊化，功能任務(wù)化，任務(wù)周期化的最終目的就是任務(wù)周期化。只有實現(xiàn)了周期化，一件事情才有始有終。有始有終，就可以根據(jù)需要發(fā)放“工資”，避免浪費。而做到任務(wù)周期化的最常見辦法就是通過模塊化的服務(wù)將功能獨立出來從而便于管理，便于找到一件事情的開頭和結(jié)尾。

找到不拉馬的士兵，是功耗管理的起點。而做到這一點，是需要對嵌入式系統(tǒng)擁有全局的概念，需要有基于模塊化開發(fā)，面向服務(wù)和接口開發(fā)的經(jīng)驗的。經(jīng)驗的積累和全局的概念，是最復(fù)雜的一個部分。

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

一旦實現(xiàn)了任務(wù)周期化，也就等于將整個系統(tǒng)分成了很多周期性工作的小任務(wù)，他們可能看起來是交錯的、并行的或者毫無先后關(guān)系的，但從本質(zhì)上說，每個小任務(wù)只要關(guān)心自己的起始和中止就好了。系統(tǒng)的功耗管理最后就化簡為每個任務(wù)的功耗管理——只要每個任務(wù)做到了功耗最小，那么系統(tǒng)整體在一個有效的協(xié)調(diào)方式下，就能做到功耗最小。

根據(jù)上面的描述，基于任務(wù)的功耗管理實際上就被人為的分成兩個部分：微觀角度任務(wù)自身的功耗管理和宏觀角度多任務(wù)休眠的協(xié)調(diào)。

我們先從微觀來看。一個任務(wù)，首先肯定能獨立完成自己的功能，這一點看似不起眼，其實很關(guān)鍵，他保證了任務(wù)中所有的步驟都是確定的，都是“自己說了算的”，對外界來說“都是黑盒子”的——簡而言之就是“自治”的。在這一基礎(chǔ)上，如果要求任務(wù)滿足低功耗的要求，不外乎以下幾種情形：

1)任務(wù)執(zhí)行的過程中，是不允許休眠的，因此任務(wù)的開頭和結(jié)尾處要設(shè)置標(biāo)志——告知協(xié)調(diào)系統(tǒng)，“只要我還沒有說ＯＫ就不允許休眠”“人在任務(wù)在”；

2)任務(wù)執(zhí)行的過程中，某一些階段允許休眠，而另外一些步驟是不允許休眠的；如果我們將“不允許休眠”看作是休眠的最低等級，那么根據(jù)功耗的大小，休眠可以由低到高分為若干各等級。這種情況下，我們可以修改上面的定義為：任務(wù)的執(zhí)行過程中，不同階段允許不同的休眠等級。

3)任務(wù)執(zhí)行的過程中，不在乎是否有休眠。

顯然，如果這三類任務(wù)同時存在于系統(tǒng)中，第三類任務(wù)基本上是“空氣”可以無視的，而第一種任務(wù)是相當(dāng)霸道的，只要他在執(zhí)行，就根本不允許休眠；對于第二類任務(wù)，即完成了任務(wù)，又兼顧了休眠，是一個值得表揚的“好同志”。我們在系統(tǒng)任務(wù)設(shè)計的時候，應(yīng)該盡可能編寫后兩類任務(wù)，而避免或者嘗試拆分第一類任務(wù)。

從宏觀角度來看，任意時刻，可能有多個任務(wù)同時在執(zhí)行，因此每個任務(wù)對休眠的需求都是不同的。如果要設(shè)立一個協(xié)調(diào)機制，該怎么辦呢？難道這個協(xié)調(diào)機制需要了解每個任務(wù)的細節(jié)，然后“智能”的找到合適的時間點使用合適的等級來休眠么？太繁雜了吧？其實很簡單，讓每個任務(wù)都選派一個代表來開會好了——每次這個協(xié)調(diào)機構(gòu)想休眠了，就召集所有的代表投票，大家每個人提供一個自己覺得能夠容忍的最高休眠等級，最后會議的仲裁者從這些投票中找到一個最小的休眠等級——也就是水桶的最矮一環(huán)作為“會議共識”，然后進入相應(yīng)的休眠等級。顯然，如果有人投了“不休眠”得票，仲裁就只能無奈的選擇放棄休眠。所以，每一個“任務(wù)”都應(yīng)該是一個負責(zé)的任務(wù)，而不能因為一己私利，為了保證自己任務(wù)的執(zhí)行就草率的選擇自己在執(zhí)行的期間“不允許休眠”。正確的做法就是，每個任務(wù)都應(yīng)該根據(jù)自己的不同步驟及時的更新自己對休眠的容忍度，從而保證開會的時候，能夠達成有意義的結(jié)果。

總結(jié)來說，如果每一個做事的人都很負責(zé)任，任務(wù)的劃分又很合理，那么通過這種協(xié)商機制，體統(tǒng)自然就不存在“不拉馬的士兵”，也能做到“能休眠時就休眠”了。這種情況下，芯片數(shù)據(jù)手冊上那些休眠的功耗數(shù)字對你就有了實實在在的意義。怎么樣？如果你已經(jīng)領(lǐng)悟到了，就偷著樂吧。如果你還不知道如何具體去實現(xiàn)這些步驟，別著急，隨后的章節(jié)我們一一為您展開。

低功耗設(shè)計第一步：自底向上，順藤摸瓜

假想一下，現(xiàn)在有一個新的項目放在你的手上，具體的項目需求包含了AD多通道數(shù)據(jù)采樣，AD采樣后數(shù)據(jù)的處理（較為復(fù)雜），同時還要支持I2C通訊，I2C的通訊協(xié)議較為復(fù)雜。這樣一個設(shè)備必須做到功耗最低。應(yīng)對這樣一個需求，如果已經(jīng)有一個建議的芯片，比如AVRMega或者Tiny我們應(yīng)該怎么做呢？

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

第一步，查閱數(shù)據(jù)手冊，找到可被喚醒的最大休眠模式，編寫一個測試工程——按照數(shù)據(jù)手冊所說的要求，實現(xiàn)一個純粹的什么都不做的休眠模式，同時，關(guān)閉所有能關(guān)閉的功耗——比如掐斷某些外設(shè)的時鐘，比如正確設(shè)置IO口狀態(tài)。這樣我們就獲得了一個極限功耗，也就是正常情況下你通過系統(tǒng)設(shè)計可以無限接近的一個功耗。

這個時候，你需要的是，根據(jù)硬件設(shè)計工程師提供的IO口設(shè)置建議配置IO狀態(tài)，以獲得一個子人為的最低功耗。下載代碼到目標(biāo)電路，測量功耗。如果將電路板上無法優(yōu)化的固有功耗——比如某些固定消耗電流的電阻功耗——消除以后，仍然沒有達到數(shù)據(jù)手冊上所說的對應(yīng)休眠模式下的最大值時，你就要找硬件設(shè)計的兄弟喝茶了，兩個人一起同時從硬件的角度和軟件的角度找原因。直到我們獲得一個滿意的可自行喚醒的“純休眠功耗”。

這個過程非常關(guān)鍵，他直接決定了日后你能達到的最好效果。多花費一點時間是值得的，因為在這一過程中，你能非常細微的“初步”了解到哪些外設(shè)和配置影響功耗，如何影響，有多大的影響。千里之行始于足下，多花點時間，值！

切忌，做軟件的同學(xué)不要一口咬定說問題一定出在硬件設(shè)計上。舉一個例子：我在這個步驟地時候，始終達不到數(shù)據(jù)手冊上標(biāo)注的休眠模式下的最大允許功耗，而根據(jù)數(shù)據(jù)手冊，我認為我已經(jīng)將所有能關(guān)斷的外設(shè)都關(guān)閉了。于是我開始聯(lián)系IC設(shè)計部門抱怨。最后的結(jié)果是，有一個外設(shè)使用了不同于CPU的獨立時鐘——也就是可以理解為異步時鐘，在這種情況下，CPU對他的寄存器設(shè)置需要一定的時鐘周期才能完成同步。而我在系統(tǒng)中簡單的設(shè)置寄存器將其“關(guān)閉”后立即就去休眠了，可想而知由于沒有等待異步始終同步，也就是這個操作還沒有生效，我就去休眠了，這個外設(shè)還處于開啟狀態(tài)，功耗自然居高不下。哎……臉紅啊……

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

第二步，確認系統(tǒng)的脈搏。所謂確認系統(tǒng)的脈搏就是要總體審查整個應(yīng)用的工作方式，找到一個系統(tǒng)時鐘的最大節(jié)拍，并根據(jù)這一要求確認芯片所使用的喚醒源。也許很多人都有使用定時器溢出中斷或者比較匹配中斷產(chǎn)生一個系統(tǒng)毫秒級時鐘的習(xí)慣，然而，除使用外部手表晶振的RTC或者異步時鐘源的定時器以外，普通定時器的正常工作都需要系統(tǒng)主時鐘提供時鐘源，這是我們所追求的低功耗模式所不允許的。有時候仔細想一想，一個毫秒級別的系統(tǒng)時鐘真的是必須的么？

在AVR中，在低功耗模式下能提供系統(tǒng)時鐘的通常就是看門狗了，通過設(shè)置，看門狗能夠以一個固定的時間間隔（16ms/32ms/64ms/128ms）將系統(tǒng)從最大的休眠模式下喚醒。因此在那些必須要用到系統(tǒng)節(jié)拍的應(yīng)用中，如果16ms是你所需系統(tǒng)節(jié)拍周期的約數(shù)，你就可以考慮采用看門狗來提供一個并不是那么準確但是非常穩(wěn)定的時鐘源；否則你就要面對以下的選擇：

a.我的系統(tǒng)工作模式?jīng)Q定了我必須要一個小于16ms的系統(tǒng)時鐘；那么整個設(shè)計是否允許使用外部時鐘源給異步定時器（Timer2的異步模式）或者某些專門的RTC提供時鐘源——這些外設(shè)通常支持將系統(tǒng)從最大的休眠模式下喚醒，就像看門狗做到的那樣。

b.如果我的系統(tǒng)不允許增加外部時鐘源，系統(tǒng)是否允許通過外部觸發(fā)的模式來工作——也就是通過外中斷或者引腳電平變化中斷來喚醒系統(tǒng)，并開始一次工作流程，完成后系統(tǒng)再次陷入永久睡眠。

c.如果以上都不行，你可以考慮換芯片或者修改系統(tǒng)的需求的——至少系統(tǒng)需求在功耗的部分需要做一些妥協(xié)。

以上“確認系統(tǒng)脈搏”的步驟實際上是一個“例子”——系統(tǒng)設(shè)計的例子，或者說系統(tǒng)工作模式設(shè)計的例子，這是一個系統(tǒng)構(gòu)架師或者說像我這樣“自覺的”系統(tǒng)構(gòu)架師應(yīng)該要認真學(xué)會并經(jīng)常實踐的工作。一個籠統(tǒng)而完整的描述如下：

1)對一塊目標(biāo)芯片進行調(diào)查和確認：確認其所有的休眠模式，以及對應(yīng)休眠模式關(guān)閉的時鐘源，這些時鐘源涉及到的外設(shè)——巧婦難為無米之炊，這一步首先搞清楚系統(tǒng)設(shè)計的時候手上有哪些材料。

2）研究具體應(yīng)用的需求，明確系統(tǒng)的工作模式（以采樣類的模式來說就是采樣，休息，再采樣，再休息，整個系統(tǒng)是一個狀態(tài)機并以采樣事件作為驅(qū)動；采樣不僅提供信息，也提供系統(tǒng)的脈搏。即便這類系統(tǒng)還涉及到LCD刷新或者I2C/串口通訊，由于信息的本源是采樣，因此采樣周期本身決定了信息的有效性，那么LCD的刷新周期，或者通訊的緩沖跟新周期沒有理由必須大于采樣的更新周期）。在這一前提下，明確系統(tǒng)對喚醒源以及喚醒模式的需求，由此便確定了系統(tǒng)的基礎(chǔ)休眠模式，進一步說，比較這一基礎(chǔ)休眠模式功耗和應(yīng)用所需的功耗，便可給出系統(tǒng)設(shè)計的一個初步評估結(jié)果。有時候甚至能給出一些系統(tǒng)功耗的直接預(yù)期數(shù)據(jù)。

舉例來說：

假如通過評估，我們發(fā)現(xiàn)“實現(xiàn)應(yīng)用所涉及到的外設(shè)”可以將系統(tǒng)從某個最大允許的SLEEP模式喚醒（例如Power-SaveMode），則這個SLEEP模式就是基礎(chǔ)Sleep模式，我們評估系統(tǒng)功耗的方法就是估算，在完成一次任務(wù)的情況下（任務(wù)節(jié)拍），sleep所占的時間是百分之幾，系統(tǒng)工作的時間是百分之幾（activetime），然后用下面的公式就可以估算出系統(tǒng)的正常功耗：

EquationA:normalpower-consumption=sleepconsumption*sleeptime(%)+activeconsumption*activetime(%)3）根據(jù)研究報告，討論系統(tǒng)的可行性。如果不可行，則根據(jù)已經(jīng)明確的系統(tǒng)工作模式，對應(yīng)的喚醒源要求重新選擇芯片，并返回步驟1）。如果可行，則可以進行后續(xù)的設(shè)計。

Figure1.1一個能體現(xiàn)低功耗節(jié)拍設(shè)計的系統(tǒng)狀態(tài)圖

這種系統(tǒng)設(shè)計模式看似有點本末倒置——還沒有搞清楚需求就已經(jīng)把芯片定了——實際上，這種方式非常符合我們通常的開發(fā)模式：先有了一個初步的概念或者備選芯片方案，這些方案可能來自一個已有的方案，一個已有方案的兼容方案，一個老板或者老員工/經(jīng)驗者提出的方案——總之有了一個基礎(chǔ)或者說原形，我們開始調(diào)查和研究具體低功耗的可行性，并形成了一個研究報告，這一報告將直接指導(dǎo)下一步的行為：由于需求非常明確，我們可以決定是否更換芯片或者直接進入下一步的開發(fā)。上面三個步驟實際上形成了一個LOOP，這一loop其實來自于“快速原型法”這一古老的“敏捷”開發(fā)模式自然，規(guī)范，高效。

完成了以上兩個步驟，可以說這一階段就結(jié)束了，至此我們對系統(tǒng)的關(guān)鍵性能數(shù)據(jù)已經(jīng)成竹在胸：系統(tǒng)最低能實現(xiàn)多大的功耗；外設(shè)某些敏感的參數(shù)設(shè)置將如何影響功耗——當(dāng)我們需要在外設(shè)性能和功耗之間做妥協(xié)和權(quán)衡的時候這些信息就將發(fā)揮巨大的作用；我們甚至對系統(tǒng)外來如何工作，或者說系統(tǒng)最基本的問題：“時間問題，整個復(fù)雜的多米諾骨牌是從哪里被什么推倒第一張牌的”大致有了了解。我們甚至知道，如果不出意外系統(tǒng)將會達到怎樣的功耗。

簡單說，我們已經(jīng)知道系統(tǒng)是能夠?qū)崿F(xiàn)的，功耗會在什么范圍也是大體有所概念的。萬事俱備，只欠東風(fēng)。欲知后事，請聽下回分解。

本小結(jié)的一個附錄：試探功耗底限的系統(tǒng)配置方式——分享一些實實在在的經(jīng)驗

A.對AVR來說，不用的引腳怎么辦？

>>如果這個引腳屬于ADC采樣引腳

i)通過DIDRn寄存器關(guān)閉對應(yīng)引腳的數(shù)字輸入，這個時候PINX對應(yīng)位將永遠讀取到0

ii)通過DDRx和PORTx寄存器將對應(yīng)的引腳設(shè)置為輸入，“關(guān)閉”上拉電阻

>>如果這個引腳是普通的GPIO

官方推薦的方式是給這個引腳一個確定的電平，比如：

i)通過DDRx和PORTx寄存器將對應(yīng)的引腳設(shè)置為輸入狀態(tài)，并“開啟”上拉電阻

ii)通過DDRx和PORTx寄存器將對應(yīng)的引腳設(shè)置為輸出狀態(tài)，并輸出低電平，PCB設(shè)計上，將該引腳接地。

>>如果這個引腳是RESET引腳當(dāng)電路要求保證穩(wěn)定的情況下盡可能簡化，同時，VCC電壓在上電時刻電壓升高速度不會很緩慢，則接外部上拉電阻到VCC，這樣雖然對功耗影響不大，但是可以適當(dāng)提高一點抗干擾性。

>>如果這個引腳是擴展的ADC引腳基本可以不管，或者接地。

B.對AVR來說，需要使用的引腳怎么辦？

>>如果這個引腳是開漏輸出/線與輸入的引腳，比如TWI，同時需要與外部設(shè)備連接，而這一連接是允許拔插的

i)如果邏輯上允許，接下拉電阻。

ii)如果是外中斷引腳或者因腳電平變化中斷引腳，避免懸浮，相比上拉來說，盡可能選擇下拉。這樣設(shè)置的目的是避免不確定電平經(jīng)常將系統(tǒng)喚醒。選擇下拉的原因是將高電平的選擇權(quán)力交給外部設(shè)備，同時更傾向于盜電(^_^)。

>>對于ADC引腳

i)如果永遠不會用于數(shù)字信號的輸入用途，請參考空閑引腳的處理方式。

ii)如果需要用作數(shù)字信號的輸入用途，請在通過PINx讀取電平前，通過DIDRn寄存器打開對應(yīng)引腳的數(shù)字輸入，并插入兩個NOP后讀取電平，完成讀取后，立即關(guān)閉數(shù)字輸入功能。

>>對于控制信號引腳

i)直接驅(qū)動LED總是悲劇的開始，別忘記加入限流電阻，盡可能使用高亮LED。

ii)如果非要輸出電平的控制信號，請認真考量有沒有漏出電流的可能，如果有，請盡可能在不需要輸出控制信號的情況下，將IO口處理為無電流漏出的狀態(tài)（或最小小電流漏出的狀態(tài)，關(guān)于出還是入的語言文字問題，你懂的），具體狀態(tài)圖應(yīng)該由硬件設(shè)計人員給建議?？傇瓌t就是按需分配。

C.說說PRR寄存器

>>如果某個外設(shè)的供電通過PRR寄存器的設(shè)置被掐斷了

i)除非特殊說明，否則這個外設(shè)的所有寄存器都是無法正確讀寫的

ii)如果在外設(shè)供電關(guān)閉前，外設(shè)的中斷標(biāo)志沒有被清零；或者說正在執(zhí)行這個中斷處理程序的時候該外設(shè)被斷電了，則中斷標(biāo)志不會被清除。表現(xiàn)癥狀就是中斷持續(xù)被觸發(fā)。其實想想很簡單，參考i)就知道了。

iii)很多時候，關(guān)閉定時器這樣的外設(shè)并不能減少多少功耗，基本上都是小于5uA的。經(jīng)驗上關(guān)閉那些和模擬特性相關(guān)度較大，或者擁有獨立相關(guān)的時鐘源的模塊，通常會減少不小的功耗。

iv)謹慎使用該功能，除非你認真閱讀了數(shù)據(jù)手冊。這也是很多人所謂休眠醒不過來或者工作不正常的主要原因之一。

D.說說工作頻率

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

i)推論1：對于同樣一個工作，頻率越高，完成該工作的時間越短

ii)推論2：根據(jù)EquationA，對于同樣一個工作，Active的時間越短，則Sleep的時間越長。

>>假設(shè)頻率翻倍，功耗增加4倍，則:

i)推論3：通常Sleep功耗至少為某一個頻率功耗的4分之一甚至更大。當(dāng)頻率翻倍的時候，工作時間縮短一半，假設(shè)功率翻倍時功耗為4倍，則Active部分的實際功率翻倍（50%*4）；同時，節(jié)省出來的時間成為Sleep功耗，此時，系統(tǒng)的功耗變化為：

假設(shè)頻率翻倍前的Active功耗認作C，工作時間為T，則：翻倍前Active部分的功耗為C*T頻率翻倍后，Active的功耗為4C，工作時間為T/2；同時，假設(shè)Sleep的功耗為C/4，則翻倍后的實際功耗為4C*(T/2)+(C/4)*(T/2)=4.25C*T/2=2.125(C*T)可見頻率翻倍后實際功率為增加前的2.125倍。顯然從功耗的角度來說并不劃算。

但請注意，Sleep功耗通常遠遠小于這里的1/4，以ATmega88為例，1MHzVCC=2V的情況下最大功耗是550uA，而Sleep模式（Power-downVCC=3V）最大功耗是15uA，差不多36倍。在這種情況下，顯然頻率翻倍，功耗接近2倍。

有意思的是，如果對以上公式進行迭代，你會發(fā)現(xiàn)，頻率越翻倍，Sleep功耗和翻倍前的Active功耗差距越大。也就是說基本上每次翻倍，功耗基本上可以認為是翻倍的。同時頻率增高帶來的好處卻是運算速度每次都翻倍的。從這個角度來說，是否頻率越高越好呢？（速度快，功耗增加?。?。再聯(lián)系到那些與外部引腳操作直接相關(guān)的功耗，頻率越高，外部引腳操作中可控的功耗部分就小（請聯(lián)系前面AD的例子），那么從這個角度來說，似乎功耗還會減小一些。

再次強調(diào)，以上結(jié)論建立在工作完成后立即休眠的工作模式下，同時Sleep模式的功耗必須遠遠小于Active功耗（通常8~10倍），使用外部時鐘源，以及晶體振蕩器所需的額外功耗，及從休眠中喚醒時時鐘穩(wěn)定期間所需功耗都未作考慮。

>>實際上，MCU的功耗分為兩個部分，一個與頻率有關(guān)，一個與工作電壓有關(guān)，即

E=E(V)+E(f)

當(dāng)頻率翻倍時，影響的只是E(f)，而這部分功耗并不會最終導(dǎo)致4倍的功耗，其值往往在2倍甚至更低。在這種情況下，Sleep+Active的工作模式會帶來更低的功耗。證明略。

>>通常，我們測量功耗的方式就是測量電流

i)推論4：在非積分式功耗測定方式中，如果工作頻率越高，則Sleep時間越長，在電流測量的時候，Active電流越接近于“毛刺”，這就導(dǎo)致了頻率越高，功耗越低的假象。因為大部分的電流采樣點都落在了Sleep上。

ii)推論5：采用積分式功耗測定方法才能正確的測定實際功耗。當(dāng)然，如果你想騙騙普通客戶，高精度電流表的電流結(jié)果（甚至是平均電流）都將反饋給你一個“非常理想的結(jié)果”。

低功耗設(shè)計第二步：讓我們來下棋，很大很大的一盤棋

通過上一節(jié)的討論，假設(shè)在您的設(shè)計中對應(yīng)的步驟已經(jīng)完成，則我們至少獲得了以下信息和結(jié)果：

一個極限功耗

一個可行的系統(tǒng)工作模式（滿足應(yīng)用需求同時兼顧低功耗的系統(tǒng)節(jié)拍）

當(dāng)使用2中提及的系統(tǒng)工作模式時，通過公式計算獲得的理論系統(tǒng)功耗（系統(tǒng)正常工作下的功耗）

顯然，萬事俱備，只欠東風(fēng)，就只剩下具體實現(xiàn)了。別著急，我們先來搞清楚幾個定義。

a.普通工作模式(NormalMode/ActiveMode)

這里的普通工作模式是指能夠?qū)崿F(xiàn)正常系統(tǒng)功能的模式，在這種模式下，MCU并非一直處于工作狀態(tài)，而是根據(jù)前面一章提到的功耗公式，結(jié)合了Active和Sleep兩種MCU狀態(tài)的模式。簡而言之，一個保證了應(yīng)用基本功能的同時能休眠就休眠的工作模式。

b.低功耗模式(IdleMode/SleepMode)

這里所說的低功耗模式是指根據(jù)用戶的應(yīng)用需求，在用戶指定或者系統(tǒng)自動偵測滿足某些特定條件的情況下，盡可能關(guān)閉不需要的功能，僅保留某些應(yīng)用必須的任務(wù)以降低功耗為目的的模式。（例如一段時間沒有用戶操作就關(guān)閉LCD和LED背光）

總結(jié)來說，這里的普通工作模式和低功耗模式都不直接對應(yīng)MCU提供的Active和Sleep模式，而是兩個根據(jù)用戶功能需求定義的具有不同功能配置的功耗模式。他們可能都牽涉到MCU的Active和Sleep狀態(tài)。明確了這兩個定義，我們后續(xù)討論中牽涉到的很多說法才不會混淆。

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

在實踐低功耗系統(tǒng)設(shè)計前，我們必須要有一個有效的手段來檢測或者說觀察系統(tǒng)當(dāng)前的工作模式，通俗的說就是要能夠隨時知道系統(tǒng)什么時候工作，什么時候休眠，并且最好能夠準確的知曉工作和休眠的時間比例。對于缺乏高精度電流表的場合來說，這種觀測手段就更為重要了。

簡而言之，我們需要一種實時追蹤（trace）系統(tǒng)功耗模式的調(diào)試（Debug）手段。既然是實時追蹤，意味著斷點、單步這種常見的手段是不行的，系統(tǒng)必須保證處于正常的非間斷工作狀態(tài)下。同時，作為Debug，必須能夠準確顯示休眠和工作的狀態(tài)，并能夠?qū)⑦@些信息保存下來，大家可以在腦海里想像有這么一個類似地震記錄儀的設(shè)備，一直不停的在紙帶上記錄著功耗變化的信息。說的這么復(fù)雜，其實做起來很簡單。Debug階段，我們關(guān)系的是系統(tǒng)如何休眠的，其實際功耗可能由于Debug手段的存在而并不準確，但這一信息已經(jīng)足夠了，因為在隨后的檢測中，我們可以生成一個release版本（移除了debug相關(guān)的代碼）直接通過電流表檢驗系統(tǒng)功耗。Code2.1就是一個很好的例子。代碼在休眠前在某一個信號引腳上輸出高電平，在退出休眠模式后輸出低電平。此時，借助示波器或者邏輯分析儀的幫助，我們就可以記錄并檢測系統(tǒng)的功耗模式，甚至根據(jù)數(shù)據(jù)手冊提供的Active電流和Sleep電流計算出一個非常接近實際結(jié)果的理論_功耗。

Code2.1一個Tiny下進入Sleep模式的代碼例子

staticvoidenter_sleep_mode(uint8_tchLevel){/*!\briefsleepmodeselectbits*!MODESM2SM1SM0*!idle000*!ADCNoiseReduction001*!Power-save011*!Power-off100*/staticFLASHuint8_tc_chSleepLevel[]={((0x00<

Figure2.1一個可能的系統(tǒng)功耗模式監(jiān)測的樣例