linux在嵌入式系统的开发
贴子发表于：2005/12/14 19:21:15
一、 Linux嵌入式系统
操作系统是一种在计算机上运行的软件，它的主要任务是管理计算机上的系统资源，为用户提供使用计算机及其外部设备的接口。它存在的目的是为了管理所有硬件资源，并且提供应用软件一个合适的操作环境。嵌入式系统由于硬件的先天限制，经常只具有极稀少的硬件资源，如 时脉较少的 CPU、较少的内存、常不具有磁盘而用小容量的DiskOnChip或DiskOnModule。而在使用电池的系统中，它还要实现节省电池消耗，延长电池使用时间的功能。
Linux 作为嵌入式操作系统是完全可行的，因为Linux提供了完成嵌入功能的基本的内核和你所需要的所有用户界面，它是多面的。它能处理嵌入式任务和用户界面。将Linux看作是连续的统一体，从一个具有内存管理、任务切换和时间服务及其他的分拆的微内核到完整的服务器，支持所有的文件系统和网络服务。Linux作为嵌入式系统是一个带有很多优势的新成员,它对许多CPU和硬件平台都是易移植的、稳定、功能强大、易于开发。
Application program
API
X-server Java virtual machine
Device driver
Linux Kernel
Boot load
嵌入式Linux系统需要下面三个基本元素：
1． 引导工具
2． Linux微内核：内存管理、 程序管理
3． 初始化进程
如果要它成为完整的操作系统且继续保持小型化，还得加上：
1．硬件驱动程序
2．硬件接口程序
3．应用程序组
谈到操作系统就一定要说一说它的开发环境，Linux是基于GNU的C编译器，作为GNU工具链的一部分，与gdb源调试器一起工作。它提供了开发嵌入式Linux系统的所有软件工具。以下是一个典型的开发工具的使用流程：
1.写入或植入引导码
2.向串口打印字符串的编码
3.将gdb目标码移植工作串口，这可与另一台运行gdb程序的Linux 主机系统对话
4.利用gdb让硬件和软件初始化码在Linux内核启动时工作
5.Linux内核启动，串口成为Linux控制口并可用于后续开发
6.如果在你的目标硬件上运行了完整的Linux内核，你可以调试你的应用进程
更详细的内容可参见网站
http://www.emlinux.com 二、硬件平台
研发人员在选择最好的硬件时，往往由于缺乏完整或精确的信息而使选择硬件成为复杂且困难的工作。硬件成本经常是关键的议题，当考虑成本时、需要确信你在考虑产品的整个成本而不仅是CPU的成本；因为好的CPU一旦加上总线逻辑和延时电路使之与外设一起工作，硬件系统可能变成非常昂贵的产品。如果你正在寻找嵌入式软件系统，那么应首先确定了硬件平台即确定了微处理器CPU的型号。
现在比较流行的硬件平台有Intel公司的Strong Arm 系列,Motorola公司的DragonBall系列，NEC公司的VR系列，Hitachi公司SH3,SH4系列等等，都可选为硬件平台。但最好在选定前先要确定所做系统的应用功能和所需的速度，并且制定好外接设备和接口标准。这样可准确的定位所需要的硬件方案，得到性价比最高的系统。 下图是以Intel公司的StrongArm为例来说明硬件平台：
三、Linux嵌入式系统与硬件的关系
对初学者而言，可以将内核与任务分开，标准的Linux内核通常驻留在内存中，每一个应用程序程序都是从磁盘运到内存上执行。当程序结束后，它所占用的内存就被释放，程序就被下载了。在一个嵌入式系统里，可能没有磁盘。有两种途径可以消除对磁盘的依赖，这要看系统的复杂性和硬件的设计。在一个简单的系统里，当系统启动后，内核和所有的应用程序都在内存里。这就是大多数传统的嵌入式系统工作模式，它同样可以被Linux支持。有了Linux，就有了第二种可能性。因为Linux已经有能力"加载"和"卸载"程序，一个嵌入式系统就可以利用它来节省内存。试想一个典型的包括一个大概8MB到16MB的Flash Memory和8MB内存的系统。Flash Memory可以作为一个文件系统。Flash Memory驱动程序用来连接Flash Memory和文件系统。作为替代也可使用Flash Disk，用工具软件可把Flash Memory仿真为磁盘或部分。其中一个例子是Intel 公司可提供Flash Memory 管理软件IPSM -Intel Persistent Storage Manager, 详情见
http://developer.intel.com/design/builder/flbldr/swb/swb.htm 所有的程序都以文件形式存储在Flash文件中，需要时可以装入内存。这种动态的、"根据需要加载"的能力是支持其它一系列功能的重要特征：
1. 它使初始化代码在系统引导后被释放。Linux同样有很多内核外运行的公用程序。这些通常程序在初始化时运行一次，以后就不再运行。而且，这些公用程序可以用它们相互共有的方式，一个接一个按顺序运行。这样，相同内存空间可以被反复使用以"调入"每一个程序，就象系统引导一样。这的确可以节省内存，特别是那些配置一次以后就不再更改的网络堆栈。如果Linux可加载模块的功能包括在内核里，驱动程序和应用程序就都可以被加载。它可以检查硬件环境并且为硬件装上相应的软件。这就消除了用一个程序占用许多Flash Memory来处理多种硬件的复杂性。
2. 软件的升级更模块化。你可以在系统运行的时候在Flash上升级应用程序和可加载驱动程序。
3. 配置信息和运行时间参数可以作为数据文件储存在Flash上。
虚拟内存
标准Linux的另一个特征是虚拟内存的能力。正是这种神奇的特征使应用程序员可以狂热的编写代码而不计后果，不管程序有多大。在嵌入式系统里不需要这种强大的功能。实际上，因为它会带来无法控制的时间因素，你可能不希望它在实时的系统里。这个软件必须设计得更加精悍，以适合硬件平台上的物理内存，就象其它嵌入式系统一样。注意由于CPU的原因，通常在Linux中保存虚拟内存代码是明智的，因为将它清除很费事；而且还有另外一个原因--它支持共享文本，这样就可以使许多程序共享一个软件。
虚拟内存的调入功能可以被关掉，只要将交换空间的大小设置为零。如果你写的程序比实际的内存大，系统就会当作你的运行用尽了交换空间来处理；这个程序将不会运行，或者malloc将会失灵。在许多CPU上，虚拟内存提供的内存管理可以将不同程序分开，防止它们写到其它地址的空间上。这在嵌入式系统上通常不可能，因为它只支持一个简单、扁平的地址空间。Linux的这种功能有助于其发展。它减少了胡乱的编写程序造成系统崩溃的可能性。许多嵌入式系统基于效率方面的原因有意识使用程序间可以共享的"全局"数据。这也可以通过Linux共享内存功能来支持，共享的只是指定的内存部分。
文件系统
许多嵌入式系统没有磁盘或者文件系统。Linux不需要它们也能运行。实际上，许多商业性嵌入式系统提供文件系统作为选项。Linux提供 MS-DOS-Compatible文件系统，同时还有其它多种选择。之所以提供其它选择是因为它们更加强大而且具有容错功能。Linux还具有检查和维护的功能，商业性供应商往往不提供这些。这对于Flash系统来说尤其重要，因为它是通过网络更新的。如果系统在升级过程中失去了能力，那它就没有用了。维护的功能通常可以解决这类问题。
文件系统可以被放在传统的磁盘驱动器、Flash Memory或其它这类的介质上。而且，用于暂时保存文件，一个小RAM盘就足够了。Flash Memories被分割成块。这些块中也许包括一个含有当CPU启动时运行的最初的软件的引导块。这可能包括Linux 引导代码。剩余的Flash可以用作文件系统。Linux的内核可以通过引导代码从Flash复制到RAM，或者还有一个选择，内核可以被存储在Flash的一个独立部分，并且直接从那里执行。另外对于一些系统来说还有一个有趣的选择，那就是将一个便宜的CD-ROM包含在内。这比Flash Memory 便宜，而且通过交换CD-ROM支持简单的升级。有了这个，Linux 只要从 CD-ROM上引导，类似从硬盘上一样从CD-ROM上获得所有的程序。
最后，对于联网的嵌入式系统来说，Linux 支持NFS（Network File system）。这为实现联网系统的许多增值功能打开了大门。第一，它允许通过网络上加载应用程序。这是控制软件修改的基础，因为每一个嵌入式系统的软件都可以在一个普通的服务器上加载。它在运行的时候也可以用来输入或输出大量的数据、配置和状态信息。这对用户监督和控制来说是一个非常强大的功能。举例来说，嵌入式系统可以建立一个小的RAM磁盘，包含的文件中有与当前状态信息同步的内容。其它系统可以简单的把这个RAM磁盘设置为基于网络的远程磁盘，并且空中存取状态文件。这就允许另一个机器上的Web服务器通过简单的CGI Script存取状态信息。在其它电脑上运行的其它应用程序包可以很容易的存取数据。
引导--LILO和BIOS在哪里
当一个微处理器第一次启动的时候，它开始在预先设置的地址上执行指令。通常在那里有一些只读内存，包括初始化或引导代码。类似于在PC上的BIOS。它执行了一些低水平的CPU初始化和其它硬件的配置文件。BIOS继续辨认哪个磁盘里有操作系统，把操作系统复制到RAM并且转向它。实际上，这非常复杂，但对我们的目标来说也非常重要。在PC上运行的Linux依靠PC的BIOS来提供这些配置和OS加载功能。
在一个嵌入式系统里经常没有这种BIOS。这样你就要提供同等的启动代码。幸运的是，嵌入式系统并不需要象PC机上的 BIOS引导程序那样的灵活性，因为它通常只需要处理一个硬件的配置。这个代码更简单也更枯燥。它只是个指令清单，将固定的数字塞到硬件寄存器中去。然而，这是关键的代码，因为这些数值要与你的硬件相符而且要按照特定的顺序进行。所以在大多数情况下，一个最小的通电自检模块，可以检查内存的正常运行、让LED闪烁，并且驱动其它必须的硬件以使主Linux OS启动和运行。这些启动代码完全根据硬件决定，不可随意移动。幸运的是，许多系统都有为核心微处理器和内存所定制的菜单式硬件设计。典型的是，芯片制造商有一个样本主板，可以用来作为设计的参考--或多或少与新设计相同。通常这些菜单式设计的启动代码是可以获得的，它可以根据你的需要轻易的修改。在少数情况下，启动代码需要重新编写.为了测试这些代码，你可以使用一个包含模拟内存的电路内置模拟器，它可以代替目标内存。你把代码装到模拟器上并通过模拟器调试。如果这样不行，你可以跳过这一步，但这样就要一个更长的调试周期。这个代码最终要在较为稳定的内存上运行，通常是Flash或EPROM芯片。你需要使用一些方法将代码放在芯片上。怎么做，要根据"目标"硬件和工具来定。
一种流行的方法是把Flash或EPROM芯片插入EPROM或Flash烧制器。这将把你的程序"烧"（存）入芯片。然后，把芯片插入你的目标板的插座，打开电源。这个方法需要板上配有插座，但有些设备是不能配插座的。
另一个方法是通过一个JTAG界面。一些芯片有JTAG界面可以用来对芯片进行编程。这是最方便的方法。芯片可以永远被焊在主板上，一个小电缆从板上的JTAG连接器，通常是一个PC卡，联到JTAG界面。下面是PC运行JTAG界面所需的一些惯用程序。这个设备还可以用来小量生产。
稳定性
对大多数微处理器来说，Linux非常好。移植到新微处理器家族的Linux内核运行起来与原来的微处理器一样稳定。它经常被移植到一个或多个特定的主板上。这些板包括特定的外围设备和CPU。幸运的是，许多代码是与处理器的特性不相关的，所以移植集中在处理器的差异上，其中大多数是在内存管理和中断控制领域。一旦成功移植，它们就非常稳定。
引导策略广泛依赖于硬件要求，而且你必须有计划地做一些定制的工作。设备驱动程序更加混乱：有些稳定有些不稳定。而且选择很有限；一旦你离开了通用的PC平台，你需要自己编写。幸运的是，周围有许多驱动程序，你可能可以找到一个与你的需求相近的修改一下。这种驱动程序界面已定义好。许多类似的驱动程序都非常相近，所以把磁盘、网络或一系列的端口驱动程序从一个设备移植到另一个设备上通常并不难。你可能发现许多驱动程序都写得很好，很容易理解，但你还是要准备一本关于内核结构的书在手头。
总之，这些操作系统和Linux的问题在于对工作过程微小之处的误解，而不在于代码的难度或基本的设计错误。任何操作系统都有很多争论不休的故事，这里不需要重复。Linux的优势在于源代码是公开、注释清晰和文档齐全的。这样，你就可以控制和处理所出现的任何问题。
三、嵌入式Linux操作系统将如何发展
嵌入式Linux的确有它的缺陷。比如，虽然它并不比某些竞争对手差多少，但它的确是个需要占用存储器的操作系统。这可以通过减少一些不必要的功能来弥补，但这可能会花很长的时间，而且如果不仔细的话，还可能带来很大的困扰。许多Linux的应用程序都要用到虚拟内存，在许多嵌入式系统中，是没有价值的，所以不要以为一个没有磁盘的Linux嵌入式系统可以运行任何Linux应用程序。
综上所述，Linux嵌入式操作系统在嵌入式系统中的应用才刚刚开始，但它所具有的技术优势和独特的运开发模式给业界以新异，有理由相信在不久的将来Linux嵌入式操作系统一定会成为绽放在操作系统中美丽的奇葩。
from：http://staff.ustc.edu.cn/~wangzhuo/rtlinux.htm
RT linux就是realtime linux的简写啦
它和mini linux，LRP,embedded linux之类的东东是分不开的，偶的兴趣就在于把linux小型化，实时化，小到一张软盘，能够用flash disk装进去，(烧进EEPROM里面，偶曾经冥思苦想了好久，觉得没有多大的必要了，除非linux机顶盒之类的)又具有网络的功能，linux的功能它都能加上去，当然啦，它的体重就会增加的了:)而且，linux的内核版本升级的时候，又不用去管它，呵呵，那是最好不过了！
RTOS现在都已经发展到第三代啦，各家都在讨论如何统一BSP（也就是那个所谓的BIOS或者说驱动程序的概念）的接口和API的接口，还有，在增加WEB server的功能和java的功能，说白了，就是希望象Windows那么好啊:)所以呢，我当时听说他们在搞这些东东，就想，咳！那些东西在linux里面不早就有了吗？！而且呢，以前偶一直迷信“实时”，后来想想，网络需要实时吗？丢一点东西就丢一点呗，嘻嘻，所以呢，需要hard relatime的地方并不是很多的啦。
我的想法是：采用RT linux的办法实现硬实时特性,同时也获得了linux的强大功能以及升级、BUG修改的自动支持；采用LRP的办法实现对linux的裁减从而小型化，同时也获得了强大的网络功能，实现了包括OSPF，VPN，RADIUS等等网络特性。
我真的期待一个那样的超级小怪物出现！！！（在国外，这些工作都有感兴趣的人们在做着。。。）那样子，cisco的低端路由器就呜呼了耶:)CISCO的IOS会不会和微软害怕linux一样害怕我们的小怪物？:)
What is RTLinux?
Rtlinux is an operating system that allows real-time control of machinery and data from a Linux environment. RTLinux is a hard real time operating system with guaranteed response times (up to hardware limits). Many "real-time" operating systems offer " typical" response times instead. RTLinux was originally developed at the New Mexico Institute of Technology.
Response times are close to hardware limits. On a modest, reasonably configured, x86 PC a RTLinux interrupt handler will run under 10 microseconds from the moment the interrupt was asserted and a RTLinux periodic task will run worst case within 30 microseconds of its scheduled time. On better hardware, these times shrink. Of course, if you insist on bad hardware, you can make things run worse.
Programs are developed in a standard Linux environment with additional capability of connecting to real-time tasks. For example, it is easy to write a Perl script that displays data in Xwindows, responds to commands delivered over a network, and collects data from a real-time task.
RTlinux is currently used for telecommunications, robotics, video editing, and data acquisition and other applications in the field and in R&D labs.
License is an open-source license with no royalties or fees. RTLinux is an open-source kernel, released under the LGPL. The source is freely distributed.
Linux as an Embedded Operating System
by Jerry Epplin
Does Linux have potential as an embedded operating system? Should vendors of high-end commercial RTOSs quake in their Bruno Maglis? This article assesses Linux's features, robustness, limitations, and most importantly, its real-time facilities.
The increasing use of PC hardware is one of the most important developments in high-end embedded systems in recent years. Hardware costs of high-end systems have dropped dramatically as a result of this trend, making feasible some projects which previously would not have been done because of the high cost of non-PC-based embedded hardware. But software choices for the embedded PC platform are not nearly as attractive as the hardware. You can choose DOS, with its well-known limitations; Microsoft Windows, with its lack of real-time capability; or one of the high-end real-time operating systems, which are expensive, proprietary, and mostly non-portable. The Linux operating system presents an attractive alternative to these options, having none of the above disadvantages. Previously used almost exclusively on the desktop computers of Unix enthusiasts with too much free time, Linux has evolved into a sophisticated and reliable operating system that must be taken seriously. One of the most recent developments has been the addition of real-time facilities to the OS, which completes the transition of Linux from a hobbyist's toy to a valuable tool to be used by embedded system designers. These real-time facilities are not yet as sophisticated as those available in high-end RTOSs, and Linux will never be appropriate for systems that must minimize RAM and ROM use. However, for many applications, the advantages of Linux overcome these drawbacks.
The advantages of using PC hardware in embedded systems are by now well known. In contrast to much hardware developed specifically for the embedded market, PC hardware is mass-produced, easily available, and cheap. You can expect interface boards such as analog and digital I/O boards, network interfaces, and image acquisition and processing boards to cost more than twice as much when designed for the VME bus as for one of the PC buses. And with the increasing use of the higher-performance PCI bus, throughput no longer suffers when a PC platform is used.
But no comparable revolution in operating system capabilities has occurred. Along with a demand for lower hardware costs, high-end embedded systems have required much more sophisticated capabilities, such as graphical user interfaces and networking capabilities. Many high-end RTOS vendors have provided these capabilities, often as options which command higher prices. Microsoft Windows also provides them, but it lacks the real-time capabilities most embedded systems require. One could probably
piece together a system based on DOS using separate third-party tools for each component, but the exercise would be frustrating and support provided for developing such a system would be non-existent. What is needed is an OS for which support is available-one that is cheap, mature, and provides the features that high-end embedded systems must have.
The Linux operating system has recently begun to attract attention from the mainstream press for many of these very reasons.1 Many desktop PC users are attracted to its features and robustness, and to the fact that it is available for only the cost of downloading it via FTP. It comes with a full complement of the features and development tools which Unix users have come to expect. Nearly all Unix system and application software has been ported to Linux. TCP/IP-based network protocols are
supplied. Internet client and server software is provided. X Windows is provided, and one can choose among several window managers. Good compilers for C, C++, Java, and other languages are available. Users find these features to be more mature, complete, and easy to use than those provided by Windows. Many companies have at least one Linux enthusiast who, when presented with a problem difficult or impossible to solve with Windows (for example, setting up a PC as a dial-in Web server), responds with "Well, if we just had Linux. . . ."
Now, whether Bill Gates has anything to worry about is a subject for debate in some other magazine. What is important is that Linux, which is owned by, and therefore supported by, no one company, is starting to be accepted by desktop computer users, many of whom can't be considered computer nerds. What makes this possible now is both the maturity of the OS and the increasing prevalence of the Internet over the last few years. Linux users who encounter problems can draw on the expertise of thousands of on-line users through Internet newsgroups and mailing lists. Any problem you encounter has certainly been encountered before by one of these users, and most are willing to help. In my experience, you can usually solve problems more quickly by using Internet resources than by relying on RTOS tech support departments. You may have to sort through a dozen uninformed responses from other newsgroup participants, but at least one answer is likely to be helpful. In contrast, you get only one answer from a tech support department. If it isn't correct, you have to start the whole process again. In addition, companies dedicated to providing support for Linux have begun to appear, presenting an option for those users who feel more comfortable dealing with more conventional technical support arrangements. Also, all of Linux is provided with source code, providing the means to answer even the most difficult questions.
Some embedded system designers will find Linux usable just as it stands. It presents a good alternative to Windows or DOS for applications without real-time requirements or for those with real-time requirements that are met with dedicated hardware or a coprocessor. But such applications are rare. What is needed is a way to implement a real-time system using Linux, and sufficient progress has been made on this front to allow many high-end embedded applications to be implemented. Two general approaches to real-time Linux are being pursued, which I'll call the POSIX approach
and the low-level approach.
POSIX and Linux
POSIX is a movement to standardize the features and interfaces that a Unix-like operating system must have. The idea is to improve the portability of software written for Unix, making the jobs of Unix programmers much easier. Some real-time extensions, known as POSIX.1b or IEEE 1003.1b, have been added to the standard. These extensions include facilities such as semaphores, memory locking, clocks and timers, message queues, and preemptive prioritized scheduling.
Using POSIX as a basis for standardizing real-time operating system features has been rightly criticized.2 The standard is big, clumsy, and bloated with features appropriate for desktop Unix workstations but unhelpful in embedded systems. The standards-making body is dominated by workstation manufacturers unwilling to make concessions to vendors and users of RTOSs. Also, the POSIX system calls reflect the arcane and cumbersome syntax of Unix system calls, so that an operation that takes
one or two calls in VxWorks or pSOS+ may take close to a dozen POSIX calls. Unix programmers are accustomed to this annoyance, but embedded system programmers find it frustrating.
A number of Linux developers are working on implementing POSIX.1b features in Linux.3 This movement has already seen some success, and the effort continues. The POSIX memory-locking facilities and the functions which determine the scheduling algorithm have been implemented. On the other hand, the timer functions and POSIX.1b signals are not yet complete. And perhaps most damaging, the POSIX semaphore and message queue features, which are essential for any serious RTOS, are not yet available.
One promising development for POSIX-based Linux is the implementation of POSIX threads, which are defined in POSIX.1c (or IEEE 1003.1c). Within a process you can have multiple threads, all sharing the same address space. This matches quite well the familiar embedded system concept of a task. Some implementations of POSIX threads are already available for Linux.
While the POSIX approach to implementing a real-time Linux holds some promise, presently and for the foreseeable future only the "softest" real-time applications can be implemented using the POSIX.1b functions. The fundamental problem faced when attempting to graft POSIX.1b functionality onto Linux is the fact that Linux has a non-preemtable kernel. So implementing "hard" real-time features without radically
changing the design of the kernel would seem to be impossible. However, at least one group has succeeded in accomplishing just that.
Low-level Approach to Real-time Linux
Of more immediate interest than the POSIX-based movement are the efforts to implement a "hard" real-time Linux, the most promising of which may be the Real-Time Linux (RT-Linux) project at the New Mexico Institute of Mining and Technology. Observing that Linux is an operating system designed by desktop computer users, researchers there concluded it would be fruitless to try to graft real-time functionality onto an OS designed for timesharing.4 Instead they implemented a simple real-time kernel underneath the operating system, with Linux itself running as just one task within that kernel. Linux runs at the lowest priority, and it can be preempted at any time by higher-priority tasks.
The design philosophy behind RT-Linux was to minimize the changes made to Linux itself, providing only the essentials necessary for implementing real-time applications.5 Minimizing the disruption to Linux makes it easy to port RT-Linux to new versions of Linux as they appear. As a result, RT-Linux relies on Linux itself to provide almost all services needed, with RT-Linux providing only low-level task creation, installation of
interrupt service routines, and queues for communication among the low-level tasks, ISRs, and Linux processes.
One result of this design is that an RT-Linux application can be thought of as having two domains-the real-time and the non-real-time. Functions placed in the real-time domain can meet their real-time requirements, but they must be simple because the resources available to them are quite limited. On the other hand, non-real-time functionality has the full range of Linux resources available for use, but cannot have any real-time requirements. Facilities for communication between the two domains are
provided. But before using RT-Linux, an embedded system designer has to be sure that all of the needed functionality could fit into one of the two domains. Using RT-Linux does not magically make pre-existing Linux functionality real-time. Suppose, for example, a designer has a Linux driver for a serial port, and wants to toggle a parallel output line (using a real-time task) within some fixed time after receiving a byte
sequence on the serial port. The Linux serial driver can't be used because it resides in the non-real-time domain, and you can't predict when the serial driver would awaken the real-time task driving the parallel output line to perform its work. Thus, both the serial and the parallel ports would have to be done in the real-time domain, which
would require redesigning the serial driver.
The RT-Linux facilities for task handling are basic. There is rt_task_init(), which creates and starts a task. The stack size and priority can be specified. Linux itself is run as a real-time task with the lowest priority. The task is set up to run at periodic intervals by rt_task_make_periodic(). The rt_task_wait() facility blocks the calling
task. The tasks are run using a simple preemptive scheduler.
The primary means of communication between the real-time tasks and the Linux processes is the FIFO. The rtf_create() facility creates a FIFO of a desired size. Data is enqueued onto the FIFO by rtf_put(), returning an error if the FIFO is full. Similarly, rtf_get() dequeues data from the FIFO, returning an error if the FIFO is empty.
The most obvious use for this FIFO scheme is data streaming. In a data acquisition application, for example, a real-time task could be set up using rt_task_init() and rt_task_make_periodic() to acquire samples from an I/O board at fixed intervals. This task would send its data to a Linux process using rtf_put(). The Linux process would be in a loop, reading data from the FIFO and perhaps writing the data to disk,sending it over a network, or displaying it in an X window. The FIFO would serve as a buffer, so the Linux process could operate without real-time constraints.
Implementing data streaming systems appears to have been the primary motivation of the RT-Linux designers. But the FIFO scheme provides a pretty good way of implementing semaphores. A binary semaphore can be implemented by creating a FIFO of size one. The "give" operation (also known as "V" or "signal") is then simply an rtf_put() of size one, with the content of the data insignificant and the error return ignored. The "take" operation (or "P" or "wait") is an rtf_get() with size one. A
counting semaphore can be implemented simply by creating the FIFO with a size large enough to accommodate the expected number of "give" operations. So the FIFO mechanism provides most of the functionality needed for task synchronization in real-time applications. The current implementation lacks some functionality to which RTOS users are accustomed, such as priority inheritance (to prevent priority inversion)
and task deletion safety. But careful design can almost always prevent the problems these features are intended to address. In addition, although the FIFO operations can be set up to block when data is not available (when reading the FIFO) or when space is not available (when writing), the syntax for doing so is rather cumbersome, as blocking capability appears not to have been a priority of the designers. Nevertheless, at least one effort is under way to provide an easy syntax for blocking operations on FIFOs.6 This effort also implements timeouts when blocking, an important feature in many embedded applications. The simple, open design of RT-Linux allows users to implement such additional favorite features quite easily.
An interesting aspect of RT-Linux is the way by which the designers made the Linux kernel preemptable. Linux, like most Unix-type operating systems, has a kernel that disables interrupts for long periods of time. This is, of course, exactly what makes Linux a non-real-time OS. Two approaches to solving this problem might be taken. The first is to redesign the kernel so that it can be preempted. But the Linux kernel is
big, complex, and subject to frequent modification. It was designed by programmers with little interest in real-time applications in mind. Thus, imposing a real-time mindset onto the existing code would be impractical. And even if done once, the modifications would have to be reexamined and redone every time a new version of Linux was released-also impractical. The RT-Linux designers instead took a different approach to making Linux preemptable. They divide the interrupts into two groups: those under
the control of Linux, and those controlled by RT-Linux. RT-Linux interrupts, like RT-Linux tasks, are restricted in what they can do; they cannot make Linux calls. So there is no reason that they can't interrupt the Linux kernel. After all, they can't interfere with anything in the kernel if they don't change anything in it. On the other hand, Linux interrupts can't be allowed to interrupt the kernel. So RT-Linux implements a virtual interrupt scheme in which Linux itself is never allowed to disable interrupts. Linux uses "cli" and "sti" macros to implement disabling and enabling interrupts. In standard Linux, these macros simply execute the corresponding x86 instructions. RT-Linux modifies these macros so that instead of disabling interrupts when a "cli" is executed, it simply reroutes the interrupt to some RT-Linux code. If the interrupt is an RT-Linux interrupt, it is allowed to continue. If it is a Linux interrupt, a flag is set. When a "sti" is executed, any pending Linux interrupts are executed. In this way, Linux still can't interrupt itself, but RT-Linux can interrupt it.
RT-Linux is simple, providing only a bare minimum of functionality necessary for implementing a real-time system. But this simplicity is to the system designer's benefit. You want to implement the bulk of the application in Linux processes because Linux itself is solid, stable, and popular with a lot of desktop users-so you know you can get help if you have trouble. Real-time tasks should have only the functionality necessary
to perform real-time I/O and pass data to and from the Linux processes. The simplicity of RT-Linux has two advantages: first, its very simplicity makes it less likely that it will be buggy; and second, if you do find a bug, it's likely to be easy to find and fix. These factors are important. Because real-time systems are a minuscule portion of Linux applications, the amount of help you can find for developing code using RT-Linux is
certain to be low. So a feature-rich RT-Linux is not necessarily something to be desired. The functionality now implemented is also sufficient for the vast majority of real-time systems if properly used.
Linux is clearly not the best platform for all embedded PCs. Because of its size, a full GUI-based system must be implemented as a disk-based system or one connected to a network from which it can boot. Still, a large and growing number of embedded applications can run with a disk and need the GUI and networking features that are built into Linux. For example, many medical devices must have attractive user interfaces to be competitive, and industrial machine controls must have both GUIs and
networking. Patching together such a system with DOS or a low-end RTOS is
impractical. Inflating the selling price with a $700 royalty paid to a high-end RTOS vendor is out of the question. Linux provides a way to incorporate these features for free. And not only are they free, they are usually more up-to-date than those supplied by RTOS vendors, who usually provide features well after they are available on desktop OSs.
In addition to the recent developments that make Linux usable in disk-based embedded systems, some progress has also been made in making it bootable from EPROM. By installing only those components that are necessary for the application, in many cases a diskless system can be put together using Linux. Thus, for example, at least one full system including Linux networking (but without X Windows) has been put together using only 2.7MB of EPROM for Linux.7 So, practical stand-alone diskless embedded systems can now be developed using Linux. In addition, the ability to boot Linux from a network is well established. Thus, a system that resides on a network can boot the entire system, including X Windows, from a disk somewhere on that network.
The Future
Linux follows the GNU movement, which produces high quality software through the combined efforts of thousands of programmers. GNU, like Linux, was ridiculed early on as the hobby of software anarchists and nerds with too much free time. But by now all the skeptics have to admit that some world-class software has been produced by GNU, notably the gcc and g++ compilers. These are competitive with the finest commercial compilers around, and even high-end RTOS products like VxWorks and LynxOS use them. What happened to RTOS compilers is likely to happen to the OSs
themselves. RTOS products based on Linux will begin to appear, with vendors emphasizing their added real-time features, as well as their support. The result will be a bonanza for developers of high-end embedded systems, with even the cheapest RTOS products providing more features than are currently available from the most expensive products.
Jerry Epplin is an embedded software consultant in St. Louis, MO. He designs software primarily for medical and industrial device manufacturers. He can be reached via e-mail at JerryEpplin@worldnet.att.net.
References
1. Mohr, Jim, "The State of Linux," Byte, January 1997.
2. Joseph, Moses, "Is POSIX Appropriate for Embedded Systems?," Embedded
Systems Programming, July 1995, p. 90.
3. Kuhn, Markus, "A Vision for Linux 2.2-POSIX.1b Compatibility and Real-Time
Support," ftp://informatik.uni-erlangen.de/local/cip/ mskuhn/misc/linux-posix.1b,
December 1996.
4. See http://luz.cs.nmt.edu/~rtlinux
5. Yodaiken, Victor, and Michael Barabanov, "A Real-Time Linux,"
ftp://luz.cs.nmt.edu/pub/rtlinux/papers/usenix.ps.gz.
6. See http://stereotaxis.wustl.edu/ ~jerry.
7. Bennett, Dave, "Booting Linux from EPROM," Linux Journal, January 1997.
SIDEBARS
Linux Resources
Because of the increasing popularity of Linux as a desktop operating system, information is easy to find on the Internet. The Linux Documentation Project, at http://sunsite.unc.edu/mdw/linux.html, is a good place to start. The site contains plenty of general information, as well as links to the commercial distributors of Linux. Because it is "free" software, controlled by no one organization, the distribution of
Linux is somewhat haphazard. Any company is free to download Linux, add some value to it, and sell it to potential users. In practice, companies have added value by improving ease of installation and by placing the software onto a CD-ROM. As a result, distributions of Linux differ primarily in their installation procedures. The best known distributions are Slackware (available from various distributors), Red Hat (http://www.redhat.com), and Debian (http://www.debian.org). Each has its own
advantages, but most embedded system designers are primarily interested in ease of installation-by that standard, the Red Hat distribution is probably currently the most attractive.
Any of the distributions can be downloaded via FTP free of charge, but because of the large size of Linux, the exercise would be painful even for a user with a high-speed Internet connection; dialup users shouldn't even consider it. CD-ROMs containing everything needed are easily and inexpensively obtained, usually costing less than $50. Further confusing the issue is the fact that anyone can take an entire distribution, place
it on CD-ROM, and sell it. For example, InfoMagic (http://www.infomagic.com) puts the Slackware, Red Hat, and Debian distributions on a set of CD-ROMs and sells it, leaving it to the user to decide which distribution to use. Other vendors provide similar products-see the Linux Documentation Project Web site for a list.
This system of distribution, although chaotic, works well. Users must simply remember to obtain tech support from the vendor from whom they bought their CD-ROM. If, for example, you install the Red Hat distribution from an InfoMagic CD-ROM, you must get support from InfoMagic rather than Red Hat. Tech support is generally available
from the CD-ROM manufacturer, but is typically limited to help with installation problems. For help on more advanced issues, dozens of newsgroups, and perhaps hundreds of mailing lists, are active with discussions of every aspect of Linux. In addition, many companies provide fee-based support and consulting services. For example, Yggdrasil Computing, which provides its own Linux distribution, also provides support for other distributions on a fee basis. A list of companies that provide support and consulting services can be found at
http://www.cyrius.com/tbm/Consultants-HOWTO/Consultants-HOWTO.html.
The recent improvements in ease of Linux installation and use are real, but a word of warning is appropriate for those embedded system designers accustomed to using Windows as a development platform. It is possible to install and use Windows for cross-development without ever learning anything significant about that operating system. This is not true of Linux-by the time you have installed Linux and are using it for developing code, you will know a lot about the operating system and the hardware you are using. Linux is still an OS for enthusiasts; to do any significant work with it you must first spend some time learning it. The learning curve is not at all daunting (especially for current Unix users), but one should expect to invest some time before getting results from Linux.
RT-Linux
Information on obtaining and using Real-Time Linux is available at
http://luz.cs.nmt.edu/~rtlinux. Some papers describing the design of and philosophy behind the effort can be obtained there, and are well worth reading. As of this writing, the latest version available is 0.5; it can be obtained via FTP directly from the Web site. Installation is usually straightforward-install Linux and then apply the RT-Linux patch. Also included at the Web site are links to a few projects that use RT-Linux.
One of the most recent and welcome developments is the start of an RT-Linux mailing list. The developers of the system, as well as other experienced RT-Linux users, frequently participate, providing guidance for newcomers and discussing potential future enhancements. Subscribing to this list is a must for anyone using or seriously considering RT-Linux for an application. To subscribe, send mail to majordomo@luz.cs.nmt.edu with "subscribe rtl" in the body of the message.
Return to Embedded.com
Send comments to: Webmaster
Copyright ?1998 Miller Freeman, Inc.,
a United News Media company.
Linux as an Embedded Operating System
by Jerry Epplin
Does Linux have potential as an embedded operating system? Should vendors of high-end commercial RTOSs quake in their Bruno Maglis? This article assesses Linux's features, robustness, limitations, and most importantly, its real-time facilities.
The increasing use of PC hardware is one of the most important developments in high-end embedded systems in recent years. Hardware costs of high-end systems have dropped dramatically as a result of this trend, making feasible some projects which previously would not have been done because of the high cost of non-PC-based embedded hardware. But software choices for the embedded PC platform are not nearly as attractive as the hardware. You can choose DOS, with its well-known limitations; Microsoft Windows, with its lack of real-time capability; or one of the high-end real-time operating systems, which are expensive, proprietary, and mostly non-portable. The Linux operating system presents an attractive alternative to these options, having none of the above disadvantages. Previously used almost exclusively on the desktop computers of Unix enthusiasts with too much free time, Linux has evolved into a sophisticated and reliable operating system that must be taken seriously. One of the most recent developments has been the addition of real-time facilities to the OS, which completes the transition of Linux from a hobbyist's toy to a valuable tool to be used by embedded system designers. These real-time facilities are not yet as sophisticated as those available in high-end RTOSs, and Linux will never be appropriate for systems that must minimize RAM and ROM use. However, for many applications, the advantages of Linux overcome these drawbacks.
The advantages of using PC hardware in embedded systems are by now well known. In contrast to much hardware developed specifically for the embedded market, PC hardware is mass-produced, easily available, and cheap. You can expect interface boards such as analog and digital I/O boards, network interfaces, and image acquisition and processing boards to cost more than twice as much when designed for the VME bus as for one of the PC buses. And with the increasing use of the higher-performance PCI bus, throughput no longer suffers when a PC platform is used.
But no comparable revolution in operating system capabilities has occurred. Along with a demand for lower hardware costs, high-end embedded systems have required much more sophisticated capabilities, such as graphical user interfaces and networking capabilities. Many high-end RTOS vendors have provided these capabilities, often as options which command higher prices. Microsoft Windows also provides them, but it lacks the real-time capabilities most embedded systems require. One could probably
piece together a system based on DOS using separate third-party tools for each component, but the exercise would be frustrating and support provided for developing such a system would be non-existent. What is needed is an OS for which support is available-one that is cheap, mature, and provides the features that high-end embedded systems must have.
The Linux operating system has recently begun to attract attention from the mainstream press for many of these very reasons.1 Many desktop PC users are attracted to its features and robustness, and to the fact that it is available for only the cost of downloading it via FTP. It comes with a full complement of the features and development tools which Unix users have come to expect. Nearly all Unix system and application software has been ported to Linux. TCP/IP-based network protocols are
supplied. Internet client and server software is provided. X Windows is provided, and one can choose among several window managers. Good compilers for C, C++, Java, and other languages are available. Users find these features to be more mature, complete, and easy to use than those provided by Windows. Many companies have at least one Linux enthusiast who, when presented with a problem difficult or impossible to solve with Windows (for example, setting up a PC as a dial-in Web server), responds with "Well, if we just had Linux. . . ."
Now, whether Bill Gates has anything to worry about is a subject for debate in some other magazine. What is important is that Linux, which is owned by, and therefore supported by, no one company, is starting to be accepted by desktop computer users, many of whom can't be considered computer nerds. What makes this possible now is both the maturity of the OS and the increasing prevalence of the Internet over the last few years. Linux users who encounter problems can draw on the expertise of thousands of on-line users through Internet newsgroups and mailing lists. Any problem you encounter has certainly been encountered before by one of these users, and most are willing to help. In my experience, you can usually solve problems more quickly by using Internet resources than by relying on RTOS tech support departments. You may have to sort through a dozen uninformed responses from other newsgroup participants, but at least one answer is likely to be helpful. In contrast, you get only one answer from a tech support department. If it isn't correct, you have to start the whole process again. In addition, companies dedicated to providing support for Linux have begun to appear, presenting an option for those users who feel more comfortable dealing with more conventional technical support arrangements. Also, all of Linux is provided with source code, providing the means to answer even the most difficult questions.
Some embedded system designers will find Linux usable just as it stands. It presents a good alternative to Windows or DOS for applications without real-time requirements or for those with real-time requirements that are met with dedicated hardware or a coprocessor. But such applications are rare. What is needed is a way to implement a real-time system using Linux, and sufficient progress has been made on this front to allow many high-end embedded applications to be implemented. Two general approaches to real-time Linux are being pursued, which I'll call the POSIX approach
and the low-level approach.
POSIX and Linux
POSIX is a movement to standardize the features and interfaces that a Unix-like operating system must have. The idea is to improve the portability of software written for Unix, making the jobs of Unix programmers much easier. Some real-time extensions, known as POSIX.1b or IEEE 1003.1b, have been added to the standard. These extensions include facilities such as semaphores, memory locking, clocks and timers, message queues, and preemptive prioritized scheduling.
Using POSIX as a basis for standardizing real-time operating system features has been rightly criticized.2 The standard is big, clumsy, and bloated with features appropriate for desktop Unix workstations but unhelpful in embedded systems. The standards-making body is dominated by workstation manufacturers unwilling to make concessions to vendors and users of RTOSs. Also, the POSIX system calls reflect the arcane and cumbersome syntax of Unix system calls, so that an operation that takes
one or two calls in VxWorks or pSOS+ may take close to a dozen POSIX calls. Unix programmers are accustomed to this annoyance, but embedded system programmers find it frustrating.
A number of Linux developers are working on implementing POSIX.1b features in Linux.3 This movement has already seen some success, and the effort continues. The POSIX memory-locking facilities and the functions which determine the scheduling algorithm have been implemented. On the other hand, the timer functions and POSIX.1b signals are not yet complete. And perhaps most damaging, the POSIX semaphore and message queue features, which are essential for any serious RTOS, are not yet available.
One promising development for POSIX-based Linux is the implementation of POSIX threads, which are defined in POSIX.1c (or IEEE 1003.1c). Within a process you can have multiple threads, all sharing the same address space. This matches quite well the familiar embedded system concept of a task. Some implementations of POSIX threads are already available for Linux.
While the POSIX approach to implementing a real-time Linux holds some promise, presently and for the foreseeable future only the "softest" real-time applications can be implemented using the POSIX.1b functions. The fundamental problem faced when attempting to graft POSIX.1b functionality onto Linux is the fact that Linux has a non-preemtable kernel. So implementing "hard" real-time features without radically
changing the design of the kernel would seem to be impossible. However, at least one group has succeeded in accomplishing just that.
Low-level Approach to Real-time Linux
Of more immediate interest than the POSIX-based movement are the efforts to implement a "hard" real-time Linux, the most promising of which may be the Real-Time Linux (RT-Linux) project at the New Mexico Institute of Mining and Technology. Observing that Linux is an operating system designed by desktop computer users, researchers there concluded it would be fruitless to try to graft real-time functionality onto an OS designed for timesharing.4 Instead they implemented a simple real-time kernel underneath the operating system, with Linux itself running as just one task within that kernel. Linux runs at the lowest priority, and it can be preempted at any time by higher-priority tasks.
The design philosophy behind RT-Linux was to minimize the changes made to Linux itself, providing only the essentials necessary for implementing real-time applications.5 Minimizing the disruption to Linux makes it easy to port RT-Linux to new versions of Linux as they appear. As a result, RT-Linux relies on Linux itself to provide almost all services needed, with RT-Linux providing only low-level task creation, installation of
interrupt service routines, and queues for communication among the low-level tasks, ISRs, and Linux processes.
One result of this design is that an RT-Linux application can be thought of as having two domains-the real-time and the non-real-time. Functions placed in the real-time domain can meet their real-time requirements, but they must be simple because the resources available to them are quite limited. On the other hand, non-real-time functionality has the full range of Linux resources available for use, but cannot have any real-time requirements. Facilities for communication between the two domains are
provided. But before using RT-Linux, an embedded system designer has to be sure that all of the needed functionality could fit into one of the two domains. Using RT-Linux does not magically make pre-existing Linux functionality real-time. Suppose, for example, a designer has a Linux driver for a serial port, and wants to toggle a parallel output line (using a real-time task) within some fixed time after receiving a byte
sequence on the serial port. The Linux serial driver can't be used because it resides in the non-real-time domain, and you can't predict when the serial driver would awaken the real-time task driving the parallel output line to perform its work. Thus, both the serial and the parallel ports would have to be done in the real-time domain, which
would require redesigning the serial driver.
The RT-Linux facilities for task handling are basic. There is rt_task_init(), which creates and starts a task. The stack size and priority can be specified. Linux itself is run as a real-time task with the lowest priority. The task is set up to run at periodic intervals by rt_task_make_periodic(). The rt_task_wait() facility blocks the calling
task. The tasks are run using a simple preemptive scheduler.
The primary means of communication between the real-time tasks and the Linux processes is the FIFO. The rtf_create() facility creates a FIFO of a desired size. Data is enqueued onto the FIFO by rtf_put(), returning an error if the FIFO is full. Similarly, rtf_get() dequeues data from the FIFO, returning an error if the FIFO is empty.
The most obvious use for this FIFO scheme is data streaming. In a data acquisition application, for example, a real-time task could be set up using rt_task_init() and rt_task_make_periodic() to acquire samples from an I/O board at fixed intervals. This task would send its data to a Linux process using rtf_put(). The Linux process would be in a loop, reading data from the FIFO and perhaps writing the data to disk,sending it over a network, or displaying it in an X window. The FIFO would serve as a buffer, so the Linux process could operate without real-time constraints.
Implementing data streaming systems appears to have been the primary motivation of the RT-Linux designers. But the FIFO scheme provides a pretty good way of implementing semaphores. A binary semaphore can be implemented by creating a FIFO of size one. The "give" operation (also known as "V" or "signal") is then simply an rtf_put() of size one, with the content of the data insignificant and the error return ignored. The "take" operation (or "P" or "wait") is an rtf_get() with size one. A
counting semaphore can be implemented simply by creating the FIFO with a size large enough to accommodate the expected number of "give" operations. So the FIFO mechanism provides most of the functionality needed for task synchronization in real-time applications. The current implementation lacks some functionality to which RTOS users are accustomed, such as priority inheritance (to prevent priority inversion)
and task deletion safety. But careful design can almost always prevent the problems these features are intended to address. In addition, although the FIFO operations can be set up to block when data is not available (when reading the FIFO) or when space is not available (when writing), the syntax for doing so is rather cumbersome, as blocking capability appears not to have been a priority of the designers. Nevertheless, at least one effort is under way to provide an easy syntax for blocking operations on FIFOs.6 This effort also implements timeouts when blocking, an important feature in many embedded applications. The simple, open design of RT-Linux allows users to implement such additional favorite features quite easily.
An interesting aspect of RT-Linux is the way by which the designers made the Linux kernel preemptable. Linux, like most Unix-type operating systems, has a kernel that disables interrupts for long periods of time. This is, of course, exactly what makes Linux a non-real-time OS. Two approaches to solving this problem might be taken. The first is to redesign the kernel so that it can be preempted. But the Linux kernel is
big, complex, and subject to frequent modification. It was designed by programmers with little interest in real-time applications in mind. Thus, imposing a real-time mindset onto the existing code would be impractical. And even if done once, the modifications would have to be reexamined and redone every time a new version of Linux was released-also impractical. The RT-Linux designers instead took a different approach to making Linux preemptable. They divide the interrupts into two groups: those under
the control of Linux, and those controlled by RT-Linux. RT-Linux interrupts, like RT-Linux tasks, are restricted in what they can do; they cannot make Linux calls. So there is no reason that they can't interrupt the Linux kernel. After all, they can't interfere with anything in the kernel if they don't change anything in it. On the other hand, Linux interrupts can't be allowed to interrupt the kernel. So RT-Linux implements a virtual interrupt scheme in which Linux itself is never allowed to disable interrupts. Linux uses "cli" and "sti" macros to implement disabling and enabling interrupts. In standard Linux, these macros simply execute the corresponding x86 instructions. RT-Linux modifies these macros so that instead of disabling interrupts when a "cli" is executed, it simply reroutes the interrupt to some RT-Linux code. If the interrupt is an RT-Linux interrupt, it is allowed to continue. If it is a Linux interrupt, a flag is set. When a "sti" is executed, any pending Linux interrupts are executed. In this way, Linux still can't interrupt itself, but RT-Linux can interrupt it.
RT-Linux is simple, providing only a bare minimum of functionality necessary for implementing a real-time system. But this simplicity is to the system designer's benefit. You want to implement the bulk of the application in Linux processes because Linux itself is solid, stable, and popular with a lot of desktop users-so you know you can get help if you have trouble. Real-time tasks should have only the functionality necessary
to perform real-time I/O and pass data to and from the Linux processes. The simplicity of RT-Linux has two advantages: first, its very simplicity makes it less likely that it will be buggy; and second, if you do find a bug, it's likely to be easy to find and fix. These factors are important. Because real-time systems are a minuscule portion of Linux applications, the amount of help you can find for developing code using RT-Linux is
certain to be low. So a feature-rich RT-Linux is not necessarily something to be desired. The functionality now implemented is also sufficient for the vast majority of real-time systems if properly used.
Linux is clearly not the best platform for all embedded PCs. Because of its size, a full GUI-based system must be implemented as a disk-based system or one connected to a network from which it can boot. Still, a large and growing number of embedded applications can run with a disk and need the GUI and networking features that are built into Linux. For example, many medical devices must have attractive user interfaces to be competitive, and industrial machine controls must have both GUIs and
networking. Patching together such a system with DOS or a low-end RTOS is
impractical. Inflating the selling price with a $700 royalty paid to a high-end RTOS vendor is out of the question. Linux provides a way to incorporate these features for free. And not only are they free, they are usually more up-to-date than those supplied by RTOS vendors, who usually provide features well after they are available on desktop OSs.
In addition to the recent developments that make Linux usable in disk-based embedded systems, some progress has also been made in making it bootable from EPROM. By installing only those components that are necessary for the application, in many cases a diskless system can be put together using Linux. Thus, for example, at least one full system including Linux networking (but without X Windows) has been put together using only 2.7MB of EPROM for Linux.7 So, practical stand-alone diskless embedded systems can now be developed using Linux. In addition, the ability to boot Linux from a network is well established. Thus, a system that resides on a network can boot the entire system, including X Windows, from a disk somewhere on that network.
The Future
Linux follows the GNU movement, which produces high quality software through the combined efforts of thousands of programmers. GNU, like Linux, was ridiculed early on as the hobby of software anarchists and nerds with too much free time. But by now all the skeptics have to admit that some world-class software has been produced by GNU, notably the gcc and g++ compilers. These are competitive with the finest commercial compilers around, and even high-end RTOS products like VxWorks and LynxOS use them. What happened to RTOS compilers is likely to happen to the OSs
themselves. RTOS products based on Linux will begin to appear, with vendors emphasizing their added real-time features, as well as their support. The result will be a bonanza for developers of high-end embedded systems, with even the cheapest RTOS products providing more features than are currently available from the most expensive products.
Jerry Epplin is an embedded software consultant in St. Louis, MO. He designs software primarily for medical and industrial device manufacturers. He can be reached via e-mail at JerryEpplin@worldnet.att.net.
References
1. Mohr, Jim, "The State of Linux," Byte, January 1997.
2. Joseph, Moses, "Is POSIX Appropriate for Embedded Systems?," Embedded
Systems Programming, July 1995, p. 90.
3. Kuhn, Markus, "A Vision for Linux 2.2-POSIX.1b Compatibility and Real-Time
Support," ftp://informatik.uni-erlangen.de/local/cip/ mskuhn/misc/linux-posix.1b,
December 1996.
4. See http://luz.cs.nmt.edu/~rtlinux
5. Yodaiken, Victor, and Michael Barabanov, "A Real-Time Linux,"
ftp://luz.cs.nmt.edu/pub/rtlinux/papers/usenix.ps.gz.
6. See http://stereotaxis.wustl.edu/ ~jerry.
7. Bennett, Dave, "Booting Linux from EPROM," Linux Journal, January 1997.
SIDEBARS
Linux Resources
Because of the increasing popularity of Linux as a desktop operating system, information is easy to find on the Internet. The Linux Documentation Project, at http://sunsite.unc.edu/mdw/linux.html, is a good place to start. The site contains plenty of general information, as well as links to the commercial distributors of Linux. Because it is "free" software, controlled by no one organization, the distribution of
Linux is somewhat haphazard. Any company is free to download Linux, add some value to it, and sell it to potential users. In practice, companies have added value by improving ease of installation and by placing the software onto a CD-ROM. As a result, distributions of Linux differ primarily in their installation procedures. The best known distributions are Slackware (available from various distributors), Red Hat (http://www.redhat.com), and Debian (http://www.debian.org). Each has its own
advantages, but most embedded system designers are primarily interested in ease of installation-by that standard, the Red Hat distribution is probably currently the most attractive.
Any of the distributions can be downloaded via FTP free of charge, but because of the large size of Linux, the exercise would be painful even for a user with a high-speed Internet connection; dialup users shouldn't even consider it. CD-ROMs containing everything needed are easily and inexpensively obtained, usually costing less than $50. Further confusing the issue is the fact that anyone can take an entire distribution, place
it on CD-ROM, and sell it. For example, InfoMagic (http://www.infomagic.com) puts the Slackware, Red Hat, and Debian distributions on a set of CD-ROMs and sells it, leaving it to the user to decide which distribution to use. Other vendors provide similar products-see the Linux Documentation Project Web site for a list.
This system of distribution, although chaotic, works well. Users must simply remember to obtain tech support from the vendor from whom they bought their CD-ROM. If, for example, you install the Red Hat distribution from an InfoMagic CD-ROM, you must get support from InfoMagic rather than Red Hat. Tech support is generally available
from the CD-ROM manufacturer, but is typically limited to help with installation problems. For help on more advanced issues, dozens of newsgroups, and perhaps hundreds of mailing lists, are active with discussions of every aspect of Linux. In addition, many companies provide fee-based support and consulting services. For example, Yggdrasil Computing, which provides its own Linux distribution, also provides support for other distributions on a fee basis. A list of companies that provide support and consulting services can be found at
http://www.cyrius.com/tbm/Consultants-HOWTO/Consultants-HOWTO.html.
The recent improvements in ease of Linux installation and use are real, but a word of warning is appropriate for those embedded system designers accustomed to using Windows as a development platform. It is possible to install and use Windows for cross-development without ever learning anything significant about that operating system. This is not true of Linux-by the time you have installed Linux and are using it for developing code, you will know a lot about the operating system and the hardware you are using. Linux is still an OS for enthusiasts; to do any significant work with it you must first spend some time learning it. The learning curve is not at all daunting (especially for current Unix users), but one should expect to invest some time before getting results from Linux.
RT-Linux
Information on obtaining and using Real-Time Linux is available at
http://luz.cs.nmt.edu/~rtlinux. Some papers describing the design of and philosophy behind the effort can be obtained there, and are well worth reading. As of this writing, the latest version available is 0.5; it can be obtained via FTP directly from the Web site. Installation is usually straightforward-install Linux and then apply the RT-Linux patch. Also included at the Web site are links to a few projects that use RT-Linux.
One of the most recent and welcome developments is the start of an RT-Linux mailing list. The developers of the system, as well as other experienced RT-Linux users, frequently participate, providing guidance for newcomers and discussing potential future enhancements. Subscribing to this list is a must for anyone using or seriously considering RT-Linux for an application. To subscribe, send mail to majordomo@luz.cs.nmt.edu with "subscribe rtl" in the body of the message.
Return to Embedded.com
Send comments to: Webmaster
Copyright ?1998 Miller Freeman, Inc.,
a United News Media company.