USB 的DataToggle

USB 的DataToggle  

USB在通信过程中，有DataToggle这么一个概念。

例如，在一次通信中，主机如果需要接收一个数据包，那么，主机会先发送一个IN的令牌包，然后从机发送数据包，然后主机再发送ACK握手包进行确认，这就完成了一次数据的接收。

假如出现通信错误，掉包的情况，那么又如何处理呢？

第一步，假如是令牌包IN发生了通信错误，那么主机则不会发送数据包。主机可以再次发送令牌包IN来让从机发送数据包。

第二步，假如是数据包发生了错误，那么主机收不到数据，则不会发出ACK信号，而再次发送IN；而从机由于没有收到ACK，则得知数据包出错，可以再次发送该数据包。

现在问题来了，假如是ACK信号出错，主机已经成功接收到数据，认为通信完成。由于从机并没有接收到ACK信号，还认为数据出错，继续准备上一包数据，此时岂不是要不同步了？

这个时候，DataToggle就派上用场了。DataToggle要求数据包前加DATA0和DATA1标识，并且要求每成功完成一次通信后，对DATA标识进行切换，这样，主机在下一次的IN包中，就可能通过DATA的标识来判断从机是否成功地完成上一次数据通信了。

DataToggle在USB Reset阶段是要清为0的，而今天就发现了一个错误，不幸在GetMaxLun和ClassReset这两条命令中对DataToggle进行了清零操作，造成了USB的通信过程中，发送这两条命令则有可能通信失败。

特记录一下：在A1 FE和21 FF这两条类命令中，是不需要对Bulk的DataToggle进行清零操作的。

因为USB构架对错误的校正是非常严谨的。就如前面所提的，ACK握手是给主机一个信号：外围器件正确 的接收到了主机所发送的数据。但是握手数据包自身会不会在传输中被混淆呢？为了能够检测这个错误 ，主机和外围设备两边都各自维护一个与数据包传输相关的校验位，当数据到达目的地时，内部校验位 就会与DATA0或者DATA1来进行比较。当主机或者外围设备发送数据时，它们交互的发送DATA0和DATA1。 主机和外围设备就可以通过对数据PID与内部校验位状态的比较来确定错误的握手数据包。
   综上得出一个结论：ACK信号只是在收到DATA0或DATA1数据包后的一个回应，如果DATA0或者DATA1无法 到达目标自然目标就认为不存在这次数据传输，这样容易产生书籍。因此通过DATA0和DATA1的交替传输 ，如果检测到两个DATA0或者两个DATA1那么就表明数据包传输错误或者被遗漏。