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

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

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

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

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

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

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

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

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

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

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

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

U盘固件编程之四:玩转你的端点

　　接上面hewx，我来谈谈端点的问题。

　　前面提到过，端点是由USB设备端的接口芯片决定的。你选择了什么样的芯片，那么端点的配置情况属性就已经决定了，你只能使用将就这些特定的情况。这些端点的配置，具体要参考你所使用的接口芯片的芯片资料，比如说，端点0当然都为控制端点，其MaxPacketSize可能为8，16，32，64；端点1 可能是Bulk－In端点，2是Bulk－Out端点，其字长也有可能是8，16，32，64，但一般是64。其他端点可能有同步端点，或者同一端点既可被配置成同步传输方式，也可以工作在Bulk传输方式下，等等，不一而足。

　　USB协议精妙之处就在于枚举过程。主机最初发过来的包，一定是8个字符长的。所以，你的端点的MaxPacketSize至少必须是8，能满足与主机之间最基本的通讯过程。对于主机的第一个请求Get&nbspDevice&nbspDescriptor，你也只用回复8个字符就 OK 了，因为主机在第一次只对这8个字符感兴趣，在后面逐渐的获取描述符的过程中，主机逐渐得到设备使用那些端点，每个端点的最大字长（这些内容在 Endpoint&nbspDescriptor中，通过Configuration&nbspDescriptor提供）是多少，等等，总之，通过枚举，主机便知道你的端点的情况了，以后就会用这些端点来与设备进行通讯。

　　对于Hewx的问题，我想是你在Endpoint&nbspDescriptor中没有正确进行端点的设置，因为，如果进行了正确的端点配置，主机是会自动通过Bulk端点来发Inquiry命令的，而不会从你说的Endpoint1（16B）来发送这一信息。而且，主机会自动对要发送的信息进行分割，每次以不高于相应端点的MaxPacketSize长度来发送。

　　除了描述符中要给出正确的端点描述符的描述，有些时候在芯片中也需要设备相应的控制位，在决定你要使用哪些及如何使用这些端点，这个也得根据具体的芯片资料来设置。

U盘固件编程之四:玩转你的端点（增补）

　　对于某种设备来说，需要使用到的端点是固定的。比如说，Mass&nbspStorage设备吧，就只需要用到一个Bulk－In端点和一个 Bulk－Out端点。而不需要几个此类端点。至于到底需要几个端点，完全需要根据有关协议中的说明进行，描述符也据此进行提供，而不是没有根据地在描述符中提供许多端点。

　　至于哪些端点可以做何种方式来使用，这也要看接口芯片的资料，比如，很可能，有的端点只能用作同步方式，那你就不要勉强将其用作批量方式，控制端点就只能用作控制传输方式，就不能为同步方式......搞清楚这个概念，在固件编程中才好正确地提供描述符。

整个U盘所涉及的内容有如下一些：

• 控制传输和批量传输的传输过程
• Read和Write之前的命令响应
  
• 文件系统
  
• Read命令和WRite命令的响应
  
• 容量与格式化
  
• 速度问题
  
• 其他问题

　　先不忙说文件系统吧。我的思路是，接下来讲讲在做U盘的过程中常见的两种传输方式：控制传输和批量传输的事务处理过程。因为我们经常在处理控制端点的传输或Bulk端点的传输时，有些朋友常碰到“主机没有反应了”这样的问题，知道这两种传输方式的几个阶段，可以对传输过程更加了解，知道主机为什么会没有反应，是因为固件中没有正确响应，还是因为别的因素。

温馨提示：

　　百合电子工作室有一个关于USB开发方面的开源项目－Easy USB 51 Programer，整个开发过程写得非常详细，不防参考一下，您还可以进入她的论坛参与此项目的讨论。