הגדרת סביבת ה-build

הצגת המקור ב-GitHub

כדי לקדם פיתוח חופשי ופתוח, ב-OpenThread נעשה שימוש ב-CMake בכלי הפיתוח ל-build. בשלב זה, ערכת הכלים הזו נדרשת כדי להעביר את OpenThread לפלטפורמת חומרה חדשה.

יכול להיות שבעתיד תהיה תמיכה בסביבות פיתוח אחרות, אבל הן לא נכללות בהיקף של מדריך ההעברה הזה.

יצירת מאגר חדש

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

בדוגמה הזו, יצרנו את המאגר SiliconLabs/ot-efr32 ב-GitHub ושיכפלנו אותו ל-~/repos/ot-efr32.

mkdir -p ~/repos
cd ~/repos
git clone git@github.com:SiliconLabs/ot-efr32.git
Cloning into 'ot-efr32'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (60/60), done.
remote: Total 333 (delta 65), reused 39 (delta 39), pack-reused 234
Receiving objects: 100% (333/333), 170.78 KiB | 5.69 MiB/s, done.
Resolving deltas: 100% (194/194), done.
git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

מבנה המאגר

כדי לשמור על עקביות עם מאגרי הפלטפורמות הקיימים בארגון OpenThread ב-GitHub, מומלץ לבנות את המאגר כך:

tree -F -L 1 --dirsfirst
.
├── examples/
├── openthread/
├── script/
├── src/
├── third_party/
├── CMakeLists.txt
├── LICENSE
└── README.md
תיקייה תיאור
examples אופציונלי דוגמאות לאפליקציות
openthread המאגר openthread כמודול משנה
script סקריפטים ל-build, לבדיקה ולניפוי שגיאות
src ההטמעה של שכבת הפשטת הפלטפורמה
third_party מיקום של מקורות מצד שלישי

הוספת מודולים משניים

בשלב הבא מוסיפים את openthread ואת כל המאגרים הנדרשים האחרים כמודולים משניים.

git submodule add git@github.com:openthread/openthread.git
Cloning into '/home/user/repos/ot-efr32/openthread'...
remote: Enumerating objects: 78281, done.
remote: Counting objects: 100% (1056/1056), done.
remote: Compressing objects: 100% (488/488), done.
remote: Total 78281 (delta 639), reused 864 (delta 556), pack-reused 77225
Receiving objects: 100% (78281/78281), 76.62 MiB | 35.24 MiB/s, done.
Resolving deltas: 100% (61292/61292), done.

בדוגמה הזו, נוסיף גרסה מצומצמת של Silicon Labs Gecko SDK כמודול משנה ב-third_party.

cd third_party
git submodule add git@github.com:SiliconLabs/sdk_support.git
Cloning into '/home/user/repos/ot-efr32/third_party/sdk_support'...
remote: Enumerating objects: 32867, done.
remote: Counting objects: 100% (8181/8181), done.
remote: Compressing objects: 100% (3098/3098), done.
remote: Total 32867 (delta 4945), reused 7469 (delta 4732), pack-reused 24686
Receiving objects: 100% (32867/32867), 128.83 MiB | 30.91 MiB/s, done.
Resolving deltas: 100% (19797/19797), done.

סקריפטים

כדי להקל על ביצוע משימות נפוצות, כדאי ליצור כמה סקריפטים בתיקייה script. יכול להיות שיהיו שם סקריפטים למשימות כמו יצירת גרסת build, הפעלת כלי לניפוי שגיאות בקוד וסקריפט בדיקה לבדיקות של GitHub CI.

בהמשך מפורטות כמה דוגמאות לסקריפטים שהם סטנדרטיים ברוב מאגרי הפלטפורמות הקיימים.

bootstrap

הסקריפט הזה אמור להתקין את כל הכלים והחבילות הנדרשים לפלטפורמת החומרה שלכם. הוא צריך גם להריץ את סקריפט ה-bootstrap של openthread כדי לוודא שלמשתמש יש את כל מה שנחוץ כדי ליצור את סטאק OpenThread.

דוגמה מופיעה בסקריפט ה-bootstrap ב-ot-efr32.

build

סקריפט ה-build של CMake אמור לאפשר למשתמשים ליצור את סטאק OpenThread לפלטפורמה שלכם. אם במאגר מוגדרות אפליקציות לדוגמה, הסקריפט הזה אמור ליצור גם אותן. הסקריפט הזה צריך להכיל את אפשרויות ההגדרה הבסיסיות של המערכת, כולל הגדרות מאקרו ספציפיות לפלטפורמה.

דוגמה לכך מופיעה בסקריפט ה-build ב-ot-efr32.

test

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

ב-ot-efr32, הסקריפט פשוט מפעיל את הסקריפט build לכל לוח נתמך בכל אחת מפלטפורמות efr32.

דוגמה זמינה בסקריפט הבדיקה ב-ot-efr32.

make-pretty

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

אתם יכולים להגדיר את הסקריפט הזה בעצמכם, אבל הכי קל להשתמש בסקריפט make-pretty שבו משתמשים המאגרים הקיימים של הפלטפורמה. הסקריפט קורא לסקריפטים של הסגנון של openthread ומסייע לשמור על עקביות בסגנון בכל המאגרים של OpenThread.

הגדרת סקריפט ה-Linker

הסקריפט של GNU Linker מתאר איך למפות את כל הקטעים בקובצי הקלט (קבצי 'אובייקט' מסוג .o שנוצרו על ידי GNU Compiler Collection‏ (GCC)) לקובץ הפלט הסופי (לדוגמה, .elf). הוא גם קובע את מיקום האחסון של כל מקטע של תוכנית הפעלה, וגם את כתובת הכניסה. סקריפט הקישור הספציפי לפלטפורמה בדרך כלל מגיע עם ה-BSP של הפלטפורמה.

מגדירים את הכלי ld כך שיצביע על סקריפט הקישור הספציפי לפלטפורמה באמצעות target_link_libraries ביעד CMake של הפלטפורמה ב-src/CMakeLists.txt:

set(LD_FILE "${CMAKE_CURRENT_SOURCE_DIR}/efr32mg12.ld")

target_link_libraries(openthread-efr32mg12
    PRIVATE
        ot-config
    PUBLIC
        -T${LD_FILE}
        -Wl,--gc-sections -Wl,-Map=$.map
)

קוד ההפעלה של ערכת הכלים

קוד ההפעלה של ערכת הכלים מסופק לרוב יחד עם ה-BSP של הפלטפורמה. בדרך כלל הקוד הזה:

  1. הטמעת פונקציית הכניסה (Reset_Handler) של קובץ ההפעלה
  2. הגדרת טבלת הווקטור של ההפרעות
  3. איפוס הערימה והמקבץ
  4. העתקת הקטע .data מזיכרון לא נדיף ל-RAM
  5. מעבר לפונקציה הראשית של האפליקציה כדי להריץ את הלוגיקה של האפליקציה

קוד ההפעלה (קוד מקור ב-C או ב-assembly) חייב להיכלל בספרייה openthread-platform-name של הפלטפורמה, אחרת לא ניתן יהיה לצטט בצורה נכונה חלק ממשתני המפתח שנעשה בהם שימוש בסקריפט של הקישור:

  • src/CMakeLists.txt

דוגמה: startup-gcc.c ב-ot-cc2538src/CMakeLists.txt

add_library(openthread-cc2538
    alarm.c
...
    startup-gcc.c
...
    system.c
    logging.c
    uart.c
    $
)