בניית מערכת Embedded Linux למוצר: מ-BSP ועד תחזוקה לאורך שנים

בעולם המוצרים המשובצים של היום, Linux רץ על מכשירים רבים: בקרים תעשייתיים, שערי תקשורת, מכשור רפואי, רחפנים, קיוסקים ומערכות ראייה. הבחירה ב-Linux קלה. בניית מערכת Linux שמתאימה למוצר מסחרי, שעולה מהר, שמתעדכנת בשטח באופן אמין ושנשארת ניתנת לבנייה גם בעוד עשר שנים, היא עבודה הנדסית של ממש. בחברת TandemG אנו מתמחים בפיתוח Embedded Linux למוצרים, מהעלאת הלוח הראשון ועד תחזוקה ארוכת טווח. המדריך עובר על כל השכבות של המערכת: בחירת כלי הבנייה, ה-BSP, ה-Kernel וה-Device Tree, ה-Bootloader, זמן העלייה, מערכת הקבצים, התחזוקה והרישוי, ומסביר אילו החלטות כדאי לקבל מוקדם ואילו אפשר לדחות.

בקצרה

• מערכת Embedded Linux למוצר נבנית במיוחד עבורו: רק הרכיבים שנדרשים, בגרסאות נעולות, עם תהליך בנייה שאפשר לשחזר.
• Yocto מתאים למוצרים עם כמה וריאנטים, מחזור חיים ארוך ותמיכה של יצרן המעבד. Buildroot מתאים למוצרים פשוטים יותר שבהם המהירות והפשטות חשובות.
• ה-BSP של יצרן המעבד נבנה עבור ערכת הפיתוח שלו. הדרך ממנו למערכת מוצר עוברת דרך Device Tree מותאם, שכבת מוצר משלכם וניקוי של כל מה שהמוצר לא צריך.
• זמן העלייה, עמידות לנפילת מתח, מנגנון העדכון והרישוי של רכיבי הקוד הפתוח הם החלטות ארכיטקטורה, לא תיקונים שמבצעים בסוף.
• מוצר שיחיה שנים צריך תוכנית תחזוקה כבר מהיום הראשון: גרסאות נעולות, סביבת בנייה משוחזרת וארכיון של כל מה שנדרש כדי לבנות מחדש.

למה הפצת Linux רגילה לא מתאימה למוצר

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

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

שכבות המערכת: מהסיליקון ועד האפליקציה

כדי לקבל החלטות נכונות, כדאי להסתכל על המערכת כשכבות, שלכל אחת מהן בעלים, תלויות ושאלות משלה.

Yocto מול Buildroot: איך בוחרים כלי בנייה

שני הכלים המרכזיים לבניית מערכת Linux משובצת הם Yocto ו-Buildroot. שניהם בונים את המערכת מקוד המקור, אבל הגישה שלהם שונה, וההבדל משפיע על כל מחזור החיים של המוצר.

מתי Yocto הוא הבחירה הנכונה. כשיצרן המעבד מספק את ה-BSP שלו ב-Yocto, כשיש כמה מוצרים או וריאנטים שחולקים בסיס משותף, כשמחזור החיים של המוצר ארוך, וכשהצוות צריך SDK למפתחי האפליקציות.

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

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

הבחירה הזו קשה לשינוי בהמשך. מעבר מ-Buildroot ל-Yocto באמצע מחזור החיים של מוצר הוא פרויקט בפני עצמו, ולכן כדאי לקבל אותה בשלב הארכיטקטורה, עם תמונה של המוצרים העתידיים ולא רק של הנוכחי.

BSP: הפער בין מה שהיצרן נותן למה שהמוצר צריך

ה-BSP (Board Support Package) של יצרן המעבד או של יצרן מודול המעבד (SoM) הוא נקודת הפתיחה כמעט בכל פרויקט. הוא כולל Bootloader, Kernel עם הדרייברים של המעבד, Device Tree לערכת הפיתוח ותצורת בנייה. הוא חוסך חודשים של עבודה, אבל הוא נבנה עבור ערכת הפיתוח, לא עבור המוצר שלכם.

הדרך ממנו למערכת מוצר כוללת כמה צעדים:

התאמת ה-Device Tree ללוח. הלוח שלכם שונה מערכת הפיתוח: רכיבים אחרים, פינים אחרים, ממשקים שלא קיימים ואחרים שנוספו. כשהלוח תוכנן בידי צוות פיתוח חומרה שעובד צמוד לצוות התוכנה, ה-Device Tree נכתב במקביל לשרטוט, ולא מפוענח ממנו אחרי שהלוח חזר מהייצור.

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

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

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

Kernel ו-Device Tree: התאמת המערכת ללוח

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

תצורת ה-Kernel. נקודת הפתיחה היא תצורת ברירת המחדל של היצרן, ומשם מצמצמים: מוציאים את מה שהלוח לא צריך, מחליטים אילו דרייברים ייבנו לתוך ה-Kernel ואילו כמודולים, ומתעדים את השינויים כקובצי תצורה חלקיים ולא כקובץ אחד ענק.

דרייברים. כשרכיב על הלוח אינו נתמך, נדרש דרייבר. ההחלטה אם לכתוב אותו בתוך עץ ה-Kernel או מחוצה לו משפיעה על התחזוקה: דרייבר מחוץ לעץ עלול לדרוש התאמה בשדרוגי Kernel. מי שעבר את התהליך של כתיבת דרייברים בלינוקס מאפס יודע שרוב העבודה היא לא בקוד עצמו, אלא בהבנת הרכיב, בהגדרתו ב-Device Tree ובבדיקה מול החומרה.

ניהול Patches. כל שינוי ב-Kernel נשמר כ-Patch מתועד בשכבת המוצר, עם הסבר למה הוא נדרש. בלי זה, שדרוג Kernel הופך לחקירה ארכיאולוגית.

דרישות זמן אמת. כשהמוצר צריך תגובה בזמן קצר וצפוי, יש שתי דרכים עיקריות: Kernel עם PREEMPT_RT, שמשפר משמעותית את זמני התגובה ואת הצפיות שלהם, ומאז גרסה 6.12 הוא חלק מה-Kernel הרשמי בארכיטקטורות המרכזיות, או העברת החלק הקריטי למעבד נלווה. כשחלק מהדרישות הן דרישות זמן אמת קשיחות, ארכיטקטורה היברידית של Linux לצד מיקרו-בקר עם RTOS היא לעיתים קרובות הפתרון היציב יותר.

Bootloader ותהליך האתחול

תהליך האתחול של מערכת Linux משובצת עובר כמה שלבים: קוד האתחול שצרוב במעבד טוען את השלב הראשון של ה-Bootloader, שמאתחל את הזיכרון וטוען את U-Boot, שטוען את ה-Kernel ואת ה-Device Tree, וה-Kernel מפעיל את מערכת האתחול שמעלה את השירותים ואת האפליקציה.

ההחלטות שכדאי לקבל מוקדם:

מדיית האתחול. eMMC, QSPI, כרטיס SD או שילוב ביניהם. ההחלטה משפיעה על התכנון החשמלי, על תהליך הצריבה בייצור ועל מבנה המחיצות.

מנגנון שחזור. מה קורה כשהמערכת לא עולה? מוצר בשטח צריך דרך לחזור לגרסה עובדת בלי טכנאי: מחיצה כפולה, מונה ניסיונות אתחול ב-Bootloader ומצב שירות מוגדר.

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

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

זמן עלייה: איך מקצרים בלי לשבור

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

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

Root Filesystem ותמונת המערכת

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

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

בחירת מערכת קבצים לזיכרון. סוג הזיכרון קובע את הבחירה: מערכות קבצים שונות מתאימות ל-eMMC ולזיכרון NAND גולמי, וההחלטה משפיעה על אורך החיים של הזיכרון ועל ההתנהגות בנפילת מתח.

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

תמונת פיתוח ותמונת ייצור. תמונת הפיתוח כוללת כלי דיבוג וגישה נוחה. תמונת הייצור כוללת רק את מה שהמוצר צריך. שתיהן נבנות מאותו מקור, וההבדל ביניהן מוגדר בתהליך הבנייה.

עדכוני תוכנה בשטח

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

קיימות מסגרות מוכרות שמממשות את הדפוס הזה, כמו Mender, RAUC ו-SWUpdate, וברוב המקרים נכון לבחור אחת מהן ולהתאים אותה למוצר במקום לבנות מנגנון מאפס. כשהמוצר מחובר לפלטפורמת IoT מקצה לקצה, העדכון הופך לחלק מניהול הצי: פריסה מדורגת, מעקב אחר הצלחת העדכון בכל מכשיר והשלמה של מכשירים שלא עודכנו.

תחזוקה ארוכת טווח ושחזור בנייה

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

נעילת גרסאות. כל השכבות, כל הרכיבים וכל הכלים נעולים בגרסאות ידועות, ומנוהלים בקובץ תצורה שנשמר במאגר הקוד.

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

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

גרסאות LTS. גם Yocto וגם ה-Kernel מפרסמים גרסאות עם תמיכה ארוכה. בחירה בהן מאריכה את החלון שבו מתקבלים תיקונים בלי שדרוג גדול.

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

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

רישוי קוד פתוח: חלק מההנדסה של המוצר

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

הדרך הנכונה היא לשלב את הרישוי בתהליך הבנייה:

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

ההחלטות המשפטיות עצמן שייכות ליועץ המשפטי של החברה. התפקיד של צוות הפיתוח הוא לספק לו תמונה מדויקת ומלאה של מה שנמצא במוצר.

טעויות נפוצות בבניית מערכת Embedded Linux

• שינוי ישיר של שכבות היצרן. כל עדכון של ה-BSP דורס את השינויים, והצוות מתחיל לפחד מעדכונים.
• Device Tree שהועתק מערכת הפיתוח. המערכת עולה, אבל חלק מהרכיבים עובדים רק במקרה.
• אופטימיזציית זמן עלייה בלי מדידה. הצוות משקיע בשלב שאינו צוואר הבקבוק.
• מערכת קבצים שנכתבת כל הזמן. נפילת מתח משחיתה נתונים, והמכשיר לא עולה.
• מנגנון עדכון שמתוכנן בסוף. מבנה המחיצות כבר נקבע, ואין מקום לגרסה שנייה.
• בנייה שתלויה במחשב של מהנדס אחד. אחרי שנתיים, אף אחד לא מצליח לבנות את הגרסה שנמצאת בשטח.
• רישוי שנבדק רק לפני השחרור. רכיב בעייתי מתגלה כשכבר קשה להחליף אותו.

רשימת בדיקה: ממערכת הדגמה למערכת מוצר

1. נבחר כלי בנייה, והבחירה תועדה עם הנימוקים.
2. קיימת שכבת מוצר נפרדת, ושכבות היצרן לא שונו.
3. ה-Device Tree מתאר את הלוח בפועל ונבדק מול השרטוט.
4. גרסת ה-Kernel נבחרה לפי חלון התמיכה, וכל ה-Patches מתועדים.
5. קיים מנגנון שחזור כשהמערכת לא עולה.
6. זמן העלייה נמדד לפי שלבים, ויש יעד מוגדר.
7. מערכת הקבצים עמידה לנפילת מתח, והנתונים במחיצה נפרדת.
8. מנגנון העדכון כולל חזרה אוטומטית לגרסה קודמת.
9. הבנייה רצה בסביבה משוחזרת, וכל המקורות בארכיון.
10. דוח הרישיונות מופק אוטומטית בכל בנייה.

שאלות נפוצות

מה ההבדל בין Yocto ל-Buildroot?

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

מה זה BSP ולמה הוא לא מספיק למוצר?

BSP הוא חבילת התמיכה של יצרן המעבד או המודול: Bootloader, Kernel, Device Tree ותצורת בנייה. הוא נבנה עבור ערכת הפיתוח של היצרן, ולכן נדרשים התאמה ללוח שלכם, שכבת מוצר וניקוי של רכיבים שאינם נדרשים.

כמה זמן לוקח להגיע למערכת עובדת על לוח חדש?

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

האם Linux מתאים למוצר עם דרישות זמן אמת?

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

איך מקצרים את זמן העלייה של מערכת Embedded Linux?

מודדים את הזמן לפי שלבים, ומטפלים בשלב שבו הוא מתבזבז: ביטול השהיות ב-Bootloader, צמצום ה-Kernel, הסרת שירותים, הפעלה מקבילית, והפעלה מוקדמת של הפונקציה הקריטית בזמן ששאר המערכת עולה ברקע.

איך מבטיחים שאפשר יהיה לבנות את המערכת גם בעוד עשר שנים?

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

מה צריך לעשות בנושא רישוי קוד פתוח?

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

היתרון של TandemG

בחברת TandemG אנו בונים מערכות Embedded Linux למוצרים מהלוח הראשון: העלאת ה-BSP, התאמת ה-Device Tree וה-Kernel, פיתוח דרייברים, אופטימיזציית זמן עלייה, מנגנוני עדכון ותחזוקה ארוכת טווח. כיוון שמחלקת החומרה ומחלקת ה-Embedded עובדות יחד, ה-Device Tree ורצף האתחול מתוכננים במקביל לשרטוט, וכשמשהו לא עולה, מי שתכנן את הלוח ומי שכותב את התוכנה עומדים יחד ליד אותו לוח.

אנו בוחרים את כלי הבנייה לפי המוצר ולא לפי הרגל: Yocto כשיש כמה וריאנטים ומחזור חיים ארוך, Buildroot כשהפשטות חשובה יותר. כשיש דרישות זמן אמת, אנו בוחנים אם PREEMPT_RT מספיק או שנדרש מעבד נלווה, שצוות ה-Real-Time Embedded שלנו מפתח עבורו את הקוד. כשהמוצר מחובר לענן, אנו מכסים גם את התקשורת, את ניהול הצי ואת השרתים.

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

למי מתאים

• חברות שעוברות מלוח פיתוח ללוח מוצר ראשון עם מעבד Cortex-A
• צוותים שמתלבטים בין Yocto ל-Buildroot או בין מודול מעבד מוכן ללוח מלא
• מוצרים עם דרישה לזמן עלייה קצר או לעמידות בנפילות מתח
• חברות עם מערכת Linux קיימת שקשה לבנות מחדש או לשדרג
• מוצרים שצריכים תחזוקה ארוכת טווח ותהליך רישוי מסודר

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, מה שמאפשר לספק ערך מהיר יותר ובאיכות גבוהה יותר ללקוחותינו.

הפרויקט הבא שלכם מתחיל בשיחה

בונים מערכת Embedded Linux למוצר חדש, או מחפשים דרך לייצב ולתחזק מערכת קיימת? הצוות של TandemG ישמח לעבור איתכם על המעבד, על ה-BSP ועל ההחלטות שכדאי לקבל עכשיו כדי שהמערכת תחזיק לאורך שנים.

בחברת TandemG אנו מלווים חברות בבניית מערכות Embedded Linux, מבחירת כלי הבנייה והעלאת הלוח, דרך ה-Kernel, הדרייברים וזמן העלייה, ועד מנגנוני העדכון והתחזוקה ארוכת הטווח. צרו קשר לייעוץ ראשוני.