USB固件编程

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调试过程中十分受用。最忌一上来就处理请求，不讲求结构，不讲求代码的条理性，最后可能弄得自己都是一头雾水。