Mga Pangunahing Kaalaman sa RC522 at PN532 RFID: 10 Mga Hakbang

2024 May -akda: John Day | [email protected]. Huling binago: 2024-01-30 13:13

TANDAAN: Mayroon na akong Mga Tagubilin na nag-aalok ng Arduino code para sa RC522 at PN532.

Ilang oras ang nakalipas bumili ako ng tatlong magkakaibang mga module ng RFID para sa pag-eksperimento. Sa isang nakaraang proyekto ay detalyado ko kung paano gumamit ng isang simpleng module na 125-kHz upang makagawa ng pangunahing pagpapaandar ng seguridad. Ang mga modyul na tulad nito ay gumagamit ng mga read-only na tag kaya ang proseso ay i-scan para sa ID, iimbak kung ninanais, at ihambing kumpara sa mga nakaimbak na ID. Ang iba pang mga modyul na binili ko ay nagpapatakbo sa 13.56-MHz at gumagamit ng mga tag na maaaring parehong mabasa at maisulat kaya't isang uri ng pag-aaksaya na gamitin lamang ang mga ito para sa pangunahing seguridad. Ang dalawang karaniwang mga module ay gumagamit ng alinman sa RC522 chip o ang PN532 chip - parehong ginawa ng NXP.

Kung nabasa mo ang alinman sa aking iba pang mga proyekto alam mo na nais kong gumamit ng murang mga microcontroller at programa ng PIC sa wika ng pagpupulong. Kaya't ang hinahanap ko ay isang pagkakasunud-sunod ng mga hakbang na kinakailangan upang makipag-usap sa mga module at sa mga RFID tag. Habang maraming halimbawa ng mga programa sa online para sa mga module, karamihan sa kanila ay nakasulat sa software na 'C' para sa Arduino at ginagamit ang interface ng SPI. Gayundin, ang mga manu-manong para sa mga chips at para sa mga Mifare tag tumagal ng kaunting pag-decipher. Ang post na ito ay pangunahing tungkol sa impormasyong nais kong magkaroon noong nagsimula ako sa proyekto. Nagsasama rin ako ng mga programa ng software ng pagpupulong ng PIC para sa pagganap ng mga pangunahing utos na kinakailangan ng bawat module. Kahit na hindi ka gumagamit ng isang PIC at / o wika ng pagpupulong, ang pinagmulang code ay dapat na magbigay sa iyo ng magandang ideya tungkol sa mga partikular na utos na kinakailangan upang maisagawa ang bawat hakbang.

Hakbang 1: Mga Serial Interface

Ang parehong mga chips na ginamit sa mga modyul na ito ay may kakayahang mag-interfacing sa pamamagitan ng SPI, I2C, o UART (HSSP). Ang module ng PN532 ay may switch na DIP na ginagamit upang piliin ang nais na interface ngunit ang MFRC522 module ay hardwired para sa interface ng SPI. Mas gusto kong gamitin ang built-in na UART ng PIC, kaya't nanghuli ako online upang makita kung mayroong isang paraan upang makuha ang MFRC522 module sa mode ng UART. Ang nalaman ko ay ang paggupit ng isang bakas sa pisara na gagawa ng trick. Epektibong inaalis ang hiwa ng 3.3 volts mula sa EA pin ng chip. Sa teknikal na paraan ang EA pin ay dapat na konektado sa lupa ngunit hindi maraming mga tao ang maaaring hilahin ang panghinang na gawa na ibinigay ang density ng chip pin. Gayunpaman, huwag magalala, dahil ang EA pin ay walang panloob na pull-up at hindi "lumutang" tulad ng ginagawa ng mga lumang input ng lohika ng TTL. Sumangguni sa diagram ng maliit na tilad at larawan ng seksyon ng board para sa hiwa ng puwesto. Siguraduhin na pinutol mo lamang ang maikling bakas na direkta sa EA pin.

Hakbang 2: Hardware

Ang mga koneksyon sa hardware para sa mga komunikasyon ng UART ay ipinapakita sa diagram sa itaas. Ang mga koneksyon sa UART para sa MFRC522 ay hindi minarkahan sa pisara ngunit, tulad ng ipinakita sa iskema, ang SDA pin ay tumatanggap ng data ng UART at ang MISO pin ay nagpapadala ng data ng UART. Ang module ng PN532 ay may mga marka ng UART sa ibabang bahagi ng pisara.

Ang parehong mga module ay tumatakbo sa 3.3 volts at ang antas ng 5-volt na lohika mula sa PIC TX pin ay kailangan ding limitahan. Ang koneksyon sa LCD ay ang karaniwang 4-bit na pag-setup na ginamit sa isang bilang ng aking nakaraang mga proyekto. Ang default na format para sa lahat ng mga mensahe ay itinakda para sa karaniwang 1602 LCD (16 na mga character sa pamamagitan ng 2 linya). Mayroon din akong 40 character by 2 line LCD na ginagamit ko para sa raw data dumps habang nagde-debug kaya't nagsama ako ng isang tukuyin sa software na pinapayagan akong samantalahin ang sobrang puwang sa pagpapakita.

Hakbang 3: Mga Pag-block ng Data

Ang Mifare Classic 1k na mga tag na ginamit para sa proyektong ito ay na-configure bilang 16 na sektor, apat na bloke ng data bawat sektor, 16 bytes bawat data block. Sa 64 bloke ng data, 47 lamang ang talagang magagamit. Naglalaman ang data block 0 ng data ng tagagawa at ang mga bloke na 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59, at 63 ay tinawag na mga Block Block. Ang mga bloke ng Trailer ay ang huli sa bawat sektor at naglalaman ang mga ito ng dalawang mga susi at ang mga block access bit. Nalalapat ang mga key at block access bit sa mga bloke ng data sa sektor na iyon upang magkaroon ka ng iba't ibang mga susi at mga panuntunan sa pag-access para sa bawat sektor. Ang mga default na key ay nakatakda sa "FF FF FF FF FFh". Para sa pangunahing proyekto na ito ay gumagamit ako ng isang data block at pinapanatili ang mga default na key at access bit. Maraming mga dokumento na nauugnay sa mga kard na ito kaya gumawa lamang ng isang online na paghahanap para sa "Mifare" o bisitahin ang website ng NXP kung nais mong tuklasin ang mga ito nang mas malalim.

Hakbang 4: Pangkalahatang Pagpapatakbo

Habang ang parehong mga module ay natatangi sa paraan ng pag-access ng mga ito at ang paraan ng pag-access sa mga tag, mayroong isang pangkalahatang proseso na kinakailangan upang matapos ang trabaho. Para sa proyektong ito ipinapalagay namin na ang mga tag ay ang Mifare Classic 1k uri at pinapayagan lamang namin ang isang tag nang paisa-isa sa patlang ng antena. Ang mga pangunahing hakbang ay tinukoy sa ibaba.

· Simulan ang modyul: Sa pangkalahatan ay nangangailangan ito ng mga bagay tulad ng mga halaga ng pagsulat upang magrehistro sa maliit na tilad, pagpapadala ng mga "paggising" na utos, at pag-on ng lakas sa antena. Sa isang application na pinapatakbo ng baterya nais mong ma-on at i-off ang lakas ng antena upang mai-save ang baterya ngunit para sa simpleng application na ito ay binuksan namin ito minsan at pagkatapos ay iwanan ito.

· I-clear ang watawat ng crypto (522 lamang): Kapag napatunayan ang isang tag, naitakda ang isang watawat upang ipaalam sa gumagamit na ang mga komunikasyon sa tag ay naka-encrypt. Ang watawat na ito ay kailangang i-clear ng gumagamit bago ang susunod na pag-scan, kahit na ang nai-scan na tag ay pareho.

· I-scan para sa isang tag: Karaniwang tinatanong ng modyul na "Mayroon bang ibang tao roon?" at ang tag ay tumutugon sa "Narito ako". Kung ang module ay hindi nakakakuha ng mabilis na tugon tumitigil ito sa pakikinig. Nangangahulugan iyon na kailangan naming paulit-ulit na magpadala ng mga utos ng pag-scan sa module hanggang sa makahanap ito ng isang tag.

· Kunin ang tag na User Identification number (UID): Tutugon ang tag sa kahilingan sa pag-scan na may ilang limitadong impormasyon tulad ng uri ng tag na ito. Nangangahulugan iyon na maaaring kailanganin naming magpadala ng isa pang utos upang makuha ang UID. Ang UID ay apat na byte para sa Mifare Classic 1k na mga tag. Kung maaaring mas mahaba para sa iba pang mga tag ngunit hindi matutugunan ng proyektong ito ang mga ito.

· Piliin ang tag (522 lamang): Ginagamit ang UID upang piliin ang tag na nais patunayan ng gumagamit para sa mga binabasa at sumusulat. Ito ay batay sa posibilidad na maaaring mayroong higit sa isang tag sa patlang ng antena. Hindi iyon ang kaso para sa aming simpleng application ngunit kailangan pa rin naming piliin ang tag.

· Patunayan ang tag: Kinakailangan ang hakbang na ito kung nais naming gumawa ng anumang pagbabasa o pagsusulat ng tag. Kung ang nais lamang nating gawin ay ang mag-iba-iba sa pagitan ng mga tag para sa isang simpleng aplikasyon sa seguridad pagkatapos ay sapat na ang UID. Kinakailangan ng pagpapatotoo na malaman namin ang UID at alam namin ang crypto key para sa sektor ng data ng tag na nais naming i-access. Para sa proyektong ito, nananatili kaming may mga default na key ngunit ang aking follow-on na proyekto ay binabago ang mga key upang ang tag ay maaaring magamit bilang isang electronic wallet.

· Basahin o isulat ang tag: Palaging binabalik ang lahat ng 16 byte ng hiniling na Data Block. Kinakailangan ng mga sulatin na ang lahat ng 16 byte ay maisulat nang sabay. Kung nais mong basahin o magsulat ng isa pang bloke sa parehong sektor ng data ang tag ay hindi kailangang patunayan muli. Kung nais mong basahin o magsulat ng isang bloke sa isang iba't ibang sektor ng data pagkatapos ang tag ay kailangang ma-authenticate muli gamit ang susi para sa sektor na iyon.

Hakbang 5: MFRC522 Pagsunod-sunod sa Pag-access ng Modyul

Kasama sa gawain sa pagsisimula ang mga pangunahing hakbang na matatagpuan sa karamihan ng mga application na tiningnan ko:

· Magpadala ng byte ng dummy data (tingnan ang susunod na talata)

· Soft reset

· Itakda ang nakuha ng RF receiver (kung ang isang bagay maliban sa default ay ninanais)

· Itakda ang porsyento ng modulate ng ASK sa 100%

· Itakda ang halaga ng binhi para sa mga kalkulasyon ng CRC

· I-on ang antena

· Kumuha ng bersyon ng firmware (hindi kinakailangan)

Para sa ilang mga hindi maipaliwanag na kadahilanan ang aking module ay nagpapatakbo ng lakas at iniisip na nakatanggap ito ng isang sumulat na utos nang walang byte ng data. Hindi ko alam kung isyu lamang ito sa aking module ngunit wala akong nakitang anumang mga sanggunian dito sa ibang lugar. Nag-eksperimento ako sa parehong pag-reset ng hardware at software at hindi ko naayos ang problema. Ang solusyon ko ay magdagdag ng isang nabasa na tawag na magparehistro ng "0" (hindi natukoy) sa pagsisimula ng gawain ng pagsisimula ng module. Kung nakikita ito ng module bilang data para sa hindi kilalang sumulat na utos, tila walang anumang masamang epekto. Kung nakikita ito bilang isang nabasa na utos, wala namang kapaki-pakinabang na nangyayari. Nakakaabala sa akin na hindi ko ganap na matukoy ang isyu, lalo na't ibinigay na ang pag-reset ng hardware ng module lamang ay hindi maaayos ang problema.

Ang RC522 chip ay binubuo ng isang bilang ng mga rehistro, na ang karamihan ay kapwa nabasa at nakasulat. Upang maisagawa ang isang sulatin, ang numero ng rehistro ay ipinapadala sa module na sinusundan ng halagang naisusulat. Upang maisagawa ang isang nabasa, ang numero ng rehistro ay may idinagdag na 0x80 dito at naipadala sa modyul. Ang tugon sa isang sumulat na utos ay isang echo ng rehistro na na-access. Ang tugon sa isang nabasa na utos ay ang mga nilalaman ng rehistro. Sinasamantala ng software ang kaalamang iyon upang mapatunayan na ang utos ay naipatupad nang maayos.

Hakbang 6: Sequence ng Pag-access ng Module ng PN532

Kasama sa gawain sa pagsisimula ang mga kinakailangang hakbang na ito:

· Magpadala ng isang string ng pagsisimula: Ito ay tiyak sa interface ng UART. Ang manwal ay nagsasaad na ang interface ng UART ay gigising sa ikalimang tumataas na gilid na nakita sa interface. Inirekumenda nito ang pagpapadala ng 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. Para sa pinaka-bahagi, kailangan lamang na magkaroon ng isang sapat na bilang ng mga character na may tumataas na mga gilid at hindi sila dapat magmukhang isang paunang utos (00 00 FF).

· Gisingin ang modyul: Inilibing sa manwal ng gumagamit ipinapakita nito na ang module ay nagpapasimula sa isang uri ng estado ng pagtulog na tinatawag na "LowVbat". Upang lumabas sa estado na ito kailangan naming magpadala ng isang "SAMConfiguration" na utos.

Inaasahan ng PN532 na ipapadala ang mga utos sa isang tinukoy na format ng mensahe na may kasamang isang paunang salita, mensahe, at isang postamble. Ang mga mensahe ng tugon ay sumusunod sa parehong format. Ang mga mensahe ng utos at tugon ay parehong nagsasama ng isang TFI (Frame Identifier) at isang bersyon ng utos. Gumagamit ang utos ng isang TFI ng 0xD4 at ang tugon ay gumagamit ng 0xD5. Ang mga bersyon ng utos ay nag-iiba ngunit ang tugon ay palaging magpapalaki ng bersyon ng utos at ibalik ito sa byte na sumusunod sa TFI. Pinapayagan ng pagkakapare-pareho na iyon para sa mga mensahe ng tugon na madaling ma-scan para sa nauugnay na impormasyon.

Ang bawat mensahe ng utos (pagsunod sa paunang salita) ay binubuo ng haba ng mensahe, pandagdag ng 2 sa haba ng mensahe, TFI, utos, data, checkum, at postamble. Binubuo ng software ang mga indibidwal na utos at pagkatapos ay tumatawag ng isang gawain na kinakalkula ang checkum at ikinakabit ang postamble.

Ang format ng mensahe para sa tugon ay katulad ng utos. Ang isang tipikal na tugon ay magsasama ng isang ACK (00 00 FF 00 FF 00) na susundan ng tukoy na tugon sa utos. Ang bawat tugon sa utos ay nagsisimula sa paunang salita na 00 00 FF. Ang tugon ay dapat ding magkaroon ng TFI byte ng D5 na sinusundan ng numero ng utos na nadagdagan ng 1. Para sa aming utos na "SAMConfiguration" (14) na magiging 15. Ang utos na "SAMConfiguration" ay nakakakuha ng tugon na ito: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Mayroong iba pang mga utos na tukoy sa modyul na maaaring maipadala ngunit hindi kinakailangan ang mga ito para sa application na ito. Gayunpaman, nagsama ako ng isang gawain na maaaring tawagan upang makuha ang numero ng bersyon ng firmware. Isang tipikal na tugon (pagkatapos ng ACK at paunang salita) ay: 06 FA D5 03 32 01 06 07 E8 00. Ang "01 06 07" ay nagpapahiwatig ng bersyon ng bersyon ng firmware na 1.6.7.

Hakbang 7: Sequence ng Pag-access sa Tag

Matapos maghanda ang module, maaari kaming magpadala ng mga utos na tukoy sa mga tag. Upang mabasa o sumulat ng data ng tag kailangan nating magkaroon ng numero ng pagkakakilanlan (UID). Ang UID at susi ay gagamitin upang pahintulutan ang isang tukoy na sektor ng data ng tag para sa mga nagbabasa / sumusulat. Ang data ng tag na bumabasa / nagsusulat ay laging ginagawa sa lahat ng 16 byte sa isang tinukoy na bloke ng data. Nangangahulugan iyon na basahin ng tipikal na application ang bloke ng data, baguhin ang data ayon sa ninanais, at pagkatapos ay isulat ang bagong data pabalik sa tag.

Hakbang 8: Software

Ang interrupt handler software ay tinatawag na tuwing makakatanggap ang PIC UART ng isang byte ng data. Sa ilan sa aking nakaraang mga proyekto sa UART nagawa kong i-poll ang RX makagambala bandila sa halip na gumamit ng isang makagambala na handler. Hindi iyon ang kaso para sa software na ito, lalo na para sa PN532 na nakikipag-usap sa mas mataas na rate ng baud kaysa sa RC522. Ang interface ng UART ng RC522 ay limitado sa 9600 baud habang ang default para sa PN532 ay 115k at maaaring itakda kasing taas ng 1.288M baud. Ang mga natanggap na byte ay nakaimbak sa isang lugar ng buffer at ang pangunahing bahagi ng software ay kinukuha ang mga ito kung kinakailangan.

Ipinapahiwatig ng watawat ng New_Msg na natanggap ang mga byte at isinasaad ng Byte_Count kung ilan. Nagsama ako ng isang "Disp_Buff" na gawain sa software na maaaring tawagan upang ipakita ang mga nilalaman ng natanggap na buffer habang nagde-debug. Ang ilan sa mga mensahe sa pagbabalik ay mag-aapaw sa isang tipikal na 1602 display ngunit mayroon akong 40 character by 2 line LCD na nakita ko sa isang online surplus electronics site. Ang "Max_Line" na tinukoy ay maaaring itakda para sa iyong laki ng LCD. Kung naabot ang "Max_Line", ang gawain na "Disp_Buff" ay nagpapatuloy sa pamamagitan ng pagsulat sa pangalawang linya. Maaari kang magdagdag ng isang maliit na code sa na gawain upang magpatuloy sa mga linya ng tatlo at apat kung mayroon kang isang 4-line LCD. Para sa PN532 mayroong isang watawat na maaaring maitakda upang ang gawain sa alinman sa pagtatapon ng lahat ng natanggap na byte o pagtatapon lamang ng 16 data bytes mula sa isang nabasa na tugon.

Hindi kailangang ma-clear ang natanggap na buffer o Byte_Count dahil ang pag-clear sa New_Msg flag ay magiging sanhi ng Byte_Count na ma-clear ng interrupt handler at iyon ang ginagamit bilang index sa buffer. Kadalasan nai-clear ang New_Msg bago ang bawat hakbang sa pag-utos upang ang mga resulta na partikular sa utos na iyon ay madaling matatagpuan at ma-verify. Sa RC522 nangangahulugan iyon na ang tumatanggap na buffer ay karaniwang may 1 hanggang 4 na mga byte lamang. Sa ilang mga kaso, tulad ng pagbasa ng block ng data, ang utos na Read_FIFO ay dapat na ipalabas ng maraming beses upang ilipat ang mga byte mula sa FIFO patungo sa natanggap na buffer. Ang lahat ng mga resulta ng utos para sa PN532 ay nagtatapos sa pagtanggap ng buffer kaya't isinasagawa ang isang pamamaraan sa pag-scan upang hanapin ang mga tukoy na byte na kinakailangan.

Ang pangunahing loop sa software ay ini-scan para sa isang tag at pagkatapos ay napatunayan ang tag para sa mga bumabasa / sumusulat. Para sa pagsubok na software na kasama dito ang variable na Junk_Num ay binago sa bawat oras sa pamamagitan ng pangunahing loop at ginagamit sa pagsulat sa tag. Ang mga halagang nakasulat na kahalili sa pagitan ng halaga ng Junk_Num at ang pang-1 na kompleto ng Junk_Num. Panghuli, ang 16 na nakasulat na halaga ay nabasa at ipinapakita. Mayroong mga display message para sa bawat hakbang na may pagkaantala ng mga regular na tawag upang bigyan ng oras na mabasa ang bawat mensahe. Ibinibigay din ang mga mensahe ng error ngunit dapat na normal lamang maganap kung ang tag ay tinanggal sa panahon ng isang operasyon.

Ang bahagi ng pagsisimula ng software ay isang seksyon ng code na naisasagawa lamang sa power up at lalaktawan kung nakita ang isang pag-reset ng software. Ang mga mensahe ng error sa pangkalahatan ay natapos na may isang pag-reset ng software bilang isang paraan upang lumabas sa pangunahing loop. Nangyayari ang pag-reset sa "Tilt" na gawain na simpleng nagbibigay-daan sa Watchdog Timer at pagkatapos ay papunta sa isang walang katapusang loop na naghihintay para sa timeout.

Hakbang 9: Natatanging Software ng MFRC522

Ang RC522 chip ay nangangailangan ng mas maraming mga tagubilin sa mababang antas kaysa sa PN532 chip upang makamit ang mga komunikasyon sa mga tag. Ito ay tulad ng pagprogram sa wika ng pagpupulong kumpara sa pagprogram sa "C". Ang isa pang makabuluhang pagkakaiba ay ang RC522 na hinihiling na ang mga komunikasyon sa tag ay pinapalabas sa pamamagitan ng isang FIFO buffer. Ang mga gawain na "Sumulat_FIFO" at "Basahin_FIFO" ang humahawak sa mga gawaing iyon. Ang software na MFRC522 ay nagsasama ng isang seksyon para sa marami sa mga mas mababang antas na utos na kung saan binuo ang mga pangunahing pag-andar.

Ang pagkalkula ng tag command checkum para sa RC522 ay ibang-iba kaysa sa PN532. Matapos mabuo ang tag utos sa FIFO, isang utos ng modyul ang ipinadala upang kalkulahin ang Checkum. Ang resulta na 16-bit ay hindi awtomatikong idinaragdag sa utos ng tag ngunit magagamit para sa pagbabasa mula sa dalawang 8-bit na rehistro. Ang pagkalkula ng tsekum ay binubura ang data sa FIFO kaya ang kinakailangang pagkakasunud-sunod ay ang mga sumusunod:

· Buuin ang utos sa FIFO

· Mag-utos ng isang pagkalkula ng tsekum

· Buuin muli ang utos sa FIFO

· Basahin ang mga rehistro ng CRC at isulat ang mga byteum ng tsekum sa FIFO

· Magpadala ng alinman sa isang utos na Transceive o Pagpapatotoo

Ipapadala ng utos ng Transceive ang buffer ng FIFO at pagkatapos ay awtomatikong lumipat upang makatanggap ng mode upang maghintay para sa tugon mula sa tag. Ang utos na Transceive ay dapat na sundin ng setting ng StartSend bit sa BitFramingRegister upang maipadala talaga ang data. Walang utos na iyon ng utos na Authenticate.

Sa pangkalahatan, ang mga aplikasyon ng code ng Arduino "C" na magagamit sa online ay gumagamit ng nakakagambala na mga rehistro ng watawat at ang pagrehistro ng timeout upang matiyak na ang tamang tugon ay matatanggap sa isang napapanahong paraan. Sa palagay ko ay labis na paggamit para sa hindi pang-oras na kritikal na application na ito. Sa halip, gumagamit ako ng maikling timeout ng software upang maghintay para sa tugon at pagkatapos ay i-verify na ito ay tama. Ang manu-manong para sa mga tag ng Mifare ay nagdedetalye sa tiyempo para sa iba't ibang mga transaksyon at pinapayagan din ang oras para sa inaasahang bilang ng mga byte na matatanggap. Ang mga pagkaantala ng oras na ito ay binuo sa karamihan ng mga mababang antas ng utos na subroutine.

Hakbang 10: Natatanging Software ng PN532

Matapos maisimula ang modyul, ang mga hakbang na kinakailangan upang hanapin at mapatunayan ang tag ay magagawa sa pamamagitan ng pagsulat ng naaangkop na utos na sinusundan ng kinakailangang data. Ibinabalik ng utos ng pag-scan ang UID na pagkatapos ay ginagamit para sa pagpapatotoo. Pagkatapos nito, basahin at isulat ang tag na ipadala o ibalik ang 16-bytes para sa naka-address na block ng data.

Ang pagkakasunud-sunod ng pagkakasunud-sunod ay detalyado nang mas maaga at ang parehong gawain ng software ay nagpapadala din ng utos na SAMConfiguration upang makuha ang module sa estado na "LowVbat". Ang natitirang mga pangunahing utos, tulad ng Scan, Pagpapatotoo, Basahin / Isulat ang Tag, ay binuo nang sunud-sunod sa mga naaangkop na gawain. Ang checkum ay kinakalkula sa pamamagitan lamang ng pagdaragdag ng mga byte ng utos, paggawa ng isang pandagdag, at pagkatapos ay pagdaragdag ng 1 upang gawin itong pandagdag ng 2. Ang 8-bit na resulta ay naidugtong sa command string bago ang postamble.

Walang FIFO tulad sa RC522 kaya awtomatikong natatanggap ang kumpletong mga mensahe sa pagtugon. Ang routine na "Find_Response" ay nag-scan ng makatanggap ng buffer ng data para sa TFI (0xD5). Sinasamantala ng gawain ang pag-alam kung ano ang dapat na mga inaasahang mensahe at hindi pinapansin ang simpleng mga tugon sa ACK na hindi kasama ang data. Kapag natagpuan ang TFI, ang mga nais na tugon ay isang kilalang offset mula rito. Ang byte ng command echo at command status ay nai-save ng "Read_Buff" na gawain para sa pag-verify sa paglaon.

Iyon lang para sa post na ito. Suriin ang aking iba pang mga proyekto sa electronics sa: www.boomerrules.wordpress.com