אני מניח שכבר ראיתם את שלט הכפפה שהכנתי למכונית-על-שלט (אם לא, הסרטון נמצא כאן). בפוסט זה אדבר על פתרון קטן וחכם, שאמנם לא אני המצאתי אבל השתמשתי בו כדי לשפר את השליטה במכונית, ואציג את ההקשר הרחב והחשוב הרבה יותר של הפתרון הזה – בעולם האלקטרוניקה בכלל וביישומים "בעולם האמתי" בפרט.
איך לא להרוג את ה-EEPROM
מספרים על אחד המדענים הגדולים, שהעביר הרצאה לקהל הרחב וציין, בין השאר, שבעוד חמישה מיליארדי שנים השמש שלנו תהפוך לענק אדום ותשמיד את כל החיים על פני כדור הארץ.
"בעוד כמה זמן?!" זעקה פתאום בבהלה קשישה אחת מהקהל.
"חמישה מיליארדי שנים, גברתי,"
"איזה מזל," נרגעה הקשישה, "חשבתי שאמרת חמישה מיליונים."
אני נזכר בבדיחה הזאת בכל פעם שחובב מודאג שואל לגבי מגבלת 100,000 הכתיבות לזיכרון ה-EEPROM של הארדואינו. הרי מאה אלף זה הגבול התחתון, ובשימוש סביר (לא אופטימלי – סתם סביר), אפילו אם מגיעים למאה כתיבות ביום, שזה המון, עדיין מקבלים יותר משנתיים וחצי רצופות של פעילות מובטחת ללא תקלות. מישהו באמת חושב להריץ יישום אחד על ארדואינו אחד במשך שנתיים וחצי? מישהו באמת חושב שכל השאר יעבוד פיקס במשך כל הזמן הזה, ורק ה-EEPROM המידרדר לאיטו יגרום לקטסטרופה?
ובכל זאת, שימוש סביר ב-EEPROM לא דומה למה שאנחנו עושים עם זיכרון ה-SRAM הרגיל, וכדאי להקדיש לו קצת מחשבה. בפוסט זה אסקור מספר טכניקות ואמצעי זהירות, שיעזרו לכם להפיק את המקסימום מהתכונה המיוחדת הזו של המיקרו-בקר.
avrdude: stk500_getsync(): not in sync: resp=0x00
לא, הכותרת היא לא באג במערכת הניהול של הבלוג, אלא אחת מהודעות השגיאה הנפוצות ביותר שמתחילים נתקלים בהן בעבודה עם ארדואינו. בפוסט זה אסביר את מהות הבעיה, מהם הגורמים הנפוצים לה – ומכאן, כמובן, גם איך לפתור אותה.
להמשיך לקרוא avrdude: stk500_getsync(): not in sync: resp=0x00
על השחיטה
במהלך השנה האחרונה יצא לי לפרק המון מכשירים חשמליים פירוק טוטאלי ובלתי הפיך (מה שנהוג לכנות בשם "שחיטה"), ומכיוון שלא פעם חובבי אלקטרוניקה מתחילים שואלים אילו רכיבים אפשר להוציא ממחשב ישן, או מכשיר מקולקל אחר, החלטתי לכתוב על תהליך השחיטה – מתי כדאי לשחוט, איך עושים זאת נכון ולמה אפשר לצפות בסיום.
הקורבן: מקצף ידני (מלוכלך אבל מהמטבח שלי, אז זה בסדר) להמשיך לקרוא על השחיטה
למה עברנו?
פוסט זה מיועד לכל חברי קהילת חובבי המיקרו-בקרים הישראלית, שנפלנו עליהם כרעם ביום בהיר והודענו שזהו, הפעילות עוברת מקבוצת הפייסבוק לאתר makers.co.il. המהלך הזה מעלה שתי שאלות חשובות שמן הראוי לענות עליהן. קודם כל, למה? ודבר שני, באיזו זכות?
זאת אומרת, דבר ראשון, למה לקחת קהילה פעילה וכיפית שבאמת עוזרת לחברים, ולהעביר אותה בבת אחת למקום אחר ולא-מוכר? ויותר מזה, מי הסמיך אותנו – הקבוצה הקטנה שאחראית למעבר הזה – לקבל את ההחלטה בשם כולם, ועוד לבקש מהאחרים לעבור בלי שהתייעצנו איתם מראש?
אם השאלות האלה הטרידו אתכם (וגם אם לא), כדאי שתקראו את התשובות בהמשך הפוסט. הכל יהיה ברור יותר.
קהילת הארדואינו הישראלית עברה דירה
עדכון: כל האתרים והלינקים בפוסט אינם קיימים או אינם רלוונטיים יותר, לצערי!
כשהיינו קטנים (וב"היינו" הכוונה לקהילת חובבי הארדואינו המקומית), פתחנו קבוצה בפייסבוק כדי שלא נצטרך להריץ מיילים בינינו כל הזמן. זה היה בשבעה-עשר באפריל 2012. בראשון באוגוסט 2012 קיימנו את הכנס הראשון, ופחות מחצי שנה לאחר מכן, הקבוצה כבר מנתה קרוב לשלוש-מאות חברים. אמנם לא כולם היו משתתפים פעילים, אך הפוסטים רצו ועוד איך.
בעשרים ותשעה בינואר 2013 נפגשנו, רוב חברי "הגרעין הקשה" המקורי ומספר פעילים בולטים חדשים, במעבדת XLN בתל אביב כדי לדון בהתפתחויות. התוכנית המקורית למפגש היתה למצוא דרכים להגדיל ולקדם את הקהילה, אך הרבה דברים הבשילו בינתיים ברקע, והרי התוצאה: makers.co.il, אתר הבית החדש של קהילת המייקרים הישראלית.
האתר מתמקד בינתיים במיקרו-בקרים, ארדואינו ואלקטרוניקה, ומקבל בברכה גם תחומים משיקים. יש בו מערכת פורומים משוכללת, ויקימדיה פתוחה, פרופילי משתמש עם אלבומים ובלוגים למי שרוצה, מסרים פרטיים, עדכונים, חיבור לפייסבוק ומה לא. אנחנו מעבירים את כובד הפעילות שלנו לשם, ומזמינים את החברים הקיימים ואת חובבי הארדואינו החדשים להגיע למקום שבו הכל קורה מעכשיו!
תודה ליוני, מעיין, אורן, אוריאל, עדי, ארנון, משה ומתן על היוזמות, ההתגייסות למשימה ועל הדחיפה ההדדית קדימה. להתראות ב-makers.co.il, ואם אתם כבר שם, אל תשכחו לקפוץ לבקר בפינה הפרטית שלי באתר – הבלוג "הבייט הלבן ג'וניור".
תקשורת קווית לטווח ארוך עם RS-485
קיץ 1997. שני עתודאים צעירים באמצע שום מקום, שומרים ימים ולילות על שום דבר. לידם טלפון שדה ענתיקה שמחובר, בתיאוריה, לעמדת שמירה נוספת במרחק כמה מאות מטרים, אבל הוא הפסיק לעבוד. אף אחד לא יודע אם הבעיה באחד המכשירים, או שיש נתק איפשהו בכבל שעובר ביניהם, קבור למחצה בחול לאורך כל הדרך.
"מה הבעיה," אומר העתודאי לפסיכולוגיה, "בכבל הרי יש שני חוטים – נחבר סוללה בצד אחד, איזה LED בצד השני ונראה מיד אם יש נתק או לא."
"זה לא כל כך פשוט," מסביר העתודאי להנדסת חשמל, "כשהכבלים בכזה אורך, יש להם התנגדות והשראה וכל מיני סיבוכים אחרים."
כשאנחנו – החובבים – חושבים על תקשורת בין רכיבים, אנחנו מדמיינים בדרך כלל כמה ג'וקים או לוחות שמחוברים פחות או יותר לאותה מטריצה, אם לא ממש רוכבים אחד על השני, והחוטים שמשמשים להעברת מידע ביניהם הם קצרצרים בהתאם. תקשורת קווית בין חדרים נחשבת יוצאת-דופן, וגם כשהיא מתבצעת, בדרך כלל מדובר על סיגנלים פשוטים מאד (כגון קריאה מחיישן ON/OFF או שליחת/הפסקת זרם לאלקטרומגנט). בתנאים כאלה הדברים נוטים לעבוד בלי תקלה, אך כאשר טווחי התקשורת מתארכים, התכונות של הכבלים עצמם והפרעות אלקטרומגנטיות מסביבתם הופכות למשמעותיות ועלולות לפגוע בנתונים.
מבוא לאופטימיזציה (עם דוגמאות)
אופטימיזציה של קוד פירושה שינוי של קוד תוכנה כך, שיבצע בדיוק את אותה משימה שביצע קודם, אך בצורה יעילה יותר. היעילות נמדדת בהתאם למטרה, שהיא לרוב מהירות ריצה גבוהה יותר או חיסכון בזיכרון. אלו הם סוגי האופטימיזציה השכיחים, אם כי ייתכנו בהחלט גם אחרים – במיוחד בעולם המיקרו-בקרים (כגון אופטימיזציה לחיסכון בחשמל). כמו כן, בהנחה שהקוד המקורי היה כתוב באיכות טובה, השגת מטרה אחת של אופטימיזציה תבוא בדרך כלל על חשבון האחרות.
תמונת רקע באפס זיכרון
הנה דוגמה בסיסית לאופטימיזציה של זיכרון. בסרטון הבא מוצג יישום קטן שכתבתי עבור ה-MSP430 Launchpad, שמציג על גבי מסך LCD זול של Nokia 5110 מלבנים מעופפים מעל רקע פיקסלים אקראי.
איך תופסים שגיאות (גם באוויר!)
בפוסט הקודם סיפרתי על בעיה שהתגלתה בהעברת מידע דרך החיבור הטורי (Serial port) בין הארדואינו למחשב. פיזית, המידע עבר דרך כבל USB רגיל, אך זה היה שלב ניסויי בלבד – כי הלקוח שעבורו נבנית המערכת זקוק להעברת מידע אלחוטית. בפוסט זה אסביר איך בוצע המעבר לאלחוט, ואתן מבוא קצרצר לנושא של איתור שגיאות בתקשורת.
לתפוס רוצח (נתונים) סדרתי
מי שעוקב אחרי הבלוג יודע שאני לא מחבב ספריות קוד מוכנות. יש לכך שתי סיבות. ראשית, כשמשתמשים בקוד מוכן של מישהו אחר, הנטיה היא פשוט ליישם אותו, וכך מתפספסת כל הלמידה של האופן בו הדברים נעשים באמת. שנית, אין שום אחריות שקוד של מישהו אחר יעבוד בצורה יעילה, או בכל התנאים האפשריים, או בהתאמה מיטבית ליישום הספציפי שלנו – או בכלל!
כמובן, לעתים קרובות אין ברירה אלא להשתמש בקוד מוכן, מפני שהוא מבצע משימה מסובכת מכדי שנכתוב אותה לבד, או שפשוט אין לנו זמן לכך. כשבחרתי בספריות של TurboPower Async Professional למימוש תקשורת טורית בין יישומים שאני כותב בדלפי לבין הארדואינו, אלה היו השיקולים שהנחו אותי. זהו גם קוד מוכר וותיק, כך שהיו לי כל הסיבות לסמוך עליו… עד שעשיתי זאת בפועל.