RC522 și PN532 RFID Noțiuni de bază: 10 pași

2024 Autor: John Day | [email protected]. Modificat ultima dată: 2024-01-30 11:44

NOTĂ: Acum am instrumente care oferă cod Arduino pentru RC522 și PN532.

Acum ceva timp am cumpărat trei module RFID diferite pentru experimentare. Într-un proiect anterior am detaliat cum să utilizați un modul simplu de 125 kHz pentru a realiza o funcție de securitate de bază. Modulele de acest fel folosesc etichete de numai citire, astfel încât procesul să scaneze ID-ul, să stocheze dacă se dorește și să se compare cu ID-urile stocate. Celelalte module pe care le-am cumpărat funcționează la 13,56 MHz și utilizează etichete care pot fi citite și scrise, astfel încât este un fel de risipă să le folosești pur și simplu pentru securitate de bază. Cele două module comune folosesc fie cipul RC522, fie cipul PN532 - ambele realizate de NXP.

Dacă ați citit oricare dintre celelalte proiecte ale mele, știți că îmi place să folosesc microcontrolere și programe PIC ieftine în limbaj de asamblare. Deci, ceea ce căutam era o secvență de pași necesari pentru a vorbi cu modulele și cu etichetele RFID. Deși există o mulțime de exemple de programe online pentru module, majoritatea sunt scrise în software-ul „C” pentru Arduino și utilizează interfața SPI. De asemenea, manualele pentru cipuri și pentru etichetele Mifare necesită un pic de descifrare. Această postare este în primul rând despre informațiile pe care mi-aș dori să le am când am început proiectul. De asemenea, includ programe software de asamblare PIC pentru efectuarea comenzilor de bază cerute de fiecare modul. Chiar dacă nu utilizați un PIC și / sau un limbaj de asamblare, codul sursă ar trebui să vă ofere cel puțin o idee bună asupra comenzilor specifice necesare pentru a efectua fiecare pas.

Pasul 1: interfețe seriale

Ambele cipuri utilizate pe aceste module sunt capabile de interfață prin SPI, I2C sau UART (HSSP). Modulul PN532 are un comutator DIP care este utilizat pentru a selecta interfața dorită, dar modulul MFRC522 este cablat pentru interfața SPI. Prefer să folosesc UART-ul încorporat al PIC, așa că am vânat online pentru a vedea dacă există o modalitate de a introduce modulul MFRC522 în modul UART. Ceea ce am constatat a fost că tăierea unei urme pe tablă ar face trucul. Tăierea elimină în mod eficient 3,3 volți de la pinul EA al cipului. Din punct de vedere tehnic, pinul EA ar trebui să fie conectat la masă, dar nu mulți oameni pot extrage acea operație de lipit, având în vedere densitatea pinului cipului. Nu vă faceți griji, totuși, deoarece pinul EA nu are un pull-up intern și nu „plutește” așa cum au vechile intrări logice TTL. Consultați schema cipurilor și imaginea secțiunii plăcii pentru locul de tăiat. Asigurați-vă că tăiați doar urmele scurte mergând direct la pinul EA.

Pasul 2: Hardware

Conexiunile hardware pentru comunicațiile UART sunt prezentate în diagrama de mai sus. Conexiunile UART pentru MFRC522 nu sunt marcate pe placă, dar, așa cum se arată în schemă, pinul SDA primește date UART, iar pinul MISO transmite date UART. Modulul PN532 are marcajele UART în partea inferioară a plăcii.

Ambele module rulează pe 3,3 volți, iar nivelul logic de 5 volți de la pinul PIC TX trebuie, de asemenea, să fie limitat. Conexiunea LCD este configurarea standard pe 4 biți care a fost utilizată în mai multe proiecte anterioare. Formatul implicit pentru toate mesajele este setat pentru ecranul LCD standard 1602 (16 caractere pe 2 rânduri). Am, de asemenea, un ecran LCD de 40 de caractere pe 2 linii pe care îl folosesc pentru depozitarea datelor brute în timpul depanării, așa că am inclus o definire în software care îmi permite să profitez de spațiul de afișare suplimentar.

Pasul 3: Blocuri de date

Etichetele Mifare Classic 1k utilizate pentru acest proiect sunt configurate ca 16 sectoare, patru blocuri de date pe sector, 16 octeți pe bloc de date. Dintre cele 64 de blocuri de date, doar 47 sunt de fapt utilizabile. Blocul de date 0 conține datele producătorului și blocurile 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 și 63 sunt denumite blocuri de remorci. Blocurile Trailer sunt ultimele din fiecare sector și conțin două chei și biții de acces la bloc. Cheile și biții de acces pentru blocuri se aplică doar blocurilor de date din acel sector, astfel încât să puteți avea chei și reguli de acces diferite pentru fiecare sector. Tastele implicite sunt setate la „FF FF FF FF FFh”. Pentru acest proiect de bază folosesc un singur bloc de date și păstrez cheile implicite și biții de acces. Există o mulțime de documente legate de aceste carduri, așa că trebuie doar să căutați online „Mifare” sau să vizitați site-ul web NXP dacă doriți să le explorați mai în profunzime.

Pasul 4: Operațiune generală

Deși ambele module sunt unice prin modul în care sunt accesate și modul în care accesează etichetele, există un proces general care este necesar pentru a face treaba. Pentru acest proiect presupunem că etichetele sunt de tip Mifare Classic 1k și că permitem doar o etichetă la un moment dat în câmpul antenei. Pașii de bază sunt definiți mai jos.

· Inițializați modulul: în general, acest lucru necesită lucruri precum scrierea valorilor în registrele din cip, trimiterea comenzilor de „trezire” și pornirea antenei. Într-o aplicație cu baterie, ați dori să puteți porni și opri antena pentru a economisi bateria, dar pentru această aplicație simplă o pornim o dată și apoi o lăsăm pornită.

· Ștergeți steagul criptografic (numai 522): atunci când o etichetă este autentificată, un steag este setat pentru a informa utilizatorul că comunicările cu eticheta vor fi criptate. Acest semnal trebuie să fie șters de către utilizator înainte de următoarea scanare, chiar dacă eticheta scanată este aceeași.

· Căutați o etichetă: modulul întreabă practic „Există cineva acolo?” iar eticheta răspunde „Sunt aici”. Dacă modulul nu primește un răspuns rapid, acesta nu mai este ascultat. Asta înseamnă că trebuie să trimitem în mod repetat comenzi de scanare către modul până când acesta găsește o etichetă.

· Obțineți eticheta Numărul de identificare a utilizatorului (UID): eticheta va răspunde cererii de scanare cu informații limitate, cum ar fi tipul de etichetă. Asta înseamnă că este posibil să trebuiască să trimitem o altă comandă pentru a obține UID-ul său. UID este de patru octeți pentru etichetele Mifare Classic 1k. Dacă poate fi mai lung pentru alte etichete, dar acest proiect nu le abordează.

· Selectați eticheta (numai 522): UID este utilizat pentru a selecta eticheta pe care utilizatorul dorește să o autentifice pentru citiri și scrieri. Aceasta se bazează pe posibilitatea ca în câmpul antenei să existe mai multe etichete. Nu este cazul aplicației noastre simple, dar oricum trebuie să selectăm eticheta.

· Autentificați eticheta: acest pas este necesar dacă dorim să citim sau să scrieți eticheta. Dacă tot ce vrem să facem este să diferențiem etichetele pentru o aplicație simplă de securitate, atunci UID este suficient. Autentificarea necesită cunoașterea UID-ului și cunoașterea cheii criptografice pentru sectorul de date al etichetei pe care dorim să o accesăm. Pentru acest proiect rămânem cu tastele implicite, dar proiectul meu de continuare schimbă tastele astfel încât eticheta să poată fi folosită ca portofel electronic.

· Citiți sau scrieți eticheta: citirile returnează întotdeauna toți cei 16 octeți ai blocului de date solicitat. Scrierile necesită ca toate cele 16 octeți să fie scrise în același timp. Dacă doriți să citiți sau să scrieți un alt bloc în același sector de date, eticheta nu trebuie să fie autentificată din nou. Dacă doriți să citiți sau să scrieți un bloc într-un sector de date diferit, atunci eticheta trebuie autentificată din nou folosind cheia pentru sectorul respectiv.

Pasul 5: Secvența de acces la modulul MFRC522

Rutina de pornire include acești pași de bază găsiți în majoritatea aplicațiilor la care m-am uitat:

· Trimiteți octet de date fictive (consultați paragraful următor)

· Resetare soft

· Setați câștigul receptorului RF (dacă se dorește altceva decât implicit)

· Setați procentul de modulare ASK la 100%

· Setați valoarea seed pentru calculele CRC

· Porniți antena

· Obțineți versiunea de firmware (nu este necesară)

Din anumite motive inexplicabile, modulul meu se pornește și crede că a primit o comandă de scriere fără octetul de date. Nu știu dacă aceasta este doar o problemă cu modulul meu, dar nu am văzut nicio referință la el în altă parte. Am experimentat atât resetări hardware, cât și software și niciunul nu a remediat problema. Soluția mea a fost să adaug un apel fals citit pentru a înregistra „0” (nedefinit) la începutul rutinei de inițializare a modulului. Dacă modulul vede acest lucru ca date pentru comanda de scriere necunoscută, nu pare să existe efecte negative. Dacă o vede ca o comandă de citire, atunci nu se întâmplă nimic util. Mă deranjează faptul că nu pot defini complet problema, mai ales având în vedere că o resetare hardware a doar modulului nu rezolvă problema.

Cipul RC522 este compus dintr-un număr de registre, majoritatea fiind citite și scrise. Pentru a efectua o scriere, numărul registrului este trimis modulului urmat de valoarea de scris. Pentru a efectua o citire, numărul de registru are 0x80 adăugat și este trimis modulului. Răspunsul la o comandă de scriere este un ecou al registrului accesat. Răspunsul la o comandă de citire este conținutul registrului. Software-ul profită de aceste cunoștințe pentru a verifica dacă comanda a fost executată corect.

Pasul 6: Secvența de acces a modulului PN532

Rutina de pornire include acești pași necesari:

· Trimiteți un șir de inițializare: Acesta este specific interfeței UART. Manualul precizează că interfața UART se va trezi pe a cincea margine ascendentă detectată pe interfață. Se recomandă trimiterea 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. În cea mai mare parte, trebuie doar să existe un număr suficient de caractere cu margini ascendente și nu trebuie să arate ca un preambul de comandă (00 00 FF).

· Treziți modulul: îngropat în manualul de utilizare arată că modulul se inițializează într-un fel de stare de repaus numită „LowVbat”. Pentru a ieși din această stare, trebuie să trimitem o comandă „SAMConfiguration”.

PN532 se așteaptă ca comenzile să fie trimise într-un format de mesaj definit care include un preambul, mesajul și un postambul. Mesajele de răspuns urmează același format. Mesajele de comandă și răspuns includ ambele un TFI (Frame Identifier) și o versiune de comandă. Comanda folosește un TFI de 0xD4, iar răspunsul folosește 0xD5. Versiunile de comandă variază, dar răspunsul va crește întotdeauna versiunea de comandă și o va returna în octetul care urmează TFI. Această consistență permite ca mesajele de răspuns să fie scanate cu ușurință pentru informații relevante.

Fiecare mesaj de comandă (urmând preambulul) constă din lungimea mesajului, complementul 2 al lungimii mesajului, TFI, comandă, date, sumă de control și postamble. Software-ul construiește comenzile individuale și apoi apelează o rutină care calculează suma de control și adaugă postamble.

Formatul mesajului pentru răspuns este similar cu cel al comenzii. Un răspuns tipic va include un ACK (00 00 FF 00 FF 00) urmat de răspunsul specific la comandă. Fiecare răspuns de comandă începe cu un preambul de 00 00 FF. Răspunsul ar trebui să aibă, de asemenea, un octet TFI de D5 urmat de numărul de comandă mărit cu 1. Pentru comanda „SAMConfiguration” (14) care ar fi 15. Comanda „SAMConfiguration” primește acest răspuns: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Există alte comenzi specifice modulelor care pot fi trimise, dar nu sunt necesare pentru această aplicație. Cu toate acestea, am inclus o rutină care poate fi apelată pentru a recupera numărul versiunii firmware-ului. Un răspuns tipic (după ACK și preambul) ar fi: 06 FA D5 03 32 01 06 07 E8 00. „01 06 07” indică numărul versiunii firmware 1.6.7.

Pasul 7: secvența de acces la etichete

După ce modulul se pregătește, putem trimite comenzi specifice etichetelor. Pentru a citi sau scrie date de etichetă trebuie să avem numărul de identificare (UID). UID și cheia vor fi apoi utilizate pentru a autoriza un anumit sector de date pentru etichete pentru citiri / scrieri. Citirile / scrierile de date ale etichetelor se fac întotdeauna pe toți cei 16 octeți dintr-un bloc de date specificat. Asta înseamnă că aplicația tipică va citi blocul de date, va modifica datele după cum doriți și apoi va scrie noile date înapoi în etichetă.

Pasul 8: Software

Programul de gestionare a întreruperilor este apelat ori de câte ori PIC UART primește un octet de date. În unele dintre proiectele mele UART anterioare, am reușit să sondez semnalizatorul de întrerupere RX în loc să trebuiască să folosesc un handler de întrerupere. Nu este cazul acestui software, în special pentru PN532 care comunică la o rată de transmisie mult mai mare decât RC522. Interfața UART a RC522 este limitată la 9600 baud, în timp ce valoarea implicită pentru PN532 este 115k și poate fi setată la 1,288M baud. Octetii primiți sunt stocați într-o zonă tampon și partea principală a software-ului le recuperează după cum este necesar.

Semnalizatorul New_Msg indică faptul că au fost primiți octeți, iar Byte_Count indică câți. Am inclus o rutină „Disp_Buff” în software care poate fi apelată pentru a afișa conținutul bufferului de primire în timpul depanării. Unele dintre mesajele de returnare vor revărsa un afișaj tipic 1602, dar am un ecran LCD de 40 de caractere pe 2 linii pe care l-am găsit la un site online de surplus de electronică. Definiția „Max_Line” poate fi setată pentru dimensiunea LCD. Dacă se atinge „Max_Line”, rutina „Disp_Buff” continuă scriind pe a doua linie. Puteți adăuga un mic cod la acea rutină pentru a continua pe liniile trei și patru dacă aveți un ecran LCD cu 4 linii. Pentru PN532 există un semnal care poate fi setat astfel încât rutina fie să descarce toate octeții primiți, fie să descarce doar cei 16 octeți de date dintr-un răspuns citit.

Nu este nevoie să ștergeți bufferul de primire sau Byte_Count, deoarece ștergerea semnalizatorului New_Msg va face ca Byte_Count să fie eliminat de către gestionarul de întreruperi și asta este ceea ce este folosit ca index în buffer. New_Msg este de obicei șters înainte de fiecare pas de comandă, astfel încât rezultatele specifice acelei comenzi să poată fi ușor localizate și verificate. În RC522 asta înseamnă că tamponul de recepție are de obicei doar 1 până la 4 octeți. În unele cazuri, cum ar fi citirea blocurilor de date, comanda Read_FIFO trebuie emisă de mai multe ori pentru a muta octeții din FIFO în bufferul de recepție. Toate rezultatele comenzilor pentru PN532 ajung în bufferul de recepție, astfel încât se efectuează o procedură de scanare pentru a localiza octeții specifici necesari.

Bucla principală din software caută o etichetă și apoi autentifică eticheta pentru citiri / scrieri. Pentru software-ul de testare inclus aici variabila Junk_Num este modificată de fiecare dată prin bucla principală și este utilizată în timpul scrierii la etichetă. Valorile scrise alternează între valoarea Junk_Num și complementul 1 al Junk_Num. În cele din urmă, cele 16 valori scrise sunt citite și afișate. Există mesaje de afișare pentru fiecare pas cu întârziere a apelurilor de rutină pentru a permite timp pentru citirea fiecărui mesaj. Mesaje de eroare sunt, de asemenea, furnizate, dar ar trebui să apară în mod normal numai dacă eticheta este eliminată în timpul unei operații.

O parte din inițializarea software-ului este o secțiune de cod care se execută numai la pornire și este omisă dacă este detectată o resetare a software-ului. Mesajele de eroare se încheie, în general, cu o resetare software ca o modalitate de a ieși din bucla principală. Resetarea se întâmplă în rutina „Tilt”, care pur și simplu activează Watchdog Timer și apoi intră într-o buclă infinită care așteaptă expirarea.

Pasul 9: Software unic MFRC522

Cipul RC522 necesită mai multe instrucțiuni de nivel scăzut decât cipul PN532 pentru a realiza comunicări cu etichete. Este un fel de programare în limbaj de asamblare versus programare în „C”. O altă diferență semnificativă este că RC522 necesită ca comunicările cu eticheta să fie canalizate printr-un buffer FIFO. Rutinele „Write_FIFO” și „Read_FIFO” gestionează aceste sarcini. Software-ul MFRC522 include o secțiune pentru multe dintre comenzile de nivel inferior din care sunt construite funcțiile principale.

Calculul sumei de verificare a comenzii de etichetă pentru RC522 este foarte diferit de cel pentru PN532. După ce comanda de etichetă este încorporată în FIFO, este trimisă o comandă de modul pentru a calcula suma de control. Rezultatul pe 16 biți nu este adăugat automat la comanda de etichetare, dar este disponibil pentru citirea din două registre de 8 biți. Calculul sumei de verificare șterge datele din FIFO, astfel încât secvența necesară este următoarea:

· Construiți comanda în FIFO

· Comandați un calcul al sumei de control

· Construiți din nou comanda în FIFO

· Citiți registrele CRC și scrieți octeții sumelor de verificare în FIFO

· Trimiteți o comandă Transceive sau Authenticate

Comanda Transceive va transmite bufferul FIFO și apoi va trece automat în modul de recepție pentru a aștepta răspunsul de la tag. Comanda Transceive trebuie urmată de setarea bitului StartSend în BitFramingRegister pentru a transmite efectiv datele. Comanda Autentificare nu are această cerință.

În general, aplicațiile de cod Arduino „C” disponibile online utilizează registrele de semnalizare de întrerupere și registrul de expirare pentru a se asigura că răspunsul corect este primit în timp util. În opinia mea, acest lucru este excesiv pentru această aplicație critică non-time. În schimb, folosesc expirări scurte ale software-ului pentru a aștepta răspunsul și apoi pentru a verifica dacă este corect. Manualul pentru etichetele Mifare detaliază momentul pentru diferitele tranzacții și timpul este, de asemenea, permis pentru numărul estimat de octeți care urmează să fie primit. Aceste întârzieri de timp sunt integrate în majoritatea subrutinelor de comandă de nivel scăzut.

Pasul 10: Software unic PN532

După inițializarea modulului, pașii necesari pentru găsirea și autentificarea etichetei se realizează prin scrierea comenzii corespunzătoare urmată de datele necesare. Comanda de scanare returnează UID-ul care este apoi utilizat pentru autentificare. După aceea, citește și scrie eticheta trimite sau returnează cei 16 octeți pentru blocul de date adresat.

Secvența de inițializare a fost detaliată mai devreme și aceeași rutină software trimite și comanda SAMConfiguration pentru a scoate modulul din starea „LowVbat”. Restul comenzilor de bază, cum ar fi Scanare, Autentificare, Citire / Scriere Tag, sunt doar construite secvențial în rutinele aplicabile. Suma de control este calculată doar prin adăugarea octeților de comandă, efectuarea unui complement și apoi adăugarea 1 pentru a face un complement 2. Rezultatul de 8 biți este atașat la șirul de comandă chiar înainte de postamble.

Nu există FIFO ca în RC522, astfel încât mesajele de răspuns complete sunt primite automat. Rutina „Find_Response” scanează bufferul de date de primire pentru TFI (0xD5). Rutina profită de a ști care ar trebui să fie mesajele așteptate și ignoră răspunsurile ACK simple care nu includ date. Odată ce TFI a fost găsit, răspunsurile dorite sunt un offset cunoscut din acesta. Ecoul comenzii și octeții stării comenzii sunt salvate de rutina „Read_Buff” pentru verificare ulterioară.

Gata pentru această postare. Consultați celelalte proiecte electronice ale mele la: www.boomerrules.wordpress.com