在越來越多的嵌入式系統(tǒng)應(yīng)用中，節(jié)能和效率已成為開發(fā)人員最優(yōu)先考慮的因素。這種情況可能是出于以下原因：政府管制、增加電池壽命的需求或者僅僅是需要降低用電量。為順應(yīng)這種趨勢，出現(xiàn)了越來越多的“超低功耗”微控制器。不過，至少到近期為止，還沒有出現(xiàn)能夠與之配套的、為開發(fā)人員提供對系統(tǒng)能耗的詳細(xì)監(jiān)控的工具。

擁有低功耗MCU本身并不意味著能耗會更低：關(guān)鍵在于優(yōu)化軟件，不僅僅是功能性方面，而且還要顧及能源效率方面。全面控制MCU周邊的硬件并優(yōu)化軟件和外設(shè)的總體使用率對于降低系統(tǒng)能耗而言是至關(guān)重要的因素。軟件并不總被看作能量的消耗者，但每個時鐘周期都會消耗電能，盡量減少它們，就能降低能耗。

節(jié)能型的嵌入式系統(tǒng)開發(fā)可以看作一種三段循環(huán)：硬件調(diào)試、軟件功能調(diào)試和軟件能耗調(diào)試。

節(jié)能型的軟件開發(fā)
在開發(fā)MCU軟件時，需要考慮的主要問題通常是降低存儲器使用量以及盡可能縮減代碼規(guī)模。為了實(shí)現(xiàn)節(jié)能，一種非常常見的方案是使其在盡可能長的時間里處于睡眠模式，但這并不是唯一的節(jié)能方式。高能源效率的MCU通常提供了其他功能，以達(dá)到更低的能耗。除了使用這些MCU所提供的睡眠模式之外，高效地使用上述的其他功能才是節(jié)能的真正訣竅。

隨著開發(fā)過程的前移，代碼變得更長，而優(yōu)化能源效率則變成了一項(xiàng)更為復(fù)雜的任務(wù)。識別可以用中斷服務(wù)例程代替的非必要等待周期或者外設(shè)誤用等錯誤，都變得越來越困難。如果這些“能源漏洞”沒有在開發(fā)階段被識別并加以解決，那么就幾乎不可能在現(xiàn)場或?qū)嶒?yàn)室測試中檢測到它們。

要查明系統(tǒng)需要使用多少電能，最常見的方法是在一段特定時間內(nèi)對電流進(jìn)行采樣，求平均值并外推到更長的時間周期。這種類型的測量可以使用萬用表或示波器來完成，但通常都不可能將結(jié)果與代碼例程關(guān)聯(lián)起來。

另一方面，邏輯分析儀可以用于記錄例程，但通常無法將其關(guān)聯(lián)到能耗。為了估計(jì)電池壽命，使用外推獲得的結(jié)果不應(yīng)該與真實(shí)使用情況相差太遠(yuǎn)，但是，當(dāng)目標(biāo)旨在優(yōu)化代碼的能源效率時，這種方法的用處很有限。

一種更富有成效的方法
現(xiàn)在，通過使用以圖形化方式實(shí)時顯示能耗信息、并能夠給出任何給定時刻的電流和實(shí)際運(yùn)行代碼之間關(guān)聯(lián)的軟件和硬件工具，就可能顯著地縮短開發(fā)時間并減少工作量。你可以使用電源軌上的電流傳感器來監(jiān)視能耗。

?在確定的時間間隔處，就可以對電流進(jìn)行采樣，完成A/D轉(zhuǎn)換，然后通過USB端口來傳送這一信息——同電壓和計(jì)時一起。此外，MCU會發(fā)送程序計(jì)數(shù)器（PC）采樣，這樣，就可以在主機(jī)計(jì)算機(jī)上將代碼和電流關(guān)聯(lián)起來。

降低1000倍
高級功率監(jiān)控（AEM）系統(tǒng)就是現(xiàn)有工具的一個例子，它是Energy Micro公司EFM32 Gecko（壁虎）MCU的入門工具箱和開發(fā)工具箱的一部分。與電流消耗量有關(guān)的實(shí)時信息將顯示在LCD顯示屏上（如果使用DVK），或者將任何一種工具箱通過USB連接到PC上，然后顯示在該公司的energyAware Profiler上。圖1給出了一種常見的energyAware Profiler顯示。這種工具將以圖形化方式表示出電流與時間的關(guān)系。

圖1 由于可以對代碼更改的作用進(jìn)行實(shí)時監(jiān)控，能耗調(diào)試得以簡化

下面的這個例子將演示如何使用能耗概要分析并結(jié)合EFM32 MCU的特性以節(jié)省能耗。在圖2中，使用了LEUART模塊。它支持波特率高達(dá)9600的UART通信，同時將能耗保持在最小值。

圖2 運(yùn)行模式下的LEUART RX輪詢（a），睡眠模式下觸發(fā)的LEUART RX中斷（b）

從接收緩沖區(qū)獲取數(shù)據(jù)的一種常見方式是對其進(jìn)行輪詢，直到獲得有效數(shù)據(jù)，然后讀取緩沖區(qū)。要這樣做，MCU必須處于運(yùn)行模式，這會造成相對較高的電流使用量。

這一循環(huán)的剖析曲線如圖2a所示，是3.33mA的恒定電流消耗量。通過單擊圖表，就能高亮顯示造成電源消耗的函數(shù)。

void pollLEUARTRx(void)
{while ( !( LEUART0 -> STATUS & LEUART_STATUS_RXDATAV ) );}
高亮顯示的代碼行是輪詢循環(huán)，它會檢查緩沖區(qū)是否接收到任何數(shù)據(jù)。剖析程序?qū)@示每個函數(shù)以及各個函數(shù)對總能耗的貢獻(xiàn)。在這里，代碼中唯一的函數(shù)是pollLEUARTRx（），所有的能耗都是由它產(chǎn)生的（見圖3）。

圖3 能耗函數(shù)

為了避免對RX緩沖區(qū)進(jìn)行輪詢，一種常見的變通方法是啟用RX中斷并將MCU置于睡眠模式。完成之后，很容易看到能耗節(jié)省是巨大的。當(dāng)我們關(guān)閉處理器，電流降至1.40mA（見圖2b）?，F(xiàn)在，當(dāng)LEUART接收到數(shù)據(jù)，它就會被喚醒并通過TX緩沖區(qū)將其傳送回去。

當(dāng)中斷被觸發(fā)時，電流尖峰將達(dá)到2.5mA，而剖析程序會精確定位到中斷例程（見圖4a）。不過，電流將在這個尖峰值保留較長的一段時間，而通過點(diǎn)擊圖表，就可能會發(fā)現(xiàn)在使用UART通信時的另一種常見錯誤。

圖4 帶有LEUART TX輪詢的LEUART RX中斷（a），在接收字節(jié)之間處于睡眠模式下的EFM32（b），以及深睡眠模式下的EFM32（c）

void pollLEUARTTX(void)
{while ( !( LEUART0 -> STATUS & LEUART_STATUS_TXC) );}

在發(fā)送數(shù)據(jù)之后，用戶會設(shè)置一個while循環(huán)以等待傳輸完成。無疑，這會使處理器過長時間保持在運(yùn)行模式之下。這段循環(huán)可以被中斷所取代，一旦傳輸完成，中斷就會喚醒處理器。通過這樣做，就將再次降低電流消耗量（見圖4b）。

現(xiàn)在，在每個接收到的字節(jié)之間，處理器都進(jìn)入睡眠模式，降低了電流。字節(jié)傳輸?shù)耐瓿蔁o須處理器的干預(yù)，所以就不需要輪詢緩沖區(qū)以獲知傳輸何時完成。將循環(huán)替換為中斷例程是一種更優(yōu)雅、更節(jié)能的解決方案，正如這兩種方法的不同剖析圖所示。

深睡眠
EFM32 MCU的LEUART模塊可以在深睡眠模式下工作。在這種模式下，高頻振蕩器被關(guān)閉，但低頻振蕩器（RC或晶振）仍在運(yùn)行并給LEUART提供時鐘。如果將EFM32置于深睡眠模式并重復(fù)上述例子，能耗將降至微安量級。

為了能夠直觀地顯示這些電流數(shù)值，剖析程序從線性坐標(biāo)切換到對數(shù)坐標(biāo)。在深睡眠模式下，電流現(xiàn)在是1μA，而接收到幀時的尖峰值是80μA（見圖4c）。從第一種方法到最后一種配置，節(jié)能倍數(shù)超過了1000。