RC522 un PN532 RFID pamati: 10 soļi

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:55

PIEZĪME: Man tagad ir Instructables, kas piedāvā Arduino kodu RC522 un PN532.

Pirms kāda laika es nopirku trīs dažādus RFID moduļus eksperimentiem. Iepriekšējā projektā es sīki aprakstīju, kā izmantot vienkāršu 125 kHz moduli, lai veiktu pamata drošības funkciju. Šādi moduļi izmanto tikai lasāmus tagus, lai process tiktu meklēts, saglabāts, ja vēlaties, un salīdzināts ar saglabātajiem ID. Citi moduļi, kurus es nopirku, darbojas 13,56 MHz un izmanto tagus, kurus var gan lasīt, gan rakstīt, tāpēc ir vienkārši izšķērdēt tos vienkārši izmantot pamata drošībai. Abos izplatītajos moduļos tiek izmantota mikroshēma RC522 vai mikroshēma PN532 - abus ražo NXP.

Ja esat lasījis kādu citu manu projektu, jūs zināt, ka man patīk izmantot lētus PIC mikrokontrollerus un programmu montāžas valodā. Tāpēc es meklēju darbību secību, kas nepieciešama, lai sarunātos ar moduļiem un RFID tagiem. Lai gan moduļiem tiešsaistē ir daudz piemēru programmu, lielākā daļa no tām ir rakstītas Arduino programmatūrā “C” un izmanto SPI saskarni. Arī mikroshēmu un Mifare tagu rokasgrāmatas nedaudz atšifrē. Šis ziņojums galvenokārt attiecas uz informāciju, kuru es vēlos iegūt, uzsākot projektu. Es iekļauju arī PIC montāžas programmatūras programmas, lai izpildītu pamata moduļus, kas nepieciešami katram modulim. Pat ja jūs neizmantojat PIC un/vai montāžas valodu, pirmkodam vajadzētu vismaz sniegt jums labu priekšstatu par konkrētajām komandām, kas nepieciešamas, lai veiktu katru darbību.

1. darbība: sērijas saskarnes

Abas šajos moduļos izmantotās mikroshēmas var mijiedarboties, izmantojot SPI, I2C vai UART (HSSP). PN532 modulim ir DIP slēdzis, ko izmanto, lai izvēlētos vēlamo saskarni, bet MFRC522 modulis ir savienots ar SPI saskarni. Es gribētu izmantot PIC iebūvēto UART, tāpēc es meklēju tiešsaistē, lai noskaidrotu, vai ir veids, kā iegūt MFRC522 moduli UART režīmā. Es atklāju, ka vienas pēdas sagriešana uz tāfeles darīs visu. Griezums efektīvi noņem 3,3 voltus no mikroshēmas EA tapas. Tehniski EA tapa pēc tam jāpievieno zemei, bet ne daudzi cilvēki var izvilkt šo lodēšanas darbu, ņemot vērā mikroshēmas tapas blīvumu. Tomēr neuztraucieties, jo EA tapai nav iekšējas pievilkšanas un tā “nepeld”, kā to dara vecās TTL loģikas ieejas. Griežamo vietu skatiet mikroshēmu diagrammā un tāfeles sadaļas attēlā. Pārliecinieties, ka esat nogriezis tikai īsās pēdas, kas iet tieši uz EA tapu.

2. darbība. Aparatūra

Aparatūras savienojumi UART sakariem ir parādīti iepriekš redzamajā diagrammā. UF savienojumi MFRC522 nav atzīmēti uz tāfeles, bet, kā parādīts shēmā, SDA tapa saņem UART datus, un MISO tapa pārraida UART datus. PN532 modulim ir UART marķējums tāfeles apakšējā pusē.

Abi moduļi darbojas ar 3,3 voltiem, un arī 5 voltu loģikas līmenis no PIC TX tapas ir jāierobežo. LCD savienojums ir standarta 4 bitu iestatīšana, kas ir izmantota vairākos iepriekšējos projektos. Standarta 1602 LCD (16 rakstzīmes ar 2 rindām) ir iestatīts visu ziņojumu noklusējuma formāts. Man ir arī 40 rakstzīmes divrindu LCD, ko izmantoju neapstrādātu datu izgāzšanai atkļūdošanas laikā, tāpēc programmatūrā iekļāvu definīciju, kas ļauj izmantot papildu displeja vietu.

3. darbība: datu bloki

Šim projektam izmantotie Mifare Classic 1k tagi ir konfigurēti kā 16 sektori, četri datu bloki sektorā, 16 baiti katrā datu blokā. No 64 datu blokiem tikai 47 ir faktiski izmantojami. Datu bloks 0 satur ražotāja datus, un blokus 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 un 63 sauc par piekabes blokiem. Piekabes bloki ir pēdējie katrā sektorā, un tie satur divas atslēgas un bloka piekļuves bitus. Atslēgas un bloķēšanas piekļuves biti attiecas tikai uz datu blokiem šajā sektorā, lai jums varētu būt dažādas atslēgas un piekļuves noteikumi katrai nozarei. Noklusējuma taustiņi ir iestatīti uz “FF FF FF FF FFh”. Šim pamatprojektam es izmantoju tikai vienu datu bloku un saglabāju noklusējuma atslēgas un piekļuves bitus. Ar šīm kartēm ir saistīti daudzi dokumenti, tāpēc vienkārši meklējiet tiešsaistē “Mifare” vai apmeklējiet NXP vietni, ja vēlaties tos izpētīt padziļināti.

4. solis: Vispārējā darbība

Lai gan abi moduļi ir unikāli piekļuves un tagu piekļuves veidā, darba veikšanai ir nepieciešams vispārējs process. Šim projektam mēs pieņemam, ka tagi ir Mifare Classic 1k tipa un ka mēs vienlaikus atļaujam tikai vienu tagu antenas laukā. Pamata darbības ir definētas zemāk.

· Inicializēt moduli: parasti tas prasa tādas lietas kā vērtību ierakstīšana mikroshēmas reģistros, “modināšanas” komandu nosūtīšana un antenas barošanas ieslēgšana. Lietojot akumulatoru, jūs vēlaties ieslēgt un izslēgt antenas strāvu, lai taupītu akumulatoru, taču šai vienkāršajai lietojumprogrammai mēs to ieslēdzam vienu reizi un pēc tam atstājam ieslēgtu.

· Notīrīt šifrēšanas karodziņu (tikai 522): ja tags tiek autentificēts, tiek iestatīts karodziņš, lai lietotājs zinātu, ka saziņa ar tagu tiks šifrēta. Pirms nākamās skenēšanas lietotājam šis karogs ir jānotīra, pat ja skenētais tags ir tas pats.

· Meklējiet tagu: modulis būtībā jautā: “Vai kāds ir tur?” un atzīme atbild: “Es esmu šeit”. Ja modulis nesaņem ātru atbildi, tas pārtrauc klausīties. Tas nozīmē, ka mums atkārtoti jānosūta skenēšanas komandas modulim, līdz tas atrod tagu.

· Iegūt tagu Lietotāja identifikācijas numurs (UID): tags atbildēs uz skenēšanas pieprasījumu, sniedzot ierobežotu informāciju, piemēram, tā veida tagu. Tas nozīmē, ka mums, iespējams, būs jānosūta cita komanda, lai iegūtu tā UID. UID ir četri baiti Mifare Classic 1k tagiem. Ja citiem tagiem tas var būt garāks, bet šajā projektā tie netiek risināti.

· Atlasiet tagu (tikai 522): UID tiek izmantots, lai atlasītu tagu, ko lietotājs vēlas autentificēt lasīšanai un rakstīšanai. Tas ir balstīts uz iespēju, ka antenas laukā var būt vairāki tagi. Tas neattiecas uz mūsu vienkāršo lietojumprogrammu, taču mums tomēr ir jāizvēlas tags.

· Autentificēt tagu: šī darbība ir nepieciešama, ja mēs vēlamies nolasīt vai rakstīt tagu. Ja viss, ko mēs vēlamies darīt, ir atšķirt tagus vienkāršai drošības lietojumprogrammai, tad pietiek ar UID. Lai veiktu autentifikāciju, mums ir jāzina UID un jāzina tā taga datu sektora šifrēšanas atslēga, kurai vēlamies piekļūt. Šim projektam mēs paliekam pie noklusējuma atslēgām, bet mans turpmākais projekts maina atslēgas, lai tagu varētu izmantot kā elektronisku maku.

· Lasīt vai rakstīt tagu: lasījumi vienmēr atgriež visus 16 pieprasītos datu bloka baitus. Rakstīšana pieprasa, lai visi 16 baiti tiktu rakstīti vienlaikus. Ja vēlaties lasīt vai rakstīt citu bloku tajā pašā datu sektorā, tags nav atkārtoti jāautentificē. Ja vēlaties lasīt vai rakstīt bloku citā datu sektorā, tags ir jāautentificē vēlreiz, izmantojot šī sektora atslēgu.

5. darbība: MFRC522 moduļa piekļuves secība

Startēšanas rutīna ietver šīs pamata darbības, kas atrodamas lielākajā daļā aplūkoto lietojumprogrammu:

· Nosūtīt fiktīvus datu baitus (sk. Nākamo rindkopu)

· Mīksta atiestatīšana

· Iestatiet RF uztvērēja pastiprinājumu (ja vēlaties kaut ko citu, nevis noklusējumu)

· Iestatiet ASK modulācijas procentuālo vērtību uz 100%

· Iestatiet sēklu vērtību CRC aprēķiniem

· Ieslēdziet antenu

· Iegūstiet programmaparatūras versiju (nav nepieciešama)

Neizskaidrojamu iemeslu dēļ mans modulis ieslēdzas un uzskata, ka ir saņēmis rakstīšanas komandu bez datu baita. Es nezinu, vai tā ir tikai problēma ar manu moduli, bet es neesmu redzējis atsauces uz to citur. Es eksperimentēju gan ar aparatūras, gan programmatūras atiestatīšanu, un neviens no tiem neizlaboja problēmu. Mans risinājums bija pievienot fiktīvu lasīšanas zvanu, lai moduļa inicializācijas rutīnas sākumā reģistrētu “0” (nenoteikts). Ja modulis to uzskata par nezināmas rakstīšanas komandas datiem, šķiet, ka nav nekādu nelabvēlīgu seku. Ja tā to uzskata par lasīšanas komandu, tad nekas noderīgs nenotiek. Mani satrauc tas, ka es nevaru pilnībā definēt problēmu, jo īpaši ņemot vērā to, ka tikai moduļa aparatūras atiestatīšana neatrisina problēmu.

RC522 mikroshēma sastāv no vairākiem reģistriem, no kuriem lielākā daļa ir gan lasīšana, gan rakstīšana. Lai veiktu rakstīšanu, reģistra numurs tiek nosūtīts modulim, kam seko rakstāmā vērtība. Lai veiktu lasīšanu, reģistra numuram ir pievienots 0x80 un tas tiek nosūtīts modulim. Atbilde uz rakstīšanas komandu ir piekļuves reģistra atbalss. Atbilde uz lasīšanas komandu ir reģistra saturs. Programmatūra izmanto šīs zināšanas, lai pārbaudītu, vai komanda tika pareizi izpildīta.

6. darbība: PN532 moduļa piekļuves secība

Palaišanas rutīna ietver šādas nepieciešamās darbības:

· Sūtīt inicializācijas virkni: tas attiecas tikai uz UART interfeisu. Rokasgrāmatā teikts, ka UART saskarne pamodīsies saskarnē konstatētajā piektajā augšējā malā. Tā iesaka sūtīt 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Lielākoties ir jābūt pietiekamam rakstzīmju skaitam ar augošām malām, un tās nedrīkst izskatīties kā komandu preambula (00 00 FF).

· Modināt moduli: apglabāts lietotāja rokasgrāmatā, tas parāda, ka modulis tiek inicializēts miega režīmā, ko sauc par “LowVbat”. Lai izietu no šī stāvokļa, mums ir jānosūta komanda “SAMConfiguration”.

PN532 sagaida, ka komandas tiks nosūtītas noteiktā ziņojuma formātā, kas ietver preambulu, ziņojumu un pasta zīmi. Atbildes ziņojumi ir tādā pašā formātā. Gan komandu, gan atbildes ziņojumos ir iekļauts TFI (kadra identifikators) un komandas versija. Komanda izmanto TFI 0xD4, bet atbilde izmanto 0xD5. Komandu versijas atšķiras, taču atbilde vienmēr palielinās komandas versiju un atdos to baitos pēc TFI. Šī konsekvence ļauj atbildes ziņojumus viegli skenēt, lai iegūtu nepieciešamo informāciju.

Katrs komandas ziņojums (pēc preambulas) sastāv no ziņojuma garuma, 2 papildinājuma ar ziņojuma garumu, TFI, komandas, datiem, kontrolsummas un pastmarkas. Programmatūra izveido atsevišķas komandas un pēc tam izsauc rutīnu, kas aprēķina kontrolsummu un pievieno pasta zīmi.

Atbildes ziņojuma formāts ir līdzīgs komandas formātam. Tipiska atbilde ietver ACK (00 00 FF 00 FF 00), kam seko īpaša atbilde uz komandu. Katra komandu atbilde sākas ar preambulu 00 00 FF. Atbildei vajadzētu būt arī TFI baitam D5, kam seko komandas numurs, kas palielināts par 1. Mūsu komandai “SAMConfiguration” (14) tas būtu 15. Komanda “SAMConfiguration” saņem šādu atbildi: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Ir arī citas moduļu komandas, kuras var nosūtīt, taču tās nav nepieciešamas šai lietojumprogrammai. Tomēr es iekļāvu rutīnu, kuru var izsaukt, lai izgūtu programmaparatūras versijas numuru. Tipiska atbilde (pēc ACK un preambulas) būtu šāda: 06 FA D5 03 32 01 06 07 E8 00. “01 06 07” norāda programmaparatūras versijas numuru 1.6.7.

7. darbība. Tagu piekļuves secība

Kad modulis ir gatavs, mēs varam nosūtīt komandas, kas raksturīgas tagiem. Lai lasītu vai rakstītu tagu datus, mums ir nepieciešams tā identifikācijas numurs (UID). Pēc tam UID un atslēga tiks izmantota, lai autorizētu noteiktu taga datu sektoru lasīšanai/rakstīšanai. Tagu datu lasīšana/rakstīšana vienmēr tiek veikta visos 16 baitos noteiktā datu blokā. Tas nozīmē, ka parastā lietojumprogramma nolasa datu bloku, pārveido datus pēc vēlēšanās un pēc tam ieraksta jaunos datus atpakaļ tagā.

8. solis: programmatūra

Pārtraukuma apstrādātāja programmatūra tiek izsaukta ikreiz, kad PIC UART saņem datu baitu. Dažos savos iepriekšējos UART projektos es varēju vienkārši aptaujāt RX pārtraukšanas karodziņu, nevis izmantot pārtraukuma apstrādātāju. Tas neattiecas uz šo programmatūru, it īpaši attiecībā uz PN532, kas sazinās ar daudz lielāku datu pārraides ātrumu nekā RC522. RC522 UART interfeiss ir ierobežots līdz 9600 baudām, savukārt PN532 noklusējuma vērtība ir 115k, un to var iestatīt līdz 1,288M baudiem. Saņemtie baiti tiek glabāti bufera zonā, un lielākā daļa programmatūras tos pēc vajadzības izgūst.

New_Msg karodziņš norāda, ka baiti ir saņemti, un baitu_skaitlis norāda, cik. Programmatūrā esmu iekļāvis “Disp_Buff” rutīnu, kuru var izsaukt, lai atkļūdošanas laikā parādītu saņemšanas bufera saturu. Daži atgriešanās ziņojumi pārpildīs tipisku 1602 displeju, bet man ir 40 rakstzīmes divrindu LCD, ko atradu tiešsaistes elektronikas pārpalikuma vietnē. Definīciju “Max_Line” var iestatīt jūsu LCD izmēram. Ja tiek sasniegts “Max_Line”, “Disp_Buff” rutīna turpinās, rakstot uz otro rindu. Jūs varētu pievienot nelielu kodu šai kārtībai, lai turpinātu uz trešo un ceturto rindu, ja jums ir 4 rindu LCD. PN532 ir karodziņš, kuru var iestatīt tā, lai rutīna vai nu izmestu visus saņemtos baitus, vai vienkārši izmestu 16 datu baitus no lasīšanas atbildes.

Nav nepieciešams notīrīt saņemšanas buferi vai baitu skaitli, jo, dzēšot karodziņu New_Msg, pārtraukšanas apstrādātājs atbrīvos Byte_Count, un tas tiek izmantots kā bufera indekss. New_Msg parasti tiek notīrīts pirms katras komandas darbības, lai šai komandai raksturīgos rezultātus varētu viegli atrast un pārbaudīt. RC522 tas nozīmē, ka saņemšanas buferim parasti ir tikai 1 līdz 4 baiti. Dažos gadījumos, piemēram, nolasot datu bloku, komanda Read_FIFO ir jāizdod vairākas reizes, lai baitus pārvietotu no FIFO uz saņemšanas buferi. Visi PN532 komandu rezultāti nonāk saņemšanas buferī, tāpēc tiek veikta skenēšanas procedūra, lai atrastu nepieciešamos konkrētos baitus.

Programmatūras galvenā cilpa meklē tagu un pēc tam autentificē lasīšanu/rakstīšanu. Šeit iekļautajai testa programmatūrai mainīgais Junk_Num tiek mainīts katru reizi, izmantojot galveno cilpu, un tiek izmantots rakstīšanas laikā tagā. Rakstītās vērtības mainās starp vērtību Junk_Num un 1 papildinājumu Junk_Num. Visbeidzot, 16 rakstītās vērtības tiek nolasītas un parādītas. Katram solim ir displeja ziņojumi ar aizkavētiem ikdienas zvaniem, lai dotu laiku katra ziņojuma lasīšanai. Tiek sniegti arī kļūdu ziņojumi, taču tiem parasti vajadzētu parādīties tikai tad, ja darbības laikā tiek noņemts tags.

Daļa programmatūras inicializācijas ir koda sadaļa, kas tiek izpildīta tikai pēc ieslēgšanas un tiek izlaista, ja tiek konstatēta programmatūras atiestatīšana. Kļūdu ziņojumi parasti beidzas ar programmatūras atiestatīšanu, lai izietu no galvenās cilpas. Atiestatīšana notiek “noliekšanas” režīmā, kas vienkārši iespējo Watchdog taimeri un pēc tam nonāk bezgalīgā ciklā, gaidot taimautu.

9. darbība: unikāla programmatūra MFRC522

Lai veiktu saziņu ar tagiem, RC522 mikroshēmai ir vajadzīgas vairāk zema līmeņa instrukcijas nekā PN532 mikroshēmai. Tas ir kā programmēšana montāžas valodā, salīdzinot ar programmēšanu “C”. Vēl viena būtiska atšķirība ir tāda, ka RC522 pieprasa, lai sakari ar tagu tiktu novirzīti caur FIFO buferi. Rutīnas “Write_FIFO” un “Read_FIFO” apstrādā šos uzdevumus. Programmatūrā MFRC522 ir sadaļa daudzām zemāka līmeņa komandām, no kurām tiek veidotas galvenās funkcijas.

Taga komandu kontrolsummas aprēķins RC522 ir ļoti atšķirīgs nekā PN532. Pēc tam, kad tagu komanda ir iebūvēta FIFO, tiek nosūtīta moduļa komanda, lai aprēķinātu kontrolsummu. 16 bitu rezultāts netiek automātiski pievienots tagu komandai, bet ir pieejams lasīšanai no diviem 8 bitu reģistriem. Kontrolsummas aprēķins izdzēš FIFO datus, tāpēc nepieciešamā secība ir šāda:

· Izveidojiet komandu FIFO

· Komandēt kontrolsummas aprēķinu

· Atkal izveidojiet komandu FIFO

· Izlasiet CRC reģistrus un ierakstiet kontrolsummas baitus FIFO

· Nosūtiet komandu Pārsūtīt vai Autentificēt

Komanda Pārņemt pārsūtīs FIFO buferi un pēc tam automātiski pārslēgsies uz saņemšanas režīmu, lai gaidītu atbildi no taga. Lai faktiski pārsūtītu datus, komandai Transieve ir jāiestata BitStartingRegister bitu StartSend. Komandai Autentificēt šī prasība nav.

Parasti tiešsaistē pieejamās Arduino “C” koda lietojumprogrammas izmanto pārtraukuma karogu reģistrus un taimauta reģistru, lai nodrošinātu, ka pareizā atbilde tiek saņemta savlaicīgi. Manuprāt, tas ir pārmērīgs risinājums šai ne laika kritiskajai lietojumprogrammai. Tā vietā es izmantoju īsus programmatūras taimautus, lai gaidītu atbildi un pēc tam pārbaudītu, vai tā ir pareiza. Mifare tagu rokasgrāmatā ir sīki izklāstīts dažādu darījumu laiks un laiks, lai saņemtu paredzamo baitu skaitu. Šie laika aizkavi ir iebūvēti lielākajā daļā zema līmeņa komandu apakšprogrammu.

10. darbība: unikāla programmatūra PN532

Kad modulis ir inicializēts, soļi, kas nepieciešami, lai atrastu un autentificētu tagu, tiek veikti, ierakstot atbilstošo komandu un pēc tam nepieciešamos datus. Skenēšanas komanda atgriež UID, kas pēc tam tiek izmantots autentifikācijai. Pēc tam taga lasīšana un rakstīšana nosūta vai atdod 16 baitus adresētajam datu blokam.

Inicializācijas secība tika detalizēta iepriekš, un tā pati programmatūras rutīna arī nosūta komandu SAMConfiguration, lai modulis izietu no “LowVbat” stāvokļa. Pārējās pamata komandas, piemēram, Skenēt, Autentificēt, Lasīt/Rakstīt tagu, tiek vienkārši veidotas secīgi piemērojamajās kārtībās. Kontrolsumma tiek aprēķināta, vienkārši saskaitot komandu baitus, veicot papildinājumu un pēc tam pievienojot 1, lai tas kļūtu par 2 papildinājumu. 8 bitu rezultāts tiek pievienots komandu virknei tieši pirms postamba.

Nav tāda FIFO kā RC522, tāpēc visi atbildes ziņojumi tiek saņemti automātiski. Rutīna “Find_Response” skenē TFI saņemšanas datu buferi (0xD5). Rutīna izmanto priekšrocības, zinot gaidāmos ziņojumus, un ignorē vienkāršas ACK atbildes, kurās nav ietverti dati. Kad TFI ir atrasts, vēlamās atbildes ir zināmas nobīdes no tā. Komandu atbalss un komandu statusa baiti tiek saglabāti, izmantojot kārtību “Read_Buff” vēlākai pārbaudei.

Tas ir šim ierakstam. Iepazīstieties ar maniem citiem elektronikas projektiem: www.boomerrules.wordpress.com