探索嵌入式應用框架（EAF）

EAF是Embedded Application Framework 的縮寫，即嵌入式應用框架。嵌入式應用框架是 Application framework的一種， 是在嵌入式領域的應用框架。

Application Framework——應用框架，是一種軟體框架，軟體開發人員用應用框架作為標準結構，以便實現應用軟體。

那什麼是軟體框架呢？

關於軟體框架

軟體框架是一個抽象的概念, 是提供了通用的軟體功能，可以通過使用者編寫程式碼有選擇地改變, 從而提供特定的軟體應用。 軟體框架提供了構建和部署應用程式的標準方式。 軟體框架是一個通用的、可重用的軟體環境, 它提供特定的功能, 作為大型軟體平臺的一部分, 以促進軟體應用程式、產品和解決方案的開發。 軟體框架可能包括輔助程式、編譯器、程式碼庫、工具集和API , 彙集了所有不同的元件, 便於一個專案或系統的開發。

那些我們用過或者常見的軟體框架太多了：

• windows上MFC

• .net Framework

• spring framework以及衍生的SSH等等

• Entity Framework

• Robot Framework

• play framework

• Zend framework

• Oracle Application Development Framework

• Cactus Framework 

• Eclipse XXX framework

• AWS Lambda Framework

• FrondEnd framework：Vue.js,Angular.js,React等等

• ……

尤其是Web 應用框架更加豐富多彩，基於各自語言實現的Web Application Framework 不勝列舉。

進一步， 很多的系統架構也引入Framework 的概念，例如，Enterprise architecture framework等等，甚至在研發管理上也同樣湧現了Framework，例如 Project Management Framework，Risk Management Framework等，外延在不斷在融合放大。

關於軟體應用框架的開發著述也有很多，例如側重API設計的《軟體框架設計的藝術》等等。

嵌入式系統的應用框架

與一般的電腦相比, 嵌入式裝置有著自己的特性, 例如耗電量低、體積小、操作範圍粗糙、單位成本低。 這是以有限的加工資源為代價的, 這使得程式和互動的難度大大增加。 然而, 通過在硬體之上建立智慧機制, 利用可能存在的感測器和存在一個嵌入式單元網路, 既可以在單位和網路一級對現有資源進行最佳管理, 並提供遠遠超出現有可用功能的增強功能。 這或許就是嵌入式應用的必然性。

EAF 是面向嵌入式系統的軟體應用框架。嵌入式系統是一個在較大的機械或電氣系統中具有專用功能的計算機系統, 通常具有實時計算約束。嵌入式系統從行動式裝置, 如數字手錶和 MP3播放器, 到大型的固定裝置, 如交通燈, 工廠控制器, 以及大部分複雜的系統, 如混合動力車、核磁共振成像和航空電子裝置等等。 複雜性從低到單一的微控制器晶片, 到非常高的多個單位等等。

鑑於如此的複雜，很難有一個統一的應用開發框架。

但是，參考Java 面向資源的分類（J2EE，J2SE，J2ME，Java Card等），我們可以對嵌入式系統的應用框架進行嘗試分析。

手機上的應用框架

由於手機的功能越來越強大，很多時候被認為超出了嵌入式系統的範疇。但是，瞭解手機上的應用框架，對於EAF而言，還是大有裨益的。

手機上的應用開發框架一般也被稱為 Mobile Development Framework。近些年，隨著智慧手機的普及，面向手機開發的應用框架已被人們所熟知，例如 ios development framework，Android development framework，還有基於HTML5的混合程式設計框架PhoneGap等等。

尤其是Android，如果資源允許，基於android的嵌入式裝置可以輕鬆使用android的軟體應用框架。google 還面向嵌入式裝置推出了android wearable 等一系列方案，當然iOS 也是如此。

下圖就是那張經典的android 架構層次圖：

Android應用程式框架分為應用層、應用框架層、系統執行庫層和Linux核心層，在開發應用時就是在這個框架上進行擴充套件。Android應用框架的部分功能如下：

• android.app：提供高層的程式模型和基本的執行環境。

• android.content：包含對各種裝置上的資料進行訪問和釋出。

• android.database：通過內容提供者瀏覽和運算元據庫。

• android.graphics：底層的圖形庫,包含畫布,顏色過濾,點,矩形，可以直接繪製螢幕上。

• android.location：定位和相關服務的類。

• android.media：提供一些類管理多種音訊、視訊的媒體介面。

• android.net：提供幫助網路訪問的類，超過通常的java.net.*介面。

• android.os：提供了系統服務、訊息傳輸和IPC機制。

• android.opengl：提供OpenGL的工具。

• android.provider：提供訪問Android內容提供者的類。

• android.telephony：提供與撥打電話相關的API互動。

• android.view：提供基礎的使用者介面介面框架。

• android.util：涉及工具性的方法，例如時間日期的操作。

• android.webkit：預設瀏覽器操作介面。

• android.widget：包含各種UI元素（大部分是可見的）在應用程式的佈局中。

智慧手機的資源還是相當豐富的，在智慧手機之前的Feature Phone 同樣有著自己的應用開發框架，只是不如Android 和iOS 那麼普及，已經逐漸被人們所遺忘。 但是，這些應用框架的設計思想和實現方式同樣有著重要的參考性。例如，Qualcomm的BREW（翻開了歷史的回憶）。

BREW 指Binary Runtime Environment for Wireless 的縮寫，從基本的層面而言，BREW 平臺就是手持裝置上嵌入式晶片作業系統的介面或抽象層。

• BINARY 是指二進位制。BREW的程式設計介面是一套二進位制的函式庫。所有基於BREW的應用和擴充套件類被編譯和聯接成二進位制程式碼，在本地執行。

• RUNTIME是指執行時間。所有基於BREW的應用和擴充套件類志在執行時被發現和呼叫，這一點很像動態連線庫，事實上，BREW的應用和擴充套件類的模擬器版本就是一個DLL。

• ENVIRONMENT是指環境。BREW是一個開放而且靈活的環境，提供了大量的程式設計介面，並可以管理豐富的業務。

• WIRELESS是指無線。BREW 可以充分無限裝置的特性，快速有效的執行與低 RAM/FLASH 的環境中，使有限的無線網路資源得到有效的使用。

BREW基本上遵從COM這一元件構架的。元件架構的一個優點就是應用可以隨時間的流逝而發展進化，除此之外，使用元件還有一些可以使對以有應用的升級更加方便和靈活的優點，如應用的定製，元件庫以及分散式元件等。

M2M的應用框架

鑑於 M2M 技術的特點, 系統設計者可能不得不從頭開始構建整個 M2M 體系結構。其核心是, M2M 技術包括增加一個裝置或裝置的智慧服務, 並將該裝置與可以監控或控制該裝置的後端基礎設施連線起來。 為了實現這一目標, 一個 M2M 裝置使用了兩個基本元素: 與後端通訊的基礎設施(無線調變解調器或模組)和執行服務的軟體。

通過提供一種將 M2M 服務直接嵌入通訊模組的方法, 以及預先安裝裝的軟體模組、連線能力和處理資源方式，一般的M2M 應用框架如下：

EAF一般包括下列組成部分:

優化的輕量級作業系統

雖然一些 M2M 應用程式需要更強大的 RTOS, 但大多數都不需要。 作業系統的設計能夠提供 API 來控制語音, 資料呼叫, 簡訊, 以及 TCP/IP 連線。 應該經過優化, 以充分利用直接訪問協議棧的能力。 為了提供對連線應用程式的全面支援, 作業系統還應提供一個核心功能集, 其中包括:

• 實時性, 包括保證對外部或內部中斷的響應時間, 不論其狀態如何。

• 靈活安排任務的優先順序。

• 多工能力, 以定義和同步服務所需的任務。

• 在處理速度和功率選擇方面的靈活性, 以優化電池壽命。

• 記憶體、韌體和軟體保護功能。

• 能夠使用API訪問蜂音訊等媒體和資料路徑。

軟體庫

為了簡化開發過程和市場的速度時間, EAF 應該包括各種軟體庫和API, 提供裝置或服務可能需要的各種功能。 這包括定位、全面的網際網路連線協議、無線和網際網路安全等服務。 EAF還應支援為目標市場具體需求開發的第三方軟體庫。 理想情況下, EAF 不僅應得到通訊模組供應商的支援, 還應該得到合作伙伴和開發者的支援。

開發工具

EAF 還應該包含一個開發工具包, 以便於編碼、除錯和監視 M2M 應用程式, 這些工具應該是開源的, 可以免費使用。 最終, EAF 應該提供開發 M2M 應用程式並將其嵌入模組所需的一切。

雲連線

最後, EAF 應該提供工具來簡化連線裝置的雲管理, 包括一個完全實現的系統來處理裝置監控和軟體/韌體升級。 該系統應該允許開發者監控裝置的健康狀況, 並識別潛在的問題。 它還應該包括已驗證的作業系統遠端升級工具, 以及使用補丁機制的熱修復工具。

面向指令碼的EAF

對於為嵌入式系統建立軟體的開發者而言，對指令碼的編寫並不陌生。 選擇指令碼是往往是解決問題的最快方法。一般地，指令碼被用來自動構建和執行驗證測試。作為全棧必備的Javascript被廣泛應用於網頁、 web 伺服器和移動應用程式中，在嵌入式系統中也將佔據一席之地。

出於對效能的擔心，可以通過一些技術手段提升JavaScript的執行效能：

1.充分利用內建函式和物件。 Javascript 語言擁有支援陣列、 JSON、正規表示式和其他字串運算的複雜內建物件。 這些實現通常在 JavaScript 引擎中得到了很好的優化。 

2.小心編碼。由於指令碼比原生程式碼慢, 程式碼優化在效能重要的地方是至關重要的。 Javascript 的動態特性意味著 JavaScript 引擎通常不能像 c 編譯器那樣有效地優化程式碼。

3.混合程式設計。沒有一種語言適用於所有情況, 所以要為工作選擇最好的語言, 而不是100% 純粹地使用。 每一個 JavaScript 引擎都提供了一種從指令碼呼叫原生程式碼的方法。 如果不確定效能, 首先在 JavaScript 中實現, 因為它更容易執行。 如果存在效能瓶頸, 請在 c 中重新實現函式。

在 Mozilla 的一個專案 asm.js 中出現了一個可以替代使用 c 的方法。 定義了一個嚴格的 JavaScript 子集, 它更容易被翻譯成原生程式碼或 c 原始碼。 利用 c 和 JavaScript 之間的語法相似性, 使翻譯變得簡單明瞭。 嵌入式開發人員可以在 asm.js JavaScript 子集中編寫效能關鍵程式碼, 並將其編譯為原生程式碼, 作為構建過程的一部分, 而不是依賴 JIT。

對於記憶體的使用而言，從積極的一面來看, JavaScript 使用了一個垃圾收集器, 從而消除了顯式釋放記憶體的需要。 通過這種簡化, 嵌入式開發人員有時間專注於其他方面的開發。 

目前，已經有多個開發系統開始支援嵌入式的JavaScript：

• Espruino是一個微控制器開發板, 被稱為微控制器的 JavaScript。 它執行開源的 Espruino JavaScript 引擎, 它支援 JavaScript 標準的子集。

• Tessel 是一個整合了Wi-Fi的JavaScript 微處理器，並提供一個相容Node.js的 API，開發人員可以使用Node.js進行開發。

• Marvell Semiconductor 的 Kinoma Create 是一個執行在 Marvell 半導體上的”JavaScript 物聯網構建工具包”, 它支援完整的 JavaScript 5.0.

在國內，也有類似的開發系統，例如老友周愛民老師所在的ruff.io。

總之，Javascript 在嵌入式裝置上的潛力很大, 可以簡化嵌入式程式設計師的開發工作, 併為客戶提供更可靠、更可定製的產品。

---

綜上所述，嵌入式應用框架（EAF）對嵌入式系統的成功有著重要的意義。特別是對於嵌入式開放平臺而言，能夠提高開發者的開發效率，促進生態系統的繁榮。然而，IoT中還有很多超輕量級的裝置，或許根本沒有OS，被稱為“智慧顆粒”，笑稱“智霾”，可能不需要EAF，也可能是一種另外形態的EAF，只是我不知道而已。

參考：

• Jaroslav Tulach， 《軟體框架的設計藝術》，人民郵電出版社，2011

• 金泰延 宋亨周 樸知勳 李白 林起永， 《Android 框架揭祕》，人民郵電出版社，2012

• 曹洪偉，《BREW 進階與精通》，電子工業出版社，2009

• http://www.embedded-computing.com/hardware/embedded-application-frameworks-simplifying-the-development-of-m2m-devices

• http://www.embedded-computing.com/embedded-computing-design/javascript-for-embedded-devices

• http://www.embedded-computing.com/embedded-computing-design/speeding-embedded-systems-time-to-market-using-node-js