嵌入式   Linux 是以Linux为基础的嵌入式作业系统，它被广泛应用在移动电话、个人数字助理(PDA)、媒体播放器、消费性电子产品以及航空航天等领域中。

过去很多嵌入式系统不是一个操作系统，或者是提供商的专有核心，或者是DOS操作系统的扩展。显然这些方法并不能适应今天嵌入式系统开发的要求！现有的一些商业实时操作系统，尽管提供了很小的核心和多任务开发环境，但性能并不理想，也不符合现在实时嵌入式市场的需求。

因此，人们把目光投向了通用操作系统（例如Windows、Solaris、linux），希望把它们“改造”为实时操作系统。通常这些操作系统功能强大，结构复杂，易于软件的二次开发，实用性强，并且提供编程人员熟悉的标准API。此外，这些操作系统也提供了一些对实时软件开发的支持。然而，这些操作系统用于嵌入式系统的开发还存在不足。嵌入式系统要求具备高可靠性，满足应用需求的可剪裁性，以及比通用操作系统要求更高的实时性。

做为嵌入式系统开发的解决方案，linux在众多通用操作系统中具有独一无二的优势。

首先，Windows和Solaris等专有商业操作系统的剪裁受到商家的严格控制。这大大限制了开发者的剪裁深度。而linux遵循GPL协议，开放所有系统源代码，非常易于剪裁。

其次，同其它开放源码的通用操作系统（如FreeBSD）相比，linux在多种处理器、开发板支持和软件开发工具支持上有很强的优势。

linux最初也是作为通用操作系统而设计开发的，但提供了一些实时处理的支持。这包括支持大部分POSIX标准中的实时功能，支持多任务、多线程，具有丰富的通信机制等。

linux还提供符合了POSIX标准的调度策略，包括FIFO调度策略、时间片轮转调度策略和静态优先级抢占式调度策略。其默认的调度策略是第三种。Linux还提供了内存?üδ埽员苊庠谑凳贝碇写娲⒁潮换怀觯蔡峁┝朔螾OSIX 标准的实时信号机制。

一个致命问题是，linux在用户态支持可抢占调度策略，而在核心态却不支持抢占式调度策略。这样运行在Linux核心态的任务（或系统调用）是不能被其它优先级更高的任务所抢占的，这样就会引起优先级逆转问题。另外，Linux操作系统的中断处理句柄是不可调度的，不能依优先级高低调度。而在实时系统中，却希望中断处理句柄同实时任务一样，可以有优先级来被系统的调度程序所调度。

此外，我们还关心和任务响应时间相关的时钟精度，以及由于资源共享而带来的优先级逆转问题。linux中硬件时钟中断的默认时间间隔是10ms，所有的软件时钟都是靠硬件来触发的。而简单同步机制(互斥)不支持优先级继承又很可能导致优先级逆转。

独立核方法

linux作为实时系统的独立核方法是指设计一种完全独立的实时核心，但其API 与Linux核心相兼容。这种方法的理论基础是一款优秀的实时操作系统必须在其设计之初就充分考虑到系统实时性的要求，并能够提供符合标准的API。这种实现方法对很多与POSIX 兼容的专有实时系统提供商很有吸引力。

这种方法的局限性是由于设计了一个完全独立的实时核心而没有使用原有linux核心，导致Linux系统的一些优势难以继承，尤其是与Linux核心相关的一些优势无法获得。比如Linux核心对大量硬件的广泛支持，Linux核心超群的可靠性、稳定性等。另外，由于这种方法并没有通过修改Linux核心代码来开发实时核心，而是在Linux系统之上重新设计了一个实时核心，这样的开发并不要求源代码开放。因此，Linux一些基于开放源代码的优势也势必受损。最后一点，任何基于Linux核心的开发成果也无法方便地应用到实时核心中。

当然这种实现方法也从linux系统中得到了很多好处。由于Linux系统的支撑，实时核心就并不需要“真”的去实现。而且熟悉Linux系统的开发人员也可以很快地熟悉这种方法开发出的实时系统。人们也会自然地想到用Linux系统做嵌入式系统的开发平台。此外，如果这种实时系统的API是Linux系统API子集的话，我们还可以只在Linux主机上仿真，进行应用程序的开发和调试，免去了远程调试之苦！

与linux API的兼容程度是评估这类实时系统的一个重要指标。如果一个实时系统兼容了所有Linux API，那么就允许所有Linux上的应用程序和库在其上运行使用。因此，这将会带来一个巨大的好处，所有在Linux上可用的第三方软件均可以在其上使用。当然，开发一款这样兼容所有Linux API的实时系统决不是件容易的事，尤其是对于单个开发商来说。

所以，大量的第三方软件并不能很容易地移植到实时系统中来，这点不足，也使linux的优势大打折扣！

双核方法

这种方法在同一硬件平台上采用了两个相互配合，共同工作的系统核心，一个核心提供精确的实时多任务管理，另一个核心提供复杂的非实时通用功能。

这种方法是通过在linux操作系统的最底层增加一层实时核心层来实现的。实时核心负责硬件管理并提供实时任务管理。实时核心还用软件“模拟”常规Linux系统对底层硬件的使用/禁止中断，而不是真正的操作中断控制寄存器。Linux核心被看做实时核心中优先级最低的任务来调度，只有当没有可运行的实时任务时Linux核心才被调度。

这种方法的一个关键所在是运行在常规linux核心上的所有非实时任务必须是支持可抢占式调度的。这样才能做到对实时核心提供精确实时保证没有任何影响。由于实时核心非常小，并不会增加整个系统的负载，所有这些对开发实时性要求严格的实时软件都提供了有力保障。

这种方法的弊端在于实时任务的开发是直接面向提供精确实时服务的小实时核心的，而不是功能强大的常规linux核心。因此，实时任务是运行在系统核心层的，这就意味着这些实时任务可以运行在没有内存保护的级别之上。所以，一个实时任务的错误可能会导致整个系统的瘫痪！更要命的是，这些实时任务的开发由于面对的是小的实时核心，而不能直接利用Linux API和第三方软件及运行库。

这种开发模式暗示我们必须要对应用进行静态分解。把它分解成实时部分和非实时部分。在大多情况下，这是件好事情。它迫使开发人员将应用系统分解成实时子系统和非实时子系统两部分。但很显然，使用这种开发模式也限制了应用的类型！因为，这种用二元论观点看待实时系统的方法并不适合所有的应用。在一些应用中，实时部分和非实时部分的界线并不是十分分明，期间可能存在着不同程度的软实时部分。

这种方法的另一个不足之处是，开发模式混合了实时应用的两个不相干维度——功能需求和实时需求。它要求应用的实时需求必须限制于由实时核心提供的功能需求限度以内。而实时核心提供的功能支持非常有限。当然我们也可以扩展实时核心的功能，比如增加实时网络功能等。然而，新增加的部分很有可能会重叠linux核心已有功能，而导致了不必要的系统“膨胀”，并折损这种方法的价值。