RC522 e PN532 Noções básicas de RFID: 10 etapas

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:37

NOTA: agora tenho Instructables que oferecem o código Arduino para RC522 e PN532.

Algum tempo atrás, comprei três módulos RFID diferentes para experimentar. Em um projeto anterior, expliquei como usar um módulo simples de 125 kHz para realizar uma função básica de segurança. Módulos como esse usam tags somente leitura para que o processo seja varrido para o ID, armazene se desejado e compare com os IDs armazenados. Os outros módulos que comprei operam a 13,56 MHz e usam tags que podem ser lidas e escritas, então é um desperdício simplesmente usá-los para segurança básica. Os dois módulos comuns usam o chip RC522 ou o chip PN532 - ambos fabricados pela NXP.

Se você leu algum dos meus outros projetos, sabe que gosto de usar microcontroladores PIC baratos e programar em linguagem assembly. Então, o que eu estava procurando era uma sequência de etapas necessárias para falar com os módulos e com as etiquetas RFID. Embora existam muitos programas de exemplo online para os módulos, a maioria deles é escrita em software ‘C’ para o Arduino e usa a interface SPI. Além disso, os manuais dos chips e das tags Mifare demoram um pouco para serem decifrados. Este post é principalmente sobre as informações que eu gostaria de ter quando comecei o projeto. Também incluo programas de software de montagem PIC para executar os comandos básicos exigidos por cada módulo. Mesmo que você não use um PIC e / ou linguagem assembly, o código-fonte deve pelo menos fornecer uma boa ideia dos comandos específicos necessários para executar cada etapa.

Etapa 1: interfaces seriais

Ambos os chips usados nesses módulos são capazes de fazer interface via SPI, I2C ou UART (HSSP). O módulo PN532 tem uma chave DIP que é usada para selecionar a interface desejada, mas o módulo MFRC522 é conectado fisicamente para a interface SPI. Eu prefiro usar o UART embutido do PIC, então eu procurei online para ver se havia uma maneira de colocar o módulo MFRC522 no modo UART. O que descobri foi que cortar um traço na placa resolveria o problema. O corte remove efetivamente 3,3 volts do pino EA do chip. Tecnicamente, o pino EA deve ser conectado ao aterramento, mas poucas pessoas podem realizar esse feito de solda dada a densidade do pino do chip. Não se preocupe, porém, porque o pino EA não tem um pull-up interno e não "flutua" como as antigas entradas lógicas TTL. Consulte o diagrama do chip e a imagem da seção da placa para ver o local a ser cortado. Certifique-se de cortar apenas o traço curto que vai diretamente para o pino EA.

Etapa 2: Hardware

As conexões de hardware para comunicações UART são mostradas no diagrama acima. As conexões UART para o MFRC522 não estão marcadas na placa, mas, conforme mostrado no esquema, o pino SDA recebe dados UART e o pino MISO transmite dados UART. O módulo PN532 tem as marcações UART na parte inferior da placa.

Ambos os módulos funcionam com 3,3 volts e o nível lógico de 5 volts do pino PIC TX também precisa ser limitado. A conexão LCD é a configuração padrão de 4 bits que foi usada em vários de meus projetos anteriores. O formato padrão para todas as mensagens é definido para o LCD 1602 padrão (16 caracteres por 2 linhas). Também tenho um LCD de 40 caracteres por 2 linhas que uso para despejos de dados brutos durante a depuração, então incluí um define no software que me permite aproveitar o espaço extra de exibição.

Etapa 3: Blocos de dados

As tags Mifare Classic 1k usadas para este projeto são configuradas como 16 setores, quatro blocos de dados por setor, 16 bytes por bloco de dados. Dos 64 blocos de dados, apenas 47 são realmente utilizáveis. O bloco de dados 0 contém dados do fabricante e os blocos 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 e 63 são chamados de blocos de trailer. Os blocos Trailer são os últimos de cada setor e contêm duas chaves e os bits de acesso do bloco. As chaves e bits de acesso de bloco aplicam-se apenas aos blocos de dados naquele setor, portanto, você pode ter chaves e regras de acesso diferentes para cada setor. As teclas padrão são definidas como “FF FF FF FF FFh”. Para este projeto básico, uso apenas um bloco de dados e mantenho as chaves padrão e os bits de acesso. Existem muitos documentos relacionados a esses cartões, portanto, faça uma pesquisa online por “Mifare” ou visite o site da NXP se quiser explorá-los com mais detalhes.

Etapa 4: Operação geral

Embora os dois módulos sejam exclusivos na maneira como são acessados e acessam as tags, há um processo geral necessário para realizar o trabalho. Para este projeto, assumimos que as tags são do tipo Mifare Classic 1k e que estamos permitindo apenas uma tag por vez no campo da antena. As etapas básicas são definidas a seguir.

· Inicializar o módulo: Em geral, isso requer coisas como escrever valores em registros no chip, enviar comandos de “despertar” e ligar a antena. Em um aplicativo operado por bateria, você gostaria de poder ligar e desligar a antena para economizar bateria, mas para este aplicativo simples, nós a ligamos uma vez e depois a deixamos ligada.

· Limpar o sinalizador de criptografia (apenas 522): Quando uma tag é autenticada, um sinalizador é definido para permitir que o usuário saiba que as comunicações com a tag serão criptografadas. Este sinalizador precisa ser apagado pelo usuário antes da próxima varredura, mesmo se a tag que está sendo escaneada for a mesma.

· Procure uma tag: o módulo basicamente pergunta "Tem alguém aí?" e a tag responde “Estou aqui”. Se o módulo não obtiver uma resposta rápida, ele para de ouvir. Isso significa que precisamos enviar repetidamente comandos de varredura para o módulo até que ele encontre uma tag.

· Obtenha o número de identificação do usuário (UID) do tag: O tag responderá à solicitação de varredura com algumas informações limitadas, como o tipo de tag que é. Isso significa que podemos precisar enviar outro comando para obter seu UID. O UID é de quatro bytes para as tags Mifare Classic 1k. Pode ser mais longo para outras tags, mas este projeto não as aborda.

· Selecione a tag (apenas 522): O UID é usado para selecionar a tag que o usuário deseja autenticar para leituras e gravações. Isso se baseia na possibilidade de haver mais de uma etiqueta no campo da antena. Esse não é o caso de nosso aplicativo simples, mas precisamos selecionar a tag de qualquer maneira.

· Autenticar a tag: Esta etapa é necessária se quisermos fazer alguma leitura ou escrita da tag. Se tudo o que queremos fazer é diferenciar as tags para um aplicativo de segurança simples, o UID é o suficiente. A autenticação requer que conheçamos o UID e que saibamos a chave criptográfica para o setor de dados da tag que queremos acessar. Para este projeto, ficamos com as chaves padrão, mas meu projeto subsequente altera as chaves para que a etiqueta possa ser usada como uma carteira eletrônica.

· Ler ou escrever o tag: As leituras sempre retornam todos os 16 bytes do Bloco de Dados solicitado. As gravações exigem que todos os 16 bytes sejam gravados ao mesmo tempo. Se você quiser ler ou gravar outro bloco no mesmo setor de dados, o tag não precisa ser autenticado novamente. Se você quiser ler ou gravar um bloco em um setor de dados diferente, a tag precisa ser autenticada novamente usando a chave desse setor.

Etapa 5: sequência de acesso ao módulo MFRC522

A rotina de inicialização inclui estas etapas básicas encontradas na maioria dos aplicativos que examinei:

· Enviar byte de dados fictícios (consulte o próximo parágrafo)

· Reinicialização suave

· Definir o ganho do receptor RF (se algo diferente do padrão for desejado)

· Defina a porcentagem de modulação ASK para 100%

· Definir o valor da semente para cálculos CRC

· Ligue a antena

· Obtenha a versão do firmware (não necessária)

Por alguma razão inexplicável, meu módulo liga e pensa que recebeu um comando de gravação sem o byte de dados. Não sei se isso é apenas um problema com meu módulo, mas não vi nenhuma referência a ele em outro lugar. Experimentei reinicializações de hardware e software e nenhuma delas resolveu o problema. Minha solução foi adicionar uma chamada de leitura fictícia para registrar “0” (indefinido) no início da rotina de inicialização do módulo. Se o módulo vê isso como um dado para o comando de gravação desconhecido, não parece haver nenhum efeito prejudicial. Se ele o vir como um comando de leitura, nada de útil acontecerá. Me incomoda que eu não consiga definir totalmente o problema, especialmente considerando que uma redefinição de hardware apenas do módulo não resolve o problema.

O chip RC522 é composto por vários registradores, a maioria dos quais são de leitura e gravação. Para realizar uma escrita, o número do registro é enviado ao módulo seguido pelo valor a ser escrito. Para realizar uma leitura, o número do registro tem 0x80 adicionado a ele e que é enviado ao módulo. A resposta a um comando de escrita é um eco do registro acessado. A resposta a um comando de leitura é o conteúdo do registro. O software aproveita esse conhecimento para verificar se o comando foi executado corretamente.

Etapa 6: Sequência de acesso ao módulo PN532

A rotina de inicialização inclui estas etapas necessárias:

· Enviar uma string de inicialização: Isso é específico para a interface UART. O manual afirma que a interface UART será ativada na quinta borda ascendente detectada na interface. Recomenda o envio de 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Para a maior parte, só precisa haver um número suficiente de caracteres com bordas crescentes e eles não devem se parecer com um preâmbulo de comando (00 00 FF).

· Despertar o módulo: Escondido no manual do usuário, mostra que o módulo inicializa em uma espécie de estado de hibernação chamado “LowVbat”. Para sair deste estado, precisamos enviar um comando “SAMConfiguration”.

O PN532 espera que os comandos sejam enviados em um formato de mensagem definido que inclui um preâmbulo, a mensagem e um postâmbulo. As mensagens de resposta seguem o mesmo formato. As mensagens de comando e resposta incluem um TFI (identificador de quadro) e uma versão de comando. O comando usa um TFI de 0xD4 e a resposta usa 0xD5. As versões do comando variam, mas a resposta sempre incrementará a versão do comando e a retornará no byte seguinte ao TFI. Essa consistência permite que as mensagens de resposta sejam facilmente verificadas em busca de informações relevantes.

Cada mensagem de comando (seguindo o preâmbulo) consiste no comprimento da mensagem, o complemento de 2 do comprimento da mensagem, TFI, comando, dados, soma de verificação e postâmbulo. O software constrói os comandos individuais e, em seguida, chama uma rotina que calcula a soma de verificação e anexa o postâmbulo.

O formato da mensagem para a resposta é semelhante ao do comando. Uma resposta típica incluirá um ACK (00 00 FF 00 FF 00) seguido pela resposta específica ao comando. Cada resposta de comando começa com um preâmbulo de 00 00 FF. A resposta também deve ter um byte TFI de D5 seguido pelo número do comando incrementado por 1. Para nosso comando “SAMConfiguration” (14), isso seria 15. O comando “SAMConfiguration” obtém esta resposta: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Existem outros comandos específicos do módulo que podem ser enviados, mas eles não são necessários para este aplicativo. No entanto, incluí uma rotina que pode ser chamada para recuperar o número da versão do firmware. Uma resposta típica (após o ACK e o preâmbulo) seria: 06 FA D5 03 32 01 06 07 E8 00. O “01 06 07” indica o número da versão do firmware 1.6.7.

Etapa 7: sequência de acesso à tag

Depois que o módulo estiver pronto, podemos enviar comandos específicos para os tags. Para ler ou gravar dados do tag, precisamos ter seu número de identificação (UID). O UID e a chave serão então usados para autorizar um setor de dados de tag específico para leituras / gravações. Leituras / gravações de dados de tag são sempre feitas em todos os 16 bytes em um bloco de dados especificado. Isso significa que o aplicativo típico lerá o bloco de dados, modificará os dados conforme desejado e, em seguida, gravará os novos dados de volta no tag.

Etapa 8: Software

O software manipulador de interrupção é chamado sempre que o PIC UART recebe um byte de dados. Em alguns dos meus projetos UART anteriores, consegui apenas pesquisar o sinalizador de interrupção RX em vez de ter que usar um manipulador de interrupção. Esse não é o caso deste software, especialmente do PN532, que se comunica a uma taxa de transmissão muito mais alta do que o RC522. A interface UART do RC522 é limitada a 9600 baud, enquanto o padrão para o PN532 é 115k e pode ser definido até 1.288M baud. Os bytes recebidos são armazenados em uma área de buffer e a parte principal do software os recupera conforme necessário.

O sinalizador New_Msg indica que bytes foram recebidos e Byte_Count indica quantos. Eu incluí uma rotina "Disp_Buff" no software que pode ser chamada para exibir o conteúdo do buffer de recepção durante a depuração. Algumas das mensagens de retorno irão estourar um display 1602 típico, mas eu tenho um LCD de 40 caracteres por 2 linhas que encontrei em um site de eletrônicos excedentes online. A definição “Max_Line” pode ser definida para o tamanho do seu LCD. Se “Max_Line” for alcançado, a rotina “Disp_Buff” continua escrevendo para a segunda linha. Você poderia adicionar um pequeno código a essa rotina para continuar nas linhas três e quatro se tiver um LCD de 4 linhas. Para o PN532, há um sinalizador que pode ser definido de forma que a rotina descarte todos os bytes recebidos ou apenas descarte os 16 bytes de dados de uma resposta de leitura.

Não há necessidade de limpar o buffer de recebimento ou Byte_Count porque limpar o sinalizador New_Msg fará com que Byte_Count seja limpo pelo manipulador de interrupção e é isso que é usado como o índice no buffer. New_Msg geralmente é apagado antes de cada etapa do comando para que os resultados específicos desse comando possam ser facilmente localizados e verificados. No RC522, isso significa que o buffer de recepção geralmente tem apenas 1 a 4 bytes. Em alguns casos, como leituras de bloco de dados, o comando Read_FIFO deve ser emitido várias vezes para mover os bytes do FIFO para o buffer de recebimento. Todos os resultados do comando para o PN532 vão para o buffer de recepção, então um procedimento de varredura é executado para localizar os bytes específicos necessários.

O loop principal no software procura uma tag e, em seguida, autentica a tag para leituras / gravações. Para o software de teste incluído aqui, a variável Junk_Num é modificada a cada vez por meio do loop principal e é usada durante a gravação no tag. Os valores escritos alternam entre o valor de Junk_Num e o complemento de 1 de Junk_Num. Finalmente, os 16 valores escritos são lidos e exibidos. Existem mensagens de exibição para cada etapa com chamadas de rotina de atraso para permitir tempo para ler cada mensagem. Mensagens de erro também são fornecidas, mas normalmente só devem ocorrer se a tag for removida durante uma operação.

Parte da inicialização do software é uma seção de código que só é executada na inicialização e é ignorada se uma reinicialização do software for detectada. As mensagens de erro geralmente terminam com uma reinicialização do software como forma de sair do loop principal. O reset acontece na rotina “Tilt” que simplesmente habilita o Watchdog Timer e então entra em um loop infinito esperando pelo timeout.

Etapa 9: Software exclusivo MFRC522

O chip RC522 requer mais instruções de baixo nível do que o chip PN532 para realizar a comunicação com tags. É como programar em linguagem assembly versus programar em “C”. Outra diferença significativa é que o RC522 requer que as comunicações com a tag sejam canalizadas por meio de um buffer FIFO. As rotinas “Write_FIFO” e “Read_FIFO” tratam dessas tarefas. O software MFRC522 inclui uma seção para muitos dos comandos de nível inferior a partir dos quais as funções principais são criadas.

O cálculo da soma de verificação do comando tag para o RC522 é muito diferente do PN532. Depois que o comando de tag é construído no FIFO, um comando de módulo é enviado para calcular a soma de verificação. O resultado de 16 bits não é anexado automaticamente ao comando tag, mas está disponível para leitura em dois registradores de 8 bits. O cálculo da soma de verificação apaga os dados no FIFO, então a sequência necessária é a seguinte:

· Construir o comando no FIFO

· Comandar um cálculo de checksum

· Construir o comando no FIFO novamente

· Ler os registros CRC e escrever os bytes de checksum no FIFO

· Envie um comando Transceive ou Authenticate

O comando Transceive transmitirá o buffer FIFO e, em seguida, alternará automaticamente para o modo de recepção para aguardar a resposta da tag. O comando Transceive deve ser seguido pela configuração do bit StartSend no BitFramingRegister para realmente transmitir os dados. O comando Authenticate não tem esse requisito.

Em geral, os aplicativos de código Arduino “C” disponíveis on-line usam os registros de sinalizadores de interrupção e o registro de tempo limite para garantir que a resposta correta seja recebida em tempo hábil. Em minha opinião, isso é um exagero para esta aplicação que não exige tempo. Em vez disso, uso tempos limites curtos de software para aguardar a resposta e, em seguida, verificar se ela está correta. O manual para as tags Mifare detalha o tempo para as várias transações e o tempo também é permitido para o número esperado de bytes a serem recebidos. Esses atrasos de tempo são integrados à maioria das sub-rotinas de comando de baixo nível.

Etapa 10: Software exclusivo PN532

Depois que o módulo é inicializado, as etapas necessárias para localizar e autenticar a tag são realizadas escrevendo o comando apropriado seguido dos dados necessários. O comando scan retorna o UID que é então usado para a autenticação. Depois disso, as leituras e escritas do tag enviam ou retornam os 16 bytes para o bloco de dados endereçado.

A sequência de inicialização foi detalhada anteriormente e a mesma rotina de software também envia o comando SAMConfiguration para tirar o módulo do estado “LowVbat”. O resto dos comandos básicos, como Scan, Authenticate, Read / Write Tag, são apenas construídos sequencialmente nas rotinas aplicáveis. A soma de verificação é calculada apenas adicionando os bytes de comando, fazendo um complemento e, em seguida, adicionando 1 para torná-lo um complemento de 2. O resultado de 8 bits é anexado à string de comando antes do postâmbulo.

Não há FIFO como no RC522, portanto, as mensagens de resposta completas são recebidas automaticamente. A rotina “Find_Response” varre o buffer de recepção de dados para o TFI (0xD5). A rotina aproveita para saber quais devem ser as mensagens esperadas e ignora respostas ACK simples que não incluem dados. Uma vez que o TFI é encontrado, as respostas desejadas são um deslocamento conhecido dele. O eco do comando e os bytes do status do comando são salvos pela rotina “Read_Buff” para verificação posterior.

É isso para este post. Confira meus outros projetos eletrônicos em: www.boomerrules.wordpress.com