Tabla de contenido:

Conceptos básicos sobre RFID RC522 y PN532: 10 pasos
Conceptos básicos sobre RFID RC522 y PN532: 10 pasos

Video: Conceptos básicos sobre RFID RC522 y PN532: 10 pasos

Video: Conceptos básicos sobre RFID RC522 y PN532: 10 pasos
Video: CONTROL DE ACCESO con RFID y ARDUINO (PN532 NFC RFID module V4 ELECHOUSE)🔑 2024, Mes de julio
Anonim
Conceptos básicos sobre RFID RC522 y PN532
Conceptos básicos sobre RFID RC522 y PN532

NOTA: Ahora tengo Instructables que ofrecen código Arduino para RC522 y PN532.

Hace algún tiempo compré tres módulos RFID diferentes para experimentar. En un proyecto anterior, detallé cómo usar un módulo simple de 125 kHz para realizar una función de seguridad básica. Módulos como ese usan etiquetas de solo lectura, por lo que el proceso busca la identificación, la almacena si lo desea y la compara con la identificación almacenada. Los otros módulos que compré funcionan a 13,56 MHz y utilizan etiquetas que se pueden leer y escribir, por lo que es una especie de desperdicio utilizarlas simplemente para la seguridad básica. Los dos módulos comunes utilizan el chip RC522 o el chip PN532, ambos fabricados por NXP.

Si ha leído alguno de mis otros proyectos, sabe que me gusta usar microcontroladores PIC baratos y programas en lenguaje ensamblador. Entonces, lo que estaba buscando era una secuencia de pasos necesarios para hablar con los módulos y las etiquetas RFID. Si bien hay muchos programas de ejemplo en línea para los módulos, la mayoría de ellos están escritos en software "C" para Arduino y utilizan la interfaz SPI. Además, los manuales de los chips y las etiquetas Mifare requieren un poco de descifrado. Esta publicación trata principalmente sobre la información que desearía tener cuando comencé el proyecto. También incluyo programas de software de ensamblaje PIC para ejecutar los comandos básicos requeridos por cada módulo. Incluso si no usa un PIC y / o lenguaje ensamblador, el código fuente debería al menos brindarle una buena idea de los comandos específicos requeridos para realizar cada paso.

Paso 1: Interfaces seriales

Interfaces seriales
Interfaces seriales
Interfaces seriales
Interfaces seriales
Interfaces seriales
Interfaces seriales
Interfaces seriales
Interfaces seriales

Ambos chips utilizados en estos módulos pueden conectarse a través de SPI, I2C o UART (HSSP). El módulo PN532 tiene un interruptor DIP que se utiliza para seleccionar la interfaz deseada, pero el módulo MFRC522 está cableado para la interfaz SPI. Prefiero usar el UART integrado del PIC, así que busqué en línea para ver si había una manera de poner el módulo MFRC522 en el modo UART. Lo que encontré fue que cortar un rastro en el tablero sería suficiente. El corte elimina efectivamente 3.3 voltios del pin EA del chip. Técnicamente, el pin EA debe conectarse a tierra, pero no muchas personas pueden lograr esa hazaña de soldadura dada la densidad del pin del chip. Sin embargo, no se preocupe, porque el pin EA no tiene un pull-up interno y no "flota" como lo hacen las antiguas entradas lógicas TTL. Consulte el diagrama de chips y la imagen de la sección de la placa para ver el lugar a cortar. Asegúrese de cortar solo el trazo corto que va directamente al pin EA.

Paso 2: hardware

Hardware
Hardware

Las conexiones de hardware para las comunicaciones UART se muestran en el diagrama anterior. Las conexiones UART para el MFRC522 no están marcadas en la placa pero, como se muestra en el esquema, el pin SDA recibe datos UART y el pin MISO transmite datos UART. El módulo PN532 tiene las marcas UART en la parte inferior de la placa.

Ambos módulos funcionan con 3.3 voltios y el nivel lógico de 5 voltios del pin PIC TX también debe ser limitado. La conexión LCD es la configuración estándar de 4 bits que se ha utilizado en varios de mis proyectos anteriores. El formato predeterminado para todos los mensajes se establece para la pantalla LCD 1602 estándar (16 caracteres por 2 líneas). También tengo una pantalla LCD de 40 caracteres por 2 líneas que utilizo para volcados de datos sin procesar durante la depuración, por lo que incluí una definición en el software que me permite aprovechar el espacio de visualización adicional.

Paso 3: bloques de datos

Las etiquetas Mifare Classic 1k utilizadas para este proyecto están configuradas como 16 sectores, cuatro bloques de datos por sector, 16 bytes por bloque de datos. De los 64 bloques de datos, solo 47 son realmente utilizables. El bloque de datos 0 contiene datos del fabricante y los bloques 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 y 63 se denominan bloques de remolque. Los bloques Trailer son los últimos de cada sector y contienen dos claves y los bits de acceso al bloque. Las claves y los bits de acceso al bloque se aplican solo a los bloques de datos en ese sector, por lo que podría tener diferentes claves y reglas de acceso para cada sector. Las teclas predeterminadas están configuradas en "FF FF FF FF FFh". Para este proyecto básico, utilizo solo un bloque de datos y conservo las claves y los bits de acceso predeterminados. Hay muchos documentos relacionados con estas tarjetas, así que simplemente haga una búsqueda en línea de “Mifare” o visite el sitio web de NXP si desea explorarlos con más profundidad.

Paso 4: Operación general

Si bien ambos módulos son únicos en la forma en que se accede a ellos y en la forma en que acceden a las etiquetas, existe un proceso general que se requiere para realizar el trabajo. Para este proyecto asumimos que las etiquetas son del tipo Mifare Classic 1k y que solo permitimos una etiqueta a la vez en el campo de la antena. Los pasos básicos se definen a continuación.

· Inicializar el módulo: En general, esto requiere cosas como escribir valores en los registros del chip, enviar comandos de "activación" y encender la antena. En una aplicación que funciona con batería, querrá poder encender y apagar la antena para ahorrar batería, pero para esta aplicación simple, la encendemos una vez y luego la dejamos encendida.

· Limpiar la bandera criptográfica (solo 522): cuando se autentica una etiqueta, se establece una bandera para que el usuario sepa que las comunicaciones con la etiqueta se cifrarán. El usuario debe borrar esta bandera antes del siguiente escaneo, incluso si la etiqueta que se escanea es la misma.

· Buscar una etiqueta: el módulo básicamente pregunta "¿Hay alguien ahí fuera?" y la etiqueta responde "Estoy aquí". Si el módulo no obtiene una respuesta rápida, deja de escuchar. Eso significa que necesitamos enviar repetidamente comandos de escaneo al módulo hasta que encuentre una etiqueta.

· Obtener el número de identificación de usuario (UID) de la etiqueta: la etiqueta responderá a la solicitud de escaneo con información limitada, como el tipo de etiqueta que es. Eso significa que es posible que necesitemos enviar otro comando para obtener su UID. El UID es de cuatro bytes para las etiquetas Mifare Classic 1k. Puede ser más largo para otras etiquetas, pero este proyecto no las aborda.

· Seleccionar la etiqueta (solo 522): El UID se utiliza para seleccionar la etiqueta que el usuario desea autenticar para lecturas y escrituras. Esto se basa en la posibilidad de que haya más de una etiqueta en el campo de la antena. Ese no es el caso de nuestra aplicación simple, pero debemos seleccionar la etiqueta de todos modos.

· Autenticar la etiqueta: Este paso es necesario si queremos hacer alguna lectura o escritura de la etiqueta. Si todo lo que queremos hacer es diferenciar entre etiquetas para una aplicación de seguridad simple, entonces el UID es suficiente. La autenticación requiere que conozcamos el UID y que conozcamos la clave criptográfica del sector de datos de la etiqueta a la que queremos acceder. Para este proyecto, nos quedamos con las claves predeterminadas, pero mi proyecto de seguimiento cambia las claves para que la etiqueta se pueda usar como billetera electrónica.

· Leer o escribir la etiqueta: las lecturas siempre devuelven los 16 bytes del bloque de datos solicitado. Las escrituras requieren que los 16 bytes se escriban al mismo tiempo. Si desea leer o escribir otro bloque en el mismo sector de datos, no es necesario volver a autenticar la etiqueta. Si desea leer o escribir un bloque en un sector de datos diferente, la etiqueta debe autenticarse nuevamente usando la clave para ese sector.

Paso 5: Secuencia de acceso al módulo MFRC522

La rutina de inicio incluye estos pasos básicos que se encuentran en la mayoría de las aplicaciones que miré:

· Enviar byte de datos ficticios (ver el siguiente párrafo)

· Reinicio suave

· Establecer la ganancia del receptor de RF (si se desea algo diferente al predeterminado)

· Establece el porcentaje de modulación ASK al 100%

· Establecer valor inicial para los cálculos de CRC

· Enciende la antena

· Obtenga la versión de firmware (no es obligatorio)

Por alguna razón inexplicable, mi módulo se enciende y cree que ha recibido un comando de escritura sin el byte de datos. No sé si esto es solo un problema con mi módulo, pero no he visto ninguna referencia a él en ningún otro lugar. Experimenté con restablecimientos de hardware y software y ninguno solucionó el problema. Mi solución fue agregar una llamada de lectura ficticia para registrar "0" (indefinido) al comienzo de la rutina de inicialización del módulo. Si el módulo ve esto como datos para el comando de escritura desconocido, no parece haber ningún efecto nocivo. Si lo ve como un comando de lectura, no sucede nada útil. Me molesta que no pueda definir completamente el problema, especialmente dado que un reinicio de hardware solo del módulo no soluciona el problema.

El chip RC522 se compone de varios registros, la mayoría de los cuales son de lectura y escritura. Para realizar una escritura, el número de registro se envía al módulo seguido del valor a escribir. Para realizar una lectura, se agrega el número de registro 0x80 y se envía al módulo. La respuesta a un comando de escritura es un eco del registro al que se accede. La respuesta a un comando de lectura es el contenido del registro. El software aprovecha ese conocimiento para verificar que el comando se ejecutó correctamente.

Paso 6: Secuencia de acceso al módulo PN532

La rutina de inicio incluye estos pasos necesarios:

· Enviar una cadena de inicialización: esto es específico de la interfaz UART. El manual indica que la interfaz UART se activará en el quinto flanco ascendente detectado en la interfaz. Recomienda enviar 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. En su mayor parte, solo debe haber una cantidad suficiente de caracteres con bordes ascendentes y no deben verse como un preámbulo de comando (00 00 FF).

· Despierta el módulo: Enterrado en el manual del usuario, muestra que el módulo se inicializa en una especie de estado de suspensión llamado “LowVbat”. Para salir de este estado necesitamos enviar un comando "SAMConfiguration".

El PN532 espera que los comandos se envíen en un formato de mensaje definido que incluya un preámbulo, el mensaje y un postámbulo. Los mensajes de respuesta siguen el mismo formato. Los mensajes de comando y respuesta incluyen un TFI (Identificador de trama) y una versión de comando. El comando usa un TFI de 0xD4 y la respuesta usa 0xD5. Las versiones de los comandos varían, pero la respuesta siempre incrementará la versión del comando y la devolverá en el byte que sigue al TFI. Esa coherencia permite que los mensajes de respuesta se escaneen fácilmente en busca de la información relevante.

Cada mensaje de comando (que sigue al preámbulo) consta de la longitud del mensaje, el complemento a 2 de la longitud del mensaje, TFI, comando, datos, suma de comprobación y postámbulo. El software crea los comandos individuales y luego llama a una rutina que calcula la suma de control y agrega el epílogo.

El formato del mensaje para la respuesta es similar al del comando. Una respuesta típica incluirá un ACK (00 00 FF 00 FF 00) seguido de la respuesta específica al comando. Cada respuesta de comando comienza con un preámbulo de 00 00 FF. La respuesta también debe tener un byte TFI de D5 seguido del número de comando incrementado en 1. Para nuestro comando "SAMConfiguration" (14), sería 15. El comando "SAMConfiguration" obtiene esta respuesta: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Hay otros comandos específicos del módulo que se pueden enviar, pero no son necesarios para esta aplicación. Sin embargo, incluí una rutina a la que se puede llamar para recuperar el número de versión del firmware. Una respuesta típica (después del ACK y el preámbulo) sería: 06 FA D5 03 32 01 06 07 E8 00. El “01 06 07” indica el número de versión de firmware 1.6.7.

Paso 7: secuencia de acceso a la etiqueta

Una vez que el módulo esté listo, podemos enviar comandos específicos a las etiquetas. Para leer o escribir datos de etiquetas, necesitamos tener su número de identificación (UID). El UID y la clave se utilizarán para autorizar un sector de datos de etiqueta específico para lecturas / escrituras. Las lecturas / escrituras de datos de etiquetas siempre se realizan en los 16 bytes de un bloque de datos especificado. Eso significa que la aplicación típica leerá el bloque de datos, modificará los datos como desee y luego volverá a escribir los nuevos datos en la etiqueta.

Paso 8: software

Se llama al software de manejo de interrupciones cada vez que el PIC UART recibe un byte de datos. En algunos de mis proyectos UART anteriores, pude sondear la bandera de interrupción RX en lugar de tener que usar un controlador de interrupciones. Ese no es el caso de este software, especialmente para el PN532 que se comunica a una velocidad de transmisión mucho mayor que la del RC522. La interfaz UART del RC522 está limitada a 9600 baudios, mientras que el valor predeterminado para el PN532 es 115k y se puede configurar tan alto como 1.288M baudios. Los bytes recibidos se almacenan en un área de búfer y la parte principal del software los recupera según sea necesario.

La bandera New_Msg indica que se han recibido bytes y Byte_Count indica cuántos. He incluido una rutina "Disp_Buff" en el software que se puede llamar para mostrar el contenido del búfer de recepción durante la depuración. Algunos de los mensajes de respuesta desbordarán una pantalla típica de 1602, pero tengo una pantalla LCD de 40 caracteres por 2 líneas que encontré en un sitio de electrónica de excedentes en línea. La definición de "Max_Line" se puede configurar para el tamaño de su LCD. Si se alcanza "Max_Line", la rutina "Disp_Buff" continúa escribiendo en la segunda línea. Puede agregar un pequeño código a esa rutina para continuar en las líneas tres y cuatro si tiene una pantalla LCD de 4 líneas. Para el PN532 hay un indicador que se puede configurar para que la rutina vuelque todos los bytes recibidos o simplemente vuelque los 16 bytes de datos de una respuesta de lectura.

No es necesario borrar el búfer de recepción o Byte_Count porque borrar el indicador New_Msg hará que el controlador de interrupciones borre Byte_Count y eso es lo que se usa como índice en el búfer. New_Msg generalmente se borra antes de cada paso del comando para que los resultados específicos de ese comando se puedan ubicar y verificar fácilmente. En el RC522 eso significa que el búfer de recepción suele tener solo de 1 a 4 bytes. En algunos casos, como las lecturas de bloques de datos, el comando Read_FIFO debe emitirse varias veces para mover los bytes del FIFO al búfer de recepción. Todos los resultados de los comandos para el PN532 terminan en el búfer de recepción, por lo que se realiza un procedimiento de escaneo para ubicar los bytes específicos necesarios.

El bucle principal del software busca una etiqueta y luego autentica la etiqueta para lecturas / escrituras. Para el software de prueba incluido aquí, la variable Junk_Num se modifica cada vez a través del bucle principal y se utiliza durante la escritura en la etiqueta. Los valores escritos alternan entre el valor de Junk_Num y el complemento a 1 de Junk_Num. Finalmente, se leen y muestran los 16 valores escritos. Hay mensajes en pantalla para cada paso con llamadas de rutina de retraso para dar tiempo a leer cada mensaje. También se proporcionan mensajes de error, pero normalmente solo deberían aparecer si la etiqueta se quita durante una operación.

Parte de la inicialización del software es una sección de código que solo se ejecuta al encender y se omite si se detecta un reinicio del software. Los mensajes de error generalmente terminan con un reinicio del software como una forma de salir del bucle principal. El reinicio ocurre en la rutina de "Inclinación" que simplemente habilita el temporizador de vigilancia y luego entra en un ciclo infinito esperando el tiempo de espera.

Paso 9: Software exclusivo MFRC522

El chip RC522 requiere más instrucciones de bajo nivel que el chip PN532 para realizar comunicaciones con etiquetas. Es como programar en lenguaje ensamblador versus programar en "C". Otra diferencia significativa es que el RC522 requiere que las comunicaciones con la etiqueta se canalicen a través de un búfer FIFO. Las rutinas "Write_FIFO" y "Read_FIFO" manejan esas tareas. El software MFRC522 incluye una sección para muchos de los comandos de nivel inferior a partir de los cuales se construyen las funciones principales.

El cálculo de la suma de verificación del comando de etiqueta para el RC522 es muy diferente al del PN532. Después de que el comando de etiqueta se construye en FIFO, se envía un comando de módulo para calcular la suma de verificación. El resultado de 16 bits no se agrega automáticamente al comando de etiqueta, pero está disponible para leer desde dos registros de 8 bits. El cálculo de la suma de verificación borra los datos en el FIFO, por lo que la secuencia requerida es la siguiente:

· Construye el comando en FIFO

· Ordenar un cálculo de suma de control

· Vuelva a construir el comando en FIFO

· Leer los registros CRC y escribir los bytes de la suma de comprobación en el FIFO

· Enviar un comando Transceive o Authenticate

El comando Transceive transmitirá el búfer FIFO y luego cambiará automáticamente al modo de recepción para esperar la respuesta de la etiqueta. El comando Transceive debe ir seguido de la configuración del bit StartSend en BitFramingRegister para transmitir realmente los datos. El comando Autenticar no tiene ese requisito.

En general, las aplicaciones de código Arduino "C" disponibles en línea utilizan los registros de banderas de interrupción y el registro de tiempo de espera para garantizar que se reciba la respuesta correcta de manera oportuna. En mi opinión, eso es excesivo para esta aplicación que no es crítica en el tiempo. En su lugar, utilizo tiempos de espera de software breves para esperar la respuesta y luego verificar que sea correcta. El manual de las etiquetas Mifare detalla el tiempo para las diversas transacciones y también se permite el tiempo para recibir el número esperado de bytes. Estos retrasos de tiempo están integrados en la mayoría de las subrutinas de comando de bajo nivel.

Paso 10: Software exclusivo PN532

Una vez que se inicializa el módulo, los pasos necesarios para encontrar y autenticar la etiqueta se llevan a cabo escribiendo el comando apropiado seguido de los datos necesarios. El comando de escaneo devuelve el UID que luego se usa para la autenticación. Después de eso, las lecturas y escrituras de la etiqueta envían o devuelven los 16 bytes para el bloque de datos direccionado.

La secuencia de inicialización se detalló anteriormente y la misma rutina de software también envía el comando SAMConfiguration para sacar el módulo del estado "LowVbat". El resto de los comandos básicos, como Escanear, Autenticar, Leer / Escribir etiqueta, simplemente se construyen secuencialmente en las rutinas aplicables. La suma de comprobación se calcula simplemente sumando los bytes del comando, haciendo un complemento y luego sumando 1 para convertirlo en un complemento de 2. El resultado de 8 bits se agrega a la cadena de comando justo antes del postámbulo.

No hay FIFO como en el RC522 por lo que los mensajes de respuesta completos se reciben automáticamente. La rutina "Find_Response" escanea el búfer de datos de recepción para el TFI (0xD5). La rutina se aprovecha de saber cuáles deberían ser los mensajes esperados e ignora las respuestas ACK simples que no incluyen datos. Una vez que se encuentra el TFI, las respuestas deseadas son una compensación conocida. El eco del comando y los bytes de estado del comando se guardan mediante la rutina "Read_Buff" para su posterior verificación.

Eso es todo por esta publicación. Vea mis otros proyectos de electrónica en: www.boomerrules.wordpress.com

Recomendado: