Nozioni di base RFID RC522 e PN532: 10 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:02

NOTA: ora ho Instructables che offrono il codice Arduino per RC522 e PN532.

Tempo fa ho acquistato tre diversi moduli RFID per sperimentare. In un progetto precedente ho spiegato come utilizzare un semplice modulo a 125 kHz per eseguire una funzione di sicurezza di base. Moduli come quello utilizzano tag di sola lettura, quindi il processo esegue la scansione dell'ID, archivia se lo si desidera e confronta con gli ID archiviati. Gli altri moduli che ho acquistato funzionano a 13,56 MHz e utilizzano tag che possono essere sia letti che scritti, quindi è un po' uno spreco usarli semplicemente per la sicurezza di base. I due moduli comuni utilizzano il chip RC522 o il chip PN532, entrambi prodotti da NXP.

Se hai letto uno dei miei altri progetti, sai che mi piace usare microcontrollori PIC economici e programmare in linguaggio assembly. Quindi quello che stavo cercando era una sequenza di passaggi necessari per parlare con i moduli e con i tag RFID. Sebbene ci siano molti programmi di esempio online per i moduli, la maggior parte di essi sono scritti in software "C" per Arduino e utilizzano l'interfaccia SPI. Inoltre, i manuali per i chip e per i tag Mifare richiedono un po' di decifrazione. Questo post riguarda principalmente le informazioni che vorrei avere quando ho iniziato il progetto. Includo anche programmi software di assemblaggio PIC per eseguire i comandi di base richiesti da ciascun modulo. Anche se non utilizzi un linguaggio PIC e/o assembly, il codice sorgente dovrebbe almeno fornirti una buona idea dei comandi specifici necessari per eseguire ogni passaggio.

Passaggio 1: interfacce seriali

Entrambi i chip utilizzati su questi moduli sono in grado di interfacciarsi tramite SPI, I2C o UART (HSSP). Il modulo PN532 dispone di un interruttore DIP utilizzato per selezionare l'interfaccia desiderata, ma il modulo MFRC522 è cablato per l'interfaccia SPI. Preferisco usare l'UART integrato del PIC, quindi ho cercato online per vedere se c'era un modo per portare il modulo MFRC522 in modalità UART. Quello che ho scoperto è che tagliare una traccia sulla lavagna avrebbe funzionato. Il taglio rimuove efficacemente 3,3 volt dal pin EA del chip. Tecnicamente il pin EA dovrebbe quindi essere collegato a terra, ma non molte persone possono realizzare quell'impresa di saldatura data la densità dei pin del chip. Non preoccuparti, però, perché il pin EA non ha un pull-up interno e non "fluttua" come fanno i vecchi ingressi logici TTL. Fare riferimento al diagramma del chip e all'immagine della sezione della scheda per il punto da tagliare. Assicurati di tagliare solo la breve traccia che va direttamente al pin EA.

Passaggio 2: hardware

Le connessioni hardware per le comunicazioni UART sono mostrate nel diagramma sopra. Le connessioni UART per MFRC522 non sono contrassegnate sulla scheda ma, come mostrato nello schema, il pin SDA riceve dati UART e il pin MISO trasmette dati UART. Il modulo PN532 ha i contrassegni UART sul lato inferiore della scheda.

Entrambi i moduli funzionano a 3,3 volt e anche il livello logico a 5 volt dal pin PIC TX deve essere limitato. La connessione LCD è la configurazione standard a 4 bit che è stata utilizzata in molti dei miei progetti precedenti. Il formato predefinito per tutti i messaggi è impostato per il display LCD 1602 standard (16 caratteri per 2 righe). Ho anche un LCD da 40 caratteri per 2 righe che uso per i dump dei dati grezzi durante il debug, quindi ho incluso una definizione nel software che mi consente di sfruttare lo spazio di visualizzazione extra.

Passaggio 3: blocchi di dati

I tag Mifare Classic 1k utilizzati per questo progetto sono configurati come 16 settori, quattro blocchi dati per settore, 16 byte per blocco dati. Dei 64 blocchi di dati, solo 47 sono effettivamente utilizzabili. Il blocco dati 0 contiene i dati del produttore e i blocchi 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 e 63 sono chiamati blocchi Trailer. I blocchi Trailer sono gli ultimi di ogni settore e contengono due chiavi e i bit di accesso al blocco. Le chiavi e i bit di accesso ai blocchi si applicano solo ai blocchi di dati in quel settore, quindi potresti avere chiavi e regole di accesso diverse per ogni settore. I tasti predefiniti sono impostati su “FF FF FF FF FFh”. Per questo progetto di base utilizzo solo un blocco dati e mantengo le chiavi e i bit di accesso predefiniti. Esistono molti documenti relativi a queste carte, quindi basta fare una ricerca online per "Mifare" o visitare il sito Web NXP se si desidera esplorarle in modo più approfondito.

Passaggio 4: operazione generale

Sebbene entrambi i moduli siano unici nel modo in cui sono accessibili e nel modo in cui accedono ai tag, è necessario un processo generale per portare a termine il lavoro. Per questo progetto assumiamo che i tag siano del tipo Mifare Classic 1k e che stiamo consentendo solo un tag alla volta nel campo dell'antenna. I passaggi di base sono definiti di seguito.

· Inizializzare il modulo: In generale, ciò richiede cose come scrivere valori sui registri nel chip, inviare comandi di "risveglio" e accendere l'antenna. In un'applicazione a batteria si vorrebbe poter accendere e spegnere l'antenna per risparmiare la batteria, ma per questa semplice applicazione la accendiamo una volta e poi la lasciamo accesa.

· Cancella il flag di crittografia (solo 522): quando un tag viene autenticato, viene impostato un flag per informare l'utente che le comunicazioni con il tag verranno crittografate. Questo flag deve essere cancellato dall'utente prima della scansione successiva, anche se il tag scansionato è lo stesso.

· Scansione per un tag: il modulo chiede fondamentalmente "C'è qualcuno là fuori?" e il tag risponde "Sono qui". Se il modulo non riceve una risposta rapida, smette di ascoltare. Ciò significa che dobbiamo inviare ripetutamente comandi di scansione al modulo finché non trova un tag.

· Ottieni il numero di identificazione utente del tag (UID): il tag risponderà alla richiesta di scansione con alcune informazioni limitate come il tipo di tag che è. Ciò significa che potrebbe essere necessario inviare un altro comando per ottenere il suo UID. L'UID è di quattro byte per i tag Mifare Classic 1k. Se potrebbe essere più lungo per altri tag ma questo progetto non li affronta.

· Selezionare il tag (solo 522): L'UID viene utilizzato per selezionare il tag che l'utente desidera autenticare per le letture e le scritture. Questo si basa sulla possibilità che ci possa essere più di un tag nel campo dell'antenna. Questo non è il caso della nostra semplice applicazione, ma dobbiamo comunque selezionare il tag.

· Autenticare il tag: questo passaggio è necessario se vogliamo eseguire qualsiasi lettura o scrittura del tag. Se tutto ciò che vogliamo fare è distinguere i tag per una semplice applicazione di sicurezza, l'UID è sufficiente. L'autenticazione richiede che conosciamo l'UID e che conosciamo la chiave crittografica per il settore dati del tag a cui vogliamo accedere. Per questo progetto ci atteniamo alle chiavi predefinite, ma il mio progetto successivo cambia le chiavi in modo che il tag possa essere utilizzato come portafoglio elettronico.

· Leggi o scrivi il tag: Le letture restituiscono sempre tutti i 16 byte del Data Block richiesto. Le scritture richiedono che tutti i 16 byte vengano scritti contemporaneamente. Se si desidera leggere o scrivere un altro blocco nello stesso settore dati, non è necessario autenticare nuovamente il tag. Se vuoi leggere o scrivere un blocco in un settore dati diverso, il tag deve essere autenticato di nuovo utilizzando la chiave per quel settore.

Passaggio 5: sequenza di accesso al modulo MFRC522

La routine di avvio include questi passaggi di base che si trovano nella maggior parte delle applicazioni che ho esaminato:

· Invia un byte di dati fittizio (vedi paragrafo successivo)

· Ripristino software

· Impostare il guadagno del ricevitore RF (se si desidera qualcosa di diverso da quello predefinito)

· Imposta la percentuale di modulazione ASK al 100%

· Imposta il valore del seme per i calcoli CRC

· Accendere l'antenna

· Ottieni la versione del firmware (non richiesta)

Per qualche motivo inspiegabile, il mio modulo si accende e pensa di aver ricevuto un comando di scrittura senza il byte di dati. Non so se questo è solo un problema con il mio modulo, ma non ho visto alcun riferimento ad esso altrove. Ho provato sia reset hardware che software e nessuno dei due ha risolto il problema. La mia soluzione era aggiungere una chiamata di lettura fittizia per registrare "0" (non definito) all'inizio della routine di inizializzazione del modulo. Se il modulo lo vede come dati per il comando di scrittura sconosciuto, non sembrano esserci effetti negativi. Se lo vede come un comando di lettura, non succede nulla di utile. Mi dà fastidio che non riesca a definire completamente il problema, soprattutto dato che un ripristino hardware del solo modulo non risolve il problema.

Il chip RC522 è composto da un numero di registri, la maggior parte dei quali sia in lettura che in scrittura. Per eseguire una scrittura, al modulo viene inviato il numero di registro seguito dal valore da scrivere. Per eseguire una lettura, al numero di registro viene aggiunto 0x80 e questo viene inviato al modulo. La risposta a un comando di scrittura è un'eco del registro a cui si accede. La risposta a un comando di lettura è il contenuto del registro. Il software sfrutta tale conoscenza per verificare che il comando sia stato eseguito correttamente.

Passaggio 6: sequenza di accesso al modulo PN532

La routine di avvio include questi passaggi obbligatori:

· Invia una stringa di inizializzazione: è specifica per l'interfaccia UART. Il manuale afferma che l'interfaccia UART si riattiverà al quinto fronte di salita rilevato sull'interfaccia. Si consiglia di inviare 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Per la maggior parte, è sufficiente che ci sia un numero sufficiente di caratteri con fronti di salita e non devono assomigliare a un preambolo di comando (00 00 FF).

· Wake up the module: Sepolto nel manuale utente mostra che il modulo si inizializza in una sorta di stato di sospensione chiamato “LowVbat”. Per uscire da questo stato dobbiamo inviare un comando “SAMConfiguration”.

Il PN532 prevede che i comandi vengano inviati in un formato di messaggio definito che include un preambolo, il messaggio e un postambolo. I messaggi di risposta seguono lo stesso formato. I messaggi di comando e di risposta includono entrambi un TFI (identificatore di frame) e una versione del comando. Il comando utilizza un TFI di 0xD4 e la risposta utilizza 0xD5. Le versioni del comando variano ma la risposta incrementerà sempre la versione del comando e la restituirà nel byte che segue il TFI. Tale coerenza consente di scansionare facilmente i messaggi di risposta per le informazioni pertinenti.

Ciascun messaggio di comando (dopo il preambolo) è costituito dalla lunghezza del messaggio, il complemento a 2 della lunghezza del messaggio, TFI, comando, dati, checksum e postambolo. Il software costruisce i singoli comandi e quindi chiama una routine che calcola il checksum e aggiunge il postambolo.

Il formato del messaggio per la risposta è simile a quello del comando. Una risposta tipica includerà un ACK (00 00 FF 00 FF 00) seguito dalla risposta specifica al comando. Ogni risposta al comando inizia con un preambolo di 00 00 FF. La risposta dovrebbe anche avere un byte TFI di D5 seguito dal numero di comando incrementato di 1. Per il nostro comando "SAMConfiguration" (14) sarebbe 15. Il comando "SAMConfiguration" ottiene questa risposta: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Esistono altri comandi specifici del modulo che possono essere inviati ma non sono necessari per questa applicazione. Tuttavia, ho incluso una routine che può essere chiamata per recuperare il numero di versione del firmware. Una risposta tipica (dopo ACK e preambolo) sarebbe: 06 FA D5 03 32 01 06 07 E8 00. "01 06 07" indica il numero di versione del firmware 1.6.7.

Passaggio 7: sequenza di accesso ai tag

Dopo che il modulo è pronto, possiamo inviare comandi specifici per i tag. Per leggere o scrivere i dati del tag abbiamo bisogno del suo numero di identificazione (UID). L'UID e la chiave verranno quindi utilizzati per autorizzare uno specifico settore di dati del tag per le letture/scritture. Le letture/scritture dei dati dei tag vengono sempre eseguite su tutti i 16 byte in un blocco dati specificato. Ciò significa che l'applicazione tipica leggerà il blocco dati, modificherà i dati come desiderato e quindi riscriverà i nuovi dati nel tag.

Passaggio 8: software

Il software di gestione degli interrupt viene chiamato ogni volta che PIC UART riceve un byte di dati. In alcuni dei miei precedenti progetti UART sono stato in grado di eseguire il polling del flag di interruzione RX invece di dover utilizzare un gestore di interruzioni. Questo non è il caso di questo software, in particolare per il PN532 che comunica a una velocità di trasmissione molto più elevata rispetto all'RC522. L'interfaccia UART dell'RC522 è limitata a 9600 baud, mentre l'impostazione predefinita per PN532 è 115k e può essere impostata fino a 1.288M baud. I byte ricevuti vengono memorizzati in un'area buffer e la parte principale del software li recupera secondo necessità.

Il flag New_Msg indica che i byte sono stati ricevuti e Byte_Count indica quanti. Ho incluso una routine "Disp_Buff" nel software che può essere chiamata per visualizzare il contenuto del buffer di ricezione durante il debug. Alcuni dei messaggi di ritorno traboccheranno su un tipico display 1602, ma ho un display LCD da 40 caratteri per 2 righe che ho trovato in un sito di elettronica in eccedenza online. La definizione "Max_Line" può essere impostata per le dimensioni dell'LCD. Se viene raggiunto "Max_Line", la routine "Disp_Buff" continua scrivendo sulla seconda riga. Potresti aggiungere un piccolo codice a quella routine per continuare sulle righe tre e quattro se hai un display LCD a 4 righe. Per il PN532 c'è un flag che può essere impostato in modo che la routine scarichi tutti i byte ricevuti o scarichi solo i 16 byte di dati da una risposta di lettura.

Non è necessario cancellare il buffer di ricezione o Byte_Count perché la cancellazione del flag New_Msg farà sì che Byte_Count venga cancellato dal gestore di interrupt e questo è ciò che viene utilizzato come indice nel buffer. New_Msg di solito viene cancellato prima di ogni passaggio del comando in modo che i risultati specifici per quel comando possano essere facilmente individuati e verificati. Nell'RC522 ciò significa che il buffer di ricezione di solito ha solo da 1 a 4 byte. In alcuni casi, come le letture di blocchi di dati, il comando Read_FIFO deve essere emesso più volte per spostare i byte dal FIFO nel buffer di ricezione. Tutti i risultati del comando per il PN532 finiscono nel buffer di ricezione, quindi viene eseguita una procedura di scansione per individuare i byte specifici necessari.

Il ciclo principale nel software esegue la scansione di un tag e quindi autentica il tag per le letture/scritture. Per il software di test qui incluso la variabile Junk_Num viene modificata ogni volta attraverso il loop principale e viene utilizzata durante la scrittura sul tag. I valori scritti si alternano tra il valore di Junk_Num e il complemento a 1 di Junk_Num. Infine vengono letti e visualizzati i 16 valori scritti. Ci sono messaggi di visualizzazione per ogni passaggio con chiamate di routine di ritardo per consentire il tempo di leggere ciascun messaggio. Vengono forniti anche messaggi di errore, ma normalmente dovrebbero verificarsi solo se il tag viene rimosso durante un'operazione.

Parte dell'inizializzazione del software è una sezione di codice che viene eseguita solo all'accensione e viene ignorata se viene rilevato un ripristino del software. I messaggi di errore generalmente terminano con un ripristino del software come modo per uscire dal ciclo principale. Il reset avviene nella routine “Tilt” che semplicemente abilita il Watchdog Timer e poi entra in un loop infinito in attesa del timeout.

Passaggio 9: software unico MFRC522

Il chip RC522 richiede più istruzioni di basso livello rispetto al chip PN532 per realizzare le comunicazioni con i tag. È un po' come programmare in linguaggio assembly rispetto alla programmazione in "C". Un'altra differenza significativa è che l'RC522 richiede che le comunicazioni con il tag vengano incanalate attraverso un buffer FIFO. Le routine "Write_FIFO" e "Read_FIFO" gestiscono queste attività. Il software MFRC522 include una sezione per molti dei comandi di livello inferiore da cui sono costruite le funzioni principali.

Il calcolo del checksum del comando tag per RC522 è molto diverso da quello per PN532. Dopo che il comando tag è stato creato nella FIFO, viene inviato un comando del modulo per calcolare il checksum. Il risultato a 16 bit non viene aggiunto automaticamente al comando tag ma è disponibile per la lettura da due registri a 8 bit. Il calcolo del checksum cancella i dati nel FIFO quindi la sequenza richiesta è la seguente:

· Costruisci il comando in FIFO

· Comanda un calcolo del checksum

· Costruisci di nuovo il comando nella FIFO

· Leggere i registri CRC e scrivere i byte di checksum nel FIFO

· Invia un comando Transceive o Autentica

Il comando Transceive trasmetterà il buffer FIFO e quindi passerà automaticamente alla modalità di ricezione per attendere la risposta dal tag. Il comando Transceive deve essere seguito dall'impostazione del bit StartSend nel BitFramingRegister per poter effettivamente trasmettere i dati. Il comando Authenticate non ha questo requisito.

In generale, le applicazioni in codice "C" di Arduino disponibili online utilizzano i registri dei flag di interrupt e il registro di timeout per garantire che la risposta corretta venga ricevuta in modo tempestivo. A mio parere è eccessivo per questa applicazione non critica in termini di tempo. Invece, utilizzo brevi timeout del software per attendere la risposta e quindi verificare che sia corretta. Il manuale per i tag Mifare dettaglia le tempistiche delle varie transazioni e viene concesso anche il tempo per il numero previsto di byte da ricevere. Questi ritardi sono incorporati nella maggior parte delle subroutine di comando di basso livello.

Passaggio 10: software unico PN532

Dopo che il modulo è stato inizializzato, i passaggi necessari per trovare e autenticare il tag vengono eseguiti scrivendo il comando appropriato seguito dai dati necessari. Il comando di scansione restituisce l'UID che viene poi utilizzato per l'autenticazione. Successivamente, le operazioni di lettura e scrittura del tag inviano o restituiscono i 16 byte per il blocco dati indirizzato.

La sequenza di inizializzazione è stata dettagliata in precedenza e la stessa routine software invia anche il comando SAMConfiguration per far uscire il modulo dallo stato "LowVbat". Il resto dei comandi di base, come Scan, Authenticate, Read/Write Tag, sono semplicemente creati in sequenza nelle routine applicabili. Il checksum viene calcolato semplicemente sommando i byte di comando, facendo un complemento e quindi aggiungendo 1 per renderlo un complemento a 2. Il risultato a 8 bit viene aggiunto alla stringa di comando appena prima del postambolo.

Non c'è FIFO come nell'RC522, quindi i messaggi di risposta completi vengono ricevuti automaticamente. La routine "Find_Response" scansiona il buffer dei dati di ricezione per il TFI (0xD5). La routine sfrutta il vantaggio di sapere quali dovrebbero essere i messaggi previsti e ignora semplici risposte ACK che non includono dati. Una volta trovato il TFI, le risposte desiderate sono un offset noto da esso. L'eco del comando e i byte di stato del comando vengono salvati dalla routine "Read_Buff" per una verifica successiva.

Questo è tutto per questo post. Dai un'occhiata ai miei altri progetti di elettronica su: www.boomerrules.wordpress.com