|
|
本帖最后由 FSL_TICS_ZP 于 2014-8-25 16:30 编辑
FSL USB Stack 简介
USB stack是飞思卡尔半导体公司为客户提供的免费USB协议栈，方便客户在飞思卡尔MCU上进行USB方面的开发，支持的MCU有：ClodFire、HCS08、Kinetis，同时它提供基于CW、IAR、KEIL MDK的例程供客户选择，这样可满足客户使用不同IDE的习惯。
USB stack按照协议驱动可分为：Device stack、Host stack和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的代码架构组成，程序流程，USB stack USB driver和HID class driver文件，API函数。
1. USB Device stack代码架构
图1是USB stack 4.1.1的目录结构，而图2表示的是USB stack 4.1.1的代码架构。
图 1 目录结构
飞思卡尔提供的USB stack的代码架构是分层式的，自上而下可分为USB Application、Class Drivers和USB Drivers。基于分层式架构的USB stack可以让USB开发者只需将开放的精力放在USB Application，而无需理会其它两层的程序代码细节，同时USB Application的程序代码也可以在不同MCU间非常容易的实现移植，只要底层程序代码与MCU是相契合。
USB Drivers处于USB stack代码架构的最底层，它与MUC的USB寄存器的联系也最为紧密，它操作USB寄存器实现USB device initialization、USB device de-initialization、端点初始化、发送字符到端点或接受来自端点的字符、配置USB device地址、stall或unstall端点、拒绝挂起传送、禁止USB device。当端点发送或接受字符和USB总线上有事件发生时，USB Drivers都会传送对应的Callback给上层架构如USB Application或Class Drivers，接着上层架构根据传送的Callback调用具体API处理。调用USB Drivers中的USB Device Controller Interface (DCI) API可直接操作USB模块中的寄存器，实现不同配置和USB总线功能。
Class Drivers由Framework模块、Common class模块、Class specific模块组成。Framework模块负责处理USB device在枚举过程中的控制端点接到的来自Host的各式请求。Common class模块负责处理所有USB类都会发生的suspend/resume、reset、stall、SOF。当检测到事件发送时，如USB总线复位、枚举成功、配置变换、数据接收或发生完成等，Common class模块都会通过传送Callback通知Class specific模块或者USB Application。图3表示USB Device在枚举过程中的状态变换关系，而状态变换中所引发请求或者事件由Framework模块和Common class模块处理，表1描述的是USB Device状态。
图3 USB device状态框图
表1 USB Device状态
Class specific模块用于处理控制端点外的端点与Host通信的事宜，在这类端点上进行字符发送和介绍都受Class specific模块管理，同时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类的Class specific模块—HID Class driver为HID类协议服务，所以对于通信设备类(CDC)，则CDC Class driver为CDC类协议服务，个人保健设备类(PHDC)的Class specific模块—PHDC Class driver自然为PHDC类协议服务，以此类推。
USB Application处于USB stack软件架构的最上层，通过调用Class Drivers和USB Drivers来实现USB通信需求。在USB stack 4.1.1中提供了各个USB类的例程（如图4所示）如HID mouse, keyboard, SD card, USB audio, battery charging, personal health care, video device, MSD, CDC，方便客户参考或者直接应用。
图 4 USB stack例程
2. USB Device stack程序流程
2.1 初始化流程
USB Device stack初始化时，USB Application通过逐层调用，实现Class Drivers和USB Drivers层的初始化。在枚举过程中，当检查到USB总线有事件发生，Class Drivers会向USB Application传送Callback，而对于USB Host向USB Device发送获得设备描述符、配置描述符、字符描述符的请求，Class Drivers也会处理，而且识别出具体请求后，会将在USB Application中，已定义好的描述符发送给USB Host。当收到到USB Host发出的Set configuration请求，即表明USB Device枚举成功，而Class Drivers也会将枚举成功事件通知给USB Application。
图 5 初始化流程
2.2 发送数据流程
USB Application通过调用Class Drivers中的Send API发送数据。Class Drivers中的Send API在发送数据前，首先检测队列的当前状态，如果队列已满，则返回Busy状态标志。如果队列不为空，已有请求正在处理，新来的请求进入队列等待，为将请求内容发送到USB Drivers做准备。而在发送请求内容期间，它会先检测USB总线是否处于挂起状态，如果正处于挂起状态，它会唤醒USB总线并接着将请求内容发送到USB Drivers。当Send API执行完成后，Class Drivers会将此请求从队列中移除，并重新发送一个新的请求。
图 6 发送数据流程
2.3数据接收流程
当USB 总线上有来自USB Host的字符数据时，USB Drivers将此事件发送给Class Drivers，而Class Drivers则调用USB Drivers中Receive API接收字符数据，如果接收的字符数据小于端点缓存值，则Class Drivers会立即处理收到的字符数据，否则，需要等Class Drivers接收到所有的字符数据后，Class Drivers才会处理。
图 7数据接收流程
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有帐号？注册
x
阿莫论坛20周年了！感谢大家的支持与爱护！！
月入3000的是反美的。收入3万是亲美的。收入30万是移民美国的。收入300万是取得绿卡后回国，教唆那些3000来反美的！
|
发表于 2014-8-25 16:01:27
楼主
