אודות Zigbee EZSP UART

מחבר: TorchIoT BootCamp
קישור: https://zhuanlan.zhihu.com/p/339700391
מאת: קורה

1. מבוא

חברת Silicon Labs הציעה פתרון של Host+NCP לתכנון שערים של Zigbee. בארכיטקטורה זו, המארח יכול לתקשר עם ה-NCP דרך ממשק UART או SPI. לרוב, נעשה שימוש ב-UART מכיוון שהוא פשוט בהרבה מ-SPI.

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

חשוב להבין את פרוטוקול שער ה-UART לפני פיתוח תוכנית אירוח מותאמת אישית. הן עבור NCP מבוסס UART והן עבור NCP מבוסס SPI, המארח משתמש בפרוטוקול EZSP כדי לתקשר עם ה-NCP.EZSPקיצור שלפרוטוקול סריאלי של EmberZnet, והוא מוגדר בUG100עבור NCP מבוסס UART, פרוטוקול שכבה תחתונה מיושם כדי להעביר נתוני EZSP בצורה אמינה דרך UART, זהו ה-אֵפֶרפרוטוקול, קיצור שלמארח טורי אסינכרונילפרטים נוספים על ASH, אנא עיינו בUG101וUG115.

ניתן להמחיש את הקשר בין EZSP ל-ASH באמצעות התרשים הבא:

ניתן להמחיש את פורמט הנתונים של EZSP ופרוטוקול ASH באמצעות התרשים הבא:

בדף זה, נציג את תהליך מסגור נתוני ה-UART וכמה מסגרות מפתח (key frames) הנמצאות בשימוש תכוף בשער זיגבי.

2. מסגור

ניתן להמחיש את תהליך העיצוב הכללי באמצעות הטבלה הבאה:

בטבלה זו, הנתונים מתייחסים למסגרת EZSP. באופן כללי, תהליכי המסגור הם: |לא|שלב|התייחסות|

|:-|:-|:-|

|1|מלא את מסגרת EZSP|UG100|

|2|רנדומיזציה של נתונים|סעיף 4.3 של UG101|

|3|הוסף את בייט הבקרה|פרק 2 ופרק 3 של UG101|

|4|חשב את ה-CRC|סעיף 2.3 של UG101|

|5|מילוי בתים|סעיף 4.2 של UG101|

|6|הוסף את דגל הסיום|סעיף 2.4 של UG101|

2.1. מילוי מסגרת EZSP

פורמט המסגרת EZSP מודגם בפרק 3 של UG100.

שימו לב שפורמט זה עשוי להשתנות בעת שדרוג ערכת ה-SDK. כאשר הפורמט ישתנה, ניתן לו מספר גרסה חדש. מספר הגרסה העדכני ביותר של EZSP הוא 8 נכון לכתיבת מאמר זה (EmberZnet 6.8).

מכיוון שפורמט המסגרת של EZSP עשוי להיות שונה בין גרסאות שונות, קיימת דרישה מחייבת שהמארח וה-NCPחוֹבָהיעבדו עם אותה גרסת EZSP. אחרת, הם לא יוכלו לתקשר כצפוי.

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

הדרישה המשתמעת מאחורי זה היא שפורמט פקודת הגרסה יכוללעולם אל תשתנהפורמט הפקודה של גרסת EZSP הוא כדלקמן:

את ההסברים על שדה הפרמטר ופורמט תגובת הגרסה ניתן למצוא בפרק 4 של UG100. שדה הפרמטר הוא גרסת EZSP של תוכנית המארח. נכון לכתיבת מאמר זה, מדובר בגרסה 8.

מחבר: TorchIoTBootCamp
链接：https://zhuanlan.zhihu.com/p/339700391
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请泤昄凂

2.2. רנדומיזציה של נתונים

תהליך הרנדומיזציה המפורט מתואר בסעיף 4.3 של UG101. כל מסגרת ה-EZSP תעבור אקראי. הרנדומיזציה היא ל-Exclusive-OR (בלעדי - או - בלעדי - מסגרת ה-EZSP) ולרצף פסאודו-אקראי.

להלן האלגוריתם ליצירת רצף פסאודו-אקראי.

rand0 = 0×42
אם סיבית 0 של רנדי היא 0, רנדי+1 = רנדי >> 1
אם סיבית 0 של רנדי היא 1, רנדי+1 = (רנדי >> 1) ^ 0xB8

2.3. הוסף את בייט הבקרה

בייט הבקרה הוא נתונים של בייט אחד, ויש להוסיף אותו לראש המסגרת. הפורמט מודגם בטבלה שלהלן:

בסך הכל, ישנם 6 סוגים של בייט בקרה. שלושת הראשונים משמשים עבור מסגרות נפוצות עם נתוני EZSP, כולל DATA, ACK ו-NAK. שלושת האחרונים משמשים ללא נתוני EZSP נפוצים, כולל RST, RSTACK ו-ERROR.

הפורמט של RST, RSTACK ו-ERROR מתואר בסעיפים 3.1 עד 3.3.

2.4. חשב את ה-CRC

CRC של 16 סיביות מחושב על בתים מבית הבקרה ועד סוף הנתונים. CRCCCITT הסטנדרטי (g(x) = x16 + x12 + x5 + 1) מאותחל ל-0xFFFF. הבית המשמעותי ביותר קודם לבית המשמעותי ביותר (מצב big-endian).