Asas RFID RC522 dan PN532: 10 Langkah

2024 Pengarang: John Day | [email protected]. Diubah suai terakhir: 2024-01-30 11:09

CATATAN: Saya sekarang mempunyai Instructables yang menawarkan kod Arduino untuk RC522 dan PN532.

Beberapa waktu yang lalu saya membeli tiga modul RFID yang berbeza untuk bereksperimen. Dalam projek sebelumnya saya terperinci bagaimana menggunakan modul 125-kHz yang sederhana untuk melakukan fungsi keselamatan asas. Modul seperti itu menggunakan tag baca sahaja sehingga prosesnya mengimbas ID, menyimpan jika dikehendaki, dan membandingkan dengan ID yang disimpan. Modul-modul lain yang saya beli beroperasi pada 13.56-MHz dan menggunakan teg yang boleh dibaca dan ditulis sehingga menjadi pembaziran jika hanya menggunakannya untuk keselamatan asas. Kedua-dua modul yang sama menggunakan cip RC522 atau cip PN532 - kedua-duanya dibuat oleh NXP.

Sekiranya anda membaca mana-mana projek saya yang lain, anda tahu bahawa saya suka menggunakan mikrokontroler dan program PIC yang murah dalam bahasa pemasangan. Jadi apa yang saya cari adalah urutan langkah yang diperlukan untuk bercakap dengan modul dan tag RFID. Walaupun terdapat banyak contoh program dalam talian untuk modul, kebanyakannya ditulis dalam perisian ‘C’ untuk Arduino dan menggunakan antara muka SPI. Juga, manual untuk kerepek dan tag Mifare memerlukan sedikit penguraian. Catatan ini adalah terutamanya mengenai maklumat yang saya mahukan semasa saya memulakan projek ini. Saya juga menyertakan program perisian pemasangan PIC untuk melaksanakan perintah asas yang diperlukan oleh setiap modul. Walaupun anda tidak menggunakan PIC dan / atau bahasa perhimpunan, kod sumber sekurang-kurangnya harus memberi anda idea yang baik mengenai perintah khusus yang diperlukan untuk melakukan setiap langkah.

Langkah 1: Antara muka bersiri

Kedua-dua cip yang digunakan pada modul ini mampu berinteraksi melalui SPI, I2C, atau UART (HSSP). Modul PN532 mempunyai suis DIP yang digunakan untuk memilih antara muka yang diinginkan tetapi modul MFRC522 adalah kabel untuk antarmuka SPI. Saya lebih suka menggunakan UART bawaan PIC, jadi saya memburu dalam talian untuk melihat apakah ada cara untuk memasukkan modul MFRC522 ke mod UART. Apa yang saya dapati ialah memotong satu jejak di papan akan berjaya. Potongan dengan berkesan mengeluarkan 3.3 volt dari pin cip EA. Secara teknikal pin EA kemudiannya harus disambungkan ke tanah tetapi tidak banyak orang dapat melakukan pematerian itu kerana ketumpatan pin cip. Tidak perlu risau, kerana pin EA tidak mempunyai penarikan dalaman dan tidak "terapung" seperti input logik TTL lama. Rujuk gambarajah cip dan gambar bahagian papan untuk tempat yang hendak dipotong. Pastikan anda hanya memotong jejak pendek terus ke pin EA.

Langkah 2: Perkakasan

Sambungan perkakasan untuk komunikasi UART ditunjukkan dalam rajah di atas. Sambungan UART untuk MFRC522 tidak ditandakan di papan tetapi, seperti yang ditunjukkan dalam skema, pin SDA menerima data UART dan pin MISO menghantar data UART. Modul PN532 mempunyai tanda UART di bahagian bawah papan.

Kedua-dua modul berjalan pada 3.3 volt dan tahap logik 5 volt dari pin PIC TX juga perlu dihadkan. Sambungan LCD adalah persediaan 4-bit standard yang telah digunakan dalam beberapa projek saya sebelumnya. Format lalai untuk semua mesej ditetapkan untuk LCD 1602 standard (16 aksara dengan 2 baris). Saya juga mempunyai LCD 40 watak dengan 2 baris yang saya gunakan untuk pembuangan data mentah semasa melakukan debug, jadi saya memasukkan definisi dalam perisian yang membolehkan saya memanfaatkan ruang paparan tambahan.

Langkah 3: Sekatan Data

Tag Mifare Classic 1k yang digunakan untuk projek ini dikonfigurasikan sebagai 16 sektor, empat blok data per sektor, 16 bait per blok data. Dari 64 blok data, hanya 47 yang sebenarnya boleh digunakan. Blok data 0 mengandungi data pengeluar 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 ia mengandungi dua kunci dan bit akses blok. Kekunci dan bit akses blok hanya berlaku untuk blok data di sektor tersebut sehingga anda mungkin mempunyai kunci dan peraturan akses yang berbeza untuk setiap sektor. Kekunci lalai ditetapkan ke "FF FF FF FF FFh". Untuk projek asas ini, saya hanya menggunakan satu blok data dan menyimpan kunci lalai dan bit akses. Terdapat banyak dokumen yang berkaitan dengan kad ini, jadi lakukan carian dalam talian untuk "Mifare" atau lawati laman web NXP jika anda ingin menerokainya dengan lebih mendalam.

Langkah 4: Operasi Umum

Walaupun kedua modul unik dalam cara mereka diakses dan cara mereka mengakses tag, ada proses umum yang diperlukan untuk menyelesaikan pekerjaan. Untuk projek ini, kami menganggap bahawa tag adalah jenis Mifare Classic 1k dan kami hanya membenarkan satu teg pada satu masa di medan antena. Langkah-langkah asas dinyatakan di bawah.

· Memulakan modul: Secara umum ini memerlukan hal-hal seperti menulis nilai untuk mendaftar dalam cip, mengirim perintah "bangun", dan menyalakan daya ke antena. Dalam aplikasi yang dikendalikan bateri, anda ingin menghidupkan dan mematikan kuasa antena untuk menjimatkan bateri tetapi untuk aplikasi mudah ini, kami menghidupkannya sekali dan kemudian membiarkannya hidup.

· Kosongkan bendera kripto (522 saja): Ketika tag disahkan, bendera akan ditetapkan untuk memberi tahu pengguna bahawa komunikasi dengan tag akan dienkripsi. Bendera ini perlu dikosongkan oleh pengguna sebelum imbasan berikutnya, walaupun teg yang dipindai adalah sama.

· Imbas tag: Modul pada dasarnya bertanya "Adakah orang di luar sana?" dan tanda itu menjawab "Saya di sini". Sekiranya modul tidak mendapat respons pantas, ia berhenti mendengar. Itu bermaksud bahawa kita perlu berulang kali menghantar arahan imbasan ke modul sehingga ia menemui tag.

· Dapatkan tag Nombor Pengenalan Pengguna (UID): Tag akan bertindak balas terhadap permintaan imbasan dengan beberapa maklumat terhad seperti jenis tag itu. Ini bermaksud bahawa kita mungkin perlu menghantar arahan lain untuk mendapatkan UID-nya. UID adalah empat bait untuk tag Mifare Classic 1k. Sekiranya mungkin lebih lama untuk tag lain tetapi projek ini tidak menanganinya.

· Pilih tag (522 sahaja): UID digunakan untuk memilih tag yang ingin disahkan oleh pengguna untuk membaca dan menulis. Ini didasarkan pada kemungkinan ada lebih dari satu tag di medan antena. Itu bukan masalah untuk aplikasi mudah kami tetapi kami tetap perlu memilih tag.

· Autentikasi tag: Langkah ini diperlukan jika kita ingin membaca atau menulis tag. Sekiranya semua yang ingin kita lakukan adalah membezakan antara tag untuk aplikasi keselamatan yang sederhana, maka UID sudah mencukupi. Pengesahan memerlukan kita mengetahui UID dan kita mengetahui kunci crypto untuk sektor data tag yang ingin kita akses. Untuk projek ini, kami tetap menggunakan kunci lalai tetapi projek susulan saya menukar kunci sehingga tag dapat digunakan sebagai dompet elektronik.

· Baca atau tulis teg: Bacaan selalu mengembalikan semua 16 bait dari Blok Data yang diminta. Menulis memerlukan semua 16 bait ditulis pada masa yang sama. Sekiranya anda ingin membaca atau menulis blok lain di sektor data yang sama, tag tidak perlu disahkan lagi. Sekiranya anda ingin membaca atau menulis blok di sektor data yang berbeza, teg tersebut perlu disahkan semula menggunakan kunci untuk sektor tersebut.

Langkah 5: Urutan Akses Modul MFRC522

Rutin permulaan merangkumi langkah-langkah asas yang terdapat dalam kebanyakan aplikasi yang saya lihat:

· Kirim bait data palsu (lihat perenggan berikutnya)

· Tetapan semula lembut

· Tetapkan keuntungan penerima RF (jika sesuatu yang selain daripada lalai diinginkan)

· Tetapkan peratusan modulasi ASK kepada 100%

· Tetapkan nilai benih untuk pengiraan CRC

· Hidupkan antena

· Dapatkan versi firmware (tidak diperlukan)

Atas sebab tertentu modul saya tidak dapat dijelaskan dan berpendapat bahawa ia telah menerima perintah menulis tanpa bait data. Saya tidak tahu adakah ini hanya masalah dengan modul saya tetapi saya tidak melihat rujukannya di tempat lain. Saya bereksperimen dengan tetapan semula perkakasan dan perisian dan tidak menyelesaikan masalah. Penyelesaian saya adalah dengan menambahkan panggilan baca dummy untuk mendaftar "0" (tidak ditentukan) pada permulaan rutin permulaan modul. Sekiranya modul melihat ini sebagai data untuk perintah tulis yang tidak diketahui, nampaknya tidak ada kesan buruk. Sekiranya ia melihatnya sebagai perintah baca, maka tidak ada yang berguna berlaku. Ini mengganggu saya bahawa saya tidak dapat menentukan sepenuhnya masalahnya, terutamanya memandangkan tetapan semula perkakasan hanya modul tidak menyelesaikan masalah.

Cip RC522 terdiri daripada sejumlah daftar, yang kebanyakannya dibaca dan ditulis. Untuk melakukan penulisan, nombor daftar dihantar ke modul diikuti dengan nilai untuk menulis. Untuk melakukan pembacaan, nombor daftar telah ditambahkan 0x80 padanya dan dihantar ke modul. Respons terhadap perintah tulis adalah gema dari daftar yang diakses. Respons terhadap arahan baca adalah kandungan daftar. Perisian memanfaatkan pengetahuan itu untuk mengesahkan bahawa perintah itu dilaksanakan dengan betul.

Langkah 6: Urutan Akses Modul PN532

Rutin permulaan merangkumi langkah-langkah yang diperlukan berikut:

· Kirim rentetan inisialisasi: Ini khusus untuk antara muka UART. Manual tersebut menyatakan bahawa antara muka UART akan bangun pada tepi kenaikan kelima yang dikesan pada antara muka. Ia mengesyorkan menghantar 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Sebilangan besar, hanya perlu ada sebilangan watak yang cukup tinggi dan mereka tidak boleh kelihatan seperti mukadimah perintah (00 00 FF).

· Bangunkan modul: Dikuburkan di dalam manual pengguna menunjukkan bahawa modul itu dimulakan menjadi semacam keadaan tidur yang disebut "LowVbat". Untuk keluar dari keadaan ini, kita harus mengirimkan perintah "SAMConfiguration".

PN532 mengharapkan perintah dikirim dalam format pesan yang ditentukan yang meliputi mukadimah, pesan, dan postamble. Mesej respons mengikut format yang sama. Kedua-dua pesanan dan mesej respons termasuk TFI (Frame Identifier) dan versi perintah. Perintah menggunakan TFI 0xD4 dan tindak balas menggunakan 0xD5. Versi perintah berbeza-beza tetapi respons akan selalu meningkatkan versi perintah dan mengembalikannya dalam bait mengikuti TFI. Ketekalan itu membolehkan mesej respons mudah diimbas untuk mendapatkan maklumat yang berkaitan.

Setiap mesej arahan (mengikuti mukadimah) terdiri dari panjang pesan, 2 pelengkap panjang mesej, TFI, perintah, data, checksum, dan postamble. Perisian membina perintah individu dan kemudian memanggil rutin yang mengira checksum dan menambahkan postamble.

Format mesej untuk respons serupa dengan arahan. Respons khas akan merangkumi ACK (00 00 FF 00 FF 00) diikuti dengan tindak balas khusus terhadap perintah. Setiap tindak balas arahan dimulakan dengan mukadimah 00 00 FF. Respons juga harus mempunyai bait TFI D5 diikuti dengan nomor perintah yang ditambahkan oleh 1. Untuk perintah "SAMConfiguration" kami (14) yang akan menjadi 15. Perintah "SAMConfiguration" mendapat respons ini: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Terdapat arahan khusus modul lain yang dapat dikirim tetapi tidak diperlukan untuk aplikasi ini. Namun, saya memasukkan rutin yang dapat dipanggil untuk mendapatkan nombor versi firmware. Respons biasa (selepas ACK dan mukadimah) adalah: 06 FA D5 03 32 01 06 07 E8 00. "01 06 07" menunjukkan nombor versi firmware 1.6.7.

Langkah 7: Urutan Akses Tag

Setelah modul siap, kita dapat menghantar perintah khusus untuk tag. Untuk membaca atau menulis data tag, kita perlu mempunyai nombor pengenalannya (UID). UID dan kunci kemudian akan digunakan untuk mengizinkan sektor data tag tertentu untuk membaca / menulis. Tag / pembacaan data tag selalu dilakukan pada semua 16 bait dalam blok data yang ditentukan. Ini bermaksud bahawa aplikasi khas akan membaca blok data, mengubah data seperti yang diinginkan, dan kemudian menulis kembali data baru ke tag.

Langkah 8: Perisian

Perisian pengendali interupsi dipanggil setiap kali PIC UART menerima bait data. Dalam beberapa projek UART saya sebelum ini, saya hanya dapat memilih bendera gangguan RX dan bukannya menggunakan pengendali interrupt. Itu tidak berlaku untuk perisian ini, terutamanya untuk PN532 yang berkomunikasi pada kadar baud yang jauh lebih tinggi daripada RC522. Antara muka UART dari RC522 terhad kepada 9600 baud sementara lalai untuk PN532 adalah 115k dan boleh ditetapkan setinggi 1.288M baud. Bait yang diterima disimpan di kawasan penyangga dan bahagian utama perisian mengambilnya mengikut keperluan.

Bendera New_Msg menunjukkan bahawa bait telah diterima dan Byte_Count menunjukkan berapa banyak. Saya telah memasukkan rutin “Disp_Buff” dalam perisian yang dapat dipanggil untuk menampilkan isi buffer penerimaan semasa melakukan debug. Sebilangan mesej balik akan melimpah paparan 1602 biasa tetapi saya mempunyai LCD 40 watak dengan 2 baris yang saya dapati di laman elektronik lebihan dalam talian. Definisi "Max_Line" dapat diatur untuk ukuran LCD anda. Sekiranya "Max_Line" tercapai, rutin "Disp_Buff" dilanjutkan dengan menulis ke baris kedua. Anda boleh menambahkan sedikit kod pada rutin itu untuk terus ke baris tiga dan empat jika anda mempunyai LCD 4 baris. Untuk PN532 ada bendera yang dapat ditetapkan supaya rutin membuang semua bait yang diterima atau hanya membuang 16 bait data dari respons yang dibaca.

Tidak perlu membersihkan buffer penerimaan atau Byte_Count kerana membersihkan bendera New_Msg akan menyebabkan Byte_Count dibersihkan oleh pengendali gangguan dan itulah yang digunakan sebagai indeks ke dalam penyangga. New_Msg biasanya dibersihkan sebelum setiap langkah arahan supaya hasil yang khusus untuk perintah itu dapat dengan mudah dijumpai dan disahkan. Dalam RC522 itu bermaksud bahawa buffer penerimaan biasanya hanya mempunyai 1 hingga 4 bait. Dalam beberapa kes, seperti pembacaan blok data, perintah Read_FIFO mesti dikeluarkan berkali-kali untuk memindahkan bait dari FIFO ke buffer penerimaan. Semua hasil perintah untuk PN532 berakhir dalam buffer penerimaan sehingga prosedur imbasan dilakukan untuk mencari bait tertentu yang diperlukan.

Gelung utama dalam perisian mengimbas tag dan kemudian mengesahkan teg untuk membaca / menulis. Untuk perisian ujian yang disertakan di sini pemboleh ubah Junk_Num diubah setiap kali melalui gelung utama dan digunakan semasa menulis ke tag. Nilai yang ditulis bergantian antara nilai Junk_Num dan pelengkap Junk_Num 1. Akhirnya, 16 nilai bertulis dibaca dan dipaparkan. Terdapat mesej paparan untuk setiap langkah dengan menunda panggilan rutin untuk memberi masa untuk membaca setiap mesej. Mesej ralat juga diberikan tetapi biasanya hanya berlaku jika tag dikeluarkan semasa operasi.

Sebahagian dari inisialisasi perisian adalah bahagian kod yang hanya dijalankan ketika power up dan dilewati jika reset perisian dikesan. Mesej ralat biasanya berakhir dengan tetapan semula perisian sebagai cara untuk keluar dari gelung utama. Penyetelan semula berlaku dalam rutin "Tilt" yang hanya membolehkan Timer Pengawas dan kemudian memasuki gelung tanpa batas menunggu masa tamat.

Langkah 9: Perisian Unik MFRC522

Cip RC522 memerlukan lebih banyak arahan tahap rendah daripada cip PN532 untuk mencapai komunikasi dengan tag. Ini seperti pengaturcaraan dalam bahasa pemasangan berbanding pengaturcaraan di "C". Perbezaan lain yang ketara ialah RC522 menghendaki komunikasi dengan tag disalurkan melalui penyangga FIFO. Rutin "Write_FIFO" dan "Read_FIFO" menangani tugas-tugas tersebut. Perisian MFRC522 merangkumi bahagian untuk banyak perintah tingkat bawah dari mana fungsi utama dibina.

Pengiraan checksum arahan tag untuk RC522 sangat berbeza daripada PN532. Setelah arahan tag dibina di FIFO, arahan modul dihantar untuk mengira checksum. Hasil 16-bit tidak ditambahkan secara automatik pada perintah tag tetapi tersedia untuk dibaca dari dua daftar 8-bit. Pengiraan checksum menghapuskan data dalam FIFO sehingga urutan yang diperlukan adalah seperti berikut:

· Bangun perintah di FIFO

· Perintahkan pengiraan checksum

· Bina perintah di FIFO sekali lagi

· Baca daftar CRC dan tulis bait checksum kepada FIFO

· Kirim arahan Transceive atau Authenticate

Perintah Transceive akan menghantar buffer FIFO dan kemudian secara automatik beralih ke mod penerimaan untuk menunggu tindak balas dari tag. Perintah Transceive mesti diikuti dengan pengaturan bit StartSend di BitFramingRegister untuk benar-benar mengirimkan data. Perintah Authenticate tidak mempunyai syarat tersebut.

Secara umum, aplikasi kod Arduino "C" yang tersedia dalam talian menggunakan register bendera interrupt dan daftar timeout untuk memastikan bahawa respons yang betul diterima tepat pada masanya. Pada pendapat saya yang berlebihan untuk aplikasi kritikal bukan masa ini. Sebagai gantinya, saya menggunakan masa tamat perisian yang singkat untuk menunggu tindak balas dan kemudian mengesahkan bahawa ia betul. Manual untuk tag Mifare memperincikan masa untuk pelbagai transaksi dan masa juga dibenarkan untuk jumlah bait yang diharapkan akan diterima. Kelewatan masa ini dimasukkan ke dalam kebanyakan subrutin arahan peringkat rendah.

Langkah 10: Perisian Unik PN532

Setelah modul diinisialisasi, langkah-langkah yang diperlukan untuk mencari dan mengesahkan tag dicapai dengan menulis perintah yang sesuai diikuti dengan data yang diperlukan. Perintah imbasan mengembalikan UID yang kemudian digunakan untuk pengesahan. Selepas itu, membaca dan menulis tag menghantar atau mengembalikan 16-bait untuk blok data yang dialamatkan.

Urutan menginisialisasi diperinci lebih awal dan rutin perisian yang sama juga mengirimkan perintah SAMConfiguration untuk mengeluarkan modul dari keadaan "LowVbat". Perintah asas selebihnya, seperti Scan, Authenticate, Read / Write Tag, hanya dibina secara berurutan dalam rutin yang berlaku. Checksum dikira dengan hanya menambahkan bait perintah, melakukan pelengkap, dan kemudian menambahkan 1 untuk menjadikannya pelengkap 2. Hasil 8-bit ditambahkan pada rentetan perintah sebelum postamble.

Tidak ada FIFO seperti di RC522 sehingga mesej respons lengkap diterima secara automatik. Rutin "Find_Response" mengimbas buffer data penerimaan untuk TFI (0xD5). Rutin itu mengambil kesempatan untuk mengetahui apa yang diharapkan dari mesej dan mengabaikan respons ACK sederhana yang tidak termasuk data. Setelah TFI dijumpai, tindak balas yang diinginkan adalah pengimbangan yang diketahui daripadanya. Gema arahan dan status perintah disimpan oleh rutin "Read_Buff" untuk pengesahan kemudian.

Itu sahaja untuk siaran ini. Lihat projek elektronik saya yang lain di: www.boomerrules.wordpress.com