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

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

אז זהו, שלא. בתור התחלה, המוניטור הטורי – שקיבל מידע בזמן אמת מהתוכנה שעל לוח הארדואינו – השתתק פתאום, וסביבת הפיתוח העלתה הודעת שגיאה שאין חיבור. תוך כדי חיפוש המקור לבעיה נגעתי בכניסת ה-USB של הלוח, והיא היתה חמה מאד. הג'וק הסמוך אליה, זה שאחראי לניהול התקשורת דרך ה-USB, רתח. לא מספיק כדי להעלות עשן או להסריח, אבל מספיק כדי להתפגר. בדיקה זריזה העלתה שפין ה-Vcc הארור כלל לא היה מיועד לאספקת חשמל לבקר, אלא היה מחובר ישירות לכניסת הפלוס של המנוע! במקום להעביר ללוח חמישה וולט, הארדואינו ספג לפין 5V מתח של 9 וולט בזרם של אמפר שלם, פחות או יותר. למה דווקא רכיב התקשורת נפגע? אינני יודע, אולי זה עניין של אופן החיווט, אולי רגישות גבוהה, אולי שניהם גם יחד.

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

תקשורת חלופית

למרבה המזל, יש דרך חלופית לתקשר עם המיקרו-בקר*. הרי התקשורת הסריאלית מתבצעת, בסופו של דבר, דרך הפינים RXD/TXD של ה-ATMega328, שמחוברים לכניסות 0 ו-1 בלוח הארדואינו, והשבב שנשרף אצלי הוא בסך הכל ממיר מפרוטוקול USB לפרוטוקול סריאלי עבור הפינים האלה. תמורת דולרים בודדים אפשר להשיג באיביי או באתרי הגאדג'טים הסיניים "ממירים" חיצוניים שעושים את אותו הדבר בדיוק. בדרך כלל הם נקראים "USB to UART" או "USB to TTL". הם מתחברים ל-USB של המחשב מצד אחד, ולארדואינו מצד שני בעזרת פינים וחוטים סטנדרטיים. הזכרתי רכיב כזה בעבר, כאן.

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

בין הפינים של ה-USB-to-TTL הנפוצים יש אחד שמסומן RST, זאת אומרת Reset, אך הוא לא שולח את הפקודה המתאימה. למעשה, הוא מיועד לאיפוס של רכיב התקשורת עצמו ולא של המיקרו-בקר. כדי לאתחל את הארדואינו צריך ללחוץ ידנית על לחצן האיפוס שעל הלוח בדיוק ברגע הנכון, או לחלופין לאתר את יציאת DTR (ראשי תיבות של Data Terminal Ready) של רכיב התקשורת, ולהוציא ממנה חוט אל פין ה-RESET של הארדואינו. למזלי, ברכיב התקשורת שלי יש יציאת DTR מסודרת – רק להלחים פין או חוט. ברכיבים אחרים צריך ידיים יציבות כמו של מנתח מוח כדי להתחבר ישירות לאחת הרגליים הזעירות של הג'וק.

עד כאן הכל טוב ויפה, חוץ מדבר קטן אחד: בפועל, ה-DTR לא הצליח לאפס את הארדואינו. כדי שיתבצע איפוס, הפקודה לפין ה-RESET של המיקרו-בקר צריכה להימשך פרק זמן מסוים – 2.5 מיקרושניות לכל הפחות, לפי מפרט ה-ATMega328 – ואילו ה-DTR שולח פולס קצר מדי!

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

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