בשביעי ביוני, בפנייה לפורום המצומצם של מפתחי הקוד של ארדואינו, מאסימו באנזי התווה מפת דרכים חדשה שמתמקדת בעשיית סדר ביסודות ושיפור שלהם – עד כדי הכנסה של מערכת הפעלה בזמן אמת (RTOS) לתמונה. האם זה ריאלי? ואיך זה ישפיע על משתמשי הקצה?
לפני פחות משנה, בהרצאה פומבית ומתוקשרת (עליה סיפרתי כאן), באנזי – המפורסם מבין מייסדי ארדואינו – הסביר שהתוכניות העתידיות שלו לארדואינו הן להפוך אותו למשהו שמצריך עוד פחות הבנה בתכנות ובאלקטרוניקה. אני ראיתי (ועדיין רואה) בזה כיוון גרוע מאוד מבחינת המייקינג, שיועיל רק לקופה של ארדואינו. אלא שההודעה שבאנזי שלח כעת לפורום המפתחים, שהגיעה גם אליי כי פעם שאלתי שם כמה שאלות, מוכיחה שהוא חושב יותר רחוק מאשר סניף הבנק הקרוב.
באנזי רוצה, קודם כול, שקוד תוכנה שנכתב לארדואינו יהיה "חוצה פלטפורמות". הכוונה לקוד שיצריך מינימום שינויים (אם בכלל) במעבר בין לוחות הארדואינו השונים – הפשוטים עם מיקרו-בקרי AVR, המתקדמים עם צ'יפים של ARM או של אינטל וכו'. כל עוד מדובר בפרויקטים בסיסיים כמו Blink, אין כמובן בעיה – אבל כשמתקדמים ליכולות WiFi או USB, הדברים נעשים כיום בצורה שונה בכל לוח. השאיפה היא ליצור Arduino API סטנדרטי, מין ספריה של פונקציות שתהווה "שכבת הפשטה" מעל רמת החומרה הבסיסית. מישהו יצטרך כמובן לכתוב את הספריה הזו בנפרד לכל סוג מעבד, אבל זה יצטרך לקרות רק פעם אחת, ויהיה שקוף למשתמש הטיפוסי: על פי החזון, כל קוד שאתם תכתבו, או ספריה שתורידו מהרשת, יסתמכו על ה-API ולכן יוכלו לרוץ על כל לוח ארדואינו בעולם אם יש לו חומרה שמסוגלת לתמוך בזה.
למעשה, המרוויחים הישירים העיקריים מ-Arduino API אוניברסלי יהיו אלה שכותבים ספריות. כיום כל מפתח חייב להגדיר ולהתחשב באינספור פרמטרים של הלוחות השונים, וזה קשה מאוד, מה שגורם לייאוש או להתמקדות בלוחות מדגם ספציפי בלבד. באנזי רוצה גם לראות סטנדרטיזציה של התיעוד לספריות, כך שלא רק הקוד אלא גם התיעוד שלו יהיה עדכני ונגיש לכולם.
בפוסט מוזכר בנוסף הנושא של pre-processing, העיבוד המוקדם של הקוד שנשלח לקומפיילר. אחד היתרונות הבולטים-לעין של עיבוד משופר יכול להיות השלמה אוטומטית של קוד בסביבת הפיתוח. אבל שני החלומות המעניינים עוד יותר הם יכולת דיבוג משופרת לארדואינו, ו-Scheduler, אלמנט שיהיה מסוגל לתזמן משימות. הרי אחת השאלות הנפוצות ביותר של מתחילים בארדואינו היא איך לגרום לשני דברים לקרות "בו-זמנית". עם Scheduler, התשובה תהיה פשוטה מאוד: תראו לו אילו פונקציות אתם רוצים שיריץ ובאיזו תדירות, והוא כבר ידאג לזה. קסם!
עד כאן החלום. להגשים אותו, זה סיפור אחר. אנשים כבר התחילו לעבוד על חלקים מסוימים בתוכנית, אך צריך להשלים אותם ולשלב את הכול ביחד, ואילו חלקים אחרים אפילו טרם נוסחו בבירור. הדיונים/ויכוחים שהתעוררו בקבוצה מוכיחים שזו לא תהיה משימה קלה בכלל. למשל, ה-Scheduler הוא בעצם מין מימוש של מערכת הפעלה מינימלית, והרי כבר יש מערכות הפעלה רבות למיקרו-בקרים. אז למה להמציא את הגלגל מחדש? אפשר לאמץ מערכת קיימת. מצד שני, לכל אחת יש יתרונות וחסרונות מסוימים, וכל מי שעבד עם מערכת מסוימת מנסה, בעקבות ניסיונו האישי, להבטיח שהיא תגיע לארדואינו – או להילחם עד טיפת דמו האחרונה כדי שזה לא יקרה…
ונניח שתימצא מערכת הפעלה הולמת, ושהמפתחים יצליחו לשלב בה את נושא הדיבוג וה-Arduino API. איך זה ישפיע על הביצועים? הפעולות שמערכת הפעלה עושה תופסות משאבים של זיכרון ושל זמן. בעולם הארדואינו יש כבר עכשיו דברים – למשל הספריות ל-Neopixel – שמתקרבים לקצה גבול היכולת של המיקרו-בקרים הפשוטים. אם לוח כמו ארדואינו אונו יצטרך להריץ גם מערכת הפעלה, ייתכן שהוא לא יעמוס בעומס – או שהמשתמש הטיפוסי יצטרך לכתוב (יותר נכון, להעתיק מהרשת) פקודות הכנה נוספות שהוא לגמרי לא מבין, רק כדי לנטרל את מערכת ההפעלה כך שהקוד יוכל לעבוד.
בעולם הממוסחר של המייקינג, שבו מנסים לפתות אנשים לקנות עוד ועוד מוצרים על סמך ביצועים-על-הנייר, השאיפה של באנזי לתשתיות קוד טובות יותר ראויה לציון ולהערכה. מזה זמן-מה אני מלגלג על לוחות הארדואינו החדשים שצצים בשוק, בידיעה שהם יזכו להתעלמות כמעט מוחלטת מצד המייקרים וייעלמו באותה פתאומיות בה הופיעו. אם החלום החדש של באנזי יתגשם, ייתכן שלוחות כאלה יממשו את הפוטנציאל שלהם ויחלצו את עולם הארדואינו מהקיפאון שבו הוא שרוי בחמש השנים האחרונות, בערך. אבל זה "אם" גדול.