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

一种叫”下半部“(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)。

将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%的及时得到执行。