مقدمه
میدونم آموزش RTOS خیلی هیجان‌انگیز است و بابت تاخیر پیش‌آمده در انتشار قسمت‌دوم نیز پوزش میخوام؛ ولی همونطورکه میدونید نوشتن مقاله قبل‌از هر چیزی نیازبه زمان و انگیزه داره که متاسفانه دارم روزهای پرمشغله‌ای رو پشت‌سر می‌گذارم، البته سعی می‌کنم که زمان‌بندی رو بهتر رعایت‌کنم، اگر عمری باقی بود. در مقاله‌ی اول آموزشRTOS سعی‌کردم که اهمیت وجود سیستم‌عامل و فلسفه وجودیش رو بررسی‌کنیم، در این مقاله سعی می‌کنم مفاهیم‌اولیه درخصوص RTOS یا همون سیستم‌عامل بلادرنگ رو بررسی‌کنیم. فکر می‌کنم داشتن درک‌صحیح از مفاهیم‌ابتدایی یک سیستم‌عامل، نکته‌مهمی باشه که در آینده استفاده‌از سیستم‌عامل را راحت‌تر می‌کنه، پس با ما همراه باشید تا باهم این مفاهیم را بررسی‌کنیم. درضمن اگر سه‌گانه ماتریکس(Matrix) رو ندیدید پیشنهاد می‌کنم که حتما ببینید پوسترهای سری پست‌های آموزش RTOS از این فیلم احتمالا ساخته‌خواهد شد.
RTOS ویندوز نیست!
قبل‌از اینکه بحث این قسمت را شروع‌کنیم لازم‌دیدم که یک مختصر توضیحی درخصوص ماهیت RTOS داشته‌باشم، چراکه در کامنت‌های قسمت اول آموزش، دوستان نکاتی را مطرح کردند که لازم میدونم درموردش بیشتر توضیح بدم. حتما ویندوز رو میشناسید! چه سوالی بود؟ به‌احتمال ۹۵درصد دارید این مقاله رو بااستفاده‌از ویندوز مطالعه می‌کنید. ویندوز رو از زمانیکه ۳.۱بود میشناسم. شاید شما به‌خاطر نداشته‌باشید، اول ویندوز۳.۱ آمد. تا قبل‌از آن از سیستم‌عامل تک‌وظیفه‌ای DOS استفاده می‌کردیم؛ ویندوز۳.۱ یک برنامه بود که توی Dos اجرا می‌شد و به‌نحوی چندوظیفگی را به‌نمایش می‌گذاشت و خوب خارق‌العاده بود. بعد‌از آن ویندوزهای ۹۵ و۹۸ وMe و بالاخره Xp وارد بازار شد. تا قبل‌از ویندوز Xp دسترسی‌به سخت‌افزار آزاد بود و در برنامه‌نویسی به‌سادگی می‌شد با دادن آدرس سخت‌افزار به آن دسترسی‌مستقیم داشت! مثلا می‌شد برنامه‌ای نوشت که رمز بایوس را پاک‌کند، یا بوق سیستم را کنترل‌کند یا هر چیزدیگری که فکرش را بکنید. به‌یاد دارم نرم‌افزاری نوشته‌بودم که درصورت اجرا یک رمز تصادفی روی بایوس می‌گذاشت و تنها راه بالا‌آمدن مجدد کامپیوتر خارج‌کردن باتری بک‌آپ بود یا برنامه‌ای نوشته‌بودم که از‌طریق پورت LPT آی‌سی حافظه ۲۴Cxx رو می‌خواند و می‌نوشت. اما وقتی ویندوز Xp امد، دسترسی‌ها را محدود کرد و دیگر دسترسی‌به سخت‌افزار کامپیوتر جزء رویا شده‌بود. اگر به‌خاطر داشته‌باشید بیشتر پروگرامرهای سخت‌افزاری که از LPT استفاده می‌کردند از کار افتادند؛ این مثال‌ها برای این بود که بگیم سیستم‌عامل بلادرنگ(RTOS) قرارنیست بین شما و سخت‌افزار قرار بگیره!
RTOS تنها قابلیت چندوظیفگی را به شما هدیه می‌کند و البته مدیریت‌زمان را در دست می‌گیرد به‌غیر از این هیچ‌محدودیتی در ارتباط شما با سخت‌افزار ایجاد نمی‌کند. مطمئن‌باشید همه‌چیز مثل گذشته خواهد‌بود. برای‌همین به‌اختصار میگم که RTOS قرار نیست ویندوز باشد.
از ویندوز XP به بعد خود سیستم‌عامل مدیریت‌کامل سخت‌افزار کامپیوتر را به‌دست گرفت و این سیکل همچنان ادامه‌داره و شما با یک برنامه‌نویسی ساده قادر نیستید به سخت‌افزار سیستم دسترسی پیداکنید درحالیکه قرار نیست این اتفاق توی سیستم‌عامل RTOS براتون بیفته و کنترل کامل سیستم در اختیار خودتون هست.
چندوظیفگی(Multitask) در سیستم‌عامل RTOS
سوالی که ممکنه برای دوستان ایجاد بشه اینه‌که چطور وقتی یک پردازنده داریم میتوانیم کارهای مختلفی رو انجام بدیم ؟و برخی‌از دوستان فکرکنند که این تنها یک شبیه‌سازی از مولتی تسک است و نه یک مولتی تسک واقعی! درواقع اگر آنقدر سریع باشیم که زمان‌های درحدود چندمیکروثانیه را درک‌کنیم شاید این حرف درست به‌نظر برسد! اما در واقع این‌چنین نیست مثل اینکه بگوییم فیلم وجود خارجی ندارد و تنها چیزی که وجود دارد عکس است! درواقع وقتی عکس‌ها با سرعت‌بالا پشت‌سرهم نمایش‌داده‌شوند حاصل فیلم است و کیست که بگوید فیلم وجود ندارد! بگذارید کمی دقیق‌تر شویم و پاسخ این پرسش مهم را با جزییات بیشتری بررسی‌کنیم. وقتی که تنها یک پردازنده داریم که در لحظه قادربه انجام یک وظیفه است چطور میتوانیم وظایف مختلف را انجام‌دهیم؟ چه هنگامی می‌گوییم که چندکار درحال انجام‌شدن باهم هستند؟ از آنجاییکه مفهوم زمان‌نسبی است.مفهوم مولتی تسکینگ هم میتواند نسبی باشد؛ اگر پردازنده یا کننده کار اینقدر سریع باشد که چندوظیفه را در زمان کوتاه‌تر از آن‌چه انتظار میرود به اتمام برساند میتوان اینطور برداشت‌کرد که کارها به‌شکل موازی باهم انجام شده‌اند درصورتیکه ممکن‌است واقعا اینطور اتفاق نیفتاده‌باشد و همانطورکه احتمالا حدس‌میزنید اینطورنیست و واقعا کارها به‌شکل سریالی انجام می‌شود ولی سرعت انجام سریالی کارها اینقدر زیاد است که به‌نظر می‌رسد کارها دارند به‌شکل موازی انجام می‌شوند. بگذارید برای روشن‌ترشدن هرچه بیشتر مساله، با طرح مثالی موضوع چندوظیفگی را بررسی‌کنیم؛ فرض‌کنیم سه روتین وظیفه تعریف‌شده است:
- اول دریافت داده سریال از روی پورت Uart و ذخیره‌سازی آن برروی حافظه
- دوم نمایش عدد دریافت‌شده برروی نمایشگر
- سوم بررسی وضعیت کلید اضطراری است که اگر تشخیص‌داد کلید فشرده‌شده باید عمل مهمی را انجام‌دهد.
برای ملموس‌شدن شرایط پیش‌رو فرض‌کنید که قرارنیست از IRQ(اینتراپت)هم استفاده‌کنیم. فرض‌کنید باوود ریت سریال هم ۹۶۰۰بیت‌درثانیه است!
سناریو اول بدون RTOS
چون از چندوظیفگی و سیستم‌عامل خبری‌نیست و چون IRQ هم درکار نیست تنها راه مانده برای انجام این وظایف استفاده‌از SuperLoop است یعنی یک حلقه بی‌انتها داشته‌باشیم و کارها را یک‌به‌یک در آن انجام‌دهیم.
...
while(1)
{
Check_Emergency_Key();
Get_Serial_Data();
Update_LCD();
}
اما انجام چنین‌کاری مخاطرات زیادی را دربردارد. فرض‌کنید چک‌کردن وضعیت کلید‌اضطراری زمان‌زیادی طول نمی‌کشد اما دریافت داده از روی پورت‌سریال فرایند زمانبری است. فرض‌کنید قصد‌داشته‌باشید ۱۰۰کارکتر را بخوانید، هر کارکتر سریال ۱۱بیت در کوتاه‌ترین حالت‌ممکن طول دارد. پس برای ۱۰۰کارکتر ۱۱۰۰بیت باید دریافت‌کنید. با‌توجه‌به باوود ۹۶۰۰ این انتقال ۱۱۰میلی‌ثانیه طول‌خواهد‌کشید، البته اگر فرض‌کنید بین هر کارکتر هیچ‌تاخیری وجود‌نداشته‌باشد که درواقع اینطورنیست بین هر کارکتر تا دریافت کارکتر بعدی تاخیر وجود خواهدداشت! فرض‌کنید آپدیتLCD در خوش‌بینانه‌ترین حالت ۵۰۰میلی‌ثانیه زمان‌ببرد. پس در زمان ۶۱۰میلی‌ثانیه شما هیچ کنترلی روی وضعیت‌اضطراری سیستم نخواهیدداشت! با بیشترشدن تعداد وظایف این زمان رشد بیشتری خواهدداشت و این واقعا میتواند در برخی پروژه‌ها فاجعه‌ای به بار بیاورد. فرض‌کنید شما برنامه را برروی یک پردازنده با کلاک یک مگاهرتز پیاده‌سازی کنید. در زمان دریافت داده سریال ۱۱۰میلی‌ثانیه پردازنده را در حلقه تاخیری می‌اندازید تا کارکتر بعدی دریافت‌شود با فرض اینکه هر انتقال داده از رجیستر Uart به Ram ده سیکل ماشین زمان ببرد! برای دریافت ۱۰۰کارکتر ۱۰۰۰سیکل ماشین لازم‌است درصورتیکه اینجا ۱۱۰۰۰۰سیکل ماشین مصرف‌کردم!(چه کارهایی که در این زمان نمیشد انجام داد…)
البته دقت‌داشته‌باشید درصورت وجود اینتراپت ساختاربرنامه خیلی‌بهتر میتواند باشد. ولی آیا اینتراپت یک وظیفه‌ی جدا نیست؟
سناریو دوم استفاده‌از RTOS
به لطف وجود سیستم‌عامل کار ما خیلی‌راحت شده‌است. در تسک اول ورودی اضطراری را چک میکنیم اگر وضعیت عادی بود تسک سوییچ می‌شود و وارد تسک دوم می‌شویم. اگر کارکتری توسط واحدسریال دریافت‌شده باشد (با چک‌کردن وضعیت رجیسترها) آن‌را خوانده به رم منتقل میکنیم بعد مجددا تسک را سوییچ میکنیم و میریم روی تسک LCD! زمانبرترین تسک همین تسک LCD است، چون باید صبرکنیم تا کنترلر LCD آماده دریافت داده باشد. وقتی‌از RTOS استفاده میکنیم لازم‌نیست متوقف‌شویم. میتوان با چک‌کردن فلگ موردنظر درصورتیکه هنوز سیستم آماده نبود، برروی دیگر کارها سوییچ کرد به این شکل، هیچ‌کاری به‌دلیل تاخیر دیگر کارها عقب نمی‌افتد چراکه پردازنده جایی متوقف نمیشود و مدام درحال سرکشی‌کردن به تسک‌ها و وظایف مختلف است.
همانطورکه می‌بینید استفاده‌از RTOS برنامه‌نویسی را به‌شکل قابل‌توجهی ساده می‌کند و نیازی‌به بررسی حالت‌های خاص نیست البته توجه‌داشته‌باشید که مقداری سبک برنامه‌نویسی متفاوت خواهد بود.
در قسمت‌های بعدی آموزش RTOS به تفاوت‌های موجود در برنامه‌نویسی RTOS و برنامه‌نویسی بدون RTOS خواهیم‌پرداخت.
در قسمت آینده آموزش RTOS مفهوم اولویت‌بندی در تسک‌ها را بیشتر بررسی خواهیم‌کرد و البته الگوریتم سوییچ بین تسک‌های مختلف را بررسی میکنیم!. پس با آموزش RTOS همراه باشید که اتفاقات هیجان‌انگیزی در راه است.
منبع: سیسوگ
