几种常用的经常出现于现有嵌入式应用中的内存映射IO方法概述

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。这些移植工作有着重要的价值和现实意义。

本 文将概述几种常用的经常出现于现有嵌入式应用中的内存映射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的嵌入式开发人员总是想把这类代码移到用户空间，通过mmap（）调用来替代定义寄存器地址 的#define 语句。这种处理方法对于一些原型是可以的，但不能支持中断处理，限制了实时响应，特别不安全，不适合商业化产品的发布。

RTOS 中断服务例程

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

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

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