對于開發人員來說，如果只是鉆研最新的微控制器(MCU)規格表，很容易就會認為有效地使用了CPU資源(包括內存和頻率周期)，這是目前在硬件設計上的一個小問題。最新的32位MCU可以為嵌入式系統提供閃存和RAM分配，這在不久前還是前所未聞的；而且其CPU通常還能與桌面計算機默認的運行速度一樣。
然而，近來開發過物聯網(IoT)產品的人都知道，這些硬件的進步并非空穴來風；它們一直在因應終端用戶的期望和設計要求而發生顯著的變化。因此，現在比以往任何時候都更重要的是：開發人員必須確保其軟件以最高效率執行，并且能有效地利用時間。
執行于現代嵌入式系統中的軟件往往出自各種來源。應用開發人員編寫的程序代碼通常結合了實時操作系統(RTOS)供貨商的現成軟件組件，而這些組件又可能利用最初由半導體公司提供的驅動程序碼。開發人員可以編寫每段程序代碼以優化效率，但本文更著重于現成軟件組件中的效率優化。特別是其中兩個組成部份將作為審視資源效率的基礎：實時核心和事務文件系統(transactional file system)。
實時核心：高效系統的核心
實時核心是執行于當今許多嵌入式系統中的軟件核心。簡言之，核心是一個排程器；為基于核心的系統編寫應用程序代碼的開發人員將程序代碼分為多個任務，而核心就負責安排這些任務。那么，核心是main()中無限循環的替代方法，它常常作為裸機(bare-metal)嵌入式系統中的主要調度機制。
使用實時核心提供了重要優點，包括提高效率。選擇將其應用程序代碼用于核心基礎的開發人員可以優化其系統中處理器資源的使用，同時更有效率地利用自己的時間。然而，并不是所有的核心都生而相同，因此，簡單地決定在新的項目中采用核心，并不一定能保證提高效率。
“排程”(scheduling)是可能有不同核心且CPU資源的使用效率差異大的關鍵領域。透過提供一種允許任務以響應事件的方式執行的智慧調度機制，讓核心有助于開發人員在無限循環中提升效率，并以固定順序執行任務(或函數)。基于核心的應用程序之確切效率部份取決于其排程器的實現方式。一個核心的排程器(只是一段負責決定每項任務何時執行的程序代碼)最終是一項開銷，但它必須不能蠶食掉透過擺脫裸機系統獲得的好處。
圖1：在μC/OS-II排程器中，每一項任務的優先級由數組中的位表示
通常，在實時核心中，排程任務是基于優先級的，這意味著應用程序開發人員為其任務分配優先級(通常以時間數字表示)，而且在進行排程決策時，核心即可支持更高優先級的任務執行。在這種機制下，核心必須保持某種類型的數據結構，即追蹤應用程序不同任務的優先級以及每項任務的當前狀態。例如Micrium的μC/OS-II核心，如圖1所示。
在OSRdyTbl[]中顯示8-元素數組(每元素8位)，每個位表示不同的任務優先級；其中：第一個元素的最低有效位對應最高優先級；最后一個元素的最高有效位表示最低優先級。數組中的位值反映任務狀態：如果相關優先級的任務準備就緒，則用1表示；若任務尚未準備就緒，就用0表示。
附帶的OSRdyTbl[]是μC/OS-II排程器的一部份，即圖中所示的單個八位變量——OSRdyGrp。該變量中的每個位表示數組中的一整行或元素：1位表示對應的行至少有一個任務就緒；0位表示該行尚無就緒的任務。透過使用列表1中所示的程序代碼先掃描OSRdyGrp、再掃描OSRdyTbl[]，μ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)中。這些位置的計數在編譯時確定，但大小無需預先確定。一個「檔案」可能包含較其它檔案更多的數據，并且僅在「檔案」的總容量達到閾值時，儲存媒體才算滿載。還可自由地對檔案進行截取、讀取和寫入。
圖2：FAT文件系統與Reliance Edge
相形之下，FAT格式的文件系統具有專用于兩種文件分配表的媒體建構模塊。針對每個用戶數據文件，為其分配檔名和元數據——前者可能相當大以支持較長的檔名。如果使用子文件夾，其元數據和長文件名也將會占用空間。所有的結果都會導致儲存媒體上用于收集用戶數據的可用空間變少。
對于較大的設計，Reliance Edge提供了更像是POSIX的環境。這里的文件名、文件夾和文件系統元數據(如屬性以及數據和時間)是一種可配置的選項。對于期望從其它設計移植POSIX界面的應用來說，這可能是非常好的選擇。最終，文件系統要求的最終選擇與用例直接相關，成為最有效率的資源方案。
全面考慮效率
除了資源使用問題之外，多年來，在購買核心、文件系統和其他軟件模塊時，效率一直是開發人員關注的頭等大事。這是因為用于證明采用這種模塊的理由通常是：從頭開始編寫等效的程序代碼相當浪費時間。換句話說，應用開發人員最有效的時間利用是編寫應用程序，而不是埋首于數萬行的基礎架構程序代碼。
然而，正如核心和文件系統的使用本身并不能保證CPU資源的有效應用一樣，將這些模塊導入新項目的決定，也不會自動確保開發人員能最有效地利用時間。為了讓開發人員真正專注于應用級程序代碼，嵌入式軟件模塊必須具有直觀的接口，該接口還必須有詳盡的文檔介紹。在缺乏有效文檔的情況下，開發人員可能要花數周的時間解決事后證明是函數誤用導致的問題。
遺憾的是，如果無法可靠地實現所描述的功能，即使是文文件編寫良好的程序代碼也會不必要地浪費開發時間。這就是為什么除了要求完整的文檔外，開發人員在為新項目選擇軟件時，應尋求可靠性證據——例如過去的認證或測試結果。實際上，每個軟件模塊在宣傳文獻中聽起來都很可靠，但只有一部份模塊提供了可靠證明能確保其「言行一致」。例如，Datalight的Reliance Edge就提供了各種不同測試的源代碼，讓應用開發人員確認文件系統在特定開發環境中能否可靠執行。
以最佳效率開發物聯網醫療裝置
什么類型的開發環境可能出現在物聯網項目中？有鑒于嵌入式裝置對于連接性的要求迅速增加，不可能確定一種硬件、軟件和工具鏈的特定組合來界定這個范圍。要找到一種能完全代表物聯網可能范圍的終端產品同樣具有挑戰性。盡管如此，這一領域的討論當然可以從具體的例子中受益。
為了說明物聯網開發人員面臨的挑戰，本文以一款在幾年前還未被視為連網裝置的血糖儀為例。這種產品的關鍵特征之一是市場容量：血糖儀每年的產量有數百萬，并且往往以低于成本的價格出售，甚至免費贈送。因此，降低BOM成本，并以最少時間開發這些儀器的壓力很大。不過，開發這些設備并不容易。事實上，新的血糖儀功能增加了彩色顯示、數據記錄功能和云端連接。
面對如此復雜的需求，負責血糖儀開發的團隊當然希望利用核心的多任務處理功能。優化核心的內存占用空間可能是開發團隊的首要關注之一，因為典型的高產量、低成本MCU往往只有有限的閃存和RAM資源。減少空間占用的關鍵步驟是刪除應用程序代碼不需要的核心資源(如TCB)。消除應用中各種核心管理任務所需的堆棧耗費也將會有幫助。
例如像Micrium μC/Probe這樣的工具，可用于實現這一目標，如圖2所示。μC/Probe可以深入了解基于核心的應用的堆棧使用情況，讓開發人員輕松地辨識低效情況，以及提高效率。
圖3：μC/Probe提供對于系統數據的運行時間存取，包括核心統計信息
當實施血糖儀的數據記錄功能時，儀器的開發團隊將可從文件系統的功能中受益。在此，與核心一樣，使用現成的軟件模塊可以減輕開發基礎架構程序代碼的負擔，從而有助于實現時間更短、更具成本效益的開發周期。處理器資源的使用一直是系統的整體限制之一，在開發數據記錄程序代碼時不可避免地必須予以考慮，因此使用高效的事務文件系統較為理想。藉由Reliance Edge等文件系統方案，開發團隊可以輕松地將服務縮減到最低限度，以便盡量為應用程序留出最多的儲存空間。
結論
雖然每個嵌入式系統都有其獨特的需求，但適于為血糖儀實現最高效率的方法也可以輕松地用于開發其它裝置類型。重復利用組件早已被公認為軟件開發的最佳實踐，而血糖儀所需的許多基礎架構程序代碼(包括實時核心和文件系統)可以作為其它裝置開發的基礎，除了替換少數底層程序代碼外，僅需很少改動。
透過選擇具有質量保證的現成組件作為項目的基礎，開發團隊可以確保自己的資源以及嵌入式硬件的有效利用，并且可以專注于編寫創新的應用程序代碼，使其設計在眾多的產品中脫穎而出。物聯網創新的曙光已經開始閃爍。
京公網安備 11010502049343號