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

נתחיל במקום בו הפסקנו בפעם שעברה, עם המדידה של אות ה-PWM. זוכרים?

תזמון חופשי

נניח שאני רוצה לדעת כמה זמן בדיוק עבר מתחילת הפולס השני של ה-PWM ועד לסוף הפולס החמישי. לשם כך, נעבור לפאנל Measurements שמימין לגרפים (ראו בתמונה הבאה). בין השאר, מופיעות שם השורות T1 ו-T2. אם במקרה הן לא מופיעות אצלכם, לחצו על אייקון גלגל השיניים מימין למעלה וסמנו את Show Timing Markers. שתי השורות מסומנות בקו תחתון, כמו לינקים. לחצו על כל אחת מהן כדי לסמן על הגרף, באמצעות העכבר, את נקודות הזמן הרצויות. כדי לעזור לנו, הקווים "נדבקים" למעברים הלוגיים בשורה שבה מצביע העכבר נמצא. למה? כי קשה לחשוב על סיבה למדוד בין נקודות שלא קורה בהן כלום, נכון? אגב, כדי למחוק את הסימונים האלה, לוחצים שוב על השורה הרצויה מימין, ואז על Esc או לחצן העכבר הימני.

בתמונה למעלה רואים את מה שקיבלנו בסיום התהליך. שימו לב לשלוש השורות התחתונות בפאנל Measurements: השורות T1 ו-T2 מציגות את הזמנים המדויקים שבהם הצבנו את הסמנים, והשורה | T1 – T2 | מראה את ההפרש ביניהם בערך מוחלט, וכן את דיוק המדידה. במקרה שלנו, הזמן שעבר בין נקודות הזמן שבחרתי הוא 3.336 אלפיות השניה.

תזמוני סיגנלים

השורות האחרות מספקות לי מידע מעניין נוסף. כאשר אני עובר עם העכבר על ערוץ שיש בו שינויים לוגיים, מסומנים לי אוטומטית שני חיצים אופקיים – אחד דו-ראשי על פרק הזמן בו סמן העכבר נמצא, בין מעבר לוגי אחד לשני, ואחד רגיל על פרק הזמן שאחריו (עד למעבר הלוגי הבא). התוכנה שלי סירבה ללכוד את הסמן, אז תצטרכו להאמין שהוא עמד על ערוץ 0, טיפה מתחת ומימין לסימון 1ms+ :

השורה Width אומרת מה רוחב הסיגנל שמסומן בחץ הדו-ראשי. השורה Period אומרת מה משך הזמן הכולל של שני החיצים גם יחד, ואילו Duty Cycle מציינת את היחס בין הסיגנל הראשון לבין הסכום. בתמונה אפשר לראות שהיחס בין הסיגנל הגבוה לבין פרק הזמן של גבוה+נמוך הוא כ-25%. זה הגיוני לגמרי, כי אם תסתכלו בקוד שבפוסט הקודם תראו שהדגימה היתה של אות PWM בעל Duty Cycle של 64 – כמעט בדיוק 25% מהמקסימום שפקודת analogWrite מקבלת.

השורה הבאה, Frequency, אומרת כמה פעמים פרק הזמן של שני החיצים גם יחד נכנס בשניה אחת, ואם זהו אות מחזורי נוכל לדבר על תדר ממש. השורה שנשארה, Byte, למעשה עוברת על כל שמונת הערוצים ויוצרת בייט אחד מכל הביטים השונים. מה שמופיע לנו כאן זה 00001011. את שני הביטים בסוף קל להסביר – אלה ערוצים 0 ו-1 שהיו שניהם גבוהים בזמן שעליו עמדתי עם העכבר. אבל למה הביט הרביעי, ערוץ 3, גבוה גם כן? פשוט כי היציאה הזו בלוג'יק לא חוברה לשום דבר, וחיבור צף תמיד יכול לקבל ערכים בלתי צפויים.

פרוטוקולים

כעת נעלה לארדואינו קוד אחר, ששולח טקסט קבוע דרך ה-Serial פעם בשניה:

void setup() {
  Serial.begin(9600);
}

void loop() {
   delay(1000);
   Serial.println("Whitebyte");
}

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

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

קיבלנו רצף מסקרן למדי, אבל מה הוא אומר? כדי לגלות זאת נעבור לפאנל Analyzers, מתחת ל-Measurements. נלחץ על אייקון ה"+" מימין, ובתפריט הנפתח נבחר את הפרוטוקול הרצוי לנו, במקרה זה Async Serial. נקבל את החלון הבא:

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

מעל רצף האותות מופיע הפענוח שלהם לתווי ASCII, שמראים בבירור את המחרוזת שהארדואינו שלח – כולל תווי CR/LF הסמויים שפקודת Serial.println מוסיפה כדי שהמוניטור יעבור לשורה חדשה!

ועכשיו תורכם

לתוכנה יש עוד יכולות שימושיות, כגון ייצוא של התוצאות, ארגון ויזואלי נוח יותר של הערוצים וכדומה, אך את אלה אשאיר לכם לגלות לבד, ויש גם מדריך מסודר למשתמש – לחצו על Options (מימן למעלה בחלון) ועל User's Guide בתפריט.

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