2009年10月30日

Linux嵌入式系统开发平台选型探讨
from:http://www.avrw.com/article/art_104_1066.htm


摘要:使用Linux进行嵌入式产品开发有一个很大的优势,就是开发资源丰富,且成本低廉;但是,技术路线复杂多样,专业人才相对匮乏是Linux嵌入式系统开发面临的一个难题。本文从实际应用的角度,探讨和研究Linux嵌入式系统开发中的平台选型问题,以期望对各位Linux开发研究者有些许裨益。

   关键词:嵌入式系统 Linux开发平台 选型
1 嵌入式系统与Linux
  按照电气工程师协会的一个定义:嵌入式系统是用来控制或监视机器、装置或工厂等的大规模系统的设备。具体说来,它是电脑软件和硬件的综合体;是以应用为中心,以计算机技术为基础,软硬件可裁减,从而能够适应实际应用中对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。一般来说,嵌入式系统不能使用通用型计算机,而且运行的是固化的软件,终端用户很难或者不可能改变固件。而Linux也早已成为IT界家喻户晓的一个名字。概括说来,将Linux应用于嵌入式系统的开发有如下一些优点:
① Linux自身具备一整套工具链,容易自行建立嵌入式系统的开发环境和交叉运行环境,并且可以跨越在嵌入式系统开发中仿真工具(ICE)的障碍。
② 内核的完全开放,使得可以自己设计和开发出真正的硬实时系统;对于软实时系统,在Linux中也容易得到实现。
③ 强大的网络支持,使得可以利用Linux的网络协议栈将其开发成为嵌入式的TCP/IP网络协议栈。
2 嵌入式系统设计的过程
  按照嵌入式系统的工程设计方法,嵌入式系统的设计可以分成三个阶段:分析、设计和实现。分析阶段是确定要解决的问题及需要完成的目标,也常常被称为“需求阶段”;设计阶段主要是解决如何在给定的约束条件下完成用户的要求;实现阶段主要是解决如何在所选择的硬件和软件的基础上进行整个软、硬件系统的协调实现。在分析阶段结束后,通常开发者面临的一个棘手的问题就是硬件平台和软件平台的选择,因为它的好坏直接影响着实现阶段的任务完成。
  通常硬件和软件的选择包括:处理器、硬件部件、操作系统、编程语言、软件开发工具、硬件调试工具、软件组件等。
  在上述选择中,通常,处理器是最重要的,同时操作系统和编程语言也是非常关键的。处理器的选择往往同时会限制操作系统的选择,操作系统的选择又会限制开发工具的选择。
3 硬件平台的选择
    3.1 处理器的选择
  嵌入式系统的核心部件是各种类型的嵌入式处理器。据不完全统计,目前全世界嵌入式处理器的品种总量已经超过1000多种,流行体系结构有30几个系列。但与全球PC市场不同的是,没有一种微处理器和微处理器公司可以主导嵌入式系统,仅以32位的CPU而言,就有100种以上嵌入式微处理器。由于嵌入式系统设计的差异性极大,因此选择是多样化的。
  调查上市的CPU供应商,有些公司如Motorola、Intel、AMD很有名气,而有一些小的公司,如QED(Santa Clara.CA)虽然名气很小,但也生产很优秀的微处理器。另外,有一些公司,如ARM、MIPS等,只设计但并不生产CPU,他们把生产权授予世界各地的半导体制造商。ARM是近年来在嵌入式系统有影响力的微处理器制造商,ARM的设计非常适用于小的电源供电系统。Apple在Newton手持计算机中使用ARM,另外有几款数字无线电话也在使用ARM。
  设计者在选择处理器时要考虑的主要因素有:
① 处理性能。一个处理器的性能取决于多个方面的因素,如时钟频率,内部寄存器的大小,指令是否对等处理所有的寄存器等。对于许多需用处理器的嵌入式系统设计来说,目标不是在于挑选速度最快的处理器,而是在于选取能够完成作业的处理器和I/O子系统。如果是面向高性能的应用设计,那么建议考虑某些新的处理器,其价格相对低廉,如IBM和Motorola Power PC。
② 技术指标。当前,许多嵌入式处理器都集成了外围设备的功能,减少了芯片的数量,降低了整个系统的开发费用。开发人员首先考虑的是,系统所要求的一些硬件能否无需过多的胶合逻辑(GL,Glue Logic)就可以连接到处理器上。其次是考虑该处理器的一些支持芯片,如DMA控制器,内存管理器,中断控制器,串行设备、时钟等的配套。
③ 功耗。嵌入式微处理器最大并且增长最快的市场是手持设备、电子记事本、PDA、手机、GPS导航器、智能家电等消费类电子产品。这些产品中选购的微处理器,典型的特点是要求高性能、低功耗。许多CPU生产厂家已经进入了这个领域。今天,用户可以买到一颗嵌入式的微处理器,其速度像笔记本中的Pentium一样快;而它仅使用普通电池供电即可,并且价格很便宜。如果用于工业控制,则对这方面的考虑较弱。
④ 软件支持工具。仅有一个处理器,没有较好的软件开发工具的支持也是不行的,因此选择合适的软件开发工具对系统的实现会起到很好的作用。
⑤ 是否内置调试工具。处理器如果内置调试工具可以大大缩小调试周期,降低调试的难度。
⑥ 供应商是否提供评估板。许多处理器供应商可以提供评估板来验证理论是否正确,决策是否得当。
3.2 硬件部件选择的其它因素
① 生产规模。打算做1套?多套?还是规模生产?如果生产规模比较大,可以自己设计和制备硬件,这样可以降低成本。反之,最好从第三方购买主板和I/O板卡。
② 开发的市场目标。如果想使产品尽快发售,以获得竞争力,此时要尽可能买成熟的硬件;反之,可以自己设计硬件,降低成本。
③ 软件对硬件的依赖性。软件是否可以在硬件没有到位的时候并行设计或先行开发。
④ 只要可能,尽量选择使用普通的硬件。在 CPU 及架构的选择上,一个原则是:只要有可替代的方案,尽量不要选择 Linux 尚不支持的硬件平台。
4 软件平台的选择
  图1所示的嵌入式软件的开发流程,主要涉及到代码编程、交叉编译、交叉连接、下载到目标板和调试等几个步骤,因此软件平台的选择也涉及到以下几个方面。
    4.1 操作系统的选择
  (1)操作系统选择应考虑的因素
  硬件方案确定之后,操作系统的选择就相对轻松了。硬件的不同,会影响操作系统的选择。低端无MMU(Memory Management Unit,存储器管理单元)的CPU,要使用uClinux 操作系统;而相对高端的硬件,则可以用普通的嵌入式 Linux 操作系统。uClinux 和普通的 Linux 有各自的优势和缺点。可用于嵌入式系统软件开发的操作系统很多,但关键是如何选择一个适合开发项目的操作系统。经过多年的开发实践,笔者认为应该从以下几点进行考虑:
① 操作系统提供的开发工具。有些实时操作系统(RTOS)只支持该系统供应商的开发工具,因此,还必须向操作系统供应商获取编译器、调试器等;而有些操作系统使用广泛,且有第三方工具可用,因此,选择的余地比较大。
② 操作系统向硬件接口移植的难度。操作系统到硬件的移植是一个重要的问题,是关系到整个系统能否按期完工的一个关键因素。因此,要选择那些可移植性程度高的操作系统,避免操作系统难以向硬件移植而带来的种种困难,加速系统的开发进度。
③ 操作系统的内存要求。均衡考虑是否需要额外花钱去购买RAM或EEPROM来迎合操作系统对内存的较大要求。
④ 开发人员是否熟悉此操作系统及其提供的API。
⑤ 操作系统是否提供硬件的驱动程序,如网卡等。
⑥ 操作系统的可剪裁性。有些操作系统具有较强的可剪裁性,如嵌入式Linux、Tornado/VxWorks等等。
⑦ 操作系统的实时性能。
  (2)几类嵌入式Linux系统的比较

  嵌入式Linux系统方面的产品主要分为三类:
  第一类是专门为Linux的嵌入式应用而做的。如何让Linux更小、更容易嵌入到体积要求和功能、性能要求更高的硬件中去,是他们的产品开发方向,如MontaVista的MontaVista Linux等。第二类是专门为Linux的实时特性设计的产品。将Linux开发成实时系统尤其是硬实时系统,应用于一些关键的控制场合(不仅仅是信息电器)。如,Fsmlabs公司开发出来的RT-Linux产品已经用在工业控制的很多方面;葡萄牙的Coimbra大学已经利用RT-Linux实现了化工生产控制厂里用来控制反应和程序控制的系统。第三类的产品是将实时性和嵌入式方案结合起来的方案。很多公司都这么做,并且提供集成化的开发方案,如Lineo、TimeSys等等。
  因此选择操作系统时,要根据自己的嵌入式要求和实时性要求,选择适合自己的嵌入式Linux;同时,和选择硬件的原则一样,如果可能,尽量选择使用普通的嵌入式 Linux 系统。
    4.2 编程语言的选择
  编程语言的选择主要考虑以下因素:
① 通用性。不同种类的微处理器都有自己专用的汇编语言。这就为系统开发者设置了一个巨大的障碍,使得系统编程更加困难,软件重用无法实现。而高级语言一般和具体机器的硬件结构联系较少,多数微处理器都有良好的支持,通用性较好。
② 可移植性程度。汇编语言和具体的微处理器密切相关,为某个微处理器设计的程序不能直接移植到另一个不同种类的微处理器上使用,移植性差;而高级语言对所有微处理器都是通用的,程序可以在不同的微处理器上运行,可移植性较好。
③ 执行效率。一般来说,越是高级的语言,其编译器和开销就越大,应用程序也就越大、越慢;但单纯依靠低级语言,如汇编语言来进行应用程序的开发,带来的问题是编程复杂、开发周期长。因此,存在一个开发时间和运行性能间的权衡问题。
④ 可维护性。低级语言如汇编语言,可维护性不高。高级语言程序往往是模块化设计,各个模块之间的接口是固定的。当系统出现问题时,可以很快地将问题定位到某个模块内,并尽快得到解决。另外,模块化设计也便于系统功能的扩充和升级。
  几种开发语言的比较:
  在嵌入式系统开发过程中使用的语言种类很多,比较广泛应用的高级语言有:Ada、C/C++、Modula-2和Java等。Ada语言定义严格,易读易懂,有较丰富的库程序支持,目前在国防、航空、航天等相关领域应用比较广泛,未来仍将在这些领域占有重要地位。C语言具有广泛的库程序支持,目前在嵌入式系统中是应用最广泛的编程语言,在将来很长一段时间内仍将在嵌入式系统应用领域占重要地位。C++是一种面向对象的编程语言,目前在嵌入式系统设计中也得到了广泛的应用,如GNU C++。Visual C++,是一种集成开发环境,支持可视化编程,广泛应用于GUI程序开发。但C与C++相比,C++的目标代码往往比较庞大和复杂,在嵌入式系统应用中应充分考虑这一因素。Modula-2定义清晰,支持丰富,具有较好的模块化结构,在教学科研方面有较广泛的应用。虽然该语言的开发应用一直比较平缓,但近两年在欧洲有所复苏。Java语言相对年轻,但有很强的跨平台特性,目前发展势头较为强劲。Java语言的“一次编程,到处可用”的特性,使得它在很多领域备受欢迎。随着网络技术和嵌入式技术的不断发展,Java及嵌入式Java的应用也将越来越广泛,但是Java消耗硬件资源较大。
    4.3 集成开发环境考虑的因素
  集成开发环境IDE(Integrated Development Environment)应考虑以下因素:
① 系统调试器的功能。系统调试特别是远程调试是一个重要的功能。
② 支持库函数。许多开发系统提供大量使用的库函数和模板代码,如大家比较熟悉的C++编译器就带有标准的模板库。它提供了一套用于定义各种有用的集装、存储、搜寻、排序对象。与选择硬件和操作系统的原则一样:除非必要,尽量采用标准的 glibc。
③ 编译器开发商是否持续升级编译器。
④ 连接程序是否支持所有的文件格式和符号格式。
4.4 硬件调试工具的选择
  好的软件调试程序可以有效地发现大多数的错误,但是如果再选择一个好的硬件调试就会达到事半功倍的效果。常用的硬件调试工具有以下几种:
① 实时在线仿真器(ICE,In-Circuit Emulator)。用户从仿真插头向ICE看,ICE应是一个可被控制的MCU。ICE是通过一根短电缆连接到目标系统上的。该电缆的一端有一个插件,插到处理器的插座上,而处理器则插到这个插件上。ICE支持常规的调试操作,如单步运行、断点、反汇编、内存检查、源程序级的调试等等。
② 逻辑分析仪。逻辑分析仪最常用于硬件调试,但也可用于软件调试。它是一种无源器件,主要用于监视系统总线的事件.
③ ROM仿真器。ROM仿真器用于插入目标上的ROM插座中的器件,用于仿真ROM芯片。可以将程序下载到ROM仿真器中,然后调试目标上的程序,就好像程序烧结在PROM中一样,从而避免了每次修改程序后直接烧结的麻烦。
④ 在线调试OCD或在线仿真(on-chip emulator)
特别的硅基材料以及定制和CPU引脚的串行连接,在这种特殊的CPU芯片上使用OCD (On-Chip Debugging),才能发挥出OCD的特点。用低端适配器就可以把OCD端口和主工作站以及前端调试软件连接起来。从OCD的基本形式看来,它的特点和单一的ROM监测器是一致的,但是不像后者那样,需要专门的程序以及额外的通信端口。
4.5 软件组件的选择
  有些软件组件是免费的,有些软件组件是授权的。授权软件组件的费用一般都很高,但大都经过严格的测试,可靠性高,调试时间短。现在也有一些免费的自由软件组件,它们的性能、可靠性也很好。因此开发人员在选择的时候要加以权衡,确定哪种方案更好。
5 展 望
  国外的开发已经如火如荼,国内的开发也不甘示弱。Linux在嵌入式系统中具有强大的生命力和利用价值,很多公司和大学都不同程度地表现出对这个方面的兴趣。有理由相信,嵌入式Linux的发展将带领我们进入嵌入式系统的新时代!
posted @ 2009-10-30 21:29 1984| 编辑 收藏
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嵌入式操作系统一定会成为绽放在操作系统中美丽的奇葩。
posted @ 2009-10-30 21:27 1984 阅读(127) | 评论 (0)编辑 收藏
上海海同科技(www.iotek.com.cn)是一家专业嵌入式培训公司,为职场工程师提供多方位的嵌入式解决方案。同时海同科技先后获得微软、ARM、中国电子协会和TI的官方认证体系。综合嵌入式Linux工程师的规划,对学入门Linux系统的同志提供如下的嵌入式系统学校步骤供参考。

1、Linux 基础
安装Linux操作系统 Linux文件系统 Linux常用命令 Linux启动过程详解 熟悉Linux服务能够独立安装Linux操作系统 能够熟练使用Linux系统的基本命令 认识Linux系统的常用服务安装Linux操作系统 Linux基本命令实践 设置Linux环境变量 定制Linux的服务 Shell 编程基础使用vi编辑文件 使用Emacs编辑文件 使用其他编辑器

2、Shell 编程基础
Shell简介 认识后台程序Bash编程熟悉Linux系统下的编辑环境 熟悉Linux下的各种Shell 熟练进行shell编程熟悉vi基本操作 熟悉Emacs的基本操作 比较不同shell的区别 编写一个测试服务器是否连通的shell脚本程序 编写一个查看进程是否存在的shell脚本程序 编写一个带有循环语句的shell脚本程序

3、Linux 下的 C 编程基础
linux C语言环境概述 Gcc使用方法 Gdb调试技术 Autoconf Automake Makefile 代码优化 熟悉Linux系统下的开发环境 熟悉Gcc编译器 熟悉Makefile规则编写Hello,World程序 使用 make命令编译程序 编写带有一个循环的程序 调试一个有问题的程序

4、嵌入式系统开发基础
嵌入式系统概述 交叉编译 配置TFTP服务 配置NFS服务 下载Bootloader和内核 嵌入式Linux应用软件开发流程熟悉嵌入式系统概念以及开发流程 建立嵌入式系统开发环境制作cross_gcc工具链 编译并下载U-boot 编译并下载Linux内核 编译并下载Linux应用程序

5、嵌入式系统移植
Linux内核代码 平台相关代码分析 ARM平台介绍 平台移植的关键技术 移植Linux内核到 ARM平台 了解移植的概念 能够移植Linux内核移植Linux2.6内核到 ARM9开发板

6、嵌入式 Linux 下串口通信
串行I/O的基本概念 嵌入式Linux应用软件开发流程 Linux系统的文件和设备 与文件相关的系统调用 配置超级终端和MiniCOM 能够熟悉进行串口通信 熟悉文件I/O 编写串口通信程序 编写多串口通信程序

7、嵌入式系统中多进程程序设计
Linux系统进程概述 嵌入式系统的进程特点 进程操作 守护进程 相关的系统调用了解Linux系统中进程的概念 能够编写多进程程序编写多进程程序 编写一个守护进程程序 sleep系统调用任务管理、同步与通信 Linux任务概述任务调度 管道 信号 共享内存 任务管理 API 了解Linux系统任务管理机制 熟悉进程间通信的几种方式 熟悉嵌入式Linux中的任务间同步与通信编写一个简单的管道程序实现文件传输 编写一个使用共享内存的程序
线程的基础知识 多线程编程方法 线程应用中的同步问题了解线程的概念 能够编写简单的多线程程序编写一个多线程程序

8、嵌入式 Linux 网络编程
网络基础知识 嵌入式Linux中TCP/IP网络结构 socket 编程 常用 API函数 分析Ping命令的实现 基本UDP套接口编程 许可证管理 PPP协议 GPRS 了解嵌入式Linux网络体系结构 能够进行嵌入式Linux环境下的socket 编程 熟悉UDP协议、PPP协议 熟悉GPRS 使用socket 编写代理服务器 使用socket 编写路由器 编写许可证服务器 指出TCP和UDP的优缺点 编写一个web服务器 编写一个运行在 ARM平台的网络播放器

9、GUI 程序开发
GUI基础 嵌入式系统GUI类型 编译QT 进行QT开发熟悉嵌入式系统常用的GUI 能够进行QT编程使用QT编写“Hello,World”程序 调试一个加入信号/槽的实例 通过重载QWidget 类方法处理事件

10、Linux 字符设备驱动程序
设备驱动程序基础知识 Linux系统的模块 字符设备驱动分析 fs_operation结构 加载驱动程序了解设备驱动程序的概念 了解Linux字符设备驱动程序结构 能够编写字符设备驱动程序编写Skull驱动 编写键盘驱动 编写I/O驱动 分析一个看门狗驱动程序 对比Linux2.6内核与2.4内核中字符设备驱动的不同Linux 块设备驱动程序块设备驱动程序工作原理 典型的块设备驱动程序分析 块设备的读写请求队列了解Linux块设备驱动程序结构 能够编写简单的块设备驱动程序比较字符设备与块设备的异同 编写MMC卡驱动程序 分析一个文件系统 对比Linux2.6内核与2.4内核中块设备驱动的不同

11、文件系统
虚拟文件系统 文件系统的建立 ramfs内存文件系统 proc文件系统 devfs 文件系统 MTD技术简介 MTD块设备初始化 MTD块设备的读写操作了解Linux系统的文件系统 了解嵌入式Linux的文件系统 了解MTD技术 能够编写简单的文件系统为 ARM9开发板添加 MTD支持 移植JFFS2文件系统 通过proc文件系统修改操作系统参数 分析romfs 文件系统源代码 创建一个cramfs 文件系统
回复次数:1
#1楼 得分:0回复于:2009-05-27 09:36:24

推荐嵌入式培训,北京亚嵌教育-国内第1家专业的嵌入式培训机构 http://www.akaedu.org


嵌入式视频教程学习:

1、宋劲杉老师介绍亚嵌教育理念    http://www.akaedu.org/page/v1/index.html
2、宋劲杉老师嵌入式C语言视频分享  http://www.akae.cn/study/C_song.html
3、零投入学习:韩老师讲嵌入式    http://www.akae.cn/study/akaedu/hanchao_embedded.html
4、Linux 基本入门命令            http://www.akae.cn/study/linuxBasicCommnad.html
5、如何使用vim编辑器              http://www.akae.cn/study/vim.html
6、Gcc编译器开发基础              http://www.akae.cn/study/gcc.html
7、Gdb 开发基础                  http://www.akae.cn/study/gdb.html
8、Makefile 详解视频分享          http://www.akae.cn/study/makefile.html
9、GNU 工具链(嵌入式开发常用的) http://www.akae.cn/study/toolchainsShow.html
10、C语言教学视频                http://www.akae.cn/study/clecture/clectureindex.html


亚嵌讲师专著和嵌入式电子书下载

《Linux C编程一站式学习》        http://learn.akae.cn/media/index.html
《源码开放的嵌入式系统软件分析与实践——基于SkyEye和ARM开发平台》
《嵌入式系统实践教程》
《嵌入式系统原理及应用开发》
《嵌入式Linux上的C语言编程实践》
《嵌入式GUI开发设计——基于MiniGUI》
《Ubuntu实战技巧精粹》
《MIPS处理器设计透视(See MIPS Run)》
《嵌入式Linux系统设计与开发》


近期开班课程
嵌入式ARM免费体验日              http://www.akaedu.org/pages/center11_armtiyan.php
嵌入式linux免费体验日            http://www.akaedu.org/pages/center11_yuke.php
嵌入式Linux系统工程师就业培训班  http://www.akaedu.org/pages/center03.htm
嵌入式Linux系统工程师强化培训    http://www.akaedu.org/pages/news_detail.php?id=435
posted @ 2009-10-30 21:27 1984| 编辑 收藏
     摘要: 嵌入式 Linux 应用:概述 从腕表到基于群集的超级计算机 ...  阅读全文
posted @ 2009-10-30 21:26 1984 阅读(145) | 评论 (0)编辑 收藏
移植Qtopia-opensource-src-4.3.2

http://blog.chinaunix.net/u3/91092/article_106802.html
1、下载
下载地址:ftp://ftp.trolltech.com/qtopia/source/qtopia-opensource-src-4.3.2.tar.gz

2、准备工作
建立build目录和安装目录:
/opt/qtopia/source 源代码解压到该目录
/opt/qtopia/target 编译目录
/usr/local/qtopia 安装目录

3、编译tslib-1.3.tar.bz2
详细步骤如下:
# tar jxvf tslib-1.3.tar.bz2 
# cd tslib-1.3
# export CC=arm-linux-gcc
# export CXX=arm-linux-g++
# ./autogen.sh
# ./configure --prefix=/opt/tslib --host=arm-linux
# make
# make install

注意:
当然,在ubuntu下要先安装两个工具,如果没安装,./autogen.sh是通不过的,安装如下:
#sudo apt-get install libtool automake
Make 过程中有个错误,如下:
libtool:link: only absolute run-paths are allowed
要修改/tslib/plugins/Makefile里面找rpath将
LDFLAGS :=$(LDFLAGS) -rpath $(PLUGIN_DIR)
修改为:
LDFLAGS :=$(LDFLAGS) -rpath `cd $(PLUGIN_DIR) && pw……

查看全文
发表于:2009-05-02 ┆ 阅读(536)评论(0)

ubuntu 8.10下建立Qt/Embedded 4.5开发环境
上次编译了Qt-4.5.0,现在又忍不住编译了QtEmbedded-4.5.0,过程如下:

一、下载
qt-embedded-linux-opensource-src-4.5.0.tar.gz
qt-x11-opensource-src-4.5.0.tar.gz

二、编译安装qt-embedded
# tar -zxvf qt-embedded-linux-opensource-src-4.5.0.tar.gz
# cd qt-embedded-linux-opensource-src-4.5.0
# ./configure -embedded x86 -qvfb
# make
# make install
qt-embedded 被安装在这个目录下/usr/local/Trolltech/QtEmbedded-4.5.0

设置环境变量:
# vi ~/.bashrc
把下面的加上去
export QTEDIR=/usr/local/Trolltech/QtEmbedded-4.5.0
export PATH=/usr/local/Trolltech/QtEmbedded-4.5.0/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/Trolltech/QtEmbedded-4.5.0/lib:$LD_LIBRARY_PATH
至此,qt-embedded安装完毕

三、编译安装qt-x11
# tar -zxvf qt-x11-opensource-src-4.5.0.tar.gz
# cd qt-x11-opensource-src-4.5.0
# ./configure
# make
# make install
qt-x11 被安装到此目录下/usr/local/Trolltech/Qt-4.5.0

编译qvfb:
# cd qt-x11-opensource……
查看全文
发表于:2009-03-14 ┆ 阅读(1740)评论(9)

Ubuntu 8.10下编译QT 4.5

到官网下载Download Qt libraries 4.5 for Linux/X11(118 Mb)

1)解压

2)运行./configure,有个许可证,填yes

3)运行make

4)运行make install

5)把路径填入PATH

PATH=/usr/local/Trolltech/Qt-4.5.0/bin:$PATH
export PATH

6)运行qtdemo

安装过程非常简单,但是时间很长,make的过程中出现了一个问题,如下:

在包含自 ../../include/QtGui/private/qt_x11_p.h:1 的文件中,
                从 kernel/qapplication.cpp:76:
../../include/QtGui/private/../../../src/gui/kernel/qt_x11_p.h:71:22: 错误: X11/Xlib.h:没有该文件或目录

posted @ 2009-10-30 21:25 1984| 编辑 收藏
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.

posted @ 2009-10-30 20:45 1984| 编辑 收藏

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.

posted @ 2009-10-30 20:45 1984| 编辑 收藏
仅列出标题  

导航

<2019年2月>
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

统计

常用链接

留言簿

随笔档案

搜索

最新评论

阅读排行榜

评论排行榜