随着通信、电子行业的迅速发展，全世界每天都会有大量的新芯片被生产，大量的新电路板被设计，因此，也会有大量设备驱动需要开发。在嵌入式开发中，这些设备驱动，或运行在简单的单任务环境中，或运行在 VxWorks、Linux、Windows等多任务操作系统环境中，发挥着不可替代的作用。

物联网设备.jpg

有无操作系统的区别

1）无操作系统（即裸机）时的设备驱动

并不是任何一个计算机系统都一定要运行操作系统，在许多情况下操作系统是不要的。对于功能比较单一、控制并不复杂的系统，如公交车刷卡机、电冰箱、微波、简单的手机和小灵通等，并不需要多任务调度、文件系统、内存管理等复杂功能，单任务架构完全可以很好地支持它们的工作。一个无限循环中夹杂对设备中断的检测或者对设备的轮询是这种系统中软件的典型架构。裸机的实现就有点类似单片机（MCU）了，尽管单片机的寄存器没有那么的多，如果会裸机驱动，我想，应该能胜任单片机的工作了，呵呵。

在这样的系统中，虽然不存在操作系统，但是设备驱动是必须存在的。一般情况下，对每一种设备驱动都会定义为一个软件模块，包含.h文件和.c文件，前者定义该设备驱动的数据结构并声明外部函数，后者进行设备驱动的具体实现。书中例举了一个串口驱动serial.c serial.h，主要是配置GPIO，串口控制寄存器，以及串口的收发（读写）寄存器，而这几个配置都是自定义函数实现的，比如串口的写（发）SerialSend 函数等。

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

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

有的工程师把单任务系统设计成设备驱动和具体的应用软件模块处于同一层次（即应用程序也在比如serial.c中实现），这显然是不合理的，不符合软件设计中高内聚低耦合的要求。

另一种不合理的设计是直接在应用中操作硬件的寄存器（单独一个main.c，所有功能都在一个函数中实现，不采用其他任何接口/函数），而不单独设计驱动模块，这种设计意味着系统中不存在或未能充分利用可被重用的驱动代码。

2）有操作系统时的设备驱动

无操作系统时的设备驱动中的设备驱动直接运行在硬件之上，不与任何操作系统关联。当系统中包含操作系统后，设备驱动会变得怎样？

首先，无操作系统时设备驱动的硬件操作工作仍然是必不可少的， 没有这一部分，设备驱动不可能与硬件打交道。

其次，我们还需要将设备驱动融入内核。为了实现这种融合，必须在所有的设备驱动中设计面向操作系统内核的接口，这样的接口由操作系统规定，对一类设备而言结构一致，独立于具体的设备。

由此可见，当系统中存在操作系统的时候，设备驱动变成了连接硬件和内核的桥梁。操作系统的存在势必要求设备驱动附加更多的代码和功能（以我看，主要是提供了很多结构），把单一的“驱使硬件设备行动”变成了操作系统内与硬件交互的模块，它对外呈现为操作系统的API，不再给应用软件工程师直接提供接口。有了操作系统之后，设备驱动反而变得复杂，那要操作系统干什么？

首先，一个复杂的软件系统需要处理多个并发的任务，没有操作系统，想完成多任务并发是很困难的。

其次，操作系统给我们提供内存管理机制。一个典型的例子是，对于多数含 MMU的处理器而言，Windows、Linux 等操作系统可以让每个进程都独立地访问 4GB的内存空间。

上述优点似乎并没有体现在设备驱动身上，操作系统的存在给设备驱动究竟带来了什么好处呢？

简而言之，操作系统通过给设备驱动制造麻烦来达到给上层应用提供便利的目的。如果设备驱动都按照操作系统给出的独立于设备的接口而设计，应用程序将可使用统一的系统调用接口来访问各种设备。对于类UNIX的VxWorks、Linux等操作系统而言，应用程序通过write()、read()等函数读写文件就可以访问各种字符设备和块设备，而不用管设备的具体类型和工作方式，是非常方便的。