לא היה לי ניסיון אישי רב עם 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.

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

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

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

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

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

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

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

דבר אחד שמצאתי שימושי במספר מכונות הוא מתג מחסנית פשוט. למעשה לא כתבתי אחד ל- 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 עשויים לנוע בכל זמן שמתקשרים למשימות (). אספן דחיסה שאינו צריך לדאוג לחפצים מוצמדים יכול להיות פשוט בהרבה מזה שעושה.

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

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

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

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

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

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

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

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

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

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

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