基于μC／OS-Ⅱ的嵌入式USB控制软件的实现

摘要：在此以杭州中天32位RISC CPU CK510为内核的HMl521_B芯片上，基于μC／OS-Ⅱ操作系统，实现对USB设备的读写控制。系统采用嵌入式USB主机控制软件的分层结构，着重阐述FAT32文件系统、USB设备枚举和BULK-ONLY传输的具体实现过程。为了节省硬件资源，放弃了USB协议中的繁文缛节，抓住协议核心，设计了精简高效的驱动程序。考虑到各种U盘的不同特性，增强了驱动兼容性方面的设计。整个阶段都由逻辑分析仪给出实测数据抓包截图。
关键词：嵌入式USB控制；FAT32文件系统；USB设备枚举；Bulk-only传输

0 引言
    2010年USB 3．0的正式推出象征USB传输极速时代的到来，但是嵌入式领域由于考虑成本等各方面因素很多仍采用USB 1．1协议。同时USB协议的主体框架并没有改变，因此研究USB 1．1协议在嵌入式系统上的实现对于USB 3．0协议的应用也是很好的铺垫。本文在以杭州中天32位RISC CPU CK510为内核的摩托罗拉HM1521_B芯片上，基于μC／OS-Ⅱ操作系统，实现对USB设备的读写控制。由于HM1521_B芯片只支持USB 1．1协议，所以本文实现的只是USB 1．1协议。USB是一种主从结构：主机Host和从机Device。所有的数据传输都由Host主动发起，而Device只是被动的负责应答。在USB OTG中，一个设备可以在Device和Host之间切换，用以实现设备与设备之间的连接，大大增加了USB的使用范围。但USBOTG依然没有脱离主从关系，设备之间必然有一个作为Host，另一个作为Device。标准的USB使用4根线，分别是5 V电源、差分数据线负(D-)、差分数据线正(D+)、地(GND)。USB的低速和全速模式采用电压传输，高速模式则采用电流传输。

1 USB控制软件的分层结构
    按照USB协议规范，USB运行首先是USB Host通过D+数据线上的电平变化检测USB Device的插入和拔出，Host和Device依据协议规定的顺序执行一系列信息交换，这称为枚举部分，也是所有USB主机都必须支持的功能。Host根据获得的Device信息判断该Device属于哪一类USB设备，并确定下一步选用哪个特定的程序加以支持。
    USB协议规定了HID(人机接口设备)类、Mass Storage(大容量存储设备，如U盘)类、音频类等各种设备类型。在嵌入式系统中，由于受系统性能和存储空间的限制，一般只能支持某几个类型。本文只支持Mass Storage类。

    图1是本文实现的USB Host控制软件的分层结构：应用层调用FAT32文件系统层的函数；文件系统层通过MassStorage UFI命令与存储设备建立联系，实现U盘上文件的建立和读写等一系列操作；最底层的是Mass Storage驱动模块，实现对U盘数据的读写功能。其主要函数包括：

    本文软件用C语言编程，并依赖μC／OS-Ⅱ操作系统提供的中断函数来调度各个函数的运行。
[!--empirenews.page--]
2 FAT32文件系统的实现
    文件系统的作用是对文件在介质上的存储进行管理，并为操作系统提供操作函数。若把U盘看成是以扇区为单位的逻辑盘(1扇区=512 B)，当一个U盘被格式化成FAT32格式的分区后，它的结构形式图如图2所示。

    引导扇区(DOS Boot Record，DBR)存储了本分区的BPB(Bios Parameter Block)信息。主引导记录MBR(Master Boot Record)是物理上第一个扇区，绝对扇区号是0，它独立于任何一个分区。MBR的前446B是系统引导程序，接着的64个字节是分区表DPT(Disk Partition Table)，最后两字节是扇区有效标志55 AA。初始化一个U盘的文件系统，很重要的一步就是填写引导扇区的过程。对有些关键字节进行分析如下所示：


    FAT32文件系统中，FAT表是一个数据表，以簇(cluster)的形式链式存放。当一个文件大于一簇(4个扇区)时，每簇中存放的数据便是文件存放的下一簇地址。直到遇到簇中的数据为“FF FF”时，才表示此文件已至尾簇。数据内容不连续地存放于数据区内。文件系统使用设备驱动提供的4个函数获取设备的状态信息以及实现对设备的读写。
   

3 USB设备枚举的实现
    枚举就是从Deveice读取信息，通过设备描述符设备告诉Host是什么设备、如何进行通信，Host根据这些信息来加载合适的驱动程序。
3．1 枚举过程及实现
    USB是一种主从的结构，所有传输由Host来发起。当Host发起一次传输时，通常包括3个包(Packets)的传输。Host首先是发送一个Token Packet，包含本次传输的命令类型(Type)、方向(Direction)、设备的地址(Device Address)以及端点号(Endpoint)；紧接着发送数据包(Da-ta Packet)，包含要求Device返回描述符的命令数据；最后由Device返回握手信号包(handshake packet)，正确返回(ACK)命令。[!--empirenews.page--]
    USB Host检测到有Device插入后，进行总线复位。然后Host使用默认地址0读取设备描述符。获取设备描述符的USB设备请求命令结构体为：
   
   
    第1次读取设备描述符时，Host首先发送setup包；之后进入主机读取数据阶段，Host发送in包，Device返回一个18 B的设备描述符，可以用一个结构体将其读回。最后Host发送0 B的数据包作为状态相应，设备返回ACK作为应答。用逻辑分析仪抓包，3个包如图3所示。

    第1次读取设备描述符后，Host依次进行地址分配、第2次读取设备描述符、读取配置描述符、读取描述符集、设置配置、读取配置状态和读取接口状态，方法和第1次读取设备描述符的方法一样。

3．2 U盘兼容性
    在设备枚举阶段将会碰到很多关于U盘兼容性的问题。
    (1)总线复位时间。不同型号的U盘对于总线复位时间的要求是不同的，比如金士顿1 GB的U盘需要的复位时间至少280 ms。在实现中为保险起见，给予400 ms的复位时间。
    (2)有些U盘的端点0是8 B payload的，大多数是64 B。对于8 B payload的U盘，要严格从第1次获取设备描述符时返回的第8字节获取payload，否则尽管枚举过程仍然能通过，但是后面在分析32字节的配置描述符时候会出现问题，没有收到完整的配置描述符是分析不出端点1和端点2的地址以及端点payload的。
    (3)在枚举阶段获取字符串描述符的时候，要进行判断。因为有些U盘不支持返回字符串描述符，用if语句判断，如果获取不到字符串描述符就跳过，不要返回失败。
[!--empirenews.page--]
4 Bulk-only传输的实现
    枚举结束后是对块设备的读写。Bulk-Only传输规范是USB组织针对大容量存储设备制定的一种块存储类协议，它仅仅使用Bulk端点来传送数据／命令／状态。

    图4是数据／命令／状态在USB总线上的传输流程图。根据此图Bulk-only传输的状态可以定义为：空闲、CBW处理、数据输出(从Host向Device传输数据)、数据输入(从Device向Host传输数据)、CSW处理、管道阻塞等6种状态。在空闲状态下，接收到的数据包为CBW包；在数据输出状态下，接收到的数据包为Host期待写入Device的数据；在数据输入状态下，Host请求从Device读取数据，Device将向Host发送这些数据包；在CSW状态下，Device封装并发送CSW包以向Host返回状态信息。因此，任何Bulk-Only事务均是以Host向Device发送CBW包并试图建立相应的数据传输开始的；而Device接收到CBW包，进行检查并解释，试图满足Host的要求，并通过CSW向主机返回状态信息。以读一个逻辑块为例，填写一个CBW包的程序如下所示：


    逻辑分析仪抓包结果如图5所示。从抓包结果可以清晰的看出CBW包由31个字节组成。

    CBW包和CSW包正确收发后，Bulk-only传输就能顺利实现。完成对扇区的读写，文件系统的挂载。上层应用程序使用文件系统提供的API，操作底层设备，实现对文件的建立、读写、删除等操作。经测试本系统支持长文件名和超过2 GB容量的USB设备。本设计最终实现了在不同型号U盘上完成对长文件名文件的新建、读写以及删除操作。

5 结语
    本设计在以CK510为内核的HM1521_B芯片上，通过文件系统实现了对USB设备的读写操作。程序代码放弃了USB协议中的繁文缛节，抓住协议核心以达到精简高效之目的。在大容量USB存储设备的兼容性方面也进行了探讨。经测试本系统支持长文件名和超过2 GB容量的USB设备。最终实现了在不同型号U盘上完成对长文件名文件的新建、读写以及删除操作。
    本系统尚需改进的地方主要是读写过程中的出错应对能力。如何应对USB设备在读写过程中的突然拔插，以及如何提高数据传输出错时的校验能力都是本课题进一步研究的方向。