בעבודה עם רכיבים אלקטרוניים, ה-Datasheet הוא ידידו הטוב ביותר של האדם. עם זאת, במיקרו-בקרים ורכיבים מתקדמים אחרים, קיים מסמך נוסף שמפתחים רציניים חייבים להכיר: ה-Errata.
את ה-Errata (בלטינית "טעויות") כבר הזכרתי פעם או פעמיים בעבר בבלוג, אך הפעם החלטתי להקדיש למסמך חשוב זה פוסט שלם. הטריגר לפוסט היה הגילוי שהתחילו למכור מיקרו-בקרים ממשפחת K42 החדשה של Microchip. לא ניכנס לפרטים כאן, מספיק לומר שהמשפחה הזו מייצגת מהפכה גדולה בעולם ה-PIC, והתקדמות שצריכה להדאיג את כל המתחרים בזירת ה-8-ביט; רציתי מאוד להשיג אחד או שניים כאלה ולשחק איתם קצת.
אלא שהמציאות לא תמיד יפה כמו בחומרים השיווקיים, ולעתים קרובות ג'וקים חדשים שיוצאים לשוק כוללים כמה באגים בחומרה. ה-Datasheet מפרט את התכונות של הג'וק רק על פי התוכנית המקורית, לא לפי איך שהם ירדו בפועל מפס הייצור, ובין התוכנית לייצור יכולות להתרחש כל מיני תקלות. התקלות שמזוהות נרשמות בקובץ ה-Errata. חברות שונות קוראות לו בשמות קצת שונים (למשל Silicon Errata או Erratasheet), אבל הכוונה זהה.
זה נכון שקשה להימנע לחלוטין מבאגים, ובכל זאת יש משהו קצת מסריח בקטע הזה. לדוגמה, ה-K42 יצאו לשוק לפני פחות מחודש, ולכן אין מצב שה-Errata הנוכחי שלהם מבוסס על פידבק ממשתמשים בשטח. מישהו בחברה עצמה ערך בדיקות יסודיות, עלה על תקלות וניסח אותן בצורה מסודרת במסמך. זאת אומרת שהחברה ידעה מראש שהיא מוציאה לשוק שבבים תקולים. אז למה לא לעצור את הייצור/הפצה, לתקן מה שאפשר ולספק ללקוחות שבב נקי מבאגים כבר מהקנייה הראשונה?
לצערנו, כל היצרנים עושים את זה, וכמו שקורה גם בהרבה מוצרי תוכנה כיום, הלקוח הופך להיות – נגד רצונו – בודק הבטא של החברות. מי שזה מתאים לו סבבה, ומי שלא (כמוני) יחכה לגרסאות הסיליקון הבאות והמשופרות של הרכיב – בשאיפה שיהיו כאלה. עד אז, בואו ונראה מה יש במסמך Errata טיפוסי.
החלק החשוב הראשון הוא טבלת הסיכום, שמתארת בקצרה את הבאגים המוכרים ואת גרסאות הסיליקון שבהן הם קיימים. עיון בטבלה הזו יכול לגלות לנו עד כמה המצב חמור באופן כללי, ועד כמה זה רלוונטי ליישום ספציפי שאנחנו צריכים. למשל, אם למיקרו-בקר מסוים מפורטות עשר תקלות במודול DAC, יכול להיות שזה עדיין יהיה בסדר גמור מבחינתנו אם אין לנו שום כוונה להשתמש ב-DAC. כמו כן, אם השגנו גרסת סיליקון חדשה ומעודכנת, ייתכן שנראה שרוב הבעיות בכלל לא קיימות יותר.
בהמשך המסמך מחכה לנו הפירוט של התקלות האלה. לגבי כל אחת יש תיאור מפורט של התנאים בהם היא באה לידי ביטוי, וכן – חשוב מאוד! – דרכים להתמודד איתה או לעקוף אותה (Workaround), אם יש כאלה. לפעמים הפתרון המוצע הוא משהו אזוטרי שצריך להתרחש ברמת הקומפיילר או קוד האסמבלי, לפעמים זה משהו פשוט שגם אנחנו יכולים לבצע בקלות בקוד שלנו, ולפעמים אין שום פתרון.
לסיום, בחלק ממסמכי ה-Errata (למשל באלה של Microchip) מופיעות גם "הבהרות" לגבי ה-Datasheet, כלומר הסברים ותיקונים שלא הספיקו להיכנס לגרסה הנוכחית שלו. ליתר ביטחון כדאי לסקור גם את שאר המסמך, ולבדוק שלא החביאו בו הפתעות לא נעימות נוספות.
צריך לזכור שה-Errata הוא לא הסמכות המוחלטת והסופית בנושא באגים בחומרה: מה שמופיע בו הם רק הבאגים שזוהו. ייתכן בהחלט שיש עוד בעיות שאורבות שם בפנים, ושאתם תהיו בין הראשונים שיסבלו מהן…
תוספת מאוחרת: בדרך כלל ה-Errata נמצא באותו מקום עם ה-Datasheet, אבל אם לא מוצאים אותו בשום מקום, ייתכן שהתוכן כלול בתוך ה-Datasheet עצמו. כרגיל, לכל יצרן יש דרך משלו לעשות דברים.
נו באמת… עוד RTFM אחד…
מניסיון, צריך לפחות 2-3 גרסות revisions לצ'יפים, כך שאם אתה רוצה משהו יציב, אל תשתמש בצ'יפים שה-revision שלהם הוא A או B.
בהנחה שלא הכניסו עוד באגים ב-C והלאה…
תלוי במורכבות של הג'וק (בפני עצמו, ובמידת השינוי לעומת דגמים קודמים) וגם במי שמייצר אותו. לפעמים יש רק תקלות זניחות יחסית, לפעמים יש יצרנים שלא טורחים לתקן מגילה שלמה של באגים גם אחרי שנים (*שיעול*TI*שיעול*)… בכל אופן רצוי מאוד לבדוק גם את המסמך הזה לפני שמקבלים החלטה.