כאשר מדבגים מערכת, קל מאד ליפול למלכודות של הנחות יסוד שגויות, שיבזבזו לנו המון זמן ויגרמו לתסכול רב. הנה דוגמה מהחיים האמתיים למצב שכזה.
למערכת שאני מפתח כעת היה באג רציני: מדי פעם היא היתה "מתרסקת" באופן מוזר במיוחד. בתפקוד הרגיל שלה, המערכת ביצעה סדרה קבועה של פעולות (שהסתיימה בהבהוב קצר של לד לאינדיקציה), המתינה רבע שניה וחוזר חלילה. אבל לפעמים, בזמן שהחזקתי אותה ביד, ההבהובים נפסקו למשך מספר שניות – ואחריהן הלד נדלק ולא כבה עוד כלל. כמובן שגם שאר הפעילות הסדירה של המערכת נתקעה. מה גורם לזה?
כמובן שבלי כל הפרטים הטכניים (שמטעמי סודיות אני לא יכול לספק כאן), אין לכם שום דרך אפילו לנחש, אז תצטרכו פשוט לקבל שהחשוד המיידי שלי היה שעון המערכת של המיקרו-בקר: חשבתי שמשהו משבש אותו, מאיט אותו לרמה שבה המערכת כבר לא מסוגלת להתמודד עם צורכי עיבוד המידע ונתקעת. נקודת התורפה של ההסבר הזה היתה שלא היה שום קוד פעיל שיכול לשנות את השעון בצורה כזו… אבל מדובר במיקרו-בקר ATmega328PB, שגם ככה כבר עשה לי צרות, ותמיד יכול להיות שאיזשהו מצביע סורר בתוכנה קופץ למקום אסור ומחולל בלגנים.
יש גם את העניין של הופעת הבאג רק כשהחזקתי את המערכת ביד. זה יכול להעיד על איזשהו קצר, או נתק, או מגע רופף – ומצד שני, יש על הלוח גם חיישנים שעשויים להגיב למצב הזה, כך שקשה לדעת מה הסיבה המדויקת.
בניסיון לבודד קודם כל את המקום בקוד שבו הבאג מופיע, שידרתי דרך חומרת הסריאל של המיקרו-בקר קוד מספרי שונה אחרי כל צעד וצעד בסדרת הפעולות של המערכת. כך, אם אראה שהשידורים האלה נפסקים תמיד אחרי קוד אחד ספציפי, אוכל לדעת שהבאג קשור איכשהו לפעולה שמגיעה אחרי הקוד הזה. ואכן, בדיוק לפי התחזית, בחמש או שש בדיקות נפרדות, בכל פעם שהבאג הופיע השידורים נפסקו אחרי קוד אחד מסוים: זה שלפני ההמתנה של רבע השניה. פה חשדתי. למה דווקא בשלב ההמתנה, שבו לא קורה שום דבר חוץ מההמתנה עצמה? זה לא היה הגיוני.
אבל מכיוון שכבר סימנתי את החשוד שלי, המשכתי באותו כיוון חקירה. הפעם, במקום רק לראות אילו קודים מופיעים, גם תיזמנתי אותם בעזרת לוג'יק אנלייזר. ואכן, בין הרצפים של הפעולות היו הפסקות של רבע שניה כצפוי – עד להופעת הבאג, שהראה כארבע שניות המתנה בין ההבהוב התקין האחרון של הלד ועד להידלקות הסופית. ארבע שניות זה פי שישה-עשר מרבע שניה. א-הה! שתיים-בחזקת-ארבע! זה לא היה פתרון אבל זה נראה כמו רמז משמעותי. אולי ככה אוכל להבין לאיזה תדר שעון המערכת עוברת, ומשם להסיק מה גרם לשינוי.
אלא שהפקטור היפה של 16 התגלה כמבוי סתום: החישובים לא הסתדרו. חזרתי ללוג'יק, עם שינוי בתוכנה: במקום רבע שניה, היא תחכה רק חמישית שניה. הפעם, משך ההמתנה האחרונה התארך ל-6.8 שניות… והבנתי שזה סתם, ושהפקטור שהתגלה קודם היה ממצא מקרי לגמרי. אילו רק הייתי מבצע עוד בדיקה בשלב הקודם הייתי רואה את זה מיד. אף פעם לא להסתפק בבדיקה יחידה!
אחרי עוד קצת מחשבה, תפסתי טעות ענקית נוספת שעשיתי בדרך למציאת הבאג. בכל הבדיקות שערכתי, הבאג אמנם הופיע תמיד בשלב ההמתנה, אבל שלב ההמתנה הזה ממושך פי כמה עשרות מהשלבים האחרים! מבחינה סטטיסטית נטו, גם אם הבאג אקראי לגמרי, ברוב המכריע של המקרים הוא יופיע בשלב ההמתנה. כמו שהסיכוי להתרחשות רעידת אדמה ביום חול גדול פי שישה מהסיכוי שהיא תתרחש בשבת. במילים אחרות, גם ה"ממצא" הזה היה חסר משמעות.
בקיצור, מכיוון שסמכתי יותר מדי על תחושת הבטן שמדובר בבעיית שעון, לא רק שחיפשתי את הבאג במקום הלא-נכון, גם עשיתי זאת בצורה רשלנית ובזבזתי כך זמן.
אתם בטח רוצים לדעת מה קרה אחר כך. ובכן, התחלתי מחדש בחיפוש שיטתי של הגורם הפיזי המדויק להופעת הבאג. האם זו תנועה שאני עושה עם היד? או נקודה מסוימת במעגל שאני נוגע בה? זה לא היה פשוט, עם כל החיבורים והרכיבים, אבל בסוף מצאתי: זה היה header אחד שחובר לפין RX של המיקרו-בקר. המגע שלי כנראה שינה לו לפעמים את המתח וגרם לו לחשוב שיש איזשהו שידור.
זה כשלעצמו לא נורא, אבל בפונקציית הפסיקה שכתבתי קודם בשביל RX, כל מה שעשיתי זה לבדוק אם יש שגיאה בקליטה, ואם לא, אז לקרוא את מה שיש בחוצץ (buffer). בבדיקה מדוקדקת יותר הסתבר שהחוצץ מתמלא גם אם יש שגיאה (כמו זו שהופיעה כשנגעתי ב-RX), וכל עוד לא מרוקנים אותו, הפסיקה פשוט מתעוררת שוב ושוב ושוב וחונקת את כל משאבי העיבוד של המיקרו-בקר…