對於開發人員來說,如果只是鑽研最新的微控制器(MCU)規格表,很容易就會認為有效地使用了CPU資源(包括記憶體和時脈週期),這是目前在硬體設計上的一個小問題。最新的32位元MCU可以為嵌入式系統提供快閃記憶體和RAM分配,這在不久前還是前所未聞的;而且其CPU通常還能與桌上型電腦預設的運行速度一樣。

然而,近來開發過物聯網(IoT)產品的人都知道,這些硬體的進步並非空穴來風;它們一直在因應終端用戶的期望和設計要求而發生顯著的變化。因此,現在比以往任何時候都更重要的是:開發人員必須確保其軟體以最高效率執行,並且能有效地利用時間。

執行於現代嵌入式系統中的軟體往往出自各種來源。應用開發人員編寫的程式碼通常結合了即時作業系統(RTOS)供應商的現成軟體元件,而這些元件又可能利用最初由半導體公司提供的驅動程式碼。開發人員可以編寫每段程式碼以最佳化效率,但本文更著重於現成軟體元件中的效率最佳化。特別是其中兩個組成部份將作為審視資源效率的基礎:即時核心和事務檔案系統(transactional file system)。

即時核心:高效系統的核心

即時核心是執行於當今許多嵌入式系統中的軟體核心。簡言之,核心是一個排程器;為基於核心的系統編寫應用程式碼的開發人員將程式碼分為多個任務,而核心就負責安排這些任務。那麼,核心是main()中無限循環的替代方法,它常常作為裸機(bare-metal)嵌入式系統中的主要調度機制。

使用即時核心提供了重要優點,包括提高效率。選擇將其應用程式碼用於核心基礎的開發人員可以最佳化其系統中處理器資源的使用,同時更有效率地利用自己的時間。然而,並不是所有的核心都生而相同,因此,簡單地決定在新的專案中採用核心,並不一定能保證提高效率。

「排程」(scheduling)是可能有不同核心且CPU資源的使用效率差異大的關鍵領域。透過提供一種允許任務以回應事件的方式執行的智慧調度機制,讓核心有助於開發人員在無限循環中提升效率,並以固定順序執行任務(或函數)。基於核心的應用程式之確切效率部份取決於其排程器的實現方式。一個核心的排程器(只是一段負責決定每項任務何時執行的程式碼)最終是一項開銷,但它必須不能蠶食掉透過擺脫裸機系統獲得的好處。

20170814_IoT_TA31P1 圖1:在μC/OS-II排程器中,每一項任務的優先順序由陣列中的位元表示 (來源:Micrium)

通常,在即時核心中,排程任務是基於優先順序的,這意味著應用程式開發人員為其任務分配優先順序(通常以時間數字表示),而且在進行排程決策時,核心即可支援更高優先順序的任務執行。在這種機制下,核心必須保持某種類型的資料結構,即追蹤應用程式不同任務的優先順序以及每項任務的當前狀態。例如Micrium的μC/OS-II核心,如圖1所示。

在OSRdyTbl[]中顯示8-元素陣列(每元素8位元),每個位元表示不同的任務優先級;其中:第一個元素的最低有效位元對應最高優先順序;最後一個元素的最高有效位元表示最低優先順序。陣列中的位元值反映任務狀態:如果相關優先順序的任務準備就緒,則用1表示;若任務尚未準備就緒,就用0表示。

附帶的OSRdyTbl[]是μC/OS-II排程器的一部份,即圖中所示的單個八位元變數——OSRdyGrp。該變數中的每個位元表示陣列中的一整行或元素:1位元表示對應的行至少有一個任務就緒;0位元表示該行尚無就緒的任務。透過使用清單1中所示的程式碼先掃描OSRdyGrp、再掃描OSRdyTbl[],μC/OS-II即可確定在特定時間中準備好執行的最高優先任務。如列表所示,如此的作業方式十分高效率,只需要兩行C程式碼。

y   =OSUnMapTbl[OSRdyGrp]; OSPrioHighRdy=(INT8U)((y<< 3u)+OSUnMapTbl[OSRdyTbl[y]]);

列表1:只需使用μC/OS-II的兩行C程式碼即可完成排程

當然,緊湊、高效率的程式碼只是開發人員在核心中尋求的特性之一。有鑒於大多數新款MCU提供的快閃記憶體相對多於RAM,對於開發人員來說,考慮核心所佔用空間的資料端也很重要。對於核心的排程器來說,龐大的RAM佔用空間導致過多的開銷,從而減少了多工應用程式碼通常具有的好處。

核心可以採用兩種方法來分配多工處理所需的基本資源:分配這些資源的責任可以留給應用程式碼,或是本身可以處理分配的核心。在任何核心中必然存在某些變數和資料結構,因為它們對於執行多工服務至關重要,所以這些變數和資料結構完全存放在核心中。然而,對用於記錄每個任務狀態的任務控制區塊(TCB)等資料結構,或甚至在情境切換期間儲存CPU暫存器值的堆疊,核心供應商可以選擇在內部進行分配或交給應用程式碼來實現。

無論是哪一種方法,只要在建置時以靈活性為目標之一,即可產生一個高效核心。延遲將資源配置給應用程式碼也是為開發人員提供最大靈活性的方法之一,因為它提供了選擇靜態或動態分配機制的空間。Micrium的μC/OS-III即採用這種方法,讓應用開發人員決定如何最有效地分配其TCB和堆疊。然而,如同在μC/OS-II的TCB情況一樣,強制在核心中實施資源配置是同樣有效的方法,只要能配置分配資源量的方法即可。最終,應用開發人員需要一種從系統的記憶體空間中消除未使用資源的方法。

檔案系統效率

大多數的裝置都需要儲存資料和記錄事件的選項,作為在傳送到雲端之前的臨時保存空間、或者是更長久地儲存在裝置上。為此目的設計的任何程式碼就是檔案系統,無論是由開發人員編寫和測試的,還是以RTOS解決方案的一部份提供。檔案系統還可以提供效率選項,其範圍從簡單(保留多少記憶體緩衝)到複雜(是否支援完整的POSIX作業)。

開發人員應該從對於儲存資料的要求開始。資料是否能在現場進行操作?或只是暫存並在稍後傳送?要測量多少內容?資料應該分開或合併儲存?資料暫時儲存至裝置進行收集之後?還是要傳送到雲端?儲存媒體有多可靠?設計能完全免受於電源故障的影響嗎?

首先,有些RTOS提供類似FAT的檔案系統。這包括使用標準媒體格式(包括資料夾和檔案)執行I/O的程式碼。一般來說,其可客製程度有限,很少能防範電源故障時的資料遺失。另一個選擇是Datalight的Reliance Edge,它採用交易點提供電源故障安全環境,其令人振奮之處在於設計的靈活性如何有助於提高效率。

Reliance Edge提供儲存選項的客製化。在最小化的用例中,它稱為「檔案系統要素」,不必使用資料夾或甚至檔名。資料儲存於編號的索引節點(inode)中。這些位置的計數在編譯時確定,但大小無需預先確定。一個「檔案」可能包含較其它檔案更多的資料,並且僅在「檔案」的總容量達到閾值時,儲存媒體才算滿載。還可自由地對檔案進行截取、讀取和寫入。

20170814_IoT_TA31P2 圖2:FAT檔案系統與Reliance Edge (來源:Datalight)

相形之下,FAT格式的檔案系統具有專用於兩種檔案配置表的媒體建構模組。針對每個用戶資料檔案,為其分配檔名和中繼資料——前者可能相當大以支援較長的檔名。如果使用子資料夾,其中繼資料和長檔名也將會佔用空間。所有的結果都會導致儲存媒體上用於收集使用者資料的可用空間變少。

對於較大的設計,Reliance Edge提供了更像是POSIX的環境。這裡的檔案名稱、資料夾和檔案系統中繼資料(如屬性以及資料和時間)是一種可配置的選項。對於期望從其它設計移植POSIX介面的應用來說,這可能是非常好的選擇。最終,檔案系統要求的最終選擇與用例直接相關,成為最有效率的資源方案。

全面考量效率

除了資源使用問題之外,多年來,在購買核心、檔案系統和其他軟體模組時,效率一直是開發人員關注的頭等大事。這是因為用於證明採用這種模組的理由通常是:從頭開始編寫等效的程式碼相當浪費時間。換句話說,應用開發人員最有效的時間利用是編寫應用程式,而不是埋首於數萬行的基礎架構程式碼。

然而,正如核心和檔案系統的使用本身並不能保證CPU資源的有效應用一樣,將這些模組導入新專案的決定,也不會自動確保開發人員能最有效地利用時間。為了讓開發人員真正專注於應用級程式碼,嵌入式軟體模組必須具有直觀的介面,該介面還必須有詳盡的文檔介紹。在缺乏有效文檔的情況下,開發人員可能要花數週的時間解決事後證明是函數誤用導致的問題。

遺憾的是,如果無法可靠地實現所描述的功能,即使是文檔編寫良好的程式碼也會不必要地浪費開發時間。這就是為什麼除了要求完整的文檔外,開發人員在為新專案選擇軟體時,應尋求可靠性證據——例如過去的認證或測試結果。實際上,每個軟體模組在宣傳文獻中聽起來都很可靠,但只有一部份模組提供了可靠證明能確保其「言行一致」。例如,Datalight的Reliance Edge就提供了各種不同測試的原始程式碼,讓應用開發人員確認檔案系統在特定開發環境中能否可靠執行。

以最佳效率開發IoT醫療裝置

什麼類型的開發環境可能出現在物聯網專案中?有鑒於嵌入式裝置對於連接性的要求迅速增加,不可能確定一種硬體、軟體和工具鏈的特定組合來界定這個範圍。要找到一種能完全代表物聯網可能範圍的終端產品同樣具有挑戰性。儘管如此,這一領域的討論當然可以從具體的例子中受益。

為了說明物聯網開發人員面臨的挑戰,本文以一款在幾年前還未被視為連網裝置的血糖儀為例。這種產品的關鍵特徵之一是市場容量:血糖儀每年的產量有數百萬,並且往往以低於成本的價格出售,甚至免費贈送。因此,降低BOM成本,並以最少時間開發這些儀器的壓力很大。不過,開發這些設備並不容易。事實上,新的血糖儀功能增加了彩色顯示、資料記錄功能和雲端連接。

面對如此複雜的需求,負責血糖儀開發的團隊當然希望利用核心的多工處理功能。最佳化核心的記憶體佔用空間可能是開發團隊的首要關注之一,因為典型的高產量、低成本MCU往往只有有限的快閃記憶體和RAM資源。減少空間佔用的關鍵步驟是刪除應用程式碼不需要的核心資源(如TCB)。消除應用中各種核心管理任務所需的堆疊耗費也將會有幫助。

例如像Micrium μC/Probe這樣的工具,可用於實現這一目標,如圖2所示。μC/Probe可以深入瞭解基於核心的應用的堆疊使用情況,讓開發人員輕鬆地辨識低效情況,以及提高效率。

20170814_IoT_TA31P4 圖3:μC/Probe提供對於系統資料的執行時間存取,包括核心統計資訊 (來源:Micrium)

當實施血糖儀的資料記錄功能時,儀器的開發團隊將可從檔案系統的功能中受益。在此,與核心一樣,使用現成的軟體模組可以減輕開發基礎架構程式碼的負擔,從而有助於實現時間更短、更具成本效益的開發週期。處理器資源的使用一直是系統的整體限制之一,在開發資料記錄程式碼時不可避免地必須予以考慮,因此使用高效的事務檔案系統較為理想。藉由Reliance Edge等檔案系統方案,開發團隊可以輕鬆地將服務縮減到最低限度,以便儘量為應用程式留出最多的儲存空間。

結論

雖然每個嵌入式系統都有其獨特的需求,但適於為血糖儀實現最高效率的方法也可以輕鬆地用於開發其它裝置類型。重覆利用元件早已被公認為軟體開發的最佳實踐,而血糖儀所需的許多基礎架構程式碼(包括即時核心和檔案系統)可以作為其它裝置開發的基礎,除了替換少數底層程式碼外,僅需很少改動。

透過選擇具有品質保證的現成元件作為專案的基礎,開發團隊可以確保自己的資源以及嵌入式硬體的有效利用,並且可以專注於編寫創新的應用程式碼,使其設計在眾多的產品中脫穎而出。物聯網創新的曙光已經開始閃爍。