תכירו את מערכת ה-Plug-n-Play

מבוא

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




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

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

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

על מה מדובר?

מערכת Plug-n-Play היא שילוב של חומרה ותוכנה בסביבת ארדואינו שמאפשרים להקל ולזרז עוד יותר את בניית הפרוייקטים. המערכת מאפשרת להתמקד בצד התוכנתי (כתיבת קוד) סביב פיתוח לכרטיסי ארדואינו ומבטלת כמעט לגמרי את הצד החומרתי, את האלקטרוניקה והגדרות בתהליך. כל הפרוייקט הוא Open Source ואפשר למצוא את הכל ב-GitHub שלי.

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

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

הנה עיקרי התכונות שמערכת Plug-n-Play מספקת. אפרט כל אחת מהן בהמשך ואסביר איך הגעתי לזה.

• 0 הלחמות. מקסימום לסגור בורג על מחבר הברגה
• חיבורים בין הרכיבים יציבים ומקוטבים (polarized)
• כל החיבורים זהים. כל חיבור מתאים לכל רכיב
• ללא הגדרות אלקטרוניקה ושל החיבור הפיזי
• גמישות לגידול הפרוייקט (Scalability)
• חשיבה פונקציונלית ולא במושגים של אלקטרוניקה
• גמישות באספקת מתח
• כיוון מחשבה של פיתוח ובניית מוצר (Development and Production)
• שימוש מובנה ושקוף בפסיקות (Interrupts) לכל הרכיבים
• תמיכה מובנית במצבי חסכון בחשמל (Power saving)
• סביבת פיתוח מבוססת אירועים (Event based)
• מחלקות (Classes) המממשות את הפונקציונליות של המודול עם ממשק פונקציונלי ולא מבוסס מושגים של אלקטרוניקה

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

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

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

מערכת Plug-n-Play אמורה להוריד חסמים למתחילים וגם לייעל את תהליך הבניה למפתחים מנוסים בתחום.

והנה הסבר על כל סעיף ברשימה:

0 הלחמות. מקסימום לסגור בורג על מחבר הברגה

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

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

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

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

חיבורים בין הרכיבים יציבים ומקוטבים (polarized)

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

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

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

בחרתי להשתמש במחברי JST-SH קטנים של 6 קווים. אסביר בהמשך למה.

בטוח שיהיו אנשים שיחשבו איך זה שונה ממערכת GROVE של SeeedStudio, או QWIIC של SparkFun, או אפילו החיבורים בין המודולים של Makeblock שהייתי מוכר לפני כמה שנים טובות… התשובה הקצרה היא שלא כל המחברים שלהם זהים (סעיף הבא ברשימה) ואין תמיכה בפסיקות, שזה אחד הדברים ההכרחיים למערכת Embedded. אפרט עוד יותר בהמשך.

כל החיבורים זהים. כל חיבור מתאים לכל רכיב

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

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



מערכת GROVE של SeeedStudio גם משתמשת במחברים מקוטבים. הנה תמונה של תוסף החיבורים לכרטיס Arduino UNO:



המחברים זהים פיזית, אבל מתהגים שונה. חלק רק דיגיטליים (מחברי ה-D), חלק עם כניסות אנלוגיות (מחברי ה-A). חלק מאפשרים I2C, חלק רק ל-UART. זה מוסיף בלבול. מה עושים אם אני צריך עוד כניסה אנלוגית? או 3 ערוצי UART? ראו סעיף הבא ברשימה. וגם, אין תמיכה בפסיקות.

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



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

נקודה שלא קשורה ישירות לפרוייקט, אבל הפסקתי למכור את המוצרים של Makeblock כי הם החליטו לנטוש את התחום ממנו הם גדלו - רכיבים ל-DIY, ולהתרכז במוצרים מוגמרים, וכמו שאני קורא להם "צעצועים לימודיים". אני מזהה כיוון מחשבה דומה גם אצל SeeedStudio. מגוון רכיבי ה-GROVE פוחת, הם לא מוציאים דגמים חדשים, מעלים רף הדרישות להזמנות ומפרסמים יותר ויותר את המחשבים שהם מייצרים וחיישנים לתעשיה וחקלאות. הרבה יותר נחמד למכור מוצרים שעולים מאות דולרים כל אחד, מאשר רכיבים שעולים דולרים בודדים. מקווה שהם לא ילכו לכיוון הזה עד הסוף…
אני מזכיר את הנקודה כי יכול לבוא היום שנשאר בלי רכיבים פשוטים וזולים לבניית פרוייקטים.

יכולת של כל חיבור נגזרת מהקווים אליהם הוא מחובר על המיקרובקר, יש חיבורים עם יכולות PWM, כניסה אנלוגית או תקשורת UART או I2C.

במערכת Plug-n-Play כל החיבורים זהים, גם פיזית וגם מבחינת היכולת שלהם. לכולם יש קו מתח (3.3V) ואדמה, שני קווים לתקשורת I2C ושני קווי GPIO שיכולים לשמש לפסיקות, כניסה או יציאה דיגיטלית. ויתרתי על היכולות הנוספות שקיימות במיקרובקר שלא משותפות לכל החיבורים (המרה אנלוגית ו-PWM), יכולות אלה אפשר יהיה לשחזר על המודולים המתחברים למערכת, אם יש צורך.

ללא הגדרות אלקטרוניקה ושל החיבור הפיזי

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

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

ב-GROVE זה פשוט חיבור ישיר לקווי ארדואינו. צריך לדעת לאיזה GPIO הרכיב חובר ולהגדיר את מה שצריך בתוכנה בהתאם לזה. שמות החיבורים והקווים שם מאוד מבלבלים. למשל בחיבור "D2" יש קווים D2 ו-D3. בחיבור "D3" יש שוב קו D3 וגם D4. בחיבור "D4" יש שוב D4 ו-D5. יש כפילות שגורמת להתנגשויות אם מחברים מודולים שזקוקים לשני הקווים (לדוגמה מודול פשוט עם 2 כפתורים).

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


במערכת Plug-n-Play אין משמעות לאיזה חיבור תחברו את הרכיב ולא צריך להגדיר שום דבר בתוכנה. חיברתם חיישן טמפרטורה לאיזה שהוא מחבר PnP? תגדירו משתנה של המחלקה (Class) שמטפלת בחיישן זה והם ידברו ביניהם מבלי שצריך להגדיר משהו נוסף. לא מספר חיבור, לא כתובת I2C… כלום! פשוט עושים ()Init למשתנה (המופע של המחלקה) וזהו.
אפשר לפרק את הפרוייקט בסוף היום, להרכיב אותו שוב למחורת עם חיבור של הרכיבים למחברים אחרים וזה עדיין יעבוד בלי שצריך לשנות משהו בקוד.

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

גמישות לגידול הפרוייקט (Scalability)

תוך כדי שאני מתכנן את הכרטיס הראשי למערכת Plug-n-Play מישהו שאל באימייל על איזה כרטיס אני יכול להמליץ שיש לו 5 ערוצי UART. הלקוח היה צריך UART אחד מהיר כדי לתקשר עם מערכת אחרת ועוד 4 איטיים יותר שצריכים להתחבר לחיישנים.

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

צריכים עוד חיבור UART? חברו עוד מודול. עד כדי כך פשוט.

ומה אם צריך עוד 20? אין בעיה!
כשלב הבא אני מתכוון לתכנן כרטיס מרבב חיבורי PnP. כל כרטיס יוכל להמיר חיבור PnP אחד ל-8 חיבורים נוספים. יהיה די פשוט להוסיף עוד 2 רמות של מרבבים למערכת, כך ש-8 חיבורים שיש על הכרטיס הקיים יוכלו להפוך להיות 512 חיבורי Plug-n-Play. כאמור כולם זהים ביכולות…

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

נהוג להשוות את כמות ה-GPIO בכרטיסי פיתוח. אז אם נניח יהיה מודול עם 8 כניסות, או כזה שמפעיל 8 ממסרים, אז זה יהיה שווה ערך ל-4096 קווים דיגיטליים לכרטיס Plug-n-Play אחד. כנראה שנגיע למגבלת זכרון במיקרובקר הרבה לפני שנוכל לחבר כמות כזו של רכיבים.

כמובן שאין ארוחות חינם. הגישה לרכיבים "הרחוקים" יותר ממיקרובקר (אלה שמחובים דרך ברבבים) תהיה איטית יותר בהשוואה לרכיבים שמחוברים ישירות לכרטיס עם הבקר. יש מקרים שזה חשוב ויש מקרים שפחות. לא תהיה בעיה להפעיל ממסרים שמחוברים דרך שתי רמות של מרבבים או לתקשר דרך ערוץ ה-UART במהירות של 9600bps.

חשיבה פונקציונלית ולא במושגים של אלקטרוניקה

אם כבר "חותכים" את שכבת האלקטרוניקה מתהליך בניית הפרוייקט ע"י מערכת Plug-n-Play, אני חושב שאפשר להיפטר גם מהמושגים של עולם האלקטרוניקה.

אפשר להפסיק לדבר על PWM, GPIO או AnalogInput, ובמקום זה לעבור לדבר על הפעלת מנוע סרוו, הפעלת ממסר או קבלת מיקום הבורר (פוטנציאומטר).

זה נושא קצת פילוסופי, אבל אם תחשבו על זה, בסופו של דבר המושגים של אלקטרוניקה הם רק "הדרך" להפעיל משהו "ממשי". ה-GPIO מפעיל ממסר, את ערך הבורר של הפוטנציאומטר מקבלים דרך AnalogInput. מערכת ה-Plug-n-Play משנה או מסתירה את "הדרך" ומאפשרת להתמקד על הדבר "הממשי" שבקצה.

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

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

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

האא… רגע… למיקרובקר בדרך כלל יש רק ממיר אנלוגי לדיגיטלי אחד (ADC), כלומר אי אפשר לעשות דברים במקביל. ומה אם צריך 10 רכיבים אנלוגיים? למיקרובקר אין כמות כזו של כניסות אנלוגיות, צריך רכיבים חיצוניים, הלחמות וכו'. כל זה לא קיים עם מערכת Plug-n-Play. חברו כמה רכיבים שאתם צריכים, כל אחד מהם הוא יחידת חומרה עצמאית כך שכולם יכולים לעשות את ההמרות במקביל. התוכנית שלכם יכולה לקבל קריאה לפונקציה כשהנתונים מוכנים. אפשר כמובן להמשיך עם התהליך בצורה טורית, אבל האפשרות לעבוד בצורה אחרת קיימת ומוכנה לשימוש.

גמישות באספקת מתח

עד עכשיו דיברנו רק על החיבור הלוגי/פונקציאונלי של הרכיבים, בוררים, כפתורים, חיישנים וכו'. חיבור זה זקוק למתח כדי לפעול. לכל המערכות שהזכרתי קודם (QWIIC, GROVE וגם Makeblock) מתח לרכיב הלוגי עובר דרך החיבור עצמו. כך גם במערכת Plug-n-Play. המתח הלוגי הוא 3.3V.

אבל מה קורה אם הפרוייקט שלכם צריך מתחים נוספים וזרם כדי להפעיל משהו? מנועים שפועלים ב-12V או 6V? רצועות לדים שצריכים 5V? מנועי סרוו? ממסרים? חזרנו להלחמות?

טיפלתי בנושא זה במערכת Plug-n-Play בצורה של חיבורים ומייצבים מודולריים:


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


מתכנן לייצר גם מודולים משלי למקרים הטיפוסיים ביותר (כמו למשל המרה מ-5V של USB למתח המערכת של 3.3V).


ל-Pololu יש גם מייצבים שיכולים להעלות את המתח, כך שאפשר יהיה להפעיל פרוייקט עם סוללת אצבע אחת (שמספקת 1.5V), או מייצב שיכול גם להעלות וגם להוריד את המתח, כך שאפשר יהיה לעבוד עם סוללת LiPo שהמתח שלה יכול להיות גבוה יותר ממתח הדרוש כשהיא טעונה (כ-4.2V) ומתח נמוך מהדרוש כשהיא לקראת סוף היכולת שלה (כ-3.2V).


לחיבורים מודולריים אני מתכוון למודולים כאלה:


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

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

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

אבל למה להסתפק רק במודולים עם מחברים פשוטים? מה אם המודול יתמוך בשנאי USB-PD חכם ויוכל לבקש ממנו 12V? או 9V? או 5V בזרם גבוה?
מודול מיוחד לחיבור פנל סולארי שמוציא ממנו את המקסימום האפשרי ע"י טכנולוגיית ה-MPPT? יש עוד כמה רעיונות לתחום זה. משהו כזה, אבל בצורת מודול למערכת Plug-n-Play:

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

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

הנה דוגמה: לפני שפיתחתי את הכרטיס של Plug-n-Play, עשיתי ניסויים על כרטיס SAMD21 Mini של SparkFun כדי להבין עד כמה אפשר יהיה להוריד את צריכת הזרם. סיפקתי 3V ישירות לרכיבים הלוגיים כדי לעקוף את המייצב שיש על המעגל. הצלחתי להגיע לצריכה של 530uA במצב שינה עמוקה. לא הבנתי למה יש צריכה כל כך גבוהה של זרם. אחרי שחתכתי פיזית את הרגל של המייצב, מדדתי צריכת זרם של 22uA! מה שאומר, שמייצב על המעגל, גם אם הוא לא בשימוש, "גונב" קצת בגלל זליגת הזרם דרכו. זה הבדל בין להפעיל את הפרוייקט שנה שלמה על סוללת כפתור CR2032 או רק שבועיים.

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

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

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

גמישות זה שם המשחק כאן.

כיוון מחשבה של פיתוח ובניית מוצר (Development and Production)

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

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

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

חורים להתקנת רכיבים זה עוד דוגמה:


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


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

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

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

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

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

שלושת הלדים על הכרטיס של הבקר SAMD21 סידרתי כך שאפשר יהיה להרכיב עליהם מוליך אור כדי לספק חיווי מחוץ למארז:



לא צריכים את החיווי מחוץ למארז? פשוט אל תוסיפו את המוליך אור.

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

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


מחבר ה-Status LED מאפשר לחבר לד חיצוני. אפילו לא צריך נגד בטור, כבר קיים על המעגל.
רוצים חיווי קולי בפרוייקט? חברו זמזם ישירות למחבר הזה. הקו שמגיע למחבר זה עובר דרך טרנזיסטור שיכול לספק כ-100mA, כך שאין בעיה עם זמזם ורכיבים אחרים שצורכים קצת זרם. יש זמזמים שמגיעים עם חוטים ופועלים החל מ-3V, כך שהוא מתאים מעולה לקונספט זה, לא דורש הלחמות:

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

שימוש מובנה ושקוף בפסיקות (Interrupts) לכל הרכיבים

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

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

אולי יש מערכת אחרת שמטפלת בזה כמו שצריך?

ארדואינו הרשמי

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


רק שההסבר שלהם הולך לכיוון אחר לגמרי:

The I2C port, also referred to as the Eslov self-identification port within Arduino, comes with: SDA, SCL, GND, +5V, and an extra digital pin meant to send an alarm to the otherwise plain I2C devices connected to it.

קו שאמור לתת התראות לרכיבי I2C שמחוברים לבקר? הפוך גוטה, הפוך… רכיב ה-I2C הוא זה שצריך להתריע למיקרובקר על משהו שקורה איתו…

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

אולי מערכת ה-QWIIC תספק פתרון?

זה מה ש-SparkFun כתבו בעמוד ההסבר על QWIIC באתר שלהם:

What about the INT pin?
We deliberately chose four conductors to increase usability of the interconnecting cables, minimize the cost of the connectors and limit the PCB footprint. All boards with extra pin options (such as interrupts, address selection, power save mode, etc.) will have those pins broken out to 0.1" holes, so the end user can add extra connections as needed.

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

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

זה הפתרון שאני מציע במערכת Plug-n-Play:

בכל מחבר PnP יש שני קווים דיגיטליים שיכולים לשמש לפסיקות, וגם כקווים דיגיטליים רגילים. למיקרובקר SAMD21, שבחרתי כבקר הראשון להתחיל איתו, יש 16 קווי פסיקות (למעשה 17, אחד נועד למצבים קטסטרופליים והוא לא בשימוש), כלומר יש מספיק לכל 8 המחברים שיש על המעגל. מרבבים לחיבורי PnP גם ממשיכים את הרעיון הזה, כך שבנוסף לריבוב של קווי I2C בחיבור PnP, הם ירבבו גם 16 קווי פסיקות עם רכיבים שישמשו כ"בקר פסיקות" שמיקרובקר יוכל להעזר בהם למימוש הרעיון.

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

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

קוד: בחר הכל

void onButtonPress()
{
    if (button.InInterrupt()) {
        // Do your urgent logic inside ISR
        // And postpone the rest of the processing
        button.PostponeProcessing();
        return;
    }

    // This function will be called again from normal run
    // Do your thing outside ISR
}


תמיכה מובנית במצבי חסכון בחשמל (Power saving)

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

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

האם הצלחתי להגיע לצריכת זרם שראיתי עם כרטיס SAMD21 Mini בו השתמשתי לבדיקות? בהחלט! בבדיקות עם הכרטיס של SparkFun הגעתי לצריכה של 22uA במצב שינה. עם כרטיס ה-Plug-n-Play שמבוסס על אותו מיקרובקר, עם כמה שבבים נוספים שיש על המעגל, שגם הם צורכים קצת זרם, הגעתי ל-21.5uA. אלה מספרים מעולים מבחינתי.

בדקתי גם את המתח המינימלי בו הכרטיס יוכל לפעול. הצלחתי להפעיל אותו עם אספקה של 1.95V בערך. מה שאומר שאפשר להפעיל את הפרוייקט מסוללת כפתור CR2032 שמספקת 3V כשהיא חדשה והמתח שלה יורד לכיוון ה-2V עם הזמן. אפשר גם להשתמש בשתי סוללות אצבע שמספקות 3V (או 2.4V לסוללות נטענות).

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

סוללת כפתור CR2032 יכולה לספק כ-210mAh. נחלק את ה-210mA ב-25uA ונקבל 8400 שעות עבודה במצב זה. שזה 350 ימים. קצת פחות משנה. לא רע…

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

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

קוד: בחר הכל

EBF.SetSleepMode(EBF_SLEEP_DEEP);

זה הכל. שאר הקוד לא משתנה.

יש גם מצב שינה EBF_SLEEP_LIGHT, שמנסה לחסוך קצת בין הפסיקות שמקדמות של הספירה שמקבלים בפונקציית ()millis.

סביבת פיתוח מבוססת אירועים (Event based)

הגענו לצד התוכנתי של הפרוייקט…

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

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

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

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

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

מערכת Plug-n-Play מתבססת על ספריית ה-EBF. טכנית, אפשר כנראה לעבוד בצורה טורית (Sequential flow), כמו שזה קורה עם תוכניות ארדואינו שמוצאים ברשת, אבל זה מבטל כמעט את כל הפונקציונליות שהמערכת מציעה. כדי שרכיבי PnP יקושרו למשתנים שמייצגים אותם בקוד צריך רק אתחול (Init) של ספריית ה-EBF ושל המשתנים עצמם, אחרי זה כל השאר שלא קשור לתזמון כנראה יעבוד רגיל (לא ניסיתי). כל מה שקשור לתזמונים, אפילו ()led.Blink כנראה שלא יעבוד, כך שאני לא ממליץ ללכת לכיוון הזה.

וזה אחד האתגרים שיהיו למערכת הזו כדי לחדור לשוק. צריך לחנך את כל העולם לתכנת בצורה נורמלית (שונה ממה שהתרגלו בעולם הארדואינו)…

מחלקות (Classes) המממשות את הפונקציונליות של המודול עם ממשק פונקציונלי ולא מבוסס מושגים של אלקטרוניקה

הזכרתי שיהיו מחלקות (Classes) עבור כל רכיב במערכת Plug-n-Play. זה שווה ערך לספריה שאתם מוסיפים לסביבת הארדואינו כדי להשתמש בחיישן כלשהו.
כל רכיב PnP שייצא לעולם, יגיע עם מחלקה מתאימה שתממש את הפונקציונליות שלו, תדע איך לתקשר איתו וגם לזהות אותו באתחול (שלב ה-Enumeration של המערכת).

אין פה משהו חדשני, חוץ מזה שהמחלקות האלה יהיו כחלק מהסביבה. כל המחלקות יהיו מותקנות יחד עם ספריית ה-EBF. לא צריך לחפש את הספרייה המתאימה לרכיב. היום יש מצבים שאתם קונים רכיב מיצרן אחד (סיני, או אפילו SparkFun) ומשתמשים בספריה של Adafruit למשל. למה? כי אומרים שהמימוש שם יותר טוב. או שהסינים לא מספקים בכלל ספריות למוצרים שלהם…

למה צריך לכתוב את הכל מ-0 עבור רכיבים שכביכול רק החיבור שלהם משתנה?
ספריות הקיימות ניגשות ישירות למשאבי הבקר (חיבור ה-I2C או GPIO), כאשר במערכת PnP צריך לעבור דרך מרבבים כדי להגיע לחומרה של המודול עצמו. צריך גם להוסיף את הטיפול בפסיקות וגם בפונקציות callback שדרושים כדי לממש את הרעיון של תכנות מבוסס אירועים.

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

דעתכם חשובה!

כבוד למי שהגיע עד כאן!

הפוסט יצא מאוד ארוך, כך שאני לא אמשיך עם ההסבר הטכני איך כל הקסם של ה-Plug-n-Play קורה. אם אתם רוצים לדעת, כתבו בתגובות, אולי אפרסם פוסט נוסף עם עוד פרטים.

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

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

אולי אתם מזהים בעיה שאני לא רואה בתכנון שלי? או יש לכם רעיון לשיפור המערכת? כל Feedback יתקבל בשמחה.

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

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


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

לא הזכרתי את זה, אבל כן, כל הרכיבים האלה מיוצרים כאן, במחסן של 4project.co.il, עם המכונות באותו החדר בו אני כותב את הפוסט הזה כרגע. כך שהכל אפשרי. גם לשנות ולשפר דברים וגם להוסיף מודולים חדשים כשיהיה צורך.

מה הלאה?

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

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

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

אני נחוש לקדם את הרעיון הזה ואני כבר All-In בפרוייקט.

מה דעתכם? האם מערכת Plug-n-Play תהפוך לפופולרית או נדונה לכישלון?
כרגיל, אשמח לתגובות לפוסט בפייסבוק.