יסודות RFID RC522 ו- PN532: 10 שלבים

2024 מְחַבֵּר: John Day | [email protected]. שונה לאחרונה: 2024-01-30 09:15

הערה: יש לי כעת הוראות המציעות קוד Arduino עבור RC522 ו- PN532.

לפני זמן מה קניתי שלושה מודולי RFID שונים להתנסות. בפרויקט קודם פירטתי כיצד להשתמש במודול פשוט של 125 קילוהרץ לביצוע פונקציית אבטחה בסיסית. מודולים כאלה משתמשים בתגים לקריאה בלבד, כך שהתהליך סורק אחר המזהה, שומר אם תרצה והשווה מול מזהים מאוחסנים. המודולים האחרים שקניתי פועלים במהירות של 13.56 מגה-הרץ ומשתמשים בתגים שניתן לקרוא ולכתוב, כך שזה פשוט בזבוז פשוט להשתמש בהם לאבטחה בסיסית. שני המודולים הנפוצים משתמשים בשבב 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". כדי לצאת ממצב זה עלינו לשלוח פקודה "תצורה SAMC".

ה- 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 interrupt במקום להשתמש במטפל להפריע. זה לא המקרה של תוכנה זו, במיוחד עבור PN532 המתקשר בקצב שידור גבוה בהרבה מזה של RC522. ממשק UART של RC522 מוגבל ל -9600 באוד בעוד ברירת המחדל עבור PN532 היא 115k וניתן להגדיר אותו עד 1.288M baud. הבייטים שהתקבלו מאוחסנים באזור חיץ והחלק העיקרי של התוכנה מאחזר אותם לפי הצורך.

הדגל New_Msg מציין שקיבלו בתים ו- Byte_Count מציין כמה. כללתי שגרה של "Disp_Buff" בתוכנה שאפשר לקרוא לה להציג את תוכן מאגר הקבלה במהלך איתור באגים. חלק מהודעות ההחזרה יציפו תצוגה טיפוסית של 1602 אבל יש לי LCD בגודל 40 תווים על 2 שורות שמצאתי באתר עודף אלקטרוניקה מקוון. ניתן להגדיר את הגדרת "Max_Line" לגודל ה- LCD שלך. אם מגיעים ל- "Max_Line", שגרת "Disp_Buff" ממשיכה בכתיבה לשורה השנייה. תוכל להוסיף קוד קטן לשגרה זו כדי להמשיך לשורות שלוש וארבע אם יש לך מסך LCD בן 4 שורות. עבור 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 הערכים הכתובים נקראים ומוצגים. ישנן הודעות תצוגה לכל שלב עם שיחות עיכוב שגרתיות כדי לאפשר זמן לקרוא כל הודעה. מסופקות גם הודעות שגיאה אך בדרך כלל הן אמורות להתרחש רק אם תג מוסר במהלך פעולה.

חלק מאתחול התוכנה הוא קטע קוד המבוצע רק בעת ההפעלה ודלג עליו אם מתגלה איפוס תוכנה. הודעות השגיאה מסתיימות בדרך כלל עם איפוס תוכנה כדרך ליציאה מהלולאה הראשית. האיפוס מתרחש בשגרת "הטיה" המאפשרת פשוט את טיימר כלב השמירה ואז נכנסת ללולאה אינסופית שמחכה לפסק הזמן.

שלב 9: תוכנה ייחודית MFRC522

שבב RC522 דורש הוראות ברמה נמוכה יותר מאשר שבב PN532 כדי לבצע תקשורת עם תגים. זה בערך כמו תכנות בשפת הרכבה לעומת תכנות ב- "C". הבדל משמעותי נוסף הוא שה- RC522 דורש שהתקשורת עם התג תועבר דרך מאגר FIFO. השגרות "Write_FIFO" ו- "Read_FIFO" מטפלות במשימות אלה. תוכנת MFRC522 כוללת קטע עבור רבות מהפקודות ברמה נמוכה יותר מהן בנויות הפונקציות העיקריות.

חישוב סכום הביקורת של תג הפקודה עבור RC522 שונה מאוד מזה של PN532. לאחר בניית הפקודה tag ב- FIFO, נשלחת פקודת מודול לחישוב סכום הביקורת. התוצאה של 16 סיביות אינה מצורפת אוטומטית לפקודת התגית אך זמינה לקריאה משני רגיסטרים של 8 סיביות. חישוב סכום הביקורת מוחק את הנתונים ב- FIFO כך שהרצף הנדרש הוא כדלקמן:

· בנה את הפקודה ב- FIFO

· פיקוד על חישוב סכום הביקורת

· בנה את הפקודה ב- FIFO שוב

· קרא את רשומות ה- CRC וכתוב את תאי סכום הביקורת ל- FIFO

· שלח פקודה Transceive או Authenticate

הפקודה Transceive תשדר את מאגר ה- FIFO ולאחר מכן תעבור אוטומטית למצב קבלה כדי לחכות לתגובה מהתג. את הפקודה Transceive חייבת להיות ההגדרה של ביט StartSend ב- BitFramingRegister על מנת לשדר את הנתונים בפועל. לפקודה Authenticate אין דרישה זו.

באופן כללי, יישומי קוד ה- "C" של Arduino הזמינים באינטרנט משתמשים ברשומות הדגל להפריע וברישום הזמן הקצוב כדי להבטיח שהתגובה הנכונה תתקבל בזמן. לדעתי זה מוגזם ליישום קריטי לא-זמן זה. במקום זאת, אני משתמש בפסק זמן קצר של תוכנה כדי לחכות לתגובה ולאחר מכן לוודא שהיא נכונה. המדריך לתגי Mifare מפרט את התזמון של העסקאות השונות והזמן מותר גם לקבלת מספר הבייטים הצפוי. עיכובים בזמן זה מובנים ברוב תת שורות הפקודה ברמה נמוכה.

שלב 10: תוכנה ייחודית PN532

לאחר אתחול המודול, השלבים הנדרשים לאיתור והתג האימות מתבצעים על ידי כתיבת הפקודה המתאימה ואחריה הנתונים הדרושים. פקודת הסריקה מחזירה את ה- UID המשמש לאחר מכן לאימות. לאחר מכן, קורא וכותב את התג שלח או החזר את 16 הבייטים עבור בלוק הנתונים המופנה.

רצף האתחול פורט קודם לכן ואותה שגרת תוכנה שולחת גם את הפקודה SAMConfiguration כדי להוציא את המודול ממצב "LowVbat". שאר הפקודות הבסיסיות, כגון סריקה, אימות, קריאה/כתיבה, נבנות רק ברצף בשגרות החלות. סכום הביקורת מחושב רק על ידי הוספת בתאי הפקודה, השלמת השלמה ולאחר מכן הוספת 1 כדי להפוך אותו למשלים 2. התוצאה של 8 סיביות מצורפת למחרוזת הפקודה ממש לפני ההדפסה.

אין FIFO כמו ב- RC522 כך שהודעות התשובה המלאות מתקבלות באופן אוטומטי. שגרת "Find_Response" סורקת את מאגר נתוני הקבלה עבור ה- TFI (0xD5). השגרה מנצלת את הידיעה מה צריכים להיות ההודעות הצפויות ומתעלמת מתגובות ACK פשוטות שאינן כוללות נתונים. לאחר שנמצא ה- TFI, התגובות הרצויות הן קיזוז ידוע ממנו. הד הפקודה ובתי סטטוס הפקודה נשמרים על ידי שגרת "Read_Buff" לאימות מאוחר יותר.

זהו הפוסט הזה. בדוק את פרויקטי האלקטרוניקה האחרים שלי בכתובת: www.boomerrules.wordpress.com