利用windriver 开发了个usb的驱动,写个开发心得

利用windriver 开发了个usb的驱动,写个开发心得
利用windriver 开发了个usb的驱动,写个开发心得

利用windriver 开发了个usb的驱动,写个开发心得

项目组需要利用2440采集数字电视的采样数据,所以让我开发一个usb的数据采集系统,就两个要求

1 速度要达到500kbyte/s以上

2 稳定

由于之前没有做过windows驱动的经验,所以花了3,4天时间读了读ddk的文档,期间还上chinapub

找个本书,读了免费的第1章,按照他配置了vc的编译环境,呵呵。

然后就吧ddk下面的bulkusb源代码进行了修改,写好usb device的驱动,有些了个应用程序,测试一下,采集数据是ok了,但是发现有时候蓝屏,特别是采集100m左右,就会出现蓝品!这下没办法了,由于我本身就对windows内核编程不熟悉,有调试了大概3,4天确认问题可能处在电源管理方面,联系到自己对这方面不是很熟悉,而且时间紧迫,没办法转向windriver开发

!我安装的是9.21版本(请到迅雷下载)。

1. 驱动的开发:

a 这步开发比较简单,首先确认你的device固件正确能枚举成功,然后将device连接到pc us

b ho st 端。

b 按照向导指引刷出你的设备进行配置,然后点击编译按钮生成代码。这部分内容请参考安装文档的快速开发向导!

2.应用程序开发:

最主要的几个函数是,opendevice 和readwrite 函数:其实大家只要摘录向导生成代码的内容即可,这里贴一个我的

static WDU_DRIVER_HANDLE hDriver = 0;

static DRIVER_CONTEXT DrvCtx ;

static BOOL DLLCALLCONV DeviceAttach(WDU_DEVICE_HANDLE hDevice,

WDU_DEVICE *pDeviceInfo, PVOID pUserData)

{

DRIVER_CONTEXT *pDrvCtx = (DRIVER_CONTEXT *)pUserData;

DEVICE_CONTEXT *pDevCtx, **ppDevCtx;

DWORD dwInterfaceNum = pDeviceInfo->pActiveInterface[0]->pActiveAltSetting->Descriptor.bInterf aceNumber;

DWORD dwAlternateSetting = pDeviceInfo->pActiveInterface[0]->pActiveAltSetting->Descriptor.bAlt ernateSetting;

TRACE("\nDeviceAttach: received and accepted attach for vendor id 0x%x, "

"product id 0x%x, interface %ld, device handle 0x%p\n",

pDeviceInfo->Descriptor.idVendor, pDeviceInfo->Descriptor.idProduct,

dwInterfaceNum, hDevice);

/* Add our device to the device list */

pDevCtx = (DEVICE_CONTEXT *)malloc(sizeof(DEVICE_CONTEXT));

if (!pDevCtx)

{

ERR("DeviceAttach: failed allocating memory\n");

return FALSE;

}

BZERO(*pDevCtx);

pDevCtx->hDevice = hDevice;

pDevCtx->dwInterfaceNum = dwInterfaceNum;

pDevCtx->dwVendorId = pDeviceInfo->Descriptor.idVendor;

pDevCtx->dwProductId = pDeviceInfo->Descriptor.idProduct;

pDevCtx->dwAlternateSetting = dwAlternateSetting;

OsMutexLock(pDrvCtx->hMutex);

for (ppDevCtx = &pDrvCtx->deviceContextList; *ppDevCtx;

ppDevCtx = &((*ppDevCtx)->pNext));

*ppDevCtx = pDevCtx;

pDrvCtx->dwDeviceCount++;

OsMutexUnlock(pDrvCtx->hMutex);

OsEventSignal(pDrvCtx->hEvent);

/* Accept control over this device */

return TRUE;

}

static VOID DLLCALLCONV DeviceDetach(WDU_DEVICE_HANDLE hDevice, PVOID pUserData) {

DRIVER_CONTEXT *pDrvCtx = (DRIVER_CONTEXT *)pUserData;

DEVICE_CONTEXT **pCur;

DEVICE_CONTEXT *pTmpDev;

BOOL bDetachActiveDev = FALSE;

TRACE("\nDeviceDetach: received detach for device handle 0x%p\n", hDevice);

OsMutexLock(pDrvCtx->hMutex);

for (pCur = &pDrvCtx->deviceContextList;

*pCur && (*pCur)->hDevice != hDevice;

pCur = &((*pCur)->pNext));

if (*pCur == pDrvCtx->pActiveDev)

{

pDrvCtx->pActiveDev = NULL;

}

pTmpDev = *pCur;

*pCur = pTmpDev->pNext;

free(pTmpDev);

pDrvCtx->dwDeviceCount--;

OsMutexUnlock(pDrvCtx->hMutex);

if (bDetachActiveDev)

{

/* When hDeviceUnusedEvent is not signaled, hDevice is possibly in use,

* and therefore the detach callback needs to wait on it until it is

* certain that it cannot be used.

* When it is signaled - hDevice is no longer used. */

OsEventWait(pDrvCtx->hDeviceUnusedEvent, INFINITE);

}

}

DWORD DriverInit(WDU_MATCH_TABLE *pMatchTables, DWORD dwNumMatchTables, const PCHAR sDriverName, const PCHAR sLicense, DRIVER_CONTEXT *pDrvCtx) {

DWORD dwError;

WDU_EVENT_TABLE eventTable;

/* Set Driver Name */

if (!WD_DriverName(sDriverName))

ERR("Error: Could not set driver name to %s, exiting\n",

sDriverName);

return WD_SYSTEM_INTERNAL_ERROR;

}

dwError = OsEventCreate(&pDrvCtx->hEvent);

if (dwError)

{

ERR("DriverInit: OsEventCreate() failed on event 0x%p: error 0x%lx " "(\"%s\")\n", pDrvCtx->hEvent, dwError, Stat2Str(dwError));

return dwError;

}

dwError = OsMutexCreate(&pDrvCtx->hMutex);

if (dwError)

{

ERR("DriverInit: OsMutexCreate() failed on mutex 0x%p: error 0x%lx " "(\"%s\")\n", pDrvCtx->hMutex, dwError, Stat2Str(dwError));

return dwError;

}

dwError = OsEventCreate(&pDrvCtx->hDeviceUnusedEvent);

if (dwError)

{

ERR("DriverInit: OsEventCreate() failed on event 0x%p: error 0x%lx " "(\"%s\")\n", pDrvCtx->hDeviceUnusedEvent, dwError,

Stat2Str(dwError));

return dwError;

OsEventSignal(pDrvCtx->hDeviceUnusedEvent);

BZERO(eventTable);

eventTable.pfDeviceAttach = DeviceAttach;

eventTable.pfDeviceDetach = DeviceDetach;

eventTable.pUserData = pDrvCtx;

dwError = WDU_Init(&hDriver, pMatchTables, dwNumMatchTables, &eventTabl e, sLicense, WD_ACKNOWLEDGE);

if (dwError)

{

ERR("DriverInit: failed to initialize USB driver: error 0x%lx "

"(\"%s\")\n", dwError, Stat2Str(dwError));

return dwError;

}

return WD_STATUS_SUCCESS;

}

VOID DriverUninit(DRIVER_CONTEXT *pDrvCtx)

{

DEVICE_CONTEXT *pCur, *pTmpDev;

if (pDrvCtx->hEvent)

OsEventClose(pDrvCtx->hEvent);

if (pDrvCtx->hMutex)

OsMutexClose(pDrvCtx->hMutex);

if (pDrvCtx->hDeviceUnusedEvent)

if (hDriver)

WDU_Uninit(hDriver);

/* Release any remaining devices */ pCur = pDrvCtx->deviceContextList; while (pCur)

{

pTmpDev = pCur;

pCur = pCur->pNext;

free(pTmpDev);

}

}

DWORD OpenUsbDevice( void)

{

DWORD dwError;

WORD wVendorId = 0;

WORD wProductId = 0;

WDU_MATCH_TABLE matchTable; BZERO(DrvCtx);

wVendorId = USE_DEFAULT;

wProductId = USE_DEFAULT;

/* use defaults */

if (wVendorId == USE_DEFAULT)

if (wProductId == USE_DEFAULT)

wProductId = DEFAULT_PRODUCT_ID;

BZERO(matchTable);

matchTable.wVendorId = wVendorId;

matchTable.wProductId = wProductId;

dwError = DriverInit(&matchTable, 1, DEFAULT_DRIVER_NAME,

DEFAULT_LICENSE_STRING, &DrvCtx);

if (dwError)

{

goto Exit;

}

/* Wait for the device to be attached */

dwError = OsEventWait(DrvCtx.hEvent, ATTACH_EVENT_TIMEOUT); if (dwError)

{

if (dwError==WD_TIME_OUT_EXPIRED)

{

ERR("Timeout expired for connection with the device.\n"

"Check that the device is connected and try again.\n");

}

else

{

ERR("main: OsEventWait() failed on event 0x%p: error 0x%lx " "(\"%s\")\n", DrvCtx.hEvent, dwError, Stat2Str(dwError));

}

goto Exit;

OsMutexLock(DrvCtx.hMutex);

if (!DrvCtx.dwDeviceCount)

{

OsMutexUnlock(DrvCtx.hMutex);

return 1;

}

OsMutexUnlock(DrvCtx.hMutex);

if (!DrvCtx.pActiveDev)

DrvCtx.pActiveDev = DrvCtx.deviceContextList; OsEventReset(DrvCtx.hDeviceUnusedEvent);

return 0 ;

Exit:

DriverUninit(&DrvCtx);

return dwError;

}

void CloseUsbDevice( void)

{

DriverUninit(&DrvCtx);

}

DWORD UsbRead(char *pBuffer , DWORD dwBufferSize , PDWORD pdwBytesTransferred)

{

DWORD dwError ;

WDU_DEVICE_HANDLE hDevice;

OsMutexLock(DrvCtx.hMutex);

hDevice = DrvCtx.pActiveDev->hDevice;

OsMutexUnlock(DrvCtx.hMutex);

dwError = WDU_TransferBulk(hDevice, 0x81,TRUE, 0, pBuffer, dwBufferSize,

pdwBytesTransferred, TRANSFER_TIMEOUT);

return dwError ;

}

3.驱动程序的发布:

这个也比较简单,请参考自带文档usb manual 的11章节,其实就是用到了他的一个wdreg工具,我写了个批处理文件,想安装的直接点批处理即可!

windriver开发驱动是比较方便,至于稳定性,现在正在测试,看来比较稳定!速度方面500kB是没问题!

不过速度方面pc驱动固然有影响,device的firmware影响也是很大的,特别是双缓冲的ep,处理不当速度很难上去!

usb驱动程序教程

编写Windows https://www.360docs.net/doc/158750341.html,的usb驱动程序教程 Windows https://www.360docs.net/doc/158750341.html, 是微软推出的功能强大的嵌入式操作系统,国内采用此操作系统的厂商已经很多了,本文就以windows https://www.360docs.net/doc/158750341.html,为例,简单介绍一下如何开发windows https://www.360docs.net/doc/158750341.html, 下的USB驱动程序。 Windows https://www.360docs.net/doc/158750341.html, 的USB系统软件分为两层: USB Client设备驱动程序和底层的Windows CE实现的函数层。USB设备驱动程序主要负责利用系统提供的底层接口配置设备,和设备进行通讯。底层的函数提本身又由两部分组成,通用串行总线驱动程序(USBD)模块和较低的主控制器驱动程序(HCD)模块。HCD负责最最底层的处理,USBD模块实现较高的USBD函数接口。USB设备驱动主要利用 USBD接口函数和他们的外围设备打交道。 USB设备驱动程序主要和USBD打交道,所以我们必须详细的了解USBD提供的函数。 主要的传输函数有: abourttransfer issuecontroltransfer closetransfer issuein te rruptransfer getisochresult issueisochtransfer gettransferstatus istransfercomplete issuebulktransfer issuevendortransfer 主要的用于打开和关闭usbd和usb设备之间的通信通道的函数有: abortpipetransfers closepipe isdefaultpipehalted ispipehalted openpipe resetdefaultpipe resetpipe 相应的打包函数接口有: getframelength getframenumber releaseframelengthcontrol setframelength takeframelengthcontrol 取得设置设备配置函数: clearfeature setdescriptor getdescriptor setfeature

Linux设备驱动程序举例

Linux设备驱动程序设计实例2007-03-03 23:09 Linux系统中,设备驱动程序是操作系统内核的重要组成部分,在与硬件设备之间 建立了标准的抽象接口。通过这个接口,用户可以像处理普通文件一样,对硬件设 备进行打开(open)、关闭(close)、读写(read/write)等操作。通过分析和设计设 备驱动程序,可以深入理解Linux系统和进行系统开发。本文通过一个简单的例子 来说明设备驱动程序的设计。 1、程序清单 //MyDev.c 2000年2月7日编写 #ifndef __KERNEL__ #define __KERNEL__//按内核模块编译 #endif #ifndef MODULE #define MODULE//设备驱动程序模块编译 #endif #define DEVICE_NAME "MyDev" #define OPENSPK 1 #define CLOSESPK 2 //必要的头文件 #include //同kernel.h,最基本的内核模块头文件 #include //同module.h,最基本的内核模块头文件 #include //这里包含了进行正确性检查的宏 #include //文件系统所必需的头文件 #include //这里包含了内核空间与用户空间进行数据交换时的函数宏 #include //I/O访问 int my_major=0; //主设备号 static int Device_Open=0; static char Message[]="This is from device driver"; char *Message_Ptr; int my_open(struct inode *inode, struct file *file) {//每当应用程序用open打开设备时,此函数被调用 printk ("\ndevice_open(%p,%p)\n", inode, file); if (Device_Open) return -EBUSY;//同时只能由一个应用程序打开 Device_Open++; MOD_INC_USE_COUNT;//设备打开期间禁止卸载 return 0; } static void my_release(struct inode *inode, struct file *file)

最新开发usb驱动程序的方法连载一

最新开发usb驱动程序的方法连载一 开发usb驱动程序的方法(连载二) NT还有更多其他的对象,例如中断对象、Controller对象、定时器对象等等,但在我们开发的驱动程序中并没有用到,因此在这里不做介绍。 I/O缓冲策略 很明显的,驱动程序和客户应用程序经常需要进行数据交换,但我们知道驱动程序和客户应用程序可能不在同一个地址空间,因此操作系统必须解决两者之间的数据交换。这就就设计到设备的I/O缓冲策略。 读写请求的I/O缓冲策略 前面说到通过设置Device对象的Flag可以选择控制处理读写请求的I/O缓冲策略。下面对这些缓冲策略分别做一介绍。 1、缓冲I/O(DO_BUFFERED_IO) 在读写请求的一开始,I/O管理器检查用户缓冲区的可访问性,然后分配与调用者的缓冲区一样大的非分页池,并把它的地址放在IRP的AssociatedIrp.SystemBuffer域中。驱动程序就利用这个域来进行实际数据的传输。 对于IRP_MJ_READ读请求,I/O管理器还把IRP的UserBuffer域设置成调用者缓冲区的用户空间地址。当请求完成时,I/O管理器利用这个地址将数据从驱动程序的系统空间拷贝回调用者的缓冲区。对于IRP_MJ_WRITE写请求,UserBuffer被设置为NULL,并把用户缓冲区的数据拷贝到系统缓冲区中。 2、直接I/O(DO_DIRECT_IO) I/O管理器首先检查用户缓冲区的可访问性,并在物理内存中锁定它。然后它为该缓冲区创建一个内存描述表(MDL),并把MDL的地址存放在IRP的MdlAddress域中。AssociatedIrp.SystemBuffer和 UserBuffer 都被设置为NULL。驱动程序可以调用函数 MmGetSystemAddressForMdl得到用户缓冲区的系统空间地址,从而进行数据操作。这个函数将调用者的缓冲区映射到非份页的地址空间。驱动程序完成I/O请求后,系统自动从系统空间解除缓冲区的映射。 3、这两种方法都不是 这种情况比较少用,因为这需要驱动程序自己来处理缓冲问题。 I/O管理器仅把调用者缓冲区的用户空间地址放到IRP的UserBuffer 域中。我们并不推荐这种方式。 IOCTL缓冲区的缓冲策略 IOCTL请求涉及来自调用者的输入缓冲区和返回到调用者的输出缓冲区。为了理解IOCTL请求,我们先来看看WIN32 API DeviceIoControl函数的原型。 BOOL DeviceIoControl ( HANDLE hDevice, // 设备句柄 DWORD dwIoControlCode, // IOCTL请求操作代码 LPVOID lpInBuffer, // 输入缓冲区地址 DWORD nInBufferSize, // 输入缓冲区大小 LPVOID lpOutBuffer, // 输出缓冲区地址 DWORD nOutBufferSize, // 输出缓冲区大小 LPDWORD lpBytesReturned, // 存放返回字节数的指针

USB驱动程序的编写采用WDM驱动程序

U S B驱动程序的编写采用W D M驱动程序 Document serial number【UU89WT-UU98YT-UU8CB-UUUT-UUT108】

USB驱动程序的编写采用WDM 驱动程序。WDM 驱动程序是一些例程的集合,它们被动地存在,等待主机系 统软件(PnP 管理器、I/O 管理器、电源管理器等)来调用或激活它们。具体驱动程序不同,其所包含 的例程也不同。一个WDM 驱动程序的基本组成包括以下5个例程:(1)驱动程序入口例程:处理驱动程序的初始化。 (2)即插即用例程:处理PnP 设备的添加、删除和停止。 (3)分发例程:处理用户应用程序发出的各种 I/O 请求。 (4)电源管理例程:处理电源管理请求。 (5)卸载例程:处理驱动程序的卸载。 包含文件: , , , , , makefile,sources) 在文件中,包含了上述五个例程: 中定义了各种数据结构还有各种IOCTL控制码,用于不同数据的读写。

中实现了各种驱动例程。包含了上述五个所说例程外还包含了其他例程,课程从下面的驱动 程序入口例程得出一些信息。 驱动程序入口例程: NTSTATUS DriverEntry( 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; ources. If you want to add a new source # file to this

《Linux设备驱动开发详解:基于最新的Linux 4.0内核》19. Linux电源管理系统架构和驱动

以下电子书来源于宋宝华《Linux设备驱动开发详解:基于最新的Linux 4.0内核》第19章《Linux电源管理系统架构和驱动》 本章导读 Linux在消费电子领域的应用已经铺天盖地,而对于消费电子产品而言,省电是一个重要的议题。 本章将介绍Linux设备树(Device Tree)的起源、结构和因为设备树而引起的驱动和BSP 变更。 19.1节阐述了Linux电源管理的总体架构。 19.2~19.8节分别论述了CPUFreq、CPUIdle、CPU热插拔以及底层的基础设施Regulator、OPP以及电源管理的调试工具PowerTop。 19.9节讲解了系统Suspend to RAM的过程以及设备驱动如何提供对Suspend to RAM的支持。 19.10节讲解了设备驱动的Runtime suspend。 本章是相对《Linux设备驱动开发详解(第2版)》全新的一章内容,也是Linux设备驱动工程师必备的知识体系。

第十九章Linux电源管理系统架构和驱动 1.Linux电源管理全局架构 Linux电源管理非常复杂,牵扯到系统级的待机、频率电压变换、系统空闲时的处理以及每个设备驱动对于系统待机的支持和每个设备的运行时电源管理,可以说和系统中的每个设备驱动都息息相关。 对于消费电子产品来说,电源管理相当重要。因此,这部分工作往往在开发周期中占据相当大的比重,图19.1呈现了Linux内核电源管理的整体架构。大体可以归纳为如下几类: 1.CPU在运行时根据系统负载进行动态电压和频率变换的CPUFreq 2.CPU在系统空闲时根据空闲的情况进行低功耗模式的CPUIdle 3.多核系统下CPU的热插拔支持 4.系统和设备对于延迟的特别需求而提出申请的PM QoS,它会作用于CPUIdle的具体 策略 5.设备驱动针对系统Suspend to RAM/Disk的一系列入口函数 6.SoC进入suspend状态、SDRAM自刷新的入口 7.设备的runtime(运行时)动态电源管理,根据使用情况动态开关设备 8.底层的时钟、稳压器、频率/电压表(OPP模块完成)支撑,各驱动子系统都可能用 到 图19.1 Linux电源管理系统架构 2.CPUFreq驱动 CPUFreq子系统位于drivers/cpufreq目录,负责进行运行过程中CPU频率和电压的动态

USB驱动开发

第17章USB设备驱动 USB设备驱动和PCI设备驱动是PC中最主要的两种设备驱动程序。与PCI协议相比,USB协议更复杂,涉及面较多。本章将介绍USB设备驱动开发。首先介绍USB协议,使读者对USB协议有个整体认识。然后介绍USB设备在WDM中的开发框架。由于操作系统的USB总线驱动程序提供了丰富的功能调用,因此开发USB驱动开发变得相对简单,只需要调用USB总线驱动接口。 17.1 USB总线协议 USB总线协议比PCI协议复杂的多,涉及USB物理层协议,又涉及USB传输层协议等。对于USB驱动程序开发者来说,不需要对USB协议的每个细节都很清楚。本节概要地介绍USB总线协议,并对驱动开发者需要了解的地方进行详细介绍。 17.1.1 USB设备简介 USB即通用串行总线(Universal Serial Bus),是一种支持即插即用的新型串行接口。也有人称之为“菊链(daisy-chaining)”,是因为在一条“线缆”上有链接127 个设备的能力。USB要比标准串行口快得多,其数据传输率可达每秒4Mb~12Mb(而老式的串行口最多是每秒115Kb)。除了具有较高的传输率外,它还能给外围设备提供支持。 需要注意的是,这不是一种新的总线标准,而是计算机系统连接外围设备(如键盘、鼠标、打印机等)的输入/输出接口标准。到现在为止,计算机系统连接外围设备的接口还没有统一的标准,例如,键盘的插口是圆的、连接打印机要用9针或25针的并行接口、鼠标则要用9针或25针的串行接口。USB能把这些不同的接口统一起来,仅用一个4针插头作为标准插头,如图17-1所示。通过这个标准插头,采用菊花链形式可以把所有的外设连接起来,并且不会损失带宽。USB正在取代当前PC上的串口和并口。

如何写驱动程序

我这里重点的介绍如何写驱动程序,对于一些应用程序我就不做介绍了,因为我对于那些高层的东西写得很少。倘若再讲,有班门弄斧之嫌,呵呵! 作为WIN98和WIN2K推荐的一项新技术来说,USB的驱动程序和以往的直接跟硬件打交道的WIN95的VXD的方式的驱动程序不同,它应该是WDM类型的。 USB的WDM接口框图如下(这个图可以说是USB软件总体框图) 对于HID的设备,就可以采用上图左上边的结构,其它类的话采用右上的结构,其实右边的结构可以又细分成两层,一层是Class Driver,一层是Miniport Driver。而倒数第三行的UHCD和OpenHCI分别是由INTEL和COMPAQ两位老大定的一个和硬件有关的底层驱动程序标准,各位可以根据所需要的选择。 对于USB的驱动程序,大家还得去了解WDM驱动程序的写法,或者早些时候的NT驱动程序,其实WDM驱动程序可以看做是NT驱动程序的一个update,只是增加了一些新的特性。 “写驱动程序是一个很漫长和繁琐的工作,在此之前,你最好要熟悉硬件,熟悉C/C++,还要用过DDK,会用一些调试程序,如SOFTICE和WINDBG之类。如果一切就绪,你就可以开始写驱动程序,工作的进程有时侯会取决于你的运气”。(这是一位留美的朋友对我说的,我写出来和大家共享) 下面是我从一个朋友那里得到的一篇文章的摘要: NT驱动程序的分层结构 驱动程序是指管理某个外围设备的一段程序代码。NT采用更灵活的分层驱动方法,允许杂应用程序和硬件之间存在几个驱动程序层次。分层机制允许NT更加广泛地定义驱动程序,包括文件系统、逻辑卷管理器和各种网络组件,各种物理设备驱动程序等等。 1、设备驱动程序 这些是管理实际数据传输和控制特定类型的物理设备的操作的驱动程序,包括开始和完成I/O操作,处理中断和执行特定的设备要求的任何差错处理。

从零开始搭建Linux驱动开发环境

参考: 韦东山视频第10课第一节内核启动流程分析之编译体验 第11课第三节构建根文件系统之busybox 第11课第四节构建根文件系统之构建根文件系统韦东山书籍《嵌入式linux应用开发完全手册》 其他《linux设备驱动程序》第三版 平台: JZ2440、mini2440或TQ2440 交叉网线和miniUSB PC机(windows系统和Vmware下的ubuntu12.04) 一、交叉编译环境的选型 具体的安装交叉编译工具,网上很多资料都有,我的那篇《arm-linux- gcc交叉环境相关知识》也有介绍,这里我只是想提示大家:构建跟文件系统中所用到的lib库一定要是本系统Ubuntu中的交叉编译环境arm-linux- gcc中的。即如果电脑ubuntu中的交叉编译环境为arm-linux-

二、主机、开发板和虚拟机要三者互通 w IP v2.0》一文中有详细的操作步骤,不再赘述。 linux 2.6.22.6_jz2440.patch组合而来,具体操作: 1. 解压缩内核和其补丁包 tar xjvf linux-2.6.22.6.tar.bz2 # 解压内核 tar xjvf linux-2.6.22.6_jz2440.tar.bz2 # 解压补丁

cd linux_2.6.22.6 patch –p1 < ../linux-2.6.22.6_jz2440.patch 3. 配置 在内核目录下执行make 2410_defconfig生成配置菜单,至于怎么配置,《嵌入式linux应用开发完全手册》有详细介绍。 4. 生成uImage make uImage 四、移植busybox 在我们的根文件系统中的/bin和/sbin目录下有各种命令的应用程序,而这些程序在嵌入式系统中都是通过busybox来构建的,每一个命令实际上都是一个指向bu sybox的链接,busybox通过传入的参数来决定进行何种命令操作。 1)配置busybox 解压busybox-1.7.0,然后进入该目录,使用make menuconfig进行配置。这里我们这配置两项 一是在编译选项选择动态库编译,当然你也可以选择静态,不过那样构建的根文件系统会比动态编译的的大。 ->Busybox Settings ->Build Options

(完整版)AT89C51单片机USB接口驱动和应用程序的开发毕业论文

北方民族大学 学士学位论文论文题目:AT89C51单片机USB接口驱动和应用程序的开发 院(部)名称:电信学院 学生姓名:杨闯 指导教师姓名:周春艳 论文提交时间: 2010年5月24日 论文答辩时间:2010年5月29日 学位授予时间:

北方民族大学教务摘要 通用串行总线USB是一种新兴的并逐渐取代其他接口标准的数据通信标准。USB,由于速度快,使用方便灵活,易于扩展,支持即插即用,成本低廉等一系列优点,得到了广泛的应用。 本论文以基于USB总线的数据采集系统的研制过程为主要内容,阐述了利用CH372与ATMEL的AT89C51等组成的一套数据采集系统的设计方案、开发方法和开发过程,并给出了具体实现方案。 论文首先简要介绍了USB总线的相关内容,然后介绍了数据采集系统的设计。数据采集系统的设计包括硬件设计、固件程序开发、驱动程序开发和应用程序开发四部分。在硬件设计部分,首先介绍了设计中所用的CH372的性能和特点,然后给出了具体硬件设计方案,并对设计中应该注意的问题进行了说明。驱动和应用程序主要完成USB设备的读写和即插即用功能,并提供一个友好的人机界面,对数据采集系统进行控制并显示采集后的数据。 本论文已完成了基于USB总线的数据采集系统的设计,用其实现了基本的数据采集功能。使用USB总线传输数据,为数据采集系统与计算机之间的通讯开辟了新的道路。 关键词:USB、驱动程序、应用程序、AT89C51、CH372

Abstract Universal serial bus USB is one kind of emerging and replace other interface standards of data communication standards. USB, due to fast, convenient and flexible easy to expand, to support plug and play, low cost advantages, such as widely application. The paper is mainly concerned with design process of data acquisition system that is based on USB bus. The design scheme, developing method and developing process of a suit of data acquisition system used with CH372 and ATMEL’s AT89C51 are expatiate. In addition, the paper also gives the material realization scheme. At fist, the paper introduces the protocol of USB bus in brief, and then discusses the design of data acquisition system, which includes four parts, , firmware design, device driver and application program. In the in detail; the questions which should be paid attention to in design is explained. Drivers and applications of the main equipment and USB plug and play function, and provide a friendly -machine interface, control of

编写USB驱动程序步骤

编写USB驱动程序步骤: 1所有usb驱动都必须创建主要结构体struct usb_driver struct usb_driver ->struct module *owner (有他可正确对该驱动程序引用计数,应为THIS_MODULE) ->const char *name (驱动名字,运行时可在查看 /sys/bus/usb/drivers/) ->const struct usb_device_id *id_table (包含该驱动可支持的所有不同类型的驱动设备,没添探测回调函数不会被调用) ->int (*probe)(struct usb_interface *intf,const struct usb_device_id *id) (usb驱动探测函数,确认后struct usb_interface 应恰当初始化,然后返0,如果出错则返负值) ->void(*disconnect)(struct usb_interface *intf) (当struct usb_interface 被从系统中移除或驱动正从usb核心中卸载时,usb核心将调用此函数)代码实例: static struct usb_driver skel_driver={ .owner = THIS_MODULE, .name = "skeleton", .id_table = skel_table, .probe = skel_probe, .disconnect = skel_disconnect, }; ↓ 2usb_register()注册将struct usb_driver 注册到usb核心,传统是在usb驱动程序模块初始化代码中完成该工作的

最新单片机USB接口驱动和应用程序的开发

单片机U S B接口驱动和应用程序的开发

北方民族大学 学士学位论文 论文题目:AT89C51单片机USB接口驱动和应用程序的开 发 院(部)名称:电信学院 学生姓名:杨闯 专业:测控技术与仪器学号:20060249 指导教师姓名:周春艳 论文提交时间: 2010年5月24日 论文答辩时间:2010年5月29日 学位授予时间: 北方民族大学教务摘要 通用串行总线USB是一种新兴的并逐渐取代其他接口标准的数据通信标准。USB,由于速度快,使用方便灵活,易于扩展,支持即插即用,成本低廉等一系列优点,得到了广泛的应用。

本论文以基于USB总线的数据采集系统的研制过程为主要内容,阐述了利用CH372与ATMEL的AT89C51等组成的一套数据采集系统的设计方案、开发方法和开发过程,并给出了具体实现方案。 论文首先简要介绍了USB总线的相关内容,然后介绍了数据采集系统的设计。数据采集系统的设计包括硬件设计、固件程序开发、驱动程序开发和应用程序开发四部分。在硬件设计部分,首先介绍了设计中所用的CH372的性能和特点,然后给出了具体硬件设计方案,并对设计中应该注意的问题进行了说明。驱动和应用程序主要完成USB设备的读写和即插即用功能,并提供一个友好的人机界面,对数据采集系统进行控制并显示采集后的数据。 本论文已完成了基于USB总线的数据采集系统的设计,用其实现了基本的数据采集功能。使用USB总线传输数据,为数据采集系统与计算机之间的通讯开辟了新的道路。 关键词:USB、驱动程序、应用程序、AT89C51、CH372 Abstract Universal serial bus USB is one kind of emerging and replace other interface standards of data communication standards. USB, due to fast, convenient and flexible easy to expand, to support plug and play, low cost advantages, such as widely

USB驱动开发——USB描述符

USB驱动开发——USB描述符 观察USB设备 1.usbview 图1 通用串行总线控制器 usbview 在C:\WINDDK\2600\src\wdm\usb\usbview\objchk\i386文件夹下,如图2所示的usbview.exe文件。

图2 usbview目录 图3 usbview观察USB外接设备 如图3所示,可以看出端口8(port8),以及图形右边关于插入U盘的描述信息。

2.bus hound 使用指南 bus hound 5.0使用方法如下: 1.请下载安装bus hound 5.0全功能版:https://www.360docs.net/doc/158750341.html,/down/view.asp?id=28 2.安装完毕后请一定要重启,否则软件不能工作; 3.进行USB监控的主要步骤如下: (1)启动软件,将USB设备插入USB口; (2)在DEVICE内选择设备,例如我的设备是一个U盘,则设备为USB DEVICE,选中该设备,可以在下面的PROPERTIES看到设备的总线类型,设备的电源以及各个端点的功能,在该设备下面还有两个分支:USB AUDIO DEVICE 和 "USB人体学输入设备"(这就是本设备占用的两个接口),一样在PROPERTIES里面可以看到他们的类代码为0x01和0x03。 (3)在看完基本信息后,将上述的某个接口,或者全部打勾。 (4)切换到"SETTING"选项卡,将MAX PHASE设置为512,这样你就可以看到完全的DESCRIPTOR 和其他的数据了。 (5)在"PHASE TO CAPTURE"里面的几个和USB相关的选项如下: CDB:命令描述符块; CTL:USB控制传输; DI/D数据输入/输出; LEN:数据长度; INSOC:同步传输; RSET:总线复位; URB:USB请求块; USTS:USB状态。 查看USB数据传输就把它们都打勾就行了; (6)在"Coloumn to display"里面,把里面的全部打勾。注意,这样要把窗体最大化才可以看见全部数据。 (7)在"CAPTURE"选项卡里面可以看捕捉的数据了,在文本框输入文字,再点旁边的箭头,可以查询。按STOP,再按START可以清屏。 (8)举个例子,接上设备,在文本框输入GET DESCRIPTOR(大小写无所谓),点箭头,可以找到你的DESCRIPTOR,但是值得注意的是这个DESCRIPTOR主要是CONFIG,如果是设备描述符会有专门的说明GET DEVICE DESCRIPTOR;这个软件好像不会捕捉STRING DESCRIPTOR。设备返回的信息在DI里面。

USB设备驱动程序的开发与USB协议

第1章绪论 1.1USB简介 USB是由世界著名计算机和通信公司等共同推出的新一代接口标准,全称为Universal Serial Bus(通用串行总线)[1],是一种快速、灵活的总线接口。它是为了解决日益增加的PC外设与有限的主板插槽和端口之间的矛盾而制定的一种串行通信标准。USB应用十分广泛,并具有下述优点: 1、适用于多种外设,使它不需要为不同的外设准备不同的接口和协议; 2、Windows能自动检测到USB设备的热插拔,并自动配置; 3、PC机上的接口线非常紧缺,而USB设备并不需要用户设置端口故无论从用户使用方便性,或从对资源的占用方面看,USB都很优秀; 4、当接入一个USB设备时,全速USB接口可达12Mbit/s。考虑到状态、控制和出错信息,最大理论速度仍可达到9.6Mbit/s,这是其他串行接口协议所不能比拟的,且USB也支持1.5Mbit/s的低速传输。

5、USB接口芯片价格低廉,这也大大促进USB设备的开发与应用。 在USB出现之前,计算机典型接口有并行口、串行口、鼠标口、键盘口、显示器口,及各种卡式接口等,与这些接口对应的有各种不同的电缆,在传输速度方面,这些接口都存在速度偏低的问题。在技术方面,这种设计容易产生I/O冲突,中断不够用,以及对于每一种新的外设都必须设计新的接口卡等缺点。当今的计算机外部设备,都在追求高速度和高通用性。USB接口适应了这种要求,并以其速度快、使用方便、成本低等优点,迅速得到了众多PC厂商和半导体厂商的大力支持,外设向USB过度成为必然趋势。 1.2USB驱动程序的意义 如果PC主机不知道如何与USB外设通信,那么这个USB外设一点用处都没有,人机接口设备(HID)[2]类是Windows完全支持的USB设备类型中的一种,应用程序可以使用操作系统内设置的驱动与HID通信,但与HID 通信不像打开一个端口,设定几个参数,然后就可以读写数据那么简单,在应用程序能与HID交换数据之前,它先要找到设备,获取有关它的报告信息。为做到这些,应用程序必须通过访问通信API函数,使位于上层的应用程序与位于下层的设备驱动程序进行数据交换。应用程序可以使用任何能访问API函数的程序语言,VC++是一种能访问API函数的功能强大的语言,因此,我们应用Visual C++6.0环境下编写与USB设备通信的Windows程序。 1.3VC++软件的介绍 应用基于MFC AppWizard的应用程序。MFC (Microsoft Foundation Class Library)中的各种类结合起来构成了一个应用程序框架,它的目的就是在此基础上来建立Windows下的应用程序,这是一种相对SDK来说更为简单的方法。因为总体上,MFC框架定义了应用程序的轮廓,并提供了用户接口的标准实现方法,要做的就是通过预定义的接口把具体应用程序特有的东西填入这个轮廓。Microsoft Visual C++提供了相应的工具来完成这个工作:

如何实现Linux设备驱动模型

文库资料?2017 Guangzhou ZHIYUAN Electronics Stock Co., Ltd. 如何实现Linux 设备驱动模型 设备驱动模型,对系统的所有设备和驱动进行了抽象,形成了复杂的设备树型结构,采用面向对象的方法,抽象出了device 设备、driver 驱动、bus 总线和class 类等概念,所有已经注册的设备和驱动都挂在总线上,总线来完成设备和驱动之间的匹配。总线、设备、驱动以及类之间的关系错综复杂,在Linux 内核中通过kobject 、kset 和subsys 来进行管理,驱动编写可以忽略这些管理机制的具体实现。 设备驱动模型的内部结构还在不停的发生改变,如device 、driver 、bus 等数据结构在不同版本都有差异,但是基于设备驱动模型编程的结构基本还是统一的。 Linux 设备驱动模型是Linux 驱动编程的高级内容,这一节只对device 、driver 等这些基本概念作介绍,便于阅读和理解内核中的代码。实际上,具体驱动也不会孤立的使用这些概念,这些概念都融合在更高层的驱动子系统中。对于大多数读者可以忽略这一节内容。 1.1.1 设备 在Linux 设备驱动模型中,底层用device 结构来描述所管理的设备。device 结构在文件中定义,如程序清单错误!文档中没有指定样式的文字。.1所示。 程序清单错误!文档中没有指定样式的文字。.1 device 数据结构定义 struct device { struct device *parent; /* 父设备 */ struct device_private *p; /* 设备的私有数据 */ struct kobject kobj; /* 设备的kobject 对象 */ const char *init_name; /*设备的初始名字 */ struct device_type *type; /* 设备类型 */ struct mutex mutex; /*同步驱动的互斥信号量 */ struct bus_type *bus; /*设备所在的总线类型 */ struct device_driver *driver; /*管理该设备的驱动程序 */ void *platform_data; /*平台相关的数据 */ struct dev_pm_info power; /* 电源管理 */ #ifdef CONFIG_NUMA int numa_node; /*设备接近的非一致性存储结构 */ #endif u64 *dma_mask; /* DMA 掩码 */ u64 coherent_dma_mask; /*设备一致性的DMA 掩码 */ struct device_dma_parameters *dma_parms; /* DMA 参数 */ struct list_head dma_pools; /* DMA 缓冲池 */ struct dma_coherent_mem *dma_mem; /* DMA 一致性内存 */ /*体系结构相关的附加项*/ struct dev_archdata archdata; /* 体系结构相关的数据 */ #ifdef CONFIG_OF

开发usb驱动程序的方法

开发驱动程序的方法(连载一) 开始驱动程序设计 下面的文字是从的帮助中节选出来的,它让我们明白在开始设计驱动程序应该注意些什么问题,这些都是具有普遍意义的开发准则。应该支持哪些请求在开始写任何代码之前,应该首先确定我们的驱动程序应该处理哪些例程。 如果你在设计一个设备驱动程序,你应该支持和其他相同类型设备的驱动程序相同的和请求代码。 如果你是在设计一个中间层驱动程序,应该首先确认你下层驱动程序所管理的设备,因为一个高层的驱动程序必须具有低层驱动程序绝大多数例程入口。高层驱动程序在接到请求时,在确定自身当前堆栈单元参数有效的前提下,设置好中下一个低层驱动程序的堆栈单元,然后再调用将请求传递给下层驱动程序处理。 一旦决定好了你的驱动程序应该处理哪些,就可以开始确定驱动程序应该有多少个例程。当然也可以考虑把某些处理的例程合并为同一例程处理。例如在和里,对和处理的例程就是同一函数。对和处理的例程也是同一个函数。 应该有多少个对象? 一个驱动程序必须为它所管理的每个可能成为请求的目标的物理和逻辑设备创建一个命名对象。一些低层的驱动程序还可能要创建一些不确定数目的对象。例如一个硬盘驱动程序必须为每一个物理硬盘创建一个对象,同时还必须为每个物理磁盘上的每个逻辑分区创建一个对象。 一个高层驱动驱动程序必须为它所代表的虚拟设备创建一个对象,这样更高层的驱动程序才能连接它们的对象到这个驱动程序的对象。另外,一个高层驱动程序通常为它低层驱动程序所创建的对象创建一系列的虚拟或逻辑对象。 尽管你可以分阶段来设计你的驱动程序,因此一个处在开发阶段的驱动程序不必一开始就创建出所有它将要处理的所有对象。但从一开始就确定好你最终要创建的所有对象将有助于设计者所要解决的任何同步问题。另外,确定所要创建的对象还有助于你定义对象的的内容和数据结构。 开始驱动程序开发 驱动程序的开发是一个从粗到细逐步求精的过程。的\ 目录下有一个庞大的样板代码,几乎覆盖了所有类型的设备驱动程序、高层驱动程序和过滤器驱动程序。在开始开发你的驱动程序之前,你应该在这个样板库下面寻找是否有和你所要开发的类似类型的例程。例如我们所开发的驱动程序,虽然对描述得不是很详细,我们还是可以在\\目录发现很多和设备有关的驱动程序。下面我们来看开发驱动程序的基本步骤。 最简的驱动程序框架 、写一个例程,在里面调用创建一个对象。 、写一个处理请求的例程的基本框架 (参见 4.4.3描述的一个例程所要完成的最基本工作。当然写了例程后,要在例程为初始化例程入口)。如果驱动程序创建了多于一个对象,则必须为请求写一个例程,该例程通常情况下可以和共用一个例程,参见参见。 、编译连接你的驱动程序。 用下面的方法来测试你的驱动程序。 首先按上面介绍的方法安装好驱动程序。 其次我们还得为逻辑设备名称和目标对象名称之间建立起符号连接,我们在前面已经知道对象名称对用户模式是不可见的,是不能直接通过来访问的,只能访问逻辑设备名称。我们可以通过修改注册表来建立这两种名称之间的符号连接。运行在\\ \ \\ \ 下建立起符号连接(这种符号连接也可以在驱动程序里调用函数来创建)。

通用串行总线USB的驱动程序设计

文章编号:1009-8119(2005)04-0040-03 基于WDM的USB驱动程序设计 赵娟1 仲顺安1 郭磊2 (1.北京理工大学信息科学技术学院,北京 100081 2.石家庄陆军参谋指挥学院教育技术专业,石家庄 050064) 摘要简单介绍了USB的特性。为了介绍USB驱动,重点阐述了WDM驱动程序的原理和Windows系统内核管理机制和应用程序的区别。并给出了利用Driverstudio的C++语言编写的例程。 关键词 USB设备,WDM,操作系统,驱动程序 The Implementation of the USB Driver Based on WDM Zhao Juan Zhong Shun'an Guo Lei Abstrct The attribute of the USB is descripted in the paper. For developing usb driver, the mechanism of kenerl management and the privilege level of applications in window2000 are introduced in the paper. An example of the driver handling USB transfer programmed by using C++ with the help of the driverstudio is given. Keyword USB device,WDM,OS,Driver 1 引言 USB,全称是Universal Serial Bus(通用串行总线),它是由Compaq、Microsoft、Intel、IBM等七家公司共同开发的,旨在解决日益增加的PC外设与有限的主板插槽和端口之间的矛盾而制定的一种串行通信的标准,自1995年在Comdex上亮相以来已广泛地为各PC厂家支持。现在市场上几乎所有的PC机器都配备了USB接口,其优点是: ? 速度快。USB有高速和低速两种方式,主模式为高速模式,速率为12Mbps;另外,为了适应一些不需要很大吞吐量和很高实时性的设备,如鼠标等,USB还提供低速方式,速率为1.5Mbps。 ? 设备安装和配置容易。安装USB设备不必再打开机箱,加减己安装过的设备完全不用关闭计算机。所有USB设备支持热插拔,系统对其进行自动配置,彻底抛弃了过去的跳线和拨码开关设置。 ? 易于扩展。通过使用Hub扩展可连接多达127个外设。标准USB电缆长度为3m(5m 低速)。通过Hub或中继器可以使外设距离达到30m。 ? 能够采用总线供电。USB总线提供最大达5V电压和500mA电流。 ? 使用灵活。USB共有4种传输模式:控制传输(control)、同步传输(synchronization)、中断传输(interrupt)、批量传输(bulk),以适应不同设备的需要。 2 WDM驱动程序的介绍 WDM(Windows Driver Model)是微软提出的一种全新的设备驱动程序模型。它是在Windows NT内核驱动程序模型(Kernel_model Driver Mode)的基础上发展起来的,增加了对即插即用(PnP)、高级电源管理(Power Management)、Windows管理接口(WMI)的支持。更重要的是,WDM是一种通用的驱动模式,提供了包括USB、IEEE1394和HID等在内的一系列驱动程序类。在 Windows 98和 Windows 2000中, WDM驱动程序均可正常使用。 在大多数操作系统中,应用程序和操作系统本身是分开的:操作系统代码运行在特权处理器模式(也称核心态),并有权访问系统数据和硬件;应用程序运行在非特权处理器模式(也称用户态)。当用户态程序调用系统服务时,处理器捕获该调用,然后把调用的线程切换到核

(简易USB驱动)开发指导

实验七(2)设备驱动开发指导 块设备种类多,使用广泛,其驱动程序的开发也比字符设备复杂。通过本实验,大家要开发一个实际块设备(U盘)的驱动程序,将能够更深入地掌握块设备驱动程序的开发方法。Linux下已经有一个通用的U盘驱动程序usb-storage.o,其源程序放在目录drivers\usb\storage下(相对于内核源码根目录)。但这个驱动的实现相当复杂,本实验希望开发一个相对简单些的U盘驱动程序,不求高性能,只求结构明朗、清晰易懂,主要是让大家掌握一个实际块设备的驱动方式,从而加深理解。 事实上,本实验开发的驱动程序应该能够适用于所有基于Bulkonly传输协议的USB大容量存储设备(USB Mass Storage),比如USB移动硬盘和USB外置光驱,USB闪存盘(U 盘)只是其中的一种。由于USB大容量存储设备具有容量大、速度快、连接灵活、即插即用、总线供电等优点,它们得到了广泛使用,掌握这类设备驱动程序的开发技术无疑具有很强的实用性。 实验内容 编写一个U盘驱动程序myudisk,只要求能够驱动某个型号的U盘,能够支持U盘的常规操作,如命令hexdump、mke2fs和mount等。同时,要求在系统内核日志中显示出U盘的容量。若有余力,可增加多分区支持功能。 实验基础和思路 在教材中P130,讲解了如何编写一个Ramdisk块设备驱动程序(sbull.c),称为radimo;在文献《Linux Device Drivers》讲解了如何编写一个USB设备驱动程序,并以Linux源代码中的usb-skeleton.c为例。虽然前者驱动的并不是一个实际的块设备,且后者又只是针对usb字符设备,但是它们提供了一个不错的基础,通过合并我们就能基本得到一个支持usb块设备的驱动程序。之所以说基本得到,是因为合并后只是有了块设备、USB设备的驱动支持框架,但还缺一样:对U盘(USB块设备)的实际访问操作。USB块设备的访问方法与USB字符设备区别很大,有一套复杂的协议。把这样一套协议研究清楚,将花费大量时间,也远离了我们驱动程序开发的核心。这是一大难点,为此我们专门编写了一个U盘访问函数(myudisk_Bulk_transport),以减轻工作量。下一节将对该函数的使用方法和工作过程进行专门讲解。 简言之,合并radimo和usb-skeleton这两个参考驱动程序,以构造整体框架,调用帮助函数myudisk_Bulk_transport以访问U盘,从而打造一个简洁的U盘驱动程序。本节接下来介绍这两个参考驱动程序:radimo和usb-skeleton,着重讲解其工作原理及合并关键环节。 参考驱动程序一:块设备驱动程序sbull 请参看教材P130

相关文档
最新文档