循序漸進式的功耗優化已經不再是超低功耗mcu的游戲規則，而是“突飛猛進”模式，與功耗相關的很多指標都不斷刷新記錄。我們在選擇合適的超低功耗mcu時要掌握必要的技巧，在應用時還需要一些設計方向與思路才能夠更好的應用。

一：低功耗mcu的選擇方法

嵌入式微控制器 （mcu）的功耗在當今電池供電應用中正變得越來越舉足輕重。大多mcu 芯片廠商都提供低功耗低功耗產品，但是選擇一款最適合您自己應用的產品并非易事，并不像對比數據表前面的數據那么簡單。我們必須詳細對比 mcu 功能，以便找到功耗最低的產品，這些功能包括：斷電模式、定時系統、事件驅動功能、片上外設、掉電檢測與保護、漏電流、處理效率。

在低功耗設計中，平均電流消耗往往決定電池壽命。例如，如果某個應用采用額定電流為 400mAh 的 Eveready 高電量 9V 1222 型電池的話，要提供一年的電池壽命其平均電流消耗必須低于 400mAh/8760h，即45.7uA。

在使 mcu 能夠達到電流預算的所有功能中，斷電模式最重要。低功耗 mcu 具有可提供不同級別功能的斷電模式。例如，TI 超低功耗 mcu MSP430 系列產品可以提供 5 種斷電模式。低功耗模式 0 （LPM0） 會關閉 CPU，但是保持其他功能正常運轉。LPM1 與 LPM2 模式在禁用功能列表中增加了各種時鐘功能。LPM3 是最常用的低功耗模式，只保持低頻率時鐘振蕩器以及采用該時鐘的外設運行。LPM3 通常稱為實時時鐘模式，因為它允許定時器采用低功耗 32768Hz 時鐘源運行，電流消耗低于 1uA，同時還可定期激活系統。最后，LPM4 完全關閉器件上的包括 RAM 存儲在內的所有功能，電流消耗僅 100 毫微安。

時鐘系統是mcu功耗的關鍵。應用可以每秒多次或幾百次進入與退出各種低功耗模式。進入或退出低功耗模式以及快速處理數據的功能極為重要，因為 CPU會在等待時鐘穩定下來期間浪費電流。大多低功耗 mcu 都具有“即時啟動”時鐘，其可以在不到 10～20us 時間內為 CPU 準備就緒。但是，重要的是要明白哪些時鐘是即時啟動、哪些非即時啟動的。某些 mcu 具有雙級時鐘激活功能，該功能在高頻時鐘穩定化過程中提供一個低頻時鐘（通常為32768Hz），其可以達到 1 毫秒。CPU 在大約 15us 時間內正常運行，但是運行頻率較低，效率也較低。如果 CPU 只需要執行數量較少的指令的話，如：25 條，其需要 763us。CPU 低頻比高頻時消耗更少的電流，但是并不足于彌補處理時間的差異。相比而言，某些 mcu 在 6 微秒時間內就可以為 CPU 提供高速時鐘，處理相同的 25 條指令僅需要大約 9us（6us 激活＋25 條指令′0.125us指令速率），而且可以實現即時啟動的高速串行通信。

另外，如果 mcu 時鐘系統為外設提供多個時鐘源的話，當 CPU 處于睡眠狀態時外設仍然可以運行。例如，一次 A/D 轉換可能需要一個高速時鐘。如果 mcu 時鐘系統提供獨立于 CPU 的高速時鐘，CPU 就可以在 A/D 轉換器運行情況下進入睡眠狀態，從而節省 CPU 耗流量。

事件驅動功能與時鐘系統的靈活性并存。中斷會使 mcu 退出低功耗模式，因此，mcu 的中斷越多，其防止浪費電流的 CPU 輪詢與降低功耗的靈活性就越大。輪詢意味著進行與不進行功耗預算之間存在差異，因為它在等待出現事件時會浪費CPU 帶寬并需要額外電流。一個好的低功耗 mcu 應具有充分的中斷功能，為其所有外設提供中斷，同時為外部事件提供眾多外部中斷。

按鈕或鍵盤應用可以證明外部中斷的優勢。如果不具備中斷功能，mcu 必須頻繁輪詢鍵盤或按鈕，以確定其是否被按下。不僅輪詢自身會消耗功率，而且控制輪詢間隔也需要定時器，其會消耗附加電流。相比而言，在具備中斷情況下，CPU 可以在整個過程中保持睡眠狀態，只有按下按鈕時才激活。

在選擇低功率 mcu 時，還需要考慮外設功耗與電源管理。某些低功率 mcu 僅僅是設計時不具備低利率功能的舊架構的改進版本。而有些 mcu 在設計時即具備低功耗特性，并在其外設中內置了低功耗功能。一種特性是在需要時單獨啟動或關閉外設的能力，換言之，更重要的是自動啟動或關閉外設的能力。 A/D 轉換器就是一個例子，其在完成一次轉換后可以自動關閉。另外，某些 mcu 正在引入直接存儲器存取功能，其可以在無需 CPU 干預情況下自動處理數據。

大多 mcu 具有集成的掉電保護功能，當電源低于正常操作范圍時其可以復位 mcu。通常會提供啟動或關閉掉電保護以節省功耗的功能，但是必須在整個過程中都使掉電保護功能置于可用狀態，因為掉電是不可預測的。某些 mcu 需要70uA 的電流來實現掉電保護。在只需要 45uA 平均電流的應用實例中很明顯可以不考慮這些 mcu。 ----在選擇低功耗 mcu 期間有時會忽視漏電流，但是，在最苛刻的低功耗應用中則必須考慮到漏電流。大多改進后的低功耗 mcu 都具有 1uA 的限定輸入漏電流。在 20 輸入器件中，它可能會消耗 20uA！針對低功耗設計的最新 mcu 具有最高50nA 的漏電流。

最后，我們常常會誤解 mcu 處理效率。大家通常會認為 16 位 mcu 需要兩倍于 8 位 mcu 的內存，但是一個 16 位架構實際上需要比 8 位架構要少一些的代碼，而 16 位 mcu 一般會更快速地執行任務。例如，8 位 mcu 需要 CPU 開銷來管理具有 10 位 A/D 轉換數據或需要 16 位計算的應用中的數據。而且當今許多mcu 產品都具有單個工作文件或累加器，其數據必須進行傳輸，以便處理，因此，與基于寄存器的架構相比需要額外的 CPU 開銷。表 1 說明在 16 位現代架構與8 位 8051 架構上傳輸 10 位 A/D 數據的指令。在采用 1Mhz 時鐘情況下，16 位器件需要 6us 進行傳輸，而 8 位器件則需要 24us。

16 位 mcu8 位 mcumov.w &ADC10MEM，&RAMmovf ADRESH，W movwf RAML bsf 0x20 movlf ADCHRESL，W bcf 0x20 movwf RAMH ----表 1：16 位與 8 位 mcu 代碼要求

選擇低功率 mcu 是一項耗時、棘手的工作。如果花費一些時間來了解可用產品選項的架構特性，我們就能夠開發出能滿足最苛刻功率預算的設計。

二：如何降低mcu的功耗

低功耗是mcu的一項非常重要的指標，比如某些可穿戴的設備，其攜帶的電量有限，如果整個電路消耗的電量特別大的話，就會經常出現電量不足的情況，影響用戶體驗。

平時我們在做產品的時候，基本的功能實現很簡單，但只要涉及低功耗的問題就比較棘手了，比如某些可以低到微安級的mcu，而自己設計的低功耗怎么測都是毫安級的，電流竟然能夠高出標準幾百到上千倍，遇到這種情況千萬不要怕，只要認真你就贏了。

下邊咱們仔細分析一下這其中的原因。

1掐斷外設命脈——關閉外設時鐘

先說最直觀的，也是工程師都比較注意的方面，就是關閉mcu的外設時鐘，對于現在市面上出現的大多數的mcu，其外設模塊都對應著一個時鐘開關。只需要打開這個外設的時鐘，就可以正常的使用這個外設了，當然，此外設也就會產生相應的功耗;反之，如果想要讓這個外設不產生功耗，只需關閉它的時鐘即可。

2讓工作節奏慢下來——時鐘不要倍頻

除了外設模塊功率消耗之外，還有一個功耗大戶需要注意一下，這就是PLL和FLL模塊。PLL和FLL主要是用來對原始的時鐘信號進行倍頻操作，從而提高系統的整體時鐘，相應的，其功耗也會被提上去。所以在進入低功耗之前，需要切換是種模式，旁路掉PLL和FLL模塊，從而盡可能的降低mcu的功耗，等到mcu喚醒之后再把時鐘切換回去。

3圍堵涓涓細流——注意I/O口的電平狀態

如果認為只要關閉外設時鐘就能夠保證外設不再耗電，那么你就太天真了。如果IO口沒有做好處理的話，它就會在暗地里偷走功耗，而你卻渾然不知。具體原因是這樣的，一般的IO的內部或者外部都會有上下拉電阻，舉個例子，如下圖所示，假如某個IO口有個10KΩ的上拉電阻，把引腳拉到3.3V，然而當mcu進入低功耗模式的時候，此IO口被設置成輸出低電平，根據歐姆定律，此引腳就會消耗3.3V/10K=0.33mA的電流，假如有四、五個這樣的IO口，那么幾個mA就貼進去了，太可惜了。所以在進入低功耗之前，請逐個檢查IO口的狀態：

如果此IO口帶上拉，請設置為高電平輸出或者高阻態輸入;
如果此IO口帶下拉，請設置為低電平輸出或者高阻態輸入;

總之一句話，不要把上好的電流浪費在產生熱量的功能上，咱可不靠這點溫度去暖手。

4睦鄰友好合作——注意I/O與外設IC的統籌

IO口的上下拉電阻消耗電流這一因素相對比較明顯，下邊咱來說一個不明顯的因素：IO口與外部IC相連時的電流消耗。假如某個IO口自帶上拉，而此與IO相連的IC引腳偏偏是自帶下拉的，那么無論這個引腳處于什么樣的電平輸出，都不可避免的產生一定的電流消耗。所以凡是遇見這一類的情況，首先需要閱讀外設IC的手冊，確定好此引腳的的狀態，做到心中有數;然后在控制mcu睡眠之前，設置好mcu的IO口的上下拉模式及輸入輸出狀態，要保證一絲兒電流都不要被它消耗掉。

5斷開調試器連接，不要被假象所迷惑

還有一類比較奇特，檢測出來的電流消耗很大，可實際結果是自己杞人憂天，什么原因呢?是因為在測試功耗的時候mcu還連接著調試器呢!這時候大部分電流就會被調試器給擄走，平白無故的讓工程師產生極度郁悶的心情。所以在測低功耗的時候，一定不要連接調試器，更不能邊調試邊測電流。

總結

mcu的低功耗設計是一個細致活，要養成良好的習慣，做到每添加一個功能都要重新驗證一下低功耗是否符合要求，這樣就可以隨時隨地干掉消耗功率的因素。如果把所有功能都設計好了才去考慮低功耗的問題，一個不小心，就可能要更改程序的架構——即便如此也不一定能把功耗給徹底降下去。