最近由于项目需要，做了iPhone新的lighting接口的播放器开发，也稍微了解了一下MFI的整个认证流程。

iPhone5采用了最新的lighting接口，说是lighting，其实就是把usb接口的 DP DM 信号顺序重排一下，正反都可以插而已，其实也没什么特别的。

旧的Dock的播放器，一般都采用模拟+UART控制来实现播放。而新的接口，只有DP DM信号，也就是说只能采用USB通信，而且最可误的就是必须要有苹果的认证IC，经过认证后才能进行播放。

在音箱播放过程中，也和传统的USB音箱实现方法不同。传统的USB音箱，音箱是做为USB Speaker从机设备，电脑做为主机设备来进行播放。而苹果的播放，则是iPhone做为USB MIC从机，音箱做为主机来进行播放。这一点，和安卓的AOA协议有些类似。

因此，第一步，主要就是对苹果这个USB MIC设备的枚举，以及相关的采样控制等操作了。

然后再谈谈认证过程。

首先，我们需要一颗苹果的认证IC，一般是IIC的接口。从认证IC中读取版本信息等。

然后，对iPhone发送 StartIDPS 命令，同时获取 设备的 lingo（命令分组） 支持，通过 setfidtoken 告知苹果我们的版本信息等。再发送 EndIDPS。这样，第一步就完成了。

接下来，第二步，苹果发起 GetDevAuthenticationInfo 请求，我们需要从认证IC中读取Cert证书信息，通过命令RetDevAuthenticationInfo回给iPhone。

第三步，苹果确认证书后，发送GetDevAuthenticationSignature命令，同时会发送Challenge数据。我们将接收到的Challenge数据，写入认证IC的Challenge寄存器，等待计算完成后，从认证IC中读出Signature数据，通过RetDevAuthenticationSignature回应给iPhone。等待苹果确认后，就可以播放音乐了。

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的DP与DM状态。

RESET，DP、DM都拉低，并维持20MS以上。
SUSPEND，处于IDLE状态DP为高，DM为低，即连续三次没有等到SOF。
RESUME，DP为低、DM为高，并维持20MS以上。

在做USB的Host时，有几个地方需要注意：
1、在做插拔简测时，检测到DP没有上拉时间，判定设备掉线的时间一定要远远大于RESET的时间。因为在RESET的时候，DP可能拉低很长一段时间，会造成拔出误判；
2、在整个USB的枚举及通信过程，不要去随意修改DP、DM的上下拉电阻，可能会对设备制造一些RESUME误判等。
3、在检测到设备插入时，最好能第一时间对设备进行RESET。
4、在发送第一条命令之前，确认发送足够的SOF，以便部分芯片内部的初始化。
5、SCSI命令的超时时间，建议采取Windows的标准，也就是10s。

这个东西老是忘，在这里记录一下吧。

USB设备是DP上有1.5K的上拉，DM悬空。

USB主机是DP和DM上都有15K的下拉。

一个是1.5K，另一个是15K；

一个是上拉，另一个是下拉。嗯，记清楚了。