让U盘固件开发成为过去

当你准备开发U盘的固件时，是否心里面仍然不踏实，让这些成为过去吧。

今年年初的时候，在驱动开发上发贴《在ARM7上使用D12开发U盘的详尽技术报告》（用书名号中的字符查找，可以找到）。其中详尽地介绍了我在ARM7上用D12开发U盘的过程，以及所涉及到的方方面面的知识。得到了一些朋友的肯定和鼓励。从中我也体会到了帮助别人的快乐。

后来忙于别的，不经常上驱动了，但偶尔看一下仍然有许多人遇到U盘开发中的各种各样的问题，心里觉得十分不快。因为看到还有许多人仍然在为已经不存在什么问题的内容所折磨，看到我们的技术开发者仍然处于一种单干的状态，技术交流的模式和通道仍然不畅......别人做过的工作，我们完全可以用一种合理的方式拿过来为已所用，而把精力放在更多未知的问题上的。

后来再做U盘文件系统（即在固件中创建文件，在PC上可以读取）、USB Host（可以读写U盘）的过程中，也碰到过一些问题，在向别人征询时，有一些朋友很爽快，愿意交换彼此的源码，有一些网友则是有所保留，可能每个人都忙，别人也没有时间解答所有问题。感觉就是得到的帮助往往是模糊的，往往还隔层纸

在驱动上发贴，总会被淹没，因此，我有一个想法，成立一个邮件组，正在做U盘碰到问题，或是准备做U盘的朋友，请给我发邮件。frank_wang@263.net,主题注明“U盘开发”字样，我会将这些邮件收集到一个邮件组中，以后大家有什么问题，我可以抄送到所有人的邮件中，大家回信的时候，也可以回复全部，让大家共享信息。并且，我们一段时间将问题整理一次，放到驱动开发网上，作为大家的参考。我也可以考虑把Bulk Only和SCSI命令集响应部分的源码以合理的方式提供给大家，并乐意解答其中的问题。

总之，我的愿望是，所有中国人，想做U盘的，让这个都不再是问题，让我们把精力放在其他更多更重要的事情上，让我们的整体水平更上层楼。我愿意为我这个愿望做些什么。同时，我也愿意跟大家交流我曾经做过的一些项目内容，比如文件系统读写，Usb－Host控制U盘等等。


在第6页上的一个回贴中新增了《对USB协议层的深层剖析》，对此的理解，更有助于USB协议相关固件的调试。

介于几个文档有时在这里下不了，请大家试试到
http://embedusb.51.net/html/download.htm
下载

[编辑 -  7/19/03 by  frank_wang]

[编辑 -  12/1/03 by  frank_wang]

[编辑 -  4/17/04 by  frank_wang]

[编辑 -  4/18/04 by  frank_wang]

[编辑 -  9/11/04 by  frank_wang]

我会陆续在此贴中贴上自己整理出来的适于入门初学者的体会、理解和图表，以及整理出来的问题集锦。

很赞同楼主观点“别人做过的工作，我们完全可以用一种合理的方式拿过来为已所用”，我们很多时候在重复别人的工作

我会陆续在此贴中贴上自己整理出来的适于入门初学者的体会、理解和图表，以及整理出来的问题集锦。

如果能够这样的话，楼主功德无量！

我真切地感受到初学一个东西时的感受。其实这些东西并不难，只要有一些时间，都可以搞出来，但我们有必要每个人都去花相当可观的时间么！没有必要。

我们有时需要挑战自己，挑战我们自己的观念和心态。我希望自己可以做一个尝试。

frank_wang很热情！
如果能将整个程序的流程叙述清楚，那就再好不过了！

如果方便的话，给我发一份。U盘开发 \\文件系统读取等。duanjong@163.com

版主，请将它置顶！

呵呵，楼主是个热心人，真好

USB固件编程之一：固件编程的工作内容
USB固件编程可以用以下语句来精练地进行描述：

Device的固件编程，要搞定的是那几个端点。端点多少和配置情况受所用的Device芯片决定，具体可以看芯片资料。芯片一般提供一个中断信号，与单片机接口时，只要端点接受到数据，或发送数据成功后，便后产生中断，在固件里面，只要对些中断进行响应即可。

当Device接收到数据时，对这些数据进行分析处理（端点0遵守标准的数据格式，其他端点受端点类型的不同，有不同的数据格式），一般来说，这些数据是主机对设备发出的请求，设备只要响应主机的这些请求即可。Device芯片发送完数据后也会产生中断，这个中断信号告诉与之接口的单片机，可以继续发送后续的数据。

USB固件，好比一个有“妻管炎”的男人，而主机，则好是一个女管家。一般来说，主机让干啥就干啥，所以，USB固件程序的结构一般是基于中断处理的。平时，主程序做完必要的初始化工作后，就什么事也不做了，等待USB中断的产生，中断产生后，根据中断状态对相应的端点读取数据，或是向相应的端点发送数据。这一点是USB通讯协议的主－从模式先天决定的。但让人不可思议的是，这还有点象是母系氏族时期，因为，一个USB总线上，只能有一个主机，可以有多个设备，整个USB总线上通讯的协议和处理，发起与中止，基本上是主机控制的。因此，固件编程中，只要满足了主机的要求，就万事大吉了，可以确保自己的氏族中的应有地位。

真是好人啊！其实很多人都在问重复的问题！

U盘固件编程之二:固件编程的几个主要部分

在整个U盘固件中,程序从功能模块上分成两个部分:USB协议的处理和对Flash的读写.

USB协议的处理又分成两个方面.
    一是端点0的配置过程.所有USB设备在插入USB端口时，主机都通过地址0与设备的端口0进行通讯。在这个过程中,主机发出一系列得到描述符的请求,通过这些请求,主机得到所有感兴趣的设备的描述符,从而知道设备的情况,然后通过Set Address为设备设置一个唯一的地址,配置过程完成以后,主机就通过为设备所设定的地址与设备通讯,而不再是使用默认地址0.配置地址后,可能还要获取一次描述符,然后设置配置(Set Configuration)，之后便完成了对新插入USB总线的设备的配置过程。

    二是其他端点的数据通讯过程。在配置阶段中，主机已经知道了设备的端点的使用情况，以后，便可以通过这些端点来进行特定传输方式的通讯了。对于U盘来说，有两种传输方式，BULK ONLY和CBI方式，一般使用Bulk Only较多。这种传输方式要使用特定的Bulk端点，然后还要为其选择一种命令集。比如UFI或SCSI，因为Bulk端点的数据没有特定的数据格式，因此，需要使用某种命令集，来约定所传数据的格式。对于U盘固件编程来讲，就是要处理BULK端点的各种数据通讯。

    除了对各个相关的端点的USB协议的处理，剩下的就是FLASH的读写问题。这里存在两个层面的问题。
    一是解决Flash读写的问题，就是说你使用的Flash，先要实现成功的读写和擦除，这部分内容，是比较成熟的，一般都使用三星公司出的K9FXX08系列的，有16M（2808），32M（5608），64M（1208），138M（1G08）。它们的封装一致，只需要软件编程中稍做修改，便可以进行适应于另一种容量的存储器。

    第二个层面的问题，就是在U盘通讯过程中的问题了。NAND型的Flash有个特点，不可随机存取，擦除操作一次对16K的内容进行。所以，在U盘响应过程中，不可避免要对数据进行缓存。如果你的U盘方案中有较宽裕的RAM（超过16K），这个问题变得简单，只需要开一个16K的数组，把数据存到这16K中，最后再写入Flash即可。否则，在缓冲上面是要花一些功夫的。最基本的思路是用Flash的另外一个Block做缓冲空间。

    但这种方式会引发下列问题：1、速度；2、Flash的那个用来做缓存的块将比别的块使用频度大幅上升，磨损最严重，最先坏，这影响整个Flash的寿命。在实际处理中，引入了一系列的折中方案，比如，对Write命令所写的Block号进行判断，如果是整个的数据Block，则直接擦除原有内容，将数据写入。再如，对于非整个Block的数据进行缓冲，而对于整个Block的读写，不缓冲直接写入。再就是对于前面文件分配表、目录项所在的Block进行缓冲，等等。经过这些处理，可以尽可能地提高Write的速度。

[编辑 -  7/20/03 by  frank_wang]

多谢版主置顶！我一定再接再厉，把我的理解和体会都写出来，有不妥和不完整的地方，也请大家补充和讨论！

U盘固件编程之三:合理的USB通讯调试方法和思路是成功的关键

在介绍更多细节内容之前，我不得不谈谈我对USB调试方法的理解。

USB通讯过程是一个动态的过程，是不太好使用硬件仿真器来设断点调试的，因为每一次USB的传输过程，都有时效要求，等待时间过长，通讯过程也就中止了。但也不排除可以巧妙地使用断点仿真的方法进行调试。但个人认为，使用串口辅助编程过程，却是一种经济有效的方法。

所谓用串口辅助调试过程，也就是在固件代码中加入类似于Printf的语句，向串口输出一些信息。这些信息可以是几个字符（如A、B、C），或是某个变量或寄存器的值。程序运行到此处时，便会输出这些信息，借此，便可以知道：1、程序是否运行到此处；2、运行到此处时相应变量或寄存器值。这不就是硬件仿真调试的功能么？

如果想使用这种方式来调试，在硬件上必须增加一个RS232串口电平转换芯片，而且所使用的MCU得要有串口，并且，一般要自己编写Printf函数的实现方式。这个翻翻串口控制方面的书籍，很容易就可以搞定。

串口调试的方法，还可以推广到其他的单片机应用中，在简单系统中，它基本可以替代掉硬件仿真器，降低开发者的门槛和投资。

在USB通讯过程中，有两个阶段，一是通过端点0完成对设备的配置，在此阶段，把从USB端点得到的数据输出到串口，就对通讯所处的阶段一目了然了。一旦完成配置阶段，Bus Hound便可以粉墨登场了，因为此时，Bus Hound中已经可以看到设备了，看到设备后，便可以选择设备，对主机与此设备间的通讯数据进行分析和监视。

串口调试和Bus Hound这两种手段配合使用，可以使USB通讯过程的调试更加容易。比如，刚开始时，端点0的数据量本来就少，因此，使用串口调试比较方便。而对于Bulk端点的数据传送过程，再使用串口就不太方便了，因为数据量大，串口输出的数据太多，延时会比较严重，影响USB通讯过程，所以改用BUS HOUND来监视USB总线上的数据。这个时候很有趣的一件事情是，Bus Hound在PC机上，而串口实际上在单片机端。所以，利用这两种手段，里应外合，有助于我们确定一方发时另一方收的数据是否正确。比如，单片机上发出的一组数，将其输出到串口，然后看看Bus Hound上是否收到的是这些数，如果正确，则说明硬件通讯过程没有问题，如果不正确，则说明通讯的某一方有问题，进一步可以定位此问题，排除之。

正确的调试思路，将使调试过程事半功倍。

比如，在调试端点0 的配置过程时，可以先用Switch...Case语句建立对于端点0的数据的分支响应，对照标准请求的数据格式，可以得到什么情况下是Get Device Descriptor，什么时候是Get Configuration Descriptor，每个分支处理时对应一个函数，在这个函数里向串口标志信息。这个工作完成以后，便一个一个地来处理请求，处理完一个后，主机会自动进入下一个阶段，这时，通过串口可以看到相应的状态，按步就班地一个一个处理余下的请求，即可完成端点0的设备配置过程的固件程序的编写。

对于Bulk端点也是一样，先建立程序框架，然后再一个一个地处理请求。这种自上而下，逐步求精的思路并不稀奇，在USB调试过程中十分受用。最忌一上来就处理请求，不讲求结构，不讲求代码的条理性，最后可能弄得自己都是一头雾水。

思路很清晰，顶！

嗯....樘知滓樘知滓
著啦

也希望大家加入讨论，看看哪些问题是大家比较关心的，同时，我的理解当中，不妥的地方，也希望可以指出来。

补充建议：在能够使用BusHound之前，使用USBCheck工具，可以逐条、逐项、随意反复地调试端点0的各项数据和设置。感觉很方便。

SZZWM，可否贴一个USBCheck上来。

请教frank_wang大侠：我的PC（WIN2K）机上设备类型已经出现Mass Storage Device，但未出现盘符，这时HOST用ENDPOINT1_OUT向D12发出Inquiry 命令：
55 53 42 43 - c8 c0 5f 81  USBC.._.       272ms         6.1.0        
            24 00 00 00 - 80 00 06 12  $.......                     6.1.8        
            00 00 00 24 - 00 00 00 00  ...$....                     6.1.16      
            00 00 00 00 - 00 00 00     .......                      6.1.24      

共31B，D12的ENDPOINT1最大信息包是16B，我必须分两次接收，如果我想HOST用ENDPOINT2_OUT（最大信息包是64B）跟D12通信该如何设置？

[编辑 -  7/21/03 by  hewx]

[编辑 -  7/21/03 by  hewx]