Dasar-dasar RFID RC522 dan PN532: 10 Langkah

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:56

CATATAN: Saya sekarang memiliki Instructables yang menawarkan kode Arduino untuk RC522 dan PN532.

Beberapa waktu lalu saya membeli tiga modul RFID yang berbeda untuk eksperimen. Dalam proyek sebelumnya saya merinci cara menggunakan modul 125-kHz sederhana untuk melakukan fungsi keamanan dasar. Modul seperti itu menggunakan tag hanya-baca sehingga prosesnya memindai ID, menyimpan jika diinginkan, dan membandingkannya dengan ID yang disimpan. Modul lain yang saya beli beroperasi pada 13,56-MHz dan menggunakan tag yang dapat dibaca dan ditulis, jadi agak sia-sia jika hanya menggunakannya untuk keamanan dasar. Dua modul umum menggunakan chip RC522 atau chip PN532 – keduanya dibuat oleh NXP.

Jika Anda telah membaca salah satu proyek saya yang lain, Anda tahu bahwa saya suka menggunakan mikrokontroler PIC murah dan program dalam bahasa rakitan. Jadi yang saya cari adalah urutan langkah yang diperlukan untuk berbicara dengan modul dan tag RFID. Meskipun ada banyak contoh program online untuk modul, kebanyakan dari mereka ditulis dalam perangkat lunak 'C' untuk Arduino dan menggunakan antarmuka SPI. Juga, manual untuk chip dan untuk tag Mifare membutuhkan sedikit penguraian. Posting ini terutama tentang informasi yang saya harap saya miliki ketika saya memulai proyek. Saya juga menyertakan program perangkat lunak perakitan PIC untuk melakukan perintah dasar yang diperlukan oleh setiap modul. Bahkan jika Anda tidak menggunakan PIC dan/atau bahasa rakitan, kode sumber setidaknya harus memberi Anda ide bagus tentang perintah khusus yang diperlukan untuk melakukan setiap langkah.

Langkah 1: Antarmuka Serial

Kedua chip yang digunakan pada modul ini mampu berinteraksi melalui SPI, I2C, atau UART (HSSP). Modul PN532 memiliki sakelar DIP yang digunakan untuk memilih antarmuka yang diinginkan tetapi modul MFRC522 dipasang untuk antarmuka SPI. Saya lebih suka menggunakan UART built-in dari PIC, jadi saya mencari secara online untuk melihat apakah ada cara untuk memasukkan modul MFRC522 ke mode UART. Apa yang saya temukan adalah bahwa memotong satu jejak di papan akan berhasil. Pemotongan secara efektif menghilangkan 3,3 volt dari pin EA chip. Secara teknis pin EA kemudian harus dihubungkan ke ground tetapi tidak banyak orang yang dapat melakukan penyolderan tersebut mengingat kepadatan pin chip. Namun, jangan khawatir, karena pin EA tidak memiliki pull-up internal dan tidak "mengambang" seperti yang dilakukan oleh input logika TTL lama. Lihat diagram chip dan gambar bagian papan untuk tempat yang akan dipotong. Pastikan Anda hanya memotong short trace yang langsung menuju pin EA.

Langkah 2: Perangkat Keras

Koneksi perangkat keras untuk komunikasi UART ditunjukkan pada diagram di atas. Koneksi UART untuk MFRC522 tidak ditandai pada papan tetapi, seperti yang ditunjukkan pada skema, pin SDA menerima data UART dan pin MISO mengirimkan data UART. Modul PN532 memiliki tanda UART di sisi bawah papan.

Kedua modul berjalan pada tegangan 3,3 volt dan level logika 5 volt dari pin PIC TX juga perlu dibatasi. Koneksi LCD adalah pengaturan 4-bit standar yang telah digunakan di sejumlah proyek saya sebelumnya. Format default untuk semua pesan diatur untuk LCD standar 1602 (16 karakter kali 2 baris). Saya juga memiliki LCD 40 karakter dengan 2 baris yang saya gunakan untuk pembuangan data mentah selama debugging, jadi saya menyertakan definisi dalam perangkat lunak yang memungkinkan saya memanfaatkan ruang tampilan ekstra.

Langkah 3: Blok Data

Tag Mifare Classic 1k yang digunakan untuk proyek ini dikonfigurasi sebagai 16 sektor, empat blok data per sektor, 16 byte per blok data. Dari 64 blok data, hanya 47 yang benar-benar dapat digunakan. Blok data 0 berisi data pabrikan dan blok 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59, dan 63 disebut blok Trailer. Blok Trailer adalah yang terakhir di setiap sektor dan mereka berisi dua kunci dan bit akses blok. Kunci dan bit akses blok hanya berlaku untuk blok data di sektor tersebut sehingga Anda dapat memiliki kunci dan aturan akses yang berbeda untuk setiap sektor. Kunci default diatur ke "FF FF FF FF FFh". Untuk proyek dasar ini saya hanya menggunakan satu blok data dan menyimpan kunci default dan bit akses. Ada banyak dokumen yang terkait dengan kartu ini, jadi lakukan pencarian online untuk "Mifare" atau kunjungi situs web NXP jika Anda ingin menjelajahinya lebih dalam.

Langkah 4: Operasi Umum

Meskipun kedua modul unik dalam cara mereka diakses dan cara mereka mengakses tag, ada proses umum yang diperlukan untuk menyelesaikan pekerjaan. Untuk proyek ini, kami berasumsi bahwa tag adalah tipe Mifare Classic 1k dan kami hanya mengizinkan satu tag pada satu waktu di bidang antena. Langkah-langkah dasar didefinisikan di bawah ini.

· Inisialisasi modul: Secara umum ini memerlukan hal-hal seperti menulis nilai ke register di chip, mengirim perintah "bangun", dan menyalakan antena. Dalam aplikasi yang dioperasikan dengan baterai, Anda ingin dapat menghidupkan dan mematikan antena untuk menghemat baterai, tetapi untuk aplikasi sederhana ini kami menyalakannya sekali dan kemudian membiarkannya menyala.

· Hapus tanda kripto (hanya 522): Ketika sebuah tag diautentikasi, sebuah tanda akan diatur untuk memberi tahu pengguna bahwa komunikasi dengan tag akan dienkripsi. Tanda ini perlu dihapus oleh pengguna sebelum pemindaian berikutnya, meskipun tag yang dipindai adalah sama.

· Pindai sebuah tag: Modul pada dasarnya menanyakan “Apakah ada orang di luar sana?” dan tag merespons "Saya di sini". Jika modul tidak mendapatkan respons cepat, modul akan berhenti mendengarkan. Itu berarti kita perlu mengirim perintah scan berulang kali ke modul sampai menemukan tag.

· Dapatkan tag Nomor Identifikasi Pengguna (UID): Tag akan menanggapi permintaan pemindaian dengan beberapa informasi terbatas seperti jenis tag itu. Itu berarti kita mungkin perlu mengirim perintah lain untuk mendapatkan UID-nya. UID adalah empat byte untuk tag Mifare Classic 1k. Jika mungkin lebih lama untuk tag lain tetapi proyek ini tidak mengatasinya.

· Pilih tag (522 saja): UID digunakan untuk memilih tag yang ingin diautentikasi pengguna untuk membaca dan menulis. Hal ini didasarkan pada kemungkinan bahwa mungkin ada lebih dari satu tag di bidang antena. Itu tidak berlaku untuk aplikasi sederhana kita tetapi kita tetap harus memilih tag.

· Otentikasi tag: Langkah ini diperlukan jika kita ingin melakukan pembacaan atau penulisan tag. Jika semua yang ingin kita lakukan adalah membedakan antara tag untuk aplikasi keamanan sederhana maka UID sudah cukup. Otentikasi mengharuskan kita mengetahui UID dan bahwa kita mengetahui kunci kripto untuk sektor data dari tag yang ingin kita akses. Untuk proyek ini kami tetap menggunakan kunci default tetapi proyek lanjutan saya mengubah kunci sehingga tag dapat digunakan sebagai dompet elektronik.

· Membaca atau menulis tag: Membaca selalu mengembalikan semua 16 byte dari Blok Data yang diminta. Penulisan mengharuskan semua 16 byte ditulis secara bersamaan. Jika Anda ingin membaca atau menulis blok lain di sektor data yang sama, tag tidak perlu diautentikasi lagi. Jika Anda ingin membaca atau menulis blok di sektor data yang berbeda, maka tag perlu diautentikasi lagi menggunakan kunci untuk sektor tersebut.

Langkah 5: Urutan Akses Modul MFRC522

Rutinitas startup mencakup langkah-langkah dasar yang ditemukan di sebagian besar aplikasi yang saya lihat:

· Kirim byte data dummy (lihat paragraf berikutnya)

· Atur ulang lunak

· Atur penguatan penerima RF (jika yang diinginkan selain standar)

· Atur persentase modulasi ASK menjadi 100%

· Tetapkan nilai benih untuk perhitungan CRC

· Nyalakan antena

· Dapatkan versi firmware (tidak diperlukan)

Untuk beberapa alasan yang tidak dapat dijelaskan modul saya menyala dan berpikir bahwa ia telah menerima perintah tulis tanpa byte data. Saya tidak tahu apakah ini hanya masalah dengan modul saya, tetapi saya belum melihat referensi apa pun untuk itu di tempat lain. Saya bereksperimen dengan pengaturan ulang perangkat keras dan perangkat lunak dan tidak ada yang memperbaiki masalah. Solusi saya adalah menambahkan panggilan baca dummy untuk mendaftarkan "0" (tidak terdefinisi) di awal rutinitas inisialisasi modul. Jika modul melihat ini sebagai data untuk perintah tulis yang tidak diketahui, tampaknya tidak ada efek buruk. Jika melihatnya sebagai perintah baca, maka tidak ada yang berguna terjadi. Ini mengganggu saya bahwa saya tidak dapat sepenuhnya mendefinisikan masalah, terutama mengingat bahwa pengaturan ulang perangkat keras hanya pada modul tidak memperbaiki masalah.

Chip RC522 terdiri dari sejumlah register, yang sebagian besar membaca dan menulis. Untuk melakukan penulisan, nomor register dikirim ke modul diikuti dengan nilai untuk ditulis. Untuk melakukan pembacaan, nomor register ditambahkan 0x80 dan dikirim ke modul. Respons terhadap perintah tulis adalah gema dari register yang diakses. Respon terhadap perintah read adalah isi dari register. Perangkat lunak memanfaatkan pengetahuan itu untuk memverifikasi bahwa perintah telah dijalankan dengan benar.

Langkah 6: Urutan Akses Modul PN532

Rutinitas startup mencakup langkah-langkah yang diperlukan ini:

· Kirim string inisialisasi: Ini khusus untuk antarmuka UART. Manual menyatakan bahwa antarmuka UART akan bangun pada tepi naik kelima yang terdeteksi pada antarmuka. Ini merekomendasikan pengiriman 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Untuk sebagian besar, hanya perlu ada jumlah karakter yang cukup dengan tepi naik dan mereka tidak boleh terlihat seperti pembukaan perintah (00 00 FF).

· Bangunkan modul: Terkubur dalam panduan pengguna, ini menunjukkan bahwa modul diinisialisasi menjadi semacam keadaan tidur yang disebut "LowVbat". Untuk keluar dari status ini, kita perlu mengirim perintah "SAMConfiguration".

PN532 mengharapkan perintah untuk dikirim dalam format pesan yang ditentukan yang mencakup pembukaan, pesan, dan postamble. Pesan tanggapan mengikuti format yang sama. Pesan perintah dan tanggapan keduanya menyertakan TFI (Frame Identifier) dan versi perintah. Perintah menggunakan TFI 0xD4 dan responsnya menggunakan 0xD5. Versi perintah bervariasi tetapi responsnya akan selalu menambah versi perintah dan mengembalikannya dalam byte setelah TFI. Konsistensi itu memungkinkan pesan respons dipindai dengan mudah untuk mendapatkan informasi yang relevan.

Setiap pesan perintah (mengikuti pembukaan) terdiri dari panjang pesan, pelengkap 2 dari panjang pesan, TFI, perintah, data, checksum, dan postamble. Perangkat lunak membangun perintah individu dan kemudian memanggil rutin yang menghitung checksum dan menambahkan postamble.

Format pesan untuk respons mirip dengan perintah. Respons tipikal akan mencakup ACK (00 00 FF 00 FF 00) diikuti oleh respons spesifik terhadap perintah. Setiap respons perintah dimulai dengan pembukaan 00 00 FF. Responsnya juga harus memiliki byte TFI D5 diikuti dengan nomor perintah yang ditambah dengan 1. Untuk perintah "SAMConfiguration" kami (14) yang akan menjadi 15. Perintah "SAMConfiguration" mendapatkan respons ini: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Ada perintah khusus modul lain yang dapat dikirim tetapi tidak diperlukan untuk aplikasi ini. Namun, saya menyertakan rutin yang dapat dipanggil untuk mengambil nomor versi firmware. Respons tipikal (setelah ACK dan pembukaan) adalah: 06 FA D5 03 32 01 06 07 E8 00. "01 06 07" menunjukkan nomor versi firmware 1.6.7.

Langkah 7: Urutan Akses Tag

Setelah modul siap, kami dapat mengirim perintah khusus untuk tag. Untuk membaca atau menulis data tag, kita perlu memiliki nomor identifikasi (UID). UID dan kunci kemudian akan digunakan untuk mengotorisasi sektor data tag tertentu untuk membaca/menulis. Pembacaan/penulisan data tag selalu dilakukan pada semua 16 byte dalam blok data yang ditentukan. Itu berarti bahwa aplikasi tipikal akan membaca blok data, memodifikasi data sesuai keinginan, dan kemudian menulis data baru kembali ke tag.

Langkah 8: Perangkat Lunak

Perangkat lunak penangan interupsi dipanggil setiap kali PIC UART menerima satu byte data. Dalam beberapa proyek UART saya sebelumnya, saya hanya dapat melakukan polling pada flag interupsi RX daripada harus menggunakan penangan interupsi. Itu tidak terjadi untuk perangkat lunak ini, terutama untuk PN532 yang berkomunikasi pada baud rate yang jauh lebih tinggi daripada RC522. Antarmuka UART RC522 dibatasi hingga 9600 baud sedangkan default untuk PN532 adalah 115k dan dapat diatur hingga 1,288M baud. Byte yang diterima disimpan di area buffer dan bagian utama dari perangkat lunak mengambilnya sesuai kebutuhan.

Bendera New_Msg menunjukkan bahwa byte telah diterima dan Byte_Count menunjukkan berapa banyak. Saya telah menyertakan rutin "Disp_Buff" dalam perangkat lunak yang dapat dipanggil untuk menampilkan konten buffer penerima selama debugging. Beberapa pesan kembali akan meluap tampilan 1602 khas tapi saya memiliki 40 karakter dengan LCD 2 baris yang saya temukan di situs elektronik surplus online. Definisi “Max_Line” dapat diatur untuk ukuran LCD Anda. Jika “Max_Line” tercapai, rutinitas “Disp_Buff” dilanjutkan dengan menulis ke baris kedua. Anda dapat menambahkan sedikit kode ke rutinitas itu untuk melanjutkan ke baris tiga dan empat jika Anda memiliki LCD 4-baris. Untuk PN532 ada tanda yang dapat diatur sehingga rutin membuang semua byte yang diterima atau hanya membuang 16 byte data dari respons baca.

Tidak perlu menghapus buffer penerima atau Byte_Count karena menghapus flag New_Msg akan menyebabkan Byte_Count dihapus oleh pengendali interupsi dan itulah yang digunakan sebagai indeks ke dalam buffer. New_Msg biasanya dibersihkan sebelum setiap langkah perintah sehingga hasil khusus untuk perintah itu dapat dengan mudah ditemukan dan diverifikasi. Dalam RC522 itu berarti bahwa buffer penerima biasanya hanya memiliki 1 hingga 4 byte. Dalam beberapa kasus, seperti pembacaan blok data, perintah Read_FIFO harus dikeluarkan beberapa kali untuk memindahkan byte dari FIFO ke buffer penerima. Semua hasil perintah untuk PN532 berakhir di buffer penerima sehingga prosedur pemindaian dilakukan untuk menemukan byte tertentu yang diperlukan.

Loop utama dalam perangkat lunak memindai tag dan kemudian mengotentikasi tag untuk membaca/menulis. Untuk perangkat lunak uji yang disertakan di sini, variabel Junk_Num dimodifikasi setiap kali melalui loop utama dan digunakan selama penulisan ke tag. Nilai yang ditulis bergantian antara nilai Junk_Num dan komplemen 1 dari Junk_Num. Akhirnya, 16 nilai tertulis dibaca dan ditampilkan. Ada pesan tampilan untuk setiap langkah dengan penundaan panggilan rutin untuk memberikan waktu untuk membaca setiap pesan. Pesan kesalahan juga disediakan tetapi biasanya hanya terjadi jika tag dilepas selama operasi.

Bagian dari inisialisasi perangkat lunak adalah bagian kode yang hanya dijalankan saat dihidupkan dan dilewati jika penyetelan ulang perangkat lunak terdeteksi. Pesan kesalahan umumnya diakhiri dengan reset perangkat lunak sebagai cara untuk keluar dari loop utama. Reset terjadi dalam rutinitas "Tilt" yang hanya mengaktifkan Watchdog Timer dan kemudian masuk ke loop tak terbatas menunggu batas waktu.

Langkah 9: Perangkat Lunak Unik MFRC522

Chip RC522 membutuhkan lebih banyak instruksi tingkat rendah daripada chip PN532 untuk menyelesaikan komunikasi dengan tag. Ini seperti pemrograman dalam bahasa assembly versus pemrograman dalam "C". Perbedaan signifikan lainnya adalah bahwa RC522 mengharuskan komunikasi dengan tag disalurkan melalui buffer FIFO. Rutinitas “Write_FIFO” dan “Read_FIFO” menangani tugas-tugas tersebut. Perangkat lunak MFRC522 mencakup bagian untuk banyak perintah tingkat rendah dari mana fungsi utama dibangun.

Perhitungan checksum perintah tag untuk RC522 sangat berbeda dengan PN532. Setelah perintah tag dibangun di FIFO, perintah modul dikirim untuk menghitung checksum. Hasil 16-bit tidak secara otomatis ditambahkan ke perintah tag tetapi tersedia untuk dibaca dari dua register 8-bit. Perhitungan checksum menghapus data di FIFO sehingga urutan yang diperlukan adalah sebagai berikut:

· Bangun perintah di FIFO

· Perintahkan perhitungan checksum

· Bangun perintah di FIFO lagi

· Baca register CRC dan tulis byte checksum ke FIFO

· Kirim perintah Transceive atau Otentikasi

Perintah Transceive akan mengirimkan buffer FIFO dan kemudian secara otomatis beralih ke mode terima untuk menunggu respons dari tag. Perintah Transceive harus diikuti dengan pengaturan bit StartSend di BitFramingRegister untuk benar-benar mengirimkan data. Perintah Otentikasi tidak memiliki persyaratan itu.

Secara umum, aplikasi kode “C” Arduino yang tersedia online menggunakan register flag interupsi dan register batas waktu untuk memastikan bahwa respons yang benar diterima secara tepat waktu. Menurut pendapat saya itu berlebihan untuk aplikasi kritis non-waktu ini. Sebagai gantinya, saya menggunakan batas waktu perangkat lunak singkat untuk menunggu respons dan kemudian memverifikasi bahwa itu benar. Manual untuk tag Mifare merinci waktu untuk berbagai transaksi dan waktu juga diperbolehkan untuk jumlah byte yang diharapkan akan diterima. Penundaan waktu ini dibangun di sebagian besar subrutin perintah tingkat rendah.

Langkah 10: Perangkat Lunak Unik PN532

Setelah modul diinisialisasi, langkah-langkah yang diperlukan untuk menemukan dan mengotentikasi tag dilakukan dengan menulis perintah yang sesuai diikuti dengan data yang diperlukan. Perintah scan mengembalikan UID yang kemudian digunakan untuk otentikasi. Setelah itu, membaca dan menulis tag mengirim atau mengembalikan 16-byte untuk blok data yang dialamatkan.

Urutan inisialisasi telah dirinci sebelumnya dan rutinitas perangkat lunak yang sama juga mengirimkan perintah SAMConfiguration untuk mengeluarkan modul dari status "LowVbat". Perintah dasar lainnya, seperti Scan, Authenticate, Read/Write Tag, hanya dibangun secara berurutan dalam rutinitas yang berlaku. Checksum dihitung dengan hanya menambahkan byte perintah, melakukan pelengkap, dan kemudian menambahkan 1 untuk menjadikannya pelengkap 2. Hasil 8-bit ditambahkan ke string perintah tepat sebelum postamble.

Tidak ada FIFO seperti di RC522 sehingga pesan respons lengkap diterima secara otomatis. Rutin "Find_Response" memindai buffer data yang diterima untuk TFI (0xD5). Rutinitas memanfaatkan mengetahui apa pesan yang diharapkan dan mengabaikan respons ACK sederhana yang tidak menyertakan data. Setelah TFI ditemukan, respons yang diinginkan adalah offset yang diketahui darinya. Perintah echo dan byte status perintah disimpan oleh rutin "Read_Buff" untuk verifikasi nanti.

Itu saja untuk posting ini. Lihat proyek elektronik saya yang lain di: www.boomerrules.wordpress.com