RC522 og PN532 Grundlæggende RFID: 10 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

BEMÆRK: Jeg har nu Instructables, der tilbyder Arduino -kode til RC522 og PN532.

For noget tid siden købte jeg tre forskellige RFID -moduler til eksperimentering. I et tidligere projekt forklarede jeg, hvordan man bruger et simpelt 125 kHz-modul til at udføre en grundlæggende sikkerhedsfunktion. Moduler som den bruger skrivebeskyttede tags, så processen scanner efter id'et, gemmer om ønsket og sammenligner med lagrede ID'er. De andre moduler, jeg købte, fungerer ved 13,56-MHz og bruger tags, der både kan læses og skrives, så det er lidt spild bare at bruge dem til grundlæggende sikkerhed. De to fælles moduler bruger enten RC522 -chippen eller PN532 -chippen - begge lavet af NXP.

Hvis du har læst nogle af mine andre projekter, ved du, at jeg godt kan lide at bruge billige PIC -mikrokontrollere og programmere på samlingssprog. Så det jeg ledte efter var en række trin, der var nødvendige for at tale med modulerne og til RFID -tags. Selvom der er masser af eksempler på programmer online til modulerne, er de fleste af dem skrevet i ‘C’ software til Arduino og bruger SPI -grænsefladen. Også manualerne til chipsene og til Mifare -tags tager lidt af dechifrering. Dette indlæg handler primært om de oplysninger, jeg ville ønske, jeg havde, da jeg startede projektet. Jeg inkluderer også PIC -samlingssoftwareprogrammer til udførelse af de grundlæggende kommandoer, der kræves af hvert modul. Selvom du ikke bruger en PIC og/eller samlingssprog, bør kildekoden i det mindste give dig en god ide om de specifikke kommandoer, der kræves for at udføre hvert trin.

Trin 1: Serielle grænseflader

Begge de chips, der bruges på disse moduler, kan kommunikere via SPI, I2C eller UART (HSSP). PN532 -modulet har en DIP -switch, der bruges til at vælge det ønskede interface, men MFRC522 -modulet er hardwired til SPI -interface. Jeg foretrækker at bruge den indbyggede UART i PIC, så jeg jagtede online for at se, om der var en måde at få MFRC522-modulet til UART-tilstand. Hvad jeg fandt ud af var, at det ville gøre tricket at skære et spor på brættet. Snittet fjerner effektivt 3,3 volt fra chipens EA -pin. Teknisk set skal EA -stiften derefter tilsluttes jorden, men ikke mange mennesker kan trække den lodning ud i betragtning af chipstiftens tæthed. Dog skal du ikke bekymre dig, fordi EA-pin ikke har en intern pull-up og ikke "flyder" som de gamle TTL-logiske input gør. Se chipdiagrammet og billedsektionsbilledet for stedet at skære. Sørg for, at du kun klipper det korte spor direkte til EA -stiften.

Trin 2: Hardware

Hardwareforbindelserne til UART -kommunikation er vist i diagrammet ovenfor. UART -forbindelserne til MFRC522 er ikke markeret på tavlen, men som vist i skematikken modtager SDA -pin UART -data, og MISO -pin sender UART -data. PN532 -modulet har UART -markeringer på undersiden af brættet.

Begge moduler kører på 3,3 volt, og det 5-volts logiske niveau fra PIC TX-pin skal også begrænses. LCD-forbindelsen er standard 4-bit opsætningen, der er blevet brugt i en række af mine tidligere projekter. Standardformatet for alle meddelelser er indstillet til standard 1602 LCD (16 tegn med 2 linjer). Jeg har også et LCD -display på 40 tegn med 2 linjer, som jeg bruger til rådata -dump ved fejlfinding, så jeg inkluderede en definition i softwaren, der giver mig mulighed for at drage fordel af det ekstra displayplads.

Trin 3: Datablokke

Mifare Classic 1k -tags, der bruges til dette projekt, er konfigureret som 16 sektorer, fire datablokke pr. Sektor, 16 bytes pr. Datablok. Af de 64 datablokke er kun 47 faktisk brugbare. Datablok 0 indeholder producentdata og blok 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 og 63 kaldes Trailerblokke. Trailerblokkene er de sidste i hver sektor, og de indeholder to nøgler og blokadgangsbitene. Nøglerne og blokadgangsbitene gælder kun for datablokkene i den sektor, så du kan have forskellige nøgler og adgangsregler for hver sektor. Standardtasterne er indstillet til "FF FF FF FF FFh". Til dette grundlæggende projekt bruger jeg kun en datablok og beholder standardnøgler og adgangsbits. Der er masser af dokumenter relateret til disse kort, så søg bare online efter "Mifare" eller besøg NXP -webstedet, hvis du vil udforske dem mere dybtgående.

Trin 4: Generel betjening

Selvom begge moduler er unikke på den måde, de får adgang til, og den måde, de får adgang til tags, er der en generel proces, der er nødvendig for at få jobbet udført. For dette projekt antager vi, at mærkerne er Mifare Classic 1k -typen, og at vi kun tillader et mærke ad gangen i antennefeltet. De grundlæggende trin er defineret nedenfor.

· Initialiser modulet: Generelt kræver dette ting som at skrive værdier til registre i chippen, sende "wakeup" -kommandoer og tænde for antennen. I et batteridrevet program vil du gerne kunne tænde og slukke for antennen for at gemme batteriet, men for denne enkle applikation tænder vi det en gang og lader det derefter være tændt.

· Ryd kryptoflaget (kun 522): Når et mærke er godkendt, sættes et flag til at lade brugeren vide, at kommunikation med mærket vil blive krypteret. Dette flag skal ryddes af brugeren inden den næste scanning, selvom mærket, der scannes, er det samme.

· Scan efter et mærke: Modulet spørger dybest set "Er der nogen derude?" og mærket svarer "I'm here". Hvis modulet ikke får et hurtigt svar, stopper det med at lytte. Det betyder, at vi gentagne gange skal scanne kommandoer til modulet, indtil det finder et mærke.

· Hent koden Brugeridentifikationsnummer (UID): Mærket reagerer på scanningsanmodningen med nogle begrænsede oplysninger, f.eks. Den type mærke, det er. Det betyder, at vi muligvis skal sende en anden kommando for at få dens UID. UID'en er fire bytes for Mifare Classic 1k -tags. Hvis det kan være længere for andre tags, men dette projekt ikke adresserer dem.

· Vælg mærket (kun 522): UID'et bruges til at vælge det mærke, som brugeren vil godkende til læsning og skrivning. Dette er baseret på muligheden for, at der kan være mere end et mærke i antennefeltet. Det er ikke tilfældet for vores enkle applikation, men vi skal alligevel vælge mærket.

· Godkend mærket: Dette trin er påkrævet, hvis vi vil læse eller skrive tagget. Hvis alt, hvad vi vil gøre, er at skelne mellem tags til et simpelt sikkerhedsprogram, er UID nok. Godkendelse kræver, at vi kender UID, og at vi kender krypto -nøglen til datasektoren for det tag, vi vil have adgang til. Til dette projekt holder vi fast ved standardnøglerne, men mit opfølgningsprojekt ændrer nøglerne, så mærket kan bruges som en elektronisk tegnebog.

· Læs eller skriv mærket: Læser returnerer altid alle 16 bytes i den ønskede datablok. Skriver kræver, at alle 16 bytes skrives på samme tid. Hvis du vil læse eller skrive en anden blok i den samme datasektor, behøver tagget ikke at blive godkendt igen. Hvis du vil læse eller skrive en blok i en anden datasektor, skal tagget godkendes igen ved hjælp af nøglen til den pågældende sektor.

Trin 5: MFRC522 -moduladgangssekvens

Opstartsrutinen indeholder disse grundlæggende trin, der findes i de fleste af de programmer, jeg kiggede på:

· Send dummy -databyte (se næste afsnit)

· Blød nulstilling

· Indstil RF -modtagerforstærkning (hvis der ønskes noget andet end standarden)

· Indstil ASK -modulationsprocent til 100%

· Indstil frøværdi til CRC -beregninger

· Tænd for antennen

· Få firmwareversion (ikke påkrævet)

Af en eller anden uforklarlig grund tænder mit modul op og tror, at det har modtaget en skrivekommando uden databyte. Jeg ved ikke, om dette bare er et problem med mit modul, men jeg har ikke set nogen referencer til det andre steder. Jeg eksperimenterede med både hardware og software nulstilling og fik ikke løst problemet. Min løsning var at tilføje et dummy read -opkald for at registrere “0” (udefineret) i starten af modulinitialiseringsrutinen. Hvis modulet ser dette som data for den ukendte skrivekommando, ser det ikke ud til at have nogen negative effekter. Hvis den ser det som en læsekommando, sker der ikke noget nyttigt. Det generer mig, at jeg ikke helt kan definere problemet, især i betragtning af at en hardware -nulstilling af bare modulet ikke løser problemet.

RC522 -chippen er sammensat af en række registre, hvoraf de fleste både er læst og skrevet. For at udføre en skrivning sendes registernummeret til modulet efterfulgt af værdien, der skal skrives. For at udføre en læsning er der tilføjet registernummeret 0x80 til det, og det sendes til modulet. Svaret på en skrivekommando er et ekko af det register, der er adgang til. Svaret på en læsekommando er registerets indhold. Softwaren udnytter denne viden til at kontrollere, at kommandoen blev udført korrekt.

Trin 6: PN532 -moduladgangssekvens

Opstartsrutinen indeholder disse nødvendige trin:

· Send en initialiseringsstreng: Dette er specifikt for UART -grænsefladen. Manualen angiver, at UART-grænsefladen vågner op på den femte stigende kant, der registreres på grænsefladen. Det anbefaler at sende 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. For det meste skal der bare være et tilstrækkeligt antal tegn med stigende kanter, og de må ikke ligne en kommandoen indledning (00 00 FF).

· Vågn op for modulet: Begravet i brugervejledningen viser det, at modulet initialiseres til en slags dvaletilstand kaldet “LowVbat”. For at forlade denne tilstand skal vi sende en kommando "SAMConfiguration".

PN532 forventer, at kommandoer sendes i et defineret meddelelsesformat, der indeholder en præambel, meddelelsen og en postamble. Svarmeddelelserne følger det samme format. Kommando- og svarmeddelelserne indeholder begge en TFI (Frame Identifier) og en kommandoversion. Kommandoen bruger en TFI på 0xD4, og svaret bruger 0xD5. Kommandoversionerne varierer, men svaret vil altid øge kommandoversionen og returnere den i byte efter TFI. Denne konsistens giver mulighed for, at svarmeddelelserne let kan scannes efter de relevante oplysninger.

Hver kommandobesked (efter præamblen) består af meddelelsens længde, 2’ernes komplement til beskedlængden, TFI, kommando, data, checksum og postamble. Softwaren bygger de enkelte kommandoer og kalder derefter en rutine, der beregner kontrolsummen og tilføjer postamble.

Meddelelsesformatet for svaret ligner kommandoens. Et typisk svar vil omfatte en ACK (00 00 FF 00 FF 00) efterfulgt af det specifikke svar på kommandoen. Hvert kommandosvar begynder med en præambel på 00 00 FF. Svaret skal også have en TFI -byte på D5 efterfulgt af kommandonummeret øget med 1. For vores "SAMConfiguration" -kommando (14) ville det være 15. Kommandoen "SAMConfiguration" får dette svar: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Der er andre modulspecifikke kommandoer, der kan sendes, men de er ikke nødvendige for denne applikation. Jeg inkluderede dog en rutine, der kan kaldes til at hente firmwareversionsnummeret. Et typisk svar (efter ACK og præamblen) ville være: 06 FA D5 03 32 01 06 07 E8 00. “01 06 07” angiver firmwareversionsnummer 1.6.7.

Trin 7: Tag adgangssekvens

Når modulet er klar, kan vi sende kommandoer, der er specifikke for tags. For at kunne læse eller skrive tagdata skal vi have dets identifikationsnummer (UID). UID'en og nøglen vil derefter blive brugt til at godkende en bestemt tagdatasektor til læsning/skrivning. Tagdata læser/skriver udføres altid på alle 16 bytes i en specificeret datablok. Det betyder, at den typiske applikation vil læse datablokken, ændre dataene efter ønske og derefter skrive de nye data tilbage til tagget.

Trin 8: Software

Interrupt -håndteringssoftwaren bliver kaldt, når PIC UART modtager en byte med data. I nogle af mine tidligere UART -projekter var jeg i stand til bare at afstemme RX -afbrydelsesflagget i stedet for at skulle bruge en interrupt -handler. Det er ikke tilfældet for denne software, især for PN532, der kommunikerer med en meget højere baudhastighed end RC522. UART -grænsefladen på RC522 er begrænset til 9600 baud, mens standarden for PN532 er 115k og kan indstilles til 1.288M baud. De modtagne bytes gemmes i et bufferområde, og hoveddelen af softwaren henter dem efter behov.

New_Msg -flag angiver, at bytes er blevet modtaget, og Byte_Count angiver, hvor mange. Jeg har inkluderet en "Disp_Buff" -rutine i softwaren, der kan kaldes til at vise indholdet i modtagelsesbufferen under fejlfinding. Nogle af tilbagemeldingsmeddelelserne vil overløbe en typisk 1602 -skærm, men jeg har et LCD -display på 40 tegn med 2 linjer, som jeg fandt på et online overskudselektronikwebsted. "Max_Line" -definitionen kan indstilles til din LCD -størrelse. Hvis "Max_Line" nås, fortsætter rutinen "Disp_Buff" ved at skrive til den anden linje. Du kan tilføje en lille kode til den rutine for at fortsætte til linje tre og fire, hvis du har en 4-line LCD. For PN532 er der et flag, der kan indstilles, så rutinen enten dumper alle modtagne bytes eller bare dumper de 16 databyte fra et læst svar.

Der er ikke behov for at rydde modtagerbufferen eller Byte_Count, fordi sletning af New_Msg -flag vil få Byte_Count til at blive ryddet af afbryderhandleren, og det er det, der bruges som indeks i bufferen. New_Msg bliver normalt ryddet før hvert kommandotrin, så de specifikke resultater for den kommando let kan lokaliseres og verificeres. I RC522 betyder det, at modtagerbufferen normalt kun har 1 til 4 bytes. I nogle tilfælde, f.eks. Datablæsninger, skal Read_FIFO -kommandoen udstedes flere gange for at flytte bytes fra FIFO til modtagerbufferen. Alle kommandoresultater for PN532 ender i modtagerbufferen, så der udføres en scanningsprocedure for at lokalisere de nødvendige bytes.

Hovedløkken i softwaren søger efter et mærke og godkender derefter mærket til læsning/skrivning. For testsoftwaren, der er inkluderet her, ændres variablen Junk_Num hver gang gennem hovedsløjfen og bruges under skrivningen til tagget. De skrevne værdier veksler mellem værdien af Junk_Num og 1’ernes komplement af Junk_Num. Endelig læses og vises de 16 skrevne værdier. Der er displaymeddelelser for hvert trin med forsinkede rutineopkald for at give tid til at læse hver meddelelse. Fejlmeddelelser findes også, men bør normalt kun forekomme, hvis mærket fjernes under en operation.

En del af softwareinitialiseringen er en sektion af kode, der kun udføres ved opstart og springes over, hvis der registreres en software -nulstilling. Fejlmeddelelserne afsluttes generelt med en nulstilling af software som en måde at afslutte hovedsløjfen på. Nulstillingen sker i "Tilt" -rutinen, som ganske enkelt aktiverer Watchdog Timer og derefter går ind i en uendelig sløjfe, der venter på timeout.

Trin 9: MFRC522 unik software

RC522-chippen kræver flere instruktioner på lavt niveau end PN532-chippen for at opnå kommunikation med tags. Det er lidt ligesom programmering i samlingssprog versus programmering i "C". En anden væsentlig forskel er, at RC522 kræver, at kommunikation med mærket ledes gennem en FIFO -buffer. Rutinerne “Write_FIFO” og “Read_FIFO” håndterer disse opgaver. MFRC522-softwaren indeholder en sektion til mange af kommandoerne på lavere niveau, hvorfra hovedfunktionerne er bygget.

Beregningen af kontrolkommandoen for tag -kommandoen for RC522 er meget anderledes end for PN532. Efter tag -kommandoen er bygget i FIFO, sendes en modulkommando til beregning af kontrolsummen. 16-bit-resultatet føjes ikke automatisk til tag-kommandoen, men er tilgængeligt til læsning fra to 8-bit-registre. Checksumberegningen sletter dataene i FIFO, så den nødvendige sekvens er som følger:

· Byg kommandoen i FIFO

· Kommandér en checksumberegning

· Byg kommandoen i FIFO igen

· Læs CRC -registre og skriv checksumbytes til FIFO

· Send enten en kommando Transceive eller Authenticate

Kommandoen Transceive sender FIFO -bufferen og skifter derefter automatisk til modtagelsestilstand for at vente på svaret fra mærket. Kommandoen Transceive skal følges af indstillingen af StartSend -bit i BitFramingRegister for faktisk at kunne overføre dataene. Kommandoen Authenticate har ikke det krav.

Generelt bruger Arduino “C” -kodeprogrammer, der er tilgængelige online, interrupt -flagregistrene og timeout -registret for at sikre, at det korrekte svar modtages rettidigt. Efter min mening er det overkill for denne ikke-tidskritiske applikation. I stedet bruger jeg korte softwaretimeouts til at vente på svaret og derefter kontrollere, at det er korrekt. Manualen til Mifare -tags beskriver timingen for de forskellige transaktioner, og det er også tilladt at modtage det forventede antal bytes. Disse tidsforsinkelser er indbygget i de fleste af kommando-underrutiner på lavt niveau.

Trin 10: PN532 unik software

Efter modulet er initialiseret, udføres de trin, der er nødvendige for at finde og godkende mærket, ved at skrive den relevante kommando efterfulgt af de nødvendige data. Scan -kommandoen returnerer UID'et, som derefter bruges til godkendelse. Derefter læser og skriver tag'et, sende eller returnere 16-bytes for den adresserede datablok.

Initialiseringssekvensen blev detaljeret tidligere, og den samme software -rutine sender også kommandoen SAMConfiguration for at få modulet ud af tilstanden "LowVbat". Resten af de grundlæggende kommandoer, f.eks. Scan, Godkend, Læs/skriv tag, er bare bygget sekventielt i de gældende rutiner. Checksummen beregnes ved blot at tilføje kommandobytes, lave et komplement og derefter tilføje 1 for at gøre det til et 2’er -supplement. 8-bit resultatet tilføjes til kommandostrengen lige før postamble.

Der er ingen FIFO som i RC522, så de komplette svarmeddelelser modtages automatisk. "Find_Response" -rutinen scanner modtagelsesdatabufferen for TFI (0xD5). Rutinen drager fordel af at vide, hvad de forventede meddelelser skal være og ignorerer enkle ACK -svar, der ikke indeholder data. Når først TFI er fundet, er de ønskede svar en kendt forskydning fra det. Kommandoekkoet og kommandostatusbytes gemmes af "Read_Buff" -rutinen til senere verifikation.

Det er det for dette indlæg. Tjek mine andre elektronikprojekter på: www.boomerrules.wordpress.com