基于RTEMS的USB设备驱动程序设计

3.2.2 端点状态管理

USB设备与主机的通信可以通过对USB端点状态的控制来完成。USB设备端点可以定义3个不同状态：空闲(Idle)状态、停止(Halt)状态和读/写(W/R)状态。USB硬件抽象层提供USB_ConfigureEndpoint、USB_Write、USB_Read、 USB_EndOfTransfer、USB_Stall、USB_HaIt和USB_ClearHalt七个功能函数对设备的状态进行管理，端点的状态转换过程如图4所示。

USB_ConfiguIreEndpoint负责配置端点的最大包长度和传输方向，并将端点状态设置为空闲状态。端点进入空闲状态，如果上层调用 USB_Write进行数据发送，将发送缓冲区指向要发送的数据，设置端点状态为写状态，等待USB主机接收数据(真正的数据传输在中断服务程序中进行)。写完成后，端点回到空闲状态。数据接收与发送类似。如果设备出现某种错误，主机会向设备发送Set_Feature命令，设备接收到 Set_Feature命令，执行USB_Halt进入停止状态。端点处于停止状态时，如果接收到Clear_Feature，则执行USB— ClearHalt清除Halt标志，进入Idle状态;如果USB设备由于某种原因无法对当前命令进行处理(如不能识别命令，或者没有准备好进行数据传输)，则执行USB_Stall通知主机发生错误，但端点的状态不变。

3.2.3 中断管理

在USB设备端，存在以下几类中断：帧起始中断、设备恢复中断、设备挂起中断和端点中断。硬件抽象层的中断服务例程对各类中断进行响应，判断中断类型。如果是与设备状态相关的中断，则需要调整设备到相应的状态，同时调用上层提供的相应回调函数;如果是端点中断，则按照图5的流程处理。

3.3 USB设备类驱动

USB设备类驱动包含两个功能：对标准命令的处理和对基于设备类的命令的处理。USB类驱动根据硬件抽象层提供的接口，与中断服务程序协同管理USB设备和端点的状态。通过为硬件抽象层的中断服务程序提供相应的回调函数，完成特定设备类要求的操作;同时根据RTEMS系统的设备管理机制，为应用程序提供设备驱动的入口点。

3.3.1 标准命令处理

为了更好地协调USB主机与设备之间的数据通信，USB规范定义了一套命令，用于完成主机对总线上的USB设备的控制。 USB设备必须对来自于主机的控制命令做出响应。一般来说，命令都是通过设备的默认管道传递到设备的。USB协议定义了11个标准命令，用于配置设备、获得设备的信息等操作。USB设备必须支持这些标准命令。

3.3.2 基于设备类的命令处理

除了标准命令以外，USB每种设备类的协议又定义了自己的类命令。设备厂商为了使设备实现某种特殊的功能，还可以定义厂商专有的命令。

所有的命令虽然有不同的内容和使用目的，但也有一些共同的特点：所有命令的结构是一样的;USB命令是在控制传输的设置阶段从USB主机发往设备的;如果除命令本身外，主机还打算向设备发送与命令相关的信息，那么这些信息将由紧跟在设置阶段的数据阶段发出;如果命令要求设备返回信息，这些信息会在控制传输的数据阶段从设备端发出;当命令完成时，设备会在握手阶段返回ACK;设备可以返回Stall，表明不支持当前命令或无法完成命令要求的操作。

3.3.3 命令的处理流程

当设备接收到新的命令时，硬件抽象层的中断处理函数会调用USB设备类驱动层提供的回调函数;在回调函数中，判断命令的类型，如果是标准命令，则交给标准命令处理函数处理;否则，交给基于设备类的命令处理函数处理。因此，要实现对某种标准USB设备类型或非标准USB设备类型的命令的支持，只需要在USB 设备类驱动层添加对该标准设备类型命令或者自定义命令的处理函数，这样使得程序易于扩展。

3.3.4 USB设备驱动程序入口函数

RTEMS系统的设备驱动程序应该包含下列入口函数：设备初始化例程、设备打开例程、设备关闭例程、从设备中读出数据的例程、向设备中写人数据的例程和特定于具体设备的设备操作例程。如果一个设备驱动程序不支持某个特定的入口函数，在设备驱动程序地址表中这个入口函数的地址值应该设置为空。以下6个函数是驱动程序为标准I/O请求提供的入口函数。

①初始化：rtems_device_driver usb_initialize(rtems_device_major_number maior，rtems_device_minor_numberminor，vold*arg)。在RTEMS系统中注册USB设备的设备名，调用 USB_Init实现设备的功能和状态初始化，注册中断。

②打开：rtems_device_driver usb_open(rtems_device_major_number major，rtems_device_minor_number mi—nor，void*arg)。如果设备已经被成功枚举(处于配置态)并且未被其他任务打开，则标记设备已被打开标志，成功返回;否则，打开失败。

③关闭：rtems_device_driver usb_close(rtems_device_major_number major，rtems_device_minor_number mi—nor，void*arg)。清除设备打开标志。

④读操作：rtems_device_driver usb_read(rtems_de—vice_major_number major，rtems_device_minor_numberminor，void*arg)。调用USB_Read()，设置端点为读状态，等待主机端发来的数据，数据到达后，中断服务程序会把端点设置为空闲状态，函数将数据返回给应用程序。

⑤写操作：rtems_device_driver usb_write(rtems_de—vice_major_number major，rtems_device_minor_numberminor，void*arg)。调用USB_Write()，设置端点为写状态，并等待主机接收数据，数据发送完成后，中断服务程序会将端点设置为空闲状态，函数返回。

⑥控制操作：rtems_device_driver usb_control(rtems_device_major_number major，rtems_device_minor_num—ber minor，void*arg)。具体操作根据需要定义。将设备驱动程序的入口函数地址添加到设备驱动程序地址表后，就可以通过RTEMS提供的I/0系统调用对设备进行操作。

结 语

在RTEMS系统的移植和应用开发过程中，设备驱动程序的编写是十分重要的一环。USB由于其协议的复杂性，成为驱动开发中的难点之一。本文对RTEMS 系统下USB设备驱动程序的设计与实现进行了详细论述，相应程序在AT91RM9200开发板上得以实现和验证。本设计着眼于程序的可移植性和可扩展性，采用层次结构，实现了硬件平台与USB具体设备类驱动的分离，使其能够方便地移植到其他硬件平台上并实现对特定USB设备类型的支持。同时，由于与操作系统的耦合度较小，驱动程序还可以方便地移植到其他的操作系统上。