在過去的10年中，Linux成功地取代了一些最主要的傳統(tǒng)RTOS平臺，成為了各種各樣的嵌入式設(shè)備和應(yīng)用中首選的新的嵌入式操作系統(tǒng)。盡管一度曾被認為是不重要的平臺，但今天嵌入式Linux已經(jīng)成為主流，并引領(lǐng)著如下重要應(yīng)用領(lǐng)域的市場和設(shè)計份額：消費電子、移動和無線設(shè)備、數(shù)據(jù)聯(lián)網(wǎng)以及電信設(shè)備。

設(shè)計團隊越來越多地期望使用Linux作為標準的嵌入式操作系統(tǒng)。考慮Linux的種種原因包括：廣泛的硬件支持、更高的可靠性、更優(yōu)異的性能、可擴展性以及更快的響應(yīng)速度。不過，工程師在將基于傳統(tǒng)RTOS的設(shè)計移植到嵌入式Linux時會遇到幾大難題，因為Linux的架構(gòu)和傳統(tǒng)RTOS有很大的不同。

移植的時機
隨著應(yīng)用開發(fā)步伐的不斷加快和產(chǎn)品生命周期的不斷縮短，對于設(shè)計團隊而言，能夠?qū)鹘y(tǒng)軟件移植到這些新平臺上并重新使用是十分重要的。盡管嵌入式Linux有許多優(yōu)勢，但是設(shè)計團隊在選擇從傳統(tǒng)的RTOS進行移植之前，必須考慮如下幾項因素：

● 內(nèi)存占用量。嵌入式Linux沒有傳統(tǒng)RTOS那樣緊湊。因此，工程師必須確保設(shè)備有足夠的內(nèi)存和閃存來應(yīng)對Linux更大的內(nèi)存占用量。

● 實時性考慮。嵌入式Linux可以實現(xiàn)50μs以下的響應(yīng)時間。不過，這不一定能夠滿足項目需求，這一點有助于確定是否需要RTOS。

● 認證需求。期望轉(zhuǎn)換到嵌入式Linux的設(shè)計團隊應(yīng)確保項目將仍然滿足業(yè)界特有的認證需求，例如安全認證或美國國防部認證。

移植路徑選擇
盡管移植過程中存在固有的難題，但從傳統(tǒng)RTOS到Linux的移植不需要轉(zhuǎn)彎抹角。工程師可以采用以下三種路徑將應(yīng)用從傳統(tǒng)的RTOS移植到Linux。

仿真RTOS的API
第一種移植路徑是仿真?zhèn)鹘y(tǒng)RTOS的API。為了使傳統(tǒng)RTOS應(yīng)用能夠駐留并運行在Linux上，必須具備基于Linux的運行時服務(wù)于RTOS系統(tǒng)調(diào)用和其他API。許多（但并非全部）RTOS入口點和獨立編譯器庫例行程序都在Linux和glibc運行時庫中有原樣的類似程序。如果不存在類似程序，就必須有新的代碼介入來仿真缺失的功能。即使存在類似的API，可能也會出現(xiàn)參數(shù)類型和數(shù)量不同的情況。

圖1 在Linux上仿真RTOS

傳統(tǒng)RTOS可以實現(xiàn)數(shù)百種系統(tǒng)調(diào)用和庫API。例如，VxWorks文檔描述了超過一千種獨特的函數(shù)和子例程。實際應(yīng)用只使用數(shù)十個獨特的RTOS API，而它們其余的操作都使用來自標準C/C++庫的調(diào)用函數(shù)。

為了仿真這些接口以用于移植，開發(fā)人員只需要RTOS調(diào)用的核心子集。許多OEM選擇自己建立和維護仿真輕量級庫，而其他OEM則使用來自供應(yīng)商的更全面的商用庫。除了商用庫和自主開發(fā)之外，另一種選擇是一個叫做v2lin的開源項目，它可以仿真數(shù)十種常用的VxWorks API。此外，v2lin項目經(jīng)過架構(gòu)改造之后，可用于較新的兼容于POSIX的glibc版本。