1 低功耗的意義

電子產品尤其是電池供電的都要求低功耗，究竟怎樣才算低功耗？脫離應用場合的數值沒有意義，低功耗是一種看情況而定、只可意會的標準。

2 思路決定成敗

芯片數據手冊寫著低功耗，上面那些小的出奇的電流標準，只是用來擺設的一種無法工作的假死狀態，工作功耗才是實實在在的。有時為了體現低功耗，還要在應用中設計所謂的低功耗模式，當系統確認沒有任務時就休眠。于是乎，低功耗這種“既要馬兒跑，又要馬兒不吃草”的邏輯，就成為降低正常工作模式下系統功耗的常規選擇。

從硬件角度來說，找到所有可能消耗電流的回路，確定哪些是可以通過軟件控制的方式來優化，哪些是不可避免的，并給軟件開發人員提供所有IO口狀態對功耗影響的關系，用簡單的表格說明一下高電平或低電平會怎樣，懸浮會怎樣。前期配置驅動軟件，驗證工作時最小電流滿足標準，基本可確認硬件正常。剩下的就是軟件開發人員的發揮空間，而基于軟件的降功耗策略，正是本文所要討論的重點。

3 驅動軟件設計

3.1 端口配置

首先確認復位后引腳的默認狀態，該狀態下是否漏電，是否會開啟某些時鐘源，是否內部上拉或下拉，軟件再結合硬件或外圍做相應配置。例如AD通道禁止內部上拉，普通GPIO設為輸出低或者高避免漏電，懸空引腳避免中斷輸入模式。

固定連接控制的，可以推挽輸出控制外設，或者外部帶上拉時選開漏；特殊引腳如UART一般配置模式即可，硬件自動控制對應電平；間歇性工作如ADC，作為輸入轉換完成后，可以再設為輸出或關閉AD。

有些外設是可以插拔的，如UART正常空閑時收發都是高，如外設關機或者移除，仍保持高電平則存在漏電，這種情況下需將引腳設為輸出低。重點關注工作中一種狀態，工作結束或異常時要及時切換狀態，避免漏電或者電平不匹配。

如果外設支持中斷盡量配置開啟，而不是定時輪詢通信。

3.2 電源管理

芯片內部往往劃分不同的電源域，硬件外設也分不同單元的供電，暫時不使用的部分，可以立刻關閉電源域、時鐘域。在硬件成本允許或者功耗要求嚴苛的情況下，外設盡量獨立供電，這樣在非使用狀態下軟件控制斷電。需要注意關閉電源域后，某些端口可能需要重新配置避免漏電，如上節所提到關閉外設的供電后，外設的UART端口變為低，主控的UART端口就不能繼續維持高電平了。

3.3 系統時鐘

在正常的工作模式下，頻率越高功耗越高，完成同樣工作的時間越短，也可更快進入休眠。如果單片機主要做控制，沒有復雜運算，降頻能實現需求就往更低的頻率切換。如果有大量數學計算，可以空間換時間，或者先高頻運行，盡快完成算法，運行結束后動態切換到低頻。

同等時鐘下，供電電壓低功耗也低；定時采樣、屏幕刷新也可在滿足需求的情況下盡量低頻處理。

3.4 待機底電流

查閱數據手冊或者SDK官方文檔，確定符合需求的、可被喚醒的最低功耗休眠模式，編寫一個測試用例，關閉所有可能耗電的外設，進入休眠的狀態，驗證極限情況下的功耗。

可能還需要硬件排除電路板上無法優化的固有功耗，比如電壓轉換等固定消耗電流的部分，單純看主芯片的工作電流，是否達到數據手冊上對應模式下的理論值。如果不滿足就需要繼續關閉一些復位后自動開啟的功能，比如時鐘使能等；或者硬件工程師配合拆除可疑器件加快排查。這第一步非常關鍵，直接決定后期整機功耗能達到的最佳效果，同時在配置過程中，非常細微的認識到哪些外設和配置影響功耗，如何影響，有多大的影響。

3.5 休眠與喚醒

休眠后有的是降頻工作，有的是假死（軟件未運行，內存可恢復；有的不能恢復，喚醒類似重啟效果），或者直接關機（RTC關機鬧鐘喚醒），不同的硬件方案和軟件需求，休眠模式的表現不同。單片機開發，確認其所有的休眠模式，以及對應休眠模式下哪些時鐘源工作或休眠，結合具體應用的需求，明確系統對喚醒源以及喚醒模式的需求，由此便確定了系統的基礎休眠模式。

注意有些芯片在休眠模式下僅少數端口維持喚醒的狀態，只有特殊引腳才能喚醒，這需要硬件設計前考慮。

3.6 功耗評估

降低功耗是軟件和硬件協同工作才能解決的問題。比如AD采樣時候的分壓電阻，如果直接接了地，那會一直消耗電流；增加分壓電阻足夠大，表面上靜態電流小，但因為AD內阻分流，最終結果就存在較大偏差。如果通過一個IO口來控制其接地的方式，只在需要采樣的時候接地，采樣完成后懸浮或者拉高，就可以將靜態損耗降到最低，雖然成本加了不少，但實實在在的省電了。具體是否采用，主要是看功耗的標準，如果略微可以接受持續的靜態損耗，就沒必要增加硬件成本。

系統實現最低功耗，有時需要在外設性能、硬件成本和功耗之間做妥協，CPU是否可以降頻，硬件外設是否支持中斷喚醒等，這些都會影響最終的待機功耗，降低功耗是硬件和軟件配合的結果，軟件配置驅動，硬件逐個確認電流是否在期望之內，這理論值定義就看原廠資料或者經驗了，以及與產品定義的待機時長妥協解決。

4 業務軟件設計

低功耗從硬件上能夠解決一部分，但單純依靠硬件肯定是不行的，需要軟件的密切配合，才能達到最好的效果。以上是從硬件驅動層面的，一般情況下都比較關注，但實際上軟件業務層的靈活性高，發掘低功耗的效果比硬件低功耗本身的效果更加顯著，通俗地講，底層硬件辛辛苦苦地優化設計節省的效果，遠遠不如軟件設計得好的表現。

從軟件的業務邏輯、產品需求方面的設計，在功耗方面更有意想不到的效果，軟件功耗優化簡單總結就是“能睡就睡”。

4.1 任務周期化

一個嵌入式產品包括很多子功能、子任務，一個應用是對若干服務的調用實現的。這里服務可以是硬件服務，比如AD電壓采樣、UART串口通訊，也可以是軟件服務，比如TCP/IP網絡通信等。簡單的功能如CRC校驗，純軟件實現，函數運行立即獲得結果，對功耗無所謂影響；復雜的功能，盡量使用任務的方式來實現，并不是特指操作系統的task或者thread，可以理解為一個流程，即一個子功能運行的完整過程。一件事有始有終就可以根據需要循環反復，周期運行的任務，明確運行的起止時間點，區分運行與非運行狀態就能更好的優化，比如減少運行持續時間或者其中大電流的時間段，在功耗方面效果比較明顯。

4.2 休眠自理與協調

將整個嵌入式軟件系統分成了很多周期性工作的小任務，它們可能是交錯的或者毫無關系并行的。從本質上說，每個小任務只需關注自身的起止時間點。系統的功耗管理就是為每個任務的功耗進行管理，整體在一個有效的協調方式下才能做到功耗最小。基于任務的功耗管理實際上分成兩個部分，微觀角度單任務自身的功耗管理，和宏觀角度多任務的休眠協調。

從微觀角度來看，一個任務能獨立完成自己的功能，任務中所有的步驟都是確定的，都是“自己說了算的”，對外界來說是“黑盒子”，對低功耗的要求，不外乎以下幾種情形：

(1)、任務執行的過程中不允許休眠，因此任務的開頭和結尾處要設置標志，告知協調系統，“只要我不同意，就不允許系統休眠”。 (2)、任務執行的過程中，某些階段允許休眠，某些階段不允許休眠；任務的執行過程中，不同階段允許不同的休眠等級。 (3)、任務執行的過程中，不在乎是否休眠。

三類任務同時存在于系統中，第一類任務是相當霸道的，只要它在執行，根本不允許休眠；第二類任務既完成了任務，又兼顧了休眠；第三類任務基本上可當做空氣無視。系統任務設計時應盡可能編寫后兩類任務，避免或者嘗試拆分第一類任務。

從宏觀角度來看，任意時刻可能有多個任務同時在執行，每個任務對休眠的需求都是不同的。如果要設立一個協調機制，該怎么辦呢？每個任務按最低需求，隨時來休眠協調機構簽到投票，表明自身當前能夠容忍的最低功耗對應的休眠等級，休眠協調機構的仲裁者定時或輪詢檢查所有任務的投票結果，找到最小的休眠等級，類似水桶的最矮一環作為“共識”，然后進入相應的休眠等級。

如果有人投了“不休眠”的票，仲裁就只能放棄休眠。所以，每一個任務都應該是一個負責的任務，都應該根據自己的不同步驟及時的更新自己對休眠的容忍度，從而保證投票能夠達成有意義的結果。

這種機制實現也很容易，比如

uint16_t sleep_enable = 0xFFFF; //0xFFFF表示可以進入休眠

uint16_t sleep_enable=0xFFFF，表示系統可以進入休眠，每個任務獨立的操作相應的一位，禁止休眠時清0，允許休眠則置1。休眠協調機制即定時查詢sleep_enable是否為0xFFFF，可以在main輪詢或RTOS的待機任務查詢，進行休眠的進出。

任務的劃分合理，盡量允許休眠，通過這種協商機制可以解決“能睡就睡”的問題。

4.3 任務等待合并

設備運行中必然存在定時喚醒的任務，多個定時任務隨機的在任意時刻喚醒工作，導致頻繁退出休眠。這種情況下，在最大允許延遲的情況下，多個任務可以在一次喚醒全部執行。比如去超市買菜，肯定是一次把當天需要的菜都買了，而不是每餐前都去買，一天到晚跑超市。在4G物聯網產品應用，比如設備每3分鐘需要向服務器發送一個TCP/IP心跳包，同時傳感器每10秒采集一個數據也需要上報服務器，可以實現為數據緩存，等到3分鐘的定時器溢出上報時，將采集的多組傳感器數據組合一并上報，減少無線網絡模塊喚醒的次數。

4.4 及時止損

因為環境或外設組合不同，可能在某些時間段無法實現需求，或者結合當前信息大概率無法實現，或者硬件部分故障，軟件監測到這種異常后，需要及時止損，減少不必要的消耗。例如GNSS衛星定位，其屬性就是必須在開闊區域才能定位，如果設備開啟GNSS但發現信號很差，可初步判斷當前位置可能在室內，即使繼續工作也不能定位，可以立刻關閉GNSS節省電量；當然產品在需求層面需要考慮不定位的其他操作。或者通信中確認外設不存在或者損壞，就沒必要繼續供電定時交互，進行異常報警即可。

4.5 需求層面

在需求定義時，充分考慮某個任務或外設工作的起止要求，避免長時間進行無效工作。例如可以根據加速度傳感器判斷設備是否處于運動狀態在開啟監控，或者通過紅外或聲控判斷有人接近才開啟工作。這種都是通過產品定義，在需求層面組合，滿足要求才喚醒工作，不滿足則及時停止進入休眠，當然也可能增加硬件成本。部分設備也可以考慮使用場地增加太陽能充電板，開源節流。

關于軟件設計模式可以參考嵌入式軟件的設計模式（上）、嵌入式軟件的設計模式（下）。

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

在實踐低功耗系統設計前，必須要有一個有效的手段來檢測或觀察系統當前的工作模式，可直觀知道系統什么時候工作，什么時候休眠，工作時長和休眠時長，高精度的電流表必不可少，如果可以記錄電流-時間曲線更佳，針對電流曲線有針對性的優化軟件流程或時間參數。

來源： 本文轉載自嵌入式系統公眾號

審核編輯：湯梓紅