אודות Zigbee EZSP UART

מחבר: TorchIoTBootCamp
קישור: https://zhuanlan.zhihu.com/p/339700391
מאת: Quora

1. הקדמה

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

Silicon Labs סיפקה גם פרויקט לדוגמה עבור התוכנית המארחת, שהיא המדגם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 וכמה מסגרות מפתח שנמצאות בשימוש תדיר בשער Zigbee.

2. מסגור

ניתן להמחיש את תהליך המסגור הכללי באמצעות התרשים הבא:

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

|:-|:-|:-|

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

|2|אקראיות של נתונים|סעיף 4.3 של UG101|

|3|הוסף את Byte Control|Chap2 ו-Chap3 של 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 ולרצף פסאודו אקראי.

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

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

2.3. הוסף את Byte Control

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

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

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

2.4. חשב את ה-CRC

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