Host的追随者Udc.docVIP

Host的追随者Udc Date Auther Action 2010/12/04 Mengfandong Creat 前面我们介绍了EHCI规范，主要用在host控制器上，有主就要有从，双方谁也离不开谁，缺少了谁，对方都将失去存在的意义。相对于host来说，USB设备就是被动的接收Host的命令，所以USB设备一侧的控制器就相对简单了，并没有专门的规范出来统一江湖。为了能够更系统的介绍USB的应用场景，这里我们就简单介绍一下USB设备驱动(或者叫做固件)的设计框架。 这一章节重在USB主从应用场景的了解，和设备驱动程序框架的理解，仅从两个方面来简单介绍：一 USB设备控制器(UDC)的基本操作思路 二 UDC和应用的结合方式，并以linux下的USB gadget框架进行一下实例化。 一UDC控制器的主要元素及流程 这里只介绍udc的通用控制流程并且以U盘为例介绍控制器驱动层和mass storage层的设计框架。 为什么说只介绍udc的通用控制流程呢？原因有二：1 据目前接触的udc 的控制方式来说，似乎在大的控制流程上基本思想是一样的，只是在实现这些流程的某个环节上如寄存器级的使用上稍微有差别; 2 具体的针对某个IP核来讲述太过具体，并不是谁都用得上，造成信息的混乱，也涉及到商业问题(暴露了公司的产品)，一位同事说的好:一切设计都是在操作寄存器，这是一位具有十多年驱动开发工作经验的老工程师的体会，经典。做任何事情都有宏观和微观之说了，大的方向就是宏观，具体怎么做就是微观。这里就是介绍宏观，udc控制器操作上的共性，大方向上该怎么去做。 首先要考虑的是端点，这是用来进行数据传输的基本要素，既然如此作为端点就会有一系列配套的元素出现:fifo缓冲区、状态寄存器、控制寄存器、中断寄存器等。在host枚举设备时，会通过获取描述符得知设备都有哪些端点、端点的传输方向和类型，这些都需要设备在初始化时做好，当然这个动作应该有应用来促发，控制器层留出设置的接口，因为控制器是为应用服务的，应用是多变的，但是不管怎样这些初始化的配置需要在枚举前给出正确的初始化，以便host获取正确的信息。以U盘为例，有3个端点：默认的控制端点、bulk in端点、bulk out端点。所以udc控制器会有相关的寄存器来设置：端点n作为什么传输、传输方向、最大包长度。 Fifo是一个很重要的角色，我们始终要记住，usb中host是主动的，device是被动的。先介绍out传输，host发送数据，device接收数据。Host要发送数据，首先会ping一下，看device是否能够接收数据，如果不能(没有准备好),就返回nak。那么device怎么能返回nak呢？这就是udc会有一个位，如果一切准备工作做好了，就把这个rxready位置1，那么udc控制器收到host的ping令牌或者out令牌时就会返回ack，host就会接着发送数据包了(如果有)，udc控制器将收到的数据放到fifo中(所以在初始化中要设置每个端点对应fifo的大小和地址)，然后报出中断，rxready位被控制器清0，如果这时host仍然发数据会返回nak。中断处理程序就应该将数据取走，如果准备好了进行下一次数据的接收，那么就置位rxready，再次接收数据。 如果是in传输，host一直发送in令牌，如果udc没有准备好数据，就返回nak。这同样有一个控制位txready。Udc准备好数据，将数据放到fifo后，将这一位置1，当host再次发送in令牌时，返回ack，udc控制器将fifo中的数据再随后的数据传输中送出，当数据发送完成后，txready被udc控制器清0。Udc控制器对host的in令牌将一直返回nak。 上面对in和out传输的介绍涵盖了udc控制器的基本框架，当然fifo模式是最基本的模式，大多数udc控制器支持dma，dma的使用方式属于每种控制器的特性了。 2 udc和应用结合的框架 由于usb总线的特殊性，即一切总线活动都有host端发起，device端被动接收，所以在开发usb device时，一个数据传输流程处理的触发位置是从中断开始的，而在开发host端时则有应用触发一次数据传输，中断只代表数据传输的结束，所以host驱动开发时，思路上更好理解。了解了两者的不同后，我们当然应该把目光集中在device 控制器发生中断时的处理，先说个大概。当udc发生中断后，如果是端点0发生中断，看看是否为setup中断(主机发送了setup包)，如果是就开始分析是那种命令，比如是获取配置描述符。那么你就将描述符准备好，放在fifo或者dma中，然后置位一个标志，主机host就可以取走了(否则会返回nak)。 那么如果不是端点0的中断呢？比如