שְׁאֵלָה:
RTOS למערכות משובצות
Kortuk
2009-12-03 02:59:25 UTC
view on stackexchange narkive permalink

ראיתי מאמרים רבים שאומרים לי שאני צריך להשתמש ב- RTOS לניהול זמן וניהול משאבים. הזמן שלי לא איפשר את המחקר שלי, אז אני מגיע לצ'יפאקר לקבלת ייעוץ.

אני משתמש במיקרו-בקרים בעלי משאבים נמוכים (MSP430, PIC) וחיפשתי RTOS שאוכל להשתמש בהם.

לעניין:

  1. עלות משאבים של המערכת
  2. יתרונות המערכת
  3. חסרונות המערכת
  4. טריקים של יישום
  5. מצבים ש- RTOS לא צריך / צריך להשתמש בהם.

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

אני מבולבל לגבי מה זה קיבל הצבעה למטה. אם הבוחר יוכל לתת לי משוב אנסה להימנע מפעולה כזו בעתיד.
כנ"ל. זו שאלה נהדרת ....
קיבלתי שאלה מכיוון שאפילו חשבתי שזו פתוחה, היו לי מספר תגובות נהדרות ורציתי לתגמל לפחות כותב אחד על המאמץ.
תֵשַׁע תשובות:
#1
+29
Jason S
2009-12-03 11:07:38 UTC
view on stackexchange narkive permalink

לא היה לי ניסיון אישי רב עם RTOS פרט ל- QNX (שזה נהדר בסך הכל אבל הוא לא זול וחוויתי ממש רע עם ספק לוח מסוים ועם הגישה הלא אכפתית של QNX למערכות שאינן הנפוצות ביותר) הגדולה מדי עבור PICs ו- MSP430.

היכן שתפיק תועלת מ- RTOS נמצא בתחומים כגון

  • ניהול / תזמון חוטים
  • תקשורת בין חוטים + סנכרון
  • קלט / פלט במערכות עם יציאות stdin / stdout / stderr או טוריות או תמיכת Ethernet או מערכת קבצים (לא MSP430 או PIC לרוב , למעט היציאות הטוריות)

עבור ציוד היקפי של PIC או MSP430: ליציאות סדרתיות הייתי משתמש במאגר צלצול + מפריע ... משהו שאני כותב פעם אחת למערכת ופשוט עושה שימוש חוזר ; ציוד היקפי אחר אני לא חושב שתמצא תמיכה רבה מ- RTOS, מכיוון שהם ספציפיים כל כך לספק.

אם אתה זקוק לתזמון מוצק סלעי למיקרו-שניה, כנראה ש- RTOS זכה ' לא עוזר - ל- RTOS יש עיתוי מוגבל, אך בדרך כלל יש עצבני תזמון בתזמון שלהם בגלל עיכובים בהחלפת הקשר ... QNX שפועל על PXA270 היה רטט בעשרות מיקרו-שניות אופייניות, 100-200us מקסימום, אז לא הייתי השתמש בו לדברים שצריכים לרוץ מהר יותר מכ- 100 הרץ או שזקוקים לתזמון הרבה יותר מדויק מכ- 500 משתמשים. עבור סוג כזה של דברים, כנראה שתצטרך ליישם את הטיפול בהפרעה שלך. יש כאלה של RTOS שישחקו יפה עם זה, ואחרים יהפכו את זה לכאב מלכותי: העיתוי שלך והתזמון שלהם לא יוכלו להתקיים היטב.

אם התזמון / התזמון אינו מורכב מדי, ייתכן שיהיה לך טוב יותר להשתמש במכונת מדינה מעוצבת היטב. אני ממליץ בחום לקרוא את Statecharts מעשי ב- C / C ++ אם עדיין לא עשית זאת. השתמשנו בגישה זו בחלק מהפרויקטים שלנו שבהם אני עובד, ויש לה כמה יתרונות אמיתיים על פני מכונות מדינה מסורתיות לניהול מורכבות ... וזו באמת הסיבה היחידה שאתה צריך RTOS.

אני עובד בחברת סטארטאפ בה החבר'ה למערכות מוטבעות המנוסות ביותר הם פשוט מחוץ לקולג '(כלומר אני והבחור השני שעובד איתי מזה כשנתיים). אני משקיע חלק גדול מאוד מהזמן בלימוד עצמי על פרקטיקה בתעשייה במהלך שבוע העבודה שלי. כפי שקראתי הודיעו לי לכל דבר, למעט מערכת העלות הנמוכה ביותר שלנו ש- RTOS יהיה שיפור גדול.
נראה שיש מערכת RTOS עם משאבים נמוכים מאוד לדברים כמו PICs ו- MSP430s שיכולים לעזור ליצור מערכת דטרמיניסטית מתוך מערכת מסובכת מאוד, וגם לנקות מאוד את הניהול שלנו של שמירת הפרדות בין המודולים. הייתי חלק מצוות שני אנשים שבנה למעשה מערכת איסוף וניתוב נתונים בשטח. עכשיו כשאני מסתכל על RTOS אני רואה שזה מושלם למה שתכננו.
סליחה על השימוש בשלושה משבצות פוסט, התשובה שלך מועילה מאוד, אני מחפש פיתרון משאבים נמוך מאוד, אך חשוב לקבל מידע זה, תודה על העזרה.
אל תדאגי לגבי ספירת התגובות (IMHO דבר אחד שחסרה במסגרת StackExchange זה תמיכה בדיונים ... פורמט Q / A מכסה את רוב הדברים אבל לא חלקם) ... נשמע שיש לך טיפול די טוב במה אתה מחפש. לא הסתכלתי על ה- FreeRTOS שסטיב הזכיר, אך אם הוא הועבר למיקרו-בקרים נמוכים אולי הוא יעשה את ניהול התזמון הדרוש לך.
נראה שהוא חוסך את המצב של כל שרשור על ידי הערימה (משהו כמו 50 הצהרות דחיפה / משיכה) ויכול להתמודד עם הפרעות מתוזמנות. המערכת שלי בדרך כלל תשתמש בהפסקת יציאה לצורך החלפת חוטים, אך המשימה נראית אפשרית. אני מאחל לאותו סוג זה לנהל דיונים בפורמט טוב יותר.
#2
+26
Steve Melnikoff
2009-12-03 06:05:08 UTC
view on stackexchange narkive permalink

ניסית את FreeRTOS? זה בחינם (בכפוף ל- T&C), והועבר הן ל- MSP430 והן למספר טעמים של PIC.

הוא קטן בהשוואה לחלק אחר, אך זה גם מקל ללמוד, במיוחד אם לא השתמשת בעבר ב- RTOS.

רישיון מסחרי (ללא תשלום) זמין, כמו גם גרסת IEC 61508 / SIL 3.

תודה רבה, אני אבדוק את זה תוך שבוע, אשאיר את השאלה פתוחה לתשובות אחרות, אבל אתה עוזר מאוד!
#3
+12
Jay Atkinson
2010-06-04 02:35:03 UTC
view on stackexchange narkive permalink

בדיוק גיליתי על NuttX RTOS, שיכול אפילו לעבוד על מערכת 8052 (8 סיביות). אין בו הרבה יציאות, אבל זה נראה מעניין. ה- POSIX יכול להיות יתרון, מכיוון שהוא עשוי להפוך חלק מהקוד שלך לנייד יותר אם תעלה למעבד בשרני יותר ותרצה להריץ לינוקס או QNX בזמן אמת.

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

אני ממליץ לך גם לחקור דרג ניתוח מונוטוני או RMA בעת שימוש ב- RTOS. זה יעזור לך להבטיח שהמשימות הקריטיות שלך יעמדו במועדי המועד שלהם.

הייתי בודק גם את מסגרת התכנות מונעת האירועים QP-nano של מירו סאמק שיכולה לעבוד עם או בלי RTOS ועדיין נותנים לך יכולת בזמן אמת. בעזרתו אתה מחלק את העיצוב שלך למכונות מדינה היררכיות במקום למשימות מסורתיות. ג'ייסון S הזכיר את ספרו של מירו בפוסט שלו. קריאה מעולה!

#4
+9
supercat
2011-03-16 09:06:07 UTC
view on stackexchange narkive permalink

דבר אחד שמצאתי שימושי במספר מכונות הוא מתג מחסנית פשוט. למעשה לא כתבתי אחד ל- PIC, אך הייתי מצפה שהגישה תפעל בסדר גמור ב- PIC18 אם שני / כל הנושאים משתמשים בסך הכל ברמות מחסנית של 31 או פחות. ב- 8051, השגרה העיקרית היא:

 _taskswitch: xch a, SP xch a, _altSP xch a, SP ret 

ב- PIC, אני שוכח את שם מצביע הערימה , אבל השגרה תהיה משהו כמו:

 _taskswitch: movlb _altSP >> 8 movf _altSP, w, b movff _STKPTR, altSP movwf _STKPTR, c return 

בתחילת לתכנית, התקשר לשגרה task2 () הטוענת את altSP עם כתובת הערימה החלופית (16 כנראה תפעל היטב עבור PIC18Fxx) ומריצה את loop the task2; אסור לחזור לשגרה זו אחרת הדברים ימותו מוות כואב. במקום זאת, היא צריכה להתקשר ל _taskswitch בכל פעם שהיא רוצה להעניק שליטה למשימה הראשית; המשימה הראשית צריכה להתקשר ל _taskswitch בכל פעם שהיא רוצה להיכנע למשימה המשנית. לעיתים קרובות יהיו לאחת שגרות קטנות וחמודות כמו:

 חלל עיכוב_ט 1 (val short לא חתום) {do Taskswitch (); בעוד ((קצר חתום) (millisecond_clock - val)> 0xFF00); } 

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

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

(עריכה): כמה אזהרות לגבי משתנים אוטומטיים וכאלה:

  1. אם קוראים לשגרה שמשתמשת בהחלפת משימות משני האשכולות, בדרך כלל יהיה צורך לקמפל שני עותקים של השגרה (אולי על ידי # הכללת אותו קובץ מקור פעמיים, עם הצהרות שונות #define). כל קובץ מקור נתון יכיל קוד לשרשור אחד בלבד, או שהוא יכיל קוד שיורכב פעמיים - פעם אחת לכל שרשור - כך שאוכל להשתמש במקרו כמו "#define delay (x) delay_t1 (x)" או #define delay (x) delay_tx (x) "תלוי באיזה שרשור אני משתמש.
  2. אני מאמין שמהדריכי PIC שאינם יכולים" לראות "פונקציה שנקראת, מניחים שפונקציה כזו עשויה לאשפה כל דבר רושם מעבד ובכך נמנע מהצורך לשמור רישומים כלשהם בשגרת החלפת המשימות [יתרון נחמד בהשוואה למולטי-טאסקינג מונע]. כל מי ששוקל לעבור על משימות משימות דומות לכל מעבד אחר צריך להיות מודע למוסכמי הרישום שנמצאים בשימוש. לפני מתג משימה והקפצה עליהם היא דרך קלה לטפל בדברים, בהנחה שקיים שטח מחסנית הולם. o>

    ריבוי משימות שיתופי אינו מאפשר לחמוק לחלוטין מבעיות נעילה וכאלה, אבל זה באמת מאוד מפשט את העניינים. ב- RTOS מקדימה עם אוסף אשפה דחוס r, למשל, יש צורך לאפשר להצמיד אובייקטים. בעת שימוש במתג שיתופי, אין זה הכרחי בתנאי שהקוד מניח שאובייקטים של GC עשויים לנוע בכל זמן שמתקשרים למשימות (). אספן דחיסה שאינו צריך לדאוג לחפצים מוצמדים יכול להיות פשוט בהרבה מזה שעושה.

תשובה מדהימה. אני חושב שזה יהיה מעניין לקבל כמה קישורים למשאבים לגישה ל- RTOS שלי. ההתמקדות שלי כאן הייתה באמת להשיג RTOS איכותי מספק שמבצע את העבודה כדי להבטיח זמן אמת קשה, אבל זה יכול להיות פרויקט תחביבים מהנה עבור עצמי.
מגניב, מעולם לא חשב על משימות כמו סתם החלפת SP ...
@JGord: עשיתי מחליפי משימות זעירים ב- 8x51 וב- DSP של TI. 8051, המוצג לעיל, מיועד בדיוק לשתי משימות. ה- DSP אחד משמש עם ארבע וזה קצת יותר מסובך. פשוט היה לי רעיון מטורף: אפשר היה להתמודד עם ארבע משימות פשוט באמצעות שלוש מטלות. בכל פעם שאחת משתי המשימות הראשונות רוצה לעבור על משימות, עליה להתקשר ל- TaskSwitch1 ו- TaskSwitch2. כשאחת משתי המשימות השנייה רוצה לבצע משימות, היא צריכה להתקשר ל- Taskswitch1 ו- Taskswitch3. נניח שקוד מתחיל ב- stack0, וכל מחליף משימות מוגדר עם מספר הערימה המתאים לו.
@JGord: הממ ... זה לא ממש עובד; נראה שהוא מניב סיבוב משולש כיווני ומתעלם מהמתג השלישי. ובכן, התנסו ואני חושב שבטח תמצאו נוסחה טובה.
#5
+7
uɐɪ
2009-12-08 22:16:22 UTC
view on stackexchange narkive permalink

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

ב- AVR32 אני משתמש ב- FreeRTOS. שוב אמין מאוד עד כה, אך היו לי כמה פערים בין תצורה / גרסה בין הגרסה ש- FreeRTOS מפרסמת לבין הגרסה המסופקת במסגרת Atmel. אולם יש לכך יתרון שהוא בחינם!

#6
+5
Amos
2009-12-09 17:09:18 UTC
view on stackexchange narkive permalink

במהדורת דצמבר של אלקטרוניקה פרקטית יומיומית יש חלק 3 מסדרה על מערכות הפעלה בזמן אמת עבור PICs (בעמודת PIC n 'Mix) ויש לה פרטים על הגדרת FreeRTOS עם MPLAB ו- PICKit 2. נראה כי שני המאמרים הקודמים (שלא ראיתי) דנו בעניין היתרונות של RTOS שונים והסתפקו ב- FreeRTOS. לאחר שהמאמר הנוכחי קבע את סביבת הפיתוח הם ממשיכים לתכנן שעון דיגיטלי בינארי. נראה שיש לפחות חלק נוסף נוסף בנושא זה.

אני לא בטוח עד כמה EPE זמין בארה"ב, אך נראה שיש חנות אמריקאית שמקושרת אליה מהאתר שלהם וייתכן שיש עותקים אלקטרוניים זמינים.

#7
+4
Jeanne Pindar
2010-06-04 07:36:57 UTC
view on stackexchange narkive permalink

מהדר CCS ל- PIC מגיע עם RTOS פשוט. לא ניסיתי את זה, אבל אם יש לך המהדר הזה, יהיה קל להתנסות איתו.

למעשה ניסיתי את זה כראשון שלי. זה לא RTOS בשום משמעות אמיתית של המילה. זה לא מקדים בשום צורה שהיא. זה דורש שימוש קבוע בפקודות התשואה, כך ש- RTOS יכול להחליט מי יפעל הבא, אתה צריך להכניס אותם בכוונה כל הזמן במקרה שתוכנית אחרת צריכה להשתלט.
אני חושב שזה עדיין נקרא RTOS. זה פשוט נשמע שיש לו מתזמן שיתופי במקום מתזמן מקדים לחלוטין.
כן, זה עדיין מבחינה טכנית RTOS, אבל היה לי עדיין מעט מאוד ערך בשבילו. אני יודע שזה דבר אישי, אבל בעיניי זה צריך להיות מקדים כדי להיות בעל ערך. אני עדיין +1 כי זו הייתה תשובה טובה ובעלת ערך.
#8
+3
davidcary
2010-06-10 02:28:42 UTC
view on stackexchange narkive permalink

שאלה קשורה מקרוב: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

תודה! נראה שרוב האנשים לא קיבלו את השאלה, אך היא עדיין מעניינת.
פרסמתי את השאלה ב- SO והזמנתי את המשתמש לבוא ל- E&R לעזרה!
אני חושב ש"קיבלנו "את השאלה ב- SO, זה שאל משהו אחר אבל קשור לשאלה זו. באשר לתגובתך שם על הסמכה; זה תלוי בהרבה דברים. כשמסתכלים על התשובות כאן, אני אוהב את התשובה של DoxaLogos המתייחסת ל- QP-nano; הניסיון שלי מוביל אותי להעדיף קוד מונע אירועים על פני שרשורים והחלפת הקשר מרומזת של שרשורים.
#9
+2
Rocketmagnet
2011-01-25 04:32:27 UTC
view on stackexchange narkive permalink

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

ישנן דרכים רבות לארגן את הזמן במיקרו-בקר, תלוי מה החשוב ביותר:

  1. קצב פריימים קבוע: עבור PIC שמריץ בקר סרוו שחייב לפעול ב- 1000Hz למשל. אם אלגוריתם ה- PID לוקח פחות מ- 1ms לביצוע, אתה יכול להשתמש בשארית המילישניות כדי לבצע משימות אחרות, כמו לבדוק את אוטובוס ה- CAN, לקרוא חיישנים וכו '.

  2. כל ההפרעות: כל מה שקורה ב- PIC מופעל על ידי הפרעה. ניתן לתעדף את ההפרעות בהתאם לחשיבות האירוע.

  3. תקעו אותו בלולאה ועשו הכל כמה שיותר מהר. ייתכן שתגלה שזה מספק גבולות זמן מתאימים.

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


שאלה ותשובה זו תורגמה אוטומטית מהשפה האנגלית.התוכן המקורי זמין ב- stackexchange, ואנו מודים לו על רישיון cc by-sa 2.0 עליו הוא מופץ.
Loading...