嵌入式低功耗開發(fā)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這個(gè)過程非常關(guān)鍵，他直接決定了日后你能達(dá)到的最好效果。多花費(fèi)一點(diǎn)時(shí)間是值得的，因?yàn)樵谶@一過程中，你能非常細(xì)微的“初步”了解到哪些外設(shè)和配置影響功耗，如何影響，有多大的影響。千里之行始于足下，多花點(diǎn)時(shí)間，值!

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

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

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

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

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

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

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

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

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

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

舉例來說：

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

Equation A: normal power-consumption = sleep consumption * sleep time(%) + active consumption * active time(%) 3)根據(jù)研究報(bào)告，討論系統(tǒng)的可行性。如果不可行，則根據(jù)已經(jīng)明確的系統(tǒng)工作模式，對(duì)應(yīng)的喚醒源要求重新選擇芯片，并返回步驟1)。如果可行，則可以進(jìn)行后續(xù)的設(shè)計(jì)。

Figure 1.1 一個(gè)能體現(xiàn)低功耗節(jié)拍設(shè)計(jì)的系統(tǒng)狀態(tài)圖

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

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

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

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

A. 對(duì)AVR來說，不用的引腳怎么辦?

>> 如果這個(gè)引腳屬于ADC采樣引腳

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

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

>> 如果這個(gè)引腳是普通的GPIO

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

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

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

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

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

B. 對(duì)AVR來說，需要使用的引腳怎么辦?

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

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

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

>> 對(duì)于ADC引腳

i) 如果永遠(yuǎn)不會(huì)用于數(shù)字信號(hào)的輸入用途，請(qǐng)參考空閑引腳的處理方式。

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

>> 對(duì)于控制信號(hào)引腳

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

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

C. 說說PRR寄存器

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

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

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

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

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

D. 說說工作頻率

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

i) 推論1：對(duì)于同樣一個(gè)工作，頻率越高，完成該工作的時(shí)間越短

ii)推論2：根據(jù)Equation A，對(duì)于同樣一個(gè)工作，Active的時(shí)間越短，則Sleep的時(shí)間越長(zhǎng)。

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

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

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

但請(qǐng)注意，Sleep功耗通常遠(yuǎn)遠(yuǎn)小于這里的1/4，以ATmega88為例，1MHz VCC = 2V的情況下最大功耗是550uA，而Sleep模式(Power-down VCC=3V)最大功耗是15uA，差不多36倍。在這種情況下，顯然頻率翻倍，功耗接近2倍。

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

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

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

E = E(V) + E(f)

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

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

i) 推論4：在非積分式功耗測(cè)定方式中，如果工作頻率越高，則Sleep時(shí)間越長(zhǎng)，在電流測(cè)量的時(shí)候，Active電流越接近于“毛刺”，這就導(dǎo)致了頻率越高，功耗越低的假象。因?yàn)榇蟛糠值碾娏鞑蓸狱c(diǎn)都落在了Sleep上。

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

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

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

一個(gè)極限功耗

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

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

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

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

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

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

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

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

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

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

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

Code 2.1 一個(gè)Tiny下進(jìn)入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(); //! 即將進(jìn)入sleep前將信號(hào)引腳置高 __sleep(); //! sleep //!< clear sleep control register MCUCR &= ~(_BV(SM0) | _BV(SM1) | _BV(SE)); clear_signal_a(); //!< 退出sleep模式后將信號(hào)引腳拉低 ) } 有了這樣一個(gè)手段，我們就能很方便的進(jìn)行實(shí)時(shí)調(diào)試，設(shè)計(jì)出“能休眠就休眠”的好算法。這也是我們后續(xù)討論的基礎(chǔ)。

Figure 2.1 一個(gè)可能的系統(tǒng)功耗模式監(jiān)測(cè)的樣例