可读可写可加密RFIDEM4450兼容EM4100实现总结

首先请上我们的主角EM4450 --1K的可读可写无线识别设备,也就可读可写的RFID码片。1K的地址空间被组织成32个word(32bits)，具体分布如下图：

随后我们来看看具体的操作：

由上图可知在对4450在采集端的EM4095对它进行无线供电复位后，初始化进入标准读模式(根据控制字像外发送数据)，在发送数据的同时还要检测RM请求标志，如果从EM4095端收到RM请求则4450进入命令操作模式，等待随后4095对它下达的指令，然后执行相应的操作，当执行完指定的指令操作后恢复到标准读模式继续下一次的操作；具体的指令操作有如上几种：

Login:登录命令：用户必须用正确的密码登录才能执行需要密码确认的相关操作如写功能，一次登录后只要4450不被软件复位或者上电复位，需要密码验证的操作都可有效，无需多次登录；

Writeword写字命令：在指定地址的情况下往4450写入数据（需注意地址字节的格式）：

WritePassword修改密码命令：主要用于修改密码，初始密码为00000000，实际使用密码根据不同的应用设置；

SelectiveRead选择读命令：区别于标准读的一种读模式，可以读取指定地址的数据；

Reset复位命令：软件复位功能，需要密码验证的操作在复位后需要重新操作；

从以上的不同操作中我们可以得出一个共同的特点，都是每一条指令执行都是一个完整的过程，而且在收到命令后只执行一次后恢复到标准读模式，过时不候，这就需要我们在如何判断每一个状态的正确上来处理一个命令的操作过程，操作过程都大同小异，只要能够正确的处理完成其中的一条命令，同理即可得其它。 以下选取其中操作过程相对较麻烦的写密码命令进行分析；

         根据如下所示 LIW  NAK  ACK的状态波形，及EM4095端编码数据波形，以及4450发出的的数据位波形，我们可以得出解决方案：

RF标准频率为125KHz， T=8us

数据编码方式为双相编码方式（1全周期为高；0 先低后高，实际带宽需要调整，硬件不同导致不同）；

 

EM4450端真实的数据格式以曼彻斯特编码方式编码，具体编码方式如上图：

由以上波形图可得：需要使用CPU定时器的输入捕获及输出比较定时功能，时间为1us，此次驱动在str710上实现，使用定时器1，有两个通道，分别都有输入捕获和输出比较功能，一个定时器足矣！ 在使用输出比较定时是（STR710中断处理存在50us的延时 无法避免，软件中断选址所耗，软件上要校正。PS：针对此问题让自己怀疑代码是不是写错了 纠结了一天的时间）；在确定了实现的方式之后接下来就是具体的方案处理；        

  方案一：将所有数据线全部接受，建立大缓冲区，随后分析： 不可行，无法判断数据的准确性，针对不同的状态值不好处理，针对来回多次交互的数据在缓冲区中处理更是会让你痛不欲生。果断放弃；

  方案二：将每一条命令的操作假想成一条原子操作，每一个状态出现错误都直接退出当前命令的操作，并返回错误码， 方案可行，但此方案的问题在于要将LIW  ACK  NAK单独判断出来，根据波形 我们知道这是可行的，将状态和数据位分开处理，根据波形和时间处理是否来得及，经过分析，也是可行的，按照此方案实施，部分参考官方基于Atmel128的demo实现（不得不说，这个demo写的还是挺好的，至少思想能让人一目了然），基于方案二，我们就需要对每一段的操作是否能按时完成需要做判断，毕竟每个状态和数据只有一次，为此启用710的TIM2 硬件定时器做状态值间是否操作完成的超时定时器处理（每个状态时间有几十微妙到几千微妙不等，必须用硬件定时器才能实现）；定时器的具体使用方案是在每个状态或数据处理前启动定时器（不同的数据和状态超时时间不同），在收到正确的状态或定时时间到（超时错误）时关掉定时器；由此我们可以得出操作的数据结构：

中断函数采用函数指针，针对不同的操作调用不同的中断函数，避免中断函数的臃肿导致程序可读性降低及给日后维护带来不必要的麻烦

在完成底层驱动的实现之后，由于一直以来使用的码片是EM4100，一款只读的RFID码片，一上电就发送RFID码值信息，不需要数据间的交互，而且相对4450价格便宜很多，现在做兼容那是必然的了；接下来面临的问题就是如何自动识别EM4100和EM4450并且向应用成发送RFID码值，这就需要做一个RFID采码中间层任务来处理以上流程，具体实现的几个关键点如下所示：

1.       向应用层抽象RFID码值的信息，统一RFID数据信息

2．自动识别码片，更具EM4450  LIW，和EM4100 数据头（9个1）来进行判断，但此处遇到一个问题，因为是根据带宽来判断，4450的数据位会出现4100数据头9个1的情况；对此需要对确保能有一个完整数据波形中都判断LIW 和数据头，然后判断他们出现的次数能更加准确的判断卡的类型，经验证 OK；

3.由于硬件修改RFID采码部分电源，改变输入纹波的问题，需要增加定时器判断RFID卡是否在线，不在线则发送0码值，或在采码过程中数据信息效验错误也发送0码值，对于4450 有着严格的ACK确认及奇偶效验，数据是不会出现错误的，采码只需要读取一次，随后查询LIW判断是否在线，在线则发送第一次读取码值，不在线则发送0 码值；

4.针对发送的码值，发送到应用层之前要先判断前后两次的码值与上一次发送的码值不一样才发送，否则不发送；（以前针对4100是3次判断），此处验证2次也不会出现什么问题；

5..具体的中间层处理原先是用任务管理实现的，后来发现用定时器也能直接实现，就直接使用定时器了，注意定时器的时间要确保兼容两种码片操作一次所需要的时间大50ms左右留有足够的余量；

总结经验与教训：

1.      首先应该明确EM4450和EM4100两种码片工作模式上的不同；

EM4450工作模式：

EM4450需要根据不同的操作命令执行不同的操作。每一个操作命令执行之前需要读卡器与码片之间通过RM同步，然后接收命令，接收到命令后每一个对应的操作只执行一次又回到标准读状态，这就需要我们在这一次的操作中如何保证操作流程正确执行，需要状态检测与超时机制保证。

EM4100工作模式：在磁场对它供电后，持续以曼彻斯特编码方式持续的发送自身码值的信息等待读卡器识别。

2.      其次由于钥匙端EM4095读卡器端的采码频率要兼容以往公司的EM4100码片，采码频率不能达到标准的125KHZ，因此读码片数据时的端曼彻斯特解码与写码片时的双相编码要根据不同的频率调试出合适的带宽值，因为同样的硬件会存在微小差异，因此要给出带宽的容错范围；

3.      对于应用层对采码接口的调用，应用只需调用一个接口即可，不关心是什么码片。底层应该封装EM4100和EM4450两种不同的码片，并自动识别不同的码片，然后执行各自流程对码片操作。对应用层提供同一个数据结构，目前暂定数据结构如下，底层通过系统消息将数据信息发送到应用层，应用层根据数据信息即可得出码片类型并执行对应的操作：

                                                    

类型1（1字节）

类型2（1字节）

RFID数据（4字节）

操作数据1（4字节）

操作数据2（4字节）

 

说明：

       类型1：说明卡片的类型，0x00表示EM4100，0x01表示Em4450，此类型值由软件添加；

        类型2：如果类型1为0x00，类型2表示产品ID，由厂家固定生成；如果类型1为0x01,则类型2的值作为子类型定义，0x03表示EM4450,此类型值由软件添加；

        RFID数据：此处表示RFID码片数据，为厂家出厂时设置的全球唯一标识码；

        操作数据1：如果是EM4100码片，此字段不用，默认为0；如果是EM4450码片；

        操作数据2：如果是EM4100码片，此字段不用，默认为0；如果是EM4450码片；

4.      对于底层处理EM4450和EM4100码片的自动识别，通过各自波形上的差异进行识别。EM4100根据同步头9个1识别，EM4450根据同步侦听窗口LIW识别，同时还要考虑4450的数据位中可能存在9个1的情况而引起的识别错误。

5. 执行写操作时多次写入，只要有其中一次成功就退出写操作返回操作状态，没有继续执行直到写次数(目前通过宏定义为5)为止，最后返回操作状态，此法可用于对能量不稳定引起的单次写失败。

教训：

1.  在使用定时器时发现并验证STR710定时器中断处理存在50us的延时，无法避免，软件中断选址所耗，程序开发时软件上需要校正。

2.  由于读卡器端采码频率并非手册规定的标准值，考虑兼容和对4450支持，需要调试带宽和容错范围，并以宏定义。

3. 对于读卡器端更换电源解决采码时的纹波问题，程序实现时需要对EM4100超时处理和EM4450的在线判断。

4. 对于EM4450，读写操作所需要的能量由电磁感应产生，且写操作所需的能量大于读，因此可能会出现在写操作过程中等待写入内存时的最后一个ACK确认收不到，实际上数据已经写入。因此在程序处理时要对该ACK进行处理，防止在操作中下一步操作无法进行；

至此，打完手工，EM4450兼容4100的RFID采码方案实现的原理就如上所示了，由于才疏学浅表达上和逻辑上可能有些混乱，望请自己见谅。