前言：中文期刊网精心挑选了驱动程序范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
驱动程序范文1
由于工作关系，我经常涉及PC机与设备接口的工作，从PC机这方面要做的工作看来，主要是通过接口处理设备的中断，通过I/O端口或内存地址与外设互相传递数据。从计算机原理的角度看，所要达到的目的很简单，那么如何编写程序完成上述功能呢？
目前国内流行的PC操作系统有三种：DOS，Win95/98系列，WindowsNT。DOS是单用户、单任务操作系统，由于PC机硬件处理速度不断提高，基于单用户、单任务的操作系统越来越不能充分发挥硬件的功能，现在只应用于一些老式PC及其它个别场合，有逐渐被淘汰的趋势；Win95/98系列和WindowsNT属于多任务操作系统，不论从其原理还是界面上看，这两种操作系统都比DOS有着无可比拟的优越性，这两种操作系统虽然在界面和操作上及其相似，但其内部实现的诸多方面有许多区别，有些区别是本质上的。Win95/98设计目标是针对一般家庭用户，安全性及可靠性存在许多薄弱环节，就可靠性而言，Win95/98系列不能很好的防止多任务环境中某个进程的非法操作导致系统中其它程序甚至整个系统的崩溃，而WindowsNT在这方面及其它诸多方面设计的相当严谨。这两种操作系统是Microsoft公司同一时期的产品，但针对不同的使用群，所以在一些重要场合及生产实践中应该选择WindowsNT作为计算机的操作系统，此外，从发展趋势来看，WindowsNT已经成为定型产品，具有相对稳定性。
在不同操作系统下编写驱动程序是有很大区别的，在DOS平台上，应用程序和设备驱动程序之间没有标准的接口，它们在外部表现为一个扩展名为EXE的文件，驱动程序的作用被柔和在应用程序中，这样，应用程序为了使用不同厂商的同一类设备，必须了解这些设备在接口上具体的硬件实现，同时，对于一个特定型号的硬件产品，所有支持它的应用软件中对于控制整个设备动作的这部分代码，可能被多次重写。这种情况不适应硬件及应用软件的飞速发展。Windows系统在这方面，进行了根本性改进，把控制设备动作的这部分代码独立出来，提出了设备驱动程序的概念,驱动程序是应用程序和硬件设备之间的一个桥梁，应用程序与驱动程序之间有明确的接口，应用程序通过与驱动程序交换信息，达到控制外设的目的。接口定义的操作是面向设备的，这就是说，在应用程序的设计中，并不用关心对外设操作的具体硬件实现，只是对驱动程序发出一系列指令既可；驱动程序接受来自上层应用程序的指示，具体操纵实际硬件，完成用户功能。具体实现上，Win95/98系列与WindowsNT又有所区别，WindowsNT是严格按照上述思路设计的；而Win95/98系列不那么严格，其支持上述思路，但同时应用程序也可以绕过驱动程序直接访问实际物理I/O，这样做，增加程序设计的灵活性，但同时，对系统可靠性造成一定隐患。这也正是Win95/98系列可靠性低于WinNT的原因之一。
WindowsNT设备驱动程序的组成原理
WindowsNT操作系统结构分为用户模式和内核模式，用户模式下的编程为应用程序的设计，而开发设备驱动程序，则属于内核模式下的编程，内核模式组件包括NTExecutive(ExXxx),内核(KeXxx),硬件抽象层(HalXxx)。其层次如图2-1所示，其中NTExecutive包括几个独立的软件组件，它们是系统服务接口(ZwXxx)，对象管理器(ObXxx)，配置管理器，进程管理器(PsXxx)，安全监视器(SeXxx)，虚拟空间管理器(MemXxx)，本地进程调用，I/O管理器(IoXxx)。内核模式的系统服务并不是全部公开的，而是提供了一系列开发设备驱动程序需要的函数(上文括号内为函数形式，函数手册参见[2]Kernel-ModeDrivers-Reference章节)，换言之，这些函数功能是所有内核模式的系统服务功能的子集。
驱动程序由一系列相对独立的函数组成，由I/O管理器根据需要调用这些函数，对于一个需要处理中断的最简单的驱动程序也需要由以下几个函数构成：
1.DriverEntry()运行于PASSIVE_LEVEL
驱动程序入口点，当驱动程序被手动或自动装入系统后，驱动程序从这点开始执行，主要用于定位硬件资源，建立指向其它驱动程序函数的指针等其它初始化工作。
2.XxUnload()运行于PASSIVE_LEVEL
用于驱动程序从系统卸出之前，释放由驱动程序占用的所有系统资源。
3.XxIsr()运行于DIRQL
中断服务程序。
4.XxDpcForIsr()运行于DISPATCH_LEVEL
中断服务程序后处理程序，以排队方执行不太关键代码的执行，由于排队机制及优先级，不会造成代码拥塞从而提高中断服务程序的响应并且提高系统总体I/O吞吐率。
5.XxOpen()运行于PASSIVE_LEVEL
处理应用程序Win32函数CreateFile()请求。
6.XxClose()运行于PASSIVE_LEVEL
处理应用程序Win32函数CloseHandle()请求。
7.XxDispatch()运行于PASSIVE_LEVEL
处理应用程序Win32函数DeviceIoControl()请求，通过一系列自定义命令，驱动程序与应用程序交换特定的信息。
WindowsNT使用一个抽象化的CPU优先级方案，IRQL代表中断请求级，任一时刻CPU总处在某一级上，这个数越大，表示当前的任务重要性越大，如表2-1所示，从上至下IRQL越来越小。所有上述驱动程序的函数及内核模式函数都必须运行于各自的IRQL级上，如果违反这一调用规定，会造成系统崩溃。例如，中断服务程序(XxIsr)运行于DIRQL及上，那幺在编写中断服务程序时，只能调用允许在这一级运行的内核模式函数(并不是所有内核模式函数都能运行于DIRQL级)。至于每个内核模式函数运行级别的说明，详见[2]Kernel-ModeDrivers-Reference章节。
WindowsNT是一多任务系统，许多设备的驱动程序同时存在系统中，这样各个设备所占用的资源(中断，I/O及RAM地址空间)很有可能冲突，如果设备驱动程序在运行之前不进行‘探测’而使用自己硬件设备的资源，有可能和系统内其它设备占用的资源冲突，后果不堪设想。WindowsNT通过注册表管理硬件资源的占用信息，作为内核模式信任的组件，驱动程序使用硬件资源之前必须遵循‘查询-申请-使用-释放’的原则
WindowsNT设备驱动程序的编写步骤与实例
现以一实际例子简要说明设备驱动程序的开发步骤，本例以CINRAD天气雷达测试卡实际应用为原型，加以简化、抽象。
第一步，了解被控设备的接口情况。
本例为一ISA卡，占用PC机9号中断，I/O地址360H及RAM地址D0228H分别一个字空间。
第二步，确定驱动程序的功能。
驱动程序每当9号中断达到时，检查运行标志变量RunFlag(为一BOOL变量)，如果等于TRUE，中断累积计数器counter(为一unsignedshort变量)增一，把这个值写入RAM地址D0228H，再从这个地址读出，如果读出值等于写入值，把这个值写入I/O地址360H,这个地址的内容会驱动板卡上的LED显示，把写入值显示出来；如果读出值不等于写入值，设置运行标志变量FALSE。如果运行标志变量等于FALSE，什幺也不做，返回。
第三步，定义驱动程序与应用程序的软件接口。
本例定义两个接口命令:
IOCTL_IOCardA_START:应用程序设置驱动程序内部的运行标志变量等于TRUE。
IOCTL_IOCardA_READ:应用程序查询驱动程序内部的中断累积计数器的值。
第四步，画流程图。这里列举本例实现的几个主要流程图，（图略）。
系统传给驱动程序入口函数系统定义的‘设备驱动对象’DrObj，通过初始化这个对象的一些成员变量，把驱动程序其它函数与这个对象联系起来。
ISA卡为非即插即用设备，事先把资源占用信息手工添加注册表如下：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IOCardA\parameters]
"IRQ"=dword:00000009
"IOSPAN"=dword:00000004
"IOAdd"=dword:00000360
"RAMAdd"=dword:000d0228
"RAMSPAN"=dword:00000002
其中IOCardA以下各子键及其值为自定义，设备驱动程序利用相应函数检索出这些值。
(3)每个设备驱动程序可以创建若干系统定义的‘设备对象’，本例根据需要只创建了一个‘设备对象’Dev。‘设备对象’其中一个成员变量为指向一非分页的物理内存块DeviceExtension，这块内存大小及内容为用户自定义，由于Dev或DeviceExtension对象会被系统传给驱动程序的其它函数，这样驱动程序各函数通过访问这块内存区，实际上达到互相传递信息的功能。本例在这里存储设备硬件资源信息及RunFlag和中断计数器counter，这些数值在DriverEntry()初始化后，供驱动程序的其它函数使用。
图3-2为中断服务程序IOCardAIsr()流程图。操作系统接受中断，连同DeviceExtension等参数传给中断服务程序，中断服务程序利用这些参数，实现要求功能。
图3-3为IOCardADispatch()流程图，这个函数用于处理来自上层应用程序的命令。上层应用程序通过以下程序段设置驱动程序中RunFlag值为TRUE，从而启动中断服务程序开始计数。
BOOLcmd=TRUE;
hTest=CreateFile(...);//打开设备
DeviceIoControl(hTest,//设备句柄
IOCTL_IOCardA_START,//命令
&cmd,sizeof(BOOL),//输入缓冲区地址及大小
NULL,0,&c,NULL);
CloseHandle(hTest);//关闭设备
上层应用程序通过以下程序段查询当前的中断计数器的值并存于变量w中。
unsignedshortw;
hTest=CreateFile(...);
DeviceIoControl(hTest,
IOCTL_IOCardA_READ,//命令
NULL,0,
&w,sizeof(unsignedshort),//输出缓冲区地址及大小
&c,NULL);
CloseHandle(hTest);
其中DeviceIoControl()执行后，操作系统调用IOCardADispatch()函数，如流程图所示，这个函数内部通过一个开关语句，根据命令执行相应的分支。驱动程序与应用程序通过此函数接换数据时，操作系统提供4种可选数据缓冲方式，本例由于数据I/O量比较小，故选用‘缓冲I/O’(METHOD_BUFFERED)。过程是，I/O管理器首先分配一个非分页池，它的大小为调用者输入缓冲区和输出缓冲区的较大者，第一段程序为sizeof(BOOL),第二段程序为sizeof(unsignedshort),它的地址存到IRP(I/O请求包)的AssociatedIrp.SystemBuffer域中，然后把输入数据拷贝到这个池中，在第一段程序中cmd的值TRUE被拷贝到池中，这样驱动程序通过RtlCopyBytes()函数再把池中的值拷贝到驱动程序的RunFlag中。IOCardADispatch()函数执行完，I/O管理器把池中的内容拷贝到调用者的输出缓冲区，在第二段程序中，驱动程序通过RtlCopyBytes()函数把counter的值拷贝到池中，从而最终传递到应用程序变量w中。
第五步，编程。在编写设备驱动程序的同时，要编写一个简单的应用程序用于测试设备驱动程序的一些功能。
第六步，驱动程序的载入。
驱动程序C语言源程序经过编译、连接生成扩展名为SYS的文件，本例为IOCardA.sys,把这个文件拷贝到\WINNT\system32\drivers\系统目录下，同时手工添加如下信息到注册表：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IOCardA]
"ErrorControl"=dword:00000001
"Start"=dword:00000003
"Type"=dword:00000001
要保证IOCardA子键名与驱动程序文件名一致，其中Type=1表示此驱动程序为内核模式驱动程序，Start=3表示此驱动程序手动载入，ErrorControl=1表示当驱动程序发生错误时，日志记录错误并显示一个消息框。这样当Windows重新启动后，通过使用控制面板中的Device小应用程序，从列表中找到IOCardA设备名，按Start按钮，于是，设备驱动程序就驻留内存并在底层开始工作了。
第七，调试。设备驱动程序没有界面，完全在系统底层运行，为了观察驱动程序的运行状态，WindowsNTDDK提供windbj.exe程序用于设备驱动程序的调试，调试设备驱动程序需要两台CPU体系结构完全相同的计算机，一台为‘宿主机’，运行windbj.exe程序，另一台为‘目标机’，运行设备驱动程序，两台计算机用串口线连好，进行一系列软件设置(参见[1]第17章)，就可以开始调试了，从‘宿主机’可以控制及观察‘目标机’上驱动程序的运行情况。最常用的调试手段是在驱动程序中必要的位置加入DbgPrint()函数，这个函数可以把指定信息输出到‘宿主机’windbg.exe窗口中，通过分析这些信息，可以了解驱动程序当前的运行情况。
结束语
WindowsNT是一个复杂而严密的系统，驱动程序的开发不可避免的涉及现代操作系统理论及其它许多计算机理论，内涵相当广泛，本文围绕着开发实践从一定深度探讨了WindowsNT设备驱动程序开发最基本的知识及一般方法，希望对读者有所帮助，对于复杂，特殊应用的实现及编程技巧，有待于读者在各自实际应用中不断探索。
参考文献
驱动程序范文2
鉴于设备驱动程序通知应用程序的重要性，本人结合一些经验，对它进行了总结，归纳出5种方法：异步过程调用(APC)、事件方式（VxD）、消息方式、异步I/O方式和事件方式(WDM)。下面分别说明这几种方式的原理，并给出实现的部分源代码。
1异步过程调用(APC)
Win32应用程序使用CreateFile()函数动态加载设备驱动程序，然后定义一个回调函数backFunc()，并且将回调函数的地址&backFunc()作为参数，通过DeviceIoControl()传送给设备驱动程序。设备驱动程序获得回调函数的地址后，将它保存在一个全局变量（如callback）中，同时调用Get_Cur_Thread_Handle()函数获取它的应用程序线程的句柄，并且将该句柄保存在一个全局变量（如appthread）中。当条件成熟时，设备驱动程序调用_VWIN32_QueueUserApc()函数，向Win32应用程序发送消息。这个函数带有三个参数：第一个参数为回调函数的地址（已经注册）；第二个参数为传递给回调函数的消息；第三个参数为调用者的线程句柄（已经注册）。Win32应用程序收到消息后，自动调用回调函数（实际是由设备驱动程序调用）。回调函数的输入参数是由设备驱动程序填入的，回调函数在这里主要是对消息进行处理。
2事件方式（VxD）
首先，Win32应用程序创建一个事件的句柄，称其为Ring3句柄。由于虚拟设备驱动程序使用事件的Ring0句柄，因此，需要创建Ring0句柄。用LoadLibrary()函数加载未公开的动态链接库Kernel32.dll，获得动态链接库的句柄。然后，调用GetProcAddress(),找到函数OpenVxDHandle()在动态链接库中的位置。接着，用OpenVxDHandle()函数将Ring3事件句柄转化为Ring0事件句柄。Win32应用程序用CreateFile()函数加载设备驱动程序。如果加载成功，则调用DeviceIoControl()函数将Ring0事件句柄传给VxD；同时，创建一个辅助线程等待信号变成有信号状态，本身则可去干其它的事情。当条件成熟时，VxD置Ring0事件为有信号状态（调用_VWIN32_SetWin32Event()函数），这马上触发对应的Ring3事件为有信号状态。一旦Ring3事件句柄为有信号状态，Win32应用程序的辅助线程就对这个消息进行相应的处理。
3消息方式
Win32应用程序调用CreateFile()函数动态加载虚拟设备驱动程序。加载成功后，通过调用DeviceIoControl()函数将窗体句柄传送给VxD，VxD利用这个句柄向窗体发消息。当条件满足时，VxD调用SHELL_PostMessage()函数向Win32应用程序发送消息。要让该函数使用成功，必须用#define来自定义一个消息，并且也要照样在应用程序中定义它；还要在消息循环中使用ON_MESSAGE()来定义消息对应的消息处理函数，以便消息产生时，能够调用消息处理函数。SHELL_PostMessage()函数的第一个参数为Win32窗体句柄，第二个参数为消息ID号，第三、四个参数为发送给消息处理函数的参数，第五、六个参数为回调函数和传给它的参数。Win32应用程序收到消息后，对消息进行处理。
4异步I/O方式
Win32应用程序首先调用CreateFile()函数加载设备驱动程序。在调用该函数时，将倒数第2个参数设置为FILE_ATTRIBUTE_NORMAL|FILE_FLAG_OVERLAPPED，表示以后可以对文件进行重叠I/O操作。当设备驱动程序文件创建成功后，创建一个初始态为无信号、需要手动复位的事件，并且将这个事件传给类型为OVERLAPPED的数据结构（如Overlapped）。然后，将Overlapped作为一个参数，传给DeviceIoControl()函数。设备驱动程序把这个I/O请求包（IRP）设置为挂起状态，并且设置一个取消例程。如果当前IRP队列为空，则将这个IRP传送给StartIo()例程；否则，将它放到IRP队列中。设备驱动程序做完这些工作后，结束这个DeviceIoControl()的处理，于是Win32应用程序可能不等待IRP处理完，就从DeviceIoControl()的调用中返回。通过判断返回值，得到IRP的处理情况。如果当前IRP处于挂起状态，则主程序先做一些其它的工作，然后调用WaitForSingleObject()或WaitForMultipleObject()函数等待Overlapped中的事件成为有信号状态。设备驱动程序在适当的时候处理排队的IRP，处理完成后，调用IoCompleteRequest()函数。该函数将Overlapped中的事件设置为有信号状态。Win32应用程序对这个事件马上进行响应，退出等待状态，并且将事件复位为无信号状态，然后调用GetOverlappedResult()
函数获取IRP的处理结果。
5事件方式（WDM）
Win32应用程序首先创建一个事件，然后将该事件句柄传给设备驱动程序，接着创建一个辅助线程，等待事件的有信号状态，自己则接着干其它事情。设备驱动程序获得该事件的句柄后，将它转换成能够使用的事件指针，并且把它寄存起来，以便后面使用。当条件具备后，设备驱动程序将事件设置为有信号状态，这样应用程序的辅助线程马上知道这个消息，于是进行相应的处理。当设备驱动程序不再使用这个事件时，应该解除该事件的指针。
驱动程序范文3
关键词:电源管理; WDM; PCI; IRP
中图分类号:TN302.7 文献标识码:A
文章编号:1004-373X(2010)14-0196-03
Driver Development of Power Management for PCI Device
CHENG Hai-quan1,2, HU Jun1, XU Shu-yan1, XIE Ai-ping3
(1. Space Optics Research Department, Changchun Institute of Optics, Fine Mechanics and Physics, Chinese Academy of Sciences, Changchun 130033, China;
2. Graduate School, Chinese Academy of Sciences, Beijing 100039, China;
3. College of Communication Engineering, Jilin University, Changchun 130032, China)
Abstract: The cooperation of operating system (OS) and driver is needed to control the power status of equipments for making PCI device to possess the function of power management. By the aid of the study on the power supply of systems and devices under Windows OS, a power management scheme is proposed to control the power status of equipments through processing system power IRP in WDM driver. WDM driver's mechanism of processing the power management IRP is elaborated. An experiment shows that WDM driver based on this scheme can work well with Windows XP.
Keywords: power management; WDM; PCI; IRP
0 引 言
随着计算机软硬件技术发展,要求设备能够从待机或睡眠中快速启动;要求在不使用时,移动设备能够保持待机或休眠以节省电能的情况越来越多,传统的冷启动或热启动(复位启动)已不能满足人们的要求。微软在Windows操作系统下设计了电源管理构架,为系统和设备的电源管理需求提供了广泛的支持。目前Windows系统下的电源管理支持(advanced configuration and power interface ,ACPI) 高级配置和电源界面工业标准。
根据微软的WDM驱动程序模型,很容易写出具有一定功能的驱动程序,可是在设备运行了一段时间后,当系统要进入待机或休眠状态时,就会发现桌面上弹出一个窗口――禁止待机。出现这种现象是由操作系统的默认电源管理策略所致,实际的原因在于驱动程序中没有写关于电源管理的代码。本文中研究的WDM驱动就是为了使设备配合操作系统支持系统的待机和休眠。
1 系统和设备的电源策略
电源管理主要涉及操作系统和设备,系统电源状态指示整个系统的总体电源使用,而设备电源状态指示鞲霆设备使用多少能量。PCI设备支持的电源等级是由PCI配置空间中的电源管理能力结构描述的[1]。PCI总线电源管理接口规范描述了电源管理能力结构寄存器和电源管理事件信号以及辅助电源,这些寄存器和信号让操作系统可以控制PCI总线以及总线上每个功能的电源[2]。
电源管理器管理着系统级的电源策略,设备电源策略主负责设备的电源策略,它们互相配合才能完成系统和设备的电源状态转换。
1.1 系统和设备电源状态
Windows操作系统定义了6种系统状态S0~S5,S0称为工作状态,S1~S4属于睡眠状态。S5是关闭状态。设备按照ACPI规范定义了4种设备状态D0~D3。在D0状态中,设备处于全供电状态。在D3状态中,设备处于无供电(或最小限度的电流)状态。中间的D1和D2状态指出设备的2个不同睡眠状态。Microsoft规定了不同类型设备的类专用的电源需求,该规范要求每个设备至少要支持D0和D3两个状态[3]。
1.2 电源状态转换
应用程序请求、系统活动/电池级别或用户按下电源按钮会导致电源状态的改变,例如系统在响应待机(standby)命令过程中,电源管理器首先向每个驱动程序发送带有IRP_MN_QUERY_POWER副功能码的IRP_MJ_POWER请求以询问设备能否接受即将到来的电源关闭请求。如果所有驱动程序都同意,电源管理器将发送第2个带有IRP_MN_SET_POWER副功能码的电源管理IRP(I/O reequest package),然后驱动程序把其设备置入低电源状态以响应这个IRP[3-4]。
前文中驱动程序不能待机的原因,也就在这里,不符合电源管理要求的驱动程序否决了电源管理器发来的要求改变电源状态IRP,导致系统不能待机。
1.3 PCI总线驱动程序与电源管理能力结构
总线驱动程序在电源管理中发挥着重要作用,甚至可以是电源策略主[5]。PCI电源管理能力结构为操作系统提供了一种标准机制来控制设备的功耗管理。对于某一个PCI设备来讲,设备本身直接由PCI总线驱动程序管理[3]。总线驱动程序通过存取PCI电源管理能力结构的寄存器直接控制设备运行,达到物理上改变设备的电源状态。
2 驱动程序设计过程
要使WDM驱动程序具有电源管理功能,首先需要在DriverEntry入口函数中注册IRP_MJ_POWER IRP的派遣函数例程[6-7]。
pDriverObject->MajorFunction[IRP_MJ_POWER]= PowerDispatchRoutine;
驱动程序的电源管理例程围绕电源IRP_MJ_POWER IRP进行处理,这些例程处理这个IRP,并在需要时产生这个IRP。这个IRP有4个电源管理次功能代码,如表1所示。
表1 IRP_MJ_POWER次功能代码
次功能IRP代码描述
IRP_MN_QUERY_
POWER查询系统或设备状态变化是否可行
IRP_MN_SET_POWER设置系统或设备电源状态
IRP_MN_WAIT_WAKE唤醒计算机,响应1个外部事件
IRP_MN_POWER_SEQUENCE发送这个IRP,确定设备是否真正进入特定的电源状态
大多数驱动程序要求必须处理表1中前2个IRP,具有唤醒能力的设备驱动要处理IRP_MN_WAIT_WAKE。这里对IRP_MN_WAIT_WAKE和IRP_MN_POWER_SEQUENCE做默认处理。
NTSTATUS PowerDispatchRoutine(IN PDEVICE_OBJECT fdo, IN PIRP Irp) {
PAGED_CODE();
KdPrint(("Enter PowerDispatchRoutine\\n"));
NTSTATUS status = STATUS_SUCCESS;
switch(stack->MinorFunction) {
case IRP_MN_SET_POWER:
status = SetPowerState(fdo, Irp);
break;
case IRP_MN_QUERY_POWER:
status =QueryPowerState(fdo, Irp);
break;
case IRP_MN_WAIT_WAKE:
case IRP_MN_POWER_SEQUENCE:
default:
status = DispatchPowerDefault(fdo, Irp);
break;
}
return status;
}
电源管理器,维护一个单独的电源IRP内部队列,这保证在系统中只有一个“设置系统电源”IRP在处理,还保证每个设备只有一个“设置设备电源”IRP在运行[5]。
设备在完成一个电源IRP的处理时,必须告诉电源管理程序,使得它可以开始下一个电源IRP的处理。一般的默认处理就是简单地把一个IRP沿设备栈向下传递(没有完成例程),在跳过或复制当前IRP栈单元之前,应调用PoStartNextPowerIrp函数,如果使用完成例程,通常也必须调用PoStartNextPowerIrp。
NTSTATUS DispatchPowerDefault(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)
{
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) DeviceObject->DeviceExtension;
PoStartNextPowerIrp(Irp);
IoSkipCurrentIrpStackLocation(Irp);
return PoCallDriver(pdx->LowerDeviceObject, Irp);
}
2.1 设备电源能力结构
PnP管理器在启动设备后向设备发出查询设备能力的请求,该请求的参数是一个DEVICE_CAPABILITIES结构,PCI总线驱动程序通常填充DEVICE_CAPABILITIES结构,该结构包含了与电源管理有关的几个域。功能设备驱动程序应该首先向设备栈下转发该IRP,等待IRP完成后,在必要时可以更改DEVICE_CAPABILITIES结构。
电源策略主负责检查DEVICE_CAPABILITIES结构中的DeviceState域来确定每个系统电源状态对应的设备电源状态。这个结构中指出了对应于一个系统电源级设备可以处于的最高电源状态。功能驱动程序可以在设备扩展中存储这个结构中相关的域,在这个IRP完成以后,驱动程序不能改变它的内容[3]。
2.2 处理系统电源IRP
如果驱动程序收到一个“设置系统电源状态”IRP,首先必须确定等效的设备电源状态,如果当前设备电源状态与要求的设备状态不同,必须改变设备的状态。通常总是把设备设置成与设备的当前活动、设备的电源能力以及系统的电源状态相一致的最低电源状态。
在向底层驱动程序传递“设置系统电源状态”IRP之前改变设备状态,在所有底层驱动程序处理后再给设备加电。必须给自己发出“设置设备电源状态”IRP以改变设备电源状态,然后等待这个IRP完成,然后可以继续处理“设置系统电源状态”IRP。以处理系统将要管理为例说明这个过程[4],如图1所示。
图1 降低系统电源IRP处理过程
2.3 处理设备电源IRP
如果收到“设置设备电源状态”IRP,在调用低层驱动程序前,必须关闭设备的电源。在所有低层驱动程序启动后,再启动设备。这意味着应设置一个完成例程,并在那里给设备加电。这里以处理降低设备电源状态为例[5]说明这个过程,如图2所示。
图2 降低设备电源IRP处理过程
2.4 实验结果及分析
在Windows XP系统上加载采用这种电源管理方案的虚拟设备驱动程序,使系统从全功耗运行转向休眠,再从休眠中恢复,用DebugView工具得到驱动打印的Log信息如下:
Enter HelloWDMPower
Power Manager query power state
Enter DispatchSystemPowerIrp
Enter CompletionSystemPowerRoutine
Send device power IRP according to system power IRP
Enter HelloWDMPower
Power Manager query power state
Enter DispatchDeviceQueryPower
Device power state query
newDeviceState = 4
Ready to pass down IRP for device power state query
Enter PowerDownPrepCallback
Enter DevicePowerCompleteCallback
Enter HelloWDMPower
System or device power is going to be change
Enter DispatchSystemPowerIrp
System power state change
newSystemState = 5
Enter CompletionSystemPowerRoutine
Send device power IRP according to system power IRP
Enter HelloWDMPower
System or device power is going to be change
Enter DispatchDeviceSetPower
Device power down
newDeviceState = 4
Ready to pass down IRP for device power state change
Enter PowerDownPrepCallback
Enter DevicePowerCompleteCallback
Enter HelloWDMPower
System or device power is going to be change
Enter DispatchSystemPowerIrp
System power state change
newSystemState = 1
Enter CompletionSystemPowerRoutine
Send device power IRP according to system power IRP
Enter HelloWDMPower
System or device power is going to be change
Enter DispatchDeviceSetPower
Device power up
newDeviceState = 1
Enter CompletionDevicePowerUp
Enter PowerUpCallback
Enter DevicePowerCompleteCallback
上述结果表明使用这种电源管理方案的驱动程序能和系统配合休眠,并能够成功从休眠的状态下启动,另外具体应用到硬件上时要在说明的地方加上与设备相关的代码。
3 结 语
本文介绍了PCI设备电源管理驱动程序的开发,电源管理在PCI规范中是可选的,现在PCI Express设备越来越多,而PCI Express设备必须实现电源管理能力。由于PCI Express与PCI软件上兼容这里研究的电源管理方案同样适用于PCI Express设备[8-10]。限于篇幅本文只给出了部分实现代码,完整实例请参考WDK给出的toaster程序。
参考文献
[1]PCI-SIG. PCI bus power management interface specification revision 1.2[EB/OL].[ 2004-03-03] . .
[2]李贵山,陈金鹏.PCI局部总线及其应用[M].西安:西安电子科技大学出版社,2003.
[3]Microsoft. Windows driver kit 7600[EB/OL].[ 2009-10-01] ..
[4]ONEY Walter. Programming the microsoft windows driver model[M]. US: Microsoft Press, 1999.
[5]Chris Cant.Windows WDM设备驱动程序开发指南[M].孙义,译.北京:机械工业出版社,2000.
[6]PCI-SIG. PCI local bus specification v3.0[EB/OL].[ 2010-03-10] ..February 3,2004.
[7]张强.Compact PCl板卡硬件设计与传输速率测试[J].光学精密工程,2009,17(8):2049-2050.
[8]PCI-SIG. PCI.Express.Base.Specification.v1.1 [EB/OL].[ 2005-03-28] ..
驱动程序范文4
关键词：TMS320DM642；DSP/BIOS；类/微型驱动模型；GIO；帧视频模块
中图分类号：TP391 文献标识码：B 文章编号：1004373X(2008)1517404
Development of Video Port Driver Based on DSP/BIOS Device Driver Model
YAN Xinzhong,LIU Zhe
(School of Electronic Information and Automation,Tianjin University of Science & Technology,Tianjin,300222,China)
Abstract：This paper takes TMS320DM642 DSP for example and introduces a method of programming the device driver,which based on DSP/BIOS Class/Mini driver model.The Class/Mini driver model is divided into two layers.One is device-independent layer and the other is device-specific layer.This architecture makes it easier to program the device driver.The application uses class driver API to call the mini driver function indirectly in order to control the peripheral pared with the traditional software development,the driver development based on the two-layer device driver model improves efficiency and increases compatibility and portability.
Keywords：TMS320DM642;DSP/BIOS;class/mini driver model;GIO;frame video model
通过给外部设备编写驱动程序是一种有效的控制外设的方法。随着DSP的应用越来越广泛，DSP实时系统的日趋复杂及新技术的出现，DSP处理器所连接的外部设备也是种类繁多，各不相同，而每一个外设都需要一个特定的驱动程序来支持外设的正常工作，这就要为每一个外设编写驱动程序，这是一项十分繁杂的工作。如何能够使系统开发人员从这些编写繁杂的驱动程序工作中解脱出来，进而能够专心投入到应用程序的开发中呢？TI公司提出了基于DSP/BIOS的设备驱动模型，该模型分为两层：类驱动即与硬件不相关的层和微型驱动即与硬件相关的层。使用这种结构，应用程序只需调用类驱动的API函数，通过类驱动使用微型驱动，用微型驱动来控制外设。这种结构，将驱动程序合理分层，使得驱动程序模块化，可移植性、复用性大大增强，缩短了驱动程序的开发时间。
1 DSP/BIOS设备驱动模型
1.1 类/微型驱动模型
DSP/BIOS是TI公司所设计开发的一个尺寸可裁剪的实时多任务操作系统内核，通过使用DSP/BIOS提供的丰富的内核服务，开发者能快速地创建满足实时性能要求的精细复杂的多任务应用程序。为了使开发设备驱动更加简单方便，提出了DSP/BIOS Device Driver Kit，定义了标准的设备驱动模型，一种将设备驱动分为与硬件无关和与硬件相关的双层结构，这样就使开发驱动程序不像以前那样复杂了，为开发者提供了便利。这两层结构称为“类/微型驱动模型”［1］，它们每一层都有各自通用的接口，所以相似设备驱动程序的主要部分可以复用，驱动代码的移植成为可能，使开发驱动的过程大大简化。
与硬件无关的层称为类驱动(Class Driver)，它处在应用程序与微型驱动之间，提供对多线程I/O请求的串行化和同步，并且维护设备数据缓冲区，向上提供API接口供应用程序调用，向下通过适配层与微型驱动相连，实现API接口函数到微型驱动层的映射。
与硬件相关的层称为微型驱动(Mini-driver)，它处在类驱动与芯片支持库(Chip Support Library)之间，对于类驱动的接口是统一的，即每一个微型驱动都为类驱动和DSP/BIOS设备驱动管理提供了标准接口。微型驱动采用芯片支持库(CSL)管理设备的寄存器、内存和中断资源［2］。但由于硬件是千差万别的，所以微型驱动对底层硬件的操作是根据硬件的不同而不同的。对于完成同样功能的不同外设，只需稍加修改微型驱动，而不需重新编写驱动程序，就可以实现驱动程序的移植与复用，使驱动程序的开发过程大大简化。类/微型驱动模型结构如图1所示。
1.2 类驱动
通过将应用软件，驱动程序分层之后，可以看到，位于顶层的应用程序并不直接与微型驱动产生联系，而是通过类驱动与微型驱动连接。每一种类驱动向上层应用程序提供一个API接口，并且与微型驱动接口进行通信。
DSP/BIOS定义了三种类驱动：流输入输出模块(SIO)，管道管理模块(PIP)，通用输入输出模块(GIO)。其中，SIO和PIP分别需要使用适配器DIO和PIO来与微型驱动进行通信。SIO/DIO是基于流的I/O模型，使用异步方式来操作I/O，对于数据的读写、处理可以同时进行。PIP/PIO是基于管道的I/O模型，每个管道维护着一个被划分为多个大小相同的帧的缓冲区。GIO类驱动采用基于流的同步I/O数据传输模式，适合大流量数据的传输，更适合文件系统。与SIO/DIO和PIP/PIO不同，GIO包含内置的IOM(I/O Manager输入输出管理)适配层，可以直接与微型驱动进行通信。
GIO模块与其他两个模块相比，有一个很重要的特性，就是可以扩展API函数支持新的应用领域，这样就实现了对GIO类驱动的扩展。这种可扩展API的特性正好可以用在视频驱动开发方面。例如这种扩展可以满足视频设备存储区的需要。另外，在提供了视频驱动和应用程序之间的视频数据同步机制之后，这种扩展也能够允许使用一个单独的调用来“交换”视频缓冲区。这种交换缓冲区的机制对于实时视频信号的采集与显示是十分重要的。所以，在视频驱动中，我们采用通用输入输出模块GIO。应用程序可以直接地调用GIO API函数和IOM微型驱动程序进行交互，这些GIO API就可以看作是类驱动。GIO类驱动接口如图
2所示。
GIOcreate会为一个特定的IOM通道实例创建一个GIO对象，这是类驱动使用微型驱动的第一步，首先创建对象及IOM通道，然后在此通道上进行数据传输工作。其结构体类型为GIOObj：
Typedef struct GIOObj{
IOMFxn *fxns;//指向IOM函数表fxn
Uns mode;//通道的使用模式 IOMINPUT IOM
OUTPUT IOMINOUT三种模式
Uns timeout;//模块调用所用时间
IOMPacket syncPacket;//只用于同步操作的IOMPacket
QUEObj freeList;//用于异步操作，存放在类与微型驱动
之间使用的任何IOMPacket
Ptr syncObj;//同步对象的隐性指针
Ptr mdChan;//微型驱动通道对象指针
}GIOObj,*GIOHandle;
1.3 微型驱动
微型驱动主要通过一些函数来完成对外部设备的直接控制。只要微型驱动创建了规定的函数，应用程序就可以方便地通过DIO适配模块、PIO适配模块或(和)GIO类驱动调用［2］。
例如：GIOcreate被调用时，会运行mdCreateChan来创建一个通道。
这些微型驱动函数包括：mdBindDev/mdUBindDev(绑定/删除通道函数)：在程序建立接口时调用，完成设备的初始化硬件设备/在程序结束时调用，卸载设备。mdCreateChan/mdDeleteChan(创建/删除通道)：需要在应用程序与设备实例之间创建一个逻辑通信通道，用于交换驱动数据。应用程序可创建一个或多个逻辑通道，微型驱动用通道对象来代表这些通道。这两个函数就是用来分配和释放通道对象。mdSubmitChan(递交I/O请求)：该函数处理传递给它的IOMPacket结构体中的命令代码(cmd),根据命令代码，完成相应的处理或返回错误代码。ISR(服务设备中断并完成I/O操作)：IOM微型驱动在中断的ISR中将以处理完的IOMPacket请求出队，启动下一次传输或服务请求，调用类驱动的回调函数与应用程序进行同步，并返回出队的IOMPacket。mdControlChan(控制设备)：用来操作外部设备。
这些微型驱动的函数入口放在接口表(IOMFxns)中，供适配模块或GIO类驱动调用。
2 TMS320DM642视频驱动
下面以TMS320DM642芯片为例，介绍有关TMS320DM642视频采集与显示的驱动程序的开发。通过编写驱动程序，完成视频信号的实时采集与显示功能。TMS320DM642是TI公司推出的一款专门用于视频/图像处理的定点数字信号处理器，它基于C64x内核，带有3个可配置的视频端口，与视频采集芯片直接相连，无需外加逻辑电路或FIFO缓存，只需编写相关解编码芯片的驱动程序，就可以完成视频信号的采集与显示。在这里使用的解码、编码芯片分别为PHILIPS SAA7115和SAA7105。
2.1 视频类驱动
在视频驱动程序结构中，为了最大程度地提高视频驱动代码的复用性和通用性，将类驱动又划分为两层结构［3］，其中上层为FVID模型，它是在DSP/BIOS GIO类驱动之上的简单封装，下层是GIO类驱动程序。GIO类驱动提供独立的、一般的API函数集并且为微型驱动提供广泛的服务，而上层的FVID模型向上层的视频采集、显示结构提供定制的API函数。
在视频驱动中，主要是通过调用FVID模块函数来完成类驱动代码的编写工作。FVID主要有以下几个API函数：FVIDcreate：分配并初始化通道对象；FVIDcontrol：向微型驱动发送控制命令；FVIDalloc：向应用程序分配视频端口缓冲区；FVIDexchange：交换缓冲区；FVIDfree：释放缓冲区；FVIDdelete：删除通道对象。
在配备视频接口的设备驱动时，至少指定它要开设3个以上的视频缓冲区(FVID模型中，默认分配3个缓冲区)［4］，帧缓冲区通过FVIDalloc(),FVIDfree(),FVIDexchange()三个函数在应用程序与驱动之间交换。
2.2 视频微型驱动
视频微型驱动也分为两层结构［3］，上层为通用视频端口层部分，下层为指定编解码芯片微驱动层部分，它们通过外部设备控制接口(External Device Control,EDC)实现对芯片的操作。这种微驱动结构的好处是，当使用不同的芯片时，只需修改指定编解码芯片微驱动那一部分，不需将整个微驱动重新编写，使得驱动的复用性大大增强。
视频驱动程序模型如图3所示。
2.3 TMS320DM642视频驱动设计步骤
2.3.1 注册微型驱动
由于应用程序、类驱动最终都是要通过微型驱动的函数来完成对外部设备的直接控制，所以驱动程序设计的第一步就是要在DSP/BIOS Config中的Input/Output->Device Drivers->User-Defined Devices项目添加设备并注册微驱动，进行属性的设置［5］，并指明IOMFxns函数表地址和设备参数地址，如图4所示。
DSP/BIOS会在内部维护一个“设备表”，其中包含User-Defined Devices对象进行配置的设备实例。
2.3.2 编写类驱动代码
FVID函数会在设备表中查找已注册的微驱动，并调用微驱动函数完成对外部设备的操作控制。
通常，首先利用FVIDcreate函数完成分配并初始化通道对象，返回值为设备实例句柄，这个句柄用于后续其他FVID函数调用这个已经创建的通道。然后调用FVIDcontrol函数向微型驱动发送控制命令，如配置编解码器，发送开始采集或显示图像的控制命令。然后利用FVIDalloc分配缓冲区，接着应用程序将缓冲区的数据进行复制的搬移工作，当应用程序完成对缓冲区数据的采集后，调用FVIDexchange来交换缓冲区，保证视频数据能够实时地、源源不断地供应用程序使用。
过程的流程图如图5所示。
下面是简单的视频采集显示驱动的部分实现代码：
FVIDHandle disChan;//定义显示句柄
FVIDHandle capChan;//定义采集句柄
capChan = FVIDcreate("/VP0CAPTURE/A/0",
IOMINPUT,&status,(Ptr)&EVMDM642vCapParamsChan,NULL);//创建采集通道
disChan = FVIDcreate("/VP2DISPLAY",
IOMOUTPUT,&status,(Ptr)&EVMDM642vDisParamsChan,NULL);//创建显示通道
FVIDcontrol(disChan,VPORTCMDEDCBASE + EDCCONFIG,
(Ptr)&EVMDM642vDisParamsSAA7105);
驱动程序范文5
2、点击“打印服务器属性”。
3、在“驱动程序”一栏下点击“添加”。
4、此时会出现添加打印机驱动程序向导，点击：下一步。
5、根据电脑的操作系统位数来选择，然后点击：下一步。
6、选择要安装的打印机驱动的制造商和型号，点击：下一步。
驱动程序范文6
关键字 Windows系统 驱动程序 通知应用程序 设计 方法
中图分类号： TP316 文献标识码：A
1 前言
操作系统的稳定性及可移植性是务必要优先确保的，为此Windows操作系统不支持应用程序直接访问系统的硬件资源，而是必须借助于相应的设备驱动程序。设备驱动程序可以直接操作硬件，假如应用程序和设备驱动程序之间实现了双向通信，也就达到了应用程序控制底层硬件设备的目的。
2 通知应用程序设计四种方法
鉴于设备驱动程序通知应用程序的重要性，本人结合一些经验，对它进行了总结，归纳出5种方法摘要：异步过程调用（APC）、事件方式（VxD）、消息方式、异步I/O方式和事件方式（WDM）。下面分别说明这几种方式的原理。
2.1 异步过程调用（APC）
Win32应用程序使用CreateFile（）函数动态加载设备驱动程序，然后定义一个回调函数backFunc（），并且将回调函数的地址%26amp；backFunc（）作为参数，通过DeviceIoControl（）传送给设备驱动程序。回调函数的输入参数是由设备驱动程序填入的，回调函数在这里主要是对消息进行处理。
2.2 事件方式（VxD）
首先，Win32应用程序创建一个事件的句柄，称其为Ring3句柄。由于虚拟设备驱动程序使用事件的Ring0句柄，因此，需要创建Ring0句柄。用LoadLibrary（）函数加载未公开的动态链接库Kernel32.dll，获得动态链接库的句柄。然后，调用GetProcAddress（）， 找到函数OpenVxDHandle（）在动态链接库中的位置。接着，用OpenVxDHandle（）函数将Ring3事件句柄转化为Ring0事件句柄。Win32应用程序用CreateFile（）函数加载设备驱动程序。
2.3 消息方式
Win32应用程序调用CreateFile（）函数动态加载虚拟设备驱动程序。加载成功后，通过调用DeviceIoControl（）函数将窗体句柄传送给VxD，VxD利用这个句柄向窗体发消息。当条件满足时，VxD调用SHELL_PostMessage（）函数向Win32应用程序发送消息。SHELL_PostMessage（）函数的第一个参数为Win32窗体句柄，第二个参数为消息ID号，第三、四个参数为发送给消息处理函数的参数，第五、六个参数为回调函数和传给它的参数。Win32应用程序收到消息后，对消息进行处理。
2.4 事件方式（WDM）
Win32应用程序首先创建一个事件，然后将该事件句柄传给设备驱动程序，接着创建一个辅助线程，等待事件的有信号状态，自己则接着干其他事情。设备驱动程序获得该事件的句柄后，将它转换成能够使用的事件指针，并且把它寄存起来，以便后面使用。
3 结语
在目前流行的Windows操作系统中，设备驱动程序是操纵硬件的最底层软件接口。它向上提供和硬件无关的用户接口，向下直接进行I/O、硬件中断、DMA和内存访问等操作。它将应用程序和硬件细节屏蔽开来，使软件不依靠于硬件并且可在多个不同的平台之间移植。这4种方法都经过实际测试。测试结果表明，它们都能够达到设备驱动程序通知应用程序的目的。
参考文献
[1] 李和平. 基于DSP的ICT图像重建系统探究. 北京摘要： 北京航空航天大学机械工程及自动化学院， 2002
