USB驱动程序编写
USB接口通信(驱动)的设计与实现

引言WDM是“Windows驱动程序模型”的简称,即“Windows Driver Model”。
实际上它是一系列集成在操作系统之中的常规系统服务集,用于简化硬件驱动程序的编写,并保证它们在Windows 98/Me/2000中的二进制兼容,WDM(Windows Driver Model)模型是从WinNT3.51和WinNT4的内核模式设备驱动程序发展而来的。
WDM主要的变化是增加了对即插即用、电源管理、Windows Management Interface(WMI)、设备接口的支持。
WDM模型的主要目标,是实现能够跨平台使用、更安全、更灵活、编制更简单的Windows 设备驱动程序。
WDM采用了“基于对象”的技术,建立了一个分层的驱动程序结构。
WDM 首先在Windows98中实现,在Windows2000中得到了进一步的完善,并在后续开发的Windows操作系统中都将存在,比如Windows Me和Windows XP。
微软在通过WDM 模型的引入,希望减轻设备驱动程序的开发难度和周期,逐渐规范设备驱动程序的开发,应该说,WDM将成为以后设备驱动程序的主流。
USB技术的全称是通用串行总线,是英文Universal Serial Bus的缩写。
它是一种应用在PC领域的新型接口技术,虽然USB2.0已经被广泛应用,但是初始的Windows 2000是支持USB1.0协议的,如果希望支持USB2.0协议,需要在微软网站上下载升级包。
实际上,对于键盘或者鼠标来说,传输的速度非常小,使用USB1.0或者是USB2.0的区别并不大。
闪存盘之类的存储设备,则需要重视传输速度。
USB1.0版本主要应用在鼠标,键盘等HID设备上,这就是本驱动程序中引用的头文件版本是USB1.0的原因。
本毕业设计的目的是希望对Windows 2000操作系统体系结构和驱动程序开发以及调试等方面的问题有一个比较深入的了解,对USB协议和USB体系有做一个比较深入的了解。
USB驱动程序的编写采用WDM 驱动程序

USB驱动程序的编写采用WDM 驱动程序。
WDM 驱动程序是一些例程的集合,它们被动地存在,等待主机系统软件(PnP 管理器、I/O 管理器、电源管理器等)来调用或激活它们。
具体驱动程序不同,其所包含的例程也不同。
一个WDM 驱动程序的基本组成包括以下5个例程:(1)驱动程序入口例程:处理驱动程序的初始化。
(2)即插即用例程:处理PnP 设备的添加、删除和停止。
(3)分发例程:处理用户应用程序发出的各种 I/O 请求。
(4)电源管理例程:处理电源管理请求。
(5)卸载例程:处理驱动程序的卸载。
包含文件:ezusbsys.c, ezusbsys.h,ezusbsys.rc, resource.h, version.h, makefile,sources)在ezusbsys.c文件中,包含了上述五个例程:ezusbsys.h中定义了各种数据结构还有各种IOCTL控制码,用于不同数据的读写。
Ezusbsys.c 中实现了各种驱动例程。
包含了上述五个所说例程外还包含了其他例程,课程从下面的驱动程序入口例程得出一些信息。
驱动程序入口例程:NTSTATUSDriverEntry(IN PDRIVER_OBJECT DriverObject,IN PUNICODE_STRING RegistryPath){NTSTATUS ntStatus = STATUS_SUCCESS;PDEVICE_OBJECT deviceObject = NULL;DriverObject->MajorFunction[IRP_MJ_CREATE] = Ezusb_Create; DriverObject->MajorFunction[IRP_MJ_CLOSE] = Ezusb_Close;//分发例程DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = Ezusb_ProcessIOCTL;//即插即用例程DriverObject->MajorFunction[IRP_MJ_PNP] = Ezusb_DispatchPnp;//电源管理例程DriverObject->MajorFunction[IRP_MJ_POWER] = Ezusb_DispatchPower;//设备添加例程DriverObject->DriverExtension->AddDevice = Ezusb_PnPAddDevice;//卸载例程DriverObject->DriverUnload = Ezusb_Unload;return ntStatus;}在原有框架下,主要实现了的代码段在于ezusbsys.c文件中的如下例程:NTSTATUSEzusb_Read_Write( IN PDEVICE_OBJECT fdo, IN PIRP Irp )在该例程中实现对大数据块的读写控制和实现。
USB设备的驱动程序实现

USB设备的驱动程序实现
USB驱动是用来控制使用USB接口的设备的软件程序,其实现是将实
际的硬件设备抽象为虚拟的设备,使其能够在计算机操作系统上应用。
一
般来讲,当你将USB设备插入你的计算机时,它将通过计算机的USB主控
芯片找到USB设备,然后测试它的功能,并决定它是否能够被用来通信,
最后安装相应的驱动程序。
实际的USB驱动程序的实现有若干方法,其中
有两种常用的技术:应用程序编程接口(API)和驱动程序模板。
1、应用程序编程接口(API)
API是一组用于访问操作系统提供的服务和功能的特殊指令序列。
应
用程序编程接口(API)可以用来创建USB驱动程序,其实现包括以下步骤:
(1)定义硬件设备的描述
在编写USB驱动程序时,首先需要定义硬件设备,即定义设备的功能,记录其编号、最大支持通信速率、硬件连接方式、发送和接收设备数据的
方式以及支持的驱动软件要求等信息。
(2)实现设备驱动的关键函数
关键函数是控制USB设备正常工作所必需的函数,包括初始化函数、
发送和接收数据的函数、获取设备状态的函数以及关闭设备的函数等。
嵌入式Linux系统下的USB驱动程序开发

程 中 的关键技 术 。
关键 词 : 嵌入 式 ; L i n u x ; U S B ; 驱动 开发 中图分 类号 : T P 3 1 6 文献标 识码 : A
De v e l o p me n t o f US B Dr i v e r Ba s e d o n Em b e d d e d Li n u x S y s t e m
L I C h u n - b o , C HE N We i - f e n g , L A I X u e - j i n
( C h e n g d u U n i v e r s i t y o f T e c h n o l o g y , C h e n g d u 6 1 0 0 5 9 , C h i n a )
Abs t r a c t : The a p pl i c a t i o n s o f Emb e d de d L i n ux s y s t e m a r e mo r e a n d mo r e wi de l y , i t s f u n c t i o ns a r e a l s o mo r e a n d mo r e
H O S T) 、 U S B设 备 ( U S B D E V I C E) 、 U S B 集 线 器
哑 I … ● I _ l C 【 l h 】 i n 国 a I n 集 t e g r 成 a t e d 电 C i r 路 c u i t
————— 珏 斗 。 ]I
嵌入式 L i n u x系统下的 US B驱动程序开发
基于USB接口设备的驱动程序设计

De i n o i ePr g a Ba e n US I t ra eDe i e sg fDrv o r m s d o B n e f c v c
TU a g mi g, EIY u g o DUAN o J , I W n — n W o .u , Da — u L ANG ic e g ZHANG e z i XI n J— h n , Xu - h , E Cu
O 引 言
US ( iesl e a u )ห้องสมุดไป่ตู้ 用 串行 总 线 已成 B Unv ra r l s Si B
文 章 编 号 : 10 — 5 6 ( 0 7 50 8 — 3 0 6 1 7 2 0 )0 —0 9 0
2 0 , 12 , 0 7 Vo . 6 No 5 .
基 于 US B接 口设 备 的驱 动程 序 设计
涂 望 明 ,魏友 国,段 道聚 ,梁季 程 ,张 学 志 ,谢存
( 武汉 军 械士 官 学校 火控 雷 达教 研 室 ,湖北 武 汉 4 0 7 ) 3 05 摘 要 :采用 P I B 2芯 片的基 于 US D US D1 B接 口设 备驱 动程 序 ,模 型 最上 层 的 函数驱 动 程序 ,管理 应 用程 序 与较 低 级总 线驱 动 程序 间的通 信 。底 层 的总 线驱 动程 序 ,管 理 函数驱 动程 序 与设 备硬 件 间通信 。中 间的过 滤 器驱 动程 序 , 辅 助 函数 驱 动 程序 与 总线 驱动 程序 .US B设 备 函数驱 动 程序 与 总 线驱 动程 序 ,使 用 I0信 息 包处 理 US / B的 通信 . 同 时 ,根据 US 通信 协议 ,使 用 Dr eWok 的 工具 模块 进 行 WDM 设备 驱 动程 序 的开 发 . B i r rs v 关键 词 :US B接 口;设备 驱 动程 序 ;P I B 2芯 片;Dr eWok D US D1 i r rs v
USB设备驱动程序的研究与开发

种 例 程 的指 针 等 。其 相关 代码 如下 :
H ̄插 即用例 程人 口 l l J D i r be t > r eE tni > d D v e : r eO jc - D i r xe s n- A d ei v v o c
口。而要 实 现U B 件 设备 与 主机 间 稳定 的数 据 S硬
传 输 ,则 不 可避 免 的要 编 写适 合U B 件要 求 的 S硬
驱 动 程序 。为此 ,本 文结 合 实 例 ,论 述 了U B S 设
备 驱动 程序 的具 体实 现机 制和 开发 方法 。
示 是其 体 系结构 图。
/ R 发送 给下 层 的U B / 将U B S 总线 驱动 程序
D i r bet > aoF n t n【R _ _ R — r eO jc 一 M jru c o I P MJC E v i
A E =D v rae T] rC et;
nSa s sC l S D fo ub tt u =U b a U B I( , r); t l d
4 U B 备 驱 动 程 序 的 实现 S设
驱 动程 序 是一 些例 程 的集 合 ,它 一般 被 动地 存 在 ,以等 待 主 机 系统 软 件 (n 管 理 器 、I PP / O管 理 器 、 电源管 理器 1来 调用 。典 型 的U B 备 驱 S设 动 程序 主要 包 括若 干 例程 ,其 中有 驱 动程 序入 口
31 I P 求包 . R 请
个U B S 系统 的分 层 结 构 。 图 中 ,功 能层 负 责 实 现
U B 备 的特 定 功能 。该 层 不 需 要 理 解U B 体 S设 S具
Silicon Labs USB 驱动程序定制 - AN220说明书

AN220: USB Driver Customization Many of Silicon Labs' USB devices require device drivers to oper-ate within Windows. Default driver installers are provided for these devices. However, if the devices are customized with a non-default VID and/or PID, the drivers must also be customized. This application note provides a tool that creates custom driver installers for Windows to match a device's configuration. This tool also provides additional driver and installation options, such as silent install.The following drivers are available in this tool:• A Virtual COM Port Driver is available for the CP210x device family.• A WinUSB driver is available for the CP2130 device.•Direct Access Drivers(formerly called USBXpress) are available for the CP210x, C8051F32x, C8051F34x, C8051F38x, C8051T32x, C8051T62x, and EFM8UBx de-vice families.This document describes the steps necessary to customize the Windows device driver installation using the Custom USB Driver Installation Wizard.KEY POINT•Use the Custom USB Driver Installation Wizard to create a custom Windows driver installer with your unique VID/PID and installation options.APPLICABLE DEVICES•CP210x•CP2130•C8051F32x•C8051F34x•C8051F38x•C8051T32x•C8051T62x•EFM8UBxCustomizing Driver Installations 1. Customizing Driver InstallationsThe driver installation is customizable by modifying certain sections of the hardware installation files (.inf). The strings contained in the .inf files affect what is displayed in the “Found New Hardware Wizard” dialogs, Device Manager, and the Registry. The changes to the VID and PID in the driver installation should match the VID and PID contained in the EPROM/FLASH of your product. See “AN721: USBXpress™ Device Configuration and Programming Guide” for more information on changing the VID and PID for your product. Note: Any changes to the Windows installation .inf files will require new Windows Hardware Quality Labs (WHQL) tests.2. Using the Custom USB Driver Installation WizardThe Custom USB Driver Installation Wizard generates a custom driver installation for distribution to end-users. This customized installa-tion consists of modified .inf files, optional installation support files, and driver files for Windows 7/8/8.1/10.The optional installation executable provided can be used to copy driver files and register a device on a PC before or after the device has been connected. It will also add an entry in the add/remove programs listing. When the device is connected to the PC for the first time, the drivers will be installed with little interaction from the user.Note: A customized installation does not contain certified drivers for Windows 7/8/8.1/10. Certification must be performed by Microsoft for the new driver installation. Uncertified drivers cannot be installed in Windows 7/8/8.1/10 except under certain testing conditions.To run the Custom USB Driver Installation Wizard, open CustomUSBDriverWizard.exe, which is included in the AN220SW.zip down-load. The figure below shows the first screen of the Custom USB Driver Installation Wizard. Choose the type of driver installation de-sired. For detailed instructions on creating a custom driver installation, see 3. Creating a Custom Driver . This description goes through the process of customizing a CP210x driver. The process for creating a Direct Access (USBXpress) driver or CP2130 driver is the same as this description, only select “USBXpress WinUSB Driver Installation” or "CP2130 WinUSB Driver Installation" on the starting screenof the wizard, respectively.Figure 2.1. Driver Installation SelectionUsing the Custom USB Driver Installation Wizard3. Creating a Custom DriverThis section describes how to create a custom driver. To begin, choose the type of installation to customize: “Virtual COM Port Driver Installation”, “USBXpress WinUSB Installation”, or "CP2130 WinUSB Driver Installation". Differences between the three installations are noted, but a sample CP210x customization is shown in the figures. Next, determine if an installation executable should be generated (see 3.5 Installation String Options and 3.8 Generation Directory for more information on the generated installer), and click Next.3.1 Driver Certification WarningThe first screen is the warning explaining that the generated driver installation will not be certified. (See figure below.) Click Next to begin customizing your driver installation.Figure 3.1. Driver Certification Warning3.2 Operating System SelectionThe first step in the customization utility (shown in the figure below) is to specify the operating system for which the custom driver is being generated.Figure 3.2. Operating System Selection3.3 String and File Name CustomizationThe next step in the customization utility (shown in Figure 3.3 String and File Customization on page 6) is to specify your preferred strings and filenames. Each field is described in further detail below.3.3.1 Company Name (Long Name for .inf File Entries)The company name appears in the .inf file entries and has a maximum length of 255 characters.3.3.2 Company Abbreviation (Short Name for .inf File Entries)The abbreviation appears in the .inf file entries and has a maximum length of 31 characters.3.3.3 File Name for .infThis field allows for specification of a unique name for the .inf file. The maximum length of this string is eight characters. The generated file will be named xxxxxxxx.inf.Figure 3.3. String and File Customization3.4 VID, PID, and Device Name CustomizationThe next step in the customization utility (shown in Figure 3.4 VID and PID Customization on page 7) allows multiple VID/PID combi-nations in one driver. This entry is also where the Device Name, which appears in Windows Device Manager, is specified. An example for Windows 7 is shown in Figure 3.6 Windows 7 Device Manager Example on page 9.3.4.1 General Device Installation NameThis field is the general description of device installation. This will not appear in Device Manager, but will show up during installation if the user is prompted for a disk.The Device List allows multiple VID and PID combinations to be added to one driver. Current devices can be edited by double-clicking an entry.Figure 3.4. VID and PID CustomizationTo add a new entry, click the Add button. A new dialog box (shown in Figure 3.5 Add VID/PID/Device Name to Installation on page 8) will appear with the following options.3.4.3 Device TypeThis specifies which device is being customized. If the VCP driver for the CP2105 Dual UART Bridge is being customized, two interface names will appear. Likewise, if the VCP driver for the CP2108 Quad UART Bridge is being customized, four interface names will ap-pear. Otherwise, only one interface name will appear.3.4.4 VIDAllows specification of a new vendor ID (VID).3.4.5 PIDAllows specification of a new product ID (PID).This string will be displayed in Device Manager under the Ports or USB tab. If the VCP driver is being customized for a multiple-inter-face bridge device, one string will be displayed per interface.Figure 3.5. Add VID/PID/Device Name to InstallationFigure 3.6. Windows 7 Device Manager ExampleIf an installer is not being generated, then skip to 3.9 Option Verification.3.5 Installation String OptionsThe next step in the customization process is to specify options for the driver installer. The driver installer will allow for a device to be installed before or after a device has been connected to the PC. If this is run before a device is plugged in, drivers will already be regis-tered for devices that belong to that installation. If a device is already plugged in, the installer will rescan the bus for any devices for that installation. This section covers adding the installer's strings and is shown in Figure 3.7 Installation Strings on page 10. The driver installer and its corresponding setup.ini file are explained in further detail in “AN335: USB DRIVER INSTALLATION METHODS”.3.5.1 Product NameThis is the string that identifies the product installation in the Add/Remove Programs listing. The string shows up as “<Product Name String> (Driver Removal)” for easy identification.3.5.2 Name for Installation FileThis is will be the name of the installation executable and shows up as “<InstallName>.exe”.Figure 3.7. Installation Strings3.6 Device OptionsThe next step in the customization utility (shown in 3.6.2 Selective Suspend Support) is to configure the serial enumeration and selec-tive suspend options.3.6.1 Serial Enumeration SupportThis allows Windows to “enumerate” a device(s), such as serial mice or an external modem, connected to the CP210x . If your device always presents data to the PC (such as a GPS device), then disable this to prevent false serial enumerations.3.6.2 Selective Suspend SupportEnabling this feature will put the device to sleep if it has not been opened for a time longer than the specified Timeout Value. This is used to save power on the PC and is recommended unless your CP210x needs to be powered if a handle to the device is not opened.Figure 3.8. Device Options3.7 Installation OptionsSpecific options for the GUI should now be specified.3.7.1 Display GUI Window during InstallCheck this option when using the generated Installer as a stand-alone application. The Installer will display several GUI windows during the installation process. Uncheck this option to run the Installer in Quiet Mode. When running in Quiet Mode, no GUI will be displayed. This is useful when using another application to launch this Installer.3.7.2 Copy Files to Target Directory during Install:Check this option if a copy of the drivers will be needed on the hard drive. This is useful when installing the drivers from a CD. Uncheck this option if copies of the driver files are not needed on the hard drive.3.7.3 Target DirectorySelects the hard drive location that will contain a copy of the driver files. The default location is C:\Program Files\Silabs\MCU\CP210x for the VCP Driver and C:\ProgramFiles\Silabs\MCU\USBXpress for the USBXpress driver. If the “Display GUI window during Installa-tion” option is selected, this path can be changed during installation by clicking the Browse button. However, if the “Display GUI window during Installation” option is not selected, then the default directory is always used unless a directory is specified through the command line. This option is ignored if the “Copy Files to Directory during Setup” option is not selected.Note: The Target Directory must be different for each product released.3.7.4 Display GUI Window during UninstallCheck this option when using the generated Uninstaller as a stand-alone application. The Uninstaller will display several GUI windows during the uninstall process. Uncheck this option if the Uninstaller will be launched by another application. The Uninstaller then runs in Quiet Mode. When running in Quiet Mode, no GUI will be displayed.3.7.5 Remove Files from Target Directory during UninstallCheck this option if the files copied to the Target directory should be removed upon uninstallation. This option is ignored if the “Copy Files to Directory during Setup” option is not selected.Figure 3.9. Installation Options3.8 Generation DirectoryThe next step in the customization utility is to specify where this custom driver’s installation files will be generated. The default directory for a VCP driver is C:\Silabs\MCU\CustomCP210xDriverInstall, and the default for a USBXpress Driver is C:\Silabs\MCU\CustomUSBX-pressDriverInstall. However, a different directory can be selected or created. This step is shown in the figure below.Note: This is not an actual installation of the drivers. This is simply a directory to output all installation files needed for the installation. These files can be added to a CD or OEM installation for distribution to the end-user.Figure 3.10. Generation Directory3.9 Option VerificationThe final step in the customization utility is to review all of the selected options. If anything needs to be changed, the Back button can be used to go back to previous pages to change items. Once all options have been verified, press Finish to create the customized driver files. This step is shown in the figure below.Figure 3.11. Option VerificationCustomizing Driver Installations, macOS (Mac OS X) 4. Customizing Driver Installations, macOS (Mac OS X)If the VID or PID is changed from the default factory settings, contact Silicon Laboratories Support (https:///support) to obtain drivers that incorporate the new values. Mac OS X requires that the drivers be compiled with the values that will be used by the production CP210x device.Revision History 5. Revision HistoryRevision 1.1Jun, 2021•Updated the title of AN335.•Replaced the AN144 with the AN721.•Updated Figure 3.2.Revision 1.0August, 2018•Converted to new Appnote format.•Updated screenshots to match the current release of the customization tool.•Added references to CP2130 driver.•Updated Windows versions to currently supported versions 7/8/8.1/10.•Updated references to USBXpress drivers to mention the current name "Direct Access Drivers."•Added EFM8UBx devices to supported device list.Revision 0.7•Added CP2108 to Relevant Devices list.Revision 0.6•Added support for C8051F38x, C8051T32x, and C8051T62x devices.•Updated Figures 1 through 12.Revision 0.5•Added support for CP2104 and CP2105.•Added support for Windows 7.•Updated all screen shots of the AN220 software.•Updated explanations of AN220 software.Revision 0.4•Updated diagrams and wording to reflect 4.1 and later versions of the Custom Driver Wizard.•Updated to include documented support of C8051F34x devices.•Updated to reflect Vista support.Revision 0.3•Updated figures and customization description to reflect version 3.4 and later of the Custom Driver Wizard.•Removed USBXpress specific customization description. Version 3.4 and later contains the same process for customizing both VCP and USBXpress driver installations.•Removed preinstaller explanations and added descriptions on how the new Driver Installer is used.Revision 0.2•Added CP2103 to Relevant Devices on page 1.Revision 0.1•Initial revision.Silicon Laboratories Inc.400 West Cesar Chavez Austin, TX 78701USAIoT Portfolio/IoTSW/HW/simplicityQuality /qualitySupport & Community/communityDisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software imple-menters using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and “Typical” parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the infor -mation supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required or Life Support Systems without the specific written consent of Silicon Labs. A “Life Support System” is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications. Note: This content may contain offensive terminology that is now obsolete. Silicon Labs is replacing these terms with inclusive language wherever possible. For more information, visit /about-us/inclusive-lexicon-projectTrademark InformationSilicon Laboratories Inc.®, Silicon Laboratories ®, Silicon Labs ®, SiLabs ® and the Silicon Labs logo ®, Bluegiga ®, Bluegiga Logo ®, Clockbuilder ®, CMEMS ®, DSPLL ®, EFM ®, EFM32®, EFR, Ember ®, Energy Micro, Energy Micro logo and combinations thereof, “the world’s most energy friendly microcontrollers”, Ember ®, EZLink ®, EZRadio ®, EZRadioPRO ®, Gecko ®, Gecko OS, Gecko OS Studio, ISOmodem ®, Precision32®, ProSLIC ®, Simplicity Studio ®, SiPHY ®, Telegesis, the Telegesis Logo ®, USBXpress ® , Zentri, the Zentri logo and Zentri DMS, Z-Wave ®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Hold-ings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.。
Windows下的USB驱动程序 简单框架

设备非自然弹出 USB设备对应操作
IRP_MN_SURPRISE_REMOVAL
IRP_MJ_PNP
来自: 即插即用管理器
注册标准的WDM回调(Callback)函数
USB设备读写 USB设备热插拔 USB设备初始化
பைடு நூலகம்
Windows下的USB驱动程序 简单框架
(背景知识)
USB功能驱动(FDO)
IRP(URB为参数)
a 尽快结束IRP并逐个取消掉 b 标记设备扩展当前状态为“停止”
设备关闭前 USB驱动程序对应操作
IRP_MN_STOP_DEVICE
a 强迫结束并取消 所有未完成的读写IRP b 标记设备状态为被拔掉
设备正常弹出前 USB驱动程序对应操作
IRP_MN_EJECT
a 强迫结束并取消 所有未完成的读写IRP b 标记设备状态为被拔掉
等待完成IRP
同步
(不做处理)
异步(STATUS_PENDING)
KeWaitForSingleObject
设备堆栈
USB物理总线驱动(PDO) 解释 转化 请求
USB Host 或 USB Hub驱动
PDO完成了大部分工作, 封装了USB协议细节
并为FDO提供了标准的接口
端点描述符
描述处理事务(Transaction)的端点 接口描述符
各种描述符
描述设备提供的功能接口
配置描述符
自下而上 (除端点描述符 可以为0个之外)
设置 IRP_MJ_READ / IRP_MJ_WRITE 派遣函数 调用 API 进行 ReadFile / WriteFile
驱动程序 应用程序
80%走Bulk管道
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
USB驱动程序编写linux下usb驱动编写(内核2.4)——2.6与此接口有区别2006-09-15 14:57我们知道了在Linux 下如何去使用一些最常见的USB设备。
但对于做系统设计的程序员来说,这是远远不够的,我们还需要具有驱动程序的阅读、修改和开发能力。
在此下篇中,就是要通过简单的USB驱动的例子,随您一起进入USB驱动开发的世界。
USB骨架程序(usb-skeleton),是USB驱动程序的基础,通过对它源码的学习和理解,可以使我们迅速地了解USB驱动架构,迅速地开发我们自己的USB硬件的驱动。
USB驱动开发在掌握了USB设备的配置后,对于程序员,我们就可以尝试进行一些简单的USB驱动的修改和开发了。
这一段落,我们会讲解一个最基础USB框架的基础上,做两个小的USB驱动的例子。
USB骨架在Linux kernel源码目录中driver/usb/usb-skeleton.c为我们提供了一个最基础的USB驱动程序。
我们称为USB骨架。
通过它我们仅需要修改极少的部分,就可以完成一个USB设备的驱动。
我们的USB驱动开发也是从她开始的。
那些linux下不支持的USB设备几乎都是生产厂商特定的产品。
如果生产厂商在他们的产品中使用自己定义的协议,他们就需要为此设备创建特定的驱动程序。
当然我们知道,有些生产厂商公开他们的USB协议,并帮助Linux驱动程序的开发,然而有些生产厂商却根本不公开他们的USB协议。
因为每一个不同的协议都会产生一个新的驱动程序,所以就有了这个通用的USB驱动骨架程序,它是以pci 骨架为模板的。
如果你准备写一个linux驱动程序,首先要熟悉USB协议规范。
USB主页上有它的帮助。
一些比较典型的驱动可以在上面发现,同时还介绍了USB urbs的概念,而这个是usb驱动程序中最基本的。
Linux USB 驱动程序需要做的第一件事情就是在Linux USB 子系统里注册,并提供一些相关信息,例如这个驱动程序支持那种设备,当被支持的设备从系统插入或拔出时,会有哪些动作。
所有这些信息都传送到USB 子系统中,在usb骨架驱动程序中是这样来表示的:static struct usb_driver skel_driver = {name: skeleton,probe: skel_probe,disconnect: skel_disconnect,fops: &skel_fops,minor: USB_SKEL_MINOR_BASE,id_table: skel_table,};变量name是一个字符串,它对驱动程序进行描述。
probe 和disconnect 是函数指针,当设备与在id_table 中变量信息匹配时,此函数被调用。
fops和minor变量是可选的。
大多usb驱动程序钩住另外一个驱动系统,例如SCSI,网络或者tty子系统。
这些驱动程序在其他驱动系统中注册,同时任何用户空间的交互操作通过那些接口提供,比如我们把SCSI设备驱动作为我们USB驱动所钩住的另外一个驱动系统,那么我们此USB设备的read、write等操作,就相应按SCSI设备的read、write函数进行访问。
但是对于扫描仪等驱动程序来说,并没有一个匹配的驱动系统可以使用,那我们就要自己处理与用户空间的read、write等交互函数。
Usb子系统提供一种方法去注册一个次设备号和函数指针,这样就可以与用户空间实现方便地交互。
USB骨架程序的关键几点如下:USB驱动的注册和注销Usb驱动程序在注册时会发送一个命令给usb_register,通常在驱动程序的初始化函数里。
当要从系统卸载驱动程序时,需要注销usb子系统。
即需要usb_unregister 函数处理:static void __exit usb_skel_exit(void){/* deregister this driver with the USB subsystem */usb_deregister(&skel_driver);}module_exit(usb_skel_exit);当usb设备插入时,为了使linux-hotplug(Linux中PCI、USB等设备热插拔支持)系统自动装载驱动程序,你需要创建一个MODULE_DEVICE_TABLE。
代码如下(这个模块仅支持某一特定设备):/* table of devices that work with this driver */static struct usb_device_id skel_table [] = {{ USB_DEVICE(USB_SKEL_VENDOR_ID,USB_SKEL_PRODUCT_ID) },{ } /* Terminating entry */};MODULE_DEVICE_TABLE (usb, skel_table);USB_DEVICE宏利用厂商ID和产品ID为我们提供了一个设备的唯一标识。
当系统插入一个ID 匹配的USB设备到USB总线时,驱动会在USB core中注册。
驱动程序中probe 函数也就会被调用。
usb_device 结构指针、接口号和接口ID都会被传递到函数中。
static void * skel_probe(struct usb_device *dev,unsigned int ifnum, const struct usb_device_id *id)驱动程序需要确认插入的设备是否可以被接受,如果不接受,或者在初始化的过程中发生任何错误,probe函数返回一个NULL值。
否则返回一个含有设备驱动程序状态的指针。
通过这个指针,就可以访问所有结构中的回调函数。
在骨架驱动程序里,最后一点是我们要注册devfs。
我们创建一个缓冲用来保存那些被发送给usb 设备的数据和那些从设备上接受的数据,同时USB urb 被初始化,并且我们在devfs子系统中注册设备,允许devfs用户访问我们的设备。
注册过程如下:/* initialize the devfs node for this deviceand register it */sprintf(name, skel%d, skel->minor);skel->devfs = devfs_register(usb_devfs_handle, name,DEVFS_FL_DEFAULT, USB_MAJOR,USB_SKEL_MINOR_BASE + skel->minor,S_IFCHR | S_IRUSR | S_IWUSR |S_IRGRP | S_IWGRP | S_IROTH,&skel_fops, NULL);如果devfs_register函数失败,不用担心,devfs子系统会将此情况报告给用户。
当然最后,如果设备从usb总线拔掉,设备指针会调用disconnect 函数。
驱动程序就需要清除那些被分配了的所有私有数据、关闭urbs,并且从devfs上注销调自己。
/* remove our devfs node */devfs_unregister(skel->devfs);现在,skeleton驱动就已经和设备绑定上了,任何用户态程序要操作此设备都可以通过结构所定义的函数进行了。
首先,我们要open此设备。
在open函数中MODULE_INC_USE_COUNT 宏是一个关键,它的作用是起到一个计数的作用,有一个用户态程序打开一个设备,计数器就加一,例如,我们以模块方式加入一个驱动,若计数器不为零,就说明仍然有用户程序在使用此驱动,这时候,你就不能通过rmmod命令卸载驱动模块了。
/* increment our usage count for the module */MOD_INC_USE_COUNT;++skel->open_count;/* save our object in the file's private structure */file->private_data = skel;当open完设备后,read、write函数就可以收、发数据了。
skel的write、和read函数他们是完成驱动对读写等操作的响应。
在skel_write中,一个FILL_BULK_URB函数,就完成了urb 系统callbak和我们自己的skel_write_bulk_callback之间的联系。
注意skel_write_bulk_callback是中断方式,所以要注意时间不能太久,本程序中它就只是报告一些urb的状态等。
read 函数与write 函数稍有不同在于:程序并没有用urb 将数据从设备传送到驱动程序,而是我们用usb_bulk_msg 函数代替,这个函数能够不需要创建urbs 和操作urb函数的情况下,来发送数据给设备,或者从设备来接收数据。
我们调用usb_bulk_msg函数并传提一个存储空间,用来缓冲和放置驱动收到的数据,若没有收到数据,就失败并返回一个错误信息。
usb_bulk_msg函数当对usb设备进行一次读或者写时,usb_bulk_msg 函数是非常有用的; 然而, 当你需要连续地对设备进行读/写时,建议你建立一个自己的urbs,同时将urbs 提交给usb子系统。
skel_disconnect函数当我们释放设备文件句柄时,这个函数会被调用。
MOD_DEC_USE_COUNT宏会被用到(和MOD_INC_USE_COUNT刚好对应,它减少一个计数器),首先确认当前是否有其它的程序正在访问这个设备,如果是最后一个用户在使用,我们可以关闭任何正在发生的写,操作如下:/* decrement our usage count for the device */--skel->open_count;if (skel->open_count <= 0) {/* shutdown any bulk writes that might begoing on */usb_unlink_urb (skel->write_urb);skel->open_count = 0;}/* decrement our usage count for the module */MOD_DEC_USE_COUNT;最困难的是,usb 设备可以在任何时间点从系统中取走,即使程序目前正在访问它。
usb驱动程序必须要能够很好地处理解决此问题,它需要能够切断任何当前的读写,同时通知用户空间程序:usb设备已经被取走。
如果程序有一个打开的设备句柄,在当前结构里,我们只要把它赋值为空,就像它已经消失了。