RC522 և PN532 RFID հիմունքներ. 10 քայլ

2024 Հեղինակ: John Day | [email protected]. Վերջին փոփոխված: 2024-01-30 09:48

ՈEՇԱԴՐՈԹՅՈՆ. Ես այժմ ունեմ Instructables, որոնք առաջարկում են Arduino կոդ RC522 և PN532 համար:

Որոշ ժամանակ առաջ ես փորձի համար գնել եմ երեք տարբեր RFID մոդուլներ: Նախորդ նախագծում ես մանրամասն նկարագրեցի, թե ինչպես օգտագործել պարզ 125 կՀց մոդուլ `հիմնական անվտանգության գործառույթը կատարելու համար: Նման մոդուլները օգտագործում են միայն կարդալու պիտակներ, այնպես որ գործընթացը սկանավորում է ID- ն, պահում ըստ ցանկության և համեմատում պահված ID- ների հետ: Իմ գնած մյուս մոդուլները գործում են 13.56-ՄՀց հաճախականությամբ և օգտագործում են պիտակներ, որոնք կարող են և՛ կարդալ, և՛ գրվել: Երկու ընդհանուր մոդուլներն օգտագործում են կամ RC522 չիպը, կամ PN532 չիպը, երկուսն էլ պատրաստված են NXP- ի կողմից:

Եթե կարդացել եք իմ ցանկացած այլ նախագիծ, ապա գիտեք, որ ես սիրում եմ օգտագործել էժան PIC միկրոկոնտրոլերներ և ծրագրեր հավաքման լեզվով: Այսպիսով, ես փնտրում էի մոդուլների և RFID պիտակների հետ խոսելու համար պահանջվող քայլերի հաջորդականությունը: Չնայած մոդուլների համար առցանց կան բազմաթիվ օրինակելի ծրագրեր, դրանցից շատերը գրված են Arduino- ի «C» ծրագրով և օգտագործում են SPI ինտերֆեյսը: Բացի այդ, չիպերի և Mifare պիտակների ձեռնարկները մի փոքր վերծանում են պահանջում: Այս գրառումը հիմնականում այն տեղեկատվության մասին է, որը ես կցանկանայի ունենալ նախագիծը սկսելիս: Ես նաև ներառում եմ PIC հավաքման ծրագրային ապահովման ծրագրեր `յուրաքանչյուր մոդուլով պահանջվող հիմնական հրամանների կատարման համար: Նույնիսկ եթե դուք չեք օգտագործում PIC և/կամ հավաքման լեզու, աղբյուրի կոդը պետք է ձեզ գոնե լավ պատկերացնի յուրաքանչյուր քայլ կատարելու համար պահանջվող հատուկ հրամանների մասին:

Քայլ 1: Սերիական միջերեսներ

Այս մոդուլների վրա օգտագործվող երկու չիպերն էլ ունակ են միանալ SPI, I2C կամ UART (HSSP) միջոցով: PN532 մոդուլն ունի DIP անջատիչ, որն օգտագործվում է ցանկալի ինտերֆեյսը ընտրելու համար, սակայն MFRC522 մոդուլը լարված է SPI ինտերֆեյսի համար: Ես նախընտրում եմ օգտագործել PIC- ի ներկառուցված UART- ը, այնպես որ ես առցանց որս արեցի ՝ տեսնելու համար, թե կա՞ արդյոք MFRC522 մոդուլը UART ռեժիմի անցնելու միջոց: Այն, ինչ ես գտա, այն էր, որ տախտակի վրա մեկ հետք կտրելը հնարք կտար: Կտրվածքն արդյունավետորեն հեռացնում է 3.3 վոլտ չիպի EA կապից: Տեխնիկապես EA կապն այնուհետև պետք է միացված լինի գետնին, բայց շատերը չեն կարող դուրս գալ այդ զոդման սխեմայից `հաշվի առնելով չիպի քորոցի խտությունը: Այնուամենայնիվ, անհանգստանալու կարիք չկա, քանի որ EA կապը չունի ներքին քաշքշուկ և չի «լողում», ինչպես անում են հին TTL տրամաբանական մուտքերը: Կտրելու տեղը տեսեք չիպերի գծապատկերին և տախտակի հատվածի նկարին: Համոզվեք, որ դուք կտրում եք միայն կարճ հետքը ՝ անմիջապես դեպի EA քորոց:

Քայլ 2: Սարքավորումներ

UART հաղորդակցությունների ապարատային միացումները ցուցադրված են վերևի դիագրամում: MFRC522- ի UART միացումները նշված չեն տախտակի վրա, բայց, ինչպես ցույց է տրված սխեմատիկայում, SDA կապը ստանում է UART տվյալները, իսկ MISO կապը փոխանցում է UART տվյալները: PN532 մոդուլն ունի UART նշումներ տախտակի ներքևի մասում:

Երկու մոդուլներն աշխատում են 3.3 վոլտ լարման վրա, և PIC TX կապից 5 վոլտ տրամաբանական մակարդակը նույնպես պետք է սահմանափակվի: LCD կապը ստանդարտ 4-բիթանոց կարգավորումն է, որն օգտագործվել է իմ նախորդ մի շարք նախագծերում: Բոլոր հաղորդագրությունների կանխադրված ձևաչափը սահմանվում է 1602 ստանդարտ LCD- ի համար (16 նիշ 2 տողով): Ես նաև ունեմ 40 տող ՝ 2 տող LCD- ով, որն օգտագործում եմ վրիպազերծման ժամանակ տվյալների հումքի թափման համար, այնպես որ ծրագրում ներառել եմ սահմանում, որը թույլ է տալիս ինձ օգտվել ցուցադրման լրացուցիչ տարածությունից:

Քայլ 3: Տվյալների արգելափակումներ

Այս ծրագրի համար օգտագործվող Mifare Classic 1k պիտակները կազմաձևված են որպես 16 հատված, չորս տվյալների բլոկ մեկ հատվածի համար, 16 բայթ մեկ տվյալների բլոկի համար: 64 տվյալների բլոկներից միայն 47 -ն են իրականում օգտագործելի: Տվյալների բլոկը 0 պարունակում է արտադրողի տվյալները և 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 և 63 բլոկները կոչվում են կցորդի բլոկներ: Թրեյլերային բլոկները վերջինն են յուրաքանչյուր հատվածում և պարունակում են երկու բանալիներ և բլոկի մուտքի բիթեր: Բանալիներն ու արգելափակման մուտքի բիթերը վերաբերում են միայն այդ հատվածի տվյալների բլոկներին, այնպես որ դուք կարող եք ունենալ տարբեր բանալիներ և մուտքի կանոններ յուրաքանչյուր հատվածի համար: Կանխադրված ստեղները սահմանվում են «FF FF FF FF FFh»: Այս հիմնական նախագծի համար ես օգտագործում եմ տվյալների միայն մեկ բլոկ և պահում եմ կանխադրված ստեղները և մուտքի բիթերը: Այս քարտերի հետ կապված բազմաթիվ փաստաթղթեր կան, այնպես որ պարզապես առցանց որոնեք «Mifare» - ը կամ այցելեք NXP կայքը, եթե ցանկանում եք դրանք ավելի խորը ուսումնասիրել:

Քայլ 4: Ընդհանուր գործողություն

Թեև երկու մոդուլները յուրահատուկ են իրենց հասանելիության և պիտակներին մուտք գործելու եղանակով, կա ընդհանուր գործընթաց, որը պահանջվում է աշխատանքը կատարելու համար: Այս նախագծի համար մենք ենթադրում ենք, որ պիտակները Mifare Classic 1k տիպն են, և որ մենք թույլ ենք տալիս միայն մեկ պիտակ միաժամանակ ալեհավաքի դաշտում: Հիմնական քայլերը սահմանվում են ստորև:

· Նախաձեռնել մոդուլը. Ընդհանրապես դա պահանջում է այնպիսի բաներ, ինչպիսիք են չիպում գրանցամատյաններում արժեքներ գրելը, «արթնացման» հրամաններ ուղարկելը և ալեհավաքի միացումը: Մարտկոցով աշխատող ծրագրում կցանկանայիք, որ մարտկոցը խնայելու համար կարողանայի միացնել և անջատել ալեհավաքը, բայց այս պարզ կիրառման համար մենք այն միացնում ենք մեկ անգամ, այնուհետև թողնում այն միացված:

· Մաքրել գաղտնագրման դրոշը (միայն 522). Երբ պիտակի իսկությունը հաստատվում է, դրոշը դրվում է ՝ օգտագործողին տեղեկացնելու համար, որ պիտակի հետ հաղորդակցությունները կոդավորված կլինեն: Այս դրոշը պետք է մաքրվի օգտվողի կողմից մինչև հաջորդ սկանավորումը, նույնիսկ եթե սկանավորվող պիտակը նույնն է:

· Որոնել պիտակի համար. Մոդուլը հիմնականում հարցնում է. «Որևէ մեկը կա՞ այնտեղ»: և պիտակը պատասխանում է «Ես այստեղ եմ»: Եթե մոդուլը արագ պատասխան չի ստանում, այն դադարում է լսել: Դա նշանակում է, որ մենք պետք է բազմիցս սկան հրամաններ ուղարկենք մոդուլին, մինչև այն չգտնի պիտակ:

· Ստացեք պիտակը Օգտվողի նույնականացման համարը (UID). Պիտակը կպատասխանի սկանավորման խնդրանքին որոշ սահմանափակ տեղեկություններով, ինչպիսիք են պիտակի տեսակը: Դա նշանակում է, որ մեզ կարող է անհրաժեշտ լինել ուղարկել մեկ այլ հրաման ՝ իր UID- ը ստանալու համար: UID- ը չորս բայթ է Mifare Classic 1k պիտակների համար: Եթե այլ պիտակների համար կարող է ավելի երկար լինել, բայց այս նախագիծը չի անդրադառնում դրանց:

· Ընտրեք պիտակը (միայն 522). UID- ն օգտագործվում է այն պիտակը ընտրելու համար, որը օգտագործողը ցանկանում է նույնականացնել կարդալու և գրելու համար: Սա հիմնված է այն հնարավորության վրա, որ ալեհավաքի դաշտում կարող է լինել մեկից ավելի պիտակ: Դա այդպես չէ մեր պարզ կիրառման համար, բայց ամեն դեպքում մենք պետք է ընտրենք պիտակը:

· Նույնականացրեք պիտակը. Այս քայլը պահանջվում է, եթե ցանկանում ենք կատարել պիտակի որևէ ընթերցում կամ գրել: Եթե այն ամենը, ինչ մենք ցանկանում ենք անել, տարբերել պիտակներն անվտանգության պարզ ծրագրի համար, ապա UID- ը բավական է: Նույնականացումը պահանջում է, որ մենք իմանանք UID- ը և իմանանք այն պիտակի տվյալների հատվածի գաղտնագրման բանալին, որին ցանկանում ենք մուտք գործել: Այս նախագծի համար մենք մնում ենք կանխադրված բանալիներին, բայց իմ հաջորդ նախագիծը փոխում է բանալիները, որպեսզի պիտակը կարող է օգտագործվել որպես էլեկտրոնային դրամապանակ:

· Կարդացեք կամ գրեք պիտակը. Ընթերցումները միշտ վերադարձնում են պահանջվող տվյալների բլոկի բոլոր 16 բայթերը: Գրելու համար պահանջվում է, որ բոլոր 16 բայթերը միաժամանակ գրվեն: Եթե ցանկանում եք կարդալ կամ գրել մեկ այլ բլոկ նույն տվյալների հատվածում, պիտակը կարիք չունի նորից վավերացնելու: Եթե ցանկանում եք բլոկ կարդալ կամ գրել տվյալների այլ հատվածում, ապա պիտակը պետք է նորից վավերացվի ՝ օգտագործելով այդ հատվածի բանալին:

Քայլ 5. MFRC522 Մոդուլի մուտքի հաջորդականություն

Գործարկման ռեժիմը ներառում է հետևյալ հիմնական քայլերը, որոնք հայտնաբերվել են իմ դիտած ծրագրերի մեծ մասում.

· Ուղարկեք տվյալների կեղծ բայթ (տե՛ս հաջորդ պարբերությունը)

· Փափուկ վերականգնում

· Սահմանել ՌԴ ստացողի շահույթը (եթե կանխադրվածից այլ բան է ցանկալի)

· ASK մոդուլյացիայի տոկոսադրույքը սահմանել 100%

· Սահմանեք սերմի արժեքը CRC հաշվարկների համար

· Միացրեք ալեհավաքը

· Ստացեք որոնվածի տարբերակ (պարտադիր չէ)

Չբացատրված պատճառով իմ մոդուլը ուժ է ստանում և կարծում է, որ ստացել է գրելու հրաման ՝ առանց տվյալների բայթերի: Ես չգիտեմ, արդյոք սա պարզապես իմ մոդուլի հետ կապված խնդիր է, բայց ես այլուր չեմ տեսել դրա վերաբերյալ հղումներ: Ես փորձարկեցի և՛ ապարատային, և՛ ծրագրային ապահովման վերագործարկումներ, և ոչ մեկը չլուծեց խնդիրը: Իմ լուծումը մոդուլի սկզբնավորման ռեժիմի սկզբում «0» (չսահմանված) գրանցելու համար կեղծ կարդալու զանգի ավելացումն էր: Եթե մոդուլը սա դիտում է որպես անհայտ գրելու հրամանի տվյալներ, չի երևում որևէ վատ ազդեցություն: Եթե այն ընկալում է որպես կարդալու հրաման, ապա ոչ մի օգտակար բան տեղի չի ունենում: Ինձ անհանգստացնում է, որ ես չեմ կարող ամբողջությամբ սահմանել հարցը, հատկապես հաշվի առնելով, որ միայն մոդուլի ապարատային վերականգնումը չի լուծում խնդիրը:

RC522 չիպը բաղկացած է մի շարք գրանցամատյաններից, որոնցից շատերը կարդալ և գրել են: Գրելու համար գրանցման համարը ուղարկվում է մոդուլ, որին հաջորդում է արժեքը գրելու համար: Ընթերցում կատարելու համար գրանցամատյանին ավելացված է 0x80 և այն ուղարկվում է մոդուլին: Գրելու հրամանի պատասխանը մուտքի գրանցման արձագանքն է: Կարդալու հրամանի պատասխանը գրանցամատյանի բովանդակությունն է: Theրագրակազմը օգտվում է այդ գիտելիքներից ՝ ստուգելու համար, որ հրամանը պատշաճ կատարված է:

Քայլ 6: PN532 Մոդուլի մուտքի հաջորդականություն

Գործարկման ռեժիմը ներառում է հետևյալ անհրաժեշտ քայլերը.

· Ուղարկեք նախաստորագրման տող. Սա հատուկ է UART ինտերֆեյսի համար: Ձեռնարկում նշվում է, որ UART ինտերֆեյսը կարթնանա ինտերֆեյսի վրա հայտնաբերված հինգերորդ բարձրացող եզրին: Այն խորհուրդ է տալիս ուղարկել 0x55, 0x55, 0x00, 0x00, 0x00, 0x00: Մեծ մասամբ, պարզապես պետք է լինեն բավարար թվով նիշեր ՝ բարձրացող եզրերով, և դրանք չպետք է նմանվեն հրամանի նախաբանի (00 00 FF):

· Արթնացեք մոդուլը. Օգտագործողի ձեռնարկում տեղադրված այն ցույց է տալիս, որ մոդուլը սկզբնավորվում է «LowVbat» կոչվող քնի վիճակի մեջ: Այս վիճակից դուրս գալու համար մենք պետք է ուղարկենք «SAMConfiguration» հրաման:

PN532- ն ակնկալում է, որ հրամանները կուղարկվեն սահմանված հաղորդագրության ձևաչափով, որը ներառում է նախաբան, հաղորդագրություն և հետամփոփ: Պատասխան հաղորդագրությունները հետևում են նույն ձևաչափին: Հրամանի և պատասխանի հաղորդագրությունները երկուսն էլ ներառում են TFI (շրջանակի նույնացուցիչ) և հրամանի տարբերակ: Հրամանը օգտագործում է 0xD4 TFI, իսկ պատասխանը `0xD5: Հրամանի տարբերակները տարբեր են, բայց պատասխանը միշտ կբարձրացնի հրամանի տարբերակը և այն կվերադարձնի բայթում ՝ TFI- ից հետո: Այդ հետևողականությունը թույլ է տալիս պատասխան հաղորդագրությունները հեշտությամբ սկանավորել համապատասխան տեղեկատվության համար:

Յուրաքանչյուր հրամանի հաղորդագրություն (նախաբանից հետո) բաղկացած է հաղորդագրության երկարությունից, հաղորդագրության երկարության 2 -ի լրացումից, TFI- ից, հրամանից, տվյալներից, ստուգիչ գումարից և հետբացականից: Theրագրակազմը կառուցում է անհատական հրամանները, այնուհետև կանչում է ռեժիմ, որը հաշվարկում է ստուգման գումարը և կցում է հետամփոփումը:

Պատասխանի համար հաղորդագրության ձևաչափը նման է հրամանին: Տիպիկ պատասխանը կներառի ACK (00 00 FF 00 FF 00), որին կհաջորդի հատուկ պատասխանը հրամանին: Յուրաքանչյուր հրամանի պատասխան սկսվում է 00 00 FF նախաբանից: Պատասխանը պետք է ունենա նաև D5- ի TFI բայթ, որին հաջորդում է հրամանի համարը `ավելացված 1 -ով: Մեր« SAMConfiguration »հրամանի (14) դեպքում դա կլինի 15:« SAMConfiguration »հրամանը ստանում է այս պատասխանը. 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00:

Կան մոդուլին հատուկ այլ հրամաններ, որոնք կարող են ուղարկվել, բայց դրանք անհրաժեշտ չեն այս հավելվածի համար: Այնուամենայնիվ, ես ներառեցի ռեժիմ, որը կարելի է անվանել որոնվածը տարբերակի համարը ստանալու համար: Տիպիկ պատասխանը (ACK- ից և նախաբանից հետո) կլինի `06 FA D5 03 32 01 06 07 E8 00:

Քայլ 7: Պիտակների մուտքի հաջորդականություն

Մոդուլի պատրաստվելուց հետո մենք կարող ենք ուղարկել պիտակներին հատուկ հրամաններ: Պիտակի տվյալները կարդալու կամ գրելու համար մենք պետք է ունենանք դրա նույնականացման համարը (UID): UID- ն ու բանալին այնուհետև կօգտագործվեն ընթերցման/գրելու համար որոշակի պիտակների տվյալների հատվածը թույլատրելու համար: Պիտակների տվյալները կարդալ/գրել միշտ կատարվում են նշված տվյալների բլոկի բոլոր 16 բայթերի վրա: Դա նշանակում է, որ տիպիկ ծրագիրը կկարդա տվյալների բլոկը, կփոխի տվյալները ըստ ցանկության և այնուհետև կգրի նոր տվյալները պիտակի վրա:

Քայլ 8: Softwareրագրակազմ

Ընդհատումների մշակման ծրագրակազմը կանչվում է ամեն անգամ, երբ PIC UART- ը ստանում է տվյալների բայթ: Իմ որոշ UART նախագծերում ես կարողացա պարզապես հարցումներ կատարել RX- ի ընդհատման դրոշի փոխարեն `ընդհատումների կարգավորիչ օգտագործելու փոխարեն: Այդպես չէ այս ծրագրաշարի համար, հատկապես PN532- ի համար, որը հաղորդակցվում է շատ ավելի բարձր արագությամբ, քան RC522- ը: RC522- ի UART ինտերֆեյսը սահմանափակված է 9600 baud- ով, մինչդեռ PN532- ի կանխադրվածը 115k է և կարող է սահմանվել մինչև 1.288M baud: Ստացված բայթերը պահվում են բուֆերային տարածքում և ծրագրաշարի հիմնական մասը դրանք վերցնում է ըստ անհրաժեշտության:

New_Msg դրոշը ցույց է տալիս, որ բայթերը ստացվել են, և Byte_Count- ը ցույց է տալիս, թե քանիսը: Theրագրի մեջ ներառել եմ «Disp_Buff» ռեժիմը, որը կարող է կանչվել ՝ կարգաբերման ընթացքում ընդունման բուֆերի բովանդակությունը ցուցադրելու համար: Հետադարձ հաղորդագրություններից մի քանիսը կհորդեն 1602 -ի տիպիկ էկրանին, բայց ես ունեմ 40 տող `2 տող LCD- ով, որը գտել եմ առցանց էլեկտրոնիկայի ավելցուկային կայքում: «Max_Line» սահմանումը կարող է սահմանվել ձեր LCD չափի համար: Եթե «Max_Line» - ը հասել է, «Disp_Buff» ռեժիմը շարունակվում է ՝ գրելով երկրորդ տողին: Դուք կարող եք մի փոքր կոդ ավելացնել այդ ռեժիմին ՝ երեք և չորս տողերի վրա շարունակելու համար, եթե ունեք 4 տող LCD: PN532- ի համար կա դրոշ, որը կարող է սահմանվել այնպես, որ առօրյան կամ թափի բոլոր ստացված բայթերը, կամ պարզապես դուրս գցի ընթերցված պատասխանի 16 տվյալների բայթերը:

Ստանալու բուֆերը կամ Byte_Count- ը մաքրելու կարիք չկա, քանի որ New_Msg դրոշը մաքրելը կհանգեցնի նրան, որ Byte_Count- ը կջնջվի ընդհատումների մշակողի կողմից, և դա այն է, ինչ օգտագործվում է որպես բուֆերի ինդեքս: New_Msg- ը սովորաբար մաքրվում է հրամանի յուրաքանչյուր քայլից առաջ, որպեսզի այդ հրամանին հատուկ արդյունքները հեշտությամբ տեղակայվեն և հաստատվեն: RC522- ում դա նշանակում է, որ ընդունման բուֆերը սովորաբար ունի ընդամենը 1 -ից 4 բայթ: Որոշ դեպքերում, ինչպիսիք են տվյալների բլոկի ընթերցումները, Read_FIFO հրամանը պետք է մի քանի անգամ տրվի, որպեսզի FIFO- ից բայթերը տեղափոխեն ստացման բուֆեր: PN532- ի հրամանի բոլոր արդյունքները հայտնվում են ստացման բուֆերում, ուստի սկանավորման ընթացակարգ է կատարվում անհրաժեշտ բայթերը գտնելու համար:

Theրագրաշարի հիմնական հանգույցը սկանավորում է պիտակը, այնուհետև նույնականացնում պիտակը կարդալու/գրելու համար: Այստեղ ներառված թեստային ծրագրաշարի համար Junk_Num փոփոխականն ամեն անգամ փոփոխվում է հիմնական հանգույցի միջոցով և օգտագործվում է պիտակին գրելու ժամանակ: Գրված արժեքները փոխարինվում են Junk_Num- ի արժեքի և Junk_Num- ի 1 -ի լրացման միջև: Ի վերջո, 16 գրված արժեքները կարդացվում և ցուցադրվում են: Կան ցուցադրվող հաղորդագրություններ յուրաքանչյուր քայլի համար `սովորական զանգերի հետաձգմամբ, որը հնարավորություն է տալիս ժամանակ կարդալ յուրաքանչյուր հաղորդագրություն: Սխալների հաղորդագրությունները նույնպես տրամադրվում են, բայց սովորաբար դրանք պետք է տեղի ունենան միայն այն դեպքում, երբ պիտակը հեռացվի գործողության ընթացքում:

Softwareրագրաշարի սկզբնավորման մի մասը կոդի մի հատված է, որը կատարվում է միայն միացման ժամանակ և բաց է թողնվում, եթե հայտնաբերվի ծրագրակազմի վերականգնում: Սխալների հաղորդագրություններն ընդհանրապես դադարում են ծրագրակազմի վերակայմամբ `որպես հիմնական հանգույցից դուրս գալու միջոց: Վերականգնումը տեղի է ունենում «Թեք» ռեժիմում, որը պարզապես հնարավորություն է տալիս Watchdog Timer- ին, այնուհետև անցնում անսահմանափակ հանգույց ՝ սպասելով ընդմիջմանը:

Քայլ 9. MFRC522 եզակի ծրագրակազմ

RC522 չիպը պահանջում է ավելի ցածր մակարդակի ցուցումներ, քան PN532 չիպը ՝ պիտակներով հաղորդակցություններ իրականացնելու համար: Դա նման է հավաքման լեզվով ծրագրավորմանը ՝ ընդդեմ «C» - ով ծրագրավորման: Մեկ այլ էական տարբերությունն այն է, որ RC522- ը պահանջում է, որ պիտակի հետ հաղորդակցությունները անցնեն FIFO բուֆերի միջոցով: «Write_FIFO» և «Read_FIFO» ռեժիմները կարգավորում են այդ խնդիրները: MFRC522 ծրագրակազմը ներառում է ստորին մակարդակի շատ հրամանների մի հատված, որից կառուցված են հիմնական գործառույթները:

RC522- ի համար պիտակի հրամանի ստուգման գումարի հաշվարկը շատ տարբեր է, քան PN532- ի համար: FIFO- ում պիտակի հրամանը կառուցելուց հետո ստուգման գումարը հաշվարկելու համար ուղարկվում է մոդուլի հրաման: 16-բիթանոց արդյունքն ինքնաբերաբար չի կցվում պիտակի հրամանին, այլ հասանելի է երկու 8-բիթանոց գրանցամատյաններից կարդալու համար: Չեկային գումարի հաշվարկը ջնջում է տվյալները FIFO- ում, այնպես որ պահանջվող հաջորդականությունը հետևյալն է.

· Կառուցեք հրամանը FIFO- ում

· Պատվիրեք ստուգիչ գումարի հաշվարկ

· Կրկին կառուցեք հրամանը FIFO- ում

· Կարդացեք CRC- ի գրանցամատյանները և գրեք ստուգաթերթի բայթերը FIFO- ին

· Ուղարկեք կամ Transceive կամ Authenticate հրաման

Transceive հրամանը կփոխանցի FIFO բուֆերը և այնուհետև ինքնաբերաբար կանցնի ստացման ռեժիմին ՝ սպասելու պիտակի պատասխանը: Տվյալների իրական փոխանցման համար Transceive հրամանին պետք է հաջորդի StartSend բիթը BitFramingRegister- ում: Նույնականացման հրամանը չունի այդ պահանջը:

Ընդհանուր առմամբ, Arduino «C» կոդային ծրագրերը, որոնք հասանելի են առցանց, օգտագործում են ընդհատումների դրոշմանիշների գրանցամատյանները և ժամանակի գրանցման գրանցամատյանը `ապահովելու համար, որ ճիշտ պատասխանը ստանա ժամանակին: Իմ կարծիքով, դա չափազանց շատ է այս ոչ ժամանակային կարևոր կիրառման համար: Փոխարենը, ես օգտագործում եմ ծրագրակազմի կարճ ընդմիջումներ `պատասխանին սպասելու համար, այնուհետև ստուգելու, որ այն ճիշտ է: Mifare պիտակների ձեռնարկը մանրամասնում է տարբեր գործարքների կատարման ժամկետները, ինչպես նաև թույլատրվում է ստանալ բայթերի ակնկալվող քանակը: Այս ժամանակային ուշացումները կառուցված են ցածր մակարդակի հրամանատարական ենթածրագրերի մեծ մասում:

Քայլ 10: PN532 եզակի ծրագրակազմ

Մոդուլի սկզբնականացումից հետո պիտակը գտնելու և նույնականացնելու համար անհրաժեշտ քայլերը կատարվում են `գրելով համապատասխան հրաման, որին հաջորդում են անհրաժեշտ տվյալները: Սկան հրամանը վերադարձնում է UID- ը, որն այնուհետև օգտագործվում է նույնականացման համար: Դրանից հետո, պիտակի կարդալն ու գրելն ուղարկել կամ վերադարձնել 16 բայթ հասցեագրված տվյալների բլոկի համար:

Նախաստորագրման հաջորդականությունը մանրամասն նկարագրվել էր ավելի վաղ, և նույն ծրագրակազմը նաև ուղարկում է SAMConfiguration հրամանը `մոդուլը« LowVbat »վիճակից դուրս բերելու համար: Մնացած հիմնական հրամանները, ինչպիսիք են ՝ Scan, Authenticate, Read/Write Tag, պարզապես հաջորդաբար կառուցված են կիրառվող առօրյայում: Ստուգման գումարը հաշվարկվում է ՝ պարզապես ավելացնելով հրամանի բայթերը, լրացնելով, այնուհետև ավելացնելով 1 ՝ այն դարձնելով 2 -ի լրացում: 8-բիթանոց արդյունքը կցվում է հրամանի տողին `փոստամբարից անմիջապես առաջ:

Չկա FIFO, ինչպես RC522- ում, այնպես որ պատասխանների ամբողջական հաղորդագրությունները ստացվում են ինքնաբերաբար: «Find_Response» ռեժիմը սկանավորում է ստացողի տվյալների բուֆերը TFI- ի համար (0xD5): Առօրյան օգտվում է այն գիտելիքից, թե ինչպիսին պետք է լինեն սպասվող հաղորդագրությունները և անտեսում է ACK- ի պարզ պատասխանները, որոնք չեն ներառում տվյալներ: Երբ TFI- ն գտնվի, ցանկալի պատասխանները հայտնի են դրա փոխհատուցմանը: Հրամանի արձագանքի և հրամանի կարգավիճակի բայթերը պահվում են «Read_Buff» ռեժիմի կողմից ՝ ավելի ուշ հաստատման համար:

Ահա այս գրառման համար: Ստուգեք իմ էլեկտրոնիկայի այլ նախագծերը ՝ www.boomerrules.wordpress.com