RC522 и PN532 Основи на RFID: 10 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:52

ЗАБЕЛЕЖКА: Сега имам инструкции, които предлагат код Arduino за RC522 и PN532.

Преди време си купих три различни RFID модула за експерименти. В предишен проект описах подробно как да използвам прост 125-kHz модул за извършване на основна функция за сигурност. Модули като този използват маркери само за четене, така че процесът се сканира за идентификационния номер, съхранява се по желание и се сравнява със съхраняваните идентификатори. Другите модули, които купих, работят на 13,56-MHz и използват тагове, които могат да се четат и пишат, така че е просто загуба просто да ги използвате за основна сигурност. Двата общи модула използват чип RC522 или чип PN532 - и двата са произведени от NXP.

Ако сте чели някой от другите ми проекти, знаете, че обичам да използвам евтини PIC микроконтролери и програми на асемблер. Така че това, което търсех, беше последователност от стъпки, необходими за разговор с модулите и с RFID таговете. Въпреки че има много примерни онлайн програми за модулите, повечето от тях са написани в софтуер „C“за Arduino и използват SPI интерфейса. Също така ръководствата за чиповете и за етикетите Mifare отнемат малко дешифриране. Тази публикация е предимно за информацията, която бих искал да имам, когато стартирах проекта. Включвам и софтуерни програми за монтаж на PIC за изпълнение на основните команди, необходими за всеки модул. Дори и да не използвате PIC и/или асемблерен език, изходният код трябва поне да ви даде добра представа за специфичните команди, необходими за изпълнение на всяка стъпка.

Стъпка 1: Серийни интерфейси

И двата чипа, използвани на тези модули, могат да се свързват чрез SPI, I2C или UART (HSSP). Модулът PN532 има DIP превключвател, който се използва за избор на желания интерфейс, но модулът MFRC522 е свързан хардуерно към SPI интерфейса. Предпочитам да използвам вградения UART на PIC, затова потърсих онлайн, за да видя дали има начин да вкарам модула MFRC522 в режим UART. Това, което открих, е, че изрязването на една следа на дъската ще свърши работа. Изрязването ефективно премахва 3,3 волта от EA щифта на чипа. Технически EA щифтът след това трябва да бъде свързан към земята, но не много хора могат да извадят този подвиг за запояване, като се има предвид плътността на щифта на чипа. Не се притеснявайте обаче, защото EA щифтът няма вътрешно издърпване и не „плава“, както правят старите TTL логически входове. Вижте диаграмата на чипа и снимката на раздела на дъската, за да изрежете мястото. Уверете се, че сте изрязали само късата следа директно към щифта на EA.

Стъпка 2: Хардуер

Хардуерните връзки за UART комуникации са показани на горната диаграма. UART връзките за MFRC522 не са маркирани на дъската, но, както е показано на схемата, SDA щифтът получава UART данни, а MISO пинът предава UART данни. Модулът PN532 има маркировката UART от долната страна на платката.

И двата модула работят на 3.3 волта и 5-волтовото логическо ниво от PIC TX щифта също трябва да бъде ограничено. LCD връзката е стандартната 4-битова настройка, използвана в редица мои предишни проекти. Форматът по подразбиране за всички съобщения е зададен за стандартния 1602 LCD (16 знака на 2 реда). Също така имам LCD дисплей с размер 40 символа на 2 реда, който използвам за изхвърляне на необработени данни по време на отстраняване на грешки, така че включих дефиниция в софтуера, която ми позволява да се възползвам от допълнителното пространство за показване.

Стъпка 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

· Включете антената

· Вземете версия на фърмуера (не се изисква)

По някаква необяснима причина моят модул се включва и смята, че е получил команда за запис без байт за данни. Не знам дали това е просто проблем с моя модул, но не съм виждал препратки към него другаде. Експериментирах както с хардуерни, така и със софтуерни нулировки и нито едно от тях не отстрани проблема. Моето решение беше да добавя фиктивно повикване за четене, за да регистрирам “0” (неопределено) в началото на рутината за инициализация на модула. Ако модулът вижда това като данни за неизвестната команда за запис, изглежда няма лоши ефекти. Ако го разглежда като команда за четене, нищо полезно не се случва. Притеснява ме, че не мога да дефинирам напълно проблема, особено като се има предвид, че хардуерното нулиране само на модула не решава проблема.

Чипът RC522 се състои от редица регистри, повечето от които се четат и записват. За да извършите запис, регистърният номер се изпраща към модула, последван от стойността за запис. За да се извърши четене, към регистрационния номер е добавен 0x80 и той се изпраща към модула. Отговорът на команда за запис е ехо от регистъра, до който се осъществява достъп. Отговорът на команда за четене е съдържанието на регистъра. Софтуерът се възползва от тези знания, за да провери дали командата е изпълнена правилно.

Стъпка 6: Последователност за достъп до модула PN532

Програмата за стартиране включва следните необходими стъпки:

· Изпращане на низ за инициализация: Това е специфично за интерфейса UART. Ръководството посочва, че интерфейсът на UART ще се събуди при петия нарастващ ръб, открит на интерфейса. Препоръчва изпращане на 0x55, 0x55, 0x00, 0x00, 0x00, 0x00. В по -голямата си част просто трябва да има достатъчен брой знаци с нарастващи ръбове и те не трябва да изглеждат като командна преамбюла (00 00 FF).

· Събудете модула: Погребан в ръководството за потребителя показва, че модулът се инициализира в нещо като спящо състояние, наречено “LowVbat”. За да излезем от това състояние, трябва да изпратим команда „SAMConfiguration“.

PN532 очаква команди да бъдат изпратени в определен формат на съобщението, който включва преамбюла, съобщението и пощенска графика. Съобщенията за отговор следват същия формат. Съобщенията за команда и отговор включват TFI (Frame Identifier) и версия на команда. Командата използва TFI от 0xD4, а отговорът използва 0xD5. Версиите на командите варират, но отговорът винаги ще увеличи версията на командата и ще я върне в байта след TFI. Тази последователност позволява съобщенията за отговор да бъдат лесно сканирани за съответната информация.

Всяко командно съобщение (след преамбюла) се състои от дължината на съобщението, допълненията на 2 от дължината на съобщението, 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.

Има и други команди, специфични за модула, които могат да бъдат изпратени, но те не са необходими за това приложение. Аз обаче включих рутина, която може да бъде извикана за извличане на номера на версията на фърмуера. Типичен отговор (след ACK и преамбюла) би бил: 06 FA D5 03 32 01 06 07 E8 00. „01 06 07“показва версия на фърмуера номер 1.6.7.

Стъпка 7: Последователност за достъп до маркери

След като модулът се подготви, можем да изпращаме команди, специфични за маркерите. За да четем или записваме данни за етикети, трябва да имаме идентификационния им номер (UID). UID и ключът след това ще се използват за оторизиране на конкретен сектор от данни за маркери за четене/запис. Четенето/записването на данни от маркери винаги се извършва на всички 16 байта в определен блок данни. Това означава, че типичното приложение ще прочете блока с данни, ще промени данните по желание и след това ще запише новите данни обратно в маркера.

Стъпка 8: Софтуер

Софтуерът за обработка на прекъсвания се извиква всеки път, когато PIC UART получи байт данни. В някои от предишните ми UART проекти успях просто да анкетирам флага за прекъсване на RX, вместо да се налага да използвам манипулатор на прекъсвания. Това не е така за този софтуер, особено за PN532, който комуникира с много по -висока скорост на предаване от RC522. UART интерфейсът на RC522 е ограничен до 9600 бода, докато по подразбиране за PN532 е 115k и може да бъде зададен до 1.288M бод. Получените байтове се съхраняват в буферна област и основната част от софтуера ги извлича според нуждите.

Флагът New_Msg показва, че са получени байтове, а Byte_Count показва колко. Включих процедура „Disp_Buff“в софтуера, която може да бъде извикана за показване на съдържанието на буфера за получаване по време на отстраняване на грешки. Някои от съобщенията за връщане ще препълнят типичен дисплей от 1602, но аз имам LCD дисплей с размер 40 символа по 2 реда, който намерих в онлайн сайт за електроника. Дефиницията „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 и допълването на 1 на Junk_Num. И накрая, 16 -те записани стойности се четат и показват. Има дисплейни съобщения за всяка стъпка с отлагане на рутинни повиквания, за да се даде време за четене на всяко съобщение. Съобщенията за грешки също се предоставят, но обикновено трябва да се появяват само ако етикетът е премахнат по време на операция.

Част от инициализацията на софтуера е част от код, който се изпълнява само при включване и се пропуска, ако бъде открито нулиране на софтуера. Съобщенията за грешки обикновено завършват със софтуерно нулиране като начин за излизане от главния цикъл. Нулирането се извършва в рутината „Tilt“, която просто активира Watchdog Timer и след това преминава в безкраен цикъл в очакване на таймаута.

Стъпка 9: Уникален софтуер на MFRC522

Чипът RC522 изисква повече инструкции на ниско ниво от чипа PN532 за осъществяване на комуникация с тагове. Това е нещо като програмиране на асемблерен език срещу програмиране в „C“. Друга съществена разлика е, че RC522 изисква комуникацията с маркера да се осъществява чрез FIFO буфер. Процедурите „Write_FIFO“и „Read_FIFO“се справят с тези задачи. Софтуерът MFRC522 включва раздел за много от командите от по-ниско ниво, от които са изградени основните функции.

Изчисляването на контролната сума на командата за етикет за RC522 е много различно от това за PN532. След като командата tag е вградена във FIFO, се изпраща команда на модул за изчисляване на контролната сума. 16-битовият резултат не се добавя автоматично към командата tag, но е достъпен за четене от два 8-битови регистри. Изчислението на контролната сума заличава данните във FIFO, така че необходимата последователност е следната:

· Изградете командата във FIFO

· Командирайте изчисление на контролна сума

· Изградете отново командата във FIFO

· Прочетете регистрите на CRC и запишете байтовете на контролната сума във FIFO

· Изпратете или команда Transceive или Authenticate

Командата Transceive ще предаде буфера FIFO и след това автоматично ще премине в режим на получаване, за да изчака отговора от маркера. Командата Transceive трябва да бъде последвана от настройката на бита StartSend в BitFramingRegister, за да се предават действително данните. Командата Authenticate няма това изискване.

Като цяло, кодовите приложения на 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