میدونم آموزش RTOS خیلی هیجان انگیز است و بابت تاخیر پیش آمده در انتشار قسمت دوم نیز پوزش میخوام ؛ ولی همونطور که میدونید نوشتن مقاله قبل از هر چیزی نیاز به زمان و انگیزه داره که متاسفانه دارم روز های پرمشغله ای رو پشت سر می‌گذارم ؛ البته سعی میکنم که زمان بندی رو بهتر رعایت کنم ؛ اگر عمری باقی بود.
در مقاله اول آموزش RTOS سعی کردم که اهمیت وجود سیستم عامل و فلسفه وجودیش رو بررسی کنیم ؛ در این مقاله سعی میکنم مفاهیم اولیه در خصوص RTOS یا همون سیسم عامل بلادرنگ رو بررسی کنیم ؛ فکر میکنم داشتن درک صحیح از مفاهیم ابتدایی یک سیستم عامل ؛ نکته مهمی باشه که در آینده استفاده از سیستم عامل را راحت تر میکنه ، پس با سیسوگ همراه باشید تا با هم این مفاهیم را بررسی کنیم. در ضمن اگر سه گانه ماتریکس ( Matrix ) رو ندیدید پیشنهاد میکنم که حتما ببینید پوستر های سری پست های آموزش RTOS از این فیلم احتمالا ساخته خواهد شد.
RTOS ویندوز نیست !
قبل از این که بحث این قسمت را شروع کنیم لازم دیدم که یک مختصر توضیحی در خصوص ماهیت RTOS داشته باشم ؛ چرا که در کامنت های قسمت اول آموزش، دوستان نکاتی را مطرح کردند که لازم میدونم در موردش بیشتر توضیح بدم. حتما ویندوز رو میشناسید ! چه سوالی بود ؛ به احتمال 95 درصد دارید این مقاله رو با استفاده از ویندوز مطالعه می‌کنید. ویندوز رو از زمانی که 3.1 بود میشناسم ؛ شاید شما به خاطر نداشته باشید ؛ اول ویندوز 3.1 آمد ؛ تا قبل از آن از سیستم عامل تک وظیفه ای DOS استفاده می کردیم ؛ ویندوز 3.1 یک برنامه بود که توی Dos اجرا می‌شد و به نحوی چند وظیفه گی را به نمایش می‌گذاشت 🙂 ؛ خوب خارق العاده بود ؛ بعد از آن ویندوز های 95 ؛ 98 ، Me و بالاخره Xp وارد بازار شد.
تا قبل از ویندوز Xp دسترسی به سخت افزار آزاد بود و در برنامه نویسی به سادگی می شد با دادن آدرس سخت افزار به آن دسترسی مستقیم داشت ! مثلا می‌شد برنامه ای نوشت که رمز بایوس را پاک کند ، یا بوق سیستم را کنترل کند یا هر چیز دیگری که فکرش را بکنید ؛ به یاد دارم نرم افزاری نوشته بودم که در صورت اجرا یک رمز تصادفی روی بایوس می‌گذاشت و تنها راه بالا آمدن مجدد کامپیوتر خارج کردن باتری بک آپ بود یا برنامه ای نوشته بودم که از طریق پورت LPT آیسی حافظه 24Cxx رو می خواند و می‌نوشت.
اما وقتی ویندوز Xp امد ؛ دسترسی ها را محدود کرد و دیگر دسترسی به سخت افزار کامپیوتر جزء رویا شده بود ؛ اگر به خاطر داشته باشید بیشتر پروگرامر های سخت افزاری که از LPT استفاده می‌کردند از کار افتادند ؛ این مثال ها برای این بود که بگیم سیستم عامل بلادرنگ (RTOS) قرار نیست بین شما و سخت افزار قرار بگیره !
از ویندوز XP به بعد خود سیستم عامل مدیریت کامل سخت افزار کامپیوتر را به دست گرفت و این سیکل همچنان ادامه داره و شما با یک برنامه نویسی ساده قادر نیستید به سخت افزار سیستم دسترسی پیداکنید در حالی که قرار نیست این اتفاق توی سیستم عامل RTOS براتون بیفته و کنترل کامل سیستم در اختیار خودتون هست.
چند وظیفه‌گی (Multitask) در سیستم عامل RTOS
سوالی که ممکنه برای دوستان ایجاد بشه اینه که چطور وقتی یک پردازنده داریم ؛ میتوانیم کارهای مختلفی رو انجام بدیم ؟ ؛ و برخی از دوستان فکر کنند که این تنها یک شبیه سازی از مولتی تسک است و نه یک مولتی تسک واقعی ! در واقع اگر آنقدر سریع باشیم که زمان های در حدود چند میکروثانیه را درک کنیم ؛ شاید این حرف درست به نظر برسد ! اما در واقع این چنین نیست ؛ مثل این که بگوییم فیلم وجود خارجی ندارد و تنها چیزی که وجود دارد عکس است !
در واقع وقتی عکس ها با سرعت بالا پشت سر هم نمایش داده شوند حاصل فیلم است و کیست که بگوید فیلم وجود ندارد !
بگذارید کمی دقیق تر شویم و پاسخ این پرسش مهم را با جزییات بیشتری بررسی کنیم ؛ وقتی که تنها یک پردازنده داریم که در لحظه قادر به انجام یک وظیفه است چطور می توانیم وظایف مختلف را انجام دهیم ؟
چه هنگامی می‌گوییم که چند کار در حال انجام شدن با هم هستند ؟ ؛ از آنجایی که مفهوم زمان نسبی است ؛ مفهوم مولتی تسک‌ینگ هم میتواند نسبی باشد ؛ اگر پردازنده یا کننده کار اینقدر سریع باشد که چند وظیفه را در زمان کوتاه تر از آن چه انتظار می رود به اتمام برساند ؛ میتوان اینطور برداشت کرد که کارها به شکل موازی با هم انجام شده اند در صورتی که ممکن است واقعا اینطور اتفاق نیفتاده باشد و همانطور که احتمالا حدس میزنید اینطور نیست و واقعا کارها به شکل سریالی انجام می شود ولی سرعت انجام سریالی کارها اینقدر زیاد است که به نظر می رسد کارها دارند به شکل موازی انجام می شوند.
بگذارید برای روشن تر شدن هرچه بیشتر مساله ، با طرح مثالی موضوع چند وظیفه‌گی را بررسی کنیم ؛ فرض کنیم سه روتین وظیفه تعریف شده است ؛
- اول دریافت داده سریال از روی پورت Uart و ذخیره سازی آن بر روی حافظه ؛
- دوم نمایش عدد دریافت شده بر روی نمایشگر
- سوم بررسی وضعیت کلید اضطراری است که اگر تشخیص داد کلید فشرده شده باید عمل مهمی را انجام دهد.
برای ملموس شدن شرایط پیش رو فرض کنید که قرار نیست از IRQ (اینتراپت) هم استفاده کنیم. فرض کنید باوود ریت سریال هم 9600 بیت در ثانیه است !
سناریو اول بدون RTOS
چون از چند وظیفه‌گی و سیستم عامل خبری نیست ؛ و چون IRQ هم در کار نیست ؛ تنها راه مانده برای انجام این وظایف استفاده از SuperLoop است ؛ یعنی یک حلقه بی انتها داشته باشیم و کار ها را یک به یک در آن انجام دهیم.
1 2 3 4 5 6 7 | ... while(1) { Check_Emergency_Key(); Get_Serial_Data(); Update_LCD(); } |
اما انجام چنین کاری مخاطرات زیادی را در بر دارد ؛ فرض کنید چک کردن وضعیت کلید اضطراری زمان زیادی طول نمی کشد ؛ اما دریافت داده از روی پورت سریال فرایند زمانبری است ؛ فرض کنید قصد داشته باشید 100 کارکتر را بخوانید ؛ هر کارکتر سریال 11 بیت در کوتاه ترین حالت ممکن طول دارد ؛ پس برای 100 کارکتر 1100 بیت باید دریافت کنید ؛ با توجه به باوود 9600 این انتقال 110 میلی ثانیه طول خواهد کشید ؛ البته اگر فرض کنید بین هر کارکتر هیچ تاخیری وجود نداشته باشد که در واقع اینطور نیست بین هر کارکتر تا دریافت کارکتر بعدی تاخیر وجود خواهد داشت ! فرض کنید آپدیت LCD در خوش‌بینانه ترین حالت 500 میلی ثانیه زمان ببرد.
پس در زمان 610 میلی ثانیه شما هیچ کنترلی روی وضعیت اضطراری سیستم نخواهید داشت ! با بیشتر شدن تعداد وظایف این زمان رشد بیشتری خواهد داشت ؛ و این واقعا میتواند در برخی پروژه ها فاجعه ای به بار بیاورد.
فرض کنید شما برنامه را بر روی یک پردازنده با کلاک یک مگاهرتز پیاده سازی کنید ؛ در زمان دریافت داده سریال 110 میلی ثانیه پردازنده را در حلقه تاخیری می اندازید تا کارکتر بعدی دریافت شود با فرض این که هر انتقال داده از رجیستر Uart به Ram ده سیکل ماشین زمان ببرد ! برای دریافت 100 کارکتر 1000 سیکل ماشین لازم است در صورتی که اینجا 110000 سیکل ماشین مصرف کردم ! (چه کارهایی که در این زمان نمیشد انجام داد…)
سناریو دوم استفاده از RTOS
به لطف وجود سیستم عامل کار ما خیلی راحت شده است ؛ در تسک اول ورودی اضطراری را چک میکنیم اگر وضعیت عادی بود تسک سوییچ می شود و وارد تسک دوم می شویم ؛ اگر کارکتری توسط واحد سریال دریافت شده باشد (با چک کردن وضعیت رجیسترها) آن را خوانده به رم منتقل می کنیم ؛ بعد مجددا تسک را سوییچ میکنیم و میریم روی تسک LCD !
زمان بر ترین تسک همین تسک LCD است، چون باید صبر کنیم تا کنترلر LCD آماده دریافت داده باشد ؛وقتی از RTOS استفاده میکنیم لازم نیست متوقف شویم. میتوان با چک کردن فلگ مورد نظر در صورتی که هنوز سیستم آماده نبود، بر روی دیگر کارها سوییچ کرد؛ به این شکل، هیچ کاری به دلیل تاخیر دیگر کارها عقب نمی افتد ! چرا که پردازنده جایی متوقف نمی شود و مدام در حال سرکشی کردن به تسک ها و وظایف مختلف است.
در قسمت های بعدی آموزش RTOS به تفاوت های موجود در برنامه نویسی RTOS و برنامه نویسی بدون RTOS خواهیم پرداخت.
در قسمت آینده آموزش RTOS مفهوم اولویت بندی در تسک ها را بیشتر بررسی خواهیم کرد و البته الگوریتم سوییچ بین تسک های مختلف را بررسی میکنیم!. پس با آموزش RTOS سیسوگ همراه باشید که اتفاقات هیجان انگیزی در راه است.
عالی
ا ی ول لا
عالی و بی نظیر بود، هم نوع و هم خود محتوا، بی صبرانه منتظر بخش های بعدی rtos ام
خوشحالم که این سری مقاله مورد توجه شما قرار گرفته
داریم برنامه ریزی میکنیم برای تغییرات جدی توی روالها مون
فکر میکنم ادامه این سری مقاله هم در اولویت باشه 🙂
سلام ممنون بابت مطالب مفیدتون . ممکنه مثلا وقتی یه سرکشی به پورت سریال می کنیم و دریافت داشته باشیم و سپس به سراغ ال سی دی بریم تو این زمان دریافت پورت سریال رو از دست بدیم ؟ در ضمن فکر کنم این تسک ها رو بتونیم با تایمر یا سیستم تیک در میکرو های ارم مدیریت کرد درسته ؟
سلام دوست عزیز
خوب باید بگم نه ممکن نیست منطقا !
اولا این که واحد های سریال میکروکنترلرهای مدرن حتی بافر های سخت افزاری دارند !
دوما این که توی میکروکنترلر های arm وقفه ها اولویت پذیر هستند و این کمک میکنه سیستم رو با وجود اولویت ها دیزاین کنیم.
ثالثا سیستم عامل بلادرنگ میآد که در این چنین شرایطی کار برنامه نویس ها رو ساده کنه 🙂
بله دقیقا درست حدس زدید با استفاده از تایمر systick تسک ها رو مدیریت میکنیم
سلام.
مطالب بسیار جالب و هیجان انگیزه.
امیدوارم هرچه زود تر این آموزش ها ادامه پیدا کنه.
به امید موفقیت شما و تیم همراهتون.
سلام دوست عزیز
انشالله مطالب قدیمی قراره از سر گرفته بشه
سلام.
مطالب واقعا مفید هستن و خواندنشون لذت بخشه. اگر مکانش هست منابع مورد استفاده برای نگارش مقالات را هم ذکر کنید که برای مطالعه بیشتر بشه به آنها مراجعه کرد.
ممنون از وبسایت مفیدتون
سلام دوست عزیز
خوشحالم که از مطالب سایت لذت می برید :)
والا در مورد منبع باید عذض کنم که اگر مطلبی منبع داشته باشه حتما ذکر میشه – مثلا این مطلب بر اساس تجربیات شخصی نوشته شده است
اما اگر میخواید بیشتر در مورد سیستم عامل بلادرنگ اطلاعات کسب کنید داکیومنت های سایت free-rtos خیلی خوب هستند.
موفق و پیروز باشید.
سلام وقت بخیر .
همچنان منتظر ادامه این مطلب هستیم. ممنون از لطفتان.
سلام دوست گرامی
انشالله در هفته اینده قسمت بعدی منتشر میشه بعد از مدت ها انتظار?
سلام خسته نباشید واقعا عالیه
اگ میشه یه چند تا کتاب یا منبع برای مطالعه معرفی کنید ممنون میشم
سلام خواهش میکنم دوست عزیز
بهترین منبع اموزش ها و داکیومنت های خود freertos است که البته فکر کنم کتابش پولی است احتمالا
سلام و خسته نباشید
واقعا عالی بود خسته نباشید
مشتاقانه منتظر قسمتهای بعدی هستیم
سلام دوست گرامی
متشکرم از لطف شما –
چشم در اولین فرصت حتما منتشر میکنیم
سلام وقت بخیر . واقعا ممنون بابت این همه مطالب مفید و ارزشمند .
همچنان منتظر ادامه این سر فصل هستیم . پیروز پاینده باشید
سلام و درود به شما دوست عزیز
بله قسمت سوم در دست تالیف است
البته اگر دوستان کامپیوتر، سیستم های عامل 1 رو به خاطر داشته باشند به طور دقیق تر اجرای RTOS روی سیستم هایی با سخت افزار محدود و single-core تحت عنوان Cooperative multitasking شناخته میشه و این task هست که CPU رو کنترل میکنه و نه CPU اجرای task ها رو!
حالا من عینا توضیح مختصر رو در اینجا از ویکیپدیا قرار میدم:
Cooperative multitasking, also known as non-preemptive multitasking, is a style of computer multitasking in which the operating system never initiates a context switch from a running process to another process. Instead, processes voluntarily yield control periodically or when idle or logically blocked in order to enable multiple applications to be run concurrently. This type of multitasking is called “cooperative” because all programs must cooperate for the entire scheduling scheme to work
پس در عمل باز هم اجرای چیزی مثل FreeRTOS یا RTEMS نمیتونه روی کنترلر یا SOC شما معجزه بوجود بیاره! و اجرای درست کل برنامه خیلی به توسعه دهنده وابسته هست. قضیه زمانی ملموس تر میشه که مفهوم Preemptive multitasking رو هم مطالعه کرد
سلام دوست عزیز !
اول متشکرم برای توضیحاتتون ؛ ولی باید بگم که تا معجزه رو چی بدونید ! ؛ اصولا هیچ کسی معتقد نیست که قراره میکرو خودش کاراش رو مدیریت کنه ؛ اصولا این برنامه نویس هست که در نهایت مشخص میکنه که قراره چه اتفاقی بیفته ! تنها مساله اینه که زمان های پرت ایجاد شده توی حلقه های انتظار رو به نحو صحیحی مدیریت کنیم ! در ضمن این شکل سوییچ کانتکس که گفتید ؛ قدیمی شده و امروز از round robin برای سوییچ بین تسک ها استفاده میشه !
پس به جرات میتونم بگم استفاده از RTOS روی SOC ها معجزه ای به پا میکنه که مثال زدنی است ! البته همچنان تاکید میکنم باید ببینیم تعریف ما از معجزه چه خواهد بود !
سلام، زئوس درست میگه، فکر می کنم preemptive یا cooperative بودن بستگی به کرنل داره مثلا :
The adopted rules depends on the kernel. As example ChibiOS/RT is a real time preemptive kernel based on priorities capable also of preemptive round-robin and cooperative scheduling
راستی ممنون میشم یک مقایسه بین RTOS هایی که تا حالا باهاشون کار کردید یا ازشون اطلاع دارید انجام بدید. ممنون
سلام دوست عزیز
متشکرم برای توضیحات 🙂
سلام – خیلی عالی
مشاقانه منتظرم که به مثال عملی برسیم تو اموزش
سلام متشکرم
انشالله یکی دو روز آینده 🙂
سلام و تشکر از کلیه مطالب مفیدی که ارایه میدین …
نکته ای من خوانده ام که در هسته های ARM7/9 تفاوت های زیادی در اجرای RTOS وجودداره
درسته ؟
یکیش نحوه استفاده از وقفه هاست و تفاوت شون در این دومدل هسته
اگر از میکرو ای با هسته ی ARM7 یا ARM9 استفائه می کنید پاسخ منفیست . شما نمیتوانید از ساختار قدیمی اینتراپت استفاده کنید.
دلیل نیز این است که ساختار مدیریت وقفه در این هسته ها به این شکل است که در هنگام ورود به روتین وقفه ای خاص همه ی ˛
وقفه ها غیر فعال شده و تا زمان خروج از روتین غیر فعال باقی می مانند. این در حالیست که اگر به خاطر داشته باشید RTX برای
کار کردن در هسته ی های غیر از CORTEX-M از یکی از تایمر های سخت افزاری برای تولید زمان TICK استفده می کرد. اما
از آنجا که تولید این زمان توسط راه اندازی وقفه ی تایمر صورت گرفته و ورود به روتین یک وقفه ی خاص سایر وقفه ها غیر فعال می کند استفاده از وقفه های دیگر در میکرو های مبتنی بر ARM7/9 موجب اختلال در عملکرد هسته ی RTX شده و منجر به هنگ
کردن برنامه می شود. اما در میکرو های مبنی بر CORTEX-M داستان از قراری دیگر است . همان طور که می دانید در
میکرو هایی مثل LPC1768 که بر مبنای هسته ی CORTEX-M ساخته شده اند کنترل وقفه توسط کنترلر تو در توی ی وقفه یا
NVIC ( Nested Vector Interrupt Controller ( صورت می گیرد .
سلام دوست عزیز ؛ خواهش میکنم
اصولا تمام RTOS ها از یک بیسیک ساده استفاده میکنند که قابل اجرا در اغلب میکروکنترلر ها است
ساختار اینتراپت توی آرم تقریبا توی تمام خانواده ها خیلی نزدیک به هم هست ؛ احتمالا معنی این جمله ای که نوشتید برای انواع ماسک ناپذیر هست.
انشالله در ادامه مقاله بیشتر در خصوص ساختار وقفه توضیح میدیم ؛ ولی مطمئن باشید اصول یکی هست و چندان پیچیدگی زیادی هم نخواهد داشت.
توی تایم لاین ویندوزا 98 رو یادتون رفته
بله متشکرم از این نکته سنجی !
شاید بخاطر این بود که لوگوهای 95 و 98 خیلی به هم شبیه هستن 🙂
سلام خدا قوت تکنیک خوبیه اما گمان میکنم برنامه پیچیده میشه وگنگ میشه ودر دیباگ کردن هم به مشکل برمیخریم چون معلوم نیست دراون لحظه روی کدوم برنامه هستیم وچقدرازبرنامه اجراشده
سلام و درود دوست عزیز ؛ امم – پیچیده نه نمیشه گفت پیچیده
اگر تکنیک هایی رو بدونید که انشالله خواهیم گفت خیلی ساده تر از برنامه نویسی سنتی میتونید مشکل رو پیدا کنید 🙂
به هر حال سیستم عامل آمده که کارها رو راحت تر کنه نه پیچیده تر 🙂
سلام
عالیه……
تشکر
خواهش میکنم دوست عزیز 🙂
سلام
واقعا دستتون درد نکنه اینهمه اطلاعات عالی و ناب بدون هیچگونه انتظاری در اختیار عموم قرار میدید
خدا خیرتون بده
خواهش میکنم ؛ همین کامنت ها هست که انگیزه ادامه مسیر را در ما تقویت میکند.
سلام زئوس
مث همیشه عالی ؛-)
منتظر قسمت بعدی هستم
سلام و درود
لطف دارید ؛ انشالله به زودی
باتشکر از انتشار قسمت جدید
امیدوارم برتی قسمت های بعدی اینقدر چشم انتظار نمونیم. این مبحث از بهترین و پرکاربردترین مطالب سیسوگه. شاد و پیروز باشید:)
خواهش میکنم
انشالله که همینطور خواهد بود ؛
سلامت باشید.
عالی، منتظر ادامشم…
متشکرم 🙂
به نوبه خودم بهتون خسته نباشید میگم بسیار عالی بود …. حتما ادامه بدین … متشکر
خواهش میکنم دوست عزیز 🙂
انشالله که بتونیم ادامه رو با نظم بیشتری دنبال کنیم