RC522 i PN532 RFID bàsics: 10 passos

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:14

NOTA: Ara tinc instruccions que ofereixen codi Arduino per a RC522 i PN532.

Fa un temps vaig comprar tres mòduls RFID diferents per experimentar. En un projecte anterior, vaig detallar com utilitzar un mòdul senzill de 125 kHz per fer una funció bàsica de seguretat. Mòduls com aquest utilitzen etiquetes de només lectura, de manera que el procés busca els identificadors, emmagatzema-ho si es desitja i es compara amb els identificadors emmagatzemats. La resta de mòduls que he comprat funcionen a 13,56 MHz i fan servir etiquetes que es poden llegir i escriure, de manera que és una pèrdua simplement utilitzar-los per seguretat bàsica. Els dos mòduls comuns utilitzen el xip RC522 o el xip PN532, tots dos fabricats per NXP.

Si heu llegit algun dels meus altres projectes, ja sabeu que m’agrada fer servir microcontroladors i programes PIC econòmics en llenguatge ensamblador. Per tant, el que buscava era una seqüència de passos necessaris per parlar amb els mòduls i amb les etiquetes RFID. Tot i que hi ha molts exemples de programes en línia per als mòduls, la majoria s’escriuen en programari ‘C’ per a l’Arduino i utilitzen la interfície SPI. A més, els manuals dels xips i de les etiquetes Mifare requereixen una mica de desxifratge. Aquest post tracta principalment de la informació que m’agradaria tenir quan vaig començar el projecte. També incloc programes de programari de muntatge PIC per realitzar les ordres bàsiques requerides per cada mòdul. Fins i tot si no feu servir un llenguatge PIC ni un llenguatge d’ensamblatge, el codi font, com a mínim, us ha de proporcionar una bona idea de les ordres específiques necessàries per realitzar cada pas.

Pas 1: interfícies en sèrie

Tots dos xips que s’utilitzen en aquests mòduls són capaços de connectar-se mitjançant SPI, I2C o UART (HSSP). El mòdul PN532 té un commutador DIP que s’utilitza per seleccionar la interfície desitjada, però el mòdul MFRC522 està connectat per a la interfície SPI. Prefereixo fer servir el UART integrat del PIC, de manera que vaig buscar en línia per veure si hi havia una manera d’incloure el mòdul MFRC522 al mode UART. El que vaig trobar va ser que tallar una traça al tauler seria el truc. El tall elimina efectivament 3,3 volts del pas EA del xip. Tècnicament, el pin EA hauria d’estar connectat a terra, però poca gent pot treure aquesta fita de soldadura donada la densitat del pin xip. No us preocupeu, però, perquè el pin EA no té cap arrencada interna i no "flota" com tenen les antigues entrades lògiques TTL. Consulteu el diagrama de xips i la imatge de la secció del tauler per obtenir el punt a tallar. Assegureu-vos que només heu tallat el traç curt que va directament al pas EA.

Pas 2: maquinari

Les connexions de maquinari per a les comunicacions UART es mostren al diagrama anterior. Les connexions UART del MFRC522 no estan marcades a la placa, però, tal com es mostra a l’esquema, el pin SDA rep dades UART i el pin MISO transmet dades UART. El mòdul PN532 té les marques UART a la part inferior del tauler.

Tots dos mòduls funcionen a 3,3 volts i el nivell lògic de 5 volts del pin PIC TX també ha de ser limitat. La connexió LCD és la configuració estàndard de 4 bits que he utilitzat en alguns dels meus projectes anteriors. El format per defecte de tots els missatges es defineix per a la pantalla LCD estàndard 1602 (16 caràcters per 2 línies). També tinc una pantalla LCD de 40 caràcters per 2 línies que faig servir per a bolcades de dades brutes durant la depuració, de manera que he inclòs una definició al programari que em permet aprofitar l'espai de visualització addicional.

Pas 3: blocs de dades

Les etiquetes Mifare Classic 1k que s’utilitzen per a aquest projecte es configuren en 16 sectors, quatre blocs de dades per sector, 16 bytes per bloc de dades. Dels 64 blocs de dades, només 47 són realment utilitzables. El bloc de dades 0 conté dades del fabricant i els blocs 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 i 63 s’anomenen blocs de remolc. Els blocs Trailer són els darrers de cada sector i contenen dues claus i els bits d'accés al bloc. Les claus i els bits d'accés al bloc s'apliquen només als blocs de dades d'aquest sector, de manera que podríeu tenir claus i regles d'accés diferents per a cada sector. Les tecles predeterminades es defineixen en "FF FF FF FF FFh". Per a aquest projecte bàsic només faig servir un bloc de dades i conservo les claus i els bits d'accés per defecte. Hi ha molts documents relacionats amb aquestes targetes, així que només cal que cerqueu "Mifare" en línia o visiteu el lloc web de NXP si voleu explorar-los amb més profunditat.

Pas 4: operació general

Tot i que els dos mòduls són únics per la manera d’accedir-hi i per accedir a les etiquetes, hi ha un procés general que es requereix per fer la feina. Per a aquest projecte suposem que les etiquetes són del tipus Mifare Classic 1k i que només permetem una etiqueta a la vegada al camp de l'antena. Els passos bàsics es defineixen a continuació.

· Inicialitzar el mòdul: en general, això requereix coses com escriure valors als registres del xip, enviar comandes de "despertar" i encendre l'antena. En una aplicació amb bateria, voldríeu poder encendre i apagar l’antena per estalviar la bateria, però per a aquesta aplicació senzilla l’encenem una vegada i després la deixem.

· Esborreu el senyal de xifratge (només 522): quan s'identifica una etiqueta, es marca un senyalador per fer saber a l'usuari que les comunicacions amb l'etiqueta es xifraran. Aquest indicador ha de ser esborrat per l'usuari abans de la següent exploració, fins i tot si l'etiqueta que s'està escanejant és la mateixa.

· Busqueu una etiqueta: el mòdul bàsicament pregunta "Hi ha algú per aquí?" i l'etiqueta respon "Estic aquí". Si el mòdul no rep una resposta ràpida, deixa d’escoltar-lo. Això vol dir que hem d’enviar repetidament ordres d’escaneig al mòdul fins que trobi una etiqueta.

· Obteniu l'etiqueta Número d'identificació d'usuari (UID): l'etiqueta respondrà a la sol·licitud d'escaneig amb informació limitada, com ara el tipus d'etiqueta que es tracta. Això vol dir que potser haurem d’enviar una altra ordre per obtenir el seu UID. L'UID és de quatre bytes per a les etiquetes Mifare Classic 1k. Si pot ser més llarg per a altres etiquetes, però aquest projecte no les aborda.

· Seleccioneu l'etiqueta (només 522): l'UID s'utilitza per seleccionar l'etiqueta que l'usuari vol autenticar per llegir i escriure. Això es basa en la possibilitat que hi hagi més d’una etiqueta al camp de l’antena. Aquest no és el cas de la nostra aplicació senzilla, però hem de seleccionar l'etiqueta de totes maneres.

· Autenticar l’etiqueta: aquest pas és obligatori si volem fer una lectura o escriptura de l’etiqueta. Si tot el que volem fer és diferenciar entre etiquetes per a una aplicació de seguretat senzilla, el UID és suficient. L’autenticació requereix que coneguem l’UID i que coneguem la clau de criptografia del sector de dades de l’etiqueta a la qual volem accedir. Per a aquest projecte ens quedem amb les tecles predeterminades, però el meu projecte de seguiment canvia les tecles perquè l'etiqueta es pugui utilitzar com a cartera electrònica.

· Llegiu o escriviu l'etiqueta: les lectures sempre retornen els 16 bytes del bloc de dades sol·licitat. Les escriptures requereixen que els 16 bytes s’escriguin alhora. Si voleu llegir o escriure un altre bloc al mateix sector de dades, l'etiqueta no ha de tornar a ser autenticada. Si voleu llegir o escriure un bloc en un sector de dades diferent, l'etiqueta s'ha de tornar a autenticar mitjançant la clau d'aquest sector.

Pas 5: Seqüència d'accés al mòdul MFRC522

La rutina d'inici inclou aquests passos bàsics que es troben a la majoria de les aplicacions que he vist:

· Envia un byte de dades fictícies (vegeu el paràgraf següent)

· Restabliment suau

· Estableix el guany del receptor de RF (si es vol alguna cosa diferent del predeterminat)

· Estableix el percentatge de modulació ASK al 100%

· Estableix el valor de llavor per als càlculs de CRC

· Enceneu l'antena

· Obteniu la versió del firmware (no obligatòria)

Per alguna raó inexplicable, el meu mòdul s'encén i creu que ha rebut una ordre d'escriptura sense el byte de dades. No sé si això és només un problema amb el meu mòdul, però no n'he vist cap referència en cap altre lloc. He experimentat amb restabliments de maquinari i programari i cap dels dos ha solucionat el problema. La meva solució era afegir una trucada de lectura fictícia per registrar "0" (sense definir) al començament de la rutina d'inicialització del mòdul. Si el mòdul veu això com a dades de l’ordre d’escriptura desconeguda, no sembla que hi hagi cap efecte negatiu. Si ho veu com una ordre de lectura, no passa res útil. Em molesta que no pugui definir completament el problema, sobretot tenint en compte que un restabliment de maquinari només del mòdul no soluciona el problema.

El xip RC522 està compost per diversos registres, la majoria dels quals són de lectura i escriptura. Per realitzar una escriptura, el número de registre s'envia al mòdul seguit del valor per escriure. Per realitzar una lectura, el número de registre té 0x80 afegit i s’envia al mòdul. La resposta a una ordre d’escriptura és un ressò del registre al qual s’accedeix. La resposta a una ordre de lectura és el contingut del registre. El programari aprofita aquests coneixements per verificar que l'ordre s'ha executat correctament.

Pas 6: Seqüència d'accés al mòdul PN532

La rutina d'inici inclou aquests passos obligatoris:

· Enviar una cadena d'inicialització: és específica de la interfície UART. El manual indica que la interfície UART es despertarà a la cinquena vora ascendent detectada a la interfície. Es recomana enviar 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. En la seva major part, només cal que hi hagi un nombre suficient de caràcters amb arestes ascendents i que no hagin de semblar un preàmbul d'ordres (00 00 FF).

· Despertar el mòdul: enterrat al manual de l'usuari mostra que el mòdul s'inicialitza en una mena d'estat de son anomenat "LowVbat". Per sortir d’aquest estat hem d’enviar una ordre “SAMConfiguration”.

El PN532 espera que s'enviïn ordres en un format de missatge definit que inclogui un preàmbul, el missatge i un postamble. Els missatges de resposta segueixen el mateix format. Els missatges d'ordre i de resposta inclouen un TFI (Frame Identifier) i una versió d'ordres. L'ordre utilitza un TFI de 0xD4 i la resposta utilitza 0xD5. Les versions de l'ordre varien, però la resposta sempre incrementarà la versió de l'ordre i la retornarà al byte següent al TFI. Aquesta consistència permet escanejar fàcilment els missatges de resposta per obtenir la informació rellevant.

Cada missatge d’ordre (seguint el preàmbul) consisteix en la longitud del missatge, el complement de 2 de la longitud del missatge, TFI, ordre, dades, suma de comprovació i postamble. El programari crea les ordres individuals i després crida a una rutina que calcula la suma de control i afegeix el postamble.

El format del missatge per a la resposta és similar al de l'ordre. Una resposta típica inclourà un ACK (00 00 FF 00 FF 00) seguit de la resposta específica a l'ordre. Cada resposta de l'ordre comença amb un preàmbul de 00 00 FF. La resposta també hauria de tenir un byte TFI de D5 seguit del número d'ordre incrementat per 1. Per a la nostra comanda "SAMConfiguration" (14) que seria 15. L'ordre "SAMConfiguration" obté aquesta resposta: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Hi ha altres ordres específiques del mòdul que es poden enviar, però no són necessàries per a aquesta aplicació. Tanmateix, he inclòs una rutina que es pot trucar per recuperar el número de versió del firmware. Una resposta típica (després de l'ACK i el preàmbul) seria: 06 FA D5 03 32 01 06 07 E8 00. El "01 06 07" indica el número de versió del firmware 1.6.7.

Pas 7: Seqüència d'accés a l'etiqueta

Un cop preparat el mòdul, podem enviar ordres específiques per a les etiquetes. Per llegir o escriure dades d’etiquetes, hem de tenir el seu número d’identificació (UID). A continuació, s'utilitzarà l'UID i la clau per autoritzar un sector de dades d'etiquetes específic per a les lectures / escriptures. Les lectures / escriptures de dades d’etiquetes es fan sempre als 16 bytes d’un bloc de dades especificat. Això vol dir que l'aplicació típica llegirà el bloc de dades, modificarà les dades com vulgueu i, a continuació, tornarà a escriure les dades noves a l'etiqueta.

Pas 8: programari

El programari de control d’interrupcions es crida cada vegada que el PIC UART rep un byte de dades. En alguns dels meus anteriors projectes UART, vaig poder enquestar la marca d'interrupció RX en lloc d'haver d'utilitzar un controlador d'interrupcions. Aquest no és el cas d'aquest programari, especialment per al PN532 que comunica a una velocitat de transmissió molt més alta que l'RC522. La interfície UART del RC522 està limitada a 9600 baud, mentre que el valor per defecte del PN532 és 115k i es pot configurar fins a 1.288M baud. Els bytes rebuts s’emmagatzemen en una àrea de memòria intermèdia i la part principal del programari els recupera segons sigui necessari.

El senyalador New_Msg indica que s'han rebut bytes i Byte_Count indica quants. He inclòs una rutina "Disp_Buff" al programari que es pot trucar per mostrar el contingut de la memòria intermèdia de recepció durant la depuració. Alguns dels missatges de retorn desbordaran una pantalla típica de 1602, però tinc una pantalla LCD de 40 caràcters per 2 línies que he trobat en un lloc electrònic en excés. La definició "Max_Line" es pot configurar per a la mida de la pantalla LCD. Si s'arriba a "Max_Line", la rutina "Disp_Buff" continua escrivint a la segona línia. Podeu afegir un petit codi a aquesta rutina per continuar a les línies tres i quatre si teniu un LCD de 4 línies. Per al PN532 hi ha un indicador que es pot configurar perquè la rutina aboqui tots els bytes rebuts o simplement aboqui els 16 bytes de dades d'una resposta de lectura.

No cal esborrar la memòria intermèdia de recepció o Byte_Count, ja que si esborreu el senyalador New_Msg, el controlador d’interrupcions farà que Byte_Count s’esborri i això és el que s’utilitza com a índex a la memòria intermèdia. New_Msg normalment s’esborra abans de cada pas de l’ordre, de manera que els resultats específics d’aquesta ordre es poden localitzar i verificar fàcilment. Al RC522 això significa que la memòria intermèdia de recepció sol tenir només 1 a 4 bytes. En alguns casos, com ara lectures de blocs de dades, l'ordre Read_FIFO s'ha d'emetre diverses vegades per tal de moure els bytes del FIFO al buffer de recepció. Tots els resultats de l'ordre del PN532 acaben al buffer de recepció, de manera que es realitza un procediment d'escaneig per localitzar els bytes específics necessaris.

El bucle principal del programari busca una etiqueta i, a continuació, autentica l'etiqueta per a les lectures / escriptures. Per al programari de prova inclòs aquí, la variable Junk_Num es modifica cada vegada a través del bucle principal i s'utilitza durant l'escriptura a l'etiqueta. Els valors escrits s’alternen entre el valor de Junk_Num i el complement de 1 de Junk_Num. Finalment, es llegeixen i es mostren els 16 valors escrits. Hi ha missatges de visualització per a cada pas amb retard de les trucades rutinàries per permetre temps per llegir cada missatge. També es proporcionen missatges d’error, però normalment només s’han de produir si l’etiqueta s’elimina durant una operació.

Part de la inicialització del programari és una secció de codi que només s’executa en engegar-se i que s’omet si es detecta un restabliment del programari. Els missatges d'error generalment finalitzen amb un restabliment de programari com a forma de sortir del bucle principal. El restabliment es produeix a la rutina "Tilt", que simplement habilita el temporitzador Watchdog i després entra en un bucle infinit esperant el temps d'espera.

Pas 9: programari únic MFRC522

El xip RC522 requereix més instruccions de baix nivell que el xip PN532 per aconseguir comunicacions amb etiquetes. És una mica com programar en llenguatge assemblador versus programar en "C". Una altra diferència significativa és que el RC522 requereix que les comunicacions amb l'etiqueta es canalitzin a través d'un buffer FIFO. Les rutines "Write_FIFO" i "Read_FIFO" gestionen aquestes tasques. El programari MFRC522 inclou una secció per a moltes de les ordres de nivell inferior a partir de les quals es construeixen les funcions principals.

El càlcul de la suma de comprovació d’ordres d’etiquetes per al RC522 és molt diferent al del PN532. Després d'incloure l'ordre tag al FIFO, s'envia una ordre de mòdul per calcular la suma de comprovació. El resultat de 16 bits no s’afegeix automàticament a l’ordre tag, sinó que es pot llegir des de dos registres de 8 bits. El càlcul de la suma de comprovació elimina les dades del FIFO, de manera que la seqüència necessària és la següent:

· Construïu l'ordre al FIFO

· Ordenar un càlcul de suma de comprovació

· Torneu a crear l'ordre al FIFO

· Llegiu els registres CRC i escriviu els bytes de suma de comprovació al FIFO

· Envieu una ordre Transceive o Authenticate

L'ordre Transceive transmetrà el buffer FIFO i després canviarà automàticament al mode de recepció per esperar la resposta de l'etiqueta. L'ordre Transceive ha d'anar seguit de la configuració del bit StartSend al BitFramingRegister per transmetre les dades realment. L'ordre Authenticate no té aquest requisit.

En general, les aplicacions de codi "C" Arduino disponibles en línia utilitzen els registres de bandera d'interrupció i el registre de temps d'espera per assegurar-se que la resposta correcta es rep de manera oportuna. Al meu parer, això és excessiu per a aquesta aplicació crítica que no és temporal. En lloc d’això, faig servir els temps d’espera curts del programari per esperar la resposta i després comprovar que sigui correcta. El manual de les etiquetes Mifare detalla el temps per a les diverses transaccions i també es permet el temps per rebre el nombre esperat de bytes. Aquests retards s’incorporen a la majoria de subrutines d’ordres de baix nivell.

Pas 10: programari únic PN532

Després d'inicialitzar el mòdul, es realitzen els passos necessaris per trobar i autenticar l'etiqueta escrivint l'ordre adequat seguit de les dades necessàries. L'ordre scan torna l'UID que s'utilitza per a l'autenticació. Després, les lectures i escriptures de l’etiqueta envien o retornen els 16 bytes del bloc de dades adreçat.

La seqüència d'inicialització es va detallar anteriorment i la mateixa rutina de programari també envia l'ordre SAMConfiguration per treure el mòdul de l'estat "LowVbat". La resta d’ordres bàsiques, com ara Escanejar, Autenticar, Llegir / Escriure etiqueta, s’acaben de construir de manera seqüencial a les rutines aplicables. La suma de comprovació es calcula només sumant els bytes de l’ordre, fent un complement i, a continuació, afegint 1 per convertir-lo en un complement de 2. El resultat de 8 bits s’afegeix a la cadena d’ordres just abans del postamble.

No hi ha FIFO com al RC522, de manera que els missatges de resposta complets es reben automàticament. La rutina "Find_Response" escaneja el buffer de dades de recepció del TFI (0xD5). La rutina aprofita el coneixement dels missatges esperats i ignora les respostes ACK simples que no inclouen dades. Un cop trobat el TFI, les respostes desitjades en són una compensació coneguda. La rutina "Read_Buff" desa els bytes de ressò i estat de les ordres per verificar-los posteriorment.

Això és tot per a aquesta publicació. Consulteu els meus altres projectes electrònics a: www.boomerrules.wordpress.com