近來(lái)開發(fā)過物聯(lián)網(wǎng)(IoT)產(chǎn)品的人都知道，這些硬件的進(jìn)步并非空穴來(lái)風(fēng)；它們一直在因應(yīng)終端用戶的期望和設(shè)計(jì)要求而發(fā)生顯著的變化。因此，現(xiàn)在比以往任何時(shí)候都更重要的是：開發(fā)人員必須確保其軟件以最高效率執(zhí)行，并且能有效地利用時(shí)間。

執(zhí)行于現(xiàn)代嵌入式系統(tǒng)中的軟件往往出自各種來(lái)源。應(yīng)用開發(fā)人員編寫的程序代碼通常結(jié)合RTOS供貨商的現(xiàn)成軟件組件，而這些組件又可能利用最初由半導(dǎo)體公司提供的驅(qū)動(dòng)程序碼。開發(fā)人員可以編寫每段程序代碼以優(yōu)化效率，但本文更著重于現(xiàn)成軟件組件中的效率優(yōu)化。

對(duì)于開發(fā)人員來(lái)說，如果只是鉆研最新的微控制器(MCU)規(guī)格表，很容易就會(huì)認(rèn)為有效地使用了CPU資源(包括內(nèi)存和頻率周期)，這是目前在硬件設(shè)計(jì)上的一個(gè)小問題。最新的32位MCU可以為嵌入式系統(tǒng)提供閃存和RAM分配，這在不久前還是前所未聞的；而且其CPU通常還能與桌面計(jì)算機(jī)默認(rèn)的運(yùn)行速度一樣。

然而，近來(lái)開發(fā)過物聯(lián)網(wǎng)(IoT)產(chǎn)品的人都知道，這些硬件的進(jìn)步并非空穴來(lái)風(fēng)；它們一直在因應(yīng)終端用戶的期望和設(shè)計(jì)要求而發(fā)生顯著的變化。因此，現(xiàn)在比以往任何時(shí)候都更重要的是：開發(fā)人員必須確保其軟件以最高效率執(zhí)行，并且能有效地利用時(shí)間。

執(zhí)行于現(xiàn)代嵌入式系統(tǒng)中的軟件往往出自各種來(lái)源。應(yīng)用開發(fā)人員編寫的程序代碼通常結(jié)合了實(shí)時(shí)操作系統(tǒng)(RTOS)供貨商的現(xiàn)成軟件組件，而這些組件又可能利用最初由半導(dǎo)體公司提供的驅(qū)動(dòng)程序碼。開發(fā)人員可以編寫每段程序代碼以優(yōu)化效率，但本文更著重于現(xiàn)成軟件組件中的效率優(yōu)化。特別是其中兩個(gè)組成部份將作為審視資源效率的基礎(chǔ)：實(shí)時(shí)核心和事務(wù)文件系統(tǒng)(transactional file system)。

實(shí)時(shí)核心：高效系統(tǒng)的核心

實(shí)時(shí)核心是執(zhí)行于當(dāng)今許多嵌入式系統(tǒng)中的軟件核心。簡(jiǎn)言之，核心是一個(gè)排程器；為基于核心的系統(tǒng)編寫應(yīng)用程序代碼的開發(fā)人員將程序代碼分為多個(gè)任務(wù)，而核心就負(fù)責(zé)安排這些任務(wù)。那么，核心是main()中無(wú)限循環(huán)的替代方法，它常常作為裸機(jī)(bare-metal)嵌入式系統(tǒng)中的主要調(diào)度機(jī)制。

使用實(shí)時(shí)核心提供了重要優(yōu)點(diǎn)，包括提高效率。選擇將其應(yīng)用程序代碼用于核心基礎(chǔ)的開發(fā)人員可以優(yōu)化其系統(tǒng)中處理器資源的使用，同時(shí)更有效率地利用自己的時(shí)間。然而，并不是所有的核心都生而相同，因此，簡(jiǎn)單地決定在新的項(xiàng)目中采用核心，并不一定能保證提高效率。

“排程”(scheduling)是可能有不同核心且CPU資源的使用效率差異大的關(guān)鍵領(lǐng)域。透過提供一種允許任務(wù)以響應(yīng)事件的方式執(zhí)行的智慧調(diào)度機(jī)制，讓核心有助于開發(fā)人員在無(wú)限循環(huán)中提升效率，并以固定順序執(zhí)行任務(wù)(或函數(shù))?；诤诵牡膽?yīng)用程序之確切效率部份取決于其排程器的實(shí)現(xiàn)方式。一個(gè)核心的排程器(只是一段負(fù)責(zé)決定每項(xiàng)任務(wù)何時(shí)執(zhí)行的程序代碼)最終是一項(xiàng)開銷，但它必須不能蠶食掉透過擺脫裸機(jī)系統(tǒng)獲得的好處。

圖1：在μC/OS-II排程器中，每一項(xiàng)任務(wù)的優(yōu)先級(jí)由數(shù)組中的位表示

通常，在實(shí)時(shí)核心中，排程任務(wù)是基于優(yōu)先級(jí)的，這意味著應(yīng)用程序開發(fā)人員為其任務(wù)分配優(yōu)先級(jí)(通常以時(shí)間數(shù)字表示)，而且在進(jìn)行排程決策時(shí)，核心即可支持更高優(yōu)先級(jí)的任務(wù)執(zhí)行。在這種機(jī)制下，核心必須保持某種類型的數(shù)據(jù)結(jié)構(gòu)，即追蹤應(yīng)用程序不同任務(wù)的優(yōu)先級(jí)以及每項(xiàng)任務(wù)的當(dāng)前狀態(tài)。例如Micrium的μC/OS-II核心，如圖1所示。

在OSRdyTbl[]中顯示8-元素?cái)?shù)組(每元素8位)，每個(gè)位表示不同的任務(wù)優(yōu)先級(jí)；其中：第一個(gè)元素的最低有效位對(duì)應(yīng)最高優(yōu)先級(jí)；最后一個(gè)元素的最高有效位表示最低優(yōu)先級(jí)。數(shù)組中的位值反映任務(wù)狀態(tài)：如果相關(guān)優(yōu)先級(jí)的任務(wù)準(zhǔn)備就緒，則用1表示；若任務(wù)尚未準(zhǔn)備就緒，就用0表示。

附帶的OSRdyTbl[]是μC/OS-II排程器的一部份，即圖中所示的單個(gè)八位變量——OSRdyGrp。該變量中的每個(gè)位表示數(shù)組中的一整行或元素：1位表示對(duì)應(yīng)的行至少有一個(gè)任務(wù)就緒；0位表示該行尚無(wú)就緒的任務(wù)。透過使用列表1中所示的程序代碼先掃描OSRdyGrp、再掃描OSRdyTbl[]，μC/OS-II即可確定在特定時(shí)間中準(zhǔn)備好執(zhí)行的最高優(yōu)先任務(wù)。如列表所示，如此的作業(yè)方式十分高效率，只需要兩行C程序代碼。


當(dāng)然，緊湊、高效率的程序代碼只是開發(fā)人員在核心中尋求的特性之一。有鑒于大多數(shù)新款MCU提供的閃存相對(duì)多于RAM，對(duì)于開發(fā)人員來(lái)說，考慮核心所占用空間的資料端也很重要。對(duì)于核心的排程器來(lái)說，龐大的RAM占用空間導(dǎo)致過多的開銷，從而減少了多任務(wù)應(yīng)用程序代碼通常具有的好處。

核心可以采用兩種方法來(lái)分配多任務(wù)處理所需的基本資源：分配這些資源的責(zé)任可以留給應(yīng)用程序代碼，或是本身可以處理分配的核心。在任何核心中必然存在某些變量和數(shù)據(jù)結(jié)構(gòu)，因?yàn)樗鼈儗?duì)于執(zhí)行多任務(wù)服務(wù)至關(guān)重要，所以這些變量和數(shù)據(jù)結(jié)構(gòu)完全存放在核心中。然而，對(duì)用于記錄每個(gè)任務(wù)狀態(tài)的任務(wù)控制區(qū)塊(TCB)等數(shù)據(jù)結(jié)構(gòu)，或甚至在情境切換期間儲(chǔ)存CPU緩存器值的堆棧，核心供貨商可以選擇在內(nèi)部進(jìn)行分配或交給應(yīng)用程序代碼來(lái)實(shí)現(xiàn)。

無(wú)論是哪一種方法，只要在建置時(shí)以靈活性為目標(biāo)之一，即可產(chǎn)生一個(gè)高效核心。延遲將資源分配給應(yīng)用程序代碼也是為開發(fā)人員提供最大靈活性的方法之一，因?yàn)樗峁┝诉x擇靜態(tài)或動(dòng)態(tài)分配機(jī)制的空間。Micrium的μC/OS-III即采用這種方法，讓應(yīng)用開發(fā)人員決定如何最有效地分配其TCB和堆棧。然而，如同在μC/OS-II的TCB情況一樣，強(qiáng)制在核心中實(shí)施資源分配是同樣有效的方法，只要能配置分配資源量的方法即可。最終，應(yīng)用開發(fā)人員需要一種從系統(tǒng)的內(nèi)存空間中消除未使用資源的方法。

文件系統(tǒng)效率

大多數(shù)的裝置都需要儲(chǔ)存數(shù)據(jù)和記錄事件的選項(xiàng)，作為在傳送到云端之前的臨時(shí)保存空間、或者是更長(zhǎng)久地儲(chǔ)存在裝置上。為此目的設(shè)計(jì)的任何程序代碼就是文件系統(tǒng)，無(wú)論是由開發(fā)人員編寫和測(cè)試的，還是以RTOS解決方案的一部份提供。文件系統(tǒng)還可以提供效率選項(xiàng)，其范圍從簡(jiǎn)單(保留多少內(nèi)存緩沖)到復(fù)雜(是否支持完整的POSIX作業(yè))。

開發(fā)人員應(yīng)該從對(duì)于儲(chǔ)存數(shù)據(jù)的要求開始。數(shù)據(jù)是否能在現(xiàn)場(chǎng)進(jìn)行操作？或只是暫存并在稍后傳送？要測(cè)量多少內(nèi)容？數(shù)據(jù)應(yīng)該分開或合并儲(chǔ)存？數(shù)據(jù)暫時(shí)儲(chǔ)存至裝置進(jìn)行收集之后？還是要傳送到云端？?jī)?chǔ)存媒體有多可靠？設(shè)計(jì)能完全免受于電源故障的影響嗎？

首先，有些RTOS提供類似FAT的文件系統(tǒng)。這包括使用標(biāo)準(zhǔn)媒體格式(包括文件夾和檔案)執(zhí)行I/O的程序代碼。一般來(lái)說，其可訂制程度有限，很少能防范電源故障時(shí)的數(shù)據(jù)遺失。另一個(gè)選擇是Datalight的Reliance Edge，它采用交易點(diǎn)提供電源故障安全環(huán)境，其令人振奮之處在于設(shè)計(jì)的靈活性如何有助于提高效率。

Reliance Edge提供儲(chǔ)存選項(xiàng)的訂制化。在最小化的用例中，它稱為「文件系統(tǒng)要素」，不必使用文件夾或甚至檔名。數(shù)據(jù)儲(chǔ)存于編號(hào)的索引節(jié)點(diǎn)(inode)中。這些位置的計(jì)數(shù)在編譯時(shí)確定，但大小無(wú)需預(yù)先確定。一個(gè)「檔案」可能包含較其它檔案更多的數(shù)據(jù)，并且僅在「檔案」的總?cè)萘窟_(dá)到閾值時(shí)，儲(chǔ)存媒體才算滿載。還可自由地對(duì)檔案進(jìn)行截取、讀取和寫入。

圖2：FAT文件系統(tǒng)與Reliance Edge

相形之下，F(xiàn)AT格式的文件系統(tǒng)具有專用于兩種文件分配表的媒體建構(gòu)模塊。針對(duì)每個(gè)用戶數(shù)據(jù)文件，為其分配檔名和元數(shù)據(jù)——前者可能相當(dāng)大以支持較長(zhǎng)的檔名。如果使用子文件夾，其元數(shù)據(jù)和長(zhǎng)文件名也將會(huì)占用空間。所有的結(jié)果都會(huì)導(dǎo)致儲(chǔ)存媒體上用于收集用戶數(shù)據(jù)的可用空間變少。

對(duì)于較大的設(shè)計(jì)，Reliance Edge提供了更像是POSIX的環(huán)境。這里的文件名、文件夾和文件系統(tǒng)元數(shù)據(jù)(如屬性以及數(shù)據(jù)和時(shí)間)是一種可配置的選項(xiàng)。對(duì)于期望從其它設(shè)計(jì)移植POSIX界面的應(yīng)用來(lái)說，這可能是非常好的選擇。最終，文件系統(tǒng)要求的最終選擇與用例直接相關(guān)，成為最有效率的資源方案。

全面考慮效率

除了資源使用問題之外，多年來(lái)，在購(gòu)買核心、文件系統(tǒng)和其他軟件模塊時(shí)，效率一直是開發(fā)人員關(guān)注的頭等大事。這是因?yàn)橛糜谧C明采用這種模塊的理由通常是：從頭開始編寫等效的程序代碼相當(dāng)浪費(fèi)時(shí)間。換句話說，應(yīng)用開發(fā)人員最有效的時(shí)間利用是編寫應(yīng)用程序，而不是埋首于數(shù)萬(wàn)行的基礎(chǔ)架構(gòu)程序代碼。

然而，正如核心和文件系統(tǒng)的使用本身并不能保證CPU資源的有效應(yīng)用一樣，將這些模塊導(dǎo)入新項(xiàng)目的決定，也不會(huì)自動(dòng)確保開發(fā)人員能最有效地利用時(shí)間。為了讓開發(fā)人員真正專注于應(yīng)用級(jí)程序代碼，嵌入式軟件模塊必須具有直觀的接口，該接口還必須有詳盡的文檔介紹。在缺乏有效文檔的情況下，開發(fā)人員可能要花數(shù)周的時(shí)間解決事后證明是函數(shù)誤用導(dǎo)致的問題。

遺憾的是，如果無(wú)法可靠地實(shí)現(xiàn)所描述的功能，即使是文文件編寫良好的程序代碼也會(huì)不必要地浪費(fèi)開發(fā)時(shí)間。這就是為什么除了要求完整的文檔外，開發(fā)人員在為新項(xiàng)目選擇軟件時(shí)，應(yīng)尋求可靠性證據(jù)——例如過去的認(rèn)證或測(cè)試結(jié)果。實(shí)際上，每個(gè)軟件模塊在宣傳文獻(xiàn)中聽起來(lái)都很可靠，但只有一部份模塊提供了可靠證明能確保其「言行一致」。例如，Datalight的Reliance Edge就提供了各種不同測(cè)試的源代碼，讓應(yīng)用開發(fā)人員確認(rèn)文件系統(tǒng)在特定開發(fā)環(huán)境中能否可靠執(zhí)行。

以最佳效率開發(fā)物聯(lián)網(wǎng)醫(yī)療裝置

什么類型的開發(fā)環(huán)境可能出現(xiàn)在物聯(lián)網(wǎng)項(xiàng)目中？有鑒于嵌入式裝置對(duì)于連接性的要求迅速增加，不可能確定一種硬件、軟件和工具鏈的特定組合來(lái)界定這個(gè)范圍。要找到一種能完全代表物聯(lián)網(wǎng)可能范圍的終端產(chǎn)品同樣具有挑戰(zhàn)性。盡管如此，這一領(lǐng)域的討論當(dāng)然可以從具體的例子中受益。

為了說明物聯(lián)網(wǎng)開發(fā)人員面臨的挑戰(zhàn)，本文以一款在幾年前還未被視為連網(wǎng)裝置的血糖儀為例。這種產(chǎn)品的關(guān)鍵特征之一是市場(chǎng)容量：血糖儀每年的產(chǎn)量有數(shù)百萬(wàn)，并且往往以低于成本的價(jià)格出售，甚至免費(fèi)贈(zèng)送。因此，降低BOM成本，并以最少時(shí)間開發(fā)這些儀器的壓力很大。不過，開發(fā)這些設(shè)備并不容易。事實(shí)上，新的血糖儀功能增加了彩色顯示、數(shù)據(jù)記錄功能和云端連接。

面對(duì)如此復(fù)雜的需求，負(fù)責(zé)血糖儀開發(fā)的團(tuán)隊(duì)當(dāng)然希望利用核心的多任務(wù)處理功能。優(yōu)化核心的內(nèi)存占用空間可能是開發(fā)團(tuán)隊(duì)的首要關(guān)注之一，因?yàn)榈湫偷母弋a(chǎn)量、低成本MCU往往只有有限的閃存和RAM資源。減少空間占用的關(guān)鍵步驟是刪除應(yīng)用程序代碼不需要的核心資源(如TCB)。消除應(yīng)用中各種核心管理任務(wù)所需的堆棧耗費(fèi)也將會(huì)有幫助。

例如像Micrium μC/Probe這樣的工具，可用于實(shí)現(xiàn)這一目標(biāo)，如圖2所示。μC/Probe可以深入了解基于核心的應(yīng)用的堆棧使用情況，讓開發(fā)人員輕松地辨識(shí)低效情況，以及提高效率。

圖3：μC/Probe提供對(duì)于系統(tǒng)數(shù)據(jù)的運(yùn)行時(shí)間存取，包括核心統(tǒng)計(jì)信息

當(dāng)實(shí)施血糖儀的數(shù)據(jù)記錄功能時(shí)，儀器的開發(fā)團(tuán)隊(duì)將可從文件系統(tǒng)的功能中受益。在此，與核心一樣，使用現(xiàn)成的軟件模塊可以減輕開發(fā)基礎(chǔ)架構(gòu)程序代碼的負(fù)擔(dān)，從而有助于實(shí)現(xiàn)時(shí)間更短、更具成本效益的開發(fā)周期。處理器資源的使用一直是系統(tǒng)的整體限制之一，在開發(fā)數(shù)據(jù)記錄程序代碼時(shí)不可避免地必須予以考慮，因此使用高效的事務(wù)文件系統(tǒng)較為理想。藉由Reliance Edge等文件系統(tǒng)方案，開發(fā)團(tuán)隊(duì)可以輕松地將服務(wù)縮減到最低限度，以便盡量為應(yīng)用程序留出最多的儲(chǔ)存空間。

結(jié)論

雖然每個(gè)嵌入式系統(tǒng)都有其獨(dú)特的需求，但適于為血糖儀實(shí)現(xiàn)最高效率的方法也可以輕松地用于開發(fā)其它裝置類型。重復(fù)利用組件早已被公認(rèn)為軟件開發(fā)的最佳實(shí)踐，而血糖儀所需的許多基礎(chǔ)架構(gòu)程序代碼(包括實(shí)時(shí)核心和文件系統(tǒng))可以作為其它裝置開發(fā)的基礎(chǔ)，除了替換少數(shù)底層程序代碼外，僅需很少改動(dòng)。

透過選擇具有質(zhì)量保證的現(xiàn)成組件作為項(xiàng)目的基礎(chǔ)，開發(fā)團(tuán)隊(duì)可以確保自己的資源以及嵌入式硬件的有效利用，并且可以專注于編寫創(chuàng)新的應(yīng)用程序代碼，使其設(shè)計(jì)在眾多的產(chǎn)品中脫穎而出。物聯(lián)網(wǎng)創(chuàng)新的曙光已經(jīng)開始閃爍。