现在用什么嵌入式系统好

bucker

现在用什么嵌入式系统好 [复制链接]

最近想买点书看看，但发现UCOS的书很少了，不知是什么原因啊？

天使疯子

51的，用的人多，价钱还少。好学。

罗曼

VXWORKS.那就学习这个把.当然一定要有钱.

黑衣人

用LINUX吧，没有版权纠纷。VXWORKS和UCOS都是有版权的，而且商业上应用要付费的。其中UCOS的源码是公开的。一点建议，说错了的请不要见怪。

bucker

看起来只有LINUX啦，下载了一个ucLINUX要400多MB哪，还不知怎么用。

呱呱

可以考虑一下eCos

bucker

eCos好像也是公开源代码的，但商业用途是否要收费呢？

呱呱

eCos的专利受eCos license 所保护，这是一个GPL license 的修改版，其准许开发者在其上开发的应用程序（eCos 以外自行撰写的部分）可以不用跟著GPL 一起发布。应用程序开发者可免费的取得其完整的源码（buyout-free），并针对其作任意的修改与在其上开发自己的应用程序并发布，唯一的限制只是若有修改到eCos 本身，其需将修改的源码回报给eCos 开发小组。当开发者将其当为产品时，也不需支付版税（royalty-free）。可以看出，eCos的Licence比GPL要宽松。

呱呱

eCos最大的特点是内核可配置。它出生于1997年，相对其他的系统来说是非常年轻的，但是也正是因为出身的晚，所以在设计理念上面是比较新颖的。其全部代码使用C++编写。 eCos可以说是嵌入式领域的一颗新星，全称是Embedded Configurable Operating System。绝大多数代码使用C++写作完成。最早是Cygnus公司开发（是不是想到Cygwin了？），不久被RedHat收购，现在RedHat 又放弃了RedHat项目，解雇了eCos的开发人员，将他踢到了Free Found Org(这是我坚决不用RedHat的原因，太功利了)。 eCos最大的特点是模块化，内核可配置。如果说嵌入式Linux太庞大了，那么eCos可能就能够满足要求。它是一个针对16位、32位和64位处理器的可移植开放源代码的嵌入式RTOS。和嵌入式Linux不同，它是由专门设计嵌入式系统的工作组设计的。ECOS具有相当丰富的特性和一个配置工具，后者能够让你选取你所需要的特性。Linux兼容的嵌入式系统在内核裁减后编译出来的二进制代码大小在500k字节以上，这还只包含最简单的内核模块，几乎没有加载任何其他的驱动与协议栈。但是eCos最小版本只有几百个字节，一般，一个完整的网路应用，其二进制的代码也就100K字节左右。而且更为重要的是，eCos提供的Linux兼容的API能让开发人员轻松的将linux应用移植（这点和RTEMS很相似），与此同时，应用程序不用跑在Linux复杂的内核机制上（这套机制，对于大型服务器也许还凑合，但是对于短小精干的嵌入式应用，太浪费了），大大节省了你的晶振和RAM。 eCos 中字面上C（configurable） 表示的“高可配置性”。eCos 可以让开发者像在玩积木般地自由选择其执行期的元件，应用程序开发者可以针对自己的应用程序来设迟一个对其最小的RTOS环境，这跟以往应用程序就是跑在一个完整的RTOS上本质上不同，在嵌入式系统资源与内存寸土寸金的环境上，这样的开发方式是很重要的。在以往的嵌入式开发方式都是自己手工的将RTOS 作缩减，对经验不足或对该RTOS不够熟悉的人将会花去许多时间，或是根本很难将RTOS拆开，但在eCos 上，由于设计之初就是朝向可设迟的原则，各种元件都遵守著模块化的开发方式，而应用程序开发者只要使用eCos 中的配置，即可轻松简单的对eCos 元件作量身打造，也不需对其内部实作有所了解即时RTOS的核心并提供标准系统API。eCos 的核心支持一般OS 常见的项目如驱动程序（Device Driver）、内存管理（Memory managemant）、异常处理（exception handling）、中断处理（exception handling）、线程的支持（thread support）、计时器（Timer）、计数器（Counter），对于即时RTOS的支持如完全优先（full preemptability）、最小中断延迟（minimal interrupt latencies ）、线程同步（synchronization primitive）、可自定的调度原则（schedule policies）。此外也支持POSIX 等操作系统的标准API 及ANSI C 与常用的数学函数。支持常用的周边及通讯协议( networking stacks)支持以太网络卡，串口，USB slave等常用周边。并支持一般常用的通讯协议如IP、IPV6、ICMP、UDP、TCP、SNMP、HTTP、TFTP、FTP 等。网络设迟部分，可支持静态IP 与DHCP 。GDB支持可支持主控端使用GDB 远端透过串口或是以太网络对应用程序除错。 此外， eCos另一个优点是他支持非常多的平台和CPU，尤其是比较新的CPU比如ARM的各个系列，DSP（BlackFin）等。并且也支持很多硬件平台。目前支持的CPU包括： ARM, CalmRISC, FR-V, H8, IA32, M68K, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC, SuperH 支持的硬件平台设备包括： Flash, Ethernet, 串口, USB, 时钟等。其已直接支持了时下绝大部分的硬件，可在eCos 官方网站上找到支持列表。具体的硬件支持情况可以参考http://ecos.sourceware.org/hardware.html，里面有长长的一个列表，大家可以根据自己的情况去看看。需要说明的是，这个硬件列表可能很久没有更新过了，最新的硬件列表可能需要访问开发者的邮件列表。 相关可下载的连接是http://ecos.sourceware.org/mirror.html,与ftp://ecos.sourceware.org/pub/ecos/ 参考 http://ecos.sourceware.org/docs-2.0/ ECos的Licence eCos的专利受eCos license 所保护，这是一个GPL license 的修改版，其准许开发者在其上开发的应用程序（eCos 以外自行撰写的部分）可以不用跟著GPL 一起发布。应用程序开发者可免费的取得其完整的源码（buyout-free），并针对其作任意的修改与在其上开发自己的应用程序并发布，唯一的限制只是若有修改到eCos 本身，其需将修改的源码回报给eCos 开发小组。当开发者将其当为产品时，也不需支付版税（royalty-free）。可以看出，eCos的Licence比GPL要宽松。 eCos 上开发的应用程序架构图中File system 指的是对文件系统如ext2 等的支持，library 是上节所提包括POSIX，ANSI C 等的函数库。这张图，由上到下，表示从高层到底层的eCos架构。最底层的是我们的硬件，在硬件上面有HAL 与装置驱动程序，而我们大部分会利用eCos 工具去设中间kernel、networking stack、library 层（OS层），只留下我们需要的部分。最上层的应用程序就是我们自行撰写的部分，通过中间OS 层的辅助来达成我们的目的。由这张图，我们可以看出，Redboot 是一个架构在eCos HAL 与Device Driver 上的一套应用程序。其中与硬件最关系密切的就是HAL，可以用“最接近硬件的软件”来形容，HAL 将所有与硬件相关的地方对外隐藏在里面。针对不同的硬件时，只需换掉HAL，换上针对新硬件而撰写的HAL 即可。

呱呱

嵌入式操作系统uClinux和eCos的比较 日期：2007-07-03 作者：戴晟晖 张良清 1 两种开源嵌入式操作系统介绍 uClinux 是一种优秀的嵌入式 Linux版本。uClinux是micro-Conrol-linux的缩写。与标准Linux相比，它集成了标准Linux操作系统的稳定性、强大网络功能和出色的文件系统等主要优点。但是由于没有MMU(内存管理单元)，故其多任务的实现需要一定技巧。 eCos(embedded Configurable operating system)，即嵌入式可配置操作系统，是RedHat的产品，但eCos并不是Linux或Linux的派生。eCos弥补了Linux在嵌入式应用领域的不足，是一个源码开放的可配置、可移植、无版税、面向深嵌入式应用的实时操作系统。eCos的核心部分是由不同的组件组成的，包括内核、C语言库和底层运行包等。每个组件能提供大量的可配置选项，利用eCos提供的配置工具可以很方便地进行配置。通过不同的配置使得eCos能够满足不同的嵌入式应用。 对于以上两种源码公开的实时操作系统，主要从以下几个方面进行比较。通过比较，能够为大家选择适合自己系统的RTOS提供参考。 2 基本操作性能的比较 2.1 应用程序的运算能力 在Linux 和uClinux操作系统启动的时候，都会有这样一句话——Calibrating delay 1oop．．0k—xxx BogoMips，这一过程叫作BogoMips(读作bogumips)。Linus Torvalds引入BogoMips主要有两个目的：①给用户一个大概的系统运算能力的概念；②由于系统中有许多代码需要精确的软件延时，通过 BogoMips来获得软件延时每个周期消耗的时间。BogoMips的过程就是一个简单计数循环，看ls可以循环多少次，然后除以500000就得到了 BogoMips的数值。 表1是分别在目标硬件平台上运行eCos和uClinux下的BogoMips应用程序得到的结果。我们使用了不同的测试条件，激活和非激活AT76C120的存储器缓冲控制器。 从表1可知，打开缓冲存储器。对eCos的应用程序性能影响较uClinux的大；反之，关闭缓冲，eCos的应用程序的性能就下降很多。 2．2 存储器访问能力 采用一种同时能够测试缓冲控制器和标准存储器访问函数的测试方法来测试存储器访问能力。在这里，选用田纳西大学的Philip J．Mucci等人提出的CacheBench方法。其工作原理是，重复顺序读／写一定长度的存储器块的数据，记录重复n次所用的时问，用总的读／写数据除以耗时，得到读／写每一字节所用的时间；同时，通过调整数据块的长度和不同的读写方法(使用标准函数或者使用直接代码读写)，获得不同条件对存储器读／写的影响。 在实验中，对于每一种测试模式使用4种不同的块长度(分别为256、512、1024、2048字节)，以观察不同的抉长度对存储器访问性能的影响。表2 是实验的结果：横向比较，eCos的存储器访问性能从总体上都优于uClinux；纵向比较，5种模式下性能关系大致为缓冲读>缓冲读，改写／写 >缓冲写>mcmset>mcmcpy。在同一种测试模式下，对于缓冲读，越大的块长度，其表现的存储器访问性能越好；而其他模式下，存储器访问性能基本与块长度无关。 基于以上结果的分析如下：①造成eCos存储器访问能力优于uClinux的原因是，eCos的应用程序获得的处理器时间较长；②造成读缓冲模式下，存储器访问性能随块长度增长而变好，而其他模式下不变的原因是，与AT76C120的缓冲控制器的回写模式有关。由于AT76C120的缓冲控制器采用了直接回写的缓冲回写模式，缓冲控制器对存储器写操作没有任何缓冲作用，因此当处理器写存储器时基本不会享受到由缓冲控制器带来的好处，相当于直接访问外部存储器。 2．3 驱动程序性能测试 为了测试系统的驱动程序性能，选择CF卡驱动程序作为测试对象。我们的测试方法简单，就是在应用程序中打开一个大文件(10MB)，然后调用fread读文件，每次读512字节到缓冲中，直至将文件读完。 表3是测试结果：uClinux的性能优于eCos。这主要是由于uClinux的块驱动有一个叫集簇的功能，它可以将对块设备的多个请求归并在一起执行，这样对于像磁盘这样反应较慢的设备可以提高整体的读／写速度。 3 综合应用性能比较 我们知道，一个图像压缩和解压缩的程序往往需要大块的存储器访问操作、密集的数学运算和大量的磁盘访问。由于现在手持的嵌入式设备大多需要有这方面的应用需求，因此一个图像压缩和解压缩的应用程序既符合理论研究的要求，又符合实际应用的需求。为此我们选择gif图片的编解码的程序作为综合性能测试的测试程序。测试结果如表4所列。 我们看到，eCos和uClinux解码速度都很低，主要是因为完全使用了软件解压缩；而且由于AT76C120的图像显示格式是YCrCb的，而 giflib的解压缩结果是RGB的，因此必须使用浮点运算将RGB的数据转换到YCrCb。AT76C120的ARM7TDMI不支持浮点指令，因此不得不使用软件仿真来完成浮点运算，这其中大部分时间被用在了从RGB到YCrCb的转换上。测试结果基本与前面基本操作系统测试的结果是一致的 ——eCos在整体上是优于uClinux的。 4 可移植性 eCos 的系统一J移植性应该明显比 uClinux的好。在eCos系统中，每一个硬件平台都用一个单独的目录存放针对这一硬件平台的硬件抽象层的代码和配置信息，较容易让用户理解。而 uClinux的硬件抽象层的代码分布在好几个目录中，而且各个平台的代码混合在一个源文件中，通过#ifdef+#end的方式来选择不同的硬件平台的代码。另外，eCos在移植时所要更改的源代码文件数少于uClinux。 可移植性不应仅仅是操作系统的移植，还应该包含应用程序的移植性。程序的可移植性，是由两方面决定的。首先，应用程序必须被编写得可以移植。关于这方面， A．Dolenc，A．Lemmke和D.Keppel在其Notes On WritingPortable Programs In C一文中给出了很好的解释。其次是嵌入式操作系统提供较丰富的系统函数和标准函数库。一个系统提供的函数库越丰富，则越多的应用程序不用进行较大的更改就能直接在其上运行。在标准函数方面，eCos只提供了较为简单的C标准函数库和IEEE浮点运算数学库，uClinux则提供了，与Linux下的 glibc相兼容的函数库，而glibc是大部分开放源代码项目的构建基础。由此可以看出，在应用程序的可移植性上，uClinux的兼容性更好。 5 开发模式和开发难易度 eCos 的开发模式是一套更接近传统单片机的开发模式(如应用程序静态链接)，uClinux的开发模式则更接近Linux的开发模式。因此可以预见，eCos更受一批从8位单片机系统开发转到 32位嵌入式系统开发设计人员的欢迎．而uClinux更受熟悉Linux的设计人员的青睐。 6 总 结 通过以上比较可知，由于eCos从一开始设汁时就是以嵌入式系统为目标的，因此在性能上，有较大优势；反之，uClinux则是由Linux进化而来的，因此在以速度和优化为主题的嵌入式系统环境中，并不占优势。但是由于有 Linux的强大后盾，其功能的强大和兼容性是非常突出的。如果应用程序是从其他系统中移植过来的，或者开发人员有Linux的背景，或者开发成本占总成本的比例较高，则uClinux比较适合；反之，eCos比较适合。