2008-09-15 27 views
42

在典型的手持/便攜式嵌入式系統設備中電池壽命是H/W,S/W設計以及設備可支持的功能中的主要關注點。從軟件編程的角度來看,人們知道MIPS,存儲器(數據和程序)優化代碼。 我知道的H/W深度睡眠模式,待機模式,用於在較低的週期時鐘硬件或整個時鐘整個一些未使用的circutis節省電力,但我正在尋找一些想法從這一點查看:高效軟件編碼

其中我的代碼正在運行,並且需要繼續執行,因此,如何有效地編寫代碼「power」以便消耗最小瓦特?

是否有任何特殊的編程結構,數據結構,控制結構,我應該看看以實現給定功能的最小功耗。

在代碼結構設計時,還是在低級設計中,爲了使代碼儘可能省電(儘可能降低功耗),是否有任何S/W高級設計注意事項?

+0

同意,這是對我沒有用,但它仍然是一個很好的問題:) – Teifion 2008-09-15 10:18:19

+0

何苦:-) 從我看到在手持設備上大多數應用程序不注重電池的壽命了:-(幸運的是,工作系統仍然會這樣做 – itj 2008-09-15 10:30:50

回答

5

請勿投票。使用事件和其他操作系統原語等待通知事件。輪詢可確保CPU保持活動狀態並延長電池壽命。

1

考慮最少使用網絡接口。您可能希望收集信息並以突發方式發送,而不是不斷髮送。

9

Zeroith,使用完全靜態的機器,可以在空閒時停下來。你不能擊敗零赫茲。

首先,切換到無滴答的操作系統調度程序。喚醒每一毫秒左右的浪費電力。如果您不能,請考慮減慢調度程序中斷。其次,確保你的空閒線程是省電,等待下一個中斷指令。 您可以在大多數小型設備所具備的「用戶空間不足」的情況下做到這一點。第三,如果您必須輪詢或執行用戶信任活動,如更新用戶界面,睡眠,執行操作並重新進入睡眠狀態。

不要相信你沒有檢查過「睡眠和旋轉」類型代碼的GUI框架。 特別是您可能會試圖用於#2的事件計時器。

在讀取而不是使用select()/ epoll()/ WaitForMultipleObjects()輪詢時阻塞讀取線程。 把重點放在線程模擬器(和你的大腦)上,但設備一般沒問題。 這最終會改變你的高層設計;它變得更加整潔! 輪詢你可能做的所有事情的主循環最終會在CPU上變得緩慢而浪費,但確保性能。 (保證慢)

緩存結果,懶洋洋地創建東西。用戶期望設備速度很慢,所以不要讓它們失望。減少跑步更好。儘可能少地運行。 當你停止需要它們時,單獨的線程可以被殺死。

試着獲得比你需要的更多的內存,然後你可以插入到多個哈希表中,並保存任何搜索。如果內存是DRAM,這是一個直接的折衷。

看看比你認爲可能需要的實時系統。它節省了時間(原文如此)。 他們也更好地應對線程。

22
  • 1800 INFORMATION表示,避免輪詢;訂閱事件,等待他們發​​生
  • 更新窗口只在必要時內容 - 讓系統決定何時重新繪製
  • 更新時窗口的內容,確保您的代碼重新創建儘可能少的無效區域儘可能
  • 通過快速代碼,CPU可以更快地回到深度睡眠模式,並且這種代碼保留在L1緩存中的機會更大
  • 一次處理小數據,因此數據仍保留在緩存中
  • 確保您的應用程序不會「在背景中做任何不必要的動作
  • 使您的軟件,不僅節能,而且功率感知 - 更新顯卡較少使用電池,禁用動畫,硬盤驅動器少顛簸

而且讀了一些其他guidelines。 ;)

最近一系列名爲"Optimizing Software Applications for Power"的帖子開始出現在英特爾軟件博客上。可能對x86開發人員有用。

5

從我使用智能手機的工作中,我發現保留電池壽命的最佳方式是確保您的程序在特定點上不需要的所有功能都被禁用。

例如,只有開關藍牙,當你需要的時候,同樣的電話功能,打開屏幕亮度下降並不需要的時候,調低音量,等上

這些函數使用的電源通常遠遠超過您的代碼所使用的能力。

+0

如果你使用像PIC這樣的嵌入式微控制器,請禁用你沒有使用的外設,如A/D轉換器或串口 – MrZebra 2008-09-30 13:03:02

1

看看你的編譯器產生了什麼,特別是對於代碼的熱門領域。

1

如果你有低優先級的間歇操作,不要使用特定的定時器來喚醒它們來處理它們,而是要在處理其他事件時處理。

使用邏輯避免愚蠢的情況,您的應用可能會進入睡眠狀態10 ms,然後必須再次喚醒以進行下一個事件。對於提到的這種平臺,如果兩個事件同時進行處理都不重要。 有你自己的計時器&回調機制可能適合這種決策。代碼的複雜性和維護與可能的節能相比。

1

簡單地說,儘量少做。

0

還有一些不平凡的事情是降低數學運算的精度,尋找可用的最小數據集,如果開發環境包數據和聚合操作可用的話。

Knuth的書可以給你的,你需要節省內存或CPU,或者減小的精度會減少舍入誤差

還具體算法所有的變量,花了一些時間來檢查所有的嵌入式設備的API - 爲例如大多數symbian手機可以通過專用硬件進行音頻編碼

1

那麼,如果您的代碼可以完全在處理器緩存中執行,那麼總線活動就會減少,節省電量。如果您的程序足夠小,可以將代碼+數據完全放入緩存中,則可以免費獲得該優勢。 OTOH,如果你的程序太大,而且你可以將你的程序分成幾乎獨立於另一個的模塊,你可以通過將它分成單獨的程序來節省一些功耗。 (我想也可以製作一個工具鏈,將相關的代碼和數據捆綁到緩存大小的塊中......)

我想,理論上,您可以通過減少數量來節省一些不必要的工作的指針解引用,並通過重構跳轉以便最有可能跳轉 - 但作爲一名程序員來說這是不現實的。

全美達已經讓機器做一些指令優化的即時節省電力的想法......但是,這似乎並沒有幫助足夠了... And look where that got them.

3

爲了避免投票是一個很好的建議。

微處理器的功耗大致與其時鐘頻率成正比,與其電源電壓的平方成正比。如果您有可能通過軟件調整這些功能,那可以節省一些電量。另外,關閉不需要的處理器部件(例如浮點單元)可能會有所幫助,但這非常依賴於您的平臺。在任何情況下,您都需要一種方法來測量處理器的實際功耗,以便了解哪些方法可行,哪些不可行。就像速度優化一樣,功率優化需要仔細分析。

1

將未使用的內存或閃存設置爲0xFF而不是0x00。對於閃存和eeprom來說,這當然是對的,對s或d ram不確定。對於proms來說,存在一個反轉,所以0被存儲爲1並且需要更多的能量,1被存儲爲零並且更少。這就是爲什麼在擦除塊後讀取0xFF。

+0

這似乎是微優化的微型優化 – Earlz 2009-12-10 20:49:34

0

儘快完成您的工作,然後進入一些空閒狀態,等待中斷(或事件)發生。嘗試使代碼儘可能少的外部內存流量從緩存中運行。

0

選擇高效的算法是快速和有小的基本塊和最小的存儲器訪問。

瞭解處理器的緩存大小和功能單位。

請勿訪問內存。如果他們在可用緩存之外展開工作代碼或數據集,請勿使用對象或垃圾回收或任何其他高級構造。如果您知道緩存大小和關聯性,請在低功耗模式下佈置所需的整個工作數據集,並將其全部納入到dcache中(忘記一些將數據分散到不同對象或數據中的「正確」編碼實踐結構,如果這會導致緩存垃圾)。與所有子例程相同。如果有必要,將你的工作代碼全部放在一個模塊中,將其全部在icache中進行條帶化。如果處理器具有多級緩存,請嘗試使用最低級別的指令或數據緩存。不要使用浮點單元或任何其他可能使任何其他可選功能單元上電的指令,除非您能夠很好地使用這些指令來顯着縮短CPU處於睡眠模式的時間。

0

而是適時這一點,今天的文章就Hackaday關於各種命令的測量功耗: Hackaday: the-effect-of-code-on-power-consumption

旁白:
- 中斷是你的朋友
- 查詢/等待( )不是你的朋友
- 做盡可能少的事
- 讓你的代碼儘可能小/高效
- 關閉儘可能多的模塊,引腳,外設儘可能在微型中
- 儘可能慢地運行
- 如果微設置了引腳驅動強度,擺率等,請檢查它們&配置它們,默認設置爲通常全功率/最大速度。
- 回到上面的文章,回去測量電源&看看你是否可以通過改變事情來放棄它。

0

不要投票,睡眠

儘可能避免使用芯片的耗電量較大的區域。例如,乘數是耗電的,如果你可以移動和增加,你可以節省一些焦耳(只要你沒有做太多的移動,並補充說實際上乘數是一個勝利!)

如果你真的很認真,我得到一個功耗感知調試器,它可以將功耗與源代碼關聯起來。 Like this