|
在過(guò)去的10年中，Linux成功地取代了一些最主要的傳統RTOS平臺，成為了各種各樣的嵌入式設備和應用中首選的新的嵌入式操作系統。盡管一度曾被認為是不重要的平臺，但今天嵌入式Linux已經(jīng)成為主流，并引領(lǐng)著(zhù)如下重要應用領(lǐng)域的市場(chǎng)和設計份額：消費電子、移動(dòng)和無(wú)線(xiàn)設備、數據聯(lián)網(wǎng)以及電信設備。 設計團隊越來(lái)越多地期望使用Linux作為標準的嵌入式操作系統�？紤]Linux的種種原因包括：廣泛的硬件支持、更高的可靠性、更優(yōu)異的性能、可擴展性以及更快的響應速度。不過(guò)，工程師在將基于傳統RTOS的設計移植到嵌入式Linux時(shí)會(huì )遇到幾大難題，因為L(cháng)inux的架構和傳統RTOS有很大的不同。 1 移植的時(shí)機 隨著(zhù)應用開(kāi)發(fā)步伐的不斷加快和產(chǎn)品生命周期的不斷縮短，對于設計團隊而言，能夠將傳統軟件移植到這些新平臺上并重新使用是十分重要的。盡管嵌入式Linux有許多優(yōu)勢，但是設計團隊在選擇從傳統的RTOS進(jìn)行移植之前，必須考慮如下幾項因素： ● 內存占用量。嵌入式Linux沒(méi)有傳統RTOS那樣緊湊。因此，工程師必須確保設備有足夠的內存和閃存來(lái)應對Linux更大的內存占用量。 ● 實(shí)時(shí)性考慮。嵌入式Linux可以實(shí)現50μs以下的響應時(shí)間。不過(guò)，這不一定能夠滿(mǎn)足項目需求，這一點(diǎn)有助于確定是否需要RTOS。 ● 認證需求。期望轉換到嵌入式Linux的設計團隊應確保項目將仍然滿(mǎn)足業(yè)界特有的認證需求，例如安全認證或美國國防部認證。 2 移植路徑選擇 盡管移植過(guò)程中存在固有的難題，但從傳統RTOS到Linux的移植不需要轉彎抹角。工程師可以采用以下三種路徑將應用從傳統的RTOS移植到Linux。 2.1 仿真RTOS的API 第一種移植路徑是仿真傳統RTOS的API。為了使傳統RTOS應用能夠駐留并運行在Linux上，必須具備基于Linux的運行時(shí)服務(wù)于RTOS系統調用和其他API。許多（但并非全部）RTOS入口點(diǎn)和獨立編譯器庫例行程序都在Linux和glibc運行時(shí)庫中有原樣的類(lèi)似程序。如果不存在類(lèi)似程序，就必須有新的代碼介入來(lái)仿真缺失的功能。即使存在類(lèi)似的API，可能也會(huì )出現參數類(lèi)型和數量不同的情況。 圖1 在Linux上仿真RTOS 傳統RTOS可以實(shí)現數百種系統調用和庫API。例如，VxWorks文檔描述了超過(guò)一千種獨特的函數和子例程。實(shí)際應用只使用數十個(gè)獨特的RTOS API，而它們其余的操作都使用來(lái)自標準C/C++庫的調用函數。 為了仿真這些接口以用于移植，開(kāi)發(fā)人員只需要RTOS調用的核心子集。許多OEM選擇自己建立和維護仿真輕量級庫，而其他OEM則使用來(lái)自供應商的更全面的商用庫。除了商用庫和自主開(kāi)發(fā)之外，另一種選擇是一個(gè)叫做v2lin的開(kāi)源項目，它可以仿真數十種常用的VxWorks API。此外，v2lin項目經(jīng)過(guò)架構改造之后，可用于較新的兼容于POSIX的glibc版本。 2.2 使用虛擬化進(jìn)行運行時(shí)劃分 對于期望采用Linux的工程師而言，虛擬化是另一種可行的移植路徑。虛擬化包括操作系統的駐留或者作為一個(gè)應用程序運行在另一個(gè)虛擬平臺之上，其中一部分系統軟件（運行在“裸機”之上或作為駐留的應用程序）可實(shí)現一個(gè)或多個(gè)“客戶(hù)”OS實(shí)例的執行。在企業(yè)級計算中，基于Linux的虛擬化技術(shù)是數據中心的主流功能，而且虛擬化也在嵌入式系統中找到了許多的應用。 嵌入式虛擬化要求將CPU、內存和其他資源進(jìn)行劃分，以駐留RTOS以及一個(gè)或多個(gè)客戶(hù)“應用程序”操作系統（通常是Linux）來(lái)運行更高層次的軟件。 圖2 采用虛擬化劃分開(kāi)的運行時(shí) 虛擬化可以通過(guò)允許RTOS應用程序和RTOS自身幾乎原樣地運行在新設計之中，而Linux則運行在自己的分區之中，以支持移植。這種方案適用于遺留代碼依賴(lài)于RTOS的API和RTOS的性能特點(diǎn)的情況，例如實(shí)時(shí)性能或協(xié)議棧的具體實(shí)現。 工程師可以使用虛擬化作為從遺留代碼向基于Linux的新設計過(guò)渡的簡(jiǎn)短且可靠的橋梁。不過(guò)，這種策略可能需要成本。OEM需要支付傳統RTOS運行時(shí)的使用費，還需要與VM供應商談判商用許可證。 圖3 RTOS的本地端口 2.3 逐步將應用移植到Linux 仿真和虛擬化可以提供直接明了的移植路徑來(lái)進(jìn)行原型制作、開(kāi)發(fā)、甚至是對運行在Linux上的傳統RTOS應用進(jìn)行部署。但是，它們的缺點(diǎn)是需要額外的代碼，并會(huì )涉及基礎設施和許可費用。相反，在Linux實(shí)現“本地化”就能降低復雜度，簡(jiǎn)化許可程序，并增強可移植性和性能。 圖4 將RTOS任務(wù)映射為L(cháng)inux線(xiàn)程 當設計團隊首次動(dòng)手處理移植項目時(shí)，他們往往會(huì )選擇仿真和虛擬化技術(shù)。隨著(zhù)他們不斷學(xué)習并更加熟悉Linux的開(kāi)發(fā)工具和運行時(shí)屬性，OEM可以逐步地重新建造傳統應用，以實(shí)現本地Linux執行。 一種方法是選擇單個(gè)傳統程序進(jìn)行本地移植，并將它們駐留在獨立的Linux進(jìn)程中。在軟件顯示出其對其他子系統有著(zhù)極小或者正常依賴(lài)性的情況下，這種技術(shù)最為適用。另一種明智的做法是，即使在部署仿真或虛擬化的時(shí)候也只將新的功能以本地代碼的形式來(lái)實(shí)現。 重要的一點(diǎn)是，要注意到這種選擇并不一定是相互排斥的。例如，設計團隊可以每次選擇一個(gè)關(guān)鍵的傳統程序，逐步地將傳統應用改造為本地Linux執行，然后將它們放入單獨的Linux進(jìn)程中，而新功能只以本地代碼方式來(lái)實(shí)現。 |
