ISO14443A读卡流程(作为示例参考)

RFID相关通讯协议有很多种，我们这里要讲的是ISO/IEC14443A。

ISO/IEC14443A读卡流程我们可以从两个角度进行分析，一个是读卡器（PCD）,另一个是卡片（PICC）

上述是卡片状态变化图（参考《射频卡协议ISO14443》）

POWER OFF : 卡片缺少载波能量，简单的说卡片没有进入到天线发射的范围内。

在有足够多能量后，卡片就会进入到IDLE状态。

IDLE : 卡片处于空闲状态，可以识别从PCD而来的REQA以及WAKEUP指令。

在接收到REQA或者WAKEUP指令后，卡片就进入到READY State。
READY:卡片处于就绪状态，就可以读取对应的UID了，但如果此时有多张卡片同时在射频场中，就可能发生冲突。这里采用的防冲突算法是基于位冲突检测协议，简单的说就是看冲突发生在哪一位，在从下位开始继续获取UID，直至获取完整的UID，可以通过下面的一个实例进行分析。
事先得到1卡片 EF 30 E2 84 2卡片 EF DB 8E 6F ，可以发现在第2字节第0bit两个卡片的UID开始不同，那么碰撞必然会发生，看看是不是这样。

这里我们用的就是4个字节uid的卡片，所以SEL = 0x93,在第一次发送防冲突时，NVB = 0x20 ，总共就2个有效字节（SEL+NVB），因为我们并不知道UID 。

                   SEL   NVB

发送报文        93       20     

收到报文       EF   读RC663寄存器，得到发生冲突的位置第2个字节 第0bit。

那么既然找到冲突位置了，那么我们就重新发送防冲突报文 SEL还是0x93，NVB 中完整字节数：（SEL+NVB+第一字节UID(EF)），NVB中的bit数（发送冲突位置在第2字节第0bit，所以有效位数是1（希望收到的是碰撞bit后的uid））
报文

                           SEL  NVB   UID0   UID1
发送报文：          93     31      EF       00

收到报文             30     E2        84      B9    收到4个字节 ，最后一个字节是完整UID的BCC校验

发送这个报文之后，2卡片因为收到的报文与自身UID不匹配，不会回复，所以得到的回复就只有一个，那就是1卡片后半部的UID，然后与前半部的UID合并起来就是完整的UID即（EF 30 E2 84 ）。

    如果读卡器里有多张卡，可能会有多次冲突，但是方法和上述步骤一样，直到收到完整的UID为止。

ACTIVE: 读取到完整UID后，发送SELECT指令就能进入到激活状态，在这个状态下，才能进行M1的操作，查看一下SELECT的实例：

                            SEL  NVB   UID0   UID1  UID2  UID3 BCC
发送报文：          93     70      EF       30       E2      84      B9    

收到报文              28

实际上就跟获取卡号的报文是一样的，只是此时已经知道完整的UID，就把完整的UID添加到发送报文，就是SELECT。

通过HALT指令，可以让卡片从ACTIVE状态转化到HALT状态。HALT指令的实例：

发送报文： 0x50 0x00

如果定时器超时了说明HALT成功了。

HALT: 不会响应除了WAKEUP以外的指令，（这样就可以读下一张卡的卡号）。

这样其实也就能知道读卡器大概是怎么个流程，直接上图：

概括一下就是，打开射频场-----发送REQA/WAKEUP，使得所有卡片进入READY状态------获取UID（防冲突）-------获取到一个完整的UID----------发送SELECT，使这张卡片进入ACTIVE状态-------------发送Halt指令，使这张卡片进入HALT状态，就不会响应除了WAKEUP外的其他指令----------发送REQA，使其他的所有卡片重新进入READY状态（HALT的卡片不会），如果没有卡片响应就结束了，否则继续获取UID，这里就是循环操作了，直至所有卡片的卡号都读取出来。

自己测试了一下，最多可以同时支持9张卡，多余的卡片就感应不到了。