الحقيقة الكاملة عن RTOS. المادة رقم 1.
أنظمة التشغيل في الوقت الفعلي: مقدمةهذه السلسلة من المقالات مخصصة لدراسة شاملة لجميع جوانب أنظمة التشغيل في الوقت الفعلي (RTOS). تهدف المقالات إلى المطورين الذين لديهم فضول لمعرفة كيفية عمل RTOS وكيفية استخدامها. ستكون نقطة البداية مناقشة حول أنظمة الوقت الفعلي بشكل عام ، وبعد ذلك سنتحدث عن كيف يمكن لـ RTOS تبسيط تنفيذها وجعل الشفرة الناتجة أكثر موثوقية.
بالنظر داخل RTOS ، سنرى كيف يعمل برنامج جدولة المهام. بفضل خاصية المعالجة المتعددة ، يبدو أن وحدة المعالجة المركزية (CPU) تقوم بالعديد من العمليات في نفس الوقت. هذا ليس سحرًا ، فهناك فهم لمبادئ جدولة المهام حتى لمهندس برمجيات قليل الخبرة. سنتحدث عن كائنات أخرى من RTOS: حول التفاعل بين المهام والمزامنة ، حول الوضع في الوقت الحقيقي ، حول إدارة الذاكرة ، وما إلى ذلك ، سيتم وصف كل شيء بدقة ودعمه من خلال أمثلة التعليمات البرمجية.
بالنسبة للمطور ، فإن أحد الجوانب الرئيسية لـ RTOS هو API ، وهي مجموعة من استدعاءات الإجراءات التي توفر الوصول إلى وظيفة RTOS. ستعرض السلسلة مقالات حول موضوع كيفية عمل واجهة برمجة التطبيقات ، وما هي المعايير المتاحة ، وكيفية الانتقال من واجهة برمجة تطبيقات إلى أخرى.
فيما يلي قائمة بالموضوعات التي سننظر فيها في المستقبل القريب:
- هيكل البرنامج والوقت الحقيقي
- أنظمة التشغيل في الوقت الحقيقي
- المهام والتخطيط
- تفاعل المهام والمزامنة
- خدمات نظام التشغيل الأخرى
- Nucleus SE
- مخطط
- المهام
- أقسام الذاكرة
- الإشارات
- مجموعات علامة الحدث
- الإشارات
- صناديق البريد
- قوائم الانتظار
- القنوات
- وقت النظام
- موقتات البرمجيات
- الانقطاعات
- التشخيص وفحص الأخطاء
- التهيئة والبدء
لا ترتبط سلسلة المقالات بأي نظام تشغيل معين في الوقت الفعلي ؛ معظم المواد قابلة للتطبيق على الخيارات المتاحة للجمهور لتطبيق RTOS. ووفقًا للمؤلف ، فإن استخدام نظام تشغيل تجاري جاهز مع الدعم الحالي هو الطريقة الأكثر موثوقية وإنتاجية للعمل. سيتم تخصيص إحدى المقالات لمناقشة تفصيلية حول موضوع "جعل مقابل شراء" ومنهجيات أخرى لاختيار RTOS.
ومع ذلك ، لشرح التصميم الداخلي لنظام RTOS ، يتم استخدام أمثلة لرمز المنتج الحقيقي ، Nucleus SE.
المصدر:
http://www.embedded.com/design/operating-systems/4442729/Introduction--RTOS-Revealingالحقيقة الكاملة عن RTOS. المادة رقم 2
RTOS: البنية ووضع الوقت الحقيقيهيكل البرنامج والوقت الحقيقيتدور هذه السلسلة من المقالات حول الأنظمة المضمنة ، وبشكل خاص ، حول البرامج التي تعمل على الأنظمة المضمنة. لنبدأ بالتعريف. ما هو النظام المضمن؟ في عام 1986 ، عندما كتبت أول كتاب حول هذا الموضوع ، لم يكن مثل هذا المصطلح موجودًا. تم استخدام مفاهيم "النظام المخصص" أو "النظام المصغر" ، لكنها بالطبع لم تعكس الجوهر بأكمله. بعد بضع سنوات ، دخلت كلمة "مدمجة" حيز الاستخدام ، وبدأ جميع المتخصصين في استخدامها بنشاط.
العودة إلى تعريف نظام مضمن. في محاولة لتوضيح للأصدقاء والعائلة ما أعمل عليه ، توصلت إلى التفسير التالي: النظام المضمن هو أي جهاز إلكتروني يحتوي على معالج ، ولكن لا يتم قبوله عادةً كجهاز كمبيوتر.
نظام التشغيل (OS) موجود دائمًا على الكمبيوتر ؛ في الأنظمة الحديثة المدمجة ، يتم استخدام بعض أنواع أنظمة التشغيل فقط. على الرغم من حقيقة أن استخدام النواة يسود في الأنظمة عالية الأداء (32 و 64 بت) ، فمن الممكن الاستفادة من استخدامه في الأجهزة منخفضة الطاقة. تركز هذه المقالات على أنظمة التشغيل ، بشكل عام ومع تنفيذ محدد.
لماذا استخدام نظام التشغيل على الإطلاق؟دعونا نرى لماذا يتم استخدام أنظمة التشغيل من حيث المبدأ. هناك العديد من التفسيرات ، بعضها يعتمد على العامل البشري وعلى الخصائص التقنية. أتذكر القصة. في أحد مكاتبنا كان هناك ركن مطبخ حيث يمكنك صنع القهوة. على الباب كانت هناك لافتة عليها نقش: "من فضلك لا تغلق الباب". تحته ، كتب شخص ما: "لماذا لا؟" ، وأجاب عليه شخص آخر: "لأن". نسخة مختصرة جدًا من العبارة "لأننا نطلب منك أن تفعل ذلك بالضبط." لنفس الأسباب ، يتم استخدام أنظمة التشغيل على بعض الأنظمة ، لمجرد أنه يجب القيام بها.
تفسير آخر هو استخدام تطبيقات سطح المكتب. من أين تبدأ إذا كتبت برنامجًا للكمبيوتر الشخصي أو جهاز Mac؟ يمكنك تشغيل الكمبيوتر وبدء تشغيل Windows / Linux أو macOS وبدء البرمجة. يعد وجود نظام تشغيل شرطًا معينًا ، ويوفر عددًا من الخدمات المفيدة. من غير المحتمل أن تقرر البدء من الصفر عند برمجة المعادن العارية. لذلك ، ليس من المستغرب أن يعتمد مهندس لديه خبرة في كتابة البرامج ، ولكن البرامج الثابتة الجديدة بالنسبة لها ، على وجود نظام تشغيل في النظام الذي طوره.
تجدر الإشارة إلى أن أحد الجوانب الرئيسية لنظام تشغيل سطح المكتب الذي يعرفه المستخدمون هو واجهة المستخدم (UI). اسأل شخصًا ما هو نظام Windows وسوف يجيبون أنه النوافذ ، والقوائم ، ومربعات الحوار ، والرموز ، ولكن نظام الملفات والاتصال بين البرامج والقدرة على التفاعل مع الأنظمة الأخرى بالكاد مذكورة. هذا هو الفرق الرئيسي بين سطح المكتب والنظام المضمن: قد لا يحتوي الأخير على واجهة مستخدم ، وإذا كان كذلك ، فهو مباشر إلى حد ما. هذا هو الأول من بين العديد من الاختلافات الرئيسية:
- عادة ما يقوم النظام المضمن بتشغيل تطبيق برنامج واحد من التشغيل إلى إيقاف التشغيل.
- الأنظمة المدمجة لها موارد محدودة. يمكن أن تكون كمية الذاكرة كبيرة جدًا ، ولكن ليس حقيقة أنه يمكن توسيعها ؛ المعالج لديه طاقة محدودة.
- تعمل العديد من التطبيقات المضمنة في الوقت الفعلي. المزيد عن هذا في المقالة أدناه.
- أدوات تطوير البرامج الثابتة متخصصة ويتم تشغيلها على الكمبيوتر المضيف (مثل الكمبيوتر الشخصي) ، وليس على النظام المستهدف.
- يعد تحديث البرامج الثابتة عملية معقدة. على الرغم من الفرص التي تظهر بسبب الأجهزة المتصلة ، لا تزال تحديثات البرامج الثابتة أثناء التشغيل ليست القاعدة (على عكس التحديثات والتصحيحات العادية (التصحيحات) المستخدمة لبرامج سطح المكتب).
قبل أن نفكر في كيفية هيكلة التطبيقات المضمنة ، سوف نفهم المفاهيم المستخدمة على أجهزة الكمبيوتر لتنفيذ البرامج باستخدام نظام التشغيل.
أولاً ، هناك تنفيذ للبرامج بأسلوب DOS ، عندما يتم تنفيذ البرامج بالتناوب.
يتم إطلاق كل برنامج وتنفيذه وإنهائه. نستخدم ، على سبيل المثال ، البرنامج 1 ، ثم البرنامج 2 ، ثم ربما نأخذ استراحة ، ننتقل إلى البرنامج 3 ، ثم نعود إلى البرنامج 2. يبدأ الاستخدام الثاني للبرنامج 2 من جديد: لا يبدأ الإطلاق من حيث توقفنا هذا (باستثناء الحالات التي لا يوفر فيها التطبيق نفسه مثل هذه الفرصة).
بعد DOS ، أصبحت الأمور معقدة بعض الشيء ، حيث أصبح Windows شائعًا. يعني تشغيل البرامج بنمط Windows تشغيل برامج متعددة في الوضع متعدد مؤشرات الترابط.
في هذا الوضع ، يبدو أن البرامج تعمل في نفس الوقت ، وأن Windows يتحكم في هذا الوهم. أولاً ، يبدأ البرنامج 1 ، ثم في نفس الوقت يبدأ البرنامج 2 ، ثم البرنامج 3. ينتهي البرنامج 2 ، ولا يزال البرنامجان 1 و 3 قيد التشغيل. ينتهي البرنامج 3 ، ويبقى البرنامج 1. فقط. وفي وقت لاحق ، يتم استئناف البرنامج 2 ، وينتهي البرنامج 1 ، يبقى البرنامج 2 فقط. هذا مسار واقعي للأحداث عندما يتم استخدام Windows من قبل مستخدم عادي. يخصص نظام التشغيل الموارد بحيث تستخدم جميع البرامج المعالج بشكل صحيح. كما يوفر اتصالاً سهلاً بين البرامج (مثل الحافظة) ويتحكم في واجهة المستخدم.
تتطلب بعض الأجهزة المحمولة مرونة أكبر مما يمكن أن تقدمه DOS ، ولكن نظرًا لمحدودية الموارد ، يلزم وجود نفقات أقل من Windows. ونتيجة لذلك ، قمنا بتنفيذ برامج بأسلوب iOS ، وهي:
يتم تشغيل البرامج واحدًا تلو الآخر ، ولكن يتم حفظ حالتها تلقائيًا حتى تتمكن من المتابعة من نفس المكان عند الإغلاق. على سبيل المثال ، يبدأ البرنامج 1 ، ثم يتوقف مؤقتًا لاستخدام البرنامج 2 ، ثم ، على سبيل المثال ، يتم إيقاف تشغيل الجهاز لفترة. عند الاستئناف ، يتم تحميل البرنامج 3 (تم حفظ حالة البرنامج 2 تلقائيًا) ، ثم يعود المستخدم إلى البرنامج 2 ، مع الاستمرار في العمل فيه. أفهم أن نموذج التنفيذ لتطبيق iOS أكثر تعقيدًا بكثير من النموذج الموصوف أعلاه ، ومع ذلك ، فإن هذا الوصف هو مجرد ملخص موجز لتصور المستخدم الأولي.
معظم التطبيقات المدمجة لا تتطابق مع أي من النماذج المذكورة أعلاه. كقاعدة ، يبدأ الجهاز البرنامج عند تشغيل الطاقة ويستمر في العمل فقط مع هذا البرنامج لفترة غير محددة من الوقت. يجب التفكير بعناية في بنية هذا الرمز.
موديلات البرامج الثابتةأنظمة سطح المكتب متشابهة تقريبًا. من وجهة نظر البرنامج التطبيقي ، جميع أجهزة الكمبيوتر الشخصية التي تعمل بنظام Windows متطابقة. الأنظمة المدمجة فريدة من نوعها: يختلف كل منها عن الآخر. يمكن أن تكون الاختلافات تقنية: نوع المعالج ، حجم الذاكرة ، عدد الأجهزة الطرفية. يمكن أن تختلف الجوانب ذات الأولوية للتطبيقات أيضًا في السرعة واستهلاك الطاقة والأمن والموثوقية. قد تكون هناك اختلافات تجارية تؤثر على التسعير: أحجام الإنتاج والاختيار بين الأجهزة المخصصة أو القياسية.
هذه الاختلافات مهمة للمطورين المضمنين. على سبيل المثال ، يعتمد اختيار أدوات التطوير (المترجمات ، المصححات ، إلخ) على نوع المعالج. تؤثر العديد من العوامل على اختيار نظام التشغيل أو حتى قرار تطبيقه من حيث المبدأ. يجب تحديد بنية البرنامج (نموذج البرنامج) بعناية لكل تطبيق مضمن فردي.
اعتمادًا على متطلبات التطبيق ، قد يكون للبرامج المدمجة هياكل مختلفة ذات مستويات تعقيد مختلفة ، على سبيل المثال:
أبسط شكل هو بنية مغلقة يتكرر فيها نفس تسلسل الإجراءات. إذا كان التطبيق بسيطًا بما فيه الكفاية بحيث يمكن تنفيذه بهذه الطريقة ، فهذا مثالي: كود بسيط موثوق به ومفهوم. ومع ذلك ، فإن هذه البنية حساسة للغاية للجزء من التعليمات البرمجية الذي يمكن أن يستغرق الكثير من وقت المعالج ، أي أن بعض الأوامر يتم تنفيذها لفترة طويلة بحيث تؤخر تنفيذ مهام التطبيق الأخرى. بالإضافة إلى ذلك ، لا يتناسب هذا النموذج بشكل جيد: يمكن أن يكون تحسين التعليمات البرمجية مشكلة ، لأن الوظائف الإضافية يمكن أن تؤثر على أداء التعليمات البرمجية القديمة.
إذا كان هناك حاجة إلى شيء أكثر تعقيدًا ، فيمكنك محاولة وضع جزء غير حرج من التعليمات البرمجية في الحلقة الرئيسية ، وجزء حساس للوقت في معالج المقاطعة (إجراءات مقاطعة المقاطعة ، ISR). تكون إجراءات معالج المقاطعة قصيرة جدًا في الأساس ، ولا تؤدي سوى المهام الحرجة وتمييز الأقسام من الحلقة الرئيسية لإكمال العمل في أقرب وقت ممكن. يمكن أن تنشأ صعوبات عندما يكون من الضروري توزيع العمل بين الحلقة الرئيسية ومعالج المقاطعة (وكذلك بين العديد من المطورين).
للحصول على أقصى مرونة للتطبيق ، سيكون من الضروري تقسيمها إلى عدة برامج منفصلة ومستقلة نسبيًا (دعنا نطلق عليها مهام أو سلاسل رسائل) ، والتي سيتم تنفيذها في الوضع متعدد الخيوط. يمكن أيضًا تضمين معالجات المقاطعة الصغيرة في النظام ، ولكنها ستخطر بشكل رئيسي بالمهام أو تؤدي إلى إجراء. لتحقيق ذلك ، تحتاج إلى نظام تشغيل ، أو على الأقل نواة. لا يوفر استخدام مؤشرات الترابط المتعددة توزيعًا مرنًا للوظائف في البرامج فحسب ، بل يسهل أيضًا توزيع العمل بين المطورين.
ما هو الوقت الحقيقي؟في وقت سابق ، كتبت أن العديد من التطبيقات المضمنة تعمل في الوقت الفعلي. في هذا السياق ، من المعتاد التحدث عن أنظمة التشغيل في الوقت الفعلي ، وليس عن نظام تشغيل بسيط. دعونا نحدد المصطلحات.
"نظام التشغيل في الوقت الفعلي هو نظام لا تعتمد فيه صحة الحسابات على الصحة المنطقية للحسابات فحسب ، بل تعتمد أيضًا على الوقت الذي سيتم فيه تحقيق النتيجة.
إذا لم يتم استيفاء القيود الزمنية للنظام ، فمن المعتقد أنه حدث فشل في النظام ".
من السمات الهامة لمثل هذا النظام قابليته للتنبؤ أو الحتمية ، كما يقولون غالبًا.
إن نظام التشغيل في الوقت الفعلي ليس بالضرورة سريعًا جدًا ؛ ف "الوقت الحقيقي" لا يعني دائمًا "الوقت سريعًا حقًا". وهذا يعني أنه سيتم الانتهاء من أي إجراء ضروري في الوقت المناسب. أي بسرعة كافية ، ولكن في الوقت نفسه ليس سريعًا جدًا (أي بطيئًا بما فيه الكفاية).
يوفر RTOS (عند استخدامه بشكل صحيح) تحكمًا دقيقًا للغاية في توزيع وقت المعالج للمهام ، وبالتالي يجعل التطبيقات حتمية تمامًا. الشيء الوحيد الذي يمكن أن يدمر هذه الصورة هو الانقطاعات. هناك RTOSs التي تتحكم بشكل كامل في المقاطعات. مهمتهم هي إدارة خدمة المقاطعة كجزء من برنامج جدولة المهام. على الرغم من حقيقة أن هذا يجب أن يؤدي إلى سلوك يمكن التنبؤ به ، فإن هذه الآلية معقدة للغاية وتحتوي على تكاليف عامة مرتفعة.
تسمح معظم RTOS ببساطة لمعالج المقاطعة "لسرقة" الوقت من مهمة كانت تعمل في وقت المقاطعة. هذا ، بدوره ، يجبر المبرمج على كتابة رمز معالج المقاطعة قصيرة قدر الإمكان. نتيجة لذلك ، لدينا خطأ مسموح به في الوقت الحقيقي. الصعوبة الوحيدة هي إجراء مكالمات لخدمات RTOS كجزء من مهمة معالج. يمكن أن تكون بعض المكالمات غير ضارة تمامًا ، بينما تتسبب مكالمات أخرى في تبديل السياق عند العودة من المقاطعة. يجب معالجة هذه الحالة بشكل خاص ، وهو أمر ممكن بمساعدة RTOS المختلفة.
المصدر:
https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-timeعندما كنا نعمل على نظام التشغيل OSRV MAX الخاص بنا في الوقت الفعلي (سبق لي أن نشرت مقالات حول هذا الموضوع) ، " صادف فريقنا" مدونة Colin Walls ، الخبيرة في الإلكترونيات الدقيقة والبرامج الثابتة في Mentor Graphics. بدت المقالات مثيرة للاهتمام ، وترجمتها لأنفسهم ، لكن لكي لا "يكتبوا على الطاولة" قرروا نشرها. آمل أن تكون مفيدة لك أيضًا. إذا كان الأمر كذلك ، فنحن نخطط لنشر جميع المقالات المترجمة في السلسلة.نبذة عن الكاتب: يعمل Colin Walls في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، ويكرس معظم وقته للبرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). غالبًا ما يتحدث كولين وولز في المؤتمرات والندوات ، مؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة. مدونة كولين المهنية: http://blogs.mentor.com/colinwalls ، البريد الإلكتروني: colin_walls@mentor.com
تم نشر المادة 3 هنا.