82 / 124
זמן המעבד לפי העדיפות שלהם. אם תוך כדי
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
כשנדרשת פעולה מורכבת יותר שקורית
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
במידה ולא נדרשות יכולות
«
מבנה
.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
של
EMBEDDED & MICROPROCESSORS
מוסף מיוחד
New-Tech Magazine l 82