New-Tech Magazine | Aug 2017

EMBEDDED & MICROPROCESSORS מוסף מיוחד

זמן המעבד לפי העדיפות שלהם. אם תוך כדי thread הטיפול (קבלה ושליחה) יתעורר לעיתים יגדל Jitter אזי ה 155 בעדיפות גבוהה יותר מ משמעותית - בתלות באורכי המשימות ה"מפריעות" הללו. דוגמה זו ממחישה את המורכבות שנוספה עם השימוש בממשקים טוריים : חלקי הפרוטוקול השונים ארוכים יותר ויש הסתברות להגדלה . Jitter משמעותית של ה INtime מערכת ההפעלה זוהי מערכת ההפעלה שבה ביצענו את המדידות והתצוגה שתוארו למעלה. כמו כל מערכת הפעלה מלאה לזמן אמת היא בעלת התכונות הבאות ישנן שתי INtime – ל Interrupt driven Interrupt אפשרויות להתיחסות ל – ניתן להפסיק מיידית כל Preemptive לפי מפתח עדיפות . thread העדיפה ביותר 0 : רמות 255 - ישנן Priority הפחות עדיפה. 255 מערכת ההפעלה בעלת פונקציות מהירות מאד. של מערכת הפעלה מוגדרים תמיד threads ה בעדיפות נמוכה ככל האפשר (וניתנים ברובם לכוונון). . INtime מוצגים באדום מרכיבי 3 באיור מספר קיים גרעין שמעליו רצים תהליכים המסופקים ותהליכי היישום. לצידם (על ליבות INtime עם אחרות) - משורטט בכחול: נמצאת מערכת והתהליכים שהלקוח כותב Windows ההפעלה מעליה. בין שני החלקים קיים ממשק הקרוי לגשת Windows שמאפשר לתהליכים של NTX . פרט לגישה לזכרון INtime לאוביקטים של וכו’. semaphores mailbox משותף יש גישה ל Interrupts הפסיקות - מרכיב חשוב בכל מערכת הפעלה ובמיוחד במערכות הפעלה לזמן אמת הוא אופן הטיפול . כל מערכת הפעלה תומכת ב Interrupts ב- , אבל רק מערכות הפעלה לזמן אמת Interrupts לנהל אותם User Mode מאפשרת למשתמש ב ישירות . user יכולות ההפעלה של הפסיקות ברמת ה נמוך. Jitter חשובות מאד כדי להבטיח קימות שתי רמות : INtime ב Interrupt handler כותבים בדרך Handler מופעלת על ידי חומרה. ב כלל מעט מאד פקודות, והכניסה והיציאה ממנו מהירים מאד. Interrupt thread כשנדרשת פעולה מורכבת יותר שקורית

מבנה .3 איור INtime התוכנה ב For Windows

«

בקונפיגורציה Code Base ניתן להשתמש באותו בכל Boot מבצע INtime .5.2 המוצגת באיור הליבות שלו ישירות מהדיסק , ולא דרך תהליכים ש"מעירים" אותו. Windows של איך נבנה את הפרויקט שיש Embedded הפתרון המומלץ לבנית מערכת timing (או קרוב לוודאי שיהיו עבורה) דרישות למממשקים: INtime for הגדרת המערכת הבסיסית עם Windows העברת הממשקים שעבורם יש דרישות INtime תזמון ל במהלך הפרויקט ניתן לשנות את נקודת החלוקה לצד INtime בין ההתקנים והתהליכים מצד ולהיפך, ואפילו להגיע לקונפיגורציה windows Visual בכלל. כל הפיתוח נעשה ב Windows ללא כך Windows וגם בצד INtime גם בצד Studio שהעברת הקוד בין שתי הסביבות קלה ביותר. כפי שראינו בדוגמא של הממשק הטורי (הוצג ) , משימות רבות, שחלקן אפילו UDP ממשק מסופק על ידי מערכת ההפעלה, מתחרות על . CPU המשאב החיוני – זמן מצד שני – אם מאות משימות תתחרינה על נמוך – ניאלץ Jitter המשאב הזה , ונרצה להבטיח לבצע עבודת כוונון מורכבת של ניסוי וטעיה. לכן נשאיר את כל התהליכים שאינם מחייבים . Windows נמוך ב Jitter לעומת זאת אם אין כלל תהליכים "טבעיים" ל מורכב או File System או GUI (כמו Windows ואינם קיימים ב Windows שקיימים ב- Drivers ) כדאי לשקול להשתמש בקונפיגורציה INtime . INtime Only של

handler אחר, ה thread כשמפסיקים ריצה של אינו חוזר ישר לנקודה בה ארע, אלא מכניס חדש ובו מקודדת thread לפעולה, לפי עדיפות , המשימה המורכבת. - משימה זו 2 למשל בניסוי שתואר באיור מספר . 54 של הכרטיס שרצה בעדיפות driver היא ה . interrupt מראה את שני סוגי ה- 4 איור מספר שימוש מושכל בהם במהלך התכנון – מבטיח נמוך . Jitter ריבוי ליבות בשנים האחרונות הפכו המעבדים למרובי ליבות ובוני המערכות מעונינים לנצלן כמה שאפשר. עליהם Linux או Windows במערכות הפעלה כמו בכל יחידת זמן threads רצחם מאות או אלפי – מנהלת מערכת ההפעלה עצמה את חלוקת SMP המשאבים "בצורה הוגנת" בשיטת ( ). ליבה אחת Symmetrical Multi Processing מבצעת תזמון והקצאת משאבים (זכרון וזמן מעבד) עבור כל הליבות. ניהול כזה אינו מאפשר נמוך, ובנוסף ניפוי שגיאות בנושא תזמונים Jitter הוא משימה מורכבת ביותר. נמוך, אינן Jitter מערכות לזמן אמת שחייבות יכולות להעביר את השליטה למנגנון "הוגן", ובנויות כך שכל ליבה מנהלת את המשאבים AMP - Asymmetric Multi שלה. זוהי שיטת . Processing מציג שלש קונפיגורציות בהן 5.1 איור מספר .Windows רצה לצידה של INtime מעל כל הליבות "שלה" SMP רצה ב- Windows רצה INtime .על כל ליבה "של" AMP ב- INtime ו- מערכת הפעלה מלאה שמתקשרת עם האחרות באמצעים שונים. מהיישום, Windows במידה ולא נדרשות יכולות

New-Tech Magazine l 82