Podstawy RFID RC522 i PN532: 10 kroków

2024 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2024-01-30 11:30

UWAGA: Mam teraz instrukcje, które oferują kod Arduino dla RC522 i PN532.

Jakiś czas temu kupiłem trzy różne moduły RFID do eksperymentów. W poprzednim projekcie szczegółowo opisałem, jak użyć prostego modułu 125 kHz do wykonania podstawowej funkcji bezpieczeństwa. Takie moduły używają tagów tylko do odczytu, więc proces polega na skanowaniu identyfikatora, przechowywaniu w razie potrzeby i porównywaniu z przechowywanymi identyfikatorami. Inne moduły, które kupiłem, pracują z częstotliwością 13,56 MHz i używają tagów, które można zarówno czytać, jak i zapisywać, więc szkoda jest po prostu używać ich do podstawowego bezpieczeństwa. Dwa popularne moduły wykorzystują układ RC522 lub układ PN532 – oba wykonane przez NXP.

Jeśli czytałeś któryś z moich innych projektów wiesz, że lubię używać tanich mikrokontrolerów PIC i programu w języku asemblerowym. Więc to, czego szukałem, to sekwencja kroków wymaganych do komunikowania się z modułami i tagami RFID. Chociaż istnieje wiele przykładowych programów online dla modułów, większość z nich jest napisana w oprogramowaniu „C” dla Arduino i korzysta z interfejsu SPI. Również instrukcje dotyczące chipów i tagów Mifare wymagają trochę rozszyfrowania. Ten post dotyczy przede wszystkim informacji, które chciałbym mieć, kiedy zaczynałem projekt. Zawieram również programy do montażu PIC do wykonywania podstawowych poleceń wymaganych przez każdy moduł. Nawet jeśli nie używasz PIC i/lub języka asemblera, kod źródłowy powinien przynajmniej dać ci dobre pojęcie o konkretnych poleceniach wymaganych do wykonania każdego kroku.

Krok 1: Interfejsy szeregowe

Oba chipy zastosowane w tych modułach mogą łączyć się przez SPI, I2C lub UART (HSSP). Moduł PN532 ma przełącznik DIP, który służy do wyboru żądanego interfejsu, ale moduł MFRC522 jest podłączony na stałe do interfejsu SPI. Wolę korzystać z wbudowanego UART PIC, więc polowałem online, aby sprawdzić, czy istnieje sposób na przełączenie modułu MFRC522 w tryb UART. Odkryłem, że wystarczy wyciąć jeden ślad na desce. Cięcie skutecznie usuwa napięcie 3,3 V z pinu EA chipa. Z technicznego punktu widzenia pin EA powinien być następnie podłączony do uziemienia, ale niewiele osób może wykonać ten wyczyn lutowania, biorąc pod uwagę gęstość pinów chipa. Nie martw się jednak, ponieważ pin EA nie ma wewnętrznego podciągania i nie „pływa”, jak robią to stare wejścia logiczne TTL. Zapoznaj się ze schematem chipów i obrazem przekroju płytki, aby znaleźć miejsce do wycięcia. Upewnij się, że przecinasz tylko krótki ślad idący bezpośrednio do pinu EA.

Krok 2: Sprzęt

Połączenia sprzętowe do komunikacji UART pokazano na powyższym schemacie. Połączenia UART dla MFRC522 nie są zaznaczone na płytce, ale, jak pokazano na schemacie, pin SDA odbiera dane UART, a pin MISO przesyła dane UART. Moduł PN532 posiada oznaczenia UART na spodniej stronie płytki.

Oba moduły działają na 3,3 V, a poziom logiczny 5 V z pinu PIC TX również musi być ograniczony. Połączenie LCD to standardowa konfiguracja 4-bitowa, która była używana w wielu moich poprzednich projektach. Domyślny format wszystkich komunikatów jest ustawiony dla standardowego wyświetlacza LCD 1602 (16 znaków na 2 linie). Mam również wyświetlacz LCD o wielkości 40 znaków na 2 wiersze, którego używam do zrzutów surowych danych podczas debugowania, więc w oprogramowaniu zawarłem definicję, która pozwala mi wykorzystać dodatkową przestrzeń wyświetlania.

Krok 3: Bloki danych

Tagi Mifare Classic 1k używane w tym projekcie są skonfigurowane jako 16 sektorów, cztery bloki danych na sektor, 16 bajtów na blok danych. Z 64 bloków danych tylko 47 nadaje się do użytku. Blok danych 0 zawiera dane producenta, a bloki 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 i 63 nazywane są blokami przyczep. Bloki Trailer są ostatnimi w każdym sektorze i zawierają dwa klucze oraz bity dostępu do bloku. Klucze i bity dostępu do bloku dotyczą tylko bloków danych w tym sektorze, więc możesz mieć różne klucze i reguły dostępu dla każdego sektora. Domyślne klawisze są ustawione na „FF FF FF FF FFh”. W tym podstawowym projekcie używam tylko jednego bloku danych i zachowuję domyślne klucze i bity dostępu. Istnieje wiele dokumentów związanych z tymi kartami, więc po prostu wyszukaj w Internecie „Mifare” lub odwiedź witrynę NXP, jeśli chcesz je dokładniej zbadać.

Krok 4: Ogólna obsługa

Chociaż oba moduły są unikalne pod względem sposobu uzyskiwania do nich dostępu i sposobu, w jaki uzyskują dostęp do tagów, istnieje ogólny proces wymagany do wykonania zadania. W tym projekcie zakładamy, że tagi są typu Mifare Classic 1k i że w polu anteny dopuszczamy tylko jeden tag na raz. Podstawowe kroki są zdefiniowane poniżej.

· Zainicjuj moduł: Na ogół wymaga to takich rzeczy, jak zapisywanie wartości do rejestrów w chipie, wysyłanie poleceń „wybudzenia” i włączanie zasilania anteny. W aplikacji zasilanej bateryjnie chciałbyś mieć możliwość włączania i wyłączania zasilania anteny, aby oszczędzać baterię, ale w tej prostej aplikacji włączamy ją raz, a następnie zostawiamy włączoną.

· Wyczyść flagę kryptograficzną (tylko 522): Po uwierzytelnieniu znacznika ustawiana jest flaga informująca użytkownika, że komunikacja ze znacznikiem będzie szyfrowana. Ta flaga musi zostać wyczyszczona przez użytkownika przed następnym skanowaniem, nawet jeśli skanowany znacznik jest tym samym.

· Skanuj w poszukiwaniu tagu: moduł zasadniczo pyta „Czy ktoś tam jest?” a tag odpowiada „Jestem tutaj”. Jeśli moduł nie otrzyma szybkiej odpowiedzi, przestaje nasłuchiwać. Oznacza to, że musimy wielokrotnie wysyłać polecenia skanowania do modułu, aż znajdzie tag.

· Uzyskaj numer identyfikacyjny użytkownika tagu (UID): tag odpowie na żądanie skanowania z pewnymi ograniczonymi informacjami, takimi jak typ tagu. Oznacza to, że możemy potrzebować wysłać kolejne polecenie, aby uzyskać jego UID. UID to cztery bajty dla tagów Mifare Classic 1k. Może być dłuższy dla innych tagów, ale ten projekt ich nie dotyczy.

· Wybierz znacznik (tylko 522): UID jest używany do wyboru znacznika, który użytkownik chce uwierzytelnić do odczytu i zapisu. Jest to oparte na możliwości, że w polu anteny może znajdować się więcej niż jeden znacznik. Tak nie jest w przypadku naszej prostej aplikacji, ale i tak musimy wybrać tag.

· Uwierzytelnij znacznik: Ten krok jest wymagany, jeśli chcemy wykonać odczyt lub zapis znacznika. Jeśli wszystko, co chcemy zrobić, to rozróżnić tagi dla prostej aplikacji zabezpieczającej, to wystarczy UID. Uwierzytelnianie wymaga znajomości UID i klucza kryptograficznego dla sektora danych tagu, do którego chcemy uzyskać dostęp. W tym projekcie trzymamy się domyślnych kluczy, ale mój kolejny projekt zmienia klucze, aby tag mógł być używany jako portfel elektroniczny.

· Odczyt lub zapis tagu: Odczyty zawsze zwracają wszystkie 16 bajtów żądanego bloku danych. Zapisy wymagają jednoczesnego zapisu wszystkich 16 bajtów. Jeśli chcesz odczytać lub zapisać inny blok w tym samym sektorze danych, znacznik nie musi być ponownie uwierzytelniany. Jeśli chcesz odczytać lub zapisać blok w innym sektorze danych, tag musi zostać ponownie uwierzytelniony przy użyciu klucza dla tego sektora.

Krok 5: Sekwencja dostępu do modułu MFRC522

Procedura uruchamiania obejmuje te podstawowe kroki, które można znaleźć w większości aplikacji, które przeglądałem:

· Wyślij fikcyjny bajt danych (patrz następny akapit)

· Miękki reset

· Ustaw wzmocnienie odbiornika RF (jeśli pożądane jest coś innego niż domyślne)

· Ustaw procent modulacji ASK na 100%

· Ustaw wartość ziarna do obliczeń CRC

· Włącz antenę

· Pobierz wersję oprogramowania (niewymagane)

Z jakiegoś niewyjaśnionego powodu mój moduł włącza się i myśli, że otrzymał polecenie zapisu bez bajtu danych. Nie wiem, czy to tylko problem z moim modułem, ale nie widziałem żadnych odniesień do niego gdzie indziej. Eksperymentowałem zarówno z resetowaniem sprzętu, jak i oprogramowania i nie naprawiłem problemu. Moje rozwiązanie polegało na dodaniu fikcyjnego wywołania odczytu, aby zarejestrować „0” (nieokreślone) na początku procedury inicjalizacji modułu. Jeśli moduł widzi to jako dane dla nieznanego polecenia zapisu, nie wydaje się, aby wystąpiły żadne złe efekty. Jeśli uzna to za polecenie odczytu, nie dzieje się nic użytecznego. Martwi mnie, że nie mogę w pełni zdefiniować problemu, zwłaszcza że reset sprzętowy samego modułu nie rozwiązuje problemu.

Układ RC522 składa się z wielu rejestrów, z których większość jest zarówno do odczytu, jak i do zapisu. W celu wykonania zapisu do modułu wysyłany jest numer rejestru, a następnie wartość do zapisu. Aby wykonać odczyt, do numeru rejestru dodawane jest 0x80, które jest przesyłane do modułu. Odpowiedź na polecenie zapisu jest echem rejestru, do którego uzyskano dostęp. Odpowiedzią na polecenie odczytu jest zawartość rejestru. Oprogramowanie wykorzystuje tę wiedzę, aby sprawdzić, czy polecenie zostało poprawnie wykonane.

Krok 6: Sekwencja dostępu do modułu PN532

Procedura uruchamiania obejmuje te wymagane kroki:

· Wyślij ciąg inicjujący: Jest to specyficzne dla interfejsu UART. Instrukcja stwierdza, że interfejs UART obudzi się przy piątym zboczu narastającym wykrytym na interfejsie. Zaleca wysyłanie 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. W większości przypadków wystarczy wystarczająca liczba znaków z rosnącymi krawędziami i nie mogą one wyglądać jak preambuła polecenia (00 00 FF).

· Obudź moduł: Pochowany w instrukcji obsługi pokazuje, że moduł inicjuje się w rodzaj stanu uśpienia o nazwie „LowVbat”. Aby wyjść z tego stanu, musimy wysłać polecenie „SAMConfiguration”.

PN532 oczekuje, że polecenia będą wysyłane w zdefiniowanym formacie komunikatu, który zawiera preambułę, komunikat i postambułę. Komunikaty odpowiedzi mają ten sam format. Komunikaty polecenia i odpowiedzi zawierają zarówno TFI (identyfikator ramki), jak i wersję polecenia. Polecenie używa TFI 0xD4, a odpowiedź używa 0xD5. Wersje poleceń różnią się, ale odpowiedź zawsze zwiększy wersję polecenia i zwróci ją w bajcie następującym po TFI. Ta spójność umożliwia łatwe skanowanie komunikatów odpowiedzi w poszukiwaniu odpowiednich informacji.

Każdy komunikat z poleceniem (po preambule) składa się z długości komunikatu, uzupełnienia do dwóch długości komunikatu, TFI, polecenia, danych, sumy kontrolnej i postambuły. Oprogramowanie buduje poszczególne polecenia, a następnie wywołuje procedurę, która oblicza sumę kontrolną i dołącza postambułę.

Format komunikatu odpowiedzi jest podobny do formatu polecenia. Typowa odpowiedź będzie zawierać ACK (00 00 FF 00 FF 00), po której następuje określona odpowiedź na polecenie. Każda odpowiedź na polecenie zaczyna się od preambuły 00 00 FF. Odpowiedź powinna również zawierać bajt TFI równy D5, po którym następuje numer polecenia zwiększony o 1. Dla naszego polecenia „SAMConfiguration” (14) byłoby to 15. Polecenie „SAMConfiguration” otrzymuje następującą odpowiedź: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Istnieją inne polecenia specyficzne dla modułu, które można wysłać, ale nie są one potrzebne w tej aplikacji. Dołączyłem jednak procedurę, którą można wywołać, aby pobrać numer wersji oprogramowania układowego. Typowa odpowiedź (po ACK i preambule) to: 06 FA D5 03 32 01 06 07 E8 00. „01 06 07” oznacza numer wersji oprogramowania 1.6.7.

Krok 7: Sekwencja dostępu do tagów

Po przygotowaniu modułu możemy wysyłać polecenia specyficzne dla tagów. Aby odczytać lub zapisać dane tagu musimy mieć jego numer identyfikacyjny (UID). UID i klucz zostaną następnie użyte do autoryzacji określonego sektora danych znacznika do odczytu/zapisu. Odczyty/zapisy danych znaczników są zawsze wykonywane na wszystkich 16 bajtach w określonym bloku danych. Oznacza to, że typowa aplikacja odczyta blok danych, zmodyfikuje dane zgodnie z potrzebami, a następnie zapisze nowe dane z powrotem do znacznika.

Krok 8: Oprogramowanie

Oprogramowanie obsługi przerwań jest wywoływane za każdym razem, gdy PIC UART otrzymuje bajt danych. W niektórych moich poprzednich projektach UART byłem w stanie po prostu odpytywać flagę przerwania RX, zamiast korzystać z obsługi przerwań. Tak nie jest w przypadku tego oprogramowania, szczególnie w przypadku PN532, który komunikuje się ze znacznie większą szybkością transmisji niż RC522. Interfejs UART RC522 jest ograniczony do 9600 bodów, podczas gdy wartość domyślna dla PN532 to 115k i może być ustawiona na nawet 1,288 M bodów. Odebrane bajty są przechowywane w obszarze buforowym, a główna część oprogramowania pobiera je w razie potrzeby.

Flaga New_Msg wskazuje, że bajty zostały odebrane, a Byte_Count wskazuje, ile. Do oprogramowania dołączyłem procedurę „Disp_Buff”, którą można wywołać, aby wyświetlić zawartość bufora odbioru podczas debugowania. Niektóre z wiadomości zwrotnych przepełnią typowy wyświetlacz 1602, ale mam wyświetlacz LCD 40 znaków na 2 linie, który znalazłem na stronie internetowej z nadmiarem elektroniki. Definicję „Max_Line” można ustawić dla rozmiaru wyświetlacza LCD. Po osiągnięciu „Max_Line” procedura „Disp_Buff” kontynuuje zapis do drugiej linii. Mógłbyś dodać mały kod do tej procedury, aby przejść do linii trzeciej i czwartej, jeśli masz 4-wierszowy wyświetlacz LCD. Dla PN532 istnieje flaga, którą można ustawić tak, aby procedura albo zrzucała wszystkie odebrane bajty, albo po prostu zrzucała 16 bajtów danych z odpowiedzi odczytu.

Nie ma potrzeby czyszczenia bufora odbioru lub Byte_Count, ponieważ wyczyszczenie flagi New_Msg spowoduje, że Byte_Count zostanie wyczyszczony przez obsługę przerwań i to jest używane jako indeks do bufora. New_Msg zwykle jest czyszczony przed każdym krokiem polecenia, aby można było łatwo zlokalizować i zweryfikować wyniki specyficzne dla tego polecenia. W RC522 oznacza to, że bufor odbioru ma zwykle tylko 1 do 4 bajtów. W niektórych przypadkach, takich jak odczyt bloku danych, polecenie Read_FIFO musi być wydawane wiele razy, aby przenieść bajty z FIFO do bufora odbioru. Wszystkie wyniki poleceń dla PN532 trafiają do bufora odbioru, więc wykonywana jest procedura skanowania w celu zlokalizowania określonych potrzebnych bajtów.

Główna pętla w oprogramowaniu skanuje w poszukiwaniu znacznika, a następnie uwierzytelnia znacznik pod kątem odczytu/zapisu. Dla oprogramowania testowego zawartego tutaj zmienna Junk_Num jest każdorazowo modyfikowana przez pętlę główną i jest używana podczas zapisu do tagu. Wartości zapisane naprzemiennie między wartością Junk_Num i uzupełnieniem do jedynki Junk_Num. Na koniec 16 zapisanych wartości jest odczytywanych i wyświetlanych. Dla każdego kroku są wyświetlane komunikaty z rutynowymi wywołaniami opóźnienia, aby dać czas na przeczytanie każdej wiadomości. Wyświetlane są również komunikaty o błędach, ale zwykle powinny pojawić się tylko wtedy, gdy znacznik zostanie usunięty podczas operacji.

Częścią inicjalizacji oprogramowania jest sekcja kodu, która jest wykonywana tylko po włączeniu zasilania i jest pomijana w przypadku wykrycia resetu oprogramowania. Komunikaty o błędach zazwyczaj kończą się resetowaniem oprogramowania, co jest sposobem na wyjście z głównej pętli. Resetowanie odbywa się w procedurze „Tilt”, która po prostu włącza Watchdog Timer, a następnie przechodzi w nieskończoną pętlę, czekając na limit czasu.

Krok 9: Unikalne oprogramowanie MFRC522

Układ RC522 wymaga więcej instrukcji niskopoziomowych niż układ PN532, aby nawiązać komunikację z tagami. To trochę jak programowanie w asemblerze kontra programowanie w „C”. Inną istotną różnicą jest to, że RC522 wymaga, aby komunikacja ze znacznikiem była kierowana przez bufor FIFO. Procedury „Write_FIFO” i „Read_FIFO” obsługują te zadania. Oprogramowanie MFRC522 zawiera sekcję dla wielu poleceń niższego poziomu, z których zbudowane są główne funkcje.

Obliczanie sumy kontrolnej komendy znacznika dla RC522 jest zupełnie inne niż dla PN532. Po zbudowaniu polecenia znacznika w FIFO, wysyłane jest polecenie modułu w celu obliczenia sumy kontrolnej. Wynik 16-bitowy nie jest automatycznie dołączany do polecenia tag, ale jest dostępny do odczytu z dwóch rejestrów 8-bitowych. Obliczenie sumy kontrolnej usuwa dane w FIFO, więc wymagana sekwencja jest następująca:

· Zbuduj polecenie w FIFO

· Polecenie obliczenia sumy kontrolnej

· Zbuduj ponownie polecenie w FIFO

· Odczytaj rejestry CRC i zapisz bajty sumy kontrolnej do FIFO

· Wyślij polecenie Transceive lub Authenticate

Polecenie Transceive prześle bufor FIFO, a następnie automatycznie przełączy się w tryb odbioru, aby czekać na odpowiedź ze znacznika. Po poleceniu Transceive musi nastąpić ustawienie bitu StartSend w BitFramingRegister, aby rzeczywiście przesłać dane. Polecenie Uwierzytelnij nie ma tego wymagania.

Ogólnie rzecz biorąc, aplikacje z kodem Arduino „C” dostępne online wykorzystują rejestry flag przerwań i rejestr limitów czasu, aby zapewnić terminowe otrzymanie prawidłowej odpowiedzi. Moim zdaniem jest to przesada dla tej aplikacji, która nie ma krytycznego znaczenia. Zamiast tego używam krótkich limitów czasu oprogramowania, aby poczekać na odpowiedź, a następnie sprawdzić, czy jest poprawna. Instrukcja dotycząca tagów Mifare wyszczególnia czas dla różnych transakcji, a także czas, w którym można otrzymać oczekiwaną liczbę bajtów. Te opóźnienia czasowe są wbudowane w większość podprogramów poleceń niskiego poziomu.

Krok 10: Unikalne oprogramowanie PN532

Po zainicjowaniu modułu kroki potrzebne do znalezienia i uwierzytelnienia znacznika są wykonywane poprzez napisanie odpowiedniego polecenia, a następnie niezbędnych danych. Polecenie scan zwraca UID, który jest następnie używany do uwierzytelniania. Następnie odczytuje i zapisuje znacznik wysyła lub zwraca 16 bajtów dla zaadresowanego bloku danych.

Sekwencja inicjowania została szczegółowo opisana wcześniej, a ta sama procedura oprogramowania wysyła również polecenie SAMConfiguration, aby wyprowadzić moduł ze stanu „LowVbat”. Pozostałe podstawowe polecenia, takie jak Skanowanie, Uwierzytelnianie, Odczyt/Zapis Tagu, są budowane sekwencyjnie w odpowiednich procedurach. Suma kontrolna jest obliczana przez dodanie bajtów polecenia, wykonanie uzupełnienia, a następnie dodanie 1, aby uczynić go uzupełnieniem dwójkowym. Wynik 8-bitowy jest dołączany do ciągu poleceń tuż przed postambułą.

Nie ma FIFO jak w RC522, więc kompletne komunikaty odpowiedzi są odbierane automatycznie. Procedura „Find_Response” skanuje bufor danych odbiorczych pod kątem TFI (0xD5). Procedura wykorzystuje wiedzę, jakie powinny być oczekiwane komunikaty i ignoruje proste odpowiedzi ACK, które nie zawierają danych. Po znalezieniu TFI pożądane odpowiedzi są znanym przesunięciem względem niego. Bajty echa polecenia i stanu polecenia są zapisywane przez procedurę „Read_Buff” w celu późniejszej weryfikacji.

To tyle w tym poście. Sprawdź moje inne projekty elektroniki na: www.boomerrules.wordpress.com