Chinaunix首页 | 论坛 | 博客
  • 博客访问: 974513
  • 博文数量: 214
  • 博客积分: 10173
  • 博客等级: 上将
  • 技术积分: 1867
  • 用 户 组: 普通用户
  • 注册时间: 2007-06-18 13:48
文章分类

全部博文(214)

文章存档

2012年(1)

2010年(13)

2009年(5)

2008年(98)

2007年(97)

分类: LINUX

2008-01-18 15:34:58

这个礼拜由于突然被安排进了一个项目,所以终止了在进行当中的USB驱动的培训。作为自己学习的总结,也希望能为有想法要往这个方向发展但暂时还没有向这 个方向发展的同学们提供一些微薄的帮助。这个项目可能要写bootloader或者sd卡/camera驱动,反正到时学会了再回来写篇笔记,希望大家喜 欢:)

开始写这篇文章之前感觉能写得比较好,可开始写了发现写这样的一篇东西有难度啊,又想不要象规范那样累赘,有想表达出自己的意思, 甚为复杂啊。暂且估计下,一般没有任何USB基础的人可能根本看不懂这篇文章,如果先能把USB 1.1 spec过一遍再来看,可能效果就会好很多。还有点就是,毕竟没有参与过实际的USB的项目开发,其中很可能有些概念我的理解也是错的,所以欢迎大家指出 错误,补充不足。

参考书籍:
USB 1.1 spec -- 可下载
UHCI/OHCI/EHCI spec -- 可下载
LINUX设备驱动程序(第三版)-- 中国电力出版社
LINUX内核源代码情景分析 -- 浙江大学出版社
PDIUSBD12 USB固件编程与驱动开发 -- 北京航空航天大学出版社
P.S.世面上能见到的有关USB的书我看过6.7成了,我发现大多只是把USB spec的英文内容翻译成中文,刚上手的时候对英文不是母语的我们有些帮助,但过了段时间之后就会发现这些书空洞无物了。上面那3本里则是有些自己的内容,还是值得一看的。

推荐软件:
usbhound 5.0 -- http://bbs.zndev.com/htm_data/9/0404/64787.html可下载,用于抓获UBS通信时的包。
linux kernel -- 可在线看,linux的USB驱动代码可从这里获得。
Platform builder 5.0 -- Windows CE开发工具,很难下到,但BT上应该有,有所有Windows CE的USB驱动的代码。
P.S.由于没有仔细接触过Windows PC上的驱动(WDM),所以不太清楚DDK里面的内容,我以下的内容也只会涉及Windows CE和linux。

1.USB是主从结构的。
如何确定主从:这个是由USB接口的芯片决定的,也就是由硬件决定的,而不象以太网中的c/s那样,由软件决定。
举个例子:我们的PC主板上提供的USB接口类型决定了PC机在USB通信中永远是主(host)端,而不能做从(device)端。而U盘里面的USB芯片也决定了U盘只能做为从(device)端。
注意:但是在USB2.0的规范中出现了OTG的概念,可以让设备即能做host,又能做device,但这个方面我只是知道概念,对于具体的内容还不熟悉。

2.USB通信都是由host端发起的。
概念描述:也就是说,必须由host先向device发送请求,然后由device作出响应。device没有主动发起通信的能力。

3.device端是通过endpoint来进行通信的。
概 念描述:USB的规范上,以及很多书籍上都有endpoint的概念,但是我感觉说得都不清楚,在这里我想尽力能描述得清楚些。首先,endpoint的 物理存在的东西,是在device芯片上存在的东西。你可以把USB的endpoint想象成切了片的连藕,那一个个孔就是endpoint,只有通过 endpoint才能传输数据。USB规范指出,必须有endpoint0来进行基本的配置操作。

4.USB的host端的驱动
USB的host端的驱动是很麻烦的,在windows ce和linux下虽然代码不一样,但是实现的基本结构相同。
USB client driver
        |
USB driver/USB core
        |
host control driver
        |
   host control
        |
      cable
就是这个5层的结构。
cable就是我们用的USB连接线,当然,要是距离足够短,也可以完全不需要,而且这个和软件上的实现完全没有关系。

host control就是我上面说过的USB芯片里的一种,也就是用于host端的芯片。所以最下面2层完全是硬件上决定的,和软件无关,是硬件设计人员决定的。而上面的3层就是具体的USB驱动的实现了。

host control driver看名字大家就应该知道了,是对host control的驱动。这里要说下,到现在为止,USB的host control分为3种,分别是UHCI,OHCI,EHCI,这3种不同的host control在硬件的实现上是不同的。EHCI用于USB2.0的规范,而UHCI和OHCI用于USB1.1的规范。一般在PC机上的1.1的接口都 是UHCI的,但是一般嵌入式CPU上的USB接口则是OHCI比较常见。UHCI在硬件复杂度上不如OHCI,所以造成的后果是UHCI对应的软件驱动 会比OHCI的麻烦些。USB的数据其中最终都是通过host control来发送的。这些不同的host control发送数据的方法其实也满类似的。一般是按照spec来定义一些结构体,当然,结构体里每个字段的含义也必须严格按照spec里的定义。这1 个结构体就当是一个数据包。然后,把一个个的数据包连接成链表的形式,再把链表头的地址赋给host control的某个特定的寄存器,这样,host control就会根据这个寄存器里的地址找到要发送的数据,然后把这些数据组装成USB通信协议中规定的格式,再发送出去。(对于UHCI, 《LINUX内核源代码情景分析》里面有比较详细的分析,不过代码是linux2.4的,和现在的2.6还是有满大不同的)。所以,如果在硬件平台确定的 情况下一般开发host control driver的机会很少,而且开发host control driver确实是一件很有难度的事。

再 上面一层,USB driver/USB core(Windows ce里叫USB driver,linux里叫USB core,只是名字不一样),这层主要实现了USB规范中的4种传输(中断,同步,控制,大块,具体可参考USB 1.1 spec),其实也就是把host control driver里的功能更集中得向上抽象了一层。这层是操作系统提供的,是不需要驱动开发人员来修改的,他是用来对最上层的client driver屏蔽掉host control的不同。

最上层的USB client driver,才是我们一般情况下讲的USB鼠标驱动啊,U盘驱动啊,数码相机驱动啊。这里就要用到上面讲的device的endpoint了。首先, USB client driver的任务是确定设备的特性,并对设备进行配置,使之进入正常的可工作状态。而这些配置必须用控制传输的方式通过device的 endpoint0来进行。(对于这些操作,一般叫做枚举,整个操作的过程可通过bushound这个软件截获,,或者在《PDIUSBD12 USB固件编程与驱动开发》中也有教详细的描述。个人感觉,理解枚举的每一个步骤有利于理解usb包发送的格式)。在完成了对设备的配置之后,设备就可以 正常工作了。这时,endpoint0的职责就就完成了。接下去,所有的通信则是同过endpoint1,endpoint2,endpoint3... 等endpoint进行了。endpoint1,endpoint2,endpoint3...不象endpoint0,他们在地位上是没有区别的。

下 面拿linux里的USB鼠标驱动做个列子,因为这是我发现的最为简单的USB client驱动了,也是我暂时基本能完全看懂的一个驱动,呵呵。(http: //lxr.linux.no/source/drivers/usb/input/usbmouse.c)在完成了枚举之后,驱动程序和USB鼠标之间 通过endpoint1进行通信。驱动调用usb_submit_urb(mouse->irq, GFP_KERNEL),mouse->irq是一个URB(至于URB是什么,可参考linux device driver 3),简单得可以理解为要发送给鼠标的数据。usb_submit_urb也就是把数据包提交给host control,让其把数据包发送出去。而在usb_submit_urb之前,usb_fill_int_urb(mouse->irq, dev,pipe,mouse->data,(maxp > 8 ? 8 : maxp),usb_mouse_irq, mouse, endpoint->bInterval),其中乱七八糟的参数暂时不要关心,要关心的是usb_mouse_irq。这是一个函数地址,起到回调 作用。也就是驱动通过usb_submit_urb把数据发送出去。当收到鼠标的正确回应之后,linux会自动去调用usb_mouse_irq来读取 鼠标传回来的值,从而进行具体的响应。当usb_submit_urb把请求发给鼠标之后,他就进行等待。鼠标收到这个请求之后就返回信息。这里又要涉及 到一个麻烦的东西,就是USB规范里对不同的设备又分了n多的类,每个不同的类又有不同的规范与之对应。鼠标对应的是HID规范。规范里指出,鼠标如果在 任何按键或者位置上没有变化的情况下,是不需要发送数据给host端的。所以,如果你的鼠标不动,鼠标只会发送一个nak标志(也就是拒绝请求)给 host端。而host端收到nak标志后会把刚才的数据进行重发。这里就有一个概念了:USB host control对于usb device是基于轮巡的机制,而USB host control对于CPU则是基于中断的机制。这个概念以前捆扰了我一段时间。就这样,USB host control对鼠标不断请求,这个请求的间隔是很短的,可能只有10ms,当鼠标发生了事件之后,鼠标会发送数据回host,这是USB host control中断通知CPU,于是usb_mouse_irq被调用。在usb_mouse_irq里,就可以读取鼠标发回的数据。当读完之后,驱动再 次调用usb_submit_urb发出请求,就这么一直重复下去,一个USB鼠标的驱动程序也就完成了。

要是U盘的驱动,和鼠标的驱动 有很大的不同。因为U盘属于mass storage类,所以必须遵循USB mass storage协议规范。USB mass storage比USB HID复杂很多,而且还要设计SCSI的命令,由于培训到这里就结束了,所以没有学下去。谁有兴趣可以去学下,感觉mass storage是很实用的技术的,数码相机,U盘,mp3...反正是不胜枚举啊。

5.USB device驱动
也就是一般说的 固件编程。device端的驱动相对host端的要简单很多。因为USB规范规定所有通信必须是由host发起的,所以device的驱动程序主要就是对 host的请求作出响应。这里就要强烈推荐《PDIUSBD12 USB固件编程与驱动开发》了,这里面的内容足够我们品位一段时间了。一般的做法是在进入了main之后除了初始化硬件之外什么也干,等着中断的发生。当 USB芯片收到从host端来的数据之后,就会发生中断,进入中断处理。通过读取USB芯片上寄存器的值,可知道是哪个endpoint来了数据,然后就 读取数据进行响应。USB host发送过来的可能是标准的请求,也可能是类的请求,有可能是厂商的请求,也可能只是数据。关于标准的请求参见USB 1.1 spec chapter 9,里面有很详细的定义。

后记:暂时就写这么多了,以后感觉哪里不足再加吧,写了那么多,手酸 了...这里有点要提醒新手们,学习的主要方法就是文档,代码,实验。这里的文档不是指书,而是官方文档。学驱动不比学C++,学JAVA,满天的经典书 籍,很多时间只能靠自己去摸索,自己去体味没有注释的代码。
阅读(2050) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~