向嵌入式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应用程序代码同驱动程序代码区分开非常困难，即使它们是有差别 的。

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

在线内存映射访问

当 在上个世纪八十年代中期商业化的RTOS产品可以买到的时候，大多数嵌入式软件包含巨大的主循环，主循环带有针对严格时间操作的注册I/O和中断服务例 程。开发人员将RTOS和执行程序设计进他们的项目，主要为了加强同时性和帮助多任务同步，但是避开其它任何有“妨碍“的构造。同样地，即使一个RTOS 提供了I/O 调用形式方法，嵌入式程序员继续使用直接的I/O操作:

#define DATA_REGISTER 0xF00000F5

char getchar(void) {

return (*((char *) DATA_REGISTER)); /* read from port */
}


void putchar(char c) {

*((char *) DATA_REGISTER) = c; /* write to port */
}

多数受过训练的开发者常常将这样的直接I/O代码从硬件代码独立分离开。但是我还曾遇见大量的意大利面条式的I/O处理代码。

当 普遍深入使用直接内存映射I/O的时候，对Linux开始接触的嵌入式开发人员总是面临将所有的这类代码移植到用户空间，将定义寄存器地址 的#define 语句转换成mmap()调用。 这种处理方法对于一些种类的原型很好，但是不能支持中断处理，限制了实时响应，特别不安全，不适合作为商业发布。

RTOS 中断服务例程

在 Linux中, 中断服务专属于内核的范围。 在一个 RTOS中, 中断服务例程代码是自由形态而且与应用程序代码没有区别（不外乎返回序列）。很多 RTOS提供系统调用或者宏，来让代码自己检测它自己的切换点（比如 Wind River VxWorks的 intContext()）。中断服务例程通常也使用标准的库函数，伴随着可重入性和可移植性问题。大多数RTOS支持注册中断服务例程代码，中断仲裁句 柄和中断服务例程调度。一些非常原始的嵌入式执行程序，仅仅支持在硬件矢量表里插入中断服务例程的开始地址。即使你试图直接在用户程序空间执行读和写的操 作，你不得不将你的Linux中断服务例程放入内核程序空间。