Az RC522 és PN532 RFID alapjai: 10 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:41

MEGJEGYZÉS: Most már olyan Instructables van, amely Arduino kódot kínál az RC522 és a PN532 számára.

Valamikor régebben vásároltam három különböző RFID modult a kísérletezéshez. Egy korábbi projektben részleteztem, hogyan lehet egy egyszerű 125 kHz-es modult használni egy alapvető biztonsági funkció végrehajtásához. Az ehhez hasonló modulok csak olvasható címkéket használnak, így a folyamat megkeresi az azonosítót, szükség esetén tárolja, és összehasonlítja a tárolt azonosítókkal. A többi megvásárolt modul 13,56 MHz-en működik, és olvasható és írható címkéket használ, így pazarlás egyszerűen használni őket az alapvető biztonság érdekében. A két közös modul vagy az RC522 chipet, vagy a PN532 chipet használja - mindkettőt az NXP készítette.

Ha olvasta más projektjeimet, tudja, hogy szeretek olcsó PIC mikrovezérlőket és programokat használni összeszerelési nyelven. Tehát amit kerestem, az a lépések sorozata, amely szükséges a modulokkal és az RFID -címkékkel való beszélgetéshez. Bár a modulokhoz sok példaprogram van online, a legtöbbjük az Arduino „C” szoftverében van írva, és az SPI felületet használja. Továbbá a chipek és a Mifare címkék kézikönyvei megfejtést igényelnek. Ez a bejegyzés elsősorban azokról az információkról szól, amelyeket szerettem volna a projekt megkezdésekor. Tartalmazok továbbá PIC összeszerelő szoftverprogramokat az egyes modulok által megkövetelt alapvető parancsok végrehajtásához. Még ha nem is használ PIC- és/vagy összeállítási nyelvet, a forráskódnak legalább jó képet kell adnia az egyes lépések végrehajtásához szükséges konkrét parancsokról.

1. lépés: Soros interfészek

Az ezeken a modulokon használt chipek mindegyike képes az SPI, I2C vagy UART (HSSP) kapcsolaton keresztül kapcsolódni. A PN532 modul rendelkezik DIP kapcsolóval, amely a kívánt interfész kiválasztására szolgál, de az MFRC522 modul az SPI interfészhez van vezetékes. Inkább a PIC beépített UART-ját használom, ezért vadásztam online, hogy van-e mód arra, hogy az MFRC522 modult UART módba állítsuk. Azt találtam, hogy egy nyoma levágása a táblán megteszi a trükköt. A vágás hatékonyan eltávolítja a 3,3 voltot a chip EA csapjából. Technikailag az EA csapot a földhöz kell csatlakoztatni, de nem sok ember tudja lehúzni ezt a forrasztási teljesítményt, tekintettel a forgácscsap sűrűségére. Ne aggódjon, mert az EA csapnak nincs belső felhúzása, és nem „lebeg”, mint a régi TTL logikai bemenetek. Tekintse meg a forgácslapot és a táblaszakasz képét a vágni kívánt helyen. Győződjön meg arról, hogy csak a rövid nyomot vágja közvetlenül az EA csaphoz.

2. lépés: Hardver

Az UART kommunikáció hardvercsatlakozásait a fenti ábra mutatja. Az MFRC522 UART -csatlakozásai nincsenek megjelölve a táblán, de amint az a sematikus ábrán látható, az SDA pin UART adatokat fogad, a MISO pin pedig UART adatokat továbbít. A PN532 modul UART jelöléssel rendelkezik a kártya alsó oldalán.

Mindkét modul 3,3 voltos feszültséggel működik, és a PIC TX tűből származó 5 voltos logikai szintet is korlátozni kell. Az LCD csatlakozás a szabványos 4 bites beállítás, amelyet számos korábbi projektemben használtam. Az összes üzenet alapértelmezett formátuma a szabványos 1602 LCD (16 karakter 2 sor). Van egy 40 karakteres, 2 soros LCD -m is, amelyet nyers adattörlésre használok a hibakeresés során, ezért beleraktam egy definíciót a szoftverbe, amely lehetővé teszi számomra, hogy kihasználjam az extra megjelenítési területet.

3. lépés: Adatblokkok

A projekthez használt Mifare Classic 1k címkék 16 szektor, négy adatblokk szektoronként, 16 bájt adatblokkonként vannak konfigurálva. A 64 adatblokkból csak 47 használható. A 0. adatblokk a gyártó adatait tartalmazza, és a 3., 7., 11., 15., 19., 23., 27., 31., 35., 39., 43., 47., 51., 55., 59. és 63. blokkot Trailer blokkoknak nevezzük. A Trailer blokkok az utolsó szektorok, és két kulcsot és a blokkhozzáférési biteket tartalmaznak. A kulcsok és a blokkhozzáférési bitek csak az adott szektor adatblokkjaira vonatkoznak, így minden szektorhoz különböző kulcsokat és hozzáférési szabályokat rendelhet. Az alapértelmezett billentyűk beállítása „FF FF FF FF FFh”. Ehhez az alapvető projekthez csak egy adatblokkot használok, és megtartom az alapértelmezett kulcsokat és hozzáférési biteket. Rengeteg dokumentum kapcsolódik ezekhez a kártyákhoz, ezért csak keressen online a „Mifare” kifejezésre, vagy keresse fel az NXP webhelyét, ha részletesebben szeretné felfedezni őket.

4. lépés: Általános működés

Bár mindkét modul egyedi a hozzáférésükben és a címkék elérésében, egy általános folyamat szükséges a munka elvégzéséhez. Ebben a projektben feltételezzük, hogy a címkék a Mifare Classic 1k típusúak, és hogy egyszerre csak egy címkét engedélyezünk az antenna mezőben. Az alapvető lépéseket az alábbiakban határozzuk meg.

· A modul inicializálása: Általában ehhez olyan dolgok szükségesek, mint az értékek írása a regiszterekbe a chipben, „ébresztési” parancsok küldése és az antenna bekapcsolása. Egy akkumulátorral működtetett alkalmazásban szeretné be- és kikapcsolni az antennát az akkumulátor kímélése érdekében, de ehhez az egyszerű alkalmazáshoz egyszer bekapcsoljuk, majd bekapcsolva hagyjuk.

· Törölje a titkosítási zászlót (csak 522): Ha egy címke hitelesítésre kerül, akkor a zászló jelzi a felhasználónak, hogy a címkével folytatott kommunikáció titkosítva lesz. Ezt a zászlót a felhasználónak törölnie kell a következő vizsgálat előtt, még akkor is, ha a vizsgálandó címke ugyanaz.

· Címke keresése: A modul alapvetően azt kérdezi: „Van valaki kint?” és a címke azt válaszolja: „Itt vagyok”. Ha a modul nem kap gyors választ, abbahagyja a hallgatást. Ez azt jelenti, hogy ismételten el kell küldenünk szkennelési parancsokat a modulnak, amíg meg nem találja a címkét.

· A címke beszerzése Felhasználói azonosító szám (UID): A címke néhány korlátozott információval, például a címke típusával válaszol a beolvasási kérésre. Ez azt jelenti, hogy szükség lehet egy másik parancs küldésére, hogy megkapjuk az UID -jét. Az UID négy bájt a Mifare Classic 1k címkékhez. Ha más címkéknél hosszabb lehet, de ez a projekt nem foglalkozik velük.

· Válassza ki a címkét (csak 522): Az UID azonosítóval választható ki a címke, amelyet a felhasználó olvasni és írni szeretne hitelesíteni. Ennek alapja az a lehetőség, hogy az antenna mezőben több címke is lehet. Egyszerű alkalmazásunk esetében ez nem így van, de a címkét mindenképpen ki kell választanunk.

· A címke hitelesítése: Ez a lépés akkor szükséges, ha a címke olvasását vagy írását akarjuk végezni. Ha csak annyit akarunk tenni, hogy különbséget teszünk egy egyszerű biztonsági alkalmazás címkéi között, akkor elegendő az UID. A hitelesítés megköveteli, hogy ismerjük az UID -t, és ismerjük a hozzáférni kívánt címke adatszektorának titkosítási kulcsát. Ehhez a projekthez ragaszkodunk az alapértelmezett kulcsokhoz, de a további projektem megváltoztatja a kulcsokat, hogy a címke elektronikus pénztárcaként használható legyen.

· A címke olvasása vagy írása: Az olvasás mindig visszaadja a kért adatblokk mind a 16 bájtját. Az írások megkövetelik, hogy mind a 16 bájt egyszerre legyen írva. Ha ugyanabban az adatszektorban egy másik blokkot szeretne olvasni vagy írni, akkor a címkét nem kell újra hitelesíteni. Ha egy blokkot egy másik adatszektorban szeretne olvasni vagy írni, akkor a címkét újra hitelesíteni kell az adott szektorhoz tartozó kulccsal.

5. lépés: Az MFRC522 modul hozzáférési sorrendje

Az indítási rutin ezeket az alapvető lépéseket tartalmazza, amelyeket a legtöbb alkalmazás nézett meg:

· Ál adatadatok küldése (lásd a következő bekezdést)

· Soft reset

· RF vevő erősítés beállítása (ha az alapértelmezettől eltérő valami kívánatos)

· Állítsa az ASK modulációs százalékát 100% -ra

· Állítsa be a vetőmag értékét a CRC számításokhoz

· Kapcsolja be az antennát

· Firmware verzió beszerzése (nem kötelező)

Megmagyarázhatatlan okokból a modulom bekapcsol, és úgy gondolja, hogy írási parancsot kapott adatbájt nélkül. Nem tudom, hogy ez csak a modulommal kapcsolatos probléma, de máshol nem láttam rá utalást. Kísérleteztem hardveres és szoftveres visszaállításokkal is, és egyik sem oldotta meg a problémát. A megoldásom az volt, hogy hozzáadtam egy dummy read hívást a „0” (nem definiált) regisztráláshoz a modul inicializálási rutinjának elején. Ha a modul ezt az ismeretlen írási parancs adatainak tekinti, úgy tűnik, nincsenek káros hatások. Ha olvasási parancsnak tekinti, akkor semmi hasznos nem történik. Zavar, hogy nem tudom teljesen meghatározni a problémát, különösen, ha csak a modul hardver -visszaállítása nem oldja meg a problémát.

Az RC522 chip számos regiszterből áll, amelyek többsége írható és olvasható. Írás végrehajtásához a regisztrációs számot elküldi a modulnak, majd az írandó értéket. Olvasás végrehajtásához a regiszterszám 0x80 -at ad hozzá, és ezt elküldi a modulnak. Az írási parancsra adott válasz az elérett regiszter visszhangja. Az olvasási parancsra adott válasz a regiszter tartalma. A szoftver ezeket az ismereteket kihasználva ellenőrzi, hogy a parancsot megfelelően hajtották -e végre.

6. lépés: PN532 modul hozzáférési sorrendje

Az indítási rutin a következő lépéseket tartalmazza:

· Inicializáló karakterlánc küldése: Ez az UART interfészre jellemző. A kézikönyv azt állítja, hogy az UART interfész felébred az interfészen észlelt ötödik emelkedő szélén. 0x55, 0x55, 0x00, 0x00, 0x00, 0x00 küldését javasolja. A legtöbb esetben elegendő számú karakternek kell lennie emelkedő szélekkel, és nem tűnhetnek úgy, mint egy parancs bevezető (00 00 FF).

· A modul felébresztése: A felhasználói kézikönyvben olvasható, hogy a modul egyfajta „LowVbat” nevű alvó állapotba inicializál. Az állapotból való kilépéshez el kell küldenünk egy „SAMConfiguration” parancsot.

A PN532 elvárja, hogy a parancsok meghatározott üzenetformátumban kerüljenek elküldésre, amely tartalmazza a bevezetőt, az üzenetet és a postamble -t. A válaszüzenetek ugyanazt a formátumot követik. A parancs- és válaszüzenetek egyaránt tartalmaznak TFI -t (Frame Identifier) és a parancs verzióját. A parancs 0xD4 TFI -t, a válasz 0xD5 értéket használ. A parancsverziók eltérőek, de a válasz mindig növeli a parancsverziót, és visszaadja a bájtban a TFI után. Ez a következetesség lehetővé teszi a válaszüzenetek könnyű beolvasását a vonatkozó információkhoz.

Minden parancsüzenet (a preambulumot követve) az üzenet hosszából, az üzenet hosszának 2 -es kiegészítéséből, a TFI -ből, a parancsból, az adatokból, az ellenőrző összegből és a postamble -ből áll. A szoftver felépíti az egyes parancsokat, majd meghív egy rutint, amely kiszámítja az ellenőrző összeget, és hozzáfűzi a postamble -t.

A válasz üzenetformátuma hasonló a parancséhoz. Egy tipikus válasz egy ACK (00 00 FF 00 FF 00), amelyet a parancsra adott válasz követ. Minden parancsválasz 00 00 FF bevezetővel kezdődik. A válasznak tartalmaznia kell egy D5 TFI bájtot, majd a parancs számát 1 -gyel növelve. A „SAMConfiguration” parancsunkhoz (14) ez a 15. A „SAMConfiguration” parancs ezt a választ kapja: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00

Vannak más modul-specifikus parancsok is, amelyeket el lehet küldeni, de ezekre nincs szükség ehhez az alkalmazáshoz. Viszont belevettem egy rutinot, amely hívható a firmware verziószámának lekéréséhez. Tipikus válasz (az ACK és a preambulum után) a következő: 06 FA D5 03 32 01 06 07 E8 00. A „01 06 07” az 1.6.7 firmware verziószámát jelzi.

7. lépés: Címke -hozzáférési sorrend

Miután a modul elkészült, a címkékre specifikus parancsokat küldhetünk. A címkeadatok olvasásához vagy írásához rendelkeznünk kell azonosító számával (UID). Az UID és a kulcs ezután egy adott címkeadat -szektor engedélyezésére lesz használható olvasásra/írásra. A címkeadatok olvasása/írása mindig a megadott adatblokk mind a 16 bájtján történik. Ez azt jelenti, hogy a tipikus alkalmazás beolvassa az adatblokkot, szükség szerint módosítja az adatokat, majd visszaírja az új adatokat a címkébe.

8. lépés: Szoftver

A megszakításkezelő szoftver hívást kap, amikor a PIC UART egy bájt adatot kap. Néhány korábbi UART projektemben csak le tudtam kérdezni az RX megszakítás jelzőt, ahelyett, hogy megszakításkezelőt kellett volna használnom. Ez nem vonatkozik erre a szoftverre, különösen a PN532 -re, amely sokkal nagyobb adatátviteli sebességgel kommunikál, mint az RC522. Az RC522 UART interfésze 9600 baudra korlátozódik, míg a PN532 alapértelmezett értéke 115k, és akár 1,288M baud is lehet. A fogadott bájtokat egy pufferterületen tárolják, és a szoftver nagy része szükség szerint lekéri őket.

A New_Msg jelző azt jelzi, hogy bájtok érkeztek, a Byte_Count pedig azt, hogy hány. A szoftverbe beépítettem egy „Disp_Buff” rutinot, amely hívható, hogy megjelenítse a fogadási puffer tartalmát a hibakeresés során. A visszaküldési üzenetek egy része túlcsordul egy tipikus 1602 -es kijelzőn, de van egy 40 karakteres, 2 soros LCD -m, amelyet egy online elektronikai többlet webhelyen találtam. A „Max_Line” definíció beállítható az LCD méretéhez. Ha eléri a „Max_Line” értéket, a „Disp_Buff” rutin a második sorba írással folytatódik. Hozzáadhat egy kis kódot ehhez a rutinhoz, hogy folytassa a harmadik és a negyedik sorral, ha rendelkezik 4 soros LCD-vel. A PN532 -nél van egy jelző, amelyet úgy lehet beállítani, hogy a rutin vagy az összes fogadott bájtot letörölje, vagy csak a kiolvasott válasz 16 adatbájtját.

Nincs szükség a fogadási puffer vagy a Byte_Count törlésére, mivel a New_Msg jelző törlésével a Byte_Count törlődik a megszakításkezelő által, és ezt használják a puffer indexeként. A New_Msg rendszerint minden parancslépés előtt törlődik, így az adott parancsra vonatkozó eredmények könnyen megtalálhatók és ellenőrizhetők. Az RC522 -ben ez azt jelenti, hogy a fogadási puffer általában csak 1-4 bájt. Bizonyos esetekben, például az adatblokkok olvasásakor a Read_FIFO parancsot többször kell kiadni ahhoz, hogy a bájtokat a FIFO -ból a fogadó pufferbe helyezze át. A PN532 összes parancs eredménye a fogadási pufferbe kerül, így a szükséges bájtok megkereséséhez szkennelési eljárást kell végrehajtani.

A szoftver fő ciklusa keres egy címkét, majd hitelesíti a címkét olvasásra/írásra. Az itt szereplő tesztszoftvereknél a Junk_Num változó minden alkalommal módosul a fő cikluson keresztül, és a címkére való írás során használatos. Az írott értékek váltakoznak a Junk_Num értéke és a Junk_Num 1 -es kiegészítése között. Végül a 16 írott érték olvasásra és megjelenítésre kerül. Minden lépéshez megjelennek üzenetek késleltetett rutinhívásokkal, hogy legyen idő az egyes üzenetek elolvasására. Hibaüzenetek is rendelkezésre állnak, de általában csak akkor fordulhatnak elő, ha egy művelet során eltávolítják a címkét.

A szoftver inicializálásának része egy kódrész, amely csak a bekapcsoláskor hajtódik végre, és kihagyásra kerül, ha szoftver visszaállítást észlel. A hibaüzenetek általában a szoftver visszaállításával fejeződnek be a fő hurokból való kilépés módjaként. A visszaállítás a „Tilt” rutinban történik, amely egyszerűen engedélyezi a Watchdog Timer -t, majd egy végtelen ciklusba megy, és várja az időtúllépést.

9. lépés: MFRC522 Egyedi szoftver

Az RC522 chip több alacsony szintű utasítást igényel, mint a PN532 chip, hogy kommunikáljon a címkékkel. Ez olyan, mint az összeszerelési nyelven történő programozás, míg a „C” programozás. Egy másik jelentős különbség az, hogy az RC522 megköveteli, hogy a címkével való kommunikáció FIFO pufferen keresztül történjen. A „Write_FIFO” és „Read_FIFO” rutinok kezelik ezeket a feladatokat. Az MFRC522 szoftver tartalmaz egy részt az alacsonyabb szintű parancsokhoz, amelyekből a fő funkciók épülnek.

A címke parancs ellenőrző összegének számítása az RC522 esetében nagyon eltér a PN532 -től. Miután a FIFO -ban felépítettük a tag parancsot, egy modulparancsot küldünk az ellenőrző összeg kiszámításához. A 16 bites eredmény nincs automatikusan hozzáfűzve a tag parancshoz, de két 8 bites regiszterből olvasható. Az ellenőrző összeg kiszámítása törli a FIFO -ban lévő adatokat, így a szükséges sorrend a következő:

· Készítse el a parancsot a FIFO -ban

· Parancsoljon egy ellenőrzőösszeg -számítást

· Ismét készítse el a parancsot a FIFO -ban

· Olvassa el a CRC regisztereket, és írja be az ellenőrző összeg bájtjait a FIFO -nak

· Küldjön vagy Átvétel vagy Hitelesítés parancsot

A Transzfere parancs továbbítja a FIFO puffert, majd automatikusan átvált vételi módba, és várja a címke válaszát. Az adatok tényleges továbbítása érdekében a Transzfere parancsot követnie kell a StartSend bit beállítását a BitFramingRegisterben. Az Authenticate parancs nem rendelkezik ezzel a követelménysel.

Általánosságban elmondható, hogy az online elérhető Arduino „C” kódú alkalmazások a megszakítás jelző regisztereit és az időtúllépési regisztert használják annak biztosítására, hogy a helyes válasz időben érkezzen. Véleményem szerint ez túlzás ehhez a nem időkritikus alkalmazáshoz. Ehelyett rövid szoftveres időtúllépésekkel várom a választ, majd ellenőrzem, hogy helyesek -e. A Mifare -címkék kézikönyve részletezi a különböző tranzakciók időzítését, és a várható bájtszám beérkezésének idejét is engedélyezi. Ezek az időkésések a legtöbb alacsony szintű parancs alprogramba vannak beépítve.

10. lépés: Egyedi PN532 szoftver

A modul inicializálása után a címke megkereséséhez és hitelesítéséhez szükséges lépéseket a megfelelő parancs, majd a szükséges adatok beírásával hajtják végre. A scan parancs visszaadja az UID -t, amelyet ezután használnak a hitelesítéshez. Ezt követően a címke olvasása és írása elküldi vagy visszaküldi a címzett adatblokk 16 bájtját.

Az inicializálási sorrendet korábban részleteztük, és ugyanez a szoftverrutin elküldi a SAMConfiguration parancsot is, hogy a modul kilépjen az „LowVbat” állapotból. A többi alapvető parancs, mint például a Szkennelés, Hitelesítés, Olvasás/Írás címke, csak egymás után épül fel a vonatkozó rutinokban. Az ellenőrző összeget úgy számítják ki, hogy összeadják a parancsbájtokat, kiegészítenek, majd hozzáadnak 1 -et, hogy 2 -es kiegészítéssé váljanak. A 8 bites eredményt közvetlenül a postamble előtt adjuk hozzá a parancssorhoz.

Nincs olyan FIFO, mint az RC522 -ben, így a teljes válaszüzenet automatikusan érkezik. A „Find_Response” rutin megvizsgálja a fogadási adatpuffert a TFI -re (0xD5). A rutin kihasználja a várt üzenetek ismeretét, és figyelmen kívül hagyja az egyszerű ACK -válaszokat, amelyek nem tartalmaznak adatokat. Miután megtalálta a TFI -t, a kívánt válaszok ismert eltolódnak tőle. A parancs visszhangját és a parancsállapot bájtokat a „Read_Buff” rutin elmenti a későbbi ellenőrzéshez.

Ennyi a bejegyzéshez. Nézze meg a többi elektronikai projektemet is: www.boomerrules.wordpress.com