RC522 en PN532 RFID Basics: 10 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:25

LET WEL: ek het nou instruksies wat Arduino -kode bied vir die RC522 en PN532.

'N Tyd gelede het ek drie verskillende RFID -modules gekoop om te eksperimenteer. In 'n vorige projek het ek uiteengesit hoe ek 'n eenvoudige 125 kHz-module kan gebruik om 'n basiese beveiligingsfunksie te verrig. Sulke modules gebruik leesalleen-etikette, sodat die proses na die ID soek, stoor indien nodig en vergelyk met gestoorde ID's. Die ander modules wat ek gekoop het, werk op 13,56 MHz en gebruik etikette wat beide gelees en geskryf kan word, so dit is 'n vermorsing om dit bloot vir basiese veiligheid te gebruik. Die twee algemene modules gebruik óf die RC522 -chip óf die PN532 -chip - albei gemaak deur NXP.

As u enige van my ander projekte gelees het, weet u dat ek daarvan hou om goedkoop PIC -mikrobeheerders te gebruik en in monteringstaal te programmeer. Wat ek dus gesoek het, was 'n reeks stappe wat nodig was om met die modules en die RFID -etikette te praat. Alhoewel daar baie voorbeeldprogramme aanlyn vir die modules is, is die meeste daarvan in 'C' sagteware vir die Arduino geskryf en gebruik hulle die SPI -koppelvlak. Die handleidings vir die skyfies en die Mifare -etikette verg ook 'n bietjie ontsyfering. Hierdie pos handel hoofsaaklik oor die inligting wat ek wou gehad het toe ek met die projek begin het. Ek bevat ook sagteware -programme vir die saamstel van PIC vir die uitvoering van die basiese opdragte wat deur elke module vereis word. Selfs as u nie 'n PIC en/of monteringstaal gebruik nie, moet die bronkode u ten minste 'n goeie idee gee van die spesifieke opdragte wat nodig is om elke stap uit te voer.

Stap 1: Seriële koppelvlakke

Albei skyfies wat op hierdie modules gebruik word, kan via SPI, I2C of UART (HSSP) verbind word. Die PN532 -module het 'n DIP -skakelaar wat gebruik word om die gewenste koppelvlak te kies, maar die MFRC522 -module is gekoppel aan die SPI -koppelvlak. Ek verkies om die ingeboude UART van die PIC te gebruik, so ek het aanlyn gejag om te sien of daar 'n manier is om die MFRC522-module in die UART-modus te kry. Wat ek gevind het, was dat die sny van een spoor op die bord die truuk sou doen. Die snit verwyder effektief 3,3 volt van die EA -pen van die chip. Tegnies moet die EA -pen dan aan die grond gekoppel word, maar nie baie mense kan die soldeerpunt bereik nie, gegewe die digtheid van die chippen. Moenie bekommerd wees nie, want die EA-pen het nie 'n interne optrek nie en dryf nie soos die ou TTL-logiese insette nie. Raadpleeg die skyfiediagram en die prentjie op die bord om die plek te sny. Maak seker dat u slegs die kort spoor na die EA -pen sny.

Stap 2: Hardeware

Die hardewareverbindings vir UART -kommunikasie word in die diagram hierbo getoon. Die UART -verbindings vir die MFRC522 is nie op die bord gemerk nie, maar, soos in die skema getoon, ontvang die SDA -pen UART -data en die MISO -pen stuur UART -data oor. Die PN532 -module het die UART -merke aan die onderkant van die bord.

Beide modules werk op 3,3 volt en die 5-volt logiese vlak van die PIC TX-pen moet ook beperk word. Die LCD-verbinding is die standaard 4-bis-opstelling wat in 'n aantal van my vorige projekte gebruik is. Die standaardformaat vir al die boodskappe is ingestel vir die standaard 1602 LCD (16 karakters by 2 reëls). Ek het ook 'n LCD -skerm van 40 tekens by 2 reëls wat ek tydens onopsporing van grondstowwe gebruik vir rou data, sodat ek 'n definisie in die sagteware ingesluit het waarmee ek voordeel kan trek uit die ekstra vertoonruimte.

Stap 3: Datablokke

Die Mifare Classic 1k -etikette wat vir hierdie projek gebruik word, is opgestel as 16 sektore, vier datablokke per sektor, 16 grepe per datablok. Van die 64 datablokke is slegs 47 bruikbaar. Datablok 0 bevat vervaardigerdata en blokke 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 en 63 word sleepwablokke genoem. Die sleepwa -blokke is die laaste in elke sektor en dit bevat twee sleutels en die blok -toegangsstukke. Die sleutels en bloktoegangstukkies is slegs van toepassing op die datablokke in daardie sektor, sodat u verskillende sleutels en toegangsreëls vir elke sektor kan hê. Die verstek sleutels is ingestel op "FF FF FF FF FFh". Vir hierdie basiese projek gebruik ek slegs een datablokkie en bewaar die verstek sleutels en toegangsstukke. Daar is baie dokumente wat verband hou met hierdie kaarte, so soek net 'Mifare' aanlyn of besoek die NXP -webwerf as u dit meer in diepte wil ondersoek.

Stap 4: Algemene werking

Alhoewel beide modules uniek is in die manier waarop toegang verkry word en die manier waarop hulle toegang tot die etikette verkry, is daar 'n algemene proses wat nodig is om die taak te verrig. Vir hierdie projek neem ons aan dat die etikette die Mifare Classic 1k -tipe is en dat ons slegs een tag op 'n slag in die antennaveld toelaat. Die basiese stappe word hieronder gedefinieer.

· Initialiseer die module: In die algemeen is dit nodig, soos die skryf van waardes in registers in die chip, die stuur van "wek" -opdragte en die aanskakel van die antenna. In 'n program wat op batterye werk, wil u die antenna aan en af skakel om die battery te bespaar, maar vir hierdie eenvoudige toepassing skakel ons dit een keer aan en laat dit dan aan.

· Maak die kripto -vlag skoon (slegs 522): As 'n merker geverifieer word, word 'n vlag ingestel om die gebruiker te laat weet dat kommunikasie met die etiket geïnkripteer sal word. Die vlag moet deur die gebruiker skoongemaak word voor die volgende skandering, selfs al is die etiket wat geskandeer word dieselfde.

· Soek na 'n etiket: die module vra basies 'Is daar iemand?' en die etiket reageer "Ek is hier". As die module nie vinnig reageer nie, luister dit nie meer nie. Dit beteken dat ons herhaaldelik scanopdragte na die module moet stuur totdat dit 'n etiket kry.

· Kry die etiket Gebruikersidentifikasienommer (UID): Die merker sal op die skanderingversoek reageer met beperkte inligting, soos die tipe merker wat dit is. Dit beteken dat ons moontlik 'n ander opdrag moet stuur om die UID daarvan te kry. Die UID is vier grepe vir die Mifare Classic 1k -etikette. Dit kan langer wees vir ander etikette, maar hierdie projek spreek dit nie aan nie.

· Kies die merker (slegs 522): Die UID word gebruik om die merker te kies wat die gebruiker wil verifieer vir lees en skryf. Dit is gebaseer op die moontlikheid dat daar meer as een tag in die antennaveld kan wees. Dit is nie die geval met ons eenvoudige toepassing nie, maar ons moet in elk geval die etiket kies.

· Verifieer die etiket: hierdie stap is nodig as ons die etiket wil lees of skryf. As ons net wil onderskei tussen etikette vir 'n eenvoudige beveiligingstoepassing, dan is die UID genoeg. Verifikasie vereis dat ons die UID ken en dat ons die kripto -sleutel ken vir die datasektor van die etiket waartoe ons toegang wil hê. Vir hierdie projek bly ons by die standaard sleutels, maar my opvolgprojek verander die sleutels sodat die etiket as 'n elektroniese beursie gebruik kan word.

· Lees of skryf die etiket: Lees gee altyd al die 16 grepe van die verlangde datablok terug. Skrywe vereis dat al 16 grepe gelyktydig geskryf word. As u 'n ander blok in dieselfde datasektor wil lees of skryf, hoef die tag nie weer geverifieer te word nie. As u 'n blok in 'n ander datasektor wil lees of skryf, moet die etiket weer geverifieer word met die sleutel vir die sektor.

Stap 5: MFRC522 Module -toegangsvolgorde

Die opstartroetine bevat hierdie basiese stappe wat gevind word in die meeste toepassings waarna ek gekyk het:

· Stuur dummy data byte (sien die volgende paragraaf)

· Sagte herstel

· Stel RF -ontvanger -versterking in (as iets anders as die standaard verlang word)

· Stel ASK -modulasiepersentasie op 100%

· Stel saadwaarde vir CRC berekeninge

· Skakel die antenna aan

· Kry firmware -weergawe (nie nodig nie)

Om een of ander onverklaarbare rede word my module aangeskakel en dink dat dit 'n skryfopdrag ontvang het sonder die databyte. Ek weet nie of dit net 'n probleem met my module is nie, maar ek het elders geen verwysings daarna gesien nie. Ek het eksperimenteer met hardeware- en sagteware -herstel, en ek het nie die probleem opgelos nie. My oplossing was om 'n dom leesoproep by te voeg om "0" (ongedefinieerd) aan die begin van die module -inisialiseringsroetine te registreer. As die module dit as data vir die onbekende skryfopdrag beskou, blyk daar geen nadelige gevolge te wees nie. As dit dit as 'n leesopdrag beskou, gebeur daar niks nuttigs nie. Dit pla my dat ek die probleem nie volledig kan definieer nie, veral omdat 'n hardeware -herstel van net die module die probleem nie oplos nie.

Die RC522 -chip bestaan uit 'n aantal registers, waarvan die meeste gelees en geskryf is. Om 'n skryfwerk uit te voer, word die registernommer na die module gestuur, gevolg deur die waarde om te skryf. Om 'n lesing uit te voer, word die registernommer 0x80 bygevoeg en dit word na die module gestuur. Die reaksie op 'n skryfopdrag is 'n eggo van die register wat verkry is. Die antwoord op 'n leesopdrag is die inhoud van die register. Die sagteware maak gebruik van hierdie kennis om te verifieer dat die opdrag korrek uitgevoer is.

Stap 6: PN532 -module -toegangsvolgorde

Die opstartroetine bevat die volgende stappe:

· Stuur 'n inisialiseringstring: Dit is spesifiek vir die UART -koppelvlak. Die handleiding sê dat die UART-koppelvlak sal wakker word op die vyfde stygende rand wat op die koppelvlak opgespoor word. Dit word aanbeveel om 0x55, 0x55, 0x00, 0x00, 0x00, 0x00 te stuur. Daar moet meestal net 'n voldoende aantal karakters met stygende rande wees, en dit mag nie soos 'n opdrag -aanhef lyk nie (00 00 FF).

· Ontwaak die module: dit word in die gebruikershandleiding begrawe en toon dat die module begin in 'n soort slaaptoestand genaamd “LowVbat”. Om hierdie toestand te verlaat, moet ons 'n "SAMConfiguration" opdrag stuur.

Die PN532 verwag dat opdragte gestuur moet word in 'n gedefinieerde boodskapformaat wat 'n aanhef, die boodskap en 'n postamble bevat. Die antwoordboodskappe volg dieselfde formaat. Die opdrag- en antwoordboodskappe bevat beide 'n TFI (Frame Identifier) en 'n opdragweergawe. Die opdrag gebruik 'n TFI van 0xD4 en die antwoord gebruik 0xD5. Die opdragweergawes wissel, maar die antwoord sal altyd die opdragweergawe verhoog en dit terugstuur in die byte na die TFI. Met hierdie konsekwentheid kan die antwoordboodskappe maklik na die relevante inligting gesoek word.

Elke opdragboodskap (na aanleiding van die aanhef) bestaan uit die lengte van die boodskap, die 2 se aanvulling van die boodskaplengte, TFI, opdrag, data, kontrolesom en postamble. Die sagteware bou die individuele opdragte en roep dan 'n roetine op wat die kontrolesom bereken en die postamble byvoeg.

Die boodskapformaat vir die antwoord is soortgelyk aan die van die opdrag. 'N Tipiese antwoord sal 'n ACK (00 00 FF 00 FF 00) insluit, gevolg deur die spesifieke reaksie op die opdrag. Elke opdragreaksie begin met 'n aanhef van 00 00 FF. Die reaksie moet ook 'n TFI -byte van D5 hê, gevolg deur die opdrag nommer verhoog met 1. Vir ons "SAMConfiguration" -opdrag (14) is dit 15. Die "SAMConfiguration" -opdrag kry die antwoord: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Daar is ander modulespesifieke opdragte wat gestuur kan word, maar dit is nie nodig vir hierdie toepassing nie. Ek het egter 'n roetine ingesluit wat geskakel kan word om die weergawe van die firmware op te haal. 'N Tipiese antwoord (na die ACK en aanhef) sou wees: 06 FA D5 03 32 01 06 07 E8 00. Die "01 06 07" dui firmware -weergawe nommer 1.6.7 aan.

Stap 7: Tag -toegangsvolgorde

Nadat die module gereed is, kan ons opdragte spesifiek vir die etikette stuur. Om etiketdata te kan lees of skryf, moet ons die identifikasienommer (UID) hê. Die UID en die sleutel sal dan gebruik word om 'n spesifieke tagdatasektor vir lees/skryf te magtig. Tagdata lees/skryf word altyd op al 16 grepe in 'n gespesifiseerde datablok gedoen. Dit beteken dat die tipiese toepassing die datablok sal lees, die data na wens aanpas en dan die nuwe data na die etiket terugskryf.

Stap 8: sagteware

Die sagteware vir onderbrekingshanteerder word gebel wanneer die PIC UART 'n greep data ontvang. In sommige van my vorige UART -projekte kon ek net die RX -interrupt -vlag ondersoek, in plaas daarvan dat ek 'n interrupt -hanteerder moes gebruik. Dit is nie die geval vir hierdie sagteware nie, veral nie vir die PN532 wat met 'n baie hoër baud -tempo kommunikeer as die RC522. Die UART -koppelvlak van die RC522 is beperk tot 9600 baud, terwyl die standaard vir die PN532 115k is en tot 1.288M baud gestel kan word. Die ontvangen grepe word in 'n buffergebied gestoor, en die grootste deel van die sagteware haal dit na behoefte op.

Die New_Msg -vlag dui aan dat grepe ontvang is en Byte_Count dui aan hoeveel. Ek het 'n 'Disp_Buff' -roetine in die sagteware ingesluit wat geroep kan word om die inhoud van die ontvangbuffer tydens ontfouting te vertoon. Sommige van die terugboodskappe sal oorloop op 'n tipiese 1602 -skerm, maar ek het 'n LCD -skerm van 40 tekens by 2 reëls wat ek op 'n aanlyn elektroniese webwerf gevind het. Die definisie van 'Max_Line' kan vir u LCD -grootte ingestel word. As “Max_Line” bereik word, gaan die “Disp_Buff” -roetine voort deur na die tweede reël te skryf. U kan 'n bietjie kode by die roetine voeg om op reëls drie en vier voort te gaan as u 'n LCD-skerm met 4 reëls het. Vir die PN532 is daar 'n vlag wat so ingestel kan word dat die roetine óf alle gegewe grepe stort, óf net die 16 databytes uit 'n leesreaksie stort.

Dit is nie nodig om die ontvangbuffer of Byte_Count uit te vee nie, want as die New_Msg -vlag verwyder word, sal Byte_Count die interrupt -hanteerder laat uitvee, en dit word gebruik as die indeks in die buffer. New_Msg word gewoonlik voor elke opdragstap skoongemaak, sodat die spesifieke resultate vir die opdrag maklik opgespoor en geverifieer kan word. In die RC522 beteken dit dat die ontvangsbuffer gewoonlik slegs 1 tot 4 grepe het. In sommige gevalle, soos databloklesings, moet die Read_FIFO -opdrag verskeie kere uitgereik word om die grepe van die FIFO na die ontvangbuffer te skuif. Alle opdragresultate vir die PN532 beland in die ontvangbuffer, sodat 'n skanderingprosedure uitgevoer word om die spesifieke grepe op te spoor.

Die hooflus in die sagteware soek na 'n etiket en verifieer dan die etiket vir lees/skryf. Vir die toetsprogrammatuur wat hier ingesluit word, word die veranderlike Junk_Num elke keer deur die hooflus gewysig en word dit gebruik tydens die skryf van die etiket. Die waardes wat geskryf word, wissel tussen die waarde van Junk_Num en die 1 se komplement van Junk_Num. Laastens word die 16 geskrewe waardes gelees en vertoon. Daar is vertoonboodskappe vir elke stap met vertragingsroetine -oproepe om tyd te gee om elke boodskap te lees. Foutboodskappe word ook verskaf, maar moet normaalweg slegs voorkom as die etiket tydens 'n operasie verwyder word.

'N Gedeelte van die inisialisering van die sagteware is 'n gedeelte van die kode wat slegs uitgevoer word tydens opstart en oorgeslaan word as 'n sagteware -herstel opgespoor word. Die foutboodskappe eindig gewoonlik met 'n sagteware -herstel as 'n manier om die hooflus te verlaat. Die herstel gebeur in die 'kantel' -roetine, wat die Watchdog Timer eenvoudig moontlik maak en dan in 'n oneindige kringloop loop en wag vir die time -out.

Stap 9: MFRC522 Unieke sagteware

Die RC522-chip benodig meer instruksies op 'n lae vlak as die PN532-chip om kommunikasie met etikette te bewerkstellig. Dit is soortgelyk aan programmering in monteringstaal versus programmering in "C". 'N Ander belangrike verskil is dat die RC522 vereis dat kommunikasie met die etiket deur 'n FIFO -buffer gestuur word. Die roetines “Write_FIFO” en “Read_FIFO” hanteer hierdie take. Die MFRC522 sagteware bevat 'n afdeling vir baie van die laer vlak opdragte waaruit die hooffunksies gebou is.

Die kontrolekomsberekening van die tagopdrag vir die RC522 is baie anders as vir die PN532. Nadat die tagopdrag in die FIFO gebou is, word 'n moduleopdrag gestuur om die kontrolesom te bereken. Die 16-bis-resultaat word nie outomaties by die tag-opdrag gevoeg nie, maar kan gelees word uit twee 8-bis-registers. Die kontrolesomberekening vee die data in die FIFO uit, sodat die vereiste volgorde soos volg is:

· Bou die opdrag in die EIEU

· Beveel 'n kontrolesomberekening

· Bou weer die opdrag in die EIEU

· Lees die CRC -registers en skryf die tjeksom -grepe aan die EIEU

· Stuur óf 'n Transceive- of Authenticate -opdrag

Die opdrag Transceive sal die FIFO -buffer stuur en dan outomaties oorskakel na die ontvangmodus om te wag vir die reaksie van die etiket. Die opdrag Transceive moet gevolg word deur die instelling van die StartSend -bit in die BitFramingRegister om die data werklik te kan oordra. Die opdrag Authenticate het nie die vereiste nie.

Oor die algemeen gebruik die Arduino -C -kode -toepassings wat aanlyn beskikbaar is, die interrupt -vlagregisters en die time -out -register om te verseker dat die korrekte antwoord betyds ontvang word. Na my mening is dit te veel vir hierdie nie-tydse kritiese toepassing. In plaas daarvan gebruik ek kort sagteware -time -out om op die antwoord te wag en dan te verifieer dat dit korrek is. Die handleiding vir die Mifare -etikette gee 'n uiteensetting van die tydsberekening vir die verskillende transaksies en die tyd word ook toegelaat om die verwagte aantal grepe te ontvang. Hierdie tydvertragings is ingebou in die meeste van die lae-opdrag-subroutines.

Stap 10: Unieke sagteware PN532

Nadat die module geïnitialiseer is, word die stappe wat nodig is om die etiket te vind en te verifieer, uitgevoer deur die toepaslike opdrag te skryf, gevolg deur die nodige data. Die scanopdrag gee die UID terug wat dan vir die verifikasie gebruik word. Daarna lees of skryf die etiket die 16-grepe vir die geadresseerde datablok, of stuur dit terug.

Die initialiseringsvolgorde is vroeër uiteengesit, en dieselfde sagteware -roetine stuur ook die SAMConfiguration -opdrag om die module uit die 'LowVbat' -toestand te kry. Die res van die basiese opdragte, soos Scan, Authenticate, Read/Write Tag, word net opeenvolgend in die toepaslike roetines gebou. Die kontrolesom word bereken deur net die opdraggrepe op te tel, 'n komplement uit te voer en dan 1 by te voeg om dit 'n 2 se komplement te maak. Die 8-bis-resultaat word by die opdragstring gevoeg net voor die postamble.

Daar is geen FIFO soos in die RC522 nie, dus word die volledige antwoordboodskappe outomaties ontvang. Die “Find_Response” -roetine skandeer die ontvangsdatabuffer vir die TFI (0xD5). Die roetine trek voordeel uit die wete wat die verwagte boodskappe moet wees en ignoreer eenvoudige ACK -antwoorde wat geen data bevat nie. Sodra die TFI gevind is, is die gewenste antwoorde 'n bekende verrekening daarvan. Die opdrag echo en opdragstatus grepe word deur die 'Read_Buff' roetine gestoor vir latere verifikasie.

Dit is dit vir hierdie pos. Kyk na my ander elektroniese projekte by: www.boomerrules.wordpress.com