OpenThread הוא פרוטוקול שאינו תלוי בפלטפורמה ובמערכת הפעלה, עם שכבת הפשטה צרה של פלטפורמה (PAL). ב-PAL הזה מוגדרים:
- ממשק התראה לטיימר שפועל ללא הגבלת זמן עם התראה
- ממשקי באס (UART, SPI) לתקשורת של הודעות CLI ו-Spinel
- ממשק רדיו לתקשורת IEEE 802.15.4-2006
- תוכניות ברירת המחדל ל-GCC
- אנטרופיה ליצירת מספרים אקראיים אמיתיים
- שירות הגדרות לאחסון תצורה לא נדיף
- ממשק ליומן לצורך שליחת הודעות ביומן של OpenThread
- תוכניות אתחול ספציפיות למערכת
כל ממשקי ה-API צריכים להיות מוטמעים על סמך חבילת התמיכה (BSP) של שכבת ההפשטה של החומרה (HAL).
קובצי ה-API צריכים להיות ממוקמים בספריות הבאות:
| סוג | ספרייה |
|---|---|
| הטמעת PAL ספציפית לפלטפורמה | /openthread/examples/platforms/platform-name |
| קובצי כותרת – API לאחסון לא נדיף | /openthread/examples/platforms/utils |
| כל שאר קובצי הכותרות | /openthread/include/openthread/platform |
| HAL BSP | /openthread/third_party/platform-name |
התראה
הצהרת API:
/openthread/include/openthread/platform/alarm-milli.h
Alarm API מספק שירותי תזמון והתראות בסיסיים להטמעת הטיימר בשכבה העליונה.
יש שני סוגים של שירותי התראות: מילישניות ומיקרו-שניות. Millisecond נדרש לפלטפורמת חומרה חדשה. הערך של מיקרו-שנייה הוא אופציונלי.
UART
הצהרת API:
/openthread/examples/platforms/utils/uart.h
ממשק ה-API של UART מטמיע תקשורת בסיסית של יציאה טורית דרך ממשק UART.
התוספים של OpenThread CLI ו-NCP תלויים בממשק UART כדי לבצע אינטראקציה עם צד המארח, אבל התמיכה ב-UART API היא אופציונלית. עם זאת, גם אם אתם לא מתכננים להשתמש בתוספים האלה בדוגמה של פלטפורמת החומרה החדשה, מומלץ מאוד להוסיף תמיכה בכמה סיבות:
- אפשר להשתמש ב-CLI כדי לאמת שהיציאה פועלת כמו שצריך
- כלי האוטומציה של Harness משתמש בממשק UART כדי לשלוט ב-OpenThread למטרות בדיקה ואימות
אם פלטפורמת החומרה של היעד תומכת במודול USB CDC במקום ב-UART, צריך לוודא את הדברים הבאים:
- התקנה של מנהל ההתקן הנכון של USB CDC בצד המארח
- מחליפים את הטמעת UART API במנהל ה-USB CDC (יחד עם ה-BSP) בצד OpenThread, באמצעות אותם טיוטות פונקציות
רדיו
הצהרת API:
/openthread/include/openthread/platform/radio.h
ב-Radio API מוגדרות כל הפונקציות הנדרשות שנקראות על ידי שכבת ה-MAC העליונה של IEEE 802.15.4. צ'יפ הרדיו חייב להיות תואם באופן מלא למפרט 2.4GHz IEEE 802.15.4-2006.
בגלל התכונה המשופרת של צריכת אנרגיה נמוכה, ב-OpenThread נדרש שכל הפלטפורמות יטמיעו מסגרת אוטומטית בהמתנה (העברה עקיפה) כברירת מחדל, וגם שטבלת ההתאמה של כתובת המקור תוטמע בקובץ המקור radio.h.
עם זאת, אם הדוגמה של פלטפורמת החומרה החדשה מוגבלת במשאבים, אפשר להגדיר את טבלת כתובות המקור באורך אפס. למידע נוסף, ראו Auto Frame Pending.
שונות/איפוס
הצהרת API:
/openthread/include/openthread/platform/misc.h
ה-Misc/Reset API מספק שיטה לאיפוס התוכנה בצ'יפ, ולשאילתה לגבי הסיבה לאיפוס האחרון.
אנטרופיה
הצהרת API:
/openthread/include/openthread/platform/entropy.h
ה-Entropy API מספק גנרטור מספרים אקראיים אמיתי (TRNG) לשכבה העליונה, שמשמשים לשמירה על נכסי האבטחה של כל רשת OpenThread. ה-API צריך להבטיח שייווצר מספר אקראי חדש לכל קריאה לפונקציה. נכסי האבטחה שמושפעים מ-TRNG כוללים:
- AES CCM nonce
- רעידות אקראיות עם עיכוב
- הכתובת המורחבת של המכשירים
- התקופה האקראית הראשונית בטיימרים של הזרמה הדרגתית
- מזהים של אסימונים/הודעות CoAP
לתשומת ליבכם: בפלטפורמות רבות כבר יש שילוב של גנרטור מספרים אקראיים, שמציג את ה-API בחבילת ה-BSP שלו. אם פלטפורמת החומרה של היעד לא תומכת ב-TRNG, כדאי להשתמש במדגם של מודול ADC כדי ליצור מספר אקראי באורך קבוע. אם צריך, אפשר לדגום כמה חזרות כדי לעמוד בדרישות של TRNG (uint32_t).
כשהמאקרו MBEDTLS_ENTROPY_HARDWARE_ALT מוגדר ל-1, ממשק ה-API הזה צריך לספק גם שיטה ליצירת האנטרופיה של החומרה שמשמשת בספריית mbedTLS.
אחסון לא נדיף
הצהרות API:
/openthread/include/openthread/platform/flash.h
או
/openthread/include/openthread/platform/settings.h
כדי לעמוד בדרישות לגבי אחסון לא נדיף, אפשר ליישם אחד משני ממשקי ה-API שמפורטים למעלה. Flash API מטמיע מנהל אחסון של זיכרון פלאש, ואילו Settings API מספק פונקציות להטמעת פעולות פלאש בסיסיות בשכבה העליונה.
ממשקי ה-API האלה חושפים לשכבה העליונה:
- נפח האחסון הלא נדיף שזמין לאחסון נתוני האפליקציה (לדוגמה, מערך נתונים פעיל/בהמתנה, פרמטרים נוכחיים של הרשת ופרטי הכניסה של מכשירי השרשור לצורך חיבור מחדש אחרי איפוס)
- פעולות קריאה, כתיבה, מחיקה ושאילתות לגבי סטטוס פלאש
משתמשים ב-OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE בקובץ התצורה של הליבה של דוגמת הפלטפורמה כדי לציין באיזה API הפלטפורמה צריכה להשתמש. אם ההגדרה היא 1, צריך להטמיע את Flash API. אחרת, צריך להטמיע את Settings API.
צריך להגדיר את הדגל הזה בקובץ /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.
רישום ביומן
הצהרת API:
/openthread/include/openthread/platform/logging.h
Logging API מיישם את הפונקציונליות של OpenThread לתיעוד ביומן ולניפוי באגים, עם כמה רמות של פלט לניפוי באגים. ה-API הזה הוא אופציונלי אם אתם לא מתכננים להשתמש ברישום ביומן של OpenThread בדוגמה החדשה של פלטפורמת החומרה.
הרמה הגבוהה והמפורטת ביותר היא OPENTHREAD_LOG_LEVEL_DEBG, שבה מודפסים כל פרטי החבילות הגולמיות ומתבצע רישום ביומן של שורות דרך היציאה הטורי או בטרמינל. בוחרים את רמת ניפוי הבאגים שהכי מתאימה לצרכים שלכם.
ספציפיים למערכת
הצהרת API:
/openthread/examples/platforms/openthread-system.h
ממשק ה-API הספציפי למערכת מספק בעיקר פעולות של הפעלה והשבתה של פלטפורמת החומרה שנבחרה. ספריית OpenThread עצמה לא קוראת ל-API הזה, אבל הוא עשוי להיות שימושי למערכת או ל-RTOS שלכם. אפשר גם להטמיע את האיניציאליזציה של מודולים אחרים (למשל, UART, Radio, Random, Misc/Reset) בקובץ המקור הזה.
ההטמעה של ה-API הזה תלויה בתרחיש לדוגמה. אם אתם רוצים להשתמש באפליקציות ה-CLI וה-NCP שנוצרו בפלטפורמה לדוגמה, עליכם להטמיע את ממשק ה-API הזה. לחלופין, אפשר להטמיע כל ממשק API כדי לשלב את מנהלי הפלטפורמה לדוגמה במערכת או ב-RTOS.