RC522 და PN532 RFID საფუძვლები: 10 ნაბიჯი

2024 ავტორი: John Day | [email protected]. ბოლოს შეცვლილი: 2024-01-30 10:18

შენიშვნა: მე ახლა მაქვს ინსტრუქცია, რომელიც გთავაზობთ Arduino კოდს RC522 და PN532.

რამდენიმე ხნის წინ შევიძინე სამი განსხვავებული RFID მოდული ექსპერიმენტისთვის. წინა პროექტში მე დეტალურად განვიხილე როგორ გამოვიყენო მარტივი 125-კჰც-იანი მოდული უსაფრთხოების ძირითადი ფუნქციის შესასრულებლად. მსგავსი მოდულები იყენებენ მხოლოდ წაკითხვის ტეგებს, ასე რომ პროცესი იდენტიფიცირდება პირადობის მოწმობაზე, ინახება სურვილისამებრ და შედარებულია შენახულ პირადობის მოწმობებთან. სხვა მოდულები, რომლებიც მე შევიძინე, ფუნქციონირებს 13.56-MHz და იყენებს ტეგებს, რომელთა წაკითხვაც და წერაც შესაძლებელია, ასე რომ, ეს არის უბრალოდ ნარჩენები მათი ძირითადი უსაფრთხოების უზრუნველსაყოფად. ორი საერთო მოდული იყენებს ან 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 pin– ზე.

ნაბიჯი 2: აპარატურა

UART კომუნიკაციის აპარატურის კავშირები ნაჩვენებია დიაგრამაში ზემოთ. MFRC522– ის UART კავშირები არ არის დატანილი დაფაზე, მაგრამ როგორც სქემატურადაა ნაჩვენები, SDA pin იღებს UART მონაცემებს და MISO pin გადასცემს UART მონაცემებს. PN532 მოდულს აქვს UART ნიშნები დაფის ქვედა მხარეს.

ორივე მოდული მუშაობს 3.3 ვოლტზე და 5 ვოლტიანი ლოგიკური დონე PIC TX პინიდან ასევე უნდა იყოს შეზღუდული. 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 მოდულის წვდომის თანმიმდევრობა

გაშვების რუტინა მოიცავს ამ ძირითად ნაბიჯებს, რომლებიც ნაპოვნია უმეტეს აპლიკაციებში:

· გამოგზავნეთ მონაცემების ბაიტი (იხილეთ შემდეგი პარაგრაფი)

· რბილი გადატვირთვა

· დააყენეთ RF მიმღების მომატება (თუ ნაგულისხმევის გარდა სხვა რამ არის სასურველი)

· დააყენეთ ASK მოდულაციის პროცენტი 100% -ზე

· დააყენეთ თესლის მნიშვნელობა CRC გამოთვლებისთვის

· ჩართეთ ანტენა

· მიიღეთ firmware ვერსია (არ არის საჭირო)

გაურკვეველი მიზეზის გამო, ჩემი მოდული ძალაში ჩნდება და ფიქრობს, რომ მან მიიღო ჩაწერის ბრძანება მონაცემთა ბაიტის გარეშე. არ ვიცი ეს მხოლოდ ჩემი მოდულის პრობლემაა, მაგრამ სხვაგან არ მინახავს მასზე მითითება. მე ექსპერიმენტი გავაკეთე როგორც აპარატურის, ასევე პროგრამული უზრუნველყოფის გადატვირთვაზე და არც პრობლემა გამოვასწორე. ჩემი გამოსავალი იყო მოდულის ინიციალიზაციის რუტინის დასაწყისში "0" (განუსაზღვრელი) რეგისტრაციისთვის დამატებული წაკითხული ზარის დამატება. თუ მოდული ხედავს ამას როგორც უცნობი ჩაწერის ბრძანების მონაცემები, არ ჩანს რაიმე ცუდი ეფექტი. თუ ის ხედავს წაკითხვის ბრძანებას, მაშინ სასარგებლო არაფერი ხდება. მე მაწუხებს, რომ მე არ შემიძლია საკითხის სრულად განსაზღვრა, განსაკუთრებით იმის გათვალისწინებით, რომ მხოლოდ მოდულის აპარატურის გადატვირთვა არ გადაჭრის პრობლემას.

RC522 ჩიპი შედგება მრავალი რეგისტრისგან, რომელთა უმეტესობა კითხულობს და წერს. ჩაწერის შესასრულებლად, რეგისტრაციის ნომერი იგზავნება მოდულში, რასაც მოჰყვება მნიშვნელობა ჩაწერისთვის. წაკითხვის შესასრულებლად, რეგისტრის ნომერს ემატება 0x80 და ეგზავნება მოდულს. ჩაწერის ბრძანებაზე პასუხი არის წვდომა რეგისტრის წვდომაზე. წაკითხვის ბრძანებაზე პასუხი არის რეესტრის შინაარსი. პროგრამული უზრუნველყოფა იყენებს ამ ცოდნას იმის დასადასტურებლად, რომ ბრძანება სწორად არის შესრულებული.

ნაბიჯი 6: PN532 მოდულის წვდომის თანმიმდევრობა

გაშვების რუტინა მოიცავს ამ აუცილებელ ნაბიჯებს:

· გაგზავნეთ ინიციალიზაციის სტრიქონი: ეს სპეციფიკურია UART ინტერფეისისთვის. სახელმძღვანელოში ნათქვამია, რომ UART ინტერფეისი გაიღვიძებს ინტერფეისზე გამოვლენილ მეხუთე მზარდ ზღვარზე. ის გირჩევთ გაგზავნას 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. უმეტესწილად, უბრალოდ უნდა იყოს საკმარისი რაოდენობის სიმბოლოები ამომავალი კიდეებით და ისინი არ უნდა გამოიყურებოდეს ბრძანების პრეამბულაზე (00 00 FF).

· გაიღვიძეთ მოდული: ჩაწერილი მომხმარებლის სახელმძღვანელოში ის აჩვენებს, რომ მოდული იწყებს ძილის ერთგვარ მდგომარეობას, სახელწოდებით "LowVbat". ამ მდგომარეობიდან გასასვლელად ჩვენ უნდა გამოგიგზავნოთ "SAMConfiguration" ბრძანება.

PN532 ელოდება ბრძანებების გაგზავნას განსაზღვრული შეტყობინების ფორმატში, რომელიც მოიცავს პრეამბულას, შეტყობინებას და პოსტამბულს. საპასუხო შეტყობინებები ერთი და იგივე ფორმატისაა. ბრძანებისა და პასუხის შეტყობინებები ორივე შეიცავს TFI (ჩარჩოს იდენტიფიკატორი) და ბრძანების ვერსიას. ბრძანება იყენებს 0xD4 TFI- ს, ხოლო პასუხი იყენებს 0xD5- ს. ბრძანების ვერსიები განსხვავდება, მაგრამ პასუხი ყოველთვის გაზრდის ბრძანების ვერსიას და დააბრუნებს მას ბაიტში TFI– ს შემდეგ. ეს თანმიმდევრულობა იძლევა საპასუხო შეტყობინებების ადვილად სკანირებას შესაბამისი ინფორმაციისათვის.

თითოეული ბრძანების შეტყობინება (წინასიტყვაობის შემდეგ) შედგება შეტყობინების სიგრძისგან, შეტყობინების სიგრძის მეორისგან, TFI- სგან, ბრძანებისაგან, მონაცემებისაგან, საკონტროლო ჯამიდან და პოსტამბლიდან. პროგრამული უზრუნველყოფა აყალიბებს ინდივიდუალურ ბრძანებებს და შემდეგ იძახებს რუტინას, რომელიც ითვლის შემოწმების ჯამს და ამატებს პოსტამბულს.

პასუხის გაგზავნის ფორმატი ბრძანების მსგავსია. ტიპიური პასუხი მოიცავს ACK (00 00 FF 00 FF 00), რასაც მოჰყვება კონკრეტული პასუხი ბრძანებაზე. თითოეული ბრძანების პასუხი იწყება 00 00 FF პრეამბულით. პასუხს ასევე უნდა ჰქონდეს TFI ბაიტი D5 რასაც მოჰყვება ბრძანების ნომერი გაზრდილი 1. ჩვენი "SAMConfiguration" ბრძანებისთვის (14) ეს იქნება 15. "SAMConfiguration" ბრძანება იღებს ამ პასუხს: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

არსებობს სხვა მოდულის სპეციფიკური ბრძანებები, რომელთა გაგზავნა შესაძლებელია, მაგრამ ისინი არ არის საჭირო ამ პროგრამისთვის. თუმცა, მე ჩავრთე რუტინა, რომელსაც შეიძლება დავარქვათ firmware ვერსიის ნომრის მოსაპოვებლად. ტიპიური პასუხი (ACK და პრეამბულის შემდეგ) იქნება: 06 FA D5 03 32 01 06 07 E8 00. "01 06 07" მიუთითებს firmware ვერსიის ნომერზე 1.6.7.

ნაბიჯი 7: წარწერის წვდომის თანმიმდევრობა

მას შემდეგ, რაც მოდული მზად იქნება, ჩვენ შეგვიძლია გამოგიგზავნოთ ბრძანებები ტეგებისთვის. იმისათვის, რომ წავიკითხოთ ან დავწეროთ ტეგის მონაცემები, ჩვენ გვჭირდება მისი საიდენტიფიკაციო ნომერი (UID). UID და გასაღები გამოყენებული იქნება წაკითხვის/წერის კონკრეტული ტეგი მონაცემების სექტორის ავტორიზაციისათვის. ტეგი მონაცემების წაკითხვა/წერა ყოველთვის კეთდება განსაზღვრულ მონაცემთა ბლოკში 16 -ე ბაიტზე. ეს ნიშნავს, რომ ტიპიური პროგრამა წაიკითხავს მონაცემთა ბლოკს, შეცვლის მონაცემებს სურვილისამებრ და შემდეგ ჩაწერს ახალ მონაცემებს ტეგზე.

ნაბიჯი 8: პროგრამული უზრუნველყოფა

შეწყვეტის დამმუშავებელი პროგრამული უზრუნველყოფა იძახება ყოველთვის, როდესაც PIC UART მიიღებს მონაცემთა ბაიტს. ზოგიერთ ჩემს წინა UART პროექტში მე შემეძლო უბრალოდ გამომეკითხა RX შეფერხების დროშა იმის ნაცვლად, რომ გამომეყენებინა შეფერხების დამმუშავებელი. ეს არ ეხება ამ პროგრამულ უზრუნველყოფას, განსაკუთრებით PN532– სთვის, რომელიც კომუნიკაციას ახდენს გაცილებით მაღალი სიჩქარით, ვიდრე RC522. RC522– ის UART ინტერფეისი შემოიფარგლება 9600 baud– ით, ხოლო PN532– ის ნაგულისხმევი არის 115k და მისი დაყენება შესაძლებელია 1.288M baud– მდე. მიღებული ბაიტები ინახება ბუფერულ ზონაში და პროგრამული უზრუნველყოფის ძირითადი ნაწილი იღებს მათ საჭიროებისამებრ.

New_Msg დროშა მიუთითებს, რომ ბაიტი მიღებულია და Byte_Count მიუთითებს რამდენზე. პროგრამულ უზრუნველყოფაში ჩავრთე „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– ის ყველა ბრძანების შედეგი მთავრდება მიმღების ბუფერში, ასე რომ სკანირების პროცედურა ტარდება საჭირო კონკრეტული ბაიტების მოსაძებნად.

პროგრამული უზრუნველყოფის მთავარი მარყუჟი იკვლევს ტეგს და შემდეგ ამოწმებს მას წაკითხვის/წერისთვის. აქ შემავალი სატესტო პროგრამისთვის ცვლადი Junk_Num იცვლება ყოველ ჯერზე ძირითადი მარყუჟის მეშვეობით და გამოიყენება ტეგზე ჩაწერის დროს. დაწერილი მნიშვნელობები მონაცვლეობს Junk_Num- ის მნიშვნელობასა და Junk_Num- ის 1 -ის დამატებას. დაბოლოს, 16 დაწერილი მნიშვნელობა იკითხება და გამოჩნდება. არსებობს შეტყობინებები თითოეული ნაბიჯისათვის რუტინული ზარების დაყოვნებით, რათა დრო დაეცეს თითოეული შეტყობინების წასაკითხად. შეცდომების შეტყობინებები ასევე მოცემულია, მაგრამ ჩვეულებრივ უნდა მოხდეს მხოლოდ იმ შემთხვევაში, თუ წარწერა ამოღებულია ოპერაციის დროს.

პროგრამული უზრუნველყოფის ინიციალიზაციის ნაწილი არის კოდის ის მონაკვეთი, რომელიც შესრულებულია მხოლოდ ჩართვისას და გამოტოვებულია პროგრამული უზრუნველყოფის გადატვირთვის გამოვლენის შემთხვევაში. შეცდომის შეტყობინებები მთავრდება პროგრამული უზრუნველყოფის გადატვირთვით, როგორც მთავარი მარყუჟის გასასვლელად. გადატვირთვა ხდება "დახრის" რუტინაში, რომელიც უბრალოდ საშუალებას აძლევს Watchdog Timer- ს და შემდეგ გადადის უსასრულო მარყუჟში, რომელიც ელოდება დროის გასვლას.

ნაბიჯი 9: უნიკალური პროგრამული უზრუნველყოფა MFRC522

RC522 ჩიპი ითხოვს უფრო დაბალ დონის ინსტრუქციას ვიდრე PN532 ჩიპი ტეგებთან კომუნიკაციის შესასრულებლად. ეს ჰგავს პროგრამირებას ასამბლეის ენაზე და პროგრამირებას "C" - ში. კიდევ ერთი მნიშვნელოვანი განსხვავება ისაა, რომ RC522 მოითხოვს, რომ ტეგთან კომუნიკაცია გადავიდეს FIFO ბუფერის საშუალებით. რუტინები "ჩაწერეთ_FIFO" და "წაიკითხეთ_ფიფო" ამ ამოცანებს უმკლავდება. MFRC522 პროგრამული უზრუნველყოფა შეიცავს განყოფილებას ქვედა დონის მრავალი ბრძანებისთვის, საიდანაც აგებულია ძირითადი ფუნქციები.

RC522 ტეგის ბრძანების შემოწმების ჯამი ძალიან განსხვავდება PN532– ისგან. მას შემდეგ, რაც tag ბრძანება აგებულია FIFO– ში, მოდულის ბრძანება იგზავნება შემოწმების ჯამის გამოსათვლელად. 16-ბიტიანი შედეგი ავტომატურად არ ერთვის ტეგის ბრძანებას, მაგრამ ხელმისაწვდომია ორი 8-ბიტიანი რეგისტრიდან წასაკითხად. შემოწმების ჯამური გაანგარიშება წაშლის მონაცემებს FIFO– ში, ასე რომ საჭირო თანმიმდევრობა ასეთია:

· შექმენით ბრძანება FIFO– ში

· ბრძანება checksum გაანგარიშება

· კვლავ შექმენით ბრძანება FIFO– ში

· წაიკითხეთ CRC რეგისტრები და ჩაწერეთ ჩეკის ბაიტი FIFO– ში

· გაგზავნეთ ან Transceive ან Authenticate ბრძანება

Transceive ბრძანება გადასცემს FIFO ბუფერს და შემდეგ ავტომატურად გადადის მიღების რეჟიმში დაელოდება პასუხს ტეგიდან. Transceive ბრძანებას უნდა მოყვეს BitFramingRegister– ში StartSend ბიტის დაყენება მონაცემების რეალურად გადასაცემად. Authenticate ბრძანებას არ აქვს ეს მოთხოვნა.

ზოგადად, Arduino "C" კოდის პროგრამები, რომლებიც ხელმისაწვდომია ინტერნეტით, იყენებს შეწყვეტის დროშის რეგისტრებს და დროის რეგისტრაციის რეგისტრს, რათა უზრუნველყოს სწორი პასუხის დროული მიღება. ჩემი აზრით, ეს ზედმეტია ამ არასამთავრობო კრიტიკული პროგრამისთვის. ამის ნაცვლად, მე ვიყენებ პროგრამული უზრუნველყოფის მოკლე ვადას, რომ დაველოდო პასუხს და შემდეგ შევამოწმო, რომ ის სწორია. Mifare ტეგების სახელმძღვანელო დეტალურადაა აღწერილი სხვადასხვა გარიგებების დრო და დრო ასევე ნებადართულია მოსალოდნელი რაოდენობის ბაიტების მისაღებად. ეს დროის შეფერხებები ჩამონტაჟებულია დაბალი დონის ბრძანების ქვეპროგრამების უმეტესობაში.

ნაბიჯი 10: PN532 უნიკალური პროგრამული უზრუნველყოფა

მოდულის ინიციალიზაციის შემდეგ, ტეგის საპოვნელად და ავთენტიფიკაციისთვის საჭირო ნაბიჯები სრულდება შესაბამისი ბრძანების დაწერის შემდეგ საჭირო მონაცემებით. სკანირების ბრძანება აბრუნებს UID რომელიც შემდეგ გამოიყენება ავტორიზაციისათვის. ამის შემდეგ, კითხულობს და წერს ტეგს, აგზავნის ან აბრუნებს 16 ბაიტს მიმართული მონაცემთა ბლოკისთვის.

ინიციალიზაციის თანმიმდევრობა ადრე იყო დეტალურად აღწერილი და იგივე პროგრამული უზრუნველყოფა ასევე აგზავნის SAMConfiguration ბრძანებას, რათა მოდული გამოვიდეს "LowVbat" მდგომარეობიდან. დანარჩენი ძირითადი ბრძანებები, როგორიცაა სკანირება, ავთენტიფიკაცია, წაკითხვა/ჩაწერის ტეგები, მხოლოდ თანმიმდევრულად არის აგებული მოქმედ რუტინაში. შემოწმების ჯამი გამოითვლება მხოლოდ ბრძანების ბაიტების დამატებით, შემავსებლის გაკეთებით და შემდეგ 1 -ის დამატებით, რომ ის გახდება 2 -ის შემავსებელი. 8-ბიტიანი შედეგი ემატება ბრძანების სტრიქონს, მხოლოდ პოსტამბლის წინ.

არ არსებობს FIFO, როგორც RC522, ასე რომ სრული საპასუხო შეტყობინებები მიიღება ავტომატურად. "Find_Response" რუტინული სკანირებას უკეთებს მონაცემების მიღებას TFI- სთვის (0xD5). რუტინა სარგებლობს იმის ცოდნით, თუ რა უნდა იყოს მოსალოდნელი შეტყობინებები და იგნორირებას უკეთებს ACK– ის მარტივ პასუხებს, რომლებიც არ შეიცავს მონაცემებს. მას შემდეგ რაც TFI მოიძებნება, სასურველი პასუხები მისგან კომპენსირებულია. ბრძანების ექო და ბრძანების სტატუსის ბაიტები ინახება "Read_Buff" რუტინით, მოგვიანებით გადამოწმებისთვის.

ეს არის ამ პოსტისთვის. გადახედეთ ჩემს სხვა ელექტრონიკურ პროექტებს: www.boomerrules.wordpress.com