RTEMS管理机制与USB驱动程序设计

引 言

    在航空航天和工业控制等一些嵌入式应用领域，要求控制系统具有严格的实时性，能够为任务提供一个可预见的响应时间。一些实时操作系统的引入可以有效地满足任务的实时性要求，如RTEMS和VxWorks。在这样的系统中，如果系统通信模块的通信速度不高，或者通信质量不可靠，就会影响整个系统的实时性能。通用串行总线(USB)由于其高带宽、高可靠性的特点，必将越来越多地应用到这类系统中。然而由于多数实时操作系统目前并未提供USB主机和设备的驱动，而且USB协议相对于其他串行通信协议(RS232、SPI等)复杂度较高，使得USB驱动程序的开发难度较大。

1 RTEMS及其设备管理机制

1．1 RTEMS简介

    RTEMS(Real—Time Executive for MultiprocessorSystem)是一个为嵌入式应用系统提供高性能支持环境的实时操作系统内核，早期用于美国军方的导弹系统。RTEMS的实时性能高于RTLinux，与VxWorks相比也毫不逊色。

    RTEMS具有如下特点：支持多任务；支持同构或异构多处理器系统；支持事件驱动、基于优先级、占先的调度算法，具有单调速率调度算法；支持任务间的通信和同步；支持优先级继承算法，快速响应的中断管理；支持动态存储器分配，具有用户配置的能力。

    RTEMS是微内核抢占式的实时操作系统，具有实时性能好、运行速度快和可靠性高等优点，在通信、航空航天、工业控制等领域有着非常广泛的应用。

1．2 设备管理机制

    操作系统的一个重要功能就是为应用程序提供一个统一的I／O设备的虚拟接口，使用户程序能够按照相同的模式对设备进行操作，无需关心每个设备的具体特性。

    RTEMS系统提出了一种设备抽象模型，使用这种模型，应用程序通过相同的I／O系统调用埘没备进行操作，而不必关心实现细节。RTEMS的I／O管理器提供的系统调用包括：

    ◆rIems_io_initialize，初始化一个设备驱动程序；
    ◆rtems_io_register_name，注册一个设备名；
    ◆rIems_io_lookup_name，根据设备名查找主／副设备号；
    ◆rterns_io_open，打开一个设备；
    ◆rteros_io_close，关闭一个设备；
    ◆rtems_io_read，从一个设备中执行读操作；
    ◆rtems_io_write，向一个设备中执行写操作；
    ◆rteros_io_control，特殊的设备服务。

    RTEMS系统使用设备驱动程序地址表来提供这种抽象，在这个表中提供了每个标准I／O请求处理函数的入口地址。RTEMS使用设备的主设备号和副设备号来定位它的驱动程序。主设备号是设备驱动程序地址表中相应设备表项的索引，用于选择某个设备驱动程序；副设备号的用途则依赖于具体的设备驱动程序，通常用于在相同设备驱动程序所控制的若干设备中指定特定的设备。在RTEMS系统中，每个特定的设备都有与之相关联的设备名称。RTEMS系统内核中包含了一个“设备驱动程序文件名表”。这个表将设备文件名与设备的主、副设备号联系起来，应用程序可以使用注册设备名查找与一个设备相关联的主设备号／副设备号，进而通过标准I／0系统调用和主设备号／副设备号在设备驱动程序地址表中找到该设备的驱动程序的入口函数地址，对设备进行操作。

    RTEMS系统在初始化时，会调用各个设备驱动程序的初始化函数，初始化所有的设备驱动程序。当应用程序需要对设备进行操作时，会执行有关设备管理的I／O系统调用，RTEMS会根据该系统调用判断应该选择的设备驱动程序的入口函数。由应用程序传递给RTEMS的信息，将被传递给适当的设备驱动程序入口函数。

2 USB通信协议简介

    USB(Universal Serial Bus，通用串行总线)是一种在主机和设备之间进行串行数据传输的通信协议。USB接口由于速度快、可靠性高、功耗低等优点，已成为当前微机的必备接口，同时也被广泛应用于嵌入式系统设计中心。USB的物理拓扑为分层的星型结构，由3部分组成——USB主机、USB集线器和USB设备，如图l所示。

    USB主机是USB系统的主控组件，控制总线上所有USB设备和USB集线器的数据通信过程，所有的数据传输都是由USB主机端发起的。

    USB主机控制器的复杂度要远远高于USB设备，典型的USB主机控制器大约需要10 000个门电路，而设备端的USB接口大约需要1 500个门电路。正是由于这种设计复杂度的不平等，使得USB设备得以在短时间内得到广泛应用。

3 RTEMS下USB设备驱动程序的设计

3．1 概 述

    嵌入式系统的硬件环境千差万别，各类USB设备的类规范也各不相同。为了确保程序的可移植性和可扩展性，将程序设计为二层结构：硬件抽象层和USB设备类驱动层，如图2所示。

    硬件抽象层封装对底层USB设备控制器的操作和对中断的处理，通过一些标准方法，为上层提供一个底层的硬件抽象，便于移植。USB设备类驱动层包含对标准命令和对特定设备类命令的处理。

3．2 硬件抽象层

    硬件抽象层对USB设备控制器进行操作，实现以下功能：设备状态管理、端点状态管理和中断管理。

3．2．1 设备状态管理

    每一个USB设备在正常工作前必须完成主机对它的配置过程，即总线枚举。USB设备在总线上共有6种状态：接入态、加电态、默认态、地址态、配置态和挂起态。

    硬件抽象层提供USB_Init、USB_Attach、USB_Disat—tach、USB_Connect、USB_Disconnect、USB_SetAddress、USB_ResetAddress、USB_SetConfiguration和USB_ResetConfiguration九个函数对设备的状态进行管理。一般来说，设备在总线上的状态变化都会由中断通知设备，中断服务程序根据中断类型和当前状态通过提供的功能接口对没备进行相应的操作，确保设备能够完成枚举过程÷顺利进入配置态。设备在硬件抽象层函数控制下的在总线上的状态机如图3所示。由于挂起与恢复无需软件干预，因此没有在状态机中描述这一状态。

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设备类型的支持。同时，由于与操作系统的耦合度较小，驱动程序还可以方便地移植到其他的操作系统上。