26
今日电子 · 2010年7月
Features
专题特写：嵌入式开发工具
从RTOS移植到实时Linux
MontaVista软件公司 在过去的10年中，L i n u x成功地 取 代 了 一 些 最 主 要 的 传 统 R T O S平 台，成为了各种各样的嵌入式设备和 应用中首选的新的嵌入式操作系统。 尽管一度曾被认为是不重要的平台， 但今天嵌入式L i n u x已经成为主流， 并引领着如下重要应用领域的市场和 设计份额：消费电子、移动和无线设 备、数据联网以及电信设备。 设计团队越来越多地期望使用 Linux作为标准的嵌入式操作系统。考 虑L i n u x的种种原因包括：广泛的硬 件支持、更高的可靠性、更优异的性 能、可扩展性以及更快的响应速度。 不过，工程师在将基于传统R T O S的 设计移植到嵌入式Linux时会遇到几大 难题，因为Linux的架构和传统RTOS 有很大的不同。 移植路径选择 尽管移植过程中存在固有的难 题，但从传统RTOS到Linux的移植不 需要转弯抹角。工程师可以采用以下 移植的时机 随着应用开发步伐的不断加快 和产品生命周期的不断缩短，对于设 计团队而言，能够将传统软件移植到 这些新平台上并重新使用是十分重要 的。尽管嵌入式L i n u x有许多优势， 但是设计团队在选择从传统的R T O S 仿真RTOS的API 第一种移植路径是仿真传统RTOS 的A P I。为了使传统R T O S应用能够 驻留并运行在L i n u x上，必须具备基 三种路径将应用从传统的R T O S移植 到Linux。 Dean Misenhimer
进行移植之前，必须考虑如下几项因 素：
●
内存占用量。嵌入式L i n u x没
有传统R T O S 紧凑。因此，工程 师必须 设备有足够的内存和闪存 来应对Linux更大的内存占用量。
●
实时性考虑。嵌入式L i n u x可
以实现50μ s以下的响应时间。不过， 这不一定能够满足项目需求，这一点 有助于 是否需要RTOS。
●
认证需求。期望转换到嵌入式
Linux的设计团队应确保项目将仍然满 足业界特有的认证需求，例如安全认 证或美国国防部认证。
今日电子 · 2010年7月
27
专题特写：嵌入式开发工具
于Linux的运行时服务于RTOS系统调 用和其他A P I。许多（但并非全部） RTOS入口点和独立编译器库例行程序 都在Linux和glibc运行时库中有原样的 类似程序。如果不存在类似程序，就 必须有新的代码介入来仿真缺失的功 能。即使存在类似的API，可能也会出 现参数类型和数量不同的情况。
Features
较新的兼容于POSIX的glibc版本。
适用于遗留代码依赖于RTOS的API和 R T O S的性能特点的情况，例如实时
使用虚拟化进行运行时划分 对于期望采用L i n u x的工程师而 言，虚拟化是另一种可行的移植路 径。虚拟化包括操作系统的驻留或者 作为一个应用程序运行在另一个虚拟 平台之上，其中一部分系统软件（运 行在“ ”之上或作为驻留的应用 程序）可实现一个或多个“客户”O S 实例的执行。在企业级计算中，基于 Linux的虚拟化技术是数据中心的主流 功能，而且虚拟化也在嵌入式系统中 找到了许多的应用。
性能或协议栈的具体实现。
图3 RTOS的本地端口
工程师可以使用虚拟化作为从遗 留代码向基于L i n u x的新设计过渡的 简短且可靠的桥梁。不过，这种策略 可能 需要 成本 。O E M需 要支 付传统
图1 在Linux上仿真RTOS
RTO S运行时的使用费，还需要与V M 供应商谈判商用许可证。
传统R T O S可以实现数百种系统 调用和库AP I。例如，Vx W o rks文 描述了超过一千种独特的函数和子例 程。实际应用只使用数十个独特的 R TO S A P I，而它们其余的操作都使 用来自标准C/C++库的调用函数。 为了仿真这些接口以用于移植， 开发人员只需要R T O S调用的核心子 集。许多O E M选择自己建立和维护仿 真轻量级库，而其他O E M则使用来自 供应商的更全面的商用库。除了商用 库和自主开发之外，另一种选择是一 个叫做v2l i n的开源项目，它可以仿真 数十种常用的VxWorks API。此外， v2l i n项目经过架构改造之后，可用于

上一页下一页