RC522 og PN532 grunnleggende RFID: 10 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:23

MERK: Jeg har nå Instructables som tilbyr Arduino -kode for RC522 og PN532.

For en tid siden kjøpte jeg tre forskjellige RFID -moduler for eksperimentering. I et tidligere prosjekt forklarte jeg hvordan jeg bruker en enkel 125 kHz modul til å utføre en grunnleggende sikkerhetsfunksjon. Moduler som det bruker skrivebeskyttede koder, slik at prosessen søker etter ID-en, lagrer om ønskelig og sammenligner med lagrede ID-er. De andre modulene jeg kjøpte opererer på 13,56-MHz og bruker tagger som kan både leses og skrives, så det er sløsing å bare bruke dem for grunnleggende sikkerhet. De to vanlige modulene bruker enten RC522 -brikken eller PN532 -brikken - begge laget av NXP.

Hvis du har lest noen av mine andre prosjekter, vet du at jeg liker å bruke billige PIC -mikrokontrollere og programmere på monteringsspråk. Så det jeg lette etter var en sekvens av trinn som kreves for å snakke med modulene og til RFID -taggene. Selv om det er mange eksempler på programmer for modulene, er de fleste skrevet i ‘C’ programvare for Arduino og bruker SPI -grensesnittet. Også håndbøkene for sjetongene og for Mifare -taggene tar litt av dechiffrering. Dette innlegget handler først og fremst om informasjonen jeg skulle ønske jeg hadde da jeg startet prosjektet. Jeg inkluderer også PIC -monteringsprogrammer for å utføre de grunnleggende kommandoene som kreves av hver modul. Selv om du ikke bruker et PIC og/eller samlingsspråk, bør kildekoden i det minste gi deg en god ide om de spesifikke kommandoene som kreves for å utføre hvert trinn.

Trinn 1: Serielle grensesnitt

Begge brikkene som brukes på disse modulene er i stand til å koble til via SPI, I2C eller UART (HSSP). PN532 -modulen har en DIP -bryter som brukes til å velge ønsket grensesnitt, men MFRC522 -modulen er koblet til SPI -grensesnittet. Jeg foretrekker å bruke den innebygde UART av PIC, så jeg jaktet på nettet for å se om det var en måte å få MFRC522-modulen til UART-modus. Det jeg fant var at det å klippe ett spor på brettet ville gjøre susen. Kuttet fjerner effektivt 3,3 volt fra EA -pinnen på brikken. Teknisk sett bør EA -pinnen deretter kobles til bakken, men ikke mange mennesker kan trekke den loddeprestasjonen gitt chip -pin -tettheten. Ikke bekymre deg, for EA-pinnen har ikke en intern pull-up og ikke "flyter" som de gamle TTL-logikkinngangene gjør. Se brikkediagrammet og tavlebildet for flekken som skal kuttes. Sørg for at du bare kutter det korte sporet direkte til EA -pinnen.

Trinn 2: Maskinvare

Maskinvaretilkoblingene for UART -kommunikasjon er vist i diagrammet ovenfor. UART -tilkoblingene for MFRC522 er ikke merket på tavlen, men som vist i skjematikken mottar SDA -pinnen UART -data og MISO -pinnen overfører UART -data. PN532 -modulen har UART -merkingene på undersiden av brettet.

Begge modulene går på 3,3 volt, og 5-volts logikknivået fra PIC TX-pinnen må også begrenses. LCD-tilkoblingen er standard 4-biters oppsett som har blitt brukt i en rekke av mine tidligere prosjekter. Standardformatet for alle meldingene er angitt for standard 1602 LCD (16 tegn på 2 linjer). Jeg har også en LCD -skjerm på 40 tegn med 2 linjer som jeg bruker for rådata -dump under feilsøking, så jeg inkluderte en definisjon i programvaren som lar meg dra nytte av den ekstra skjermplassen.

Trinn 3: Datablokker

Mifare Classic 1k -taggene som brukes for dette prosjektet, er konfigurert som 16 sektorer, fire datablokker per sektor, 16 byte per datablokk. Av de 64 datablokkene er bare 47 faktisk brukbare. Datablokk 0 inneholder produsentdata og blokkene 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 og 63 kalles tilhengerblokker. Tilhengerblokkene er de siste i hver sektor, og de inneholder to nøkler og blokktilgangsbitene. Nøklene og blokktilgangsbitene gjelder bare datablokkene i den sektoren, slik at du kan ha forskjellige nøkler og tilgangsregler for hver sektor. Standardtastene er satt til "FF FF FF FF FFh". For dette grunnleggende prosjektet bruker jeg bare en datablokk og beholder standardnøkler og tilgangsbiter. Det er mange dokumenter knyttet til disse kortene, så bare søk på nettet etter “Mifare” eller besøk NXP -nettstedet hvis du vil utforske dem mer grundig.

Trinn 4: Generell drift

Selv om begge modulene er unike i måten de får tilgang til og måten de får tilgang til taggene på, er det en generell prosess som er nødvendig for å få jobben gjort. For dette prosjektet antar vi at merkene er av Mifare Classic 1k -typen og at vi bare tillater én tag om gangen i antennefeltet. De grunnleggende trinnene er definert nedenfor.

· Initialiser modulen: Generelt krever dette ting som å skrive verdier til registre i brikken, sende “wakeup” -kommandoer og slå på strømmen til antennen. I et batteridrevet program vil du kunne slå antennen på og av for å spare batteriet, men for denne enkle applikasjonen slår vi den på en gang og lar den deretter være på.

· Slett kryptoflagget (bare 522): Når en tagg er autentisert, blir et flagg satt til å gi brukeren beskjed om at kommunikasjon med taggen vil bli kryptert. Dette flagget må slettes av brukeren før neste skanning, selv om taggen som skannes er den samme.

· Søk etter en tag: Modulen spør i utgangspunktet "Er det noen der ute?" og taggen svarer "I'm here". Hvis modulen ikke får et raskt svar, slutter den å lytte. Det betyr at vi må gjentatte ganger sende skannekommandoer til modulen til den finner en kode.

· Få taggen User Identification number (UID): Koden vil svare på skanneforespørselen med begrenset informasjon, for eksempel hvilken type tag den er. Det betyr at vi kanskje må sende en annen kommando for å få sin UID. UID er fire byte for Mifare Classic 1k -taggene. Hvis det kan være lengre for andre tagger, men dette prosjektet ikke adresserer dem.

· Velg taggen (kun 522): UID -en brukes til å velge taggen som brukeren vil autentisere for lesing og skriving. Dette er basert på muligheten for at det kan være mer enn én tag i antennefeltet. Det er ikke tilfelle for vår enkle applikasjon, men vi må velge taggen uansett.

· Godkjen taggen: Dette trinnet er nødvendig hvis vi vil lese eller skrive taggen. Hvis alt vi ønsker å gjøre er å skille mellom tagger for et enkelt sikkerhetsprogram, er UID nok. Godkjenning krever at vi kjenner UID og at vi kjenner krypto -nøkkelen for datasektoren til taggen vi vil ha tilgang til. For dette prosjektet holder vi fast med standardnøklene, men oppfølgingsprosjektet mitt endrer nøklene slik at taggen kan brukes som en elektronisk lommebok.

· Les eller skriv taggen: Leser returnerer alltid alle 16 byte i datablokken som er forespurt. Skriver krever at alle 16 byte skrives samtidig. Hvis du vil lese eller skrive en annen blokk i samme datasektor, trenger ikke taggen å bli autentisert igjen. Hvis du vil lese eller skrive en blokk i en annen datasektor, må taggen autentiseres igjen ved hjelp av nøkkelen for den sektoren.

Trinn 5: MFRC522 modultilgangssekvens

Oppstartsrutinen inkluderer disse grunnleggende trinnene som finnes i de fleste applikasjonene jeg så på:

· Send dummy -databyte (se neste avsnitt)

· Myk tilbakestilling

· Still inn RF -mottakerforsterkning (hvis noe annet enn standard er ønsket)

· Sett ASK modulasjonsprosent til 100%

· Angi frøverdi for CRC -beregninger

· Slå på antennen

· Få fastvareversjon (ikke nødvendig)

Av en eller annen uforklarlig grunn slår min modul seg på og tror at den har mottatt en skrivekommando uten databyte. Jeg vet ikke om dette bare er et problem med modulen min, men jeg har ikke sett noen referanser til den andre steder. Jeg eksperimenterte med både maskinvare og programvare tilbakestillinger, og ingen av dem løste problemet. Min løsning var å legge til et dummy -leseanrop for å registrere “0” (udefinert) ved starten av modulinitialiseringsrutinen. Hvis modulen ser på dette som data for den ukjente skrivekommandoen, ser det ikke ut til å ha noen negative effekter. Hvis den ser det som en lese -kommando, skjer det ikke noe nyttig. Det plager meg at jeg ikke helt kan definere problemet, spesielt gitt at en maskinvaretilbakestilling av bare modulen ikke løser problemet.

RC522 -brikken består av en rekke registre, hvorav de fleste er både lest og skrevet. For å skrive, sendes registernummeret til modulen etterfulgt av verdien som skal skrives. For å utføre en lesing har registernummeret 0x80 lagt til det, og det sendes til modulen. Svaret på en skrivekommando er et ekko av registeret som er åpnet. Svaret på en lesekommando er innholdet i registeret. Programvaren utnytter denne kunnskapen for å bekrefte at kommandoen ble utført på riktig måte.

Trinn 6: Tilgangssekvens for PN532 -modul

Oppstartsrutinen inkluderer disse nødvendige trinnene:

· Send en initialiseringsstreng: Dette er spesifikt for UART -grensesnittet. I håndboken står det at UART-grensesnittet vil våkne opp på den femte stigekanten som oppdages på grensesnittet. Den anbefaler å sende 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. For det meste trenger det bare å være et tilstrekkelig antall tegn med stigende kanter, og de må ikke ligne på en kommandoinnledning (00 00 FF).

· Vekk modulen: Begravet i brukerhåndboken viser det at modulen initialiseres til en slags søvnstilstand kalt “LowVbat”. For å gå ut av denne tilstanden må vi sende en "SAMConfiguration" -kommando.

PN532 forventer at kommandoer skal sendes i et definert meldingsformat som inneholder en innledning, meldingen og en postamble. Svarmeldingene følger samme format. Kommando- og svarmeldingene inkluderer begge en TFI (Frame Identifier) og en kommandoversjon. Kommandoen bruker en TFI på 0xD4 og svaret bruker 0xD5. Kommandoversjonene varierer, men svaret vil alltid øke kommandoversjonen og returnere den i byte etter TFI. Denne konsistensen gjør at svarmeldingene lett kan skannes etter relevant informasjon.

Hver kommandomelding (følger innledningen) består av meldingslengden, 2s komplement til meldingslengden, TFI, kommando, data, kontrollsum og postamble. Programvaren bygger de enkelte kommandoene og kaller deretter en rutine som beregner kontrollsummen og legger til postamble.

Meldingsformatet for svaret ligner på kommandoen. Et typisk svar vil inkludere en ACK (00 00 FF 00 FF 00) etterfulgt av det spesifikke svaret på kommandoen. Hvert kommandosvar begynner med en innledning på 00 00 FF. Svaret bør også ha en TFI -byte på D5 etterfulgt av kommandonummeret økt med 1. For vår "SAMConfiguration" -kommando (14) vil det være 15. Kommandoen "SAMConfiguration" får dette svaret: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Det er andre modulspesifikke kommandoer som kan sendes, men de er ikke nødvendige for denne applikasjonen. Jeg inkluderte imidlertid en rutine som kan kalles for å hente fastvareversjonsnummeret. En typisk respons (etter ACK og inngang) vil være: 06 FA D5 03 32 01 06 07 E8 00. “01 06 07” angir fastvareversjon 1.6.7.

Trinn 7: Tag Access Sequence

Etter at modulen er klar, kan vi sende kommandoer som er spesifikke for taggene. For å lese eller skrive taggedata må vi ha identifikasjonsnummeret (UID). UID og nøkkel vil deretter bli brukt til å autorisere en bestemt taggedatasektor for lesing/skriving. Merking av data leser/skriver utføres alltid på alle 16 byte i en spesifisert datablokk. Det betyr at den typiske applikasjonen vil lese datablokken, endre dataene etter ønske og deretter skrive de nye dataene tilbake til taggen.

Trinn 8: Programvare

Avbruddshåndteringsprogramvaren blir oppringt når PIC UART mottar en byte med data. I noen av mine tidligere UART -prosjekter kunne jeg bare avstemme RX -avbruddsflagget i stedet for å måtte bruke en avbruddshåndterer. Det er ikke tilfelle for denne programvaren, spesielt for PN532 som kommuniserer med en mye høyere overføringshastighet enn RC522. UART -grensesnittet til RC522 er begrenset til 9600 baud mens standard for PN532 er 115k og kan settes så høyt som 1,288M baud. Mottatte byte lagres i et bufferområde, og hoveddelen av programvaren henter dem etter behov.

New_Msg -flagget indikerer at byte er mottatt og Byte_Count angir hvor mange. Jeg har inkludert en "Disp_Buff" -rutine i programvaren som kan kalles for å vise innholdet i mottaksbufferen under feilsøking. Noen av returmeldingene vil overfylle en typisk 1602 -skjerm, men jeg har en LCD -skjerm på 40 tegn med 2 linjer som jeg fant på et elektronisk nettsted for elektronisk overskudd. "Max_Line" -definisjonen kan angis for LCD -størrelsen. Hvis “Max_Line” er nådd, fortsetter “Disp_Buff” -rutinen med å skrive til den andre linjen. Du kan legge til en liten kode i rutinen for å fortsette til linje tre og fire hvis du har en 4-linjers LCD. For PN532 er det et flagg som kan settes slik at rutinen enten dumper alle mottatte byte eller bare dumper de 16 databytesene fra et lest svar.

Det er ikke nødvendig å slette mottaksbufferen eller Byte_Count fordi sletting av New_Msg -flagget vil føre til at Byte_Count blir slettet av avbryterbehandleren, og det er det som brukes som indeks i bufferen. New_Msg blir vanligvis slettet før hvert kommandotrinn, slik at resultatene som er spesifikke for den kommandoen, enkelt kan lokaliseres og bekreftes. I RC522 betyr det at mottaksbufferen vanligvis bare har 1 til 4 byte. I noen tilfeller, for eksempel datablokker, må Read_FIFO -kommandoen utstedes flere ganger for å flytte byte fra FIFO til mottaksbufferen. Alle kommandoresultater for PN532 havner i mottaksbufferen, så en skanningsprosedyre utføres for å finne de spesifikke byte som trengs.

Hovedløkken i programvaren søker etter en kode og autentiserer deretter taggen for lesing/skriving. For testprogramvaren som er inkludert her, blir variabelen Junk_Num endret hver gang gjennom hovedsløyfen og brukes under skrivingen til taggen. Verdiene som skrives veksler mellom verdien av Junk_Num og 1 -komplementet til Junk_Num. Til slutt leses og vises de 16 skrevne verdiene. Det er displaymeldinger for hvert trinn med forsinkede rutineanrop for å gi tid til å lese hver melding. Feilmeldinger er også gitt, men bør normalt bare oppstå hvis taggen fjernes under en operasjon.

En del av initialiseringen av programvaren er en del av koden som bare kjøres ved oppstart og hoppes over hvis en programvare tilbakestilles. Feilmeldingene avsluttes vanligvis med en tilbakestilling av programvare som en måte å gå ut av hovedsløyfen. Tilbakestillingen skjer i "Tilt" -rutinen som ganske enkelt aktiverer Watchdog Timer og deretter går inn i en uendelig sløyfe som venter på timeout.

Trinn 9: MFRC522 unik programvare

RC522-brikken krever flere instruksjoner på lavt nivå enn PN532-brikken for å oppnå kommunikasjon med koder. Det er litt som å programmere på samlingsspråk kontra programmering i "C". En annen vesentlig forskjell er at RC522 krever at kommunikasjon med taggen blir kanalisert gjennom en FIFO -buffer. Rutinene “Write_FIFO” og “Read_FIFO” håndterer disse oppgavene. MFRC522-programvaren inneholder en seksjon for mange av kommandoene på lavere nivå som hovedfunksjonene er bygd fra.

Beregningen av kontrollkommandoen for tag -kommandoen for RC522 er veldig annerledes enn for PN532. Etter at tag -kommandoen er bygget i FIFO, sendes en modulkommando for å beregne kontrollsummen. 16-bits resultatet blir ikke automatisk lagt til tag-kommandoen, men er tilgjengelig for lesing fra to 8-biters registre. Kontrollsumberegningen sletter dataene i FIFO, så den nødvendige sekvensen er som følger:

· Bygg kommandoen i FIFO

· Kommander en kontrollsumberegning

· Bygg kommandoen i FIFO igjen

· Les CRC -registrene og skriv kontrollsumbytes til FIFO

· Send enten en Transceive- eller Authenticate -kommando

Kommandoen Transceive sender FIFO -bufferen og bytter deretter automatisk til mottaksmodus for å vente på responsen fra taggen. Kommandoen Transceive må følges av innstillingen av StartSend -biten i BitFramingRegister for å faktisk overføre dataene. Kommandoen Authenticate har ikke det kravet.

Generelt bruker Arduino "C" -kodeapplikasjonene som er tilgjengelige online avbruddsflaggeregistrene og tidsavbruddsregisteret for å sikre at riktig svar blir mottatt i tide. Etter min mening er det overkill for denne ikke-tidskritiske applikasjonen. I stedet bruker jeg korte programvaretidsavbrudd for å vente på svaret og deretter bekrefte at det er riktig. Håndboken for Mifare -taggene beskriver tidspunktet for de forskjellige transaksjonene, og det er også tillatt tid for det forventede antall byte som skal mottas. Disse tidsforsinkelsene er innebygd i de fleste kommandosubrutiner på lavt nivå.

Trinn 10: PN532 unik programvare

Etter at modulen er initialisert, utføres trinnene som trengs for å finne og autentisere koden ved å skrive den riktige kommandoen etterfulgt av de nødvendige dataene. Skanningskommandoen returnerer UID som deretter brukes til autentisering. Etter det kan du lese eller skrive av taggen sende eller returnere 16-bytes for den adresserte datablokken.

Initialiseringssekvensen ble beskrevet tidligere, og den samme programvarerutinen sender også SAMConfiguration -kommandoen for å få modulen ut av "LowVbat" -tilstanden. Resten av de grunnleggende kommandoene, for eksempel Scan, Authenticate, Read/Write Tag, er bare bygget sekvensielt i de gjeldende rutinene. Kontrollsummen beregnes ved å bare legge til kommandobyttene, gjøre et komplement og deretter legge til 1 for å gjøre det til et 2’er -komplement. 8-bits resultatet legges til kommandostrengen like før postamble.

Det er ingen FIFO som i RC522, så hele svarmeldingene mottas automatisk. "Find_Response" -rutinen skanner mottaksdatabufferen for TFI (0xD5). Rutinen drar fordel av å vite hva de forventede meldingene skal være og ignorerer enkle ACK -svar som ikke inneholder data. Når TFI er funnet, er de ønskede svarene en kjent forskyvning fra den. Kommandoekko og kommandostatusbyte lagres av "Read_Buff" -rutinen for senere bekreftelse.

Det er det for dette innlegget. Sjekk mine andre elektronikkprosjekter på: www.boomerrules.wordpress.com