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

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

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

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

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

פרט שטני 1: באגים

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

פרט שטני 2: עדיין צריך להכיר את המערכת

כדי להמחיש בצורה הטובה ביותר את הסעיף הזה, הסתכלו על כלי הקונפיגורציה הבא, מתוך Simplicity Studio של חברת Silicon Labs:

כלי הקונפיגורציה של Simplicity Studio (לחצו להגדלה)

בחלונית Properties מימין באמצע, למשל, חוץ מ-IOMode ו-Label, האם אתם מבינים מה כל משתנה אומר? מעבר לזה, למי שלא מכיר את הנושא של ה-Crossbar – ראו בפוסט הזה בסעיף "ואחת מוזרה במיוחד" – מובטחת חוויה, ובכן, מוזרה במיוחד: כל שינוי בבחירה של פונקציות מיוחדות בחלונית מימין למטה יגרום לקפיצות של הקצאות הפינים במפה הראשית. כלי התוכנה עושה את העבודה שלו, אבל חייבים להכיר את הארכיטקטורה הפנימית כדי להבין איך הוא עובד ואיך להשתמש בו, וכדי להכיר את הארכיטקטורה חייבים ניסיון קודם ולקרוא לא מעט ב-Datasheet. מי שינסה לגשת למיקרו-בקר חדש בפעם הראשונה דרך כלי קונפיגורציה כזה יכול לאבד בקלות את הידיים ואת הרגליים.

פרט שטני 3: חוסר גמישות

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

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

דווקא בכלי של Silicon Labs שהראיתי למעלה יש פיצ'ר מעניין, של הגדרת מצבי חומרה שונים ("Modes") ומעברים ביניהם. זה פותר את הבעיה שהצגתי, אבל מצד שני, איך בדיוק משתמשים בפיצ'ר הזה? אם אני צריך לשבת עם מדריך למשתמש וללמוד את כל הדקויות של כלי הקונפיגורציה, אפשר באותה מידה לשבת עם ה-Datasheet וללמוד את כל הדקויות של הרכיב עצמו…

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

פרט שטני 4: התחייבות ל-HAL

רבים מכלי הקונפיגורציה לא מסתפקים בכתיבה של קוד הצבת ערכים ברגיסטרים, אלא משלבים אותו בפונקציות עזר גבוהות יותר, מה שנקרא Hardware Abstraction Layer או HAL בקיצור. כל ספריות הליבה של ארדואינו, למשל הפונקציות digitalRead ו-digitalWrite, הן HAL בסיסית.

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

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

אז כן או לא?

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