RTOS设备驱动向嵌人式Linux的移植

Linux暴风雨般占领了嵌入式系统市场。分析家指出，大约有1/3到1/2的32/64位新的嵌入式系统设计采用了Linux。嵌入式Linux已经在很多应用领域显示出优势，比如SOHO家庭网络和成像/多功能外设。在(NAS/SAN)存储，家庭数字娱乐(HDTV/PVR/DVR/STB)，和手持设备/无线设备，特别是数字移动电话更获得大幅度发展。

嵌入式Linux新应用不会凭空从开发者的头脑中冒出来，大部分项目都是由成千上万行，甚至数百万行的代码组成。成千上百的嵌入式项目已经成功地将现有的其它平台的代码移植到Linux下，比如WindRiverVxWorks和pSOS，VRTX，Nucleus和其它RTOS。这些移植工作有着重要的价值和现实意义。

到目前为止，大多数关于移植已有的RTOS应用到嵌入式Linux的文献，关注RTOS接口（API）、任务、调度模式以及怎样将他们映射到相应得用户空间去。同样重要的是，在I/O调用密集的嵌入式程序中如何将RTOS的硬件接口代码移植到更加规范的Linux设备驱动程序中去。

本文将概述几种常用的经常出现于现有嵌入式应用中的内存映射I/O方法。它们涵盖的范围从对中断服务例程的特殊使用及用户线程对硬件访问到出现于有些ROTS中的半规范化驱动程序模型。这对于移植RTOS代码到规范化的Linux设备启动程序具有一定启发作用，并且介绍了一些移植方法。特别地，本文会重点讨论RTOS和Linux中的内存映射，基于I/O调度队列的移植，将RTOSI/O重定义到Linux下的驱动程序和守护进程里。

RTOSI/O概念

“不规范”是描述大多数RTOS系统I/O的最佳词语。多数RTOS是针对较早的无MMU的CPU而设计，所以忽略了内存管理部分，即使当MMU问世后也是这样：不区分物理地址和逻辑地址。大多数RTOS还全部运行在特权模式，虽然表面上看来是增强了性能。全部的RTOS应用和系统代码都能够访问整个地址空间、内存映射过的设备、以及其他I/O操作。这样，即使存在差别，也是很难把RTOS应用程序代码同驱动程序代码区分开来。

不规范的结构导致了I/O实现的特殊性。在很多情况下，缺乏设备驱动程序模型的认同。根据这种无层次的特性，回顾一下基于RTOS软件中使用的一些重要概念和习惯用法非常有指导意义。

内嵌的内存访问

上个世纪八十年代中期商业化的RTOS产品中，多数嵌入式软件都有一个对执行时间有严格需求的，采用I/O查询和中断服务例程的大循环。开发人员在项目采用RTOS和执行程序，主要为了加强并行性和多任务同步，绕开其它有碍实现该目标的程序结构。这样，即使RTOS提供了I/O调用形式化方法，嵌入式程序员继续使用直接的I/O操作：

#defineDATA_REGISTER0xF00000F5

chargetchar(void){

return(*((char*)DATA_REGISTER));/*readfromport*/

}

voidputchar(charc){

*((char*)DATA_REGISTER)=c;/*writetoport*/

}

多数受过训练的开发者常会将这样的直接I/O代码从硬件代码中分离开来。但是我还是经常看到诸如此类的I/O调用代码。

当开始使用直接内存映射I/O的时候，新接触Linux的嵌入式开发人员总是想把这类代码移到用户空间，通过mmap()调用来替代定义寄存器地址的#define语句。这种处理方法对于一些原型是可以的，但不能支持中断处理，限制了实时响应，特别不安全，不适合商业化产品的发布。

RTOS中断服务例程

在Linux里，中断服务属于内核层;在一个RTOS里，中断服务例程代码没有特殊规定且常与应用程序代码没什么区别（不外乎返回序列异同）。很多RTOS提供系统调用或者宏来让代码自己检测它自己的切换状态（比如WindRiverVxWorks的intContext()）。中断服务例程通常也使用标准的库函数，随之而来也有可重入性和移植性等问题。

大多数RTOS支持注册中断服务例程代码、中断判断和中断服务调用。一些简单的嵌入式程序，仅仅支持在硬件矢量表里插入中断服务例程的起始地址。

如果试图直接在用户程序空间执行读和写操作，你不得不将Linux中断服务例程放入内核程序空间。

RTOSI/O子系统

大多数RTOS会提供一个定制的标准C运行库(比如pSOS的pREPC)，或者修改编译器提供商的C库(libc)或修改glibc。在尽量最小化情况下，多数的RTOS支持标准C的I/O子集(open/close/read/write/ioctl)。大多数情况下，这些调用和从衍生出来的调用转化为基本I/O简单封装。有趣的是，因为大多数的RTOS不支持文件系统，这些平台不提供针对flash和其他存储介质的文件存储，常采用完全不同的代码实现或者其他应用程序接口(API)(比如pSOS的pHILE)。

WindRiverVxWorks在这方面比其它RTOS做得好些，它提供功能丰富的I/O子集，有效广泛集成网络接口及网络媒体。

延时处理

很多RTOS也支持一种叫”下半部“("bottomhalf")的机制，把I/O处理放到可中断或者可抢占切换上下文中执行。其他RTOS提供类似机制比如中断嵌套来获得同样的效果。

典型RTOS应用的I/O架构

下面描述一个典型的I/O图解(仅输入)和它向主应用程序传递数据的路径，处理过程如下：

·一个硬件中断触发一个中断服务例程执行。

·中断服务例程做基本处理，完成本地输入操作，或者让RTOS调度延时处理。在一些情况下，延时处理过程由Linux里的用户进程来处理，在这里就是普通的RTOS任务。

·当获取到数据(中断服务例程或者延时切换)，准备好的数据被放进队列(RTOS中断服务例程能够访问应用程序队列通过应用程序接口(API)和其它进程间通信(IPC)，请看下面的API表)。

·一个或者多个应用任务从队列读消息取出数据

传统的RTOS和Linux的典型I/O比较

输出常常由类似的机制来完成-代替write()或者相似的系统调用，一个或者多个RTOS任务，将数据放进队列。队列中的数据由以下几种过程取出：一个I/O程序或者响应“准备好发送”中断的中断服务例程，一个系统时钟，或者其它阻塞在取数据队列中的应用任务，然后执行I/O操作(可以是轮询，也可以是通过DMA)。[!--empirenews.page--]

将RTOSI/O映射到Linux中

上面描述的基于队列的生产者/消费者I/O模型，仅仅是传统多种设计中所采用的特别方法的一种。让我们继续用这个直接的例子，来讨论几种在嵌入式Linux下的实现方法：

大规模移植到用户空间

对于只是初步了解Linux设备驱动设计，或者没有经验的开发者，可能将大多数这种基于队列的程序原封不动地移植到用户空间。在这种驱动程序映射中，内存映射通过函数mmap()提供的指针可以在用户空间操作物理I/O接口。

#include

#defineREG_SIZE0x4/*deviceregistersize*/

#defineREG_OFFSET0xFA400000

/*physicaladdressofdevice*/

void*mem_ptr;/*de-referenceformemory-mappedaccess*/

intfd;

fd=open("/dev/mem"，O_RDWR);/*openphysicalmemory(mustberoot)*/

mem_ptr=mmap((void*)0x0，REG_AREA_SIZE，PROT_READ+PROT_WRITE，

MAP_SHARED，fd，REG_OFFSET);

/*actualcalltommap()*/

一个进程下的用户线程运行类似RTOS的中断服务例程或延时任务一样的操作，然后使用SVR4进程间通信函数msgsnd()将消息放进队列，等待被另一个本地线程或者另一个进程利用函数msgrcv()获取。

这种快速缺乏技巧的处理方法是一种较好的原型，但同时给代码模型建立带来了巨大的挑战。首先重要的是要在用户空间扫描中断。象DOSEMU项目提供基于信号的I/O中断方式，但用户空间的中断处理过程非常慢(一般毫秒级中断延时相较内核中断服务例程数十微秒中断延时)。进一步讲，即使采用可抢占Linux内核，和实时调度策略，用户空间的切换调度不能保证I/O线程100%的及时得到执行。