Bases RFID RC522 et PN532 : 10 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:07

REMARQUE: j'ai maintenant des Instructables qui offrent le code Arduino pour le RC522 et le PN532.

Il y a quelque temps, j'ai acheté trois modules RFID différents pour expérimenter. Dans un projet précédent, j'ai expliqué comment utiliser un simple module de 125 kHz pour effectuer une fonction de sécurité de base. Des modules comme celui-ci utilisent des balises en lecture seule, le processus consiste donc à rechercher l'ID, à le stocker si vous le souhaitez et à le comparer aux ID stockés. Les autres modules que j'ai achetés fonctionnent à 13,56 MHz et utilisent des balises qui peuvent être à la fois lues et écrites, c'est donc une sorte de gaspillage de les utiliser simplement pour une sécurité de base. Les deux modules communs utilisent soit la puce RC522 soit la puce PN532, toutes deux fabriquées par NXP.

Si vous avez lu l'un de mes autres projets, vous savez que j'aime utiliser des microcontrôleurs PIC bon marché et programmer en langage assembleur. Donc, ce que je cherchais, c'était une séquence d'étapes nécessaires pour parler aux modules et aux étiquettes RFID. Bien qu'il existe de nombreux exemples de programmes en ligne pour les modules, la plupart d'entre eux sont écrits dans le logiciel "C" pour l'Arduino et utilisent l'interface SPI. De plus, les manuels des puces et des balises Mifare demandent un peu de déchiffrement. Cet article concerne principalement les informations que j'aurais aimé avoir lorsque j'ai commencé le projet. J'inclus également des logiciels d'assemblage PIC pour exécuter les commandes de base requises par chaque module. Même si vous n'utilisez pas de langage PIC et/ou assembleur, le code source devrait au moins vous donner une bonne idée des commandes spécifiques requises pour effectuer chaque étape.

Étape 1: Interfaces série

Les deux puces utilisées sur ces modules sont capables de s'interfacer via SPI, I2C ou UART (HSSP). Le module PN532 possède un commutateur DIP qui est utilisé pour sélectionner l'interface souhaitée, mais le module MFRC522 est câblé pour l'interface SPI. Je préfère utiliser l'UART intégré du PIC, j'ai donc cherché en ligne pour voir s'il y avait un moyen de faire passer le module MFRC522 en mode UART. Ce que j'ai trouvé, c'est que couper une trace sur la planche ferait l'affaire. La coupe supprime efficacement 3,3 volts de la broche EA de la puce. Techniquement, la broche EA doit ensuite être connectée à la terre, mais peu de gens peuvent réaliser cet exploit de soudure compte tenu de la densité des broches de la puce. Ne vous inquiétez pas, cependant, car la broche EA n'a pas de pull-up interne et ne "flotte" pas comme le font les anciennes entrées logiques TTL. Reportez-vous au diagramme de la puce et à l'image de la section du panneau pour l'endroit à couper. Assurez-vous de ne couper que la courte trace allant directement à la broche EA.

Étape 2: Matériel

Les connexions matérielles pour les communications UART sont illustrées dans le schéma ci-dessus. Les connexions UART pour le MFRC522 ne sont pas marquées sur la carte mais, comme le montre le schéma, la broche SDA reçoit les données UART et la broche MISO transmet les données UART. Le module PN532 a les marquages UART sur la face inférieure de la carte.

Les deux modules fonctionnent sur 3,3 volts et le niveau logique de 5 volts de la broche PIC TX doit également être limité. La connexion LCD est la configuration standard à 4 bits qui a été utilisée dans un certain nombre de mes projets précédents. Le format par défaut de tous les messages est défini pour l'écran LCD standard 1602 (16 caractères sur 2 lignes). J'ai également un écran LCD de 40 caractères sur 2 lignes que j'utilise pour les vidages de données brutes pendant le débogage, j'ai donc inclus une définition dans le logiciel qui me permet de profiter de l'espace d'affichage supplémentaire.

Étape 3: Blocs de données

Les balises Mifare Classic 1k utilisées pour ce projet sont configurées en 16 secteurs, quatre blocs de données par secteur, 16 octets par bloc de données. Sur les 64 blocs de données, seuls 47 sont réellement utilisables. Le bloc de données 0 contient les données du fabricant et les blocs 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 et 63 sont appelés blocs de remorque. Les blocs Trailer sont les derniers de chaque secteur et ils contiennent deux clés et les bits d'accès aux blocs. Les clés et les bits d'accès aux blocs s'appliquent uniquement aux blocs de données de ce secteur, vous pouvez donc avoir des clés et des règles d'accès différentes pour chaque secteur. Les touches par défaut sont définies sur « FF FF FF FF FFh ». Pour ce projet de base, j'utilise un seul bloc de données et je conserve les clés et les bits d'accès par défaut. Il existe de nombreux documents liés à ces cartes, alors effectuez simplement une recherche en ligne sur « Mifare » ou visitez le site Web de NXP si vous souhaitez les explorer plus en profondeur.

Étape 4: Fonctionnement général

Bien que les deux modules soient uniques dans la manière dont ils sont accessibles et dans la manière dont ils accèdent aux balises, un processus général est nécessaire pour effectuer le travail. Pour ce projet, nous supposons que les balises sont du type Mifare Classic 1k et que nous n'autorisons qu'une seule balise à la fois dans le champ d'antenne. Les étapes de base sont définies ci-dessous.

· Initialiser le module: En général, cela nécessite des choses telles que l'écriture de valeurs dans les registres de la puce, l'envoi de commandes de « réveil » et la mise sous tension de l'antenne. Dans une application fonctionnant sur batterie, vous voudriez pouvoir allumer et éteindre l'antenne pour économiser la batterie, mais pour cette application simple, nous l'allumons une fois puis la laissons allumée.

· Effacer l'indicateur de chiffrement (522 uniquement): lorsqu'une étiquette est authentifiée, un indicateur est défini pour informer l'utilisateur que les communications avec l'étiquette seront cryptées. Cet indicateur doit être effacé par l'utilisateur avant le prochain scan, même si le tag scanné est le même.

· Rechercher un tag: le module demande essentiellement « Y a-t-il quelqu'un là-bas ? » et le tag répond "Je suis là". Si le module n'obtient pas de réponse rapide, il arrête d'écouter. Cela signifie que nous devons envoyer à plusieurs reprises des commandes de scan au module jusqu'à ce qu'il trouve une balise.

· Obtenez le numéro d'identification de l'utilisateur (UID) de la balise: la balise répondra à la demande de numérisation avec des informations limitées telles que le type de balise dont il s'agit. Cela signifie que nous devrons peut-être envoyer une autre commande pour obtenir son UID. L'UID est de quatre octets pour les balises Mifare Classic 1k. Cela peut être plus long pour d'autres balises, mais ce projet ne les traite pas.

· Sélectionner la balise (522 uniquement): L'UID est utilisé pour sélectionner la balise que l'utilisateur souhaite authentifier pour les lectures et les écritures. Ceci est basé sur la possibilité qu'il puisse y avoir plus d'une étiquette dans le champ d'antenne. Ce n'est pas le cas pour notre application simple mais nous devons quand même sélectionner la balise.

· Authentifier le tag: Cette étape est obligatoire si l'on souhaite effectuer une quelconque lecture ou écriture du tag. Si tout ce que nous voulons faire est de différencier les balises pour une simple application de sécurité, alors l'UID est suffisant. L'authentification nécessite que nous connaissions l'UID et que nous connaissions la clé de chiffrement du secteur de données de la balise à laquelle nous voulons accéder. Pour ce projet, nous nous en tenons aux clés par défaut, mais mon projet suivant modifie les clés afin que l'étiquette puisse être utilisée comme porte-monnaie électronique.

· Lire ou écrire la balise: les lectures renvoient toujours les 16 octets du bloc de données demandé. Les écritures nécessitent que les 16 octets soient écrits en même temps. Si vous souhaitez lire ou écrire un autre bloc dans le même secteur de données, le tag n'a pas besoin d'être à nouveau authentifié. Si vous souhaitez lire ou écrire un bloc dans un secteur de données différent, le tag doit être à nouveau authentifié à l'aide de la clé de ce secteur.

Étape 5: Séquence d'accès au module MFRC522

La routine de démarrage comprend ces étapes de base trouvées dans la plupart des applications que j'ai examinées:

· Envoyer un octet de données factice (voir le paragraphe suivant)

· Redémarrage en douceur

· Réglez le gain du récepteur RF (si vous souhaitez quelque chose d'autre que la valeur par défaut)

· Réglez le pourcentage de modulation ASK sur 100 %

· Définir la valeur de départ pour les calculs CRC

· Allumez l'antenne

· Obtenir la version du firmware (non requis)

Pour une raison inexpliquée, mon module s'allume et pense qu'il a reçu une commande d'écriture sans l'octet de données. Je ne sais pas s'il s'agit uniquement d'un problème avec mon module, mais je n'en ai vu aucune référence ailleurs. J'ai expérimenté des réinitialisations matérielles et logicielles et aucune n'a résolu le problème. Ma solution consistait à ajouter un appel de lecture factice pour enregistrer « 0 » (non défini) au début de la routine d'initialisation du module. Si le module considère cela comme des données pour la commande d'écriture inconnue, il ne semble pas y avoir d'effets néfastes. S'il la considère comme une commande de lecture, rien d'utile ne se produit. Cela me dérange de ne pas pouvoir définir complètement le problème, d'autant plus qu'une réinitialisation matérielle du module uniquement ne résout pas le problème.

La puce RC522 est composée d'un certain nombre de registres, dont la plupart sont à la fois en lecture et en écriture. Pour effectuer une écriture, le numéro de registre est envoyé au module suivi de la valeur à écrire. Pour effectuer une lecture, le numéro de registre a 0x80 ajouté et qui est envoyé au module. La réponse à une commande d'écriture est un écho du registre consulté. La réponse à une commande de lecture est le contenu du registre. Le logiciel profite de cette connaissance pour vérifier que la commande a été correctement exécutée.

Étape 6: Séquence d'accès au module PN532

La routine de démarrage comprend les étapes requises:

· Envoyer une chaîne d'initialisation: Ceci est spécifique à l'interface UART. Le manuel indique que l'interface UART se réveillera au cinquième front montant détecté sur l'interface. Il recommande d'envoyer 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Pour la plupart, il suffit d'avoir un nombre suffisant de caractères avec des fronts montants et ils ne doivent pas ressembler à un préambule de commande (00 00 FF).

· Réveillez le module: Enfoui dans le manuel d'utilisation, il indique que le module s'initialise dans une sorte d'état de veille appelé « LowVbat ». Pour sortir de cet état, nous devons envoyer une commande « SAMConfiguration ».

Le PN532 s'attend à ce que les commandes soient envoyées dans un format de message défini qui comprend un préambule, le message et un postambule. Les messages de réponse suivent le même format. Les messages de commande et de réponse incluent tous deux un TFI (Frame Identifier) et une version de commande. La commande utilise un TFI de 0xD4 et la réponse utilise 0xD5. Les versions de commande varient mais la réponse incrémentera toujours la version de commande et la renverra dans l'octet suivant le TFI. Cette cohérence permet aux messages de réponse d'être facilement analysés pour les informations pertinentes.

Chaque message de commande (suivant le préambule) comprend la longueur du message, le complément à 2 de la longueur du message, le TFI, la commande, les données, la somme de contrôle et le postambule. Le logiciel construit les commandes individuelles, puis appelle une routine qui calcule la somme de contrôle et ajoute le postambule.

Le format du message pour la réponse est similaire à celui de la commande. Une réponse typique comprendra un ACK (00 00 FF 00 FF 00) suivi de la réponse spécifique à la commande. Chaque réponse de commande commence par un préambule de 00 00 FF. La réponse doit également avoir un octet TFI de D5 suivi du numéro de commande incrémenté de 1. Pour notre commande « SAMConfiguration » (14) ce serait 15. La commande « SAMConfiguration » obtient cette réponse: 00 00 FF 00 FF 00 00 00 FF 02 EF D5 15 16 00.

Il existe d'autres commandes spécifiques au module qui peuvent être envoyées, mais elles ne sont pas nécessaires pour cette application. J'ai cependant inclus une routine qui peut être appelée pour récupérer le numéro de version du firmware. Une réponse typique (après l'ACK et le préambule) serait: 06 FA D5 03 32 01 06 07 E8 00. Le « 01 06 07 » indique le numéro de version du firmware 1.6.7.

Étape 7: séquence d'accès aux balises

Une fois le module prêt, nous pouvons envoyer des commandes spécifiques aux balises. Afin de lire ou d'écrire des données de balise, nous devons disposer de son numéro d'identification (UID). L'UID et la clé seront ensuite utilisés pour autoriser un secteur de données de balise spécifique pour les lectures/écritures. Les lectures/écritures de données de balise sont toujours effectuées sur les 16 octets d'un bloc de données spécifié. Cela signifie que l'application typique lira le bloc de données, modifiera les données comme souhaité, puis réécrira les nouvelles données dans le tag.

Étape 8: Logiciel

Le logiciel du gestionnaire d'interruption est appelé chaque fois que le PIC UART reçoit un octet de données. Dans certains de mes projets UART précédents, j'ai pu simplement interroger l'indicateur d'interruption RX au lieu d'avoir à utiliser un gestionnaire d'interruption. Ce n'est pas le cas pour ce logiciel, notamment pour le PN532 qui communique à un débit beaucoup plus élevé que le RC522. L'interface UART du RC522 est limitée à 9600 bauds tandis que la valeur par défaut du PN532 est de 115k et peut être réglée jusqu'à 1,288M bauds. Les octets reçus sont stockés dans une zone tampon et la partie principale du logiciel les récupère au besoin.

L'indicateur New_Msg indique que des octets ont été reçus et Byte_Count indique combien. J'ai inclus une routine "Disp_Buff" dans le logiciel qui peut être appelée pour afficher le contenu du tampon de réception pendant le débogage. Certains des messages de retour déborderont d'un écran 1602 typique, mais j'ai un écran LCD de 40 caractères sur 2 lignes que j'ai trouvé sur un site d'électronique de surplus en ligne. La définition "Max_Line" peut être définie pour la taille de votre écran LCD. Si "Max_Line" est atteint, la routine "Disp_Buff" continue en écrivant sur la deuxième ligne. Vous pouvez ajouter un petit code à cette routine pour continuer sur les lignes trois et quatre si vous avez un écran LCD à 4 lignes. Pour le PN532, il existe un indicateur qui peut être défini de sorte que la routine vide tous les octets reçus ou vide simplement les 16 octets de données d'une réponse de lecture.

Il n'est pas nécessaire d'effacer le tampon de réception ou Byte_Count car l'effacement de l'indicateur New_Msg entraînera l'effacement de Byte_Count par le gestionnaire d'interruption et c'est ce qui est utilisé comme index dans le tampon. New_Msg est généralement effacé avant chaque étape de commande afin que les résultats spécifiques à cette commande puissent être facilement localisés et vérifiés. Dans le RC522, cela signifie que le tampon de réception n'a généralement que 1 à 4 octets. Dans certains cas, tels que les lectures de blocs de données, la commande Read_FIFO doit être émise plusieurs fois afin de déplacer les octets de la FIFO dans le tampon de réception. Tous les résultats de commande pour le PN532 se retrouvent dans le tampon de réception, une procédure de balayage est donc effectuée pour localiser les octets spécifiques nécessaires.

La boucle principale du logiciel recherche une balise, puis authentifie la balise pour les lectures/écritures. Pour le logiciel de test inclus ici, la variable Junk_Num est modifiée à chaque fois dans la boucle principale et est utilisée lors de l'écriture dans le tag. Les valeurs écrites alternent entre la valeur de Junk_Num et le complément à 1 de Junk_Num. Enfin, les 16 valeurs écrites sont lues et affichées. Il y a des messages d'affichage pour chaque étape avec des appels de routine de retard pour laisser le temps de lire chaque message. Des messages d'erreur sont également fournis mais ne devraient normalement apparaître que si la balise est supprimée au cours d'une opération.

Une partie de l'initialisation du logiciel est une section de code qui n'est exécutée qu'à la mise sous tension et est ignorée si une réinitialisation du logiciel est détectée. Les messages d'erreur se terminent généralement par une réinitialisation logicielle comme moyen de quitter la boucle principale. La réinitialisation se produit dans la routine « Tilt » qui active simplement le temporisateur de chien de garde, puis entre dans une boucle infinie en attendant le délai d'attente.

Étape 9: Logiciel unique MFRC522

La puce RC522 nécessite plus d'instructions de bas niveau que la puce PN532 pour effectuer les communications avec les balises. C'est un peu comme la programmation en langage assembleur par rapport à la programmation en "C". Une autre différence significative est que le RC522 nécessite que les communications avec l'étiquette soient acheminées via un tampon FIFO. Les routines « Write_FIFO » et « Read_FIFO » gèrent ces tâches. Le logiciel MFRC522 comprend une section pour de nombreuses commandes de niveau inférieur à partir desquelles les fonctions principales sont construites.

Le calcul de la somme de contrôle de la commande de point pour le RC522 est très différent de celui du PN532. Une fois la commande de tag créée dans la FIFO, une commande de module est envoyée pour calculer la somme de contrôle. Le résultat 16 bits n'est pas automatiquement ajouté à la commande de balise mais est disponible pour la lecture à partir de deux registres 8 bits. Le calcul de la somme de contrôle efface les données dans la FIFO de sorte que la séquence requise est la suivante:

· Construire la commande dans le FIFO

· Commande un calcul de somme de contrôle

· Construire à nouveau la commande dans le FIFO

· Lire les registres CRC et écrire les octets de somme de contrôle dans la FIFO

· Envoyez une commande Transceive ou Authenticate

La commande Transceive transmettra le tampon FIFO puis passera automatiquement en mode réception pour attendre la réponse du tag. La commande Transceive doit être suivie du réglage du bit StartSend dans BitFramingRegister afin de transmettre réellement les données. La commande Authenticate n'a pas cette exigence.

En général, les applications de code Arduino "C" disponibles en ligne utilisent les registres d'indicateurs d'interruption et le registre de temporisation pour garantir que la réponse correcte est reçue en temps opportun. À mon avis, c'est exagéré pour cette application non critique dans le temps. Au lieu de cela, j'utilise des délais d'attente logiciels courts pour attendre la réponse, puis vérifier qu'elle est correcte. Le manuel des balises Mifare détaille le calendrier des différentes transactions et le temps est également autorisé pour le nombre attendu d'octets à recevoir. Ces délais sont intégrés à la plupart des sous-programmes de commande de bas niveau.

Étape 10: Logiciel unique PN532

Une fois le module initialisé, les étapes nécessaires pour trouver et authentifier la balise sont accomplies en écrivant la commande appropriée suivie des données nécessaires. La commande scan renvoie l'UID qui est ensuite utilisé pour l'authentification. Après cela, les lectures et écritures du tag envoient ou renvoient les 16 octets du bloc de données adressé.

La séquence d'initialisation a été détaillée plus tôt et la même routine logicielle envoie également la commande SAMConfiguration pour sortir le module de l'état "LowVbat". Le reste des commandes de base, telles que Scan, Authenticate, Read/Write Tag, sont simplement construits séquentiellement dans les routines applicables. La somme de contrôle est calculée en additionnant simplement les octets de commande, en faisant un complément, puis en ajoutant 1 pour en faire un complément à 2. Le résultat 8 bits est ajouté à la chaîne de commande juste avant le postambule.

Il n'y a pas de FIFO comme dans le RC522 donc les messages de réponse complets sont reçus automatiquement. La routine "Find_Response" scanne le tampon de données de réception pour le TFI (0xD5). La routine profite de la connaissance des messages attendus et ignore les réponses ACK simples qui n'incluent pas de données. Une fois le TFI trouvé, les réponses souhaitées en sont un décalage connu. Les octets d'écho de commande et d'état de commande sont sauvegardés par la routine "Read_Buff" pour une vérification ultérieure.

C'est tout pour ce post. Découvrez mes autres projets électroniques sur: www.boomerrules.wordpress.com