FSL USB Stack 简介

       USB stack是飞思卡尔半导体公司为客户提供的免费USB协议栈，方便客户在飞思卡尔MCU上进行USB方面的开发，支持的MCU有：ClodFire、HCS08、Kinetis，同时它提供基于CW、IAR、KEIL MDK的例程供客户选择，这样可满足客户使用不同IDE的习惯。

      USB stack按照协议驱动可分为：Device stack、Hoststack和OTG stack；同时其支持的USB 类几乎可以满足所有的USB开发需求，包括个人保健设备类(PHDC)、人机接口设备(HID)、大容量存储设备(MSD)、通信设备类(CDC)、音频类、On-The-Go USB 2.0标准附录和PHDC USB.org标准类等。其中除了标准USB类，PHDC可遵照康体佳健康联盟等医疗行业标准，使软件能够支持医疗设备内部的USB连接。该协议栈使现有的8位和32位飞思卡尔MCU实现了标准化、数据连接和可移植性，有助于加速通用和医疗产品的开发。

       本文以USB stack 4.1.1中的Kinetis_twrmkl25z128_hid_mouse例程为例，介绍USB Device stack的代码架构组成，程序流程，USBstack USB driver和HID class driver文件，API函数。

       图1是USB stack 4.1.1的目录结构，而图2表示的是USB stack 4.1.1的代码架构。

图 1 目录结构

图 2 软件架构

       飞思卡尔提供的USBstack的代码架构是分层式的，自上而下可分为USB Application、Class Drivers和USBDrivers。基于分层式架构的USB stack可以让USB开发者只需将开放的精力放在USB Application，而无需理会其它两层的程序代码细节，同时USBApplication的程序代码也可以在不同MCU间非常容易的实现移植，只要底层程序代码与MCU是相契合。

       USB Drivers处于USB stack代码架构的最底层，它与MUC的USB寄存器的联系也最为紧密，它操作USB寄存器实现USB device initialization、USB devicede-initialization、端点初始化、发送字符到端点或接受来自端点的字符、配置USB device地址、stall或unstall端点、拒绝挂起传送、禁止USBdevice。当端点发送或接受字符和USB总线上有事件发生时，USBDrivers都会传送对应的Callback给上层架构如USBApplication或Class Drivers，接着上层架构根据传送的Callback调用具体API处理。调用USB Drivers中的USB Device Controller Interface (DCI) API可直接操作USB模块中的寄存器，实现不同配置和USB总线功能。

       Class Drivers由Framework模块、Commonclass模块、Class specific模块组成。Framework模块负责处理USB device在枚举过程中的控制端点接到的来自Host的各式请求。Commonclass模块负责处理所有USB类都会发生的suspend/resume、reset、stall、SOF。当检测到事件发送时，如USB总线复位、枚举成功、配置变换、数据接收或发生完成等，Commonclass模块都会通过传送Callback通知Class specific模块或者USB Application。图3表示USB Device在枚举过程中的状态变换关系，而状态变换中所引发请求或者事件由Framework模块和Common class模块处理，表1描述的是USB Device状态。

图3USB device状态框图

表1 USBDevice状态

        Class specific模块用于处理控制端点外的端点与Host通信的事宜，在这类端点上进行字符发送和介绍都受Classspecific模块管理，同时Class specific模块还会处理在控制端点上接收到的特定请求，以Kinetis_twrmkl25z128_hid_mouse例程为例，Get_Report、Set_Report 、Get_Idle、 Set_Idle 、Get_Protocol、Set_Protocol就属于HID类的特定请求。

       不同USB类的Class specific模块其Class specific模块名称和API也是不同，像HID类的Classspecific模块—HID Class driver为HID类协议服务，所以对于通信设备类(CDC)，则CDC Classdriver为CDC类协议服务，个人保健设备类(PHDC)的Class specific模块—PHDC Class driver自然为PHDC类协议服务，以此类推。

       USB Application处于USBstack软件架构的最上层，通过调用Class Drivers和USBDrivers来实现USB通信需求。在USB stack4.1.1中提供了各个USB类的例程（如图4所示）如HID mouse, keyboard, SD card, USB audio, battery charging,personal health care, video device, MSD, CDC，方便客户参考或者直接应用。

图 4USB stack例程

        USB Device stack初始化时，USBApplication通过逐层调用，实现Class Drivers和USB Drivers层的初始化。在枚举过程中，当检查到USB总线有事件发生，Class Drivers会向USBApplication传送Callback，而对于USB Host向USB Device发送获得设备描述符、配置描述符、字符描述符的请求，ClassDrivers也会处理，而且识别出具体请求后，会将在USB Application中，已定义好的描述符发送给USB Host。当收到到USB Host发出的Set configuration请求，即表明USB Device枚举成功，而Class Drivers也会将枚举成功事件通知给USBApplication。

图 5 初始化流程

     USB Application通过调用Class Drivers中的Send API发送数据。Class Drivers中的Send API在发送数据前，首先检测队列的当前状态，如果队列已满，则返回Busy状态标志。如果队列不为空，已有请求正在处理，新来的请求进入队列等待，为将请求内容发送到USB Drivers做准备。而在发送请求内容期间，它会先检测USB总线是否处于挂起状态，如果正处于挂起状态，它会唤醒USB总线并接着将请求内容发送到USB Drivers。当Send API执行完成后，Class Drivers会将此请求从队列中移除，并重新发送一个新的请求。

图 6 发送数据流程

      当USB 总线上有来自USB Host的字符数据时，USB Drivers将此事件发送给ClassDrivers，而Class Drivers则调用USBDrivers中Receive API接收字符数据，如果接收的字符数据小于端点缓存值，则ClassDrivers会立即处理收到的字符数据，否则，需要等Class Drivers接收到所有的字符数据后，Class Drivers才会处理。