省電模式奏效 MCU打造低功耗WSN

2010-10-25
環保意識抬頭,各式新的無線技術架構也掀起綠色風潮,而無線技術架構中最重要元件當屬微控制器,其負責運算與傳送資料等功能,若能進一步降低微控制器的功耗,對於整體無線通訊架構的耗電量,也能達到一定的作用,延長電池壽命。
全球對綠色科技和能源使用效率的要求,推動新一代超低功耗無線網路的發展。新一代無線網路主要被應用在工業和控制應用中的遠端感測系統;此外,也促使更多應用採用無需網路電纜或電源線的無線解決方案。

用於監視和控制的感測器網路並非新概念,現有的技術即可實現有線和無線兩種系統,然而,由於有線方案的價格低廉、設計簡便,因此得以廣泛使用;相反地,無線方案則有些限制,僅使用在一些特定的應用。

如今,採用低功耗的設計將協助開發無線感測器系統。新一代無線網路可使用電池供電及能維持更長的工作時間,且在應用的生命週期中僅需很少或者根本毋須進行維護。未來,能量採集(Energy Harvesting)甚至可以提供所需能源,而不再需要電池。本文將著重介紹新一代嵌入式微控制器(MCU)所具有的各種超低功耗控制功能,以及設計人員如何利用這些功能延長無線感測器節點中電池的使用壽命。

MCU功耗管理功能成關鍵

何謂「低功耗」呢?在討論之前,首先須界定一些術語。「能量」為單位時間內所做的功,而「功率」測量功的速率(單位時間使用的能量)。在電子學中,能量=功率×時間;功率=電壓×電流。因此,所要注意的關鍵系統參數為電壓、電流和時間,也就是應用在多大電壓下運作,要消耗多少電流及總共的運作時間。從微控制器的選擇探討這個問題,首先須要比較新型微控制器的各種功耗模式。

三大典型功耗模式各有所長

根據處理需求的不同,應用包含一組預設工作模式。嵌入式微控制器可能只是眾多周邊中的一個,採樣來自周圍環境的訊號,在周邊收集到一定數量的採樣前,微控制器暫時無事可做。因此,為有效節省功耗,微控制器在每次資料採樣期間將採取「休眠」或進入超低功耗的待機模式。一旦周邊收集到足夠的採樣資料,微控制器才會切換至「全速運作」模式,此時微控制器將被喚醒並以最大工作效率運作。

微控制器通常要接收到某些類型的喚醒訊號(Wake-up Event),才會從各種低功耗模式跳脫出來。喚醒訊號包括輸入/輸出(I/O)接腳位準改變的觸發(Toggle)、外部訊號或類似計時器周邊產生中斷等內部處理器的動作。微控制器所支援的功耗模式有所不同,但通常各種功耗模式總有一些共同點,典型的功耗模式如下包括常開模式(Always On)、休眠或待機模式,此時保持對記憶體供電,以及深度休眠模式,此時不對記憶體供電,盡可能地節省功耗。

常開模式
  當系統位於常開模式時,代表系統正處於持續供電的運作狀態。這些系統的平均功耗需求極有可能位在次毫安培(Sub-milliamp)範圍內,從而直接限制微控制器所能達到的處理性能。幸運的是,新一代嵌入式微控制器具有動態控制其時脈頻率的切換功能,因為在無需高速處理的情況下,降低工作時脈有助於減少工作電流的消耗。

待機模式
  在待機模式下,系統處於工作或低功耗非活動的模式。而對系統而言,工作和待機電流的消耗都非常重要。當系統處於待機模式時,由於持續為微控制器記憶體供電,雖然電流消耗顯著減少,但仍可保存所有內部狀態及記憶體內容,並可於數毫秒(ms)內喚醒微控制器。通常,這類系統在大部分時間皆處於低功耗模式,但仍具備快速啟動能力以跟上外部環境的變化,並符合高時效性的系統指令。保持對記憶體的供電有助於保持軟體參數的完整性及應用程式軟體的現狀,一般來說,退出待機模式並喚醒系統所需的時間約為5~10微秒(μs)。

深度休眠模式
  深度休眠模式透過完全關閉嵌入式微控制器核心的活動(包括內建記憶體),為系統盡可能地節省功耗。由於在該模式下不對記憶體供電,因此必須在進入深度休眠模式前將關鍵資料迅速寫入非揮發性記憶體(Non-volatile Memory)。該模式使微控制器的功耗降至最小值,有時甚至可低至20奈安培(nA)。然而,喚醒微控制器後須重新初始化所有記憶體參數,因此延長了喚醒到系統反應的總時間,退出深度休眠模式並喚醒系統所需的時間約為200~300微秒。

在上述採超低功耗模式運作的系統中,電池的壽命通常由電路中整體系統的電流消耗決定。因此,不單單要注意微控制器消耗的電流,而且要關注印刷電路板(PCB)上其他元件消耗的電流。舉例來說,設計人員也可考慮使用陶瓷電容替代鉭電容,因為後者的漏電流(Leakage Current)通常較高,設計人員還可決定在應用處於低功耗狀態下要為哪些電路供電。

利用功耗模式大幅降低耗電量

接下來還有一種可能的情況,在這種情況下,選擇不同微控制器的功耗模式將對系統的總功率造成很大的影響。以一般遠端溫度感測器為例,該應用收集較長時間內的資料,並運用較為成熟的雜訊濾波演算法對資料進行處理,處理完畢則將微控制器重新設為待機模式,直到須進行更多採樣測量為止,這個應用還將採用無線射頻(RF)的傳輸方式將溫度資訊報告給中央控制台。

對溫度進行採樣須使用微控制器內建的類比數位轉換器(ADC),這時會花掉一些少量處理能量。在處理雜訊濾波階段,微控制器必須採用功耗較高的模式執行數位濾波器演算法,並盡快將結果存回記憶體。因此,微控制器只須在短時間內維持高速運作,這樣整體所消耗電力將大大的降低。

每隔一段預定的時間間隔,微控制器就會組合所有的採樣結果並利用RF收發器設備傳送至中央控制台。在這個程序中時機的掌握非常重要,方能確保無線感測器在預先決定的時間內送出採樣資訊,從而允許同一系統中的多個無線感測器節點協同工作。

那麼,又該如何掌握喚醒處理器的頻率呢?透過整合計時器周邊的32kHz振盪器電路,微控制器能很精確地在每秒產生一次中斷,進而保證能在適當時機喚醒處理器。此中斷事件還可以使微控制器按預定的時間表向採樣緩衝區提供溫度資料。

微控制器將溫度資料傳送至採樣緩衝區後,將會切換至處理器的高速模式,以完成較為複雜的雜訊濾波演算,然後盡快返回休眠模式,以縮短工作時間。微控制器採用同樣的即時時脈功能決定將捕捉到的採樣資料發送回中央控制台的時間,微控制器的最佳功耗模式--也就是能消耗最少總電流的模式,取決於多種因素,以下將對此進行討論。

最佳能源利用率左右MCU功耗

要降低整體功耗,僅選擇微控制器最低功耗的模式是不夠的,還必須確定微控制器必須完成的任務是否能被達成,如採樣外部溫度的任務。一旦確定每個任務的性能需求,還必須確定每個任務的最佳能源利用率,請參考前面提到的公式,能量=時間×電壓×電流,由於系統整體需求和實際電源已決定電壓值,因此公式中所列的電壓並沒有什麼改變的空間,如此一來,只能操作兩個參數,即時間和電流。並須權衡微控制器的工作時間和電流消耗,以下將探討在執行上述分析時要切記的一些微控制器參數。

喚醒處理器
  將微控制器置於低功耗模式後,可透過外部的觸發將其喚醒,例如透過通用序列匯流排(USB)、即時時脈的設置,甚至是I/O接腳上的外部觸發訊號。微控制器從低功耗「休眠」模式喚醒並開始執行程式碼的時間非常重要;通常,須盡可能地縮短喚醒時間,這也是之所以要在「休眠」和「深度休眠」模式間選擇的原因。由於微控制器從「休眠」模式到執行代碼只需要10微秒,若須每秒喚醒一 次微控制器,毋須初始化任何軟體記憶體位置(Software Memory Location),因此判斷休眠模式為降低功耗的最佳選擇。若微控制器處於低功耗狀態的時間較長,如數分鐘甚至數小時才須喚醒一次,則「深度休眠」模式可能是最佳選擇。選擇的關鍵是何種模式能使微控制器在完成任務之餘,總電流的消耗量最小,若微控制器處於低功耗模式的時間較長,300微秒的喚醒時間比起數分鐘或數小時的深度休眠時間就微不足道了。

系統級喚醒事件的另一個絕佳範例,可藉著透過串列介面連接到處理器的外部RF晶片進行說明。處理器閒置時,可將其置於某個低功耗狀態下,僅保持RF晶片運作。由於新一代RF晶片的邏輯僅負責搜尋流入的RF資料封包,因此即使保持在工作狀態下,消耗的電流也很小。一旦接收到與該單元的指定位址相關的有效資料封包,亦即須要處理的有效資料封包,則喚醒微控制器開始處理資訊,此類功耗模式通常用於無線網路的解決方案中,例如那些根據ZigBee無線協議設計的解決方案。

時脈頻率
  微控制器從外部或內部時脈源(Clock Source)獲取系統時脈頻率,再依應用程式所需的工作時脈頻率劃分該時脈頻率。較低的頻率通常等同於較低 的功耗,有時,微控制器還可以採用鎖相迴路(PLL)以倍頻方式增加內部系統的時脈頻率,提高執行效能。外部系統時脈訊號通常來自石英振盪器(Crystal Oscillator)。

當元件進入低功耗模式時,微控制器還可以關閉石英振盪電路,以節省幾毫安培的電流,但由於外部晶體振盪器啟動時造成的的延遲,因此在恢復正常工作狀態時振盪器的啟動時間將會延長。然而,有些微控制器具有採用雙速啟動模式(Two-speed Startup Mode)的能力,在這種模式下,微控制器將優先使用內部振盪器並立刻開始運作,並在更精確的外部時脈源穩定後,自動切換至外部時脈源。

微控制器控制自身時脈頻率的能力將能協助軟體工程人員在總電流消耗最少的情況下,選擇適用於特定任務的時脈速度。因此,工程人員須評估能量公式中的時間×電流等參數,以確定何種方案較好,決定在較短時間內全速運作,或在較長時間內慢速運作,或是介於兩者之間。

即時時脈
  在本文的遠端無線感測器應用範例中,系統對時間的掌握必須要非常精確。除系統時脈外,還可採用即時時脈和日曆(RTCC)周邊輕鬆實現掌握時間。RTCC的主要功能是追蹤日期和時間,在本文的範例中,RTCC能夠協助控制功耗模式,更能在適當時間協助喚醒微控制器、觸發採樣測量或與中央控制台開始同步訊號。

在系統中配備RTCC有多種方法,第一,可將專用RTCC晶片連結至微控制器;第二,可採用整合基本計時軟體、32kHz的石英振盪器,第三則是可採用擁有專屬RTCC的微控制器。對系統成本的考量通常在第一時間就排除第一種選擇,對後兩種方法的選擇則須綜合考慮微控制器應用的其他需求及成本的限制。以下將詳述第二種方法,也就是利用32kHz振盪器與一些非常基本的軟體加入RTCC的功能。

外部32kHz晶體振盪器驅動電路與16位元計時器配合使用,每秒喚醒一次處理器。每秒喚醒一次處理器除更新RTCC計時器,也可能測量當前溫度。然後處理器再返回到低功耗模式,此方法提供一種占用動作時間非常小的機制,而元件運作的大多數時間都在休眠模式下僅消耗600奈安培的電流。

建立RF無線感測節點須注意各項參數

高度整合的單晶片通用工業、科學和醫療(ISM)頻率調變方式收發器解決方案(FSK Transceiver Solution)搭配低功耗微控制器,能輕鬆實現無線感測應用。在本例中,微控制器採用序列周邊介面(SPI)作為與射頻設備連接的串列通訊埠,並使用微控制器初始化收發器設備的射頻設定。設定完成後,收發器設備將透過微控制器發出的基本串列命令處理大多數RF資料的發送和接收,結合這兩種技術,即可建構基本網路以遠端監視各種數位或類比的無線感測器節點,如本文中的遠端溫度感測器。

評估無線系統的總功耗預算,最關注的參數不外是RF系統的傳送功耗、接收功耗、待機功耗及須耗費的啟動時間。了解這些參數後,將能確定系統通過無線RF通道發送和接收資料所消耗的電流,除此之外,以下也將詳述開發RF解決方案時須注意的兩個重點,包含發送的資料長度和安全性。

RF發送時間
  設計人員常常忽略考量RF資料封包的大小,事實上,RF發送時間對無線解決方案的性能、品質和功耗影響很大,較小的資料封包有助於減少電力需求,甚至可以縮小電池體積,因此,在決定新的低功耗RF協議時,設計人員必須將這點牢記在心。

針對無線溫度感測器的設計,可試著評估目前通用的各種RF通訊協定,諸如ZigBee、ZigBee Pro、微芯(Microchip)的MiWi和MiWi P2P協議。由於本應用要求較低的功耗,所以決定採用基本的時間分割多重存取(TDMA)協定。

透過在RF資料框(Dataframe)中預先分配時間(Predefined Time Slot),並利用第一個時間槽(Time Slot)作為中央處理器(CPU)發送的訊框起始封包(Start-of-frame),藉此確保整個感測器監視系統的精確時序,同時降低功耗。採用這種基本時間片段的方法,微控制器和RF收發器可在大多數時間內皆保持低功耗待機模式。

安全性
  隨著無線網路在傳送資料中可能造成的安全問題漸漸受到關注,大多數RF系統均採用強大的演算法保護資料。具有128位元密鑰的高級加密標準(AES)可透過軟體執行,確保資料完整性及系統抵抗駭客的能力,對商務應用至關重要。對於無線感測器節點來說,為節省節點工作時的功耗,須盡可能縮短節點的工作時間,因此,能快速執行AES演算非常重要,微控制器可按需求、動態更改處理能力加速AES的演算。除由電池供電的無線設備以外,採用有線電源的系統,考量功耗對整體系統的溫度、體積及成本均有影響,也須要加速AES演算。

系統成本
  眾所周知,系統的總成本在設計任何系統,如無線溫度感測器的過程中始終為非常重要的考量,確定無線微控制器成本的關鍵因素是所需程式和資料記憶體的大小。感測器網路和相關產品的開發人員偏好採用大儲存空間的微控制器滿足應用程式的需求,開發基於網路協定層如ZigBee的應用程式時,需要較大的儲存空間,某些情況下則需要至少250KB的記憶體。若要為成本相當有限的設計增加基本的傳輸功能,可利用微控制器的許多功耗控制功能最大程度地降低成本和功耗。

硬體/軟體
  本文中的設計範例組合使用配備通用ISM頻寬調變收發器的單一晶片和一顆超低功耗的微控制器。感測器內的超低功耗微控制器每秒測量一次類比溫度感測器,並將結果存入資料緩衝區,進行複雜的雜訊濾波演算法,然後採用RF收發器發送結果資料。出於安全考慮,此資料已透過AES演算法保護並在預定分配好的時間內發送。此外,微控制器在接上電源後初始化RF收發器的射頻設定,並按需求控制射頻設備的功耗模式。

本文介紹如何輕鬆建置低功耗無線感測器網路的過程。藉由全面地理解超低功耗微控制器的各種功耗管理功能,有助於系統設計人員開發環保的「綠色」無線設計方案。只要選擇合適的超低功耗微控制器和RF射頻產品,評估整體系統的需求,然後使用微控制器的功耗管理設定,即可使系統處於低功耗「休眠」狀態,以有效降低成本。

(本文作者為微芯安全、微控制器及技術開發部門應用工程經理)

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!