למה פסיקות הן לב הקושחה
תכנון פסיקות בקושחה הוא אחד הנושאים שמבדילים קושחה יציבה מקושחה שנתקעת "לפעמים, אצל חלק מהלקוחות". פסיקה (Interrupt) היא מנגנון החומרה שעוצר את ריצת התוכנית כדי לטפל באירוע דחוף: תו שהגיע בתקשורת, לחיצת כפתור, טיימר שהסתיים, דגימה מחיישן. בלי פסיקות, המעבד היה צריך לבדוק כל ערוץ שוב ושוב (polling) — בזבוז אנרגיה וזמן תגובה. עם פסיקות שתוכננו רע — מתקבלים הבאגים הקשים ביותר לשחזור: קריסות אקראיות, נתונים משובשים ומערכת שקופאת פעם בשבוע.
העיקרון הראשון: שגרת פסיקה קצרה
שגרת הטיפול בפסיקה (ISR) חייבת להיות קצרה ככל האפשר: לאסוף את הנתון, לסמן דגל או לדחוף לתור — ולצאת. את העיבוד עצמו עושה הלולאה הראשית או משימה ייעודית. הסיבה: כל זמן שה-ISR רץ, פסיקות אחרות באותה עדיפות או נמוכה ממתינות. ISR שמבצע חישוב ארוך, כתיבה לזיכרון לא נדיף או — הגרוע מכול — המתנה בלולאה, גורם לאיבוד אירועים במקומות אחרים לגמרי במערכת. כלל אצבע: מיקרו-שניות, לא מילי-שניות.
תעדוף: לא הכול דחוף באותה מידה
מרבית הבקרים המודרניים תומכים ברמות עדיפות לפסיקות, כולל קינון — פסיקה דחופה שקוטעת ISR פחות דחוף. תכנון נכון מתחיל בטבלה פשוטה: כל מקורות הפסיקה במערכת, הקצב המקסימלי של כל אחד, וזמן התגובה המחייב. בטיחות ותקלות חומרה למעלה; תקשורת מהירה שדורשת מענה מיידי באמצע; אירועים איטיים כמו כפתורים למטה. הבחירה קשורה ישירות לארכיטקטורה הכללית — ב-RTOS חלק מהעבודה עובר למשימות עם עדיפויות משלהן, כמוסבר בRTOS או Bare Metal, וגם ליכולות הבקר שנבחר — ראו בחירת מיקרו-בקר למוצר.
המוקש הגדול: שיתוף נתונים בין ISR לקוד הראשי
כשה-ISR והקוד הראשי ניגשים לאותו משתנה, נוצר מצב מרוץ (Race Condition): הקוד הראשי קורא ערך באמצע עדכון ומקבל נתון לא עקבי. עקרונות ההגנה:
- משתנים משותפים מסומנים volatile כדי שהקומפיילר לא "ייעל" את הקריאה שלהם.
- גישה אטומית או חסימת פסיקות קצרה סביב עדכון של נתון רחב ממילת מעבד אחת — וקצרה באמת, כי חסימה ארוכה מחזירה אותנו לבעיית ה-ISR הארוך.
- תור מעגלי (Ring Buffer) חד-כיווני הוא הדפוס הבטוח והנפוץ להעברת נתוני תקשורת מה-ISR לקוד הראשי.
- לעולם לא לקרוא מתוך ISR לפונקציות שאינן בטוחות לפסיקות — הקצאת זיכרון, הדפסות, ורוב קריאות המערכת של RTOS בגרסתן הרגילה.
עוד עקרונות שחוסכים לילות דיבוג
- ניקוי דגל הפסיקה בזמן הנכון לפי הוראות יצרן הבקר — ניקוי שגוי גורם לפסיקה כפולה או לאובדן אירוע.
- סינון רעידות (Debounce) לכפתורים בתוכנה או בחומרה — כפתור מכני מייצר עשרות מעברים בלחיצה אחת.
- מדידה, לא ניחוש: מודדים את משך ה-ISR ואת העומס הכולל בעזרת פין GPIO ולוגיק אנלייזר — הכלים מפורטים בכלי דיבוג לפיתוח embedded.
- תכנון ליציאה משינה: במוצרי סוללה הפסיקות הן מה שמעיר את הבקר, והבחירה אילו מקורות מעירים אותו קובעת את צריכת החשמל — ראו מצבי שינה במיקרו-בקר.
- רשת ביטחון: גם עם תכנון מצוין, שילוב Watchdog מבטיח שהמערכת תתאושש ממצב לא צפוי — כמתואר בWatchdog ומנגנוני התאוששות.
איך זה נראה בתכנון מסודר
בפרויקט מנוהל נכון, מסמך ארכיטקטורת הקושחה כולל פרק פסיקות קצר: טבלת מקורות עם קצב ועדיפות לכל אחד, רשימת המשתנים המשותפים ומנגנון ההגנה של כל אחד, ותקציב זמן ל-ISR הארוך ביותר. שני עמודים שחוסכים שבועות. בבדיקות, מוסיפים תרחישי עומס מכוונים — הצפת תקשורת בקצב מקסימלי בזמן לחיצות כפתור ופעילות חיישנים — כי באגים של פסיקות מתגלים רק כשכמה אירועים מתנגשים באותה מילי-שנייה. מערכת שעוברת עומס משולב כזה במעבדה תשרוד גם את המקרים הנדירים בשטח.
השורה התחתונה
פסיקות אינן פרט מימוש שמשאירים לסוף — הן חלק מארכיטקטורת הקושחה שמתכננים ביום הראשון: מפת מקורות, עדיפויות, דפוסי שיתוף נתונים וכללי כתיבה אחידים לצוות. מוצר שעבר את התכנון הזה מגיב בזמן, ישן בחיסכון ולא קורס בשטח. עוד בנושאי קושחה למוצרים חדשים — בעמוד פיתוח תוכנה embedded.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
