|
典型RTOS应用I/O架构
下面描述一个典型的I/O配置(仅仅输入)和它向主要应用程序传递数据的路径处理过程依次如下:
* 一个硬件中断触发一个中断服务例程的执行。
* 中断服务例程做基本的处理和完成本地的输入操作,或者让RTOS调度延时的处理。在一些情况下,延时处理过程由在Linux里面被叫做用户进程来处理,在这里就是通常的RTOS任务。
* 无论在何时何地获得数据(中断服务例程或者延时切换),准备好的数据被放进队列(RTOS中断服务例程能够访问应用程序队列通过应用程序接口(API)和其它进程间通信 (?IPC),请看下面的API表)。
* 一个或者多个应用任务然后从队列读消息,来取出数据。
在传统的RTOS和Linux之间的典型I/O的比较输出常常由类似的机制来完成。替代使用write()或者相似的系统调用, 一个或者多个RTOS应用程序任务,把准备好的数据放进队列。队列中的数据由以下过程取出:一个I/O程序或者响应”准备好发送”中断的中断服务例程,一个系统时钟,或者其它阻塞在获取队列中的应用任务,然后直接执行I/O操作(可以是轮询,也可以是通过 DMA)。
把RTOS I/O 映射进 Linux
上面描述的基于队列的生产/消费I/O模型,仅仅是很多种在传统设计中所采用的特别方法之一。让我们继续用这个直接的例子,来讨论几种在嵌入式Linux下的实现:
大规模移植到用户空间
对于勉强了解Linux设备驱动设计细节,或者非常匆忙的开发者,可能把大多数这样基于队列设计程序完整无缺地移植到用户空间。在这种驱动程序映射配置中,内存映射的物理I/O口通过函数mmap()提供的指针可以在用户空间操作。
#include <sys/mman。h>
#define REG_SIZE 0x4 /* device register size */
#define REG_OFFSET 0xFA400000
/* physical address of device */
void *mem_ptr; /* de-reference for memory-mapped access */
int fd;
fd=open("/dev/mem",O_RDWR); /* open physical memory (must be root) */
mem_ptr = mmap((void *)0x0, REG_AREA_SIZE, PROT_READ+PROT_WRITE,
MAP_SHARED, fd, REG_OFFSET);
/* actual call to mmap() */
|
一个基于进程的用户线程进行与基于RTOS的中断服务例程或者延时任务一样的操作,然后使用SVR4进程间通信函数msgsnd()把消息放进队列,等待被另一个本地线程或者另一个进程利用函数msgrcv()来获取。这种快速”脏的” 处理方法是好的原型,同时对于建立可发布型代码带来了巨大的挑战。首先重要的是需要在用户空间扫描中断。象DOS仿真(DOSEMU)项目提供基于信号的带SIG(Silly中断发生器)中断I/O,但是用户空间的中断处理过程非常慢(毫秒量级中断延时,所替代的基于内核的中断服务例程中断延时为数十微秒)。更进一步讲,在用户空间的切换调度不能保证用户空间的I/O 线程100%的及时执行,即使采用可抢占Linux内核和实时调度策略。
为使用Linux驱动程序重新设计写至少一个简单的Linux驱动程序在内核层次处理中断过程,更为可取。一个基本的字符驱动程序或者块驱动程序,能够在”上半部”直接扫描应用中断数据,或者延时到任务队列去后续处理, 任务队列是内核线程或者在2。6内核里为新的工作队列(下半部)机制。一个或者多个应用线程/进程能够打开设备然后执行同时的读操作,正像RTOS应用同时队列接受调用一样。要注意的是,这种方法把需要至少记录I/O线程使用设备读活动的开销,替代队列接受操作。
保留一个RTOS基于队列的I/O架构
为了减小移植到嵌入式Linux 后的影响,你也可以在原来的地方保留基于队列的方案,并且添加额外的线程或者守护进程,他们在新创建的设备上等待I/O操作。当数据准备好以后,这些线程或者守护进程被唤醒 ,按队列接受数据,由应用线程或者进程取尽使用。
移植方法把RTOS移植到嵌入式Linux 与商业应用程序移植没有概念上的区别。当移植的基础性工作准备好了后（创建make/build脚本和工具，兼容性编译器，特定的包含文件等等）,代码级移植把面临应用架构和应用程序（API）使用问题的挑战。
为了便于下面的讨论，我们假设“应用”部分（除针对I/O以外的所有代码）会被从基于RTOS系统中移植到单独的一个Linux进程；RTOS任务映射到Linux线程，而任务里的进程间通信（IPC）映射到Linux里相当的进程里和线程里。
映射RTOS任务到Linux基于进程的线程 Process-based Threads 移植的基本概念容易理解，同时问题出现在细节上。最显而易见的是正在应用中的RTOS应用程序接口，怎么样才能保留到Linux结构中继续使用。
整体分析―重构
假如你的项目没有很紧的时间要求，并且为了把来项目可反复使用建立可移植性代码，你会化时间分析当前RTOS应用程序结构，和如何把它们映射到Linux结构中去。对于RTOS应用代码，你要考虑把RTOS任务一一映射到Linux基于进程的线程的生存能力，和是否把RTOS应用重新分配到多个Linux进程。依赖于选择，你会重新考虑使用中的RTOS进程间通信（IPC），采用合适的进程间或者进程内的通信机制。
共3页: 上一页 [1] 2 [3] 下一页
|
收藏
推荐
评论(0条)
