RC522 och PN532 Grundläggande RFID: 10 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:44

OBS: Jag har nu Instructables som erbjuder Arduino -kod för RC522 och PN532.

För en tid sedan köpte jag tre olika RFID -moduler för experiment. I ett tidigare projekt beskriver jag hur jag använder en enkel 125 kHz modul för att utföra en grundläggande säkerhetsfunktion. Moduler som den använder skrivskyddade taggar så processen söker efter ID: t, lagrar om så önskas och jämför med lagrade ID: er. De andra modulerna jag köpte fungerar på 13,56 MHz och använder taggar som kan både läsas och skrivas så det är lite slöseri att helt enkelt använda dem för grundläggande säkerhet. De två vanliga modulerna använder antingen RC522 -chipet eller PN532 -chipet - båda tillverkade av NXP.

Om du har läst något av mina andra projekt vet du att jag gillar att använda billiga PIC -mikrokontroller och programmera på monteringsspråk. Så det jag letade efter var en sekvens av steg som krävs för att prata med modulerna och till RFID -taggarna. Även om det finns många exempelprogram online för modulerna, är de flesta av dem skrivna i 'C' -programvara för Arduino och använder SPI -gränssnittet. Även manualerna för chipsen och för Mifare -taggarna tar lite av dechiffrering. Det här inlägget handlar främst om den information jag önskar att jag hade när jag startade projektet. Jag inkluderar också PIC -monteringsprogram för att utföra de grundläggande kommandona som krävs för varje modul. Även om du inte använder en PIC och/eller monteringsspråk, bör källkoden åtminstone ge dig en bra uppfattning om de specifika kommandon som krävs för att utföra varje steg.

Steg 1: Seriella gränssnitt

Båda chipsen som används på dessa moduler kan anslutas via SPI, I2C eller UART (HSSP). PN532 -modulen har en DIP -switch som används för att välja önskat gränssnitt men MFRC522 -modulen är fastkopplad för SPI -gränssnittet. Jag föredrar att använda den inbyggda UART i PIC, så jag jagade online för att se om det fanns ett sätt att få MFRC522-modulen till UART-läge. Vad jag fann var att klippa ett spår på brädan skulle göra susen. Snittet tar effektivt bort 3,3 volt från chipets EA -stift. Tekniskt sett bör EA -stiftet sedan anslutas till marken, men inte många människor kan dra av den lödningen med tanke på spånstiftstätheten. Oroa dig dock inte, eftersom EA-stiftet inte har en intern pull-up och inte "flyter" som de gamla TTL-ingångarna gör. Se flisdiagrammet och kartonsektionsbilden för platsen att klippa. Se till att du bara klipper det korta spåret direkt till EA -stiftet.

Steg 2: Hårdvara

Hårdvaruanslutningarna för UART -kommunikation visas i diagrammet ovan. UART -anslutningarna för MFRC522 är inte markerade på kortet, men som visas i schemat, tar SDA -stiftet emot UART -data och MISO -stiftet överför UART -data. PN532 -modulen har UART -markeringar på undersidan av kortet.

Båda modulerna körs på 3,3 volt och 5-volts logiknivån från PIC TX-stiftet måste också begränsas. LCD-anslutningen är standard 4-bitars setup som har använts i ett antal av mina tidigare projekt. Standardformatet för alla meddelanden är inställt för standard 1602 LCD (16 tecken med 2 rader). Jag har också en LCD -skärm på 40 tecken med 2 rader som jag använder för rådata -dumpningar under felsökning, så jag inkluderade en definition i programvaran som gör att jag kan dra nytta av det extra displayutrymmet.

Steg 3: Datablock

Mifare Classic 1k -taggarna som används för detta projekt är konfigurerade som 16 sektorer, fyra datablock per sektor, 16 byte per datablock. Av de 64 datablocken är bara 47 faktiskt användbara. Datablocket 0 innehåller tillverkardata och block 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 och 63 kallas Trailer -block. Trailerblocken är de sista i varje sektor och de innehåller två nycklar och blockåtkomstbitarna. Nycklarna och blockåtkomstbitarna gäller bara datablocken i den sektorn så att du kan ha olika nycklar och åtkomstregler för varje sektor. Standardknapparna är inställda på "FF FF FF FF FFh". För detta grundläggande projekt använder jag bara ett datablock och behåller standardnycklarna och åtkomstbitarna. Det finns massor av dokument som är relaterade till dessa kort, så sök bara online efter “Mifare” eller besök NXP: s webbplats om du vill utforska dem mer ingående.

Steg 4: Allmän drift

Medan båda modulerna är unika på sättet att komma åt dem och hur de kommer åt taggarna, krävs det en allmän process för att få jobbet gjort. För detta projekt antar vi att taggarna är Mifare Classic 1k -typen och att vi bara tillåter en tagg i taget i antennfältet. De grundläggande stegen definieras nedan.

· Initiera modulen: I allmänhet kräver detta saker som att skriva värden till register i chipet, skicka "väckarkommandon" och slå på antennen. I en batteridriven applikation skulle du vilja kunna slå på och stänga av antennen för att spara batteriet, men för den här enkla applikationen slår vi på den en gång och lämnar den sedan på.

· Rensa kryptoflaggan (endast 522): När en tagg är autentiserad ställs en flagga in så att användaren får veta att kommunikation med taggen kommer att krypteras. Denna flagga måste rensas av användaren före nästa genomsökning, även om taggen som skannas är samma.

· Sök efter en tagg: Modulen frågar i princip "Finns det någon där ute?" och taggen svarar "I'm here". Om modulen inte får ett snabbt svar slutar den lyssna. Det betyder att vi flera gånger måste skicka skanningskommandon till modulen tills den hittar en tagg.

· Skaffa taggen User Identification number (UID): Taggen svarar på skanningsförfrågan med viss begränsad information, till exempel vilken typ av tagg den är. Det betyder att vi kan behöva skicka ett annat kommando för att få dess UID. UID är fyra byte för Mifare Classic 1k -taggar. Om det kan vara längre för andra taggar men det här projektet inte tar upp dem.

· Välj taggen (endast 522): UID används för att välja taggen som användaren vill autentisera för läsningar och skrivningar. Detta är baserat på möjligheten att det kan finnas mer än en tagg i antennfältet. Så är inte fallet för vår enkla applikation men vi måste välja taggen ändå.

· Autentisera taggen: Detta steg krävs om vi vill läsa eller skriva taggen. Om allt vi vill göra är att skilja mellan taggar för en enkel säkerhetsapplikation räcker det med UID. Autentisering kräver att vi känner till UID och att vi känner till krypteringsnyckeln för datasektorn för taggen som vi vill komma åt. För detta projekt håller vi fast vid standardnycklarna men mitt uppföljningsprojekt ändrar nycklarna så att taggen kan användas som en elektronisk plånbok.

· Läs eller skriv taggen: Läsningar returnerar alltid alla 16 bytes i det begärda datablocket. Skriver kräver att alla 16 byte skrivs samtidigt. Om du vill läsa eller skriva ett annat block i samma datasektor behöver inte taggen autentiseras igen. Om du vill läsa eller skriva ett block i en annan datasektor måste taggen autentiseras igen med nyckeln för den sektorn.

Steg 5: MFRC522 -modulåtkomstsekvens

Startrutinen innehåller dessa grundläggande steg som finns i de flesta applikationer jag tittade på:

· Skicka dummy -databyte (se nästa stycke)

· Mjuk omstart

· Ställ in RF -mottagarens förstärkning (om något annat än standard önskas)

· Ställ in ASK -moduleringsprocent till 100%

· Ställ in frövärdet för CRC -beräkningar

· Slå på antennen

· Skaffa firmwareversion (krävs inte)

Av någon oförklarlig anledning slår min modul på och tror att den har fått ett skrivkommando utan databyte. Jag vet inte om detta bara är ett problem med min modul men jag har inte sett några referenser till den någon annanstans. Jag experimenterade med både maskin- och programvaruåterställningar och ingen av dem löste problemet. Min lösning var att lägga till ett dummy -läsanrop för att registrera “0” (odefinierat) i början av modulinitieringsrutinen. Om modulen ser detta som data för det okända skrivkommandot verkar det inte finnas några dåliga effekter. Om det ser det som ett läskommando, händer inget användbart. Det stör mig att jag inte helt kan definiera problemet, särskilt med tanke på att en hårdvaruåterställning av bara modulen inte löser problemet.

RC522 -chipet består av ett antal register, varav de flesta är både lästa och skrivna. För att skriva, skickas registernumret till modulen följt av värdet som ska skrivas. För att utföra en läsning har registret 0x80 lagts till och det skickas till modulen. Svaret på ett skrivkommando är ett eko av det register som du har åtkomst till. Svaret på ett läskommando är innehållet i registret. Programvaran drar nytta av den kunskapen för att verifiera att kommandot utfördes korrekt.

Steg 6: PN532 -modulåtkomstsekvens

Startrutinen innehåller följande steg:

· Skicka en initialiseringssträng: Detta är specifikt för UART -gränssnittet. Handboken anger att UART-gränssnittet kommer att vakna på den femte stigande kanten som upptäcks på gränssnittet. Den rekommenderar att du skickar 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. För det mesta behöver det bara finnas ett tillräckligt antal tecken med stigande kanter och de får inte se ut som en kommandon ingress (00 00 FF).

· Väck modulen: Begravd i bruksanvisningen visar det att modulen initieras till ett slags sömntillstånd som kallas”LowVbat”. För att lämna detta tillstånd måste vi skicka ett "SAMConfiguration" -kommando.

PN532 förväntar sig att kommandon ska skickas i ett definierat meddelandeformat som innehåller en ingress, meddelandet och en postamble. Svarsmeddelandena följer samma format. Kommando- och svarsmeddelandena innehåller båda en TFI (Frame Identifier) och en kommandoversion. Kommandot använder en TFI på 0xD4 och svaret använder 0xD5. Kommandoversionerna varierar men svaret kommer alltid att öka kommandoversionen och returnera den i byte efter TFI. Den konsekvensen gör att svarsmeddelandena lätt kan skannas efter relevant information.

Varje kommandomeddelande (efter ingressen) består av meddelandelängden, 2: s komplement till meddelandelängden, TFI, kommando, data, kontrollsumma och postamble. Programvaran bygger de enskilda kommandona och anropar sedan en rutin som beräknar kontrollsumman och lägger till postamble.

Meddelandeformatet för svaret liknar kommandot. Ett typiskt svar kommer att inkludera ett ACK (00 00 FF 00 FF 00) följt av det specifika svaret på kommandot. Varje kommandosvar börjar med en ingress på 00 00 FF. Svaret bör också ha en TFI -byte på D5 följt av kommandonumret ökat med 1. För vårt "SAMConfiguration" -kommando (14) skulle det vara 15. Kommandot "SAMConfiguration" får detta svar: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Det finns andra modulspecifika kommandon som kan skickas men de behövs inte för den här applikationen. Jag inkluderade dock en rutin som kan kallas för att hämta firmwareversionsnumret. Ett typiskt svar (efter ACK och ingressen) skulle vara: 06 FA D5 03 32 01 06 07 E8 00. “01 06 07” indikerar firmware -version 1.6.7.

Steg 7: Taggningssekvens

När modulen är klar kan vi skicka kommandon specifika för taggarna. För att kunna läsa eller skriva taggdata måste vi ha dess identifikationsnummer (UID). UID och nyckel kommer sedan att användas för att auktorisera en specifik taggdatasektor för läsning/skrivning. Tagdata läser/skriver görs alltid på alla 16 byte i ett specifikt datablock. Det betyder att den typiska applikationen kommer att läsa datablocket, ändra data efter önskemål och sedan skriva den nya datan tillbaka till taggen.

Steg 8: Programvara

Avbrottshanteringsprogramvaran blir uppringd när PIC UART tar emot en byte med data. I några av mina tidigare UART -projekt kunde jag bara undersöka RX -avbrottsflaggan istället för att behöva använda en avbrottshanterare. Detta är inte fallet för denna programvara, särskilt för PN532 som kommunicerar med en mycket högre överföringshastighet än RC522. UART -gränssnittet på RC522 är begränsat till 9600 baud medan standard för PN532 är 115k och kan ställas in så högt som 1,288M baud. Mottagna byte lagras i ett buffertområde och huvuddelen av programvaran hämtar dem efter behov.

New_Msg -flaggan indikerar att byte har tagits emot och Byte_Count anger hur många. Jag har inkluderat en "Disp_Buff" -rutin i programvaran som kan kallas för att visa innehållet i mottagningsbufferten under felsökning. Några av returmeddelandena kommer att överflödas av en typisk 1602 -skärm men jag har en LCD -skärm på 40 tecken med 2 rader som jag hittade på en elektronisk webbplats för överskott online. "Max_Line" -definieringen kan ställas in för din LCD -storlek. Om”Max_Line” nås fortsätter rutan “Disp_Buff” genom att skriva till den andra raden. Du kan lägga till en liten kod till den rutinen för att fortsätta till rad tre och fyra om du har en 4-raders LCD. För PN532 finns det en flagga som kan ställas in så att rutinen antingen dumpar alla mottagna byte eller bara dumpar de 16 databyte från ett lässvar.

Det finns inget behov av att rensa mottagningsbufferten eller Byte_Count eftersom rensning av New_Msg -flaggan kommer att få Byte_Count att rensas av avbrottshanteraren och det är det som används som index i bufferten. New_Msg rensas vanligtvis före varje kommandosteg så att resultaten specifika för det kommandot enkelt kan lokaliseras och verifieras. I RC522 betyder det att mottagningsbufferten vanligtvis bara har 1 till 4 byte. I vissa fall, till exempel datablockläsningar, måste Read_FIFO -kommandot utfärdas flera gånger för att flytta byte från FIFO till mottagningsbufferten. Alla kommandoresultat för PN532 hamnar i mottagningsbufferten så att en skanningsprocedur utförs för att hitta de specifika byte som behövs.

Huvudslingan i programvaran söker efter en tagg och autentiserar sedan taggen för läsning/skrivning. För testprogramvaran som ingår här ändras variabeln Junk_Num varje gång genom huvudslingan och används under skrivningen till taggen. De skrivna värdena växlar mellan värdet på Junk_Num och 1: s komplement av Junk_Num. Slutligen läses och visas de 16 skrivna värdena. Det finns displaymeddelanden för varje steg med fördröjningsrutinsamtal för att ge tid att läsa varje meddelande. Felmeddelanden tillhandahålls också men bör normalt bara uppstå om taggen tas bort under en operation.

En del av programvaruinitialiseringen är en koddel som bara körs vid uppstart och som hoppas över om en programåterställning upptäcks. Felmeddelandena avslutas vanligtvis med en programvaruåterställning som ett sätt att lämna huvudslingan. Återställningen sker i "Tilt" -rutinen som helt enkelt aktiverar Watchdog Timer och sedan går in i en oändlig loop som väntar på timeout.

Steg 9: MFRC522 Unik programvara

RC522-chipet kräver mer instruktioner på låg nivå än PN532-chipet för att uppnå kommunikation med taggar. Det är ungefär som att programmera i monteringsspråk kontra programmering i "C". En annan signifikant skillnad är att RC522 kräver att kommunikation med taggen får kanal genom en FIFO -buffert. Rutinerna "Write_FIFO" och "Read_FIFO" hanterar dessa uppgifter. Programvaran MFRC522 innehåller en sektion för många av kommandona på lägre nivå som huvudfunktionerna är byggda från.

Beräkningen av kontrollkommandon för taggkommandot för RC522 är mycket annorlunda än för PN532. När taggkommandot har byggts i FIFO skickas ett modulkommando för att beräkna kontrollsumman. 16-bitarsresultatet läggs inte automatiskt till taggkommandot utan är tillgängligt för läsning från två 8-bitars register. Beräkningen av kontrollsumman raderar data i FIFO så att den erforderliga sekvensen är följande:

· Skapa kommandot i FIFO

· Kommando en kontrollsumberäkning

· Bygg kommandot i FIFO igen

· Läs CRC -registren och skriv kontrollsummabyte till FIFO

· Skicka antingen ett Transceive- eller Authenticate -kommando

Kommandot Transceive överför FIFO -bufferten och växlar sedan automatiskt till mottagningsläge för att vänta på svaret från taggen. Kommandot Transceive måste följas av inställningen av StartSend -biten i BitFramingRegister för att faktiskt kunna överföra data. Kommandot Authenticate har inte det kravet.

I allmänhet använder Arduino “C” -kodapplikationer som är tillgängliga online interruptflaggregistren och timeoutregistret för att säkerställa att rätt svar tas emot i tid. Enligt min mening är det överkill för denna icke-tidskritiska applikation. Istället använder jag korta programtidstider för att vänta på svaret och sedan verifiera att det är korrekt. Manualen för Mifare -taggarna beskriver tidpunkten för de olika transaktionerna och tid är också tillåten för det förväntade antalet byte att tas emot. Dessa tidsfördröjningar är inbyggda i de flesta av kommandosubrutinerna på låg nivå.

Steg 10: PN532 Unik programvara

Efter att modulen har initierats utförs stegen som behövs för att hitta och autentisera taggen genom att skriva lämpligt kommando följt av nödvändig data. Skanningskommandot returnerar UID som sedan används för autentisering. Därefter läser och skriver taggen skicka eller returnera 16-byte för det adresserade datablocket.

Initieringssekvensen var detaljerad tidigare och samma programvarurutin skickar också SAMConfiguration -kommandot för att få modulen ur "LowVbat" -läget. Resten av de grundläggande kommandona, till exempel Scan, Authenticate, Read/Write Tag, byggs bara sekventiellt i de tillämpliga rutinerna. Kontrollsumman beräknas genom att bara lägga till kommandobyten, göra ett komplement och sedan lägga till 1 för att göra det till ett 2 -komplement. 8-bitarsresultatet läggs till kommandosträngen strax före postamble.

Det finns ingen FIFO som i RC522 så att hela svarsmeddelandet tas emot automatiskt. "Find_Response" -rutinen skannar mottagningsdatabufferten för TFI (0xD5). Rutinen drar nytta av att veta vad de förväntade meddelandena bör vara och ignorerar enkla ACK -svar som inte innehåller data. När TFI väl har hittats är de önskade svaren en känd förskjutning från den. Kommandoeko och kommandostatusbyte sparas av "Read_Buff" -rutinen för senare verifiering.

Det är det för det här inlägget. Kolla in mina andra elektronikprojekt på: www.boomerrules.wordpress.com