|
- UID
- 872238
|
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)。
将RTOSI/O映射进Linux
上面描述的基于队列的生产/消费I/O模型，仅仅是很多种在传统设计中所采用的特别方法之一。让我们继续用这个直接的例子，来讨论几种在嵌入式Linux下的实现：
大规模移植到用户空间
对于勉强了解Linux设备驱动设计细节，或者非常匆忙的开发者，可能将大多数这样基于队列设计程序完整无缺地移植到用户空间。在这种驱动程序映射配置中，内存映射的物理I/O口通过函数mmap()提供的指针可以在用户空间操作。
#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()来获取。这种快速”脏的”处理方法是好的原型，同时对于建立可发布型代码带来了巨大的挑战。首先重要的是需要在用户空间扫描中断。象DOS仿真(DOSEMU)项目提供基于信号的带SIG(Silly中断发生器)中断I/O，但是用户空间的中断处理过程非常慢(毫秒量级中断延时，所替代的基于内核的中断服务例程中断延时为数十微秒)。更进一步讲，在用户空间的切换调度不能保证用户空间的I/O线程100%的及时执行，即使采用可抢占Linux内核和实时调度策略。 |
|
