|
|||||||||||
| 技术交流 | 电路欣赏 | 工控天地 | 数字广电 | 通信技术 | 电源技术 | 测控之家 | EMC技术 | ARM技术 | EDA技术 | PCB技术 | 嵌入式系统 驱动编程 | 集成电路 | 器件替换 | 模拟技术 | 新手园地 | 单 片 机 | DSP技术 | MCU技术 | IC 设计 | IC 产业 | CAN-bus/DeviceNe |
Real-Time Linux 简介 |
| 作者：barco 栏目：嵌入式系统 |
即时作业系统 (Real-time OS) 是相对于分时作业系统 (Time-Sharing OS) 的一个 概念。在一个分时作业系统中，电脑系统的资料会被平均的分配给系统内所有的工 作 。对于这些工作而言，它们似乎是在一个速度较慢、资源较少的虚拟系统上工作。 而这 个虚拟系统所拥有的资源会和真实系统内等待执行的工作数有关。简单的说，如 果有 n 个工作要做，每一个工作就会分到 n 分之一的资源。 然而在一个即时作业系统之中，系统内有多少工作并不是那么重要。我们关心的 事 一个工作在多少的时间内可以被完成。和分时作业系统最大的不同之处在于 『时限(dea dline)』这个概念，即时作业系统通常会要求每一个工作在交付给系 统的时候同时也给 定一个时限。即时作业系统的任务不只是要求完成每一个工作， 并且要按时给定的时限 完成每一个工作。 所以我们可以看出这二个概念的不同之处，分时作业系统的重点在于『公平』， 而 即时作业系统的重点在于『时限(timing constraint))』。 任何时候。我不是开玩笑，当一个即时作业系统中的每一个工作都有相同的时限时 ， 它应该和分时作业系统用相同的方式工作。分时作业系统和即时作业系统的分野在于 工作的特性而非作业系统工作的模式。 在很多的书及文献上我们可能会看到『硬即时(hard real-time)』和『软即时 ( soft real-time)』这二个名词。不同的人会给它们不同的意义，但大致来说它们 是一 组相对的概念。硬即时对满足时限的要求会比软即时来的严格。有些人会从 工作的特性 上来分，硬即时工作 (hard real-time task) 通常指不能有任何差 错的工作而软即时 则是指比较容许差错的工作。例如我们常会用核能电厂和看 VCD 为例，用在核能电厂的 即时作业系统如果出了差错可能会导致严重的损害，然而 VCD Player 出了些差错不过 是让使用者认清他所用的程式不够好而已。所以前者 是硬即时，后者是软即时。 但在大多数的状况下，分野并不是如此的清楚。做 VCD Player 的厂商当然不 希望 它的 Player 老是出错，它也会希望 Player 用一个硬即时作业系统来驱动。 所以硬即 时和软即时的差别可能只是分类学上的问题而已。 然而对于一般的应用而言，即时作业系统的意义在那里呢? 我们使用流览器看一 个 网站时，如果结果在 0.5 秒内出现，我们可能会觉得非常舒服。如果结果在 2 秒才出 现，可能会觉得有些延迟。但如果花上 30 秒才出现，那可能就没有人会等 到结果出现 了。 对于我们而言，等个 3,5 秒可能觉得没什么。但也许 Bill Gates 不这么想， 他 会算给你听他的一秒值多少钱! 所以不同的人可能会对延迟有不同的看法。即 时作业系 统最大的优势就在于他可以为不同的工作提供『不同等级的服务( differentiated service)』。 一个对即时系统常有的误解是即时系统是一个高效率 (high performance) 的 系统 ，它会跑得比一般作业系统来的快，overhead 来得小。这其实是市场策略宣 传造成的 影响。一大堆非常小的作业系统宣称它们是嵌入式即时作业系统 (embedded real-time OS)，这么一来『嵌入』、『即时』和『小』就被莫名其 妙的连起来了。实 事上这三个是完全不相干的概念。『嵌入』指的是作业系统可 以在一些资源受限的环境 ，例如没有 disk，的情况下工作。『小』是指因为功能 简单，要求不多，所以作业系 统可以写的很小，减少不必要的额外负担。这些都 和『即时』的概念完全没有关系。不 幸的是，即使是学有专精的电脑工程师也常 把它们混为一谈。 为什么不用? 即时作业系统和分时作业系统并不是完全互斥的概念，我前面说过如 果一个即时作业系统中所有的工作都有相同的时限，那它应该会制造出和分时作业 系统相同的结果。 所以一个系统可以同时执行分时和即时的工作另一个常有的误解是即时的工作 应该比分时的工作先执行。这其实是不对的，即时的工作只是要求在时限内完成 而已，一个时限在 10 秒之后的工作没有道理一定要在现在立刻执行。太早完成 它没有任何好处，有时还会造成系统不必要的负担。 即时作业系统的优势在于它知道目前系统资源使用的状况，它能比起分时作业 系统更精准的控制系统资源的使用。对于分时作业系统而言，它无法预测一个工 作到底还须要花多少时间才能完成。因此对于比较重要的工作，唯一的方法就是 尽快的完成它。而即时作业系统可以预测工作完成的时间，因此它可以轻易的决 定工作要在什么时间被执行。 所以即时作业系统所做的事，不过就是一个更强大的 renice 指令而已。在 renice 中，你只能指定一个叫优先权 (priority) 的值。优先权越高的工作 在分时系统中会分到更多的时间，但多多少呢? 没人能回答这个问题，因为在 分时作业系统中不把它视为一个重要的事。 而即时作业系统的 renice 指定可以指定一大堆的参数，你可以指定前述的 时限 (deadline)，优先权 (priority)。还可以指定工作在单工状态下执行所 需的时间 (execution time)、工作应该在什么时候允许开始执行 (start time) 、什么时候就不应该再继续下去了(finish time)。当然过去二十年来在即时作 业系统理论上的发展使得我们还有更多更多的可能性来实作即时作业系统的 renice 指令。但简单的说，我们得到的是一个更强大的 renice 指令。它可以被用来更 精准的调整系统的整体效能。这也就是我为什么会认为，为什么不用即时作业系 统。 我的看法是，在将来的作业系统，即时会是一个和网路一样、是系统标准的功能。 和 Linux 其它领域一般，有一大堆的人都试图为 Linux 加上即时的功能。每个人 都有不同的看法，每个人看的角度也不相同，所以产生了各式各样的『real-time Linux OS』。在这里，我们看到了开放原始码 (open source) 在这个领域优势所 在。我们可以想见在不久的将来，这些各有专精的系统会自然的合并成一套非常好 用的即时作业系统。而不是相互用市场的策略恶性竞争。所以 open source 可以 提供我们一套更新、更好、更实用的即时作业系统。 接下来，我们先简介一下现存的各种 real-time Linux OS。 NMT RT-Linux NMT 是新墨西哥科技大学(New MEXICO TECHNOLOGY) 的缩写。这一套系统可以说是 所有 Real-time Linux 的鼻祖。它目前已经发展到 3.0 版。这个系统是由 Victor Yodaiken 和它的学生 Michael Barabanov 所完成。这个系统的概念是『架空』 Linux kernel，使得它的 real-time 行程得以尽快的被执行。下面的图例说明了 NMT RT-Linux 和其它类似产品的系统架构。 你可以看到基本上RT-Linux 中的即时工作(realtime task) 其实并不是 一个 Linux 的行程，而是一个 Linux 的可载入式核心模组( loadable kernel MODULE)。 之所以要如此做的原因在于 Linux 是一个很大的系统，且在设计的时候并没 有考虑 real-time 的需求。举个例说，单一个 Linux 系统呼叫可能会花上超过 10ms 的时间。对有些像工业控制的应用而言，它们对时间的要求通常在 1ms 的 等级上，Linux 根本无法满足这种需求。所以 NMT RT-Linux 采用一个比较简单 的做法，它乾脆不用直接 Linux 的任何功能，而把需要高度时间精确度的工作 写成一个驱动程式的型式，然后直接用 PC 时序晶片 (timer chip) 所产生的中 断呼叫这个驱动程式。如此一来，不管 Linux 系统呼叫的时间有多长都没有关系 了。 从这个角度看，NMT RT-Linux 其实是一个即时驱动程式的架构，算不上是真 正的 real-time Linux. 但由于它出现的早，且其架构很符合自动控制的需求。 使用者非常的多，且多半是有关自动控制的应用。 RTAI RTAI 是 Real-Time Application Interface 的缩写。顾名思义知道它是一套可 以用来写即时应用程式的界面。大致而言，RTAI 和 NMT RT-Linux 是相同的东西。 它同样的架空了 Linux，而直接用可载入式核心模组( loadable kernel MODULE) 实作 real-time PROCESS。每一个即时行程实际上就是一个可载入式核心模组。 RTAI 和 NMT RT-Linux 最大的不同地方在于它非常小心的在 Linux 上定义了 一组 RTHAL (Real-Time HARDWARE Abstraction Layer)。RTHAL 将 RTAI 需要 在 Linux 中修改的部份定义成一组程式界面，RTAI 只使用这组界面和 Linux 沟通。这样做的好处在于我们可以将直接修改 Linux 核心的程式码减至最小， 这使得将 RTHAL 移植到新版 Linux 的工作量减至最低。 RTAI 采取这种途径最大的原因在于 NMT RT-Linux 在由 2.0 版移植至 2.2 版 的过程式遇到问题，使得基于 2.2 版核心的 NMT RT-Linux 一直无法完成。所以 在 Dipartimento di Ingegneria Aerospaziale Politecnico di Milano 的 Paolo Mantegazza 和他的同事们就决定自行做移植的工作，但由 NMT RT-Linux 的困境他们体认到必须采取上述的途径以解决将来可能再度面临的相容性问题。 于是 RTAI 便诞生了，它是一个比 NMT RT-Linux 更好的 NMT RT-Linux，虽 然后来 NMT RT-Linux 也随后完成移植的工作，但那已经是 RTAI 诞生半年以 后的事了。 LXRT 由于 RTAI 无法直接使用 Linux 的系统呼叫，解决的方法是使用 RT-FIFO 将一个 RTAI real-time kernel MODULE 和真正的 Linux 行程连接在一起，由这个行程做 代理人的工作为其呼叫 Linux 系统呼叫。下图说明了 LXRT proxy 行程的概念 红色的部份表示一组 RTAI 的即时行程和它在使用者模式 (user space) 的 伙伴。你可以了解，当 proxy 启动后，它不再可以被任何的抢先 (preempt)， 所以原本有的优势就不再保有了。 KURT KURT 是由 kansas 大学所创造的系统，它和 NMT RT-Linux 及 RTAI 有很大的不同。KURT 是第一个可 |
| 2楼： | >>参与讨论 |
| 作者： zz433 于 2005/1/29 15:24:00 发布：
好东西！ 好东西！ |
|
|
|
| 免费注册为维库电子开发网会员，参与电子工程师社区讨论，点此进入 |
Copyright © 1998-2006 www.dzsc.com 浙ICP证030469号 |