开源嵌入式操作系统和开源手机操作系统

uesoft

1.开源嵌入式操作系统
市场有很多著名的嵌入式操作系统如商业的VxWorks、WinCE、PalmOS、Symbian、pSOS、QNX、HOPEN OS 或开源的如contiki、uCOS、raw-os、Rtems、salvo、embos、uClinux、RTLinux、Arm-Linux、FreeRTOS、eCos、uTenux、Nucleus、ThreadX、 Lynx 、INTEGRITY、OSE、C Executive、RT-thread、RTX、tinyOS、t-kernel、liteOS、nano-RK、kingmos、zephyr、ubiquiOS，等等。
UESOFT公司设想利用开源嵌入式操作系统集成开发一个开源的嵌入式操作系统，能运行在各种设备上，充分利用设备的硬件资源如无线射频、GPS、Bluetooth、NFC、传感器，用于互联网和物联网。

1.1 开源嵌入式操作系统 Contiki
Contiki 是一个适用于有内存的嵌入式系统的开源的、高可移植的、支持网络的多任务操作系统。包括一个多任务核心、TCP/IP 堆栈、程序集以及低能耗的无线通讯堆栈。Contiki 采用 C 语言开发的非常小型的嵌入式操作系统，运行只需要几K的内存。
http://www.oschina.net/p/contiki

1.2 RTEMS   http://zh.wikipedia.org/wiki/RTEMS
http://www.rtems.net/
欢迎来到RTEMS的神奇世界！

RTEMS, 即: 实时多处理器系统(Real Time Executive for Multiprocessor Systems)，是一个开源的无版税实时嵌入操作系统RTOS。 它最早用于美国国防系统，早期的名称为实时导弹系统（Real Time Executive for Missile Systems），后来改名为实时军用系统（Real Time Executive for Military Systems），现在由OAR公司负责版本的升级与维护。目前无论是航空航天、军工，还是民用领域RTEMS都有着极为广泛的应用。

从体系结构上来看，RTEMS是微内核抢占式的实时系统，他具有下面的优点：

优秀的实时性能
支持硬实时和软实时（可抢占内核）
支持优先级继承，防止优先级反转
支持单调周期调度
支持优先级高度协议
非常的稳定
运行速度快
支持多种CPU，无论是ARM， MIPS，PowerPC，i386还是DSP，AVR，Zilog，都可以找到对应的BSP。
高度可剪裁内核（目标系统小只有30KB；大可上百兆）1,2,3
占用系统资源小，在32位系统中最小的内核只有30Kb左右1,2
支持多处理器（不同于SMP，RTEMS中多个处理器是协作关系）
提供POSIX API，Linux/UNIX下的程序可以方便移植
提供完整的BSD的TCP/IP协议栈以及FTP、WebServer、NFS等服务
使用面向对象思想设计，可以大大缩短开发周期
核心代码使用C/C++写作，可移植性好
支持ISO/ANSI C库
支持ISO/ANSI C++库以及STL库
支持精简的可重入glibc库
支持图形用户界面（Microwindows/Nano-X）
支持文件系统（FAT，IMFS等）
支持多种调试模式（包括GDB，DDD，串口调试，以太网调试）
支持32位处理器，Tiny RTEMS项目将对8位和16位处理器进行支持2
支持JAVA虚拟机
（注1：最小内核指的是只包含BSP、任务调度、内存模块这些功能的内核。它的大小和CPU指令集、外设多少、二进制代码格式等相关。CPU是ARM7时，产生的ELF格式标准ARM目标可以减少到46kb。通常来说如果只需要最主要的功能，未压缩目标目标可以控制在60kb(内核+BSP+简单应用)，这比起Linux2.4 压缩后还有700K的庞大体积来说,更适合成本体积敏感的应用）

（注2：现在也有hacker主持Tiny RTEMS项目，该项目中，未压缩的最小的RTEMS bin镜像(内核+BSP)只有20kb。该项目将RTEMS id变成了16bit了，此外该项目将BSD TCP/IP换成了LWIP。这样RTEMS变成了能给8bit和16bit用户使用的小型RTOS，COOL!!。）

（注3：如果只是RTEMS可管理的存储空间，rtems.com公布的应用中，基于RTEMS的飞行记录仪提供多达8G的存储空间。）

RTEMS在性能上丝毫不输于VxWorks，他和VxWorks以及RtLinux的性能比较可以参考《RTEMS简介》。他在全球有不少的用户，尤其是在通信、航空航天、工业控制、军事等领域有着非常广泛的应用，在系统实现上，RTEMS和VxWorks以及NucleusPlus的实现基本相同。

RTEMS的官方网站是www.rtems.com，当前最新的稳定版本是4.7.1，开发版是4.9。在国内，RTEMS主要用在航空航天和军工领域。 我们希望这个网站能普及RTEMS知识，帮助RTEMS在民用领域发挥更大的作用。

本站开设的目的主要是在国内推广嵌入式系统知识（主要介绍RTEMS，此外也不排除其他优秀的嵌入式系统比如 eCos、Linux等）。

RTEMS.net近期项目计划

下面是近期的开放项目，如果你有兴趣、有时间、有能力，可以申请加入。

1.3 uCOS
uC/OS II(Micro Control Operation System Two)是一个可以基于ROM运行的、可裁减的、抢占式、实时多任务内核，具有高度可移植性，特别适合于微处理器和控制器，是和很多商业操作系统性能相当的实时操作系统(RTOS)。为了提供最好的移植性能，uC/OS II最大程度上使用ANSI C语言进行开发，并且已经移植到近40多种处理器体系上，涵盖了从8位到64位各种CPU(包括DSP)。 uC/OS II可以简单的视为一个多任务调度器，在这个任务调度器之上完善并添加了和多任务操作系统相关的系统服务，如信号量、邮箱等。其主要特点有公开源代码，代码结构清晰、明了，注释详尽，组织有条理，可移植性好，可裁剪，可固化。内核属于抢占式，最多可以管理60个任务。从1992年开始，由于高度可靠性、移植性和安全性，uC/OS II已经广泛使用在从照相机到航空电子产品的各种应用中。
μC/OS-II实时多任务操作系统内核。它被广泛应用于微处理器、微控制器和数字信号处理器。 μC/OS-II 的前身是μC/OS，最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。

http://baike.baidu.com/link?url= ... gq-xm6SYE_6uUBDEU2K

1.4 FreeRTOS
简介
FreeRTOS是一个迷你的实时操作系统内核，功能包括：任务管理、时间管理、信号量、消息队列、内存管理、记录功能、软件定时器、协程等，可基本满足较小系统的需要。
由于RTOS需占用一定的系统资源(尤其是RAM资源)，只有μC/OS-II、embOS、salvo、FreeRTOS、RTX等少数实时操作系统能在小RAM单片机上运行。相对μC/OS-II、embOS等商业操作系统，FreeRTOS操作系统是完全免费的操作系统，具有源码公开、可移植、可裁减、调度策略灵活的特点，可以方便地移植到各种单片机上运行，其最新版本为8.2.3版。
功能和特点
用户可配置内核功能
多平台的支持
提供一个高层次的信任代码的完整性
目标代码小，简单易用
遵循MISRA-C标准的编程规范
强大的执行跟踪功能
堆栈溢出检测
没有限制的任务数量
没有限制的任务优先级
多个任务可以分配相同的优先权
队列，二进制信号量，计数信号灯和递归通信和同步的任务
优先级继承
免费开源的源代码
原理与实现
任务调度机制是嵌入式实时操作系统的一个重要概念，也是其核心技术。对于可剥夺型内核，优先级高的任务一旦就绪就能剥夺优先级较低任务的CPU使用权，提高了系统的实时响应能力。不同于μC/OS-II，FreeRTOS对系统任务的数量没有限制，既支持优先级调度算法也支持轮换调度算法，因此FreeRTOS采用双向链表而不是采用查任务就绪表的方法来进行任务调度。系统定义的链表和链表节点数据结构如下所示：
http://www.freertos.org/

6.开源手机操作系统
市场有很多著名的手机操作系统如android,ios,symbian，meego、mer、sailfish、tizen、ubuntu touch等等。
UESOFT公司设想利用开源Linux操作系统集成一个开源的手机操作系统，也能应用在PC，运行在手机上，充分利用手机的硬件资源如无线射频、GPS、Bluetooth、NFC、传感器，用于互联网和物联网。著名的开源手机操作系统有：android,

下面是一些著名手机操作系统简介。

6.1，Android
Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发，主要支持手机。2005年8月由Google收购注资。2007年11月，Google与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android系统。随后Google以Apache开源许可证的授权方式，发布了Android的源代码。第一部Android智能手机发布于2008年10月。Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机等。2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。 2012年11月数据显示，Android占据全球智能手机操作系统市场76%的份额，中国市场占有率为90%。2013年09月24日谷歌开发的操作系统Android在迎来了5岁生日，全世界采用这款系统的设备数量已经达到10亿台。

开发android app的主要语言是java，也可使用c/c++如QT开发android NDK程序。

6.2，苹果iOS
苹果iOS是由苹果公司开发的移动操作系统。苹果公司最早于2007年1月9日的Macworld大会上公布这个系统，最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad以及Apple TV等产品上。iOS与苹果的Mac OS X操作系统一样，它也是以Darwin为基础的，因此同样属于类Unix的商业操作系统。原本这个系统名为iPhone OS，直到2010WWDC大会上宣布改名为iOS。最新版本为iOS7。

下面是另外一些基于Linux的手机操作系统演变过程。

http://zh.wikipedia.org/wiki/移动操作系统

主流行動作業系統[编辑]
Android（谷歌，開放原始碼）
Android是一個基於開放源碼的Linux平台的作業系統，受谷歌及參與開放手機聯盟的主要硬件和軟件開發商（如英特爾、宏達電、ARM公司、三星、摩托羅拉等）支持。Android最早是由一個小型創業公司（Android公司）開發，公司於2005年被谷歌併購後，谷歌繼續開發，逐漸形成現時的Android。
Android至今最新為4.4版本，其中一個特色是每一個發布版本的開發代號均與甜點有關，例如1.6版本的甜甜圈（Donut）和2.2版本的霜凍優格（Froyo）等。大多數主要移動服務供應商均有支援Android裝置使用其網絡。自推出首台裝置HTC Dream後，使用Android的裝置數量一直大幅度增長。至2010年第二季，Android在國際市場的佔有率達17.2%，較2009年第二季增加八倍半。至2011年11月，Android在國際市場的佔有率已超過半數，達52.5%[4]。
iOS（蘋果，封閉原始碼）
iPhone、iPod Touch、iPad和Apple TV都是以源自OS X的iOS作為操作系統，至今最新為7.0版本。在2008年7月11日發布2.0版本前，iOS不支持第三方應用程序。在此之前，一般會透過越獄以容許安裝第三方應用程序，而此途徑至今已然有效。目前所有的iOS設備都是由蘋果公司開發，並由富士康或其他蘋果的合作夥伴製造。
Windows Phone（微軟，封閉原始碼）
微軟的行動作業系統，取代Windows Mobile。
其他行動作業系統[编辑]
BlackBerry 10
黑莓公司的行動作業系統。
Nokia OS
諾基亞的行動作業系統。
Firefox OS
Mozilla基金會旗下所開發的行動作業系統。
Sailfish OS
基於Linux的行動作業系統，由MeeGo的分支Mer再分支而成。
Tizen
由Linux基金會和LiMo基金會主導的開放原始碼專案。
Ubuntu Touch
由Canonical公司發起的開放原始碼專案，基於Ubuntu，正在開發中。
停止更新的行動作業系統[编辑]
OpenEmbedded
基於linux的自由軟體專案，由社群自行開發，可安裝於Nokia N800，已停止更新。
Openmoko Linux
2010年後停止更新。
LiMo
2010年後停止開發，併入Tizen。
MeeGo
主要開發者英特爾與諾基亞宣布不再支持此項目，於2011年停止開發。Linux基金會將此項目併入Tizen，自由軟體社群分支出Mer與Sailfish OS，繼續開發。
Bada
由三星公司開發，2012年停止開發，併入Tizen。
webOS
2011年推出3.0版後停止開發。
Symbian
2013年，諾基亞宣布停止開發，以Windows Phone為主。
Windows Mobile
2010年，微軟宣布停止開發，以Windows Phone取代。
智慧型手機的作業系統之比較[编辑]

主条目：移动操作系统比较

uesoft

c 函数库比较
http://blog.chinaunix.net/uid-25147458-id-193010.html




一. GLIBC  最小系统：ROM 400K RAM ?K


glibc是一种按照LGPL许可协议发布的C函数库，是程序运行时使用到的一些API集合，它们一般是已预先编译好，以二进制代码形式存在于Linux类系统中，glibc通常作为GNU C编译程序的一个部分发布。 它最初是自由软件基金会为其GNU操作系统所写，但目前最主要的应用是配合Linux内核，成为GNU/Linux操作系统一个重要的组成部分。

在通用的PC和Server中，Linux（ubuntu, Redhat, CentOS etc.）默认提供对glibc的支持；但是在嵌入式应用中，考虑到系统对os大小的要求和简化系统的复杂度等因素，并不一定支持glibc，而是支持uClibc、newLib等针对嵌入式应用的C函数库。这就要求在嵌入式系统开发的过程中，需要评估应用对glibc的依赖程度，评估程序开发或移植的工作量和复杂度。

glibc是linux系统中最底层的api（应用程序开发接口），几乎其它任何的运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现，关于glibc功能的介绍可以在其官方网站上获取到详细的手册资料（http://www.gnu.org/software/libc/manual/）。

主要的功能如下（摘自glibc手册）：

(1)Error Reporting，进行错误类型的检测和报告（how errors detected by the library are reported）

(2)Language Features,  support for standard parts of the C language, including things like the sizeof operator and the symbolic constant NULL, how to write functions accepting variable numbers of arguments, and constants describing the ranges and other properties of the numerical types. There is also a simple debugging mechanism which allows you to put assertions in your code, and have diagnostic messages printed if the tests fail.

(3)Memory, 动态内存的分配和管理 （describes the GNU library's facilities for managing and using virtual and real memory, including dynamic allocation of virtual memory. If you do not know in advance how much memory your program needs, you can allocate it dynamically instead, and manipulate it via pointers.）

(4) 字符、字符串及数组的处理 Character Handling is about character classification functions (such as isspace) and functions for performing case conversion. String and Array Utilities, include functions for manipulating strings (null-terminated character arrays) and general byte arrays, including operations such as copying and comparison.

(5)标准IO的支持

(6)文件操作的支持（File System Interface,  such as functions for deleting and renaming them and for creating new directories.  also contains information about how you can access the attributes of a file, such as its owner and file protection modes. ）

(7)进程间通讯的支持（Pipes and FIFOs,  Pipes allow communication between two related processes (such as between a parent and child), while FIFOs allow communication between processes sharing a common file system on the same machine. ）

(8)网络的支持（socket）

(9)  虚拟终端设备的管理，及系统的安全访问（Low-Level Terminal Interface， change the attributes of a terminal device. disable echo of characters typed by the user, for example, read this chapter. ）

(10)数学及运算库的支持（定点运算和浮点库）

(11)查找和分类的支持（Searching and Sorting）

(12)模式匹配的支持（Pattern Matching）

(13)时间及定时器的管理

(14)不同字符集的编码转换

(15)国际化的支持，选择不同的语言种类和国家

(16)Non-Local Exits （provide a facility for goto-like jumps which can jump from one function to another.）

(17)信号量的支持（Signal Handling, establish a handler that is called when a particular kind of signal is delivered, and how to prevent signals from arriving during critical sections of your program.）

(18)进程编程和进程控制(process and Job control)

(19)用户管理和系统管理（User Database and System Management） 等



二. uClibc  最小系统：ROM ?K RAM ?K


uClibc 是一个面向嵌入式Linux系统的小型的C标准库。最初uClibc是为了支持uClinux而开发，这是一个不需要内存管理单元的Linux版本，因此适合于微控制器系统（uCs；此处"u"是代表"micro"的μ的罗马化）.[2]

uClibc比一般用于Linux发行版的C库GNU C Library (glibc)要小得多，glibc目标是要支持最大范围的硬件和内核平台的所有C标准，而uClibc专注于嵌入式Linux.很多功能可以根据空间需求进行取舍。

uClibc运行于标准的以及无MMU的Linux系统上，支持tile, i386，x86 64，ARM (big/little endian), AVR32，Blackfin，h8300，m68k，MIPS (big/little endian), PowerPC，SuperH (big/little endian), SPARC，和v850等处理器。

uClibc和Glibc并不相同，两者有许多不同之处，而且以下不同有可能给你带来一些问题.

1.uClibc比Glibc小，虽然uClibc和Glibc在已有的接口上是兼容的，而且采用uClibc编译应用程序比采用Glibc编译应用程序要更方便，但是uClibc并没有包括Glibc中的所有接口实现，因此有些应用可能在uClibc中不能编译。

2.uClibc在可配置性上比Glibc要好。

3.uClibc并不能保证发布的库二进制兼容旧版本uClibc库。当一个新的版本uClibc库被发布，则可能需要也可能不需要重新编译应用程序。

4.uClibc没有提供用于数据接口的库(libdb)。

5.uClibc不支持NSS(/lib/libnss_*)，在这方面Glibc更容易支持不同方式的认证和DNS解析。uClibc仅仅支持采用flat口令文件或者shadow口令文件存储授权信息。如果需要比这些更复杂的的授权，可以编译安装pam。

6.uClibc中的libresolv库仅仅是一个桩。Glibc的libresolv库中的部分并不是全部的功能uClibc都提供，许多函数都没有实现。

7.提供网络信息服务支持(NIS)libnsl库(最初被称为黄页YP)，被SUN扩展为发明为RPC并用于网络共享Unix口令文件。个人认为NIS是一个令人厌恶的东西并应该使用。因此，在实现相同的功能情况下采用ldap比NIS更有效。uClibc虽然提供一个桩libnsl，但并不支持NIS。我们因此也不提供在Glibc下提供的位于/usr/include/rpcsvc里的头文件。

8.uClibc的区域支持并不是100%的完全。正在这方面努力

9.uClibc的数据功能函数库内部仅仅支持long double，设置对于long double的支持也是非常有限。与此对应的只实现了较少的数学函数。如果应用程序采用double类型，则会程序会运行得较好。

10.uClibc的libcrpt库不支持可重入crypt_r,setkey_r和encrypt_r，因为这些也不是SuSv3所规定的。

11.uClibc直接采用内核的数据类型去定义大多数透明的数据类型。

12.uClibc支持采用linux内核结构特有的结构体"struct stat"。

13.uClibc的运行时库librt当前缺少aio接口、全部的时钟接口和共享内存接口(仅仅实现定时器接口和消息队列接口)



三. newlib  最小系统：ROM ?K RAM ?K


Newlib是一个面向嵌入式系统的C运行库。最初是由Cygnus Solutions收集组装的一个源代码集合，取名为newlib，现在由Red Hat维护。

对于与GNU兼容的嵌入式C运行库，Newlib并不是唯一的选择，但是newlib是比较优秀和成熟度比较高的一个。newlib具有独特的体系结构，使得它能够非常好地满足深度嵌入式系统的要求。newlib可移植性强，具有可重入特性、功能完备等特点，已广泛应用于各种嵌入式系统中。

newlib 是一个用于嵌入式系统的开放源代码的C语言程序库，由libc和libm两个库组成，特点是轻量级，速度快，可移植到很多CPU结构上。newlib实现了许多复杂的功能，包括字符串支持，浮点运算，内存分配(如malloc)和I/O流函数(printf，fprinf()等)。其中libc提供了c 语言库的实现，而libm提供了浮点运算支持。

在使用gcc编译器时，对gcc指定不同的配置选项时，使用的C语言库就不同，默认情况是下使用glibc，可以通过--with-newlib选择使用newlib.



四. Bionic  最小系统：ROM 200K RAM ?K


Android除了使用的是ARM版本的内核外和传统的x86有所不同外，重要的是Google为Linux内核增强了不少东西，自己开发了 Bionic库，同时又贡献给Linux社区了。首先GNU的内核在体积和运行效率上不适合移动设备，系统核心组件都是以动态库的形式驻留在每个进程中， 运行效率和内存占用都是十分重要的问题。Google开发了一个自定义的库名为Bionic，以BSD许可形式开源。

Bionic库仅为200KB大小是GNU版本体积的一半，这意味着更高的效率和低内存占用，同时配合经过优化的Java VM Dalvik才可以保证高的性能。Bionic不支持一些特性比如宽字节对unicode，类似c++那样的异常处理。



五. EGLIBC  最小系统：ROM ?K RAM ?K


2009年，Debian及其衍生发行版用EGLIBC取代了GNU C Library(GLIBC)。EGLIBC是GLIBC的改良版，源代码和二进制都兼容于GLIBC。然而五年后的今天(2014年06月20日)，EGLIBC已经是一个死亡的项目，所以Debian又用GLIBC替换了EGLIBC。EGLIBC死得其所，因为过去几年GLIBC的开发发生了很大的变化，主要是两大事件所致：其一是 Ulrich Drepper在2010年离开Red Hat和GLIBC加入了高盛，其二是GLIBC指导委员会2012年自行解散。这两件大事改变了团队协作和开发环境，现在的GLIBC开发是基于同行审议，代码bug很少，而 EGLIBC的大部分功能都已合并到GLIBC。

2012年05月09日EGLIBC 2.15.1 发布，该版本修复了 7 个 bug ，没有新功能引入。
Embedded GLIBC (EGLIBC) 是 GNU C Library (GLIBC) 的一个变种，用于工作在嵌入式的系统中。EGLIBC 严格兼容二进制的 GLIBC 。
GLIBC为了实现最优化处理，致使在空间占用上越来越为人诟病。EGLIBC的主要特性是更好的支持嵌入式架构，支持不同的shell(GLIBC只支持bash)，支持-Os，可配置组件，稳定分支修正了一些重要Bug等。

uesoft

对RTOS的粗浅认知
(2013-01-09 17:08:52)
source: http://blog.sina.com.cn/s/blog_93f5f7380101aj35.html
分类： 嵌入式
用STM32做东西也就几年了，一直都是延续单片机裸奔的搞法，前后台，用的也还可以，但是总觉得性能这么好不跑个OS浪费了。于是关注了一阵子RTOS，看了些相关资料。结合自己的理解整理如下：

UCOS：最小系统：ROM 10K RAM 4K
     以前一直留下的印象大多是别人对UCOS2的抱怨，然后大多说只适合教学，体积太大，臃肿啥的，再就是商用要付费。几乎每个UCOS的文件头里都有这么一句“Your honesty is greatly appreciated.”人家把商用代码无偿提供给你学习研究，然后告诉你商用使用要付费，我觉得这样很大气，毕竟也是人家智慧的结晶劳动的成果，免费提供给你，付不付费看自觉。昨天晚上粗读了下UCOS3的代码，感觉自己过去写的都是屎，是得要把项目代码好好整理一下了。

FreeRTOS：最小系统：ROM 6K RAM 2K
      以前对FreeRTOS的印象还不错，就因为免费，最近上官网仔细看过以后发现它用的是修改版GPL2，商用确实是免费的，但是必须告知用户你的产品用了FreeRTOS，并且如果用户要求就必须提供源代码。如果要不谈我用的什么系统，也不想提供源代码，就的付费给它，改授权变成OpenRTOS。还有更好的呢！如果想要更多的功能，更全的协议栈，更完善完整的安全性，请付更多的钱得到SafeRTOS！看个API文档都要收钱，要其他模块也要收钱（FS，TCP）。要不就自己费点劲移植吧。另外，功能也比较简单，只能支持：队列，信号量和互斥，而UCOS还可以支持邮箱和事件（FLAG）。可靠性的话也不如UCOS，但是他的收费版SafeRTOS应该不错，只是不拿钱就见不着(流明的CM3部分型号内建了SafeRTOS的API，出厂就有可以直接用，这个不错。)

RL-RTX：最小系统：ROM 4K RAM 0.5K
      RVMDK里附送的RTOS，附送完全源代码，授权宽松几乎没有限制，唯一的难点在于不够成熟，好在升级不断改进也不断。然后配置方便，跟RVMDK结合紧密，它有挺全的中间件（FS，TCP，USB）等回头装了RVMDK以后仔细看看好了。

RTX:
Windows 2000的内核实际上是非实时的,内核任务调度的最小时间片是10ms,有数据表明,Windows2000的ISTLatency(中断服务延迟时间)在4.3～5000us这样一个非常大的范围内波,
没有稳定的响应延迟和任务处理的确定性,无法满足同步信号输出时延小于4us的需求和稳定性要求。加上复杂的TCP/IP协议栈,运行几个控制周期也许能满足系统实时性的要求,但要长时间稳定工作,显然仅靠Windows2000操作系统,要保证数据传输时延稳定满足要求小于2ms的任务需求几乎是不可能的。
RTX的全称是Real Time Extension,是由美国Venturcom公司开发的专为基于NT构架的Windows操作系统开发的实时性扩展软件包。RTX610的单套报价大约是1万美元,不到Vxworks实时操作系统的1/6;另外RTX提供的rtAPI与WinAPI极度相似,在同名的WinAPI函数前加rt-前缀就可以访问rtAPI了。如果用户对Vxworks实时操作系统编程不熟悉,而又有Windows操作系统编程基础,那末使用RTX就可以轻松上手,省去了繁杂的学习时间,对于工程应用开发非常有利。
RTX实时性机理
通过研究发现,RTX改动了Windows HAL(硬件抽象层),增加了Real Time HAL Extension,简称rtHAL。rtHAL的功能则是拦截中断、提供硬件直接访问支持,因实时子系可以独立访问硬件,而不需要通过Windows。第二,RTX拥有一套完全独立于Windows内核的中断处理、线程调度、事件同步机制。第三,RTX优先于Windows内核的执行。当有硬件中断到来时,rtHAL会首先拦截该中断,交给实时子系统处理,如果实时子系统不处理该中断,中断会被交给Windows内核去处理。可见通过rtHAL、独立的中断处理、线程调度、事件同步机制及优先执行,使得RTX能够真正避开Windows内核,实现实时处理。
工程设计实现
硬件设计
脉冲发生卡设计
为了减小脉冲输出的时延,脉冲发生卡设计为ISA插卡形式。通过给0X320端口先写入0x01,延迟1us,再写入0x00就得到了一个1us的脉冲信号。由于运行在RTX实时子系统下的应用程序可以直接访问硬件,不需要专门的驱动程序,这样就减少了系统开销,最大限度的提高了实时性。
网卡选型
网卡选用
RTX自带实时驱动程序的3C905C作为以太网通讯网卡;也可以选择其它RTX提供驱动的网卡,详细目录可参考RTX用户手册。
RTX51 Tiny:  最小系统：ROM 0.9K RAM 13字节(2个任务)
一个实时操作系统（RTOS）可以更灵活有效地分配系统资源，例如CPU和存储器，同时也提供任务之间的通信。RTX51 Tiny是一个功能强大且易于使用的RTOS，可以运行在所有8051以及其衍生产品上，支持循环任务切换与信号传递，不提供抢先的任务切换，还能并行的利用中断功能。RTX51 Tiny的程序设计可以使用标准C语言，并可以用Keil的C51 C编译器进行编译。利用C51附加的特性，你可以很容易声明任务函数，却不需要复杂的堆栈以及变量帧的配置。RTX51 Tiny的程序设计仅要求你包换一个特定的头文件以及正确连接RTX51的库到你的程序中。
产品规格
产品参数 限制值
最大可定义的任务数 16
最大激活的任务数   16
需要的CODE 空间   900字节（最大）
需要的DATA空间    7 字节
需要的STACK空间   3 字节/任务
需要的XDATA空间   0 字节
定时器           0
系统时钟的除数   1,000-65,535
中断响应时间     20 机器周期（最大）
上下文切换时间   100-700 机器周期

PowerPac(EmbOS):
最小系统：ROM 1K RAM 52字节      这个家伙其实不应该放在这里，因为他是纯商业的，只要OS的库文件就很贵，要源代码版的更贵！自带的文档很全面，就是得费事去看。破解的二进制文件的OS库我倒是有，最新版到v2.40.2，对应的IAR ARM 6306。据说性能非常好，既然卖那么贵，估计也确实是好吧，等我水平高点再来看看吧。

eCOS:
最小系统：ROM 30K RAM 10K
      REDBOOT:ROM 40K     完全开源，内核用C++编写，支持POSIX和uITRON接口，可靠性很高，有比较全的模块，TCP/IP部分支持LwIP和BSD TCP/IP。牛逼的是它跑在了国际空间站上的阿尔法磁谱仪AMS-02上，确实厉害。eCOS有收费版，叫eCOSPRO,可以给你提供更严格检查测试过的代码和完整的技术支持。曾经看到eCOS的资深程序员招聘广告，给的是35K~45K英镑的年薪。这说明客户给他们的钱更多-_-。

RTEMS：最小系统：ROM 30K RAM 4K
      完全开源，最早用于美国国防系统，之前是叫导弹控制系统，现在的全称是Real Time Executive for Military Systems，在航空航天军事系统里有广泛的应用，稳定性可靠性不必谈了,性能不输VxWORKS。支持POSIX和uITRON接口。用的是BSD的TCP/IP。也有hack过的TinyRTEMS,使用LwIP。

      TinyRTEMS:ROM 20K
RT-Thread:
      国产开源系统，说自己多牛，性能比eCOS/UCOS高多少倍，只是应用较少，据说有人拿它做商用产品了，暂时还没有后续消息（问题？改进？）。我相信咱中国人的聪明才智，但是系统这玩意是需要时间和应用的沉淀才能慢慢成熟的。可以持续关注。
TI-RTOS和SYS/BIOS：
      今天很偶然的看到了TI自己的RTOS，只提供给他自己的CPU上。先说SYS/BIOS吧，以前看DSP资料时知道TI的DSP可以提供给你一套RTOS用，名字叫BIOS，只能在DSP上用。现在BIOS发展到6.x的版本以后改名叫SYS/BIOS了，支持的CPU也增加了MSP430和流明的CM，从介绍上看这个SYS/BIOS只是个调度器核心（全称叫SYS/BIOS Real-Time Kernel），似乎跟UCOS/FreeRTOS没多大区别，授权上是完全开源没有限制。而这个TI-RTOS呢，是建立在SYS/BIOS的核心上加上TCP/USB/FS/设备驱动的完整的RTOS。同样也是完全开源没有限制，一定要说的话限制开发环境吧，必须是CCS，不过我想如果有心移植到其他环境也应该好办。     

我关注和粗浅了解的基本就这些吧，真正要用到产品里还是要看具体的需求。但是就目前来看，我本人是没有能力去评估一款RTOS的稳定性可靠性，只能指望作者写得够好。如果在应用中出现BUG（确实是RTOS的BUG），要我去给它除BUG，我还真担心自己没那个水平。
就我目前的水平，还是老老实实地读UCOS3的源代码来学习好了，一方面应用RTOS的需求还不太迫切，另方面自己水平有限。等看懂了UCOS3，看FreeRTOS和RL-RTX也应该没什么问题了，再就往eCOS和RTEMS发展。

uesoft

Zephyr ：最小系统：ROM 10K RAM 8K
Zephyr 是 Linux 基金会推出的一个适用于物联网的小型可伸缩的实时操作系统，支持多种处理器架构。Zephyr 是安全的、开源的、模块化的以及支持多种连接方式，支持 Bluetooth, Bluetooth LE, WiFi, 802.15.4 以及 6Lowpan, CoAP, IPv4, IPv6, and NFC.。

Linux基金会宣布了微内核项目Zephyr。Zephyr微内核将被用于开发针对物联网设备的实时操作系统（RTOS)。Zephyr项目得到了英特尔、 NXP半导体、Synopsys和UbiquiOS等公司的支持，英特尔子公司Wind River向Zephyr项目捐赠了它的Rocket RTOS内核。

Wind River的Rocket RTOS将转变成基于Zephyr内核的下游商业发行版。Zephyr微内核能运行在只有10KB RAM的32位微控制器上，相比之下基于Linux的微控制器项目uClinux需要200KB RAM。

uesoft

UbiquiOS:Flash/RAM 最小 128/16 kB
UbiquiOS™
Low-cost Wi-Fi connectivity for the Internet of Things.
Turn-Key

ubiquiOS™ enables the use of light-weight Wi-Fi transceivers with low-cost, low-power microcontrollers. It provides everything you need for standards-based wireless networking.
Internet of Things

ubiquiOS™ is optimised for the Internet of Things, with a strong feature set that gives fastest time to market for products incorporating wireless connectivity for the first time.
Cost-Optimised

ubiquiOS™ allows you to optimise your architecture for production volumes by minimising resource requirements on your MCU, and eliminating unnecessary components.
Interoperability

ubiquiOS™ is built on global standards. Our efficient protocol implementations mean you don't need to compromise on functionality, security, or interoperability when using low-cost MCUs.
TARGET MARKETS

    LIGHTING HVAC SMART OBJECTS SMART ENERGY WHITEWARE MULTIMEDIA

Features
You focus on changing the world – leave the wireless connectivity to us!
Don't Compromise on Security

With industry-standard encryption and authentication across layers, ubiquiOS brings robust information security to the Internet of Things.
Connect to the Cloud

ubiquiOS products can leverage the power of the cloud, with native support for RESTful APIs and common web data interchange formats.
Quick and Easy Integration

ubiquiOS APIs are powerful, simple, and make connectivity a breeze, leaving you to focus on making your product a world-beater.
Reduce Your Footprint

Designed from the ground up for Internet of Things applications, ubiquiOS has a tiny memory footprint, reducing silicon area, and thus solution cost.
Zero-Config Discovery and Control

With built-in support for UPnP™, and example apps for various platforms, ubiquiOS enables zero-config discovery and control from any smart device.
Product Development Support

If you want more than just technology you've come to the right place. We'll help turn your connectivity dreams into reality.
Key Specifications
Wireless Connectivity

    IEEE 802.11 wireless LAN upper MAC, MLME, and SME
    Station and soft AP modes of operation
    WEP, WPA, and WPA2 link-layer security
    Push-button or PIN provisioning to Wi-Fi Protected Setup APs

Processor Support

    Designed for low-cost MCUs based on ARM, MIPS, x86/IA-32, etc.
    Flash/RAM requirement from 128/16 kBytes
    CPU clock frequency from 16 MHz
    ARM Cortex™-M0/M3/M4 cores
    Microchip 32-bit PIC® based on MIPS® M4K®
    NXP LPC ARM Cortex-M series MCUs
    Silicon Labs EFM32
    ST Microelectronics STM32

Networking

    TCP/IP stack optimised for Internet of Things
    ARP, DHCP, Auto-IP, IGMP, ICMP, DNS, UDP
    Network Time Protocol (NTP) for internet time sync
    HTTP/HTTPS client supporting object transfer and streaming
    HTTP/HTTPS server supporting scripted/static pages with AJAX
    Zero-config device/service discovery and control with UPnP or mDNS/DNS-SD

Security

    AES and RC4 ciphers
    SHA-1, SHA-256, SHA-512, and MD5 cryptographic hashes
    Diffie-Hellman and RSA key management
    Transport Layer Security (TLS) v1.2
    Server certificate validation including OCSP
    Client authentication by embedded certificate

uesoft

实时linux系统
real time linux os

开源的实时linux系统有很多，如RTAI、xenomai、RT-Linux、adeos

0,linux实时性能比较
0.1,强实时应用环境下VxWorks, Linux, RTAI和Xenomai系统的性能比较
http://wenku.baidu.com/link?url= ... uSYQ3sAhAylkWGCI7za
无重调度的测量延迟和抖动
system     linux  RTAI Xenomai VxWorks
Jitter(us)  0.4   0.15  0.25    0.5
Delay(us)  72.8   71.8  73.2   69.2

有实时网络通信的测量延迟(RTAI和Xenomai都使用RTnet IP栈,linux和vxworks使用本地ip栈)
system     linux  RTAI Xenomai  VxWorks
Jitter(us)  11.1    3    3.3     20.4
Delay(us)   113   101    104.5   156.5
本篇文章的目的是为了评估Linux实时解决方案替代RFX-mod目前正在使用的VxWorks的可能性。基于性能测定的结果，我们可以得到以下结论：
当前Linux 2.6内核的性能非常好，在小的专用系统是可以接受的。但RFX-mod的反馈控制系统并非如此，涉及的控制单元要处理高数据吞吐量的输入/输出和网络通信。  RTAI和Xenomai都值得考虑。
Xenomai的性能表现略次于RTAI，主要是因为它分层的方法在中断管理中引入一些开销。另一方面，Xenomai结构化更优，很多平台可以使用。此外，Xenomai提供一组模拟层，这在大型系统的移植中会非常有用。
RTAI和Xenomai在软件开发时用户友好都不及VxWorks。因为实时任务要在内核模式执行以实现最佳性能，程序员不能使用通常在用户空间可用的系统服务，调试变得非常困难。然而，对于Xenomai和RTAI，让用户进程成为实时却是可能的。允许实时应用用户进程的开发简化了实时系统程序开发也允许IPC Linux标准进程。实时用户进程靠一个与Linux调度器协同工作的专门的调度程序进行管理，当用户进程需要实时性时，窃取它们。与内核进程不同，为用户
进程进行上下文转换需要重新映射页表，这是一个潜在的耗时的操作。因为这个原因我们计划进一步测试量化MMU重新映射对上下文切换的影响。
网络性能是对RTAI和Xenomai最有利的支持。UDP已成功用于实时网络通信。RTnet被证实是一种良好的解决方案，尤其是的与目标板的最新版VxWorks IP堆栈的不良性能给我们的用户体验相比的时候。
RTnet只在不使能TDMA时可以达到最佳性能，这似乎最适合有大量接入点但是没有严格时间要求的系统（访问冲突的机率更高）。RFX-mod并不是运行在这样的环境下，只有不到10个控制单元。
因此我们可以说，RTAI和Xenomai都可以在RFX-mod，或者更广泛的说，在聚变装置的实时控制系统有效替代VxWorks。
参考文献
[1] A. Luchetta and G. Manduchi, ―RFX数字反馈控制的总体构架，实现和性能‖ IEEE Trans. Nucl. Sci., vol. 47, pp. 186–191, 2000.
[2] M. Cavinato, G. Manduchi, A. Luchetta, and C. Taliercio, ―核聚变实验中一般目的的实时控制框架‖ Trans. Nucl. Sci., vol. 53, pp. 1002–1008, 2006.
[3] Wind River 主页, [在线].可访问: http: www.windriver.com.
[4] J. A. Stillerman, M. Ferrara, T. W. Fredian, and S. M. Wolfe, ―Alcator C-Mod 数字实时等离子体控制系统‖ Fus. Eng. Des., vol. 81, pp. 1905–1910, 2006.
[5] B. G. Penaflor, J. R. Ferron, M. L. Walker, D. A. Piglowski, and R. D. Johnson, ―使用一个Linuxα的计算集群对DIII-D等离子放电进行实时控制‖ Fus. Eng. Des., vol. 56-57, pp. 739–742, 2001.
[6] RTAI主页, [在线]. 可访问: http:// www.rtai.org.

0.2,LinuxCNC延迟与抖动测试
Latency-test comes with LinuxCNC, you can run it with 'latency-test' from the prompt. For details, see WhatLatencyTestDoes.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test

1,RTAI 和 RTAI-lab
RTAI - Real Time Application Interface Official Website

This is the homepage of RTAI - the RealTime Application Interface for Linux - which lets you write applications with strict timing constraints for your favourite operating system. Like Linux itself this software is a community effort. If you are interested in what it does just join our mailing list and help our team!

RTAI supports several architectures:

    x86 (with and without FPU and TSC)
    x86_64
    PowerPC
    ARM (StrongARM; ARM7: clps711x-family, Cirrus Logic EP7xxx, CS89712, PXA25x)
    m68k (supporting both MMU and NOMMU cpus)

The RTAI distribution includes RTAI-Lab, a tool chain to convert block diagrams into RTAI executables and to monitor their operation on various targets.
2016.05.02访问https://www.rtai.org/看到这些资料，同日不能访问www.comedi.org

About RTAI-Lab
RTAI-Lab是一个工具链，它能编译scilab/scicoslab或matlab/simulink/rtw开发的块图成为在RTAI实时linux系统上运行的程序。RTAI-Lab被包括在RTAI分发包中。
The RTAI-Lab project provides a tool chain to develop block diagrams that can be compiled and executed on the RTAI real-time Linux operating system. RTAI-Lab is included in the RTAI distribution.

Block diagrams can be developed using either Scilab/Scicos (Open Source) or Matlab/Simulink/RTW (commercial).

See also:

    RTAI-Lab tutorial for Scilab/Scicos and Linux
    [PDF], [Tar archive with files]
    Instructions to port Matlab/Simulink diagrams to RTAI:
    RTAI-TARGET-HOWTO
    RTAI-Lab repository

RTAI-Lab main features

    Adds RTAI-Lib palette of RTAI blocks to Scicos to develop real-time block diagrams
    Enables host and target systems to communicate via net_rpc
    xrtailab virtual oscilloscope and monitoring application lets you interact with the real-time executable
    Automatic real-time code generation from Scilab/Scicos
    Possibility to port Matlab/Simulink/Real-Time Workshop projects to RTAI
    Interfaces to signal acquisition hardware and other devices supported by Comedi

RTAI-Lab bug reports

To report bugs, ask questions, or submit improvements contact roberto.bucher at supsi.ch.For bug reports please provide Linux kernel version, RTAI version, RTAI patch number, CPU type, data acqusition hardware type, Scilab version, gcc/g++/cpp versions, the block diagram that may cause the bug (.cos file), outputs using verbose option "-v", and possibly kernel logs resulting from "tail -f /var/log/syslog".
RTAI-Lab project leaders

Roberto Bucher, roberto.bucher at supsi.ch
Lorenzo Dozio, dozio at aero.polimi.it

关于RTAI-TARGET-HOWTO
安装步骤文档在https://www.rtai.org/userfiles/d ... AI-TARGET-HOWTO.txt
其中STEP 7 - Download and install the MESA library
Mesa 3D是一个在MIT许可证下开放源代码的三维计算机图形库，以开源形式实现了OpenGL的应用程序接口。
OpenGL的高效实现一般依赖于显示设备厂商提供的硬件，而Mesa 3D是一个纯基于软件的图形应用程序接口。由于许可证的原因，它只声称是一个“类似”于OpenGL的应用程序接口。由于Mesa 3D的api是和opengl 相同，具体的opengl版本浏览Mesa 3D官方网站，我们可以这么认为它就是opengl的软件模拟gpu光栅处理器的一个实现。我们知道如果要实现一个opengl，其本身是一个设备器，不能实现窗体的透明，如果我想要实现窗体透明，又想要有3D的应用，可以试试它。
Mesa是个类似OPENGL的应用程序接口，它可以在Unix/X11上运行，可以支持3dfx Voodoo1, Voodoo2, Voodoo Rush, Voodoo Banshee, Voodoo3,Matrox G200/G400, nVidia RIVA, ATI Rage Pro, Intel i810 on Linux和NVIDIA的RIVA系列显示卡。玩3D游戏的好帮手。
Mesa is an open-source OpenGL implementation, continually updated to support the latest OpenGL specification.

The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa. Several 3D accelerated drivers have been written to the DRI specification, including drivers for chipsets produced by 3DFX, AMD (formerly ATI), Intel and Matrox.

STEP 8 - Download and install the EFLTK package
EDE，A light desktop environment for UNIX operating systems. 见https://sourceforge.net/projects/ede/files/efltk/
http://osdir.com/ml/lib.fltk.general/2004-08/msg00341.html
Jamiil wrote:

> Hi!
> Does anyone know what is eFLTK? and where can I get a doc for it?
>
> TIA
>

eFLTK is dead project. But still, there are a lot of good things there -
nice widgets, database classes, net classes, utf8 etc.
As eFLTK developer I can say only one thing - now when FLTK team is focused
more on FLTK2, there is no need for eFLTK. FLTK2 (almost) matches eFLTK
developers visions.

Best regards

Dejan

--
Dejan Lekic
developer, sysadmin and DBA
http://dejan.lekic.org

2,comedi
comedi提供了驱动程序、库函数和API来与信号采集硬件交互，支持292种硬件。
Introduction

The Comedi project develops open-source drivers, tools, and libraries for data acquisition.

Comedi is a collection of drivers for a variety of common data acquisition plug-in boards. The drivers are implemented as a core Linux kernel module providing common functionality and individual low-level driver modules.

Comedilib is a user-space library that provides a developer-friendly interface to Comedi devices. Included in the Comedilib distribution is documentation, configuration and calibration utilities, and demonstration programs.

Kcomedilib is a Linux kernel module (distributed with Comedi) that provides the same interface as Comedilib in kernel space, suitable for real-time tasks. It is effectively a "kernel library" for using Comedi from real-time tasks.
Features

    Integrated real-time support for most hardware
    High-level library (comedilib)
    Application-level device independence
    Works with Linux 2.0, 2.2, and 2.4 kernels

Latest version

(probably not accurate!)

    comedi-0.7.45
    comedilib-0.7.9

Comedi and Comedilib are being actively developed, and because of this, new versions are sometimes buggy. However, reported bugs are usually quickly fixed.
Maintainer

David Schleef
ds@schleef.org

Much of Comedi has been developed by others, suggesting the need for a contributors list.
2016.05.02访问http://stm.lbl.gov/comedi/看到这些资料，同日不能访问www.comedi.org

3,NMT RT-linux
http://blog.csdn.net/kendiv/article/details/589724
已经实现的Real-Time Linux简介

Real-Time Linux主要有二个大类：

第一类以NMT RT-Linux为代表，它们的实时进程实际上是一个核心模块。所以它们事实上是一种Real-Time驱动程序，RTAI及网络系统与之有很相似的结构，差别只是在于其驱动的硬件类别不同而已。

第二类如KURT,Linux/RK及RED-Linux等，这些系统的系统响应时间受限于PC能达到的时间分辨率。虽然RED-Linux已经把这个极限推到1ms左右，但可以预期在PC的架构下要达到100us以下是很困难的。也就是说，对于要求10K
以上频率的应用是不可能使用这种架构来达成。

3.1. NMT RT-Linux

NMT是新墨西哥科技大学(New Mexico Technology)的缩写。这一套系统可以说是最早的获得成功的Real-Time Linux，它目前已发展到3.0版。这个系统是由Victor Yodaiken和它的学生Michael Barabanov所完成。这个系统的概念是“架空”Linux内核，使得Real-Time进程得以尽快的被执行。

事实上，RT-Linux中的实时任务(Real-Time Task) 其实并不是 一个Linux的进程，而是一个 Linux 的可加载式核心模块(Loadable Kernel Module)。NMT RT-Linux采用一个比较简单的做法，它不使用Linux的任何功能，把需要高度时间精确度的工作写成一个驱动程序，然后直接用PC时序芯片 (Timer Chip) 所产生的中断调用这个驱动程序。这样，它就可以绕开Linux的中断机制，从而使系统响应时间大缩短。

从这个角度看，NMT RT-Linux 其实是一个实时驱动程序，算不上是真正的 Real-Time Linux。但由于它出现得早，且其架构很符合自动控制的需求，使用者非常的多，且多半是有关自动控制的应用。

下文对这个系统将会有更详细的论述。

3.2. RTAI 最小延迟15us

RTAI是 Real-Time Application Interface 的缩写。顾名思义知道它是一套可以用来写实时应用程序的接口。大致而言，RTAI和NMT RT-Linux是相同的东西。它同样的“架空”了Linux，而直接用可加载式核心模块( Loadable Kernel Module)实现实时进程。每一个实时进程实际上就是一个可加载式核心模块。

RTAI和NMT RT-Linux 最大的不同地方在于它非常小心的在Linux上定义了 一组实时硬件抽象层(Real-Time Hardware Abstraction Layer)。RTHAL将RTAI 需要在Linux中修改的部份定义成一组程序接口，RTAI只使用这组接口和Linux沟通。这样做的好处在于我们可以将直接修改Linux核心的程序代码减至最小，这使得将 RTHAL 移植到新版 Linux 的工作量减至最低。

RTAI 采取这种途径最大的原因在于NMT RT-Linux在由2.0版移植至2.2版的过程中遇到问题，使得基于2.2版核心的NMT RT-Linux一直无法完成。所以在Dipartimento di Ingegneria Aerospaziale Politecnico di Milano的Paolo Mantegazza和他的同事们就决定自行做移植的工作，由于NMT RT-Linux的困境他们认识到必须采取上述的途径以解决将来可能再度面临的兼容性问题。

于是 RTAI 便诞生了，它是一个比 NMT RT-Linux 更好的 NMT RT-Linux，虽然后来NMT RT-Linux也随后完成移植的工作，但那已经是RTAI诞生半年以后的事了。

3.3. LXRT

由于 RTAI 无法直接使用Linux的系统调用，解决的方法是使用RT-FIFO将一个RTAI Real-Time Kernel Module和真正的Linux进程连接在一起，由这个进程负责为其调用Linux系统调用。似乎其友善性得到提高，但代价是“实时性”降低了，这时实时任务不再能进行任何抢先式操作（而“抢先式”被认为是实时系统最佳的方式），所以实时系统的优势就不再具有了。

3.4. KURT  http://www.ittc.ku.edu/kurt/

KURT是由Kansas大学所创造的系统，它和NMT RT-Linux及RTAI有很大的不同。KURT是第一个可以使用系统调用的Real-Time Linux。由于KURT只是简单的将 Linux 的进程管理器用一个很简单的时间驱动式(Time Driven)进程管理器加以取代，实时进程的执行很容易很其它非实时进程的影响。KURT直接修改Linux内核，增加Linux的抢占机制(Linux抢占机制最早是在linux 2.6版本中实现)以及改变Linux调度策略。前期的时候，Linux的时钟调度中断频率是100HZ，也就是说任务的请求调度延迟是10ms,这也就是Linux为什么不支持实时调度的原因。在KURT中，Linux采用了新的更灵活的调度机制，它不再受100HZ的限制，可以根据任务的优先级，中断的优先级任务而调用实时任务。KURT是支持软实时任务调度的。

3.5. RED-Linux 最小延迟100us

这是加州大学Irvine分校所做的系统，它和KURT类似，是一个可以使用所以Linux系统调用的Real-Time Linux。它的特点是使用“抢先检查点 (preemption point)”改善系统的反应速度。前面说过KURT的最大问题在于它受限于原有的Linux架构，使得系统的反应时间很难控制。然而在RED-Linux这一点已经被大大的改善，其2.0版的反应延迟约在100 us左右。

RED-Linux 非常有弹性的进程管理器架构也是其特点之一。它使得RED-Linux可以符合各种不同复杂度系统的需求。它将进程管理分成Dispartcher和Allocator二部份，Dispatcher在核心中执行而Allocator在用户模式执行。Allocator可以是应用程序的一部份，也可以是一个独立的单位。通常它负责将应用程序的资源请求转换成内核可以解释的格式。

4,OSADL
https://www.osadl.org/Realtime-L ... altime-linux.0.html

5, RTLCP
http://collabprojects.linuxfoundation.org/
2015年10月5日至7日在都柏林举办的 Linux 大会（LinuxCon 2015）上，Linux 基金会宣布了又一个协作项目 —— Real Time Linux 协作项目（Real Time Linux Collaborative Project ，RTLCP）。

RTLCP 的一个主要目标是推动关键代码上游审查，最终合并到 Linux 内核主线并得到持续地支持。

RTL 内核在支持其它大规模架构实时 Linux 上同样也有优势。它可以从主线内核中利用Linux 设备驱动，文件系统等等。实时的特性让它可以控制一些对时间敏感的应用上使用，例如机器人，数据采集系统，制造工厂，医药工业等。Linux 基金会表示， RTL 将聚集工业领导者和专家来发展这项技术。

Google 是 RTL 的创始白金会员，黄金会员包括美国国家仪器，OSADL 和德州仪器，白银会员包括 Altera 公司，ARM，英特尔和 IBM。

6, L4/Fiasco  http://os.inf.tu-dresden.de/L4
L4/Fiasco系统是完全不同与RTLinux和RTAI机制的实时系统，它可以支持软实时任务调度。L4最先由Jochen Liedtke开发的第二代微内核。目前，它已经变成了第二代微内核的一个标准，基于这个标准，有很多L4 API的实现。其中一个实现就是Fiasco，它是在德国德累斯顿大学开发的。为了强调Fiasco跟L4之间的这种关系，我们把Fiasco一般称L4/Fiasco。L4/Fiasco与其它L4的实现不同的是L4/Fiasco是一个具有实时特性的微内核，L4/Fiasco是DROPS项目的一个核心子项目，它同时提供了很多软件包，以方便基于L4/Fiasco的程序设计。因为L4/Fiasco是具有实时功能的微内核，而在实时程序的设计中，一般可以分为实时任务和非实时任务。对于使在L4/Fiasco上运行非实时任务的程序可以兼容Linux程序，设计者们修改了Linux内核，使得整个Linux可以运行在L4/Fiasco之上。目前L4Linux的最新版本是基于Linux-2.6.18的。

7,XtratuM   http://www.xtratum.org
     XtratuM是我们介绍的Real-Time Linux系统中最年轻的一个，2003年XtratuM-0.1版本的发布标志者XtratuM的诞生，到现在为止，XtratuM共发布了三个版本XtratuM-0.1，XtratuM-0.3和刚刚发布的XtratuM-1.0。XtratuM与上面列举的real-time linux系统的最大不同之处是XtratuM采用超微内核设计理念，它从影响实时系统性能最重要的两个方面中断和定时器着手，建立一个超微的系统内核，实现对中断和定时器的虚拟。从而使上层系统，例如Linux，RTLinux系统以域(domain)的方式运行。内存分离的保护机制提高了系统的安全性，Linux做为最低优先级的域只有在无实时任务的时候调用。域和域之间可以通过FIFO或者SHM(Share Memory)通信。从另一个角度看，XtratuM是一个实时虚拟机，它可以直接运行在底层硬件上，并且向上层系统提供标准的中断、时钟接口。从而提高了上层系统的可移植性。当前RTLinux社区正在将RTLInux移植到XtratuM上面。
http://www.xtratum.org/main/projects

8,linux 2.6.22  https://www.kernel.org/pub/linux/kernel/projects/rt/
The Real Time Preempt Patch:
Index of /pub/linux/kernel/projects/rt         -   
2.6.22/                     08-Aug-2013 18:24    -


9,MontaVista linux
MontaVista正在为Linux增添实时功能，提高其速度，使其更强壮，其目的是使Linux能够在瞬间可靠地处理数据和发布结果。MontaVista的首席执行官吉姆说，新软件是一大进步，它极大地提高了Linux的吸引力。

Linux最初在服务器上获得了成功，现在已经在向包括手机和家庭网络工具在内的各类设备蔓延。它在对实时处理要求较高的设备中还不太普及，对实时处理要求较高的设备的二个例子是:汽车引擎电子设备、导弹导航系统。

10,LynxOS
LynxOS是一个分布式、嵌入式、可规模扩展的实时操作系统，它遵循POSIX.1a、POSIX.1b和POSIX.1c标准。它最早开发于1988年。
LynuxWorks等其它公司也在销售实时版本的Linux。吉姆说，这些公司通常是在Linux上再开发一个独立的实时操作系统，在Linux中增添内置的实时功能则有很大不同之处，这可能使嵌入式Linux的市场翻一番而达到30亿美元。

Wind River的营销总监约翰表示，Linux最终将有强大的实时功能，但MontaVista的方法是错误的:它采用了非标准的代码。约翰认为MontaVista的软件是“专有版Linux”，与Linux社区没有任何联系。它带来的问题比解决的问题还要多。他说，因为MontaVista的功能不是标准Linux的一部分，因此买主将被捆绑到MontaVista的版本上。这与Linux的主要目的之一是相违背的:得到各大高科技厂商支持的业界标准。很少有Linux公司的规模能够提供非标准版本Linux所需要的支持。  

11,QNX
QNX是一个分布式、嵌入式、可规模扩展的实时操作系统。它遵循POSIX.1 (程序接口)和POSIX.2 (Shell和工具)、部分遵循POSIX.1b(实时扩展)。它最早开发于1980年，到现在已相当成熟。

12,Xenomai
产品定义
Xenomai 是一种采用双内核机制的Linux 内核的强实时扩展。由于Linux 内核本身的实现方式和复杂度，使得Linux 本身不能使用于强实时应用。在双内核技术下，存在一个支持强实时的微内核，它与Linux 内核共同运行于硬件平台上，实时内核的
优先级高于Linux 内核，它负责处理系统的实时任务，而Linux 则负责处理非实时任务，只有当实时内核不再有实时任务需要处理的时候，Linux 内核才能得到运行的机会。
Xenomai 基于Adeos(Adaptive Domain Environment for Operating System)实现双内核机制，图3.1 显示了Xenomai、Adeos 和Linux 这三个软件实体之间的相互关系。Adeos 是扩展Linux 的基础环境，有必要对其做一个较详细的介绍。
产品简介
Adeos 的设计目标是为操作系统提供一个灵活的、可扩展的自适应环境，在这个环境下，多个相同或不同的操作系统可以共存，共享硬件资源。目前，Adeos 是基于Linux 内核实现的，主要的应用是在Linux 的实时化方面，使基于Linux 的系统能满足强实时的要求（例如Xenomai 和RTAI3.2 以上版本都是基于Adeos 实现的）。在基于Adeos 的系统中，每个操作系统都是在独立的域内运行（但不一定所有的域实现的都是操作系统，也可以是完成其它功能的软件实体），每个域可以有独立的地址空间和类似于进程、虚拟内存等的软件抽象层，而且这些资源也可以由不同的域共享。
对于一个计算机系统来说，系统的运行是由内部和外部的中断和异常所触发的，例如系统时钟中断对操作系统来说就是最重要的。所以，Adeos 的主要工作就是管理硬件的中断，根据域的优先级依次执行相应域的中断服务程序，从而驱动域内的系统运行；同时，Adeos 还提供域之间的通信机制实现域的调度等。
为了实现对中断的管理和域之间的优先级控制，Adeos 使用了中断管道(Interrupt Pipe)的概念。Adeos 通过中断管道在不同的域之间传播中断，而且提供了相应的机制可以让域改变自己在中断管道中的优先级。
Xenomai 在Adeos 系统中的域优先级高于Linux 域，每当中断到来之后，Adeos先调度Xenomai 对该中断进行处理、执行中断相应的实时任务，只有当Xenomai 没有实时任务和中断需要处理的时候，Adeos 才会调度Linux 运行，这就保证了Xenomai的中断响应速度和实时任务不受Linux 的影响，从而提供了实时系统的可确定性。
Xenomai 实时内核为开发强实时应用提供了丰富的功能，主要包括实时线程调度与管理、用户空间实时任务支持、线程同步服务、时钟服务、中断服务、动态内存申请和实时对象注册服务等。
Xenomai简介及其Adeos实现

Xenomai是一个自由软件项目，提供了一个基于Linux的实时解决方案。它可以提供工业级RTOS的性能，而且完全遵守GNU／Linux自由软件协议。目前最新稳定版本是2．4．5。

Xenomai项目起始于2001年。从2003年夏天起，Xenomai和RTAI有了两年时间的合作，期间开发了广为人知的RTAI／fusion项目分支。到2005年，Xenomai项目又重新独立出来。而从2．0．0版本开始，Xenomai在硬件平台的移植就一直是基于Adeos构架来实现的。

在基于Adeos的系统中，分为多个域。每个域中独立运行一个操作系统(或者是实现一定功能的程序模块)，每个域可以有独立的地址空间和类似于进程、虚拟内存等的软件抽象层。在各个域下层有一个Adeos通过虚拟中断等方法来调度上面的各个域。在基于Adeos的系统中，存在着A、B、C、D四种类型的交互，如图1所示。
A类交互是各个域直接操作硬件设备，包括访问内存等；B类交互指当Adeos接收到硬件中断后，会根据中断来对相应的域进行中断服务；C类交互指当前域内的操作系统主动向Adeos请求某些服务；D类交互是指Adeos接收硬件产生的中断和异常，同时也可以直接控制硬件。其中，Adeos实现的功能主要包括中断管道机制(I—Pipe)、域管理模块和域调度模块功能。

Xenomai用户层实时的实现

Xenomai除了在内核层利用Adeos实现了硬实时外，它在用户空间也有很好的实时性。在S3C2410平台上，为了实现用户层的实时，Xenomai实现了一个硬件计数器——Decrementer。这个硬件计数器可以在用户空问里很好地模拟TSC(Time Stamp Counter，时间戳计数器)。

同时，Xenomai在Linux内核中加入了一个全新的数据结构__ipipe_tscinfo，可以通过此数据结构变量存放用户层需要的数据。该数据结构组成如下：
在用户层，应用程序通过系统调用可以迅速得到struct_ipipe_tscinfo结构体中的数据。而且为了避免受到缓存的影响，Xenomai将此结构体变量存放在Linux的向量页中。

内核通过函数_ipipe_mach_get_tscinfo来填充struct_ipipe_tscinfo结构体变量中的各项内容：
Xenomai多API构架

除了提供Linux硬实时，Xenomai的另一个目的是使基于Linux的实时操作系统能提供与传统的工业级实时操作系统(包括VxWorks、 pSOS+、VRTX或者uITRON)功能相同的API。这样，可以让这些操作系统下的应用程序能够很容易地移植到GNU／Linux环境中，同时保持很好的实时性。

Xenomai的核心技术表现为使用一个实时微内核(real—time nucleus)来构建这些实时API，也称作“skin”。在实时核复用的基础上，一个skin可以很好地模拟一种实时操作系统的API。它的结构图可以参考图2。
图2中，Native是Xenomai自带的API，各类API都有着同等的地位，都独立地基于同一个实时微内核。这样做可以让内核的优点被外层所有的 API很好地继承下来。更重要的是，实时微内核提供的服务被外层各种API以不同的方式表现出来，由此可以增强整个系统的强壮性。

编制实时程序时，在很多实时操作系统上只能在内核层实现；而编制实时内核模块时，会受到内核的限制，比如有些实时内核不支持浮点运算，模块出错时容易使整个系统挂起，而且内核模块的调试比较困难。Xenomai能够支持较好的用户层实时，这为编制实时性要求不是非常高的实时程序提供了一个有效途径。下面这个用户层实时例程使用的是Xenomai提供的Native API：

13,adeos  http://home.gna.org/adeos/
RTAI和xenomai都使用了adeos架构。
The purpose of Adeos is to provide a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single OS.

To this end, Adeos enables multiple prioritized domains to exist simultaneously on the same hardware. For instance, we have successfully inserted the Adeos nanokernel beneath the Linux kernel, opening a full range of new possibilities, notably in the fields of SMP clustering, patchless kernel debugging and real-time systems for GNU/Linux.

The complete Adeos approach has been thoroughly documented in a whitepaper entitled « Adaptive Domain Environment for Operating Systems  ».

uesoft

FreeEMS  http://forum.diyefi.org/viewtopic.php?f=54&t=1241
FreeEMS是一个开源免费的引擎管理系统。一般在修改一辆车时需要一个引擎管理系统。

FreeEMS is an Engine Management System (EMS) with Free (as in freedom and price) source code and hardware designs. Typically you need an EMS when you modify a car. The reasons for using an EMS like FreeEMS include some of the following:

    Fuel injection and/or electronic ignition on an old carburettor/distributor/points engine
    Transplant a newer engine into an older car without some things the original ECU needs
    Any power adders, such as turbo, supercharger, nitrous, camshafts, ITBs, extractors, etc.
    Education and learning about EFI and electronic ignition systems on engines
    Data-logging and fine tuning
    Controlling more solenoids than an OEM (GM/Ford/Toyota/Mazda/etc) ECU can
    In the case of FreeEMS, running custom control strategies

uesoft

这里提供一组实时性测试方面的数据，通过任务主动释放CPU权利来测试任务的切换速度
测试条件 ：STM32F103VET6，Cortex-M3内核，72Mhz，
                   软件用的MDK4.54,  1级优化。
                   测试10000次，2ms测试一次，然后求平均

RTX        V4.5          252个时钟周期
uCOS-II    V2.92.07      354个时钟周期
embOS      V3.86         389个时钟周期
FreeRTOS   V7.4.2        514个时钟周期（可能是这种测试方法对这个OS不太适合，另一个时间切换的时间是374个时钟周期）
uCOS-III   V3.03.01      576个时钟周期


RTX在众多项的数据面前还是很强的，主要是它能充分的发挥M3/M4的性能

uesoft

2016-11-02 21:47:39 搜索github.com结果：
key      repository results
wifi        12,726
bluetooth        11,635
zigbee        724
freertos 973
zephyr         526
contiki        517
ucos 315
6lowpan   109
uip        1084
lwip        376
snmp        2,141
modbus        1,441
canopen        115
profibus        9
powerlink        35
ethercat        

uesoft

4个linux函数库比较 musl-libc, uClibc, dietlibc, glibc

http://www.etalabs.net/compare_libcs.html

Comparison of C/POSIX standard library implementations for Linux

A project of Eta Labs.

The table below and notes which follow are a comparison of some of the different standard library implementations available for Linux, with a particular focus on the balance between feature-richness and bloat. I have tried to be fair and objective, but as I am the author of musl, that may have influenced my choice of which aspects to compare.

Future directions for this comparison include detailed performance benchmarking and inclusion of additional library implementations, especially Google's Bionic and other BSD libc ports.

Bloat comparison         musl        uClibc        dietlibc        glibc
Complete .a set         426k         500k         120k         2.0M †
Complete .so set         527k         560k         185k         7.9M †
Smallest static C program         1.8k         5k         0.2k         662k
Static hello (using printf)         13k         70k         6k         662k
Dynamic overhead (min. dirty)         20k         40k         40k         48k
Static overhead (min. dirty)         8k         12k         8k         28k
Static stdio overhead (min. dirty)         8k         24k         16k         36k
Configurable featureset         no         yes         minimal         minimal
Behavior on resource exhaustion         musl        uClibc        dietlibc        glibc
Thread-local storage         reports failure         aborts         n/a         aborts
SIGEV_THREAD timers         no failure         n/a         n/a         lost overruns
pthread_cancel         no failure         aborts         n/a         aborts
regcomp and regexec         reports failure         crashes         reports failure         crashes
fnmatch         no failure         unknown         no failure         reports failure
printf family         no failure         no failure         no failure         reports failure
strtol family         no failure         no failure         no failure         no failure
Performance comparison         musl        uClibc        dietlibc        glibc
Tiny allocation & free         0.005         0.004         0.013         0.002
Big allocation & free         0.027         0.018         0.023         0.016
Allocation contention, local         0.048         0.134         0.393         0.041
Allocation contention, shared         0.050         0.132         0.394         0.062
Zero-fill (memset)         0.023         0.048         0.055         0.012
String length (strlen)         0.081         0.098         0.161         0.048
Byte search (strchr)         0.142         0.243         0.198         0.028
Substring (strstr)         0.057         1.273         1.030         0.088
Thread creation/joining         0.248         0.126         45.761         0.142
Mutex lock/unlock         0.042         0.055         0.785         0.046
UTF-8 decode buffered         0.073         0.140         0.257         0.351
UTF-8 decode byte-by-byte         0.153         0.395         0.236         0.563
Stdio putc/getc         0.270         0.808         7.791         0.497
Stdio putc/getc unlocked         0.200         0.282         0.269         0.144
Regex compile         0.058         0.041         0.014         0.039
Regex search (a{25}b)         0.188         0.188         0.967         0.137
Self-exec (static linked)         234µs         245µs         272µs         457µs
Self-exec (dynamic linked)         446µs         590µs         675µs         864µs
ABI and versioning comparison         musl        uClibc        dietlibc        glibc
Stable ABI         yes         no         unofficially         yes
LSB-compatible ABI         incomplete         no         no         yes
Backwards compatibility         yes         no         unofficially         yes
Forwards compatibility         yes         no         unofficially         no
Atomic upgrades         yes         no         no         no
Symbol versioning         no         no         no         yes
Algorithms comparison         musl        uClibc        dietlibc        glibc
Substring search (strstr)         twoway         naive         naive         twoway
Regular expressions         dfa         dfa         backtracking         dfa
Sorting (qsort)         smoothsort         shellsort         naive quicksort         introsort
Allocator (malloc)         musl-native         dlmalloc         diet-native         ptmalloc
Features comparison         musl        uClibc        dietlibc        glibc
Conformant printf         yes         yes         no         yes
Exact floating point printing         yes         no         no         yes
C99 math library         yes         partial         no         yes
C11 threads API         yes         no         no         no
C11 thread-local storage         yes         yes         no         yes
GCC libstdc++ compatibility         yes         yes         no         yes
POSIX threads         yes         yes, on most archs         broken         yes
POSIX process scheduling         stub         incorrect         no         incorrect
POSIX thread priority scheduling         yes         yes         no         yes
POSIX localedef         no         no         no         yes
Wide character interfaces         yes         yes         minimal         yes
Legacy 8-bit codepages         no         yes         minimal         slow, via gconv
Legacy CJK encodings         no         no         no         slow, via gconv
UTF-8 multibyte         native; 100% conformant         native; nonconformant         dangerously nonconformant         slow, via gconv; nonconformant
Iconv character conversions         most major encodings         mainly UTFs         no         the kitchen sink
Iconv transliteration extension         no         no         no         yes
Openwall-style TCB shadow         yes         no         no         no
Sun RPC, NIS         no         yes         yes         yes
Zoneinfo (advanced timezones)         yes         no         yes         yes
Gmon profiling         no         no         yes         yes
Debugging features         no         no         no         yes
Various Linux extensions         yes         yes         partial         yes
Target architectures comparison         musl        uClibc        dietlibc        glibc
i386         yes         yes         yes         yes
x86_64         yes         yes         yes         yes
x86_64 x32 ABI (ILP32)         experimental         no         no         non-conforming
ARM         yes         yes         yes         yes
Aarch64 (64-bit ARM)         experimental         no         no         yes
MIPS         yes         yes         yes         yes
SuperH         experimental         yes         no         yes
Microblaze         yes         partial         no         yes
PowerPC         yes         yes         yes         yes
Sparc         no         yes         yes         yes
Alpha         no         yes         yes         yes
S/390         no         no         yes         yes
OpenRISC 1000 (or1k)         yes         no         no         not upstream
MMU-less microcontrollers         no         yes         no         no
Build environment comparison         musl        uClibc        dietlibc        glibc
Legacy-code-friendly headers         partial         yes         no         yes
Lightweight headers         yes         no         yes         no
Usable without native toolchain         yes         no         yes         no
Respect for C namespace         yes         LFS64 problems         no         LFS64 problems
Respect for POSIX namespace         yes         LFS64 problems         no         LFS64 problems
Security/hardening comparison         musl        uClibc        dietlibc        glibc
Attention to corner cases         yes         yes         no         too much malloc
Safe UTF-8 decoder         yes         yes         no         yes
Avoids superlinear big-O's         yes         sometimes         no         yes
Stack smashing protection         yes         yes         no         yes
Heap corruption detection         yes         no         no         yes
Misc. comparisons         musl        uClibc        dietlibc        glibc
License         MIT         LGPL 2.1         GPL 2         LGPL 2.1+ w/exceptions

uesoft

其他libc库

https://www.uclibc.org/other_libs.html

uesoft

开源内存数据库

FastDB、SQLite、Berkeley DB、GigaBASE、VoltDB、geode、MySQL的MEMORY存储引擎、Microsoft SQL Server Compact

主流内存数据库简要比较
http://blog.csdn.net/nanfeiyannan/article/details/9003009

eXtremeDB已经广泛应用于众多行业及领域，如：网络设备、消费电子、国防、航空航天、工业控制、轨道交通、能源电力、医疗设备，地理信息、汽车电子,以及金融实时交易、通信技术、互联网等，得到了国内外许多知名客户的一致好评与青睐。
McObject从一开始就创建了eXtremeDB内存数据库系统，这个系统尤其适合新兴网络和连接设备。eXtremeDB跨多硬件和软件平台部署，在内存处理架构优化上有无法比拟的优势。小到50K的代码尺寸却有运营商级别的提升，如High Availability和Transaction Logging，eXtremeDB实时数据库通过今天智能网络的电信架构设备和高传输速率数据被用于资源有限的移动设备。
McObject解决方案在全球的许多关键任务运用中都有应用。eXtremeDB数据库的实时数据管理应用包括Boeing, Motorola, JVC, F5 Networks, Tyco Thermal Controls, Genesis Microchip, EFJohnson, Peiker acustic还有其他。
到目前为止，McObject已经建立了全球合作伙伴和代理网络。eXtremeDB内存数据库在性能上已经取得重大的成就，包括
· 在嵌入式数据管理中，最高级别的持久性，包括eXtremeDB High Availability (HA)和Transaction Logging
· 小于30K的小尺寸HTTP服务器eXtremeWS，为监控和控制嵌入式设备，以及eXtremeDB管理数据存储提供连接。
· XML support 为eXtremeDB更新基础的数据库结果提供无缝的基于XML的数据库交换和简化方法。
· eXtremeSQL支持SQL，eXtremeSQL是eXtremeDB内存数据库在SQL数据库程序架构语言下实现的高性能。
McObject还发布了Perst，Perst是针对Java和C#，开源的、面向对象的嵌入式数据库。除了高性能和小尺寸，Perst最大的成果之一就是在这些快速增加的程序设计语言中，它独特的“透明持久性”功能和在处理对象时的简单程度。
总部
McObject 总部位于美国华盛顿的Issaquah。我们致力于开发优质的产品和给客户和合作伙伴提供一流的支持。McObject成熟的技术和优质的服务使客户能把目光集中于以最低的开发成本把最优质的产品快速推向市场。
http://www.mcobject.com/embedded_database_products

eXtremeDB 与 SQLite的对比 2015-05-25 00:02:38
http://blog.chinaunix.net/uid-26904793-id-5047238.html


http://blog.csdn.net/tanga842428/article/details/52769732

uesoft

8 种 NoSQL 数据库系统对比
http://blog.jobbole.com/1344/

uesoft

libcrystax 一个第三方android ndk库 https://www.crystax.net/en/android/ndk

Google's Android NDK不够标准化,移植大量已有代码库非常痛苦,幸好有了CrystaX NDK,让这件事变得简单很多.
翻译自https://www.crystax.net/en/android/ndk
CrystaX NDK是Google's Android NDK的一个替代方案,提供了一些很棒的新功能和大量的bugfix和改进.
它的主要目的是让Android开发者更高效地运用标准化代码进行native开发. 通过使用那些支持多平台(IOS,OS X,Windows,Linux等等)的标准代码库,它显著减少了开发时间,不需要再为Android平台做特殊修改(甚至于为Android特殊定制实现那些在其他平台早已实现的功能).
Android libc(Bionic)功能有限,版本之间还不尽相同,开发者需要做很多运行时版本检测和兼容性适配的额外工作.
CrystaX NDK提供的libcrystax屏蔽了Android版本兼容性差异,甚至重写了很多libc函数,使得应用程序在所有Android设备上表现一致.
CrystaX NDK的另一个目的是为Android Native开发提供一些很棒的新功能.例如: Objective-C和其他编程语言的支持.
这个项目最初是2009年Dmitry Moskalchuk的个人项目,只是为了添加一些Google Android NDK缺失的C++特性(exceptions,RTTI,C++标准库),后来越加越多,不断优化一步步步变成了Android native开发的最佳进化.很多开源和商业化项目使用CrystaX NDK进行Android开发和移植.
现在CrystaX NDK提供了大量新功能,使得Android native开发更容易,详见以下关键特性.



libhybris及EGL Platform-在Glibc生态中重用Android的驱动   http://blog.csdn.net/jinzhuojun/article/details/41412587

libhybris主要作用是为了解决libc库的兼容问题，目的是为了在基于GNU C library的系统运行那些用bionic编译的库（主要是Android下的闭源HAL库）。它在Ubuntu touch, WebOS, Jolla Sailfish OS等系统中都有使用。因为这些系统都是基于glibc生态的，然而现有的硬件厂商提供的driver多是为Android而写的，自然也是用bionic编译的。那么问题来了，说服厂商再写一套驱动不是那么容易的，就算写出来也需要经过一段时间才能变得成熟。那如何让基于glibc的系统能够重用现有Android的driver呢？这就需要像libhybris这样的兼容层。

uesoft

2019年5月，华为在美国通信市场受到诸多限制之际，俄罗斯通信部向华为抛出了橄榄枝，其提供的Aurora前身为Sailfish系统，由诺基亚前员工组建的公司开发，该系统基于MeeGo，可以运行大部分Android应用。
2010年，诺基亚与英特尔合作开发了MeeGo系统，但应用该系统之后的第二年，诺基亚就转向与微软合作的Windows Phone系统，将MeeGo打入了冷宫。在2011年10月，MeeGo的研发团队选择了另立门户，组建了名为Jolla的新公司。
Jolla 的CEO Jussi Hurmola表示，诺基亚选择了新的系统，但他们将坚守MeeGo系统的未来。Jolla公司成立后，基于MeeGo创建了一套全新操作系统系统Sailfish。
但由于2012年Android系统已被广大用户所熟知并接受，Sailfish便一直没能“大红大紫”。其实Jolla也为Sailfish的发展做出过很多努力，他们在早期就接触过中国的小米和魅族公司，但他们都选择了使用更容易融入市场的Android系统。
2013年，Sailfish新的版本更新中内置了一套可以运行Android软件的虚拟程序，实现了Sailfish系统与Android的兼容。
2015年，俄罗斯贸易投资公司ESN集团CEO Grigory Berezkin拿下了Jolla公司的大部分股权。直到2018年，Sailfish才公开更名为Aurora。
Aurora与Sailfish最大区别是剥离了Android兼容层，主攻安全方向。也就是说，Aurora将无法像Sailfish一样能运行Android应用。目前Aurora主要供俄政府部门和国企使用。
据调研机构CounterPoint发布的2018年第四季度俄罗斯手机市场报告显示，华为手机占俄罗斯手机市场份额28%，同比增长91%，取代三星成为了俄罗斯最畅销的的智能手机品牌。
Aurora操作系统很可能是华为针对俄罗斯市场的一次试水，搭载销往俄罗斯的华为手机使用。

uesoft

Zircon 是 Google 新操作系统 Fuchsia 的内核，基于 LK - Little Kernel 演变而来。而 Little Kernel 一直作为 Android 系统的 Bootloader 的核心而存在。Zircon 在此基础上增加了 MMU，System Call 等功能。
Zircon 目前支持 X86/X64 和 ARM 两种 CPU 平台，下面我将以 ARM64 为例，一行行分析 Zircon 内核的早期启动过程，看一下 Zircon 和 ARM64 是如何完成平台初始化的，这部分由汇编实现。
需要事先声明的是，本人平时从事的是 Android 开发，对于 ARM 了解有限，此次源码阅读也会参考一些其他资料，其中难免会有一些错误，望广大读者谅解。

Zircon 调度
背景
任何调度器首要的责任都是在所有请求的线程之间分配处理器的有限时间资源。在通用操作系统中，尽可能实现公平的分配，确保所有的线程都能够取得一定的进展。
Zircon的调度器由Little Kernel的调度器进化而来。所以是以一个最小化的调度器实现开始，并且随着工程的成长，可依据需求进行扩展。
设计
概述
本质上，机器中的每个逻辑处理器上运行着一个调度器。这些调度器独立运行，通过IPI（Inter-Processor Interrupts核间中断）进行彼此协调。尽管如此，还是每个处理器负责运行在其上线程的调度。参见以下的CPU Assignment部分，获取线程如何决定运行在哪个处理器，以及怎样/何时进行迁移的信息。
每个处理器有其自身的优先级队列。系统中的每个优先级对应一个队列，当前为32个。注意这些为FIFO队列，并不是优先级队列结构体。在每个队列中都是一个有次序的等待执行的运行线程链表。当可运行新线程的时候，调度器简单的查看包含有线程的最高优先权队列，弹出队列头部的线程并执行。参见以下 优先级管理部分获得关于如何决定哪个线程分配在哪个队列的详细信息。如果所有队列中都没有可运行的线程，执行空闲线程。参见以下 [Realtime and Idle Threads] 获取更多详情。
每个线程当被选择开始执行时，授予相同的时间片长度(THREAD_INITIAL_TIME_SLICE)。如果其使用完了整个时间片，将其重新插入到相应优先级队列的末尾。尽管如此，如果上一次运行的时间片还有剩余，将其插入到相应优先级队列的头部，以便可以尽快的恢复继续运行。当再次被选择运行时，时间仅为之前时间片的剩余时长。
当调度器从优先级队列选择一个新线程运行时，同时设置处理器抢占定时器，时间为一个完整的时间片，或者之前时间片的剩余时长。当定时器到期时，调度器将停止当前进程的执行，将其放回相应的队列中，选取另一个进程再从头开始。
如果一个线程阻塞在等待共享资源，其将被由所在的优先级队列中取出，放置到该共享资源的等待队列中。当阻塞解除时，该进程被重新插入到一个合适处理器(CPU Assignment) 的相应优先级队列中，并且，如果其还有剩余的时间片，将其插入到队列的头部以便尽快运行处理。
优先级管理
三个不同的因素用来决定线程的实际优先级，实际的优先级正是又来决定其放入哪个队里的。
第一个因素是基本优先级，即为线程请求的优先级。目前由32个优先级别，0表示最低优先级，31表示最高优先级。
第二个因素是优先级提升值。其范围在[-MAX_PRIORITY_ADJ, MAX_PRIORITY_ADJ]之间，用来在基本优先级基础上做偏移，以下情况对此值进行修改：
当线程解锁时，可能是等待共享资源后或者睡眠，给与其1个优先级提升值.
当进程放弃执行 (自愿放弃控制), 或者自愿开启重调度，将其提升值减去1，最小为0（不能是负值）.
当进程被抢占并且使用完了整个时间片，其提升值递减1，可以为负值.
第三个因素是继承优先级。如果一个线程正在操作共享资源，并且阻塞了另外一个优先级更高的线程，将提高当前线程优先级，以允许其尽快执行完成，以便另外的更高优先级的线程得以继续执行。
如果继承优先级存在的话，线程的实际优先级等于继承优先级，否则，等于基本优先级与提升值的计算和。当由于以上因素的改变，导致实际优先级改变时，调度器将线程移动到一个新的优先级队列，并且重新调度处理器。如果其是当前最高优先级的任务，其可占用处理器，否则，如果优先级不是最高，放弃处理器占用。
系统的目的是保证交互类型的线程被尽快的服务。因为这些线程通常是直接与用户交互，有可能引起可察觉到的延迟。这类进程通常做很少的工作，大部分时间阻塞等待其他用户事件。所以在解锁之后需要获得优先级的提高，而后台做大部分的处理工作的线程可接受优先级惩罚，可使用整个的时间片。
处理器分配与迁移线程可通过设置处理器亲核性掩码来请求在哪个处理器上运行，掩码为32位，0b001表示处理器1，0b100表示处理器3，0b101表示处理器1或者处理器3。通常情况下会遵照请求的掩码，但是如果请求的处理器都未在活动状态，将被分配另外的处理器。特别的，如果进程"绑定"在一个处理器，即其掩码中仅包含一个处理器，当此处理器不可用时，此线程将得不到服务，直到处理器再次可用。详细信息参见CPU Activation。
当为进程选择处理器时，调度器将按以下条件顺序进行:
运行选择的处理器，如果其空闲并且在亲核性掩码中.
上一次线程运行的处理器, 如果其空闲并且在亲核性掩码中.
亲核性掩码中的任意空闲处理器.
上一次线程运行的处理器，如果其在活动状态并且在亲核性掩码中.
运行选择的处理器，如果其是亲核性掩码中的唯一处理器，或者掩码中的所有处理都处在非活动状态.
亲核性掩码中的任意活动处理器。
如果线程运行在非亲核性掩码中的处理器上（由于以上的条件5），调度器在每次该线程被抢占，放弃处理器占用和资源重调度时，尝试纠正此情况。通用，如果线程改变了其亲核性掩码的值，调度器需要迁移它。
每次线程由等待共享资源，或者睡眠返回时，或者需要赋予优先级队列时，调度器将根据以上的逻辑重新评估线程的处理器选择，以及迁移线程。
处理器激活
当处理器被置为不活动时，其被关闭，并从系统中移除。调度器将其上运行的所有线程转移到其它的处理器。唯一的例外是pinned钉在此处理器上的线程，它们的亲核性掩码中仅有此不活动的处理器。这些线程被放入运行队列但是不会被服务，直到该处理器再次激活.
当处理器再次激活时，将服务等待的钉在此处理器上的线程，以及那些运行在非亲核性处理器上的线程，这类线程将尽快的被其处理器的调度器依据以上原则迁移到刚刚激活的处理器上。不存在由于重平衡分配到新唤醒CPU的线程，但是它可能更频繁的空闲，所有根据以上的逻辑CPU Assignment and Migration应看到更多的线程迁移。
实时性和空闲线程
有一些特殊的线程会有一些不同的对待.
空闲线程在没有其它可运行线程时执行。每个处理器上有一个空闲线程，它并不在优先级队列中，但是实际上在一个优先级为-1的队列。用来监测空闲时间，也可被平台使用作为低功耗等待模式。
实时性线程（标记为THREAD_FLAG_REAL_TIME）允许没有强占的运行，一直运行到阻塞、放弃执行或者手动重调度。
---------------------
版权声明：本文为CSDN博主「redwingz」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/sinat_20184565/article/details/93124622
带注释的 Zircon 内核源码（未完成）：https://github.com/ganyao114/zircon/tree/doc

uesoft

http://www.techweb.com.cn/ucweb/news/id/2754974

腾讯开源自研轻量级物联网操作系统TencentOS tiny
2019-09-18 16:51:07 来源: IT之家 作者:远洋

9月18日消息 据腾讯科技报道，腾讯宣布将开源自主研发的轻量级物联网实时操作系统TencentOS tiny。

报道称，相比市场上其它系统，腾讯TencentOS tiny在资源占用、设备成本、功耗管理以及安全稳定等层面极具竞争力。该系统的开源可大幅降低物联网应用开发成本，提升开发效率，同时支持一键上云，对接云端海量资源。TencentOS tiny提供业界最精简的RTOS内核，最少资源占用为RAM 0.6KB，ROM 1.8KB，极大地降低硬件资源占用。
目前，TencentOS tiny已支持意法半导体、恩智浦、华大半导体、瑞兴恒方、国民技术等主流厂商多种芯片和模组。
腾讯物联网团队表示：“将腾讯自主研发的物联网操作系统TencentOS Tiny开源，不仅可以将腾讯在物联网领域的技术和经验和全球开发者分享，还能够汲取全球物联网领域的优秀成果和创新理念，最终推动整体物联网生态的繁荣以及万物智联时代的到来。”
据权威资料显示，全球物联网市场规模发展迅猛，2018年，仅国内物联网市场容量已经超过1万亿，预计2020年国内物联网市场容量可望超过1.5万亿。
TencentOS tiny Github开源地址：https://github.com/Tencent/TencentOS-tiny

uesoft

为汽车量身定做的Linux系统—AGL呼之欲出
2020-03-12来源: EEWORLD关键字：汽车  Linux  AGL

翻译自——Embedded+网络整理

汽车可不单单是由引擎和华丽外壳组成的，汽车里还有许许多多的计算部件，而 Linux 就在它们里面跑着。Linux 不只运行在你的服务器和手机（安卓）上。它还运行在你的车里，听起来有意思吧。这要从AGL说起…

在听说了多年有关汽车级Linux (AGL)及其所有潜力的介绍之后，直到现在，我们才开始看到从独立的合同市场获得AGL（Automotive Grade Linux）相关专业知识的商业兴趣。虽然在过去几年里，合作伙伴社区对AGL知识的需求一直在稳步增长，但到2020年，似乎可以看到对基于商业汽车项目的AGL相关技能的需求也在大幅增长。



这里简单讲一下AGL是干嘛的？

Automotive Grade Linux是一个协作开源项目，由Linux 基金会管理，它将汽车制造商，供应商和技术公司聚集在一起，以加速开发和采用完全开放的联网汽车软件堆栈。他们的宗旨是：“以Linux为核心，建立一个通用的、基于Linux的联网汽车内部使用开源平台，以实现新功能和技术的快速开发。” Linux基金会汽车总经理Dan Cauchy也曾表示：“我们的目标是创建一个整个行业可以作为向消费者提供联网汽车体验的基础的平台。”

AGL成长史

2014年，Linux 基金会发布了开源 AGL（Automotive Grade Linux）规范 1.0 版本，它是业界首个开放式车载信息娱乐（IVI）软件规范。这也是第一次汽车制造商、供应商以及开源开发者可以基于同一个规范进行协作，该规范很好的定义了将来的联网汽车提供基于 Linux 的软件堆栈。

在此之后，AGL发布了首个 AGL 参考实现平台，平台基于 Tizen IVI 平台，用来运行 HTML5 应用。基于Tizen IVI，AGL添加了直观的UI / UX以及用HTML5和JavaScript编写的各种应用程序，并支持多种硬件架构。

看到AGL的好处之后，各大科技公司纷纷前来报到，Movimento、甲骨文、高通、德仪、UIEvolution和VeriSilicon、JVC KENWOOD Corporation，Linaro和OpenSynergy等软件厂商，先后都加入到了Linux开源车载系统AGL(Automotive Grade Linux)项目。AGL目前专注于为车载信息娱乐控制台提供操作系统。但其支持者设想的操作系统可以控制仪表板并处理从连接车辆功能到自动驾驶车辆的所有事情。丰田，本田，马自达，日产，斯巴鲁，三菱，福特和捷豹路虎都参与其中。

据 Linux 基金会汽车总经理 Dan Cauchy 表示：“我们的会员基础不单单只是迅速壮大，而且通过横跨不同的业界实现了多元化，从半导体和车载软件到 IoT 和连接云服务。这是一个明显的迹象，即联网汽车的革命已经间接影响到许多行业纵向市场。”

“此外，新发行的UCB新版本是将 AGL、Tizen、GENIVI 项目和相关开源代码中的精华部分整合进 AGL Unified Code Base （UCB）中，使得汽车制造商能够利用一个通用平台进行快速创新。在汽车中采用基于Linux 的系统来实现所有功能时，AGL 的UCB 发行版将扮演一个重大的角色。”

AGL队伍不断壮大

根据Linux基金会消息，他们的AGL合作开源项目现在有超过150个成员，其中11个是汽车制造商，包括丰田和斯巴鲁，他们现在正在他们的一些车型上部署AGL平台。尽管AGL在最新发布的车型上取得了重大进展，但黑莓的QNX平台仍是目前市场的主导车辆，在全球的销量超过1.5亿辆。如果想要有底气与QNX这样的公司竞争，AGL还有很长路要走。就在近期，QNX刚刚宣布与亚马逊(Amazon)就其AWS物联网服务在黑莓QNX平台上运行达成新的合作伙伴关系。亚马逊发布了用于开发车内讯息娱乐系统的Alexa SDK，此举预示亚马逊将正式进军车载娱乐领域。不过目前这个初版的SDK，还需要通过云端来获取机器学习相关能力，但在未来，亚马逊希望帮助用户在离线状态下，也能使用Alexa的核心功能。如AlexaAuto SDK支持的拨打电话、导航和搜索、当地餐馆，地理位置等功能。



亚马逊在一篇博文中表示，Alexa Auto SDK简化了Alexa与车载信息娱乐系统的集成。Alexa Auto包含C ++和Java中的源代码和函数库，使车辆能够处理音频输入，与Alexa建立连接，并处理所有Alexa交互。还包括示例应用程序，构建脚本，序列图和文档。支持ARM和x86处理器体系结构上的Android和QNX操作系统。

虽然黑莓是明显的市场领导者，但也不乏来自WindRiver、Green Hills、Nvidia、Mentor、谷歌、Apple和AGL等竞争对手的良性竞争。未来几年谁将成为主要的竞争对手，还未曾可知。

细数AGL 优、缺点

AGL的主要优势之一是它的统一代码库（UCB），这是一个新的Linux发行版，它基于AGL和另外两个汽车开源项目：Tizen和GENIVI Alliance。UCB是第二代Linux汽车系统。它从底层开始开发，一直到特定的汽车应用软件。



通过汽车制造商和供应商的共同努力，可以为消费者提供现代化的车载信息娱乐和联网汽车体验。进而它提供了70%到80%的现成平台，可为制造商和供应商提供了快速、轻松定制技术的机会，因为这可以使他们能够将其资源集中在定制其他20-30％以满足其独特的产品需求上，缩短了投放市场的时间。除此之外，其成员之间较低的研发成本有助于AGL迅速发展其整体服务，近年来从车辆信息娱乐(IVI)扩展到包括远程信息、仪表集群、平视显示器、ADAS和自动驾驶。许多人吹捧AGL平台有其基于开放源代码的解决方案的独特优势，而另一些人则更怀疑像AGL这样的开放源代码平台是否能够长期满足ISO26262和ASIL C&D认证所要求的严格的安全和安全标准。

市场预测

未来几年AGL是否会成为市场领先的平台还有待观察，但可以肯定的是，到2025年，AGL的市场前景可能会与现在大不相同。到本世纪20年代中期，全球汽车物联网市场预计将超过1000亿欧元，因此谁能给够脱颖而出，他的“奖金”将不可估量。任何一个平台能否成为“实际的”标准，以及其他平台在整个市场中还能扮演什么角色，都有待观察。随着未来前景变得更加明朗，我们可能会在未来几年看到更多的战略合作伙伴关系，并可能出现一些并购事件。

专业人才要跟上

在过去的10年里，我们看到了对Autosar、POSIX、QNX、VxWorks、Integrity、嵌入式Linux、Android和iOS等软件和固件工程师的需求大幅增长。对这些技能的需求一直超过供应，这将给研发项目经理带来了额外的难题，因为他们无法为汽车行业提供全新的具有突破性的解决方案。

既然AGL最终获得了青睐，但是否有足够的AGL专业知识来满足需求呢?至少在目前，不断增长的需求正从一个非常小的基数开始。然而，随着2020年，这些需求继续增长，AGL成员很可能会开始经历类似的困难，在寻找足够的AGL知识人才来满足他们所有新项目的需求。还有一种明显的可能性是，上面提到的一些竞争对手(它们更出名的是应用程序套件)可能会满足于在QNX或AGL平台上运行这些应用程序。这将有助于缓解特定QNX或AGL技能的压力，并使整个市场以更快的速度增长。

因为嵌入式Linux在过去的5年里发展得如此之快，AGL很可能会受益于拥有核心嵌入式Linux技能的工程师的快速增长。具有嵌入式Linux坚实背景的工程师应该能够很容易地适应AGL平台的某些层。在底层，公司可能会寻找ARM、CPU、GPU、DSP、HW加速、Hypervisor、分区、容器、虚拟化、嵌入式内核等其他技能。其他公司可能正在寻找有Yocto、OpenEmbedded、Linux /内核驱动、CAN、SPI、I2C、UART、WiFi、LTE等经验的工程师。对于基于AGL平台开发的产品和解决方案的公司来说，这些技能与扎实的嵌入式Linux技能的任何组合都很有吸引力。在那里，工程师将有机会使用如IVI应用程序，安全，安全，ISO26262, ASIL A-D, Autosar等更具体的汽车技术和标准。

结论

我们很难预测5年后的市场会是什么样子，但似乎越来越多的人认为，核心平台市场可能会被少数几家主要玩家所主导。其他公司可能会选择在这些核心平台上提供更高水平的信息娱乐应用和基于云的服务。只要虚拟机监控程序、分区、容器、虚拟执行环境等安全概念继续发展，并为任务和安全关键系统提供隔离保护，那么在整个联网汽车生态系统中，就很有可能为所有主要参与者提供足够的空间。这对消费者来说是个好消息，因为市场在未来很长一段时间内都将保持高度竞争。这对研发来说也是个好事，因为交付所有潜在创新所需的技能和经验将在更广泛的技能基础上传播。这样，它就不会被少数专业技能所主宰，也不会受到供应限制，从而导致整个行业的发展放缓。

延伸阅读—Linux和汽车的渊源

Linux是一个操作系统，类似于大家常见的Windows、Mac OS，区别于后者主要在于Linux是一个免费开源的系统，无论数据库还是数据库服务器，都可以免费使用，自由搭建。



当然，这一切都要感谢一个人——Linus Torvalds，Linux内核的主要作者。

在遥远的1984年，AT＆T剥离了贝尔实验室; 贝尔实验室免除了需要免费许可的法律义务，开始将Unix作为专有产品销售，在法律上不允许用户修改Unix。

之后的GNU项目创造了完全组成的“完整的UNIX兼容的软件系统”的目标，并于1989年编写了GNU通用公共许可证（GNU GPL）。1991年，正在赫尔辛基上大学的穷小子Linus Torvalds，对操作系统产生了兴趣，但却发现没有一个免费的系统让其使用。

没有枪没有炮的时候，只能自己造。

Linus Torvalds开始在MINIX上开发Linux内核，为MINIX编写的应用程序也在Linux上使用。世间的穷小子不止Torvalds一个，Linux得到了众多开发者的支持，全球的工程人员利用闲暇时间，维护升级Linux，最后星火燎原，一个功能齐全且免费的操作系统Linux便诞生了。

而囿于昂贵的授权费用，其它学术机构、商业团体也开始使用Linux，NASA、IBM、Dell逐渐开始使用Linux，丢弃Windows。现在，从个人到团体，Linux的身影已经出现在很多地方，自动驾驶领域也一样。

如今的Linux也有了几个主流的发行版，如 Ubuntu、Debian、Fedora、CentOS、openSUSE、Linux Mint、Arch Linux等。

Intel发布的车载计算机Lanner的Linux系列，就是基于Apollo Lake的V3系列车载电脑包括-40至70°C的V3G和V3S型号以及MIL-STD-810G加固型。

V3G和V3S都配备了英特尔Apollo Lake系列的四核1.6GHz Atom x7-E3950 SoC。他们使用Linux Kernel 2.6.18或更高版本以及Windows 10运行Red Hat Enterprise Linux（RHEL）5和Fedora 14。

奔驰在早前的Mercedes-Benz S 500上，演示了自动驾驶技术，工程师使用的就是Ubuntu和Xubuntu系统来进行操作控制。

Linux 已经为像丰田、日产、捷豹路虎这些大型汽车制造商提供了信息娱乐系统、平视显示以及其联网汽车connected car的 4G 与 Wi-Fi 系统，而且 Linux 也会登陆福特汽车、马自达、三菱、斯巴鲁。


关键字：汽车  Linux  AGL
编辑：muyan 引用地址：http://news.eeworld.com.cn/qcdz/ic491293.html