آموزش RTOS قسمت دوم : آشنایی با مفهوم چند وظیفه‌گی

میدونم  آموزش 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 است ؛ یعنی یک حلقه بی انتها داشته باشیم و کار ها را یک به یک در آن انجام دهیم.

اما انجام چنین کاری مخاطرات زیادی را در بر دارد ؛ فرض کنید چک کردن وضعیت کلید اضطراری زمان زیادی طول نمی کشد ؛ اما دریافت داده از روی پورت سریال فرایند زمانبری است ؛ فرض کنید قصد داشته باشید 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 سیسوگ همراه باشید که اتفاقات هیجان انگیزی در راه است.