טיפים לפרויקטים למערכות משובצות

אם יש תחום שהשתנה מאוד בשנים האחרונות, הרי זהו תחום המערכות המשובצות (Embedded). בשנות ה-90 ועד ועד לעשור האחרון, בתחום זה שלטו מערכות קניינות (היי VXWorks!) והמעבדים היו יחסית די חלשים. לינוקס נכנס לתחום בשנות ה-2000 עם כל מיני פתרונות, חלקן קוד פתוח לחלוטין, חלקן מעורבות בחלקים עם קוד סגור והדברים החלו להשתנות באופן רציני במיוחד ב-5 שנים האחרונות.

ישנן בארץ לא מעט חברות שמפתחות פתרונות על מערכות משובצות, אולם נראה כי במקרים רבים חברות לא יודעות או לא מנסות להשתמש בכלים חדשים ויותר מודרניים, ופוסט זה ינסה לשפוך מעט אור על ההתפתחויות האחרונות. (גילוי נאות: כותב שורות אלו בונה גם פתרונות משובצים עוד משנת 2010).

נתחיל עם המעבדים: אם יש משהו אחד שאני רואה בחברות רבות בשימוש – זה לוחות מבוססים I.MX של NXP (לשעבר Freescale זכרונה לברכה). מעבד זה הוא מעבד כלל לא רע והוא מעולה בפתרונות לוידאו, אך כיום ישנם לא מעט פתרונות מחברות מתחרות שונות שלא רק נותנות את מה ש-I.MX (כולל דור אחרון) נותנים, הם נותנים גם ביצועים יותר טובים וגם מחיר יותר טוב (תלוי כמובן בכמות המוזמנת). מעבדים של סמסונג, קוואלקום, Rockchip, Texas Instruments, Amologic ואחרות מציעות מעבדי ARM שונים בין אם מדובר ב-32 או 64 ביט, עם תמיכה לציודים שונים, כולל התקנים חדשים (כמו פתרונות Wifi בסטנדרטים האחרונים).

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

כיום לעומת זאת, התחרות מ-ט-ו-ר-פ-ת! ה-Raspberry Pi יצא במחיר מגוחך של 35$ והמתחרים הגיבו בהתאם, וכיום אפשר להשיג לוחות עם מעבדים ברמות שונות בפחות מ-150$ (בקצה הגבוה) ללוח שכולל את המעבד, זכרון, כניסות ויציאות ועוד. אף אחד לא האמין שנגיע לסיטואציה הזו.

מה שמוביל לסיטואציה המעניינת הבאה שעדיין נראית בחברות רבות: שימוש בכלים ישנים. כיום כל מפתח מערכת משובצת נעזר ב-PC כדי לקמפל את הקוד ל-ARM על ה-PC ולהריץ את הקוד על הלוח, אולם רבים שוכחים שגם כלי הבניה השתנו מאוד לאחרונה (במיוחד ב-4 שנים האחרונות). ישנן עדיין חברות שמשתמשות ב-LTIB בשביל לקמפל (למרות שהכלי כבר מת)

אבל כיום ישנה דרך אחרת שכדאי לתת את הדעת עליה: אם אתם מכינים את המוצר שלכם, סביר להניח שניסיתם אותו בסביבת לינוקס על PC בשלב ה-PoC, וזה מעולה, אבל במקום להתחיל לעבוד על Yocto, אני ממליץ ללכת בדרך אחרת: לרוב המעבדים המודרניים (מבוססי ARM) יש היום גירסת לינוקס כמו אובונטו שקומפלה לאותו מעבד (אם אין, אפשר לבנות עבורכם. צרו קשר). קחו את ה-IMAGE הזה, התקינו אותו על כרטיס מיקרו SD (לפחות Class 10 או U1) והריצו את הלינוקס הזה על הלוח ואז התקינו את מוצרכם על אותו אובונטו שרץ על ה-ARM. זה יתן לכם מושג כללי איך המוצר שלכם רץ על מערכת משובצת. יכול להיות שזה יהיה קצת יותר איטי מבניה מצומצמת (עם Yocto ועל השאר תיכף ארחיב) – אבל זה יכול לתת לכם מושג אם זה רץ ואיך, ולמפתחים זה יכול לעשות את החיים יותר קלים אם הם אינם מכירים לינוקס לעומק בצורה מעולה – כי זה נראה בדיוק כמו דסקטופ לינוקס.

אחרי שהמוצר שלכם רץ על אובונטו מבוסס ARM – יגיע הזמן להתחיל לבנות את ה-IMAGE שאותו תתקינו על ה-eMMC שנמצא על הלוח. כאן מומלץ בשלב ראשון אם אתם עדיין משתמשים ב-LTIB – לצאת לגמרי מהכלי הזה (שוב, הוא מת). אם אתם משתמשים ב-Yocto לבנות Image (עם או בלי ה-BSP של היצרן) הגיע הזמן גם לבדוק חלק נוסף שנקרא Open Embedded – כיום שתיהם משולבים והיתרון הגדול של OE הוא כמות נוספת (ולעיתים נחוצה) של "מתכונים" המאפשרים הוספת חבילות חדשות בעת יצירת ה-Image, שלא לדבר על היתרון הגדול של הכלי smart שנמצא ב-Yocto שמאפשר לכם לבנות עדכונים חלקיים (הן כ-RPM או APT או IPK או OPKG) כך שכשמוצאים חור אבטחה באחת מהחבילות, סקריפט פשוט בתוך המערכת המשובצת שאתם בונים יכול להוריד מהשרתים שלכם עדכון חבילה ספציפית ושימוש ב-smart יכול להתקין את החבילה – וכך אין צורך להוציא IMAGE שלם בגלל חור אבטחה.

כלי נוסף שכדאי להתאמן עליו ולהכיר לעומק (במיוחד ל-IoT) הוא Buildroot – שמאפשר לכם לבנות Image שלם והכל מתוך תפריט המאפשר בחירת חלקים שונים שאתם זקוקים. כך יוצא Image קטן (יחסית) שכולל את הכל, וכך יש גם פחות חורי אבטחה פוטנציאליים, וגם קל להעביר את הפרויקט לפלטפורמות אחרות ומעבדים אחרים והוא גם קל מאוד לשימוש ע"י אנשים שמכירים את הצ'יפים אך אינם מכירים לעומק את עולם הלינוקס.

עוד כלי שכדאי להכיר (ולהפתעתי עוד לא פגשתי חברות שמשתמשות בו) זה Docker לבניית Images. מדוע? כשמריצים Yocto, אין אפשרות להריץ מספר סשנים של Bakebit. לעומת זאת, עם טכנולוגיית קונטיינרים כמו Docker אפשר בהחלט להקים כמה קונטיינרים ולהריץ בכל אחד מהם Bakebit, זה יכול מאוד לסייע אם מקמפלים קוד לכמה מעבדים או לכמה מטרות (Targets) שונות. יתרון נוסף של Docker זה שהכל רץ במהירות טבעית ויש אפשרות מובנית לשיתוף תיקיות (כמו תיקיית Cache ל-Yocto. אגב, טיפ קטן לאלו שצריכים לעבוד המון עם Yocto – להריץ bitbake world בפעם הראשונה, עדיף לעשות זאת בסופ"ש או בלילה לפני שיוצאים – וכך יהיה לכם Cache שיעזור "לאפות" דברים יותר מהר).

נקודה אחרונה שאני מעוניין להתייחס אליה היא נקודת ה"חסכנות" שקיימת בחברות רבות שרוצות שהמהנדס שבונה את הדרייברים/אלגוריתמים – גם יכין את ה-Image הלינוקסי, גם יכין פתרונות עדכון ועוד ועוד, ולצערי כאן יש פספוס רציני (ולעיתים התוצאות בהתאם, אני יכול להראות לכם ערימות של מודמים מלאי חורי אבטחה, פרוצדורות עדכון תמוהות ועוד).

אין לי ספק שאנשי פיתוח אלגוריתמים ודרייברים הם אנשים חכמים ומוכשרים, אבל במקרים רבים אין להם את הידע שצריך "מסביב". כך לדוגמא, אם יש צורך בכך שהמערכת תציע ממשק Web, ישנם כמה פתרונות. לפעמים יש צורך להציג גרפיקה, ויש הבדל ענקי בין להוסיף Xorg ל-Image או להסתפק ב-Frame Buffer, וישנן עוד מאות דוגמאות שאיש לינוקס רציני יכול להמליץ להוסיף/להחליף במקום פתרון ברירת מחדל (שאחר כך יכול להתגלות כחור אבטחה ענק או כחבילה שלא מתוחזקת ע"י המפתח שלה כבר שנים). לכן, המלצתי היא דווקא במקרים של פרוייקטים משובצים לפצל את המשרה ל-2. תנו למפתח לעשות את עבודתו המקצועית ותנו לאיש הלינוקס לבנות את השאר, בדיוק כמו שתיקחו גרפיקאי ומעצב UX לעצב לכם את הממשק Web ולא תסמכו על המתכנת שיעצב לכם את הממשק.

לסיכום: כדאי להכיר את המעבדים החדשים, כדאי לקנות לוחות (הם זולים!) וכדאי בשלב הראשון להתקין הפצת לינוקס רגילה על הלוח המשובץ כדי שתוכלו לבנות PoC טוב – עוד לפני שאתם מתקרבים לכלים לפיתוח/הכנה של Image למערכת המשובצת. כדאי להתעדכן גם בכלים שיש וגם מומלץ כמה שפחות להיות תלותיים בפתרונות (וגם ספריות) בקוד סגור. מומלץ לא "לזרוק" את כל עבודת הפרויקט על מפתח הדרייברים/אלגוריתמים ולסיום – כדאי לעבוד עם כלים שמאפשרים עדכונים חלקיים במקום לשחרר Image חדש כל פעם שמתגלה חור אבטחה או מעדכנים תכונות מסויימות.

Comments

comments

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *