前言
無線通信技術(shù)相關(guān)應(yīng)用中,用戶體驗一直是用戶關(guān)系的重點。無線通訊距離近一點,通訊速度慢一點,這都不是致命的問題,在某些場合下是完全可以接受的,甚至?本身就是項目的技術(shù)需求;但是有一些設(shè)計缺陷卻會嚴重影響用戶體驗的,一旦大面積的出現(xiàn),基本上可以判定為產(chǎn)品失敗了;總結(jié)起來,大家都無法忍受的問題主要是下述兩個?:
(1)通訊失敗或者數(shù)據(jù)傳輸錯誤
(2)電池消耗快,很快沒電
01
業(yè)內(nèi)問題
在絕大部分用戶的心目中,無線通訊本身就不如有線通訊技術(shù)穩(wěn)定,如果一款產(chǎn)品還經(jīng)常傳輸失敗,試問用戶會對這款產(chǎn)品有信心嗎?
無線產(chǎn)品配合上電池供電,才能充分發(fā)揮無線技術(shù)可以隨意移動的優(yōu)勢,因此很多的無線產(chǎn)品經(jīng)常和低功耗或電池供電有非常緊密的聯(lián)系;一旦這個產(chǎn)品電池消耗很快,那么必然將是其便攜性,移動性大打折扣。
當(dāng)然,在理論設(shè)計上產(chǎn)品的電池壽命肯定是非常長的,但是真正實現(xiàn)起來卻比較困難,很多的產(chǎn)品設(shè)計電池壽命有 5 年之久,但是現(xiàn)場運行不到一年,甚至幾個月就完全沒電了,這種問題的發(fā)作經(jīng)常沒有任何規(guī)律,測試時間上又以年/月為單位,且呈現(xiàn)出偶發(fā)特性,定位起來極其困難,困擾了不少的無線通訊技術(shù)工程師,被認為是業(yè)界的重要難題之一。?
02
技術(shù)難點
其實電池快速耗電和通訊不穩(wěn)定說到底都是軟件設(shè)計,特別是軟件架構(gòu)方面的設(shè)計問題;軟件架構(gòu)上的不完整或混亂,導(dǎo)致射頻芯片的控制不準確甚至部分狀態(tài)失去控制才是問題的源頭。既然大家都認為功耗的管理是一個難題,那么到底難在哪些環(huán)節(jié)呢?
(1)?產(chǎn)品的低功耗休眠喚醒設(shè)計,存在系統(tǒng)業(yè)務(wù)和應(yīng)用層業(yè)務(wù)兩種:在系統(tǒng)層面講,主要有OTA無線升級、遠程診斷、遠程控制(無線I/O)等;在應(yīng)用層中則是回調(diào)機制、關(guān)閉端口上拉、檢測用戶按鍵、關(guān)閉工作指示燈等。系統(tǒng)層內(nèi)容屬于整個產(chǎn)品的軀干和骨架,通常需要交給經(jīng)驗豐富的工程師負責(zé),因為涉及精密的規(guī)則和龐大的算法問題,需要較為強大的抽象能力和全面的視角。而應(yīng)用層則是面向用戶的,體現(xiàn)在軟件部分則相對比較簡單。
(2)?系統(tǒng)存在多種喚醒源:如UART、GPIO、RTC、Timer等,這些喚醒源中斷方式和清除規(guī)則略有不同,但是進入和退出休眠需要遵循相同的路徑,因此其控制邏輯需要做一定的抽象化設(shè)計,具有一定的挑戰(zhàn)。
(3)?基于RTC定時器的后臺背景活動:?某些延遲操作,比如開啟一個 LED 指示燈,十秒之后關(guān)閉,此時如果處理器全速運行就為了運行這一功能,是不太經(jīng)濟的;通常是設(shè)置一個狀態(tài)標志,然后啟動RTC定時器,并將處理器切入休眠狀態(tài),計時的時間到了之后會產(chǎn)生一個RTC中斷,處理器可以在這種中斷到達的時候關(guān)閉這個LED 指示燈。類似這些延遲操作,往往還會和其他的業(yè)務(wù)狀態(tài)交織在一起,控制邏輯需要精確設(shè)計,稍有不慎就會失去控制。
(4)?被未知的電磁波干擾,吵醒?,?誤喚醒等假喚醒行為:無線電波由于空間開放的特性,其喚醒動作往往伴隨著少量的模擬特性,偶爾會被一些未知的信號給誤觸發(fā),處理器被喚醒之后,?需要對喚醒后的實時參數(shù)做一些分析計算,對喚醒源進行甄別篩選,如果不是有效的喚醒,需要提前終止業(yè)務(wù)邏輯。
(5)?存在多種不同模式的睡眠深度的低功耗模式:處理器通常支持多種不同的睡眠?深度,?對應(yīng)不同的功耗等級。不同睡眠模式下,處理器可以激活的外設(shè)不一樣的,在喚醒之后,有些外設(shè)需要再次初始化之后才可以重新投入工作,只有深入了解處理器的工作特性,才能控制好處理器不同睡眠模式?的切換工作。
(6)?雙芯片模式(獨立的無線通訊模塊)模式和單芯片模式(協(xié)議棧和應(yīng)用層業(yè)務(wù)運行在一個芯片上),需要統(tǒng)一的編程接口。?如果維持兩套不同的編程接口,代碼分支龐大不說,還很容易產(chǎn)生歧義,為后續(xù)的產(chǎn)品維護和架構(gòu)升級帶來困難。
綜合以上難點,需要解決如此復(fù)雜的功耗控制要求,必須分而治之,采用分層的控制策略;行之有效的解決方案就是如下的內(nèi)-中-外,三級環(huán)形架構(gòu)。
03
三級環(huán)形架構(gòu)
上圖是一個電子價簽的主程序框架??梢钥闯鲈摮绦蛑饕譃槿齻€主線程,分別是協(xié)議棧的主線程;低功耗休眠與喚醒的主線程與墨水屏應(yīng)用業(yè)務(wù)的主線程。這三個主線程在同一個層級平行運行,具有相同的調(diào)度優(yōu)先級。
局放圖
我們將低功耗休眠與喚醒的主線程做局部放大,如上所示。
圖中的三級環(huán)架構(gòu)是休眠喚醒管理模塊的核心,是整個休眠喚醒功能的局部放大。如圖所示,由內(nèi)環(huán)、中環(huán)、外環(huán),三部分構(gòu)成。因為考慮到在無線通信中,各種事件的復(fù)雜程度及其處理方式,分為以上三環(huán)。最內(nèi)部一環(huán)主管電磁波喚醒,中層環(huán)主管GPIO喚醒、RTC喚醒、UART喚醒,最外層環(huán)則啟動了整個協(xié)議棧以及業(yè)務(wù)層,面向用戶進行交互。
三級環(huán)的目的突出的是分層做事原則。在內(nèi)環(huán)中只進行電磁波喚醒的工作,這里主要有三部分,查詢中斷、分析中斷狀態(tài)、無線電波處理。當(dāng)信號到達這一環(huán),會根據(jù)信號類型分析是否進行無線電波的喚醒處理。
如果不是無線電波喚醒,則跳出該層,進入中環(huán)處理。這里的信號類型分析和處理是根據(jù)不同事件、不同時刻產(chǎn)生的耦合性而定的。
在中環(huán),GPIO 喚醒是特定產(chǎn)品的喚醒模式;RTC 喚醒通常用于一些低優(yōu)先級的后臺任務(wù),比如檢測是否漏電或者執(zhí)行一些延遲 I/O 操作;UART???串口喚醒?則是針對用戶處理器。
外環(huán)則是面向用戶的層級,如需要啟動主程序固件升級或者業(yè)務(wù)邏輯,比如墨水屏的刷新屏幕顯示內(nèi)容等,則程序會被全面喚醒,此時就在外環(huán)中進行。
環(huán)形架構(gòu)的優(yōu)勢
由外環(huán)、中環(huán)到內(nèi)環(huán),視覺效果方面是越來越小的,越來越縮放的。自然在功能性方面也是越來越小,越來越簡潔的過程。三級環(huán)從外到內(nèi),能做的?“?事?”?就越來越少,體現(xiàn)在軟件代碼方面就是,代碼更少,功能性更加單一,邏輯更加清晰,運行更穩(wěn)定。從而更加節(jié)省功耗。
為什么功耗更加節(jié)約?將電磁波喚醒獨立拆分,做成了獨立的單元結(jié)構(gòu),是出于這樣的考慮的。當(dāng)信號指令到達三級環(huán),內(nèi)環(huán)首先進行判定,是否需要電磁波喚醒,判定是,就進行電磁波喚醒;判定不是,則跳入中環(huán)選擇喚醒類別,內(nèi)環(huán)進入休眠。
考慮到事件的復(fù)雜性、多樣性,需要從不同屬性、不同時間等多角度考量休眠喚醒的執(zhí)行,通俗點說就是“跟我相關(guān)起來干活,跟我無關(guān)繼續(xù)睡覺”,這樣的三級環(huán)設(shè)計針對性很強,在需要單一模式喚醒時,只需要調(diào)動少數(shù)軟件資源和內(nèi)部耗能就可以完成,完成相關(guān)作業(yè)后繼續(xù)休眠,等待下一輪指令喚醒。從而這樣的三級環(huán)設(shè)計是一款更加節(jié)約功耗的方案。
回調(diào)函數(shù)
//?*****************************************************************************
//?Design?Notes:
//?-----------------------------------------------------------------------------
char?OnHostWakeup_Request(?unsigned?char?iStatus,?char?iCause,?char?iReqAck?)
{
unsigned?char?iRetVal;
//?The?callback?status
switch?(?iStatus?)
{
case??WIMINET_SLEEP_CALL_INIT:
{
OnWakeupRequest_Init(?iCause,?iReqAck?);
}
break?;
case??WIMINET_SLEEP_CALL_OPEN:
{
OnWakeupRequest_Open(?iCause,?iReqAck?);
}
break?;
case??WIMINET_SLEEP_CALL_WORK:
{
OnWakeupRequest_Work(?iCause,?iReqAck?);
}
break?;
case??WIMINET_SLEEP_CALL_STOP:
{
OnWakeupRequest_Stop(?iCause,?iReqAck?);
}
break?;
default:
{
iRetVal?=?0X00;
}
break?;
}
//?The??return??status
return??iRetVal;
以上是一個 SoC 產(chǎn)品方案,回調(diào)函數(shù)的標準樣本,通常需要實現(xiàn)“系統(tǒng)剛剛喚醒”,“已經(jīng)完成初始化”,“執(zhí)行用戶任務(wù)”,“即將進入休眠”等幾個重要的通知時刻:
系統(tǒng)剛剛喚醒?:?系統(tǒng)運行在三級環(huán)的內(nèi)環(huán),處理器剛剛被中斷喚醒,需要啟用系統(tǒng)層級別的外設(shè),比如 SPI 總線等;
已經(jīng)完成初始化:?系統(tǒng)已經(jīng)切換至三級環(huán)的外環(huán),控制權(quán)準備釋放給用戶程序,通常在此時初始化用戶任務(wù);
執(zhí)行用戶任務(wù)?:?系統(tǒng)運行在三級環(huán)的外環(huán),此時協(xié)議棧程序也在同層級平行運作,用戶程序執(zhí)行完了之后,需要釋放控制權(quán)給系統(tǒng),通知系統(tǒng)進入睡眠模式
即將進入休眠?:?系統(tǒng)運行在三級環(huán)的中環(huán),所有的數(shù)據(jù)都已經(jīng)發(fā)送完畢或者超時終止,即將重新進入睡眠模式,通知用戶關(guān)閉外設(shè),執(zhí)行任務(wù)的清理或者重置工作。
對于不太復(fù)雜的系統(tǒng),通常僅僅需要實現(xiàn)上述四個通知的回調(diào)函數(shù)即可,其余的通知可以不做處理器;對于更加復(fù)雜的系統(tǒng),可以根據(jù)需要實現(xiàn)其他更多的回調(diào)通知。