君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
从RTOS到Linux的应用移植
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口从RTOS到Linux的应用移植_电工电气_中国百科网
从RTOS到Linux的应用移植
    引言
　　在过去几年中，Linux成功地取代了一些最主要的传统RTOS（实时操作系统）平台，成为了各种各样的嵌入式和应用中首选的嵌入式操作系统。尽管一度曾被认为是不重要的平台，但今天嵌入式Linux已经成为主流，广泛应用于消费电子、手持和无线、数据联网以及电信设备等领域。Google公司在2007年11月发布的Android手机操作系统正是基于Linux内核的操作系统，使得Linux在数字移动电话业取得跨越式发展。
　　笔者在从台式频谱仪到手持式频谱仪的项目研发中实现了RTOS到Linux的应用移植。本文介绍了整体的设计思路和一些关键问题的实现细节。
1　RTOS到Linux的移植分析
　　几乎所有的RTOS都有一个简单的编程模型，它由多线程的执行（通常称为任务）构成，包含在单一的地址空间中。在RTOS中，单一主程序下多任务同时运行，具有很高的实时响应能力。
　　过去大多数嵌入式处理器没有内存管理单元，因此RTOS是单地址空间模式，即它们的物理地址和逻辑地址都是一样的。然而目前大多数的中高端处理器配备了MMU（内存管理单元）。在MMU的支持下，Linux采用虚拟内存管理，将地址空间分为物理地址和虚拟地址，因此系统操作硬件时要进行地址映射。
　　根据两类系统的体系结构，RTOS移植到Linux的基本框架如图1所示。
图1　RTOS移植到Linux的基本框架
　　由图1可看出，移植的基本步骤为：
① RTOS的全部应用代码移植到一个Linux单进程；
② RTOS的任务转换成Linux线程；
③ RTOS的物理地址空间映射到Linux的虚拟地址空间。
　　在具体的应用移植过程中，还应考虑在Linux系统下解决上层应用实时响应底层硬件中断，应用层与内核层的异步通信、数据交换，以及多进程、多线程的设计等问题。
2　RTOS到Linux的移植实现
2.1　地址映射
　　多数RTOS是针对较早的无MMU的CPU而设计，所以忽略了内存管理部分，即使当MMU问世后也是这样――不区分物理地址和虚拟地址。大多数 RTOS还全部运行在特权模式，虽然表面上看来是增强了性能，但全部的RTOS应用和系统代码都能够访问整个地址空间、内存映射过的设备以及其他I/O操作。这样，即使存在差别，也很难把RTOS应用程序代码同驱动程序代码区分开来。
　　对于当前包含MMU的处理器而言，Linux系统提供了复杂的存储管理系统，使得进程所能访问的虚拟内存达到4 GB。
　　在Linux系统中，进程的4 GB虚拟内存空间[1]被分为两个部分――用户空间与内核空间。用户地址空间一般分布为0~3 GB，剩下的3~4 GB为内核空间。上层应用程序通常情况下只能访问用户空间的虚拟地址，不能访问内核空间的虚拟地址。应用程序只有通过系统调用（代表应用程序进程在内核态执行）等方式才可以访问到内核空间。
　　而外设I/O资源是不在Linux内核虚拟地址空间中的（如SRAM或硬件接口寄存器等），若需要访问某外设I/O资源，必须先将其物理地址映射到内核虚拟地址空间中，然后才能在内核空间中访问它。
　　Linux内核访问外设I/O资源的方式有两种：静态映射（map_desc）和动态映射（ioremap）。对于静态映射，内核在系统启动时通过map_desc结构体静态创建I/O资源到内核地址空间的线性映射表(即page table)，这种映射表是一一映射的关系。开发人员可以自定义该I/O内存资源映射后的虚拟地址。创建好了静态映射表，在内核或驱动中访问该I/O资源时则无需再进行ioremap映射，可以直接通过映射后的I/O虚拟地址去访问它。
　　这里主要讨论更常用的动态映射方式。动态映射方式是直接通过内核提供的ioremap函数动态创建一段外设I/O内存资源到内核虚拟地址的映射表，从而可以在内核空间中访问这段I/O资源。代码如下：
#define bcon*(volatile unsigned long*)ioremap(0x)//动态映射
上述代码的含义是将0x开始的4字节的物理地址映射到内核的虚拟地址中，返回的起始虚拟地址值赋给bcon宏定义。对宏定义的操作即对物理地址的操作。
ioremap宏定义在asm/io.h内：
#define ioremap(addr, size)__ioremap(addr, size, 0)
__ioremap函数原型为(arm/mm/ioremap.c)：
void __iomem * __ioremap(unsigned long phys_addr, size_t size, unsigned long flags);
其中，phys_addr为要映射的起始的I/O地址；size为要映射的空间的大小；flags为要映射的I/O空间和权限有关的标志。
该函数返回映射后的内核虚拟地址(3G~4G)，接着便可以通过读写该返回的内核虚拟地址去访问这段I/O内存资源。所以，在移植的开始就应该在头文件中完成设备物理地址的映射，方便后续的开发。
2.2　多进程多线程设计
　　大多数的RTOS内核都提供多任务的管理机制。任务是一个具有独立功能的无限循环的程序段的一次运行活动，是实时内核调度的单位。多任务在内核的管理、调度下并行执行，而且任务都是无限循环的，持续实现其功能。多任务实时操作系统示意图如图2所示。
图2　多任务实时操作系统示意图
　　在比较两类嵌入式系统的架构之后，移植的过程中很自然地将RTOS的多任务转换成Linux的多进程、多线程。
　　进程是Linux系统资源管理的最小单位，是程序的一次执行过程，是Linux资源分配的基本单位。线程是在进程内部，它是比进程更小的能独立运行的基本单位，是Linux系统分配CPU时间的基本单位。线程比进程更节约资源，节约时间。在具体的移植过程中，采用主进程等待上层连接，主进程下多线程并行执行。同时采用互斥信号量解决线程访问资源的同步问题。
　　Linux主进程程序流程如图3所示。
图3　Linux主进程程序流程
2.3　应用层与内核层通信
　　由于RTOS的单地址空间模式使得其内核层与应用层没有区别，所以在数据交换、实时响应等方面有一定的优势。而Linux系统提供了严格的内存管理机制，能保证系统更加稳定地运行。但同时增加了应用层与内核层，以及应用层与底层硬件通信的难度。本节内容主要解决应用层与内核层的信号通知、数据交换这两个关键问题。
2.3.1　　异步信号通知机制
　　RTOS是对外来事件在限定时间内能作出反应的系统。在RTOS中，时间是一种重要的系统资源，对外部事件的响应和任务的执行都必须在限定的时间内完成。在多机系统中，还必须在限定的时间内完成消息的发送和接收。在RTOS中，输出结果的正确性不仅取决于计算所形成的逻辑结束，还要取决于结果产生的时间。
　　Linux在发行最初并未定义为一款实时操作系统。随着Linux内核的不断发展，如今稳定的Linux2.6内核已经具备了很好的实时响应能力。本文的研究项目中，需要上层应用对底层硬件进行实时响应。RTOS并没有严格区分上层应用和内核，其多任务并行执行，能很好达地到实时响应的目的。而移植到Linux系统中，上层应用和底层硬件并不能直接通信，要经过内核驱动层。虽然可以采用查询方式实现，但是实时性不高，同时浪费CPU资源。本文采用异步信号通知机制，实现了上层应用对底层硬件的实时响应。
　　异步通知[2]的意思是：一旦设备就绪，则主动通知应用程序，这样应用程序根本不需要查询设备状态，这一点非常类似于硬件上“中断”的概念，比较准确的称谓是“信号驱动的异步I/O”。信号是在软件层次上对中断机制的一种模拟，在原理上进程收到信号与处理器收到中断请求是一样的。信号是异步的，一个进程不必通过任何操作来等待信号的到达，原理如图4所示。
图4　异步信号通知示意图
　　在具体的程序设计过程中，上层应用为了能处理一个设备释放的信号，要完成3项工作：
① 通过F_SETOWN控制命令设置设备文件的拥有者为本进程，这样从设备驱动发送的信号才能被本进程接收到。
② 通过F_SETFL控制命令设置设备文件支持FASYNC，即异步通知模式。
③ 通过signal()函数连接信号和信号处理函数。
　　在上层应用设置捕获信号后，还应在设备驱动端设置信号源，在合适的时机让设备驱动释放信号，其相关代码也包括3部分：
① 支持F_SETOWN命令，能在这个控制命令处理中设置filpf_owner为对应进程ID。
② 支持F_SETFL命令的处理，每当FASYNC标志改变时，驱动程序中的fasync()函数将得以执行。
③ 在设备资源可获得时，调用kill_fasync()函数释放相应的信号给上层应用。
　　上述3项工作和上层应用的3项工作是一一对应的。按其步骤设计程序，即可实现上层应用通过内核层对底层硬件的及时响应。
2.3.2　proc方式数据共享
　　除了前面提到的信号、套接字、信号量外，Linux还有管道、报文队列、共享内存等进程间通信机制。在移植过程中，由于Linux系统分为应用层和内核层，所以不仅要进行进程间的通信，还要实现应用层与内核层的数据交换。以上的机制多是基于进程间通信，并不能很好地满足要求。在这里采用proc文件系统的方法在Linux内核层和应用层之间进行数据交换。
　　在Linux系统中，proc文件系统是一个虚拟文件系统，用于内核向用户导出信息。利用proc文件系统通信是比较方便的一种应用层与内核层的数据交换方式，可以将对虚拟文件的读写作为与内核中实体进行通信的一种手段。内核的很多数据都是通过这种方式出口给上层应用的，内核的很多参数也是通过这种方式来让上层方便设置的。实际上，很多应用严重地依赖于proc文件系统，因此它几乎是必不可少的组件。
　　对于proc文件系统的使用，有如下的接口函数：
struct proc_dir_entry *create_proc_entry(const char *name,mode_t mode,struct proc_dir_entry *parent);
typedef int (read_proc_t) (char *page, char **start, off_t off, int count, int *eof, void *data);
typedef int (write_proc_t) (struct file *file, const char __user *buffer,unsigned long count, void *data);
void remove_proc_entry(const char *name, struct proc_dir_entry *parent);
　　以上函数作用分别是创建proc文件系统节点、读写proc节点，以及删除proc节点。具体移植的proc程序流程如图5所示。
图5　proc程序流程
2.4　调试运行
　　根据移植的基本框架，在解决了以上几个关键问题后，基本完成了整个移植的过程。最后要做的就是程序的调试。对于程序语法的调试，在编译的过程中解决。根据Linux平台下的编译器gcc的提示信息，修改出现的语法类错误。在保证了应用程序文件的成功编译后，采用gdb调试软件进行功能的调试，同时结合打印函数printf跟踪调试。在程序适当的位置加入printf打印信息，例如根据创建proc节点的返回值来打印成功或者失败的信息，可以很直观地了解程序的运行情况，是很有效的调试方法。通过两种手段的结合，最后完成应用程序的调试。结果表明，能够在Linux系统下正常运行。
　　现在越来越多的开发团队正在放弃第一代实时操作系统，选择更稳定的开放式的嵌入式Linux平台。参考本文概括的应用程序的移植步骤以及相关的关键技术，开发人员可以通过更少的时间，将以前的RTOS的代码成功地移植到一个现代化的Linux平台上来。
收录时间:日 11:13:10 来源:电子产品世界 作者:匿名
上一篇： &(&&)
创建分享人
喜欢此文章的还喜欢
Copyright by ；All rights reserved. 联系：QQ：您的位置： >
考虑的种种原因包括：广泛的硬件支持、更高的可靠性、更优异的性能、可扩展性以及更快的响应速度。不过，工程师在将基于传统RTOS的设计移植到嵌入式Linux时会遇到几大难题，因为Linux的架构和传统RTOS有很大的不同。
Linux成功地取代了一些最主要的传统RTOS平台，成为了各种各样的嵌入式设备和应用中首选的新的嵌入式操作系统。尽管一度曾被认为是不重要的平台，但今天嵌入式Linux已经成为主流，并引领着如下重要应用领域的市场和设计份额：消费电子、移动和无线设备、数据联网以及电信设备。
移植的时机随着应用开发步伐的不断加快和产品生命周期的不断缩短，对于设计团队而言，能够将传统软件移植到这些新平台上并重新使用是十分重要的。尽管嵌入式Linux有许多优势，但是设计团队在选择从传统的RTOS进行移植之前，必须考虑如下几项因素：
● 内存占用量。嵌入式Linux没有传统RTOS那样紧凑。因此，工程师必须确保设备有足够的内存和闪存来应对Linux更大的内存占用量。
● 实时性考虑。嵌入式Linux可以实现50μs以下的响应时间。不过，这不一定能够满足项目需求，这一点有助于确定是否需要RTOS。
● 认证需求。期望转换到嵌入式Linux的设计团队应确保项目将仍然满足业界特有的认证需求，例如安全认证或美国国防部认证。
移植路径选择尽管移植过程中存在固有的难题，但从传统RTOS到Linux的移植不需要转弯抹角。工程师可以采用以下三种路径将应用从传统的RTOS移植到Linux。
仿真RTOS的API第一种移植路径是仿真传统RTOS的API。为了使传统RTOS应用能够驻留并运行在Linux上，必须具备基于Linux的运行时服务于RTOS系统调用和其他API。许多（但并非全部）RTOS入口点和独立编译器库例行程序都在Linux和glibc运行时库中有原样的类似程序。如果不存在类似程序，就必须有新的代码介入来仿真缺失的功能。即使存在类似的API，可能也会出现参数类型和数量不同的情况。
图1 在Linux上仿真RTOS
传统RTOS可以实现数百种系统调用和库API。例如，VxWorks文档描述了超过一千种独特的函数和子例程。实际应用只使用数十个独特的RTOS API，而它们其余的操作都使用来自标准C/C++库的调用函数。
为了仿真这些接口以用于移植，开发人员只需要RTOS调用的核心子集。许多OEM选择自己建立和维护仿真轻量级库，而其他OEM则使用来自供应商的更全面的商用库。除了商用库和自主开发之外，另一种选择是一个叫做v2lin的开源项目，它可以仿真数十种常用的VxWorks API。此外，v2lin项目经过架构改造之后，可用于较新的兼容于POSIX的glibc版本。
使用虚拟化进行运行时划分对于期望采用Linux的工程师而言，虚拟化是另一种可行的移植路径。虚拟化包括操作系统的驻留或者作为一个应用程序运行在另一个虚拟平台之上，其中一部分系统软件（运行在“裸机”之上或作为驻留的应用程序）可实现一个或多个“客户”OS实例的执行。在企业级计算中，基于Linux的虚拟化技术是数据中心的主流功能，而且虚拟化也在嵌入式系统中找到了许多的应用。
嵌入式虚拟化要求将CPU、内存和其他资源进行划分，以驻留RTOS以及一个或多个客户“应用程序”操作系统（通常是Linux）来运行更高层次的软件。
图2 采用虚拟化划分开的运行时
虚拟化可以通过允许RTOS应用程序和RTOS自身几乎原样地运行在新设计之中，而Linux则运行在自己的分区之中，以支持移植。这种方案适用于遗留代码依赖于RTOS的API和RTOS的性能特点的情况，例如实时性能或协议栈的具体实现。
工程师可以使用虚拟化作为从遗留代码向基于Linux的新设计过渡的简短且可靠的桥梁。不过，这种策略可能需要成本。OEM需要支付传统RTOS运行时的使用费，还需要与VM供应商谈判商用许可证。
图3 RTOS的本地端口
逐步将应用移植到Linux仿真和虚拟化可以提供直接明了的移植路径来进行原型制作、开发、甚至是对运行在Linux上的传统RTOS应用进行部署。但是，它们的缺点是需要额外的代码，并会涉及基础设施和许可费用。相反，在Linux实现“本地化”就能降低复杂度，简化许可程序，并增强可移植性和性能。
图4 将RTOS任务映射为Linux线程 当设计团队首次动手处理移植项目时，他们往往会选择仿真和虚拟化技术。随着他们不断学习并更加熟悉Linux的开发工具和运行时属性，OEM可以逐步地重新建造传统应用，以实现本地Linux执行。
一种方法是选择单个传统程序进行本地移植，并将它们驻留在独立的Linux进程中。在软件显示出其对其他子系统有着极小或者正常依赖性的情况下，这种技术最为适用。另一种明智的做法是，即使在部署仿真或虚拟化的时候也只将新的功能以本地代码的形式来实现。
重要的一点是，要注意到这种选择并不一定是相互排斥的。例如，设计团队可以每次选择一个关键的传统程序，逐步地将传统应用改造为本地Linux执行，然后将它们放入单独的Linux进程中，而新功能只以本地代码方式来实现。
非常好我支持^.^
不好我反对
相关阅读：
( 发表人：发烧友 )
评价:好评中评差评
技术交流、我要发言
发表评论，获取积分！ 请遵守相关规定！提 交
Powered by: 电子发烧友 （
. .All Rights Reserved 粤ICP备号> RTOS设备驱动向嵌人式Linux的移植
RTOS设备驱动向嵌人式Linux的移植
　　Linux暴风雨般占领了嵌入式系统市场。分析家指出，大约有1/3到1/2的32/64位新的嵌入式系统设计采用了Linux。嵌入式 Linux 已经在很多应用领域显示出优势，比如SOHO家庭网络和成像/多功能外设。在(NAS/SAN)存储，家庭数字娱乐(HDTV/PVR/DVR/STB)，和手持设备/无线设备，特别是数字移动电话更获得大幅度发展。　　嵌入式Linux新应用不会凭空从开发者的头脑中冒出来，大部分项目都是由成千上万行，甚至数百万行的代码组成。成千上百的嵌入式项目已经成功地将现有的其它平台的代码移植到Linux下,比如Wind River VxWorks 和 pSOS, VRTX, Nucleus 和其它RTOS。这些移植工作有着重要的价值和现实意义。　　到目前为止，大多数关于移植已有的RTOS应用到嵌入式Linux的文献，关注RTOS 接口（API）、任务、调度模式以及怎样将他们映射到相应得用户空间去。同样重要的是，在I/O调用密集的嵌入式程序中如何将RTOS的硬件接口代码移植到更加规范的Linux设备驱动程序中去。　　本文将概述几种常用的经常出现于现有嵌入式应用中的内存映射I/O方法。它们涵盖的范围从对中断服务例程的特殊使用及用户线程对硬件访问到出现于有些ROTS中的半规范化驱动程序模型。这对于移植RTOS 代码到规范化的Linux设备启动程序具有一定启发作用，并且介绍了一些移植方法。特别地，本文会重点讨论RTOS和Linux中的内存映射，基于I/O调度队列的移植，将RTOS I/O重定义到Linux下的驱动程序和守护进程里。　　RTOS I/O 概念　　&不规范&是描述大多数RTOS系统I/O的最佳词语。多数RTOS是针对较早的无MMU的CPU而设计，所以忽略了内存管理部分，即使当MMU问世后也是这样：不区分物理地址和逻辑地址。大多数 RTOS还全部运行在特权模式，虽然表面上看来是增强了性能。全部的RTOS 应用和系统代码都能够访问整个地址空间、内存映射过的设备、以及其他I/O操作。这样，即使存在差别，也是很难把RTOS应用程序代码同驱动程序代码区分开来。
本文地址 ：
------分隔线----------------------------