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

לפני יותר משנה השגתי את CY8CKIT-049-42XX – קיט פיתוח והערכה זול במיוחד, למיקרו-בקר מסוים ממשפחת PSoC4 (בארכיטקטורת ARM 32-bit Cortex-M0), מתוצרת חברת Cypress. אחרי שהצלחתי לצרוב עליו את תוכנת ה-Blink לדוגמה – זה לא היה פשוט – וכתבתי על זה פוסט, הלוח עבר למגירת "צריך לעשות עם זה משהו מתישהו", ודי נשכח בין כל הפרויקטים והרכיבים האחרים.

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

תכנות וויזואלי-למחצה

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

למיקרו-בקרים אין GUI, אך יש להם המון אלמנטים ומודולים "פריפראליים" מעבר לליבה שמריצה את הקוד: פיני IO, ממירי ADC, טיימרים, EEPROM ועוד. במקום ללמוד את כולם מה-Datasheet במאמץ רב, או לקרוא לשורה ארוכה של פונקציות אתחול והגדרה מספריה מוכנה, סביבת הפיתוח PSoC Creator מאפשרת לנו להפעיל, להגדיר ולחבר את המודולים של המיקרו-בקר בעזרת כלים גרפיים. בנוסף, לכל אלמנט שאנחנו יוצרים, מופקות אוטומטית פונקציות תפעול "רגילות" שבהן נוכל להשתמש בקוד הראשי במקרה הצורך.

כמובן, זה לא רעיון חדש וגם לא ייחודי ל-Cypress. אותו דבר נעשה ב-STM32Cube של STMicroelectronics, ב-Code Configurator של Microchip ועוד.

ואיך זה, טוב?

העבודה עם הממשק הגרפי קלה, אבל זה לא אומר שקל ליצור יישומים. לדוגמה, אני יכול להציב תוך שניות אובייקט טיימר בשם Timer_1 ולהגדיר לו מקור שעון וערך מקסימום (שיעורר פסיקה שתהבהב ב-LED, למשל), אבל אם לא אכלול את הפקודה Timer_1_Start בתחילת הקוד שלי, הוא פשוט לא יפעל. כדי להבין את זה הייתי צריך דוגמאות קוד מהרשת, ולחפש ב-Datasheet, בדיוק כמו בתכנות רגיל. אפילו בפרויקט Blink פשוט יש מספר "מלכודות" כאלה.

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

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

מסקנות

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

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

בפוסט הבא בנושא זה אדגים בנייה של פרויקט Blink מבוסס על טיימר.