本章导读

本章将带您走入Linux设备驱动的精彩世界。

1.1节阐明了设备驱动的概念和作用。

1.2节和1.3节分别讲述在无操作系统情况下和有操作系统情况下设备驱动的设计，通过对二者不同的分析阐明设备驱动与硬件和操作系统的关系。

1.4节对Linux操作系统的设备驱动进行了概要性的介绍，给出了驱动与整个软硬件系统的关系，分析了Linux设备驱动的重难点和学习方法。

本章的最后给出了一个设备驱动的“Hello World”实例，即最简单的LED驱动在无操作系统情况下和Linux操作系统下的实现。

1.1设备驱动的作用

任何一个计算机系统的运转都是系统中软硬件共同努力的结果，没有硬件的软件是空中楼阁，而没有软件的硬件则只是一堆废铁。硬件是底层基础，是所有软件得以运行的平台，代码最终会落实为硬件上的组合逻辑与时序逻辑。软件则实现了具体应用，它按照各种不同的业务需求而设计，完成了用户的最终诉求。硬件较固定，软件则很灵活，可以适应各种复杂多变的应用。可以说，计算机系统的软硬件互相成就了对方。

但是，软硬件之间同样存在着悖论，那就是软件和硬件不应该互相渗透入对方的领地。为尽可能快速地完成设计，应用软件工程师不想也不必关心硬件，而硬件工程师也难有足够的闲暇和能力来顾及软件。譬如，应用软件工程师在调用套接字发送和接收数据包的时候，他不必关心网卡上的中断、寄存器、存储空间、I/O端口、片选以及其他任何硬件词汇；在使用printf()函数输出信息的时候，他不用知道底层究竟是怎样把相应的信息输出到屏幕或者串口。

也就是说，应用软件工程师需要看到一个没有硬件的纯粹的软件世界，硬件必须被透明地呈现给他。谁来实现硬件对应用软件工程师的隐形？这个光荣而艰巨的任务就落在了驱动工程师的头上。

对设备驱动最通俗的解释就是“驱使硬件设备行动”。驱动与底层硬件直接打交道，按照硬件设备的具体工作方式，读写设备的寄存器，完成设备的轮询、中断处理、DMA通信，进行物理内存向虚拟内存的映射……凡此种种，最终让通信设备能收发数据，让显示设备能显示文字和画面，让存储设备能记录文件和数据。

由此可见，设备驱动充当了硬件和应用软件之间的纽带，它使得应用软件只需要调用系统软件的应用编程接口（API）就可让硬件去完成要求的工作。在系统中没有操作系统的情况下，工程师可以根据硬件设备的特点自行定义接口，如对串口定义SerialSend()、SerialRecv()，对LED定义LightOn()、LightOff()，对Flash定义FlashWrite()、FlashRead()等。而在有操作系统的情况下，驱动的架构则由相应的操作系统定义，驱动工程师必须按照相应的架构设计驱动，这样，驱动才能良好地整合入操作系统的内核。

驱动程序沟通着硬件和应用软件，而驱动工程师则沟通着硬件工程师和应用软件工程师。目前，随着通信、电子行业的迅速发展，全世界每天都会有大量的新芯片被生产，大量的新电路板被设计，也因此，会有大量地设备驱动需要开发。这些驱动，或运行在简单的单任务环境，或运行在VxWorks、Linux、Windows等多任务操作系统环境，发挥着不可替代的作用。

1.2无操作系统时的设备驱动

并不是任何一个计算机系统都一定要运行操作系统，有许多情况下，操作系统都不必存在。对于功能比较单一、控制并不复杂的系统，譬如ASIC内部、公交车的刷卡机、电冰箱、微波炉、简单的手机和小灵通等，并不需要多任务调度、文件系统、内存管理等复杂功能，用单任务架构完全可以良好地支持它们的工作。一个无限循环中夹杂对设备中断的检测或者对设备的轮询是这种系统中软件的典型架构，如代码清单1-1。

代码清单1-1  单任务软件典型架构

1 int main(int argc, char* argv[])

2 {

3    while (1)

4    {

5      if (serialInt == 1)

6      /* 有串口中断 */

7      {

8        ProcessSerialInt(); /* 处理串口中断 */

9        serialInt = 0; /* 中断标志变量清 0*/

10     }

11     if (keyInt == 1)

12     /* 有按键中断 */

13     {

14       ProcessKeyInt(); /* 处理按键中断 */

15       keyInt = 0; /* 中断标志变量清 0*/

16     }

17     status = CheckXXX();

18     switch (status)

19     {

20       ...

21     }

22     ...

23   }

24 }

在这样的系统中，虽然不存在操作系统，但是设备驱动则无论如何都必须存在。一般情况下，对每一种设备驱动都会定义为一个软件模块，包含.h文件和.c文件，前者定义该设备驱动的数据结构并声明外部函数，后者进行驱动的具体实现。譬如，可以如代码清单1-2那样定义一个串口的驱动。

代码清单1-2  无操作系统情况下串口的驱动

1 /**********************

2   *serial.h 文件

3   **********************/

4 extern void SerialInit(void);

5 extern void SerialSend(const char buf*,int count);

6 extern void SerialRecv(char buf*,int count);

7 

8 /**********************

9   *serial.c 文件

10 **********************/

11 /* 初始化串口 */

12 void SerialInit(void)

13 {

14  ...

15 }

16 /* 串口发送 */

17 void SerialSend(const char buf*,int count)

18 {

19  ...

20 }

21 /* 串口接收 */

22 void SerialRecv(char buf*,int count)

23 {

24  ...

25 }

26 /* 串口中断处理函数 */

27 void SerialIsr(void)

28 {

29  ...

30  serialInt = 1;

31 }

其他模块想要使用这个设备的时候，只需要包含设备驱动的头文件 serial.h，然后调用其中的外部接口函数。如我们要从串口上发送“Hello World”字符串，使用语句SerialSend(“Hello World”,11)即可。

由此可见，在没有操作系统的情况下，设备驱动的接口被直接提交给了应用软件工程师，应用软件没有跨越任何层次就直接访问了设备驱动的接口。驱动包含的接口函数也与硬件的功能直接吻合，没有任何附加功能。图1.1给出了无操作系统情况下硬件、驱动与应用软件的关系。

 

图1.1  无操作系统时硬件、驱动和应用软件的关系

有的工程师把单任务系统设计成了如图1.2所示的结构，即设备驱动和具体的应用软件模块之间平等，驱动中包含了业务层面上的处理，这显然是不合理的，不符合软件设计中高内聚，低耦合的要求。

 

图1.2  驱动与应用高耦合的不合理设计

另一种不合理的设计是直接在应用中操作硬件的寄存器，而不单独设计驱动模块，如图1.3所示。这种设计意味着系统中不存在或未能充分利用可被重用的驱动代码。

 

图1.3 应用直接访问硬件的不合理设计