Основы RFID RC522 и PN532: 10 шагов

2024 Автор: John Day | [email protected]. Последнее изменение: 2024-01-30 11:51

ПРИМЕЧАНИЕ. Теперь у меня есть Instructables, которые предлагают код Arduino для RC522 и PN532.

Некоторое время назад я купил три разных модуля RFID для экспериментов. В предыдущем проекте я подробно описал, как использовать простой модуль 125 кГц для выполнения базовой функции безопасности. Такие модули используют теги только для чтения, поэтому процесс сканирует идентификатор, сохраняет при желании и сравнивает с сохраненными идентификаторами. Другие модули, которые я купил, работают на частоте 13,56 МГц и используют теги, которые можно как читать, так и писать, поэтому просто использовать их для базовой безопасности - пустая трата времени. В двух общих модулях используется либо микросхема RC522, либо микросхема PN532 - оба производства NXP.

Если вы читали другие мои проекты, то знаете, что я люблю использовать дешевые микроконтроллеры PIC и программы на языке ассемблера. Так что я искал последовательность шагов, необходимых для общения с модулями и RFID-метками. Хотя в Интернете есть множество примеров программ для модулей, большинство из них написаны на программном обеспечении «C» для Arduino и используют интерфейс SPI. Кроме того, необходимо немного расшифровать руководства для чипов и тегов Mifare. Этот пост в первую очередь посвящен той информации, которую я хотел бы иметь, когда начинал проект. Я также включаю программы сборки PIC для выполнения основных команд, требуемых каждым модулем. Даже если вы не используете PIC и / или язык ассемблера, исходный код должен, по крайней мере, дать вам хорошее представление о конкретных командах, необходимых для выполнения каждого шага.

Шаг 1. Последовательные интерфейсы

Обе микросхемы, используемые в этих модулях, могут взаимодействовать через SPI, I2C или UART (HSSP). Модуль PN532 имеет DIP-переключатель, который используется для выбора желаемого интерфейса, но модуль MFRC522 жестко подключен к интерфейсу SPI. Я предпочитаю использовать встроенный UART PIC, поэтому я поискал в Интернете, чтобы узнать, есть ли способ перевести модуль MFRC522 в режим UART. Я обнаружил, что вырезание одного следа на доске поможет. Разрез эффективно снимает 3,3 вольта с вывода EA микросхемы. Технически вывод EA должен быть затем подключен к земле, но не многие люди могут осуществить эту пайку, учитывая плотность выводов микросхемы. Однако не беспокойтесь, потому что вывод EA не имеет внутреннего подтягивания и не «плавает», как старые логические входы TTL. Обратитесь к схеме микросхемы и изображению разреза платы, чтобы найти место для резки. Убедитесь, что вы обрезали только короткую дорожку, идущую непосредственно к выводу советника.

Шаг 2: Оборудование

Аппаратные соединения для связи UART показаны на схеме выше. Соединения UART для MFRC522 не отмечены на плате, но, как показано на схеме, вывод SDA принимает данные UART, а вывод MISO передает данные UART. Модуль PN532 имеет маркировку UART на нижней стороне платы.

Оба модуля работают от 3,3 В, и логический уровень 5 В на выводе PIC TX также должен быть ограничен. Подключение ЖК-дисплея представляет собой стандартную 4-битную установку, которая использовалась в ряде моих предыдущих проектов. Формат по умолчанию для всех сообщений установлен для стандартного ЖК-дисплея 1602 (16 символов на 2 строки). У меня также есть 40-символьный двухстрочный ЖК-дисплей, который я использую для дампа необработанных данных во время отладки, поэтому я включил определение в программное обеспечение, которое позволяет мне использовать дополнительное пространство дисплея.

Шаг 3: блоки данных

Теги Mifare Classic 1k, используемые для этого проекта, сконфигурированы как 16 секторов, четыре блока данных на сектор, 16 байтов на блок данных. Из 64 блоков данных фактически можно использовать только 47. Блок данных 0 содержит данные производителя, а блоки 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 и 63 называются блоками трейлера. Блоки трейлера являются последними в каждом секторе и содержат два ключа и биты доступа к блоку. Ключи и биты доступа к блокам применяются только к блокам данных в этом секторе, поэтому у вас могут быть разные ключи и правила доступа для каждого сектора. Клавиши по умолчанию установлены на «FF FF FF FF FFh». Для этого базового проекта я использую только один блок данных и сохраняю ключи и биты доступа по умолчанию. Есть много документов, связанных с этими картами, поэтому просто выполните поиск в Интернете по запросу «Mifare» или посетите веб-сайт NXP, если вы хотите изучить их более подробно.

Шаг 4: Общие операции

Хотя оба модуля уникальны по способу доступа к ним и по способу доступа к тегам, существует общий процесс, необходимый для выполнения работы. В этом проекте мы предполагаем, что теги относятся к типу Mifare Classic 1k и что мы разрешаем только один тег за раз в поле антенны. Основные шаги определены ниже.

· Инициализировать модуль. Обычно для этого требуются такие вещи, как запись значений в регистры микросхемы, отправка команд «пробуждения» и включение питания антенны. В приложении с батарейным питанием вы хотели бы иметь возможность включать и выключать антенну для экономии заряда батареи, но для этого простого приложения мы включаем ее один раз, а затем оставляем включенной.

· Очистить криптографический флаг (только 522): когда тег аутентифицирован, устанавливается флаг, чтобы пользователь знал, что обмен данными с тегом будет зашифрован. Этот флаг должен быть сброшен пользователем перед следующим сканированием, даже если сканируемый тег тот же самый.

· Сканировать на наличие тега: модуль обычно спрашивает: «Есть ли там кто-нибудь?» и тег отвечает: «Я здесь». Если модуль не получает быстрого ответа, он перестает слушать. Это означает, что нам нужно многократно посылать модулю команды сканирования, пока он не найдет тег.

· Получить идентификационный номер пользователя (UID) тега: тег ответит на запрос сканирования с некоторой ограниченной информацией, такой как тип тега. Это означает, что нам может потребоваться отправить другую команду, чтобы получить его UID. UID составляет четыре байта для тегов Mifare Classic 1k. If может быть длиннее для других тегов, но в этом проекте они не рассматриваются.

· Выберите тег (только 522): UID используется для выбора тега, который пользователь хочет аутентифицировать для чтения и записи. Это основано на возможности того, что в антенном поле может быть более одной метки. Это не относится к нашему простому приложению, но нам все равно нужно выбрать тег.

· Проверка подлинности тега: этот шаг необходим, если мы хотим выполнить какое-либо чтение или запись тега. Если все, что мы хотим сделать, это различать теги для простого приложения безопасности, тогда UID будет достаточно. Аутентификация требует, чтобы мы знали UID и криптоключ для сектора данных тега, к которому мы хотим получить доступ. В этом проекте мы придерживаемся ключей по умолчанию, но в моем последующем проекте ключи меняются так, чтобы тег можно было использовать в качестве электронного кошелька.

· Чтение или запись тега: чтение всегда возвращает все 16 байтов запрошенного блока данных. Для записи необходимо, чтобы все 16 байтов были записаны одновременно. Если вы хотите прочитать или записать другой блок в том же секторе данных, тег не нуждается в повторной аутентификации. Если вы хотите прочитать или записать блок в другом секторе данных, тег необходимо снова аутентифицировать с использованием ключа для этого сектора.

Шаг 5: Последовательность доступа к модулю MFRC522

Процедура запуска включает следующие основные шаги, которые есть в большинстве рассмотренных мной приложений:

· Отправить фиктивный байт данных (см. Следующий абзац)

· Мягкий сброс

· Установите усиление РЧ приемника (если желательно что-то другое, кроме значения по умолчанию)

· Установите процент модуляции ASK на 100%

· Установить начальное значение для вычислений CRC

· Включите антенну

· Получить версию прошивки (не обязательно)

По какой-то необъяснимой причине мой модуль включается и думает, что получил команду записи без байта данных. Я не знаю, связана ли это только с моим модулем, но я не видел никаких ссылок на него в другом месте. Я экспериментировал как с аппаратным, так и с программным сбросом, и ни один из них не устранил проблему. Мое решение состояло в том, чтобы добавить фиктивный вызов чтения для регистрации «0» (неопределенный) в начале процедуры инициализации модуля. Если модуль воспринимает это как данные для неизвестной команды записи, то никаких побочных эффектов не наблюдается. Если он видит это как команду чтения, то ничего полезного не происходит. Меня беспокоит то, что я не могу полностью определить проблему, особенно с учетом того, что аппаратный сброс только модуля не решает проблему.

Микросхема RC522 состоит из ряда регистров, большинство из которых предназначены для чтения и записи. Для выполнения записи в модуль отправляется номер регистра, за которым следует записываемое значение. Чтобы выполнить чтение, к номеру регистра добавляется 0x80, и он отправляется в модуль. Ответ на команду записи - это эхо регистра, к которому был осуществлен доступ. Ответ на команду чтения - это содержимое регистра. Программное обеспечение использует эти знания для проверки правильности выполнения команды.

Шаг 6: Последовательность доступа к модулю PN532

Процедура запуска включает следующие обязательные шаги:

· Отправить строку инициализации: это характерно для интерфейса UART. В руководстве указано, что интерфейс UART активируется при пятом нарастающем фронте, обнаруженном на интерфейсе. Рекомендуется отправлять 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. По большей части просто должно быть достаточное количество символов с нарастающими фронтами, и они не должны выглядеть как преамбула команды (00 00 FF).

· Разбудить модуль: в руководстве пользователя указано, что модуль инициализируется в своего рода спящий режим, называемый «LowVbat». Чтобы выйти из этого состояния, нам нужно отправить команду «SAMConfiguration».

PN532 ожидает, что команды будут отправлены в определенном формате сообщения, который включает в себя преамбулу, сообщение и постамблю. Ответные сообщения имеют тот же формат. Командные и ответные сообщения включают в себя TFI (идентификатор кадра) и версию команды. Команда использует TFI 0xD4, а ответ использует 0xD5. Версии команд различаются, но ответ всегда будет увеличивать версию команды и возвращать ее в байте, следующем за TFI. Такая согласованность позволяет легко сканировать ответные сообщения на предмет соответствующей информации.

Каждое командное сообщение (следующее за преамбулой) состоит из длины сообщения, дополнения до 2 длины сообщения, TFI, команды, данных, контрольной суммы и постамбулы. Программное обеспечение создает отдельные команды, а затем вызывает процедуру, которая вычисляет контрольную сумму и добавляет постамблю.

Формат сообщения для ответа аналогичен формату команды. Типичный ответ будет включать ACK (00 00 FF 00 FF 00), за которым следует конкретный ответ на команду. Каждый ответ на команду начинается с преамбулы 00 00 FF. В ответе также должен быть байт TFI D5, за которым следует номер команды, увеличенный на 1. Для нашей команды «SAMConfiguration» (14) это будет 15. Команда «SAMConfiguration» получает следующий ответ: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Есть и другие специфичные для модуля команды, которые можно отправлять, но они не нужны для этого приложения. Однако я включил подпрограмму, которую можно вызвать для получения номера версии прошивки. Типичный ответ (после ACK и преамбулы) будет: 06 FA D5 03 32 01 06 07 E8 00. «01 06 07» указывает номер версии прошивки 1.6.7.

Шаг 7. Последовательность доступа к тегу

После того, как модуль будет готов, мы можем отправлять команды, специфичные для тегов. Для чтения или записи данных тега нам нужен его идентификационный номер (UID). Затем UID и ключ будут использоваться для авторизации определенного сектора данных тега для чтения / записи. Чтение / запись данных тега всегда выполняются для всех 16 байтов в указанном блоке данных. Это означает, что типичное приложение будет читать блок данных, изменять данные по желанию, а затем записывать новые данные обратно в тег.

Шаг 8: Программное обеспечение

Программа обработки прерывания вызывается всякий раз, когда PIC UART получает байт данных. В некоторых из моих предыдущих проектов UART я мог просто опросить флаг прерывания RX вместо того, чтобы использовать обработчик прерывания. Это не относится к этому программному обеспечению, особенно к PN532, который обменивается данными на гораздо более высокой скорости передачи, чем RC522. Интерфейс UART RC522 ограничен 9600 бод, в то время как значение по умолчанию для PN532 составляет 115 кбит / с и может быть установлено на 1,288 Мбод. Полученные байты сохраняются в буферной области, и основная часть программного обеспечения извлекает их по мере необходимости.

Флаг New_Msg указывает, что байты были получены, а Byte_Count указывает, сколько байтов. Я включил в программу подпрограмму Disp_Buff, которую можно вызвать для отображения содержимого приемного буфера во время отладки. Некоторые из ответных сообщений будут выходить за пределы типичного дисплея 1602, но у меня есть ЖК-дисплей размером 40 символов на 2 строки, который я нашел на онлайн-сайте излишков электроники. Определение «Max_Line» может быть установлено для размера вашего ЖК-дисплея. Если достигается «Max_Line», процедура «Disp_Buff» продолжает запись во вторую строку. Вы можете добавить небольшой код в эту процедуру, чтобы продолжить работу на третьей и четвертой строках, если у вас 4-строчный ЖК-дисплей. Для PN532 есть флаг, который может быть установлен таким образом, что подпрограмма либо выгружает все полученные байты, либо просто выгружает 16 байтов данных из ответа на чтение.

Нет необходимости очищать буфер приема или Byte_Count, потому что очистка флага New_Msg приведет к тому, что Byte_Count будет очищен обработчиком прерывания, и это то, что используется в качестве индекса в буфере. New_Msg обычно очищается перед каждым шагом команды, чтобы можно было легко найти и проверить результаты, специфичные для этой команды. В RC522 это означает, что буфер приема обычно имеет от 1 до 4 байтов. В некоторых случаях, например при чтении блока данных, команду Read_FIFO необходимо запускать несколько раз, чтобы переместить байты из FIFO в приемный буфер. Все результаты команд для PN532 попадают в приемный буфер, поэтому выполняется процедура сканирования для поиска конкретных необходимых байтов.

Основной цикл в программном обеспечении сканирует тег, а затем аутентифицирует тег для чтения / записи. Для включенного сюда тестового программного обеспечения переменная Junk_Num изменяется каждый раз в основном цикле и используется во время записи в тег. Записанные значения чередуются между значением Junk_Num и дополнением до 1 Junk_Num. Наконец, 16 записанных значений считываются и отображаются. Для каждого шага есть сообщения на дисплее с вызовами процедуры задержки, чтобы дать время прочитать каждое сообщение. Также предоставляются сообщения об ошибках, но обычно они возникают только в том случае, если тег удаляется во время операции.

Часть инициализации программного обеспечения - это часть кода, которая выполняется только при включении питания и пропускается, если обнаружен программный сброс. Сообщения об ошибках обычно заканчиваются программным сбросом как способом выхода из основного цикла. Сброс происходит в подпрограмме «Наклон», которая просто включает сторожевой таймер, а затем переходит в бесконечный цикл, ожидая тайм-аута.

Шаг 9: Уникальное программное обеспечение MFRC522

Микросхема RC522 требует большего количества команд нижнего уровня, чем микросхема PN532, для осуществления связи с тегами. Это похоже на программирование на языке ассемблера или программирование на «C». Еще одно существенное отличие состоит в том, что RC522 требует, чтобы обмен данными с тегом проходил через буфер FIFO. Подпрограммы «Write_FIFO» и «Read_FIFO» обрабатывают эти задачи. Программное обеспечение MFRC522 включает раздел для многих команд нижнего уровня, из которых строятся основные функции.

Расчет контрольной суммы команды тегов для RC522 сильно отличается от PN532. После того, как команда тега встроена в FIFO, отправляется команда модуля для вычисления контрольной суммы. 16-битный результат не добавляется автоматически к команде тега, но доступен для чтения из двух 8-битных регистров. Расчет контрольной суммы стирает данные в FIFO, поэтому необходимая последовательность выглядит следующим образом:

· Создайте команду в FIFO

· Подайте команду на вычисление контрольной суммы

· Снова создайте команду в FIFO

· Прочитать регистры CRC и записать байты контрольной суммы в FIFO

· Отправьте команду "Принять" или "Проверить подлинность"

Команда Transceive передаст буфер FIFO, а затем автоматически переключится в режим приема, чтобы дождаться ответа от тега. За командой Transceive должна следовать установка бита StartSend в BitFramingRegister для фактической передачи данных. Команда Authenticate не требует этого.

В общем, приложения с кодом Arduino «C», доступные в сети, используют регистры флагов прерывания и регистр тайм-аута, чтобы гарантировать своевременный получение правильного ответа. На мой взгляд, это перебор для этого некритичного по времени приложения. Вместо этого я использую короткие программные тайм-ауты, чтобы дождаться ответа, а затем проверить его правильность. В руководстве по тегам Mifare подробно описывается время для различных транзакций, а также время, отведенное для ожидаемого количества получаемых байтов. Эти временные задержки встроены в большинство подпрограмм команд нижнего уровня.

Шаг 10: Уникальное программное обеспечение PN532

После инициализации модуля шаги, необходимые для поиска и аутентификации тега, выполняются путем написания соответствующей команды, за которой следуют необходимые данные. Команда сканирования возвращает UID, который затем используется для аутентификации. После этого операции чтения и записи тега отправляют или возвращают 16 байтов для адресуемого блока данных.

Последовательность инициализации была подробно описана ранее, и та же программная процедура также отправляет команду SAMConfiguration, чтобы вывести модуль из состояния «LowVbat». Остальные основные команды, такие как сканирование, аутентификация, чтение / запись тега, просто последовательно встроены в соответствующие процедуры. Контрольная сумма вычисляется путем простого сложения байтов команды, выполнения дополнения и последующего добавления 1, чтобы получилось дополнение до 2. 8-битный результат добавляется к командной строке непосредственно перед постамблеей.

В RC522 нет FIFO, поэтому полные ответные сообщения принимаются автоматически. Подпрограмма Find_Response сканирует буфер принимаемых данных на предмет TFI (0xD5). Подпрограмма использует знание того, какими должны быть ожидаемые сообщения, и игнорирует простые ответы ACK, не содержащие данных. Как только TFI найден, желаемые отклики представляют собой известное смещение от него. Эхо команды и байты состояния команды сохраняются процедурой Read_Buff для последующей проверки.

Это все для этого поста. Ознакомьтесь с моими другими проектами в области электроники на сайте: www.boomerrules.wordpress.com