כולם יודעים של-ATmega328, המיקרו-בקר שבלב לוחות הארדואינו הנפוצים, יש 32 קילובייט של זכרון Flash לשמירת הקוד המקומפל. כולם יודעים גם שיש לו 2 קילובייט של זכרון RAM, וליתר דיוק SRAM, לאחסון זמני של משתנים ומידע אחר (עד שהארדואינו מנותק מזרם החשמל). אבל אם תסתכלו היטב במפרט של הג'וק הזה תראו שם גם קילובייט אחד של EEPROM. מה זה? מה זה נותן? ואיך מגיעים לשם? כל זאת ועוד, אחרי התמונה…
אז ראינו איך שולטים בשתי נוריות LED נפרדות באמצעות שני חוטים בלבד, והכללנו את השיטה למספר גדול יותר של נוריות (שיטה שמכונה, כך למדתי בדיעבד, Charlieplexing). כעת הגיע הזמן לעסוק בתכונה חשמלית מעניינת נוספת של נוריות ה-LED, שמאפשרת לנו להשתמש בהן בתור חיישני אור!
בפוסט זה אתייחס בעיקר לפן המעשי וה"מלוכלך" של השימוש. אפרופו, כל שימוש כזה יהיה בהכרח "מלוכלך": היעילות והאמינות של נוריות ה-LED בתור חיישני אור נמוכה, ואם הפרויקט שלכם רציני, עשו לעצמכם טובה והשיגו חיישן נורמלי.
זה עבד! בדיוק לפי התוכנית, ועם מספר נמוך להפתיע של תקלות ובאגים בתוכנה ובחומרה, הצלחתי לחבר את הארדואינו אל מקלדת ה-TI99/4A העתיק ולקרוא ממנה הקשות מקשים בזמן אמת (ובעזרת שלושה פינים בלבד, אם לא סופרים את הפלוס וה-Ground). לפני שניכנס לפרטים, הנה הדגמה חיה:
בחלק א' הראיתי איך אפשר, באמצעות שני חוטי חשמל בלבד, לשלוט בשתי נוריות LED נפרדות (עם מגבלה על הארה בו-זמנית), ושאלתי בכמה נוריות אפשר לשלוט באמצעות שלושה, ארבעה או מקרה כללי כלשהו של N חוטים.
אחד המגיבים השקיע ומצא את התשובה הנכונה עבור שלושה חוטים – שש נוריות LED. ומה לגבי השאר? אם אתם עדיין רוצים לפתור את החידה לבד, אל תקראו את הפסקאות הבאות, כי בפוסט זה אגלה את התשובה המפורטת. בנוסף, נזכיר שאלה מעניינת נוספת שעלתה בתגובות לחלק הקודם. אך לפני שנתחיל, הנה הדגמה של שליטה בשש נוריות באמצעות שלושה חוטים:
הנה חידה. יש לכם לוח עם מיקרו-בקר, נניח ארדואינו, ונורית LED אחת מרוחקת שאתם צריכים לשלוט בה. לכמה חוטי חשמל תזדקקו כדי לחבר ביניהם? התשובה היא, כמובן, שניים: אחד לאספקת (או אי-אספקת) מתח, והשני ל-Ground. לא, זו לא היתה החידה, רק ההקדמה. החידה היא: לכמה חוטים תזדקקו אם במקום נורית אחת תצטרכו לשלוט בשתיים?
התשובה האינטואיטיבית היא שלושה: שניים למתח ואחד משותף ל-Ground (או להיפך). אבל אם היישום הספציפי אינו מצריך הפעלה של שתי הנוריות בו-זמנית, אפשר להסתפק בשניים! בואו ונראה איך…
כשעלה הצורך לקנות ונטה, ולא חשוב כרגע למה, ניצבו בפני שתי ברירות: ונטה חד-כיוונית "פשוטה", או ונטה משוכללת במחיר כמעט כפול, שאפשר להחליף בה את כיוון המאוורר לפי הצורך. הפונקציה הדו-כיוונית נראתה לי מספיק שימושית, בהתחשב בצרכים, כדי להשקיע את הסכום הנוסף, אך בתוך הקופסה חיכתה לי הפתעה לא נעימה. במקום מתג מובנה פשוט, או חוט משיכה להחלפת הכיוון, נראה היה שקיבלתי רק "תשתית להחלפה". שיחה זועמת לחנות אישרה את החשד: כדי לבצע את החלפת הכיוון בפועל, בהנחה שלא בא לי לפרק את הוונטה כולה ולהבריג החוצה ופנימה חוטים כל פעם מחדש, אזדקק למפסק קיר מיוחד (שעולה בערך כמו ונטה חד-כיוונית), וכמובן שהתקנתו צריכה להתבצע על ידי טכנאי מטעם החנות, שגם הוא מן הסתם לא עובד בחינם.
במקרים כאלה, התגובה הספונטנית שלי היא – וסליחה על הביטוי – זובי. רוצים לסחוט ממני ארבע-מאות שקל אקסטרה על משהו שהיה אמור להיות במוצר המקורי? בפרנציפ אני אמצא לבד פתרון נוח וזול יותר. פוסט זה הוא סיפורו של הפתרון שמצאתי.
בפוסט קצר זה אדגים את השימוש בחיישן קרבה אופטי קטן וזול, שמסוגל להבחין בגופים בטווח של סנטימטר או שניים (לכן הוא נקרא חיישן קרבה ולא חיישן מרחק). למה רכיב כזה טוב? סבלנות. קודם כל, בואו ונראה את החיישן בפעולה:
כזכור, אני מנסה ליצור עבור הארדואינו מודול זיכרון של 64 קילובייט משני ג'וקים של זיכרון סריאלי, בני 32 קילובייט כל אחד, וזאת באמצעות אותו מספר חיבורים שנדרש עבור ג'וק יחיד בפרוטוקול SPI בו הם עובדים.
בעיקרון, חיבור CS (בחירת ג'וק, או Chip Select) אמור להיות "גבוה" כל הזמן, ולרדת רק למשך פעולת קריאה או כתיבה. הגישה ל-32K נעשית באמצעות כתובות בנות 15 ביטים (32,768 כתובות שונות, מ-0 ועד 32,767), והרעיון שלי היה לנצל את הביט הנוסף בטיפוס הנתונים int (בן 16 הביטים) כדי לבחור לאיזה משני הג'וקים להוריד את ה-CS, וכך להשיג טווח כתובות גדול פי שניים. על הדרך ניסיתי גם לחסוך בחוט ולבצע פעולות קלט ופלט על אותו קו כביכול. זה לא עבד, אבל השאר כן והנה ההוכחה:
תופעה מרגיזה במיוחד, עם פוטנציאל גבוה לשגע חובבי ארדואינו מתחילים, היא זו של החיבורים הצפים. במילים פשוטות, אם ננסה לקרוא ערכי מתח ממקור שאינו חולק את ה-Ground עם הארדואינו עצמו, תוצאות הקריאה עלולות להיות אקראיות ו/או שונות לגמרי מהצפוי.
התוכנה הראשית של פרויקט MBM אמורה לאסוף ולטפל בהמון נתונים. כמה זה המון? תלוי במשתמש: במקרים קיצוניים, הכמות יכולה להגיע לכמאה מגהבייט ביום. כל הנתונים מגיעים בפורמט קבוע ומובנה. נשמע כמו מקרה קלאסי לשימוש במסד נתונים, נכון? אך לאחר בדיקת הנושא לעומק החלטתי לוותר על הרעיון ולעבוד ישירות עם קבצים גולמיים, שינוהלו על ידי התוכנה עצמה. מה עומד מאחורי ההחלטה המוזרה הזו?