Ember endDevice 功耗/睡眠機制

參考轉自 https://www.sekorm.com/news/9339.html

 

EFR32MG自己具備五種低功耗工做模式：

EM0：Active狀態，此時CPU活動、外設活動，功耗最高，最低65uA/MHz。

EM1：IDLE狀態，此時，CPU中止，外設活動，功耗和所使用的外設有關，通常能夠認爲此時3mA~5mA左右的功耗。

EM2：Deepsleep狀態，此時，部分LFXO或LFRCO、ULFRCO低速時鐘的外設活動，RAM保存，標稱此時電流爲1.5uA。

EM3：Stop狀態，此時高速時鐘HFXO或HFRCO、LFRCO、LFXO均會被關掉，ULFRCO活動，採用ULFRCO的外設仍然能夠運行，可選的RAM保存，如RTCC/WDOG/CROTIMER。

EM4H：冬眠狀態，從該狀態開始，RAM的保存將受到限制，最多經過RTCC外設的RAM區保存128字節的RAM數據。所以，該狀態喚醒將會將系統復位。在該狀態下，可使用Cryotimer和指定的GPIO喚醒。

EM4S：關閉狀態，在該狀態下，全部外設基本都關掉，RAM所有丟失，能夠經過基於ULFRCO的Cryotimer或指定的GPIO喚醒，喚醒後系統復位。

 

在EmberZNet協議棧中，使用到了EM0 、EM一、EM2和EM4H模式，主要的休眠工做在idle-sleep-soc.c line21的void emberAfPluginIdleSleepTickCallback(void)函數中處理。

流程以下：

 

1.要關閉全局中斷，保證睡眠的處理不被中斷打斷和篡改。

 

2.是否能夠進入休眠，判斷條件是

1）開發者是否指定保持喚醒狀態不休眠。

2）開發者是否指定未加入網絡時不休眠。

3）是否有串口正在發送數據，此時不能休眠。

4）是夠有任務等待執行，若是有則不能休眠，要處理就緒的任務，包括用戶任務和協議棧任務。

 

若是這些均所有經過，那至少能夠進入IDLE狀態了。

 

3.若是斷定能夠休眠，對於Sleepy End Device來講，因爲RADIO在休眠時是不能夠打開的，所以，還須要進行進一步判斷是否能夠關閉Radio，進入休憩模式，判斷依據是查詢是否有高優先級的協議棧任務須要運行，目前定義是4個任務具備高優先級：

1）RADIO數據發送任務。

2）RADIO數據接收任務。

3）RADIO外設正在使用。

4）RF4CE網絡忙。（一種Zigbee遙控標準協議）

 

若是有以上任務正在執行，則系統仍是不能休眠。

 

4.若是沒有stack高優先級任務在執行，系統就能夠安心休眠，首先，須要計算休眠的時間，休眠時間指從如今開始到執行下一個事件發生的時間，以[1/1024]秒爲單位，若是計算出來能夠休眠的時間小於5ms（系統默認，可修改），那也不能夠進入Deepsleep狀態，由於進入Deepsleep須要關外設、關協議棧，喚醒後須要開外設、開協議棧，這些動做完成也須要幾毫秒的時間，功耗覈算下來進入Deepsleep沒有任何意義。這種狀況下系統會默認進入個EM1 IDLE狀態就能夠了。若是休眠時間大於5ms，那系統就着手進入deepsleep。再次喚醒時，會給出已經睡眠了多久，用以作調試使用。

注意一點是，不管系統進入IDLE或Deepsleep狀態，都會在睡眠以前把中斷所有再從新打開，用做喚醒源，但操做是封裝在睡眠函數中未開源，咱們不要再去手動添加。

接下來，若是咱們想要使用EM4--系統最低功耗的模式，那咱們須要再進行一點複雜的處理。

 

首先，EM4喚醒就會復位，所以，在進入EM4以前，要保存Parent Info，也就是父節點的IEEE地址和NodeID，這個不要咱們去作，系統會自動添加，在斷定是否進入EM4時，默認會進行bool emberParentTokenSet(void)判斷是否該操做已經完成，若是未完成則不能進入EM4。同時，須要用戶在bool emberAfOKToGoToEM4Callback（）函數中返回true，系統才能夠確認進入EM4，在進入EM4以前，系統會使用RTCC保存16字節的與當前網絡通訊加密有關的數據，包括髮送數據的FrameCounter、接收數據的FrameCounter、發送數據的LinkKeyFrameCounter、接收數據的LinkKeyFrameCounter，再次喚醒時會自動讀取。從EM4喚醒後，系統會獲取復位緣由，若是是EM4形成的，則會進入void emberAfCameBackFromEM4Callback()函數中，進行EM4的參數回讀工做。

可是，使用EM4仍是須要作不少工做，由於若是直接使用EM4，會形成周期性的任務事件沒有辦法執行，每次進入EM4會丟失以前的任務信息，好比Sleepy End Device的Short poll、Long Poll事件沒法正常執行。建議是在進入EM4以前就先作好此類工做，bool emberAfOKToGoToEM4Callback()是很是適合的接口。

 

EM4目前進入機制中協議棧有些地方須要修改，除在ISC文件中選擇EM4 plugin外。須要增長EMBER_AF_PLUGIN_EM四、EMBER_ENABLE_EM4定義，重複的定義問題能夠去掉$Prj_name.h中的相同定義。在micro.c文件line380 void setEm4WakeupTimer(uint32_t duration)中的  cryotimerInit.period = closestPowerOfTwo(duration)；計算週期不正確，請參考手冊配置。另外，在child.h文件line 334 

#define emberOkToGoToLowPowerMode() (！emberCurrentStackTasks() && emberParentTokenSet())

修改成

#define emberOkToGoToLowPowerMode() (！emberCurrentStackTasks() && ！emberParentTokenSet())