معرفات المهام
يجب أن تكون قادرًا على تحديد كل مهمة في النظام. هذا المطلب مهم لكائنات kernel الأخرى ، ولكن هناك بعض الفروق الدقيقة في المهام التي تتوافق مع موضوع هذه المقالة.
يستخدم مطورو RTOS أساليب مختلفة لتحديد المهام ، ولكن يمكن تمييز أربع استراتيجيات عامة:
- يتم تحديد المهمة باستخدام مؤشر إلى "كتلة التحكم" الخاصة به. تعتبر المؤشرات دائمًا فريدة من نوعها وهي أيضًا مريحة في الاستخدام ، نظرًا لأن الوصول إلى وحدة التحكم مطلوب للعديد من مكالمات API. هذا يعني أنه يتم تخزين جميع بيانات المهمة في ذاكرة الوصول العشوائي (RAM) ، والتي يمكن أن تكون غير فعالة. يستهلك المؤشر عادةً حوالي 32 بت من الذاكرة.
- يمكن تعريف المهمة باستخدام "رقم فهرس" تعسفي. قد تكون هذه القيمة مفيدة عند منح الوصول إلى السجلات في جداول معينة. يمكن أن يشغل هذا المعرف ثمانية بتات أو أقل من الذاكرة ، اعتمادًا على القيود المفروضة على عدد المهام التي يدعمها RTOS.
- تسمح بعض أنظمة RTOS بمهمة واحدة فقط لكل مستوى أولوية وبالتالي تستخدم الأولوية لتحديد مهمة بشكل فريد. هذا يعني أنه لا يمكن تغيير أولوية المهمة. هذا النهج هو اختلاف عن النهج السابق.
- يمكن أن تحتوي المهام على أسماء عبارة عن سلاسل أحرف. قد يكون هذا مفيدًا لتصحيح الأخطاء ، ولكن من غير المحتمل أن يكون وسيلة فعالة لتحديد مهمة بشكل فريد. عادةً ما تحتوي أجهزة RTOS التي تدعم تسمية المهام على معرف إضافي (مثل المؤشر) يتم استخدامه بواسطة مكالمات API ، وما إلى ذلك. يسمح لك المصحح الجيد بالاتصال بها محليًا على المضيف.
المقالات السابقة في السلسلة:
المادة رقم 3. المهام والتخطيطالمادة رقم 2. RTOS: البنية ووضع الوقت الحقيقي
المادة رقم 1. RTOS: مقدمة.
تبديل السياق
تبديل السياق هو عملية نقل التحكم من مهمة إلى أخرى. يستحق هذا الموضوع استكشافه عن كثب ، حيث أن كيفية عمل تبديل السياق هي مبدأ أساسي لـ RTOS.
ما هي المهمة؟
نحن نعلم أن المهمة هي برنامج شبه مستقل يشارك وقت المعالج مع عدد من المهام الأخرى تحت سيطرة RTOS. ولكن عليك التفكير فيما يميز المهمة حقًا.
مجموعة التسجيل
المهمة هي في النهاية مجموعة فريدة من قيم تسجيل المعالج. يتم تحميلها إما في سجلات المعالج (أي أن المهمة حديثة) ، أو يتم تخزينها في مكان ما حتى وقت التنفيذ المجدول. في عالم مثالي ، سيكون للمعالج المركزي عدة مجموعات من السجلات ، ويمكن تعيين كل منها لمهمة منفصلة. تم تنفيذ هذا للمناسبات الخاصة. قبل عدة سنوات ، كانت سلسلة Texas Instruments TI 9900 تحتوي على مجموعات عديدة من السجلات لكل وظيفة ، ولكن تم تنفيذها في الذاكرة الرئيسية ، مما حد من الأداء. تدعم بنية SPARC (المستخدمة سابقًا في أنظمة سطح المكتب Unix) العديد من مجموعات التسجيلات في "بنية الحلقة" ، ولكن عدد المجموعات لا يزال محدودًا.
البيانات الداخلية
من المحتمل أن يكون للمهمة مجموعة خاصة بها ، يمكن تعيين حجمها بشكل منفصل لكل مهمة أو يمكن أن يكون معلمة عامة لجميع المهام في النظام. هذا ، إلى جانب السجلات ، يوفر تخزين البيانات لمهام محددة. قد تكون هناك مناطق أخرى من الذاكرة لتخزين البيانات لمهمة معينة.
الموارد المشتركة
عمليا يمكن مشاركة أي موارد بين المهام. يمكن أن يكون الرمز عامًا: إما وظائف معينة ، أو رمز المهمة بأكمله. من الضروري التأكد من أن الكود هو مرة أخرى ، أولاً وقبل كل شيء ، لا يجب استخدام المتغيرات الثابتة (المحددة على أنها ثابتة أو خارج الوظيفة فقط). كن حذرًا مع وحدات المكتبة القياسية غير المخصصة للاستخدام المدمج ؛ عادة ما يكون لديهم الكثير من الوظائف غير الموثوق بها.
مشاركة البيانات ممكنة أيضًا ، ولكن التحكم الدقيق في الوصول ضروري. من الناحية المثالية ، مهمة واحدة فقط هي "مالك" البيانات في أي وقت.
كيفية الحفاظ على السياق
عندما تتم إعادة جدولة المهمة (أي ، تتوقف عن كونها حالية) ، يجب حفظ مجموعة السجلات الخاصة بها في مكان ما. هناك احتمالان على الأقل:
- يمكن تخزين السجلات في جدول خاص للمهام. قد يكون جزءًا من كتلة التحكم بالمهام (TCB). الحجم هو قيمة يمكن التنبؤ بها وثابتة (لبنية وحدة معالجة مركزية محددة).
- يمكن دفع التسجيلات إلى مكدس المهام. يتطلب ذلك تخصيص مساحة تكديس إضافية كافية وتخزين المؤشر (ربما في TCB).
يعتمد اختيار الآلية على ميزات RTOS معينة وعلى المعالج الهدف. يمكن لبعض الأجهزة (عادة 32 بت) الوصول إلى المكدس بكفاءة ؛ قد يكون الباقي (على سبيل المثال ، 8 بت) أكثر مثالية عند العمل مع الجداول.
إنشاء مهمة ديناميكية
الجانب الرئيسي من بنية RTOS هو أن RTOS إما "ثابتة" أو "ديناميكية".
عند استخدام RTOS ثابت ، يتم تحديد كل شيء أثناء إنشاء التطبيق ، على وجه الخصوص ، عدد المهام في النظام. هذا هو حل منطقي للتطبيقات المضمنة ، والتي عادة ما تكون وظائفها محدودة.
تطلق Dynamic RTOS مهمة واحدة (والتي يمكن أن تكون مهمة "رئيسية" متخصصة) ، كما تنشئ وتحذف مهام أخرى حسب الحاجة. وهذا يسمح للنظام بالتكيف مع المتطلبات المتغيرة وهو نظير أقرب لنظام سطح المكتب ، الذي يتصرف بهذه الطريقة. ينطبق العرض الثابت / الديناميكي أيضًا على كائنات kernel الأخرى.
متطلبات إنشاء المهام الديناميكية
يتم تضمين هذه الميزة في معظم RTOS التجارية. ومع ذلك ، لا يحتاج سوى جزء صغير من التطبيقات إلى وضع ديناميكي للتشغيل. في كثير من الأحيان ، يبدأ النظام في إنشاء جميع المهام الضرورية (والكائنات الأخرى) ، ومن ثم لا يُنشئ رمز التطبيق ويدمره بعد الآن. أصبحت القدرة على إنشاء مهام ديناميكية شكليًا. قدمه أحد الموردين ، وحذو حذوه الآخرون.
من الجدير بالذكر أن معيار OSEK / VDX يتطلب بنية ثابتة ، على الرغم من أن هذا قد ينطبق على التطبيقات المعقدة إلى حد ما. نتيجة هذه المتطلبات هي عدم القدرة على تنفيذ OSEK / VDX مع غلاف ، طبقة متوسطة فوق RTOS (ديناميكي) عادي.
مطبات خلق مهمة ديناميكية
هناك العديد من المشكلات في وضع التشغيل الديناميكي التي يمكن أن تكون مزعجة.
أولاً ، يصبح النظام أكثر تعقيدًا ، مما يعني أنه بالنسبة لهياكل البيانات التي تصف المهام (TCBs) ، هناك حاجة إلى معلومات إضافية. كقاعدة ، يتم تنفيذها في شكل قوائم ثنائية الاتجاه ، مما يؤدي إلى التكاليف المرتبطة بحجم الذاكرة.
يجب تخزين جميع البيانات التي تصف المهمة في ذاكرة الوصول العشوائي. هذا غير فعال ، لأن معظمها قد يكون ببساطة عناصر بيانات ثابتة منسوخة من ROM. بالإضافة إلى ذلك ، قد لا تحصل على ذاكرة الوصول العشوائي على المعالجات ذات المستوى الأدنى (وحدات التحكم الدقيقة).
ربما يكون الأمر الأكثر مدعاة للقلق هو إمكانية حدوث نقص غير متوقع في الموارد ، مما قد يؤدي إلى عدم القدرة على إنشاء أشياء جديدة. نظرًا لأن جوهر النظام في الوقت الفعلي هو إمكانية التنبؤ به ، فهذا أمر غير مقبول. لذلك ، يجب توخي الحذر عند استخدام إنشاء المهام الديناميكية (والكائنات الأخرى).
الانقطاعات
من الممكن أن يتم تنفيذ نظام مضمن في الوقت الفعلي دون استخدام المقاطعات ، ولكن هذا ليس نموذجيًا.
المقاطعات و Kernel
عند استخدام RTOS ، يتم تسهيل معالج المقاطعة (ISR) قدر الإمكان "لسرقة" الحد الأدنى من وقت المعالج من المهام المجدولة. غالبًا ما يمكن صيانة الجهاز ببساطة ، وسيتم وضع أي مهمة مطلوبة في قائمة الانتظار للمعالجة. بالإضافة إلى ذلك ، من الصعب التحدث بشكل عام عن المقاطعات وتفاعلها مع النواة ، لأنها ببساطة تختلف اختلافًا كبيرًا. من ناحية ، يمكن لمطور RTOS التأكد من أن المقاطعات لا تتعلق بالنواة على الإطلاق ، وسيتعين على المبرمج التأكد من عدم تحميل برنامج جدولة المهام بشكل زائد ، باستخدام الكثير من وقت المعالج في ISR. من ناحية أخرى ، يمكن لـ RTOS التحكم بشكل كامل في النظام الفرعي للمقاطعة بالكامل. لا يوجد أي من الطرق الموصوفة صحيحة أو خاطئة ، فهي مختلفة فقط.
حفظ السياق
تحتاج ISR دائمًا إلى الحفاظ على "سياق" بحيث لا تتأثر الشفرة القابلة للانقطاع بحسابات ISR. في نظام يتم تنفيذه بدون نظام RTOS ، فإن الأمر يتعلق ببساطة بحفظ أي سجلات يستخدمها ISR (عادةً على المكدس) واستعادتها قبل العودة. تحتوي بعض المعالجات على مكدس ISR مخصص ، بينما يستخدم البعض الآخر المكدس نفسه الذي يستخدمه رمز التطبيق.
عند استخدام RTOS ، قد يكون النهج هو نفسه تمامًا. بنفس الطريقة ، يمكن "استعارة" المكدس المستخدم بواسطة ISR من المهمة الحالية ، أو يمكن أن يكون مكدس آخر مخصص للمقاطعات. تقوم بعض النوى بتنفيذ هذه الميزة ، حتى إذا كان المعالج نفسه لا يدعم مكدس المقاطعة. الوضع معقد إذا قام ISR بإجراء مكالمة API تؤثر على برنامج جدولة المهام. يمكن أن يؤدي ذلك إلى عودة المقاطعة إلى مهمة أخرى من المهمة التي تم بدءها عند حدوث المقاطعة.
المقاطعات والجدولة
هناك العديد من الظروف التي قد يعود فيها رمز تنفيذ ISR إلى مهمة أخرى:
- يمكن لـ ISR تعيين أولوية أعلى لمهمة مكتملة بالفعل ، بدلاً من المهمة الحالية ، إذا تم استخدام جدولة مهمة الأولوية.
- قد ISR إيقاف المهمة الحالية مؤقتًا.
- باستخدام أداة جدولة الشرائح الزمنية (TS) ، سيتحكم معالج مقاطعة موقت النظام في الفترات الزمنية ويمكنه الاتصال بالجدولة إذا لزم الأمر.
مؤقت الساعة (ساعة القراد)
في الأنظمة المدمجة ، غالبًا ما يتم العثور على استخدام "مؤقت ساعة" دوري (شريحة زمنية). في بعض RTOS ، هو مكون مطلوب. عادةً ما يكون وجود مؤقت الساعة اختياريًا ، وغيابه يحول ببساطة دون توفر بعض الخدمات. يوفر معالج مقاطعة المؤقت عادةً أربع وظائف:
- إذا تم استخدام جدولة فتحة زمنية ، فإن معالج مقاطعة المؤقت سوف يتحكم في عداد الوقت وجدولة مهمة جديدة في كل مرة ينفد فيها الوقت.
- يوفر دعم وقت النظام. هذا هو في الأساس متغير 32 بت يتم زيادته بواسطة جهاز ضبط الوقت ويمكن تحديده مسبقًا أو طلبه بواسطة المهام.
- إذا قام RTOS بتزويد التطبيقات بمؤقتات ، فسيتم دعمه بواسطة معالج مقاطعة مؤقت يكون مسؤولاً عن انتهاء الصلاحية وإعادة الجدولة.
- إذا كان RTOS يدعم المهلات في حظر مكالمات API أو المهام التي قد تكون في حالة سكون ، فسيتم دعم هذه الفترات الزمنية بواسطة معالج مقاطعة المؤقت.
عندما عملنا على نظام التشغيل OSRV MAX الخاص بنا (المقالات المنشورة سابقًا حوله) ، "وصل فريقنا" إلى مدونة Colin Walls ، الخبيرة في الإلكترونيات الدقيقة والبرامج الثابتة في Mentor Graphics. بدت المقالات مثيرة للاهتمام ، وترجمتها لأنفسهم ، لكن لكي لا "يكتبوا على الطاولة" قرروا نشرها. آمل أن تكون مفيدة لك أيضًا. إذا كان الأمر كذلك ، فنحن نخطط لنشر جميع المقالات المترجمة في السلسلة.
نبذة عن الكاتب: يعمل Colin Walls في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، ويكرس معظم وقته للبرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). غالبًا ما يتحدث كولين وولز في المؤتمرات والندوات ، مؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة. مدونة كولين المهنية: blogs.mentor.com/colinwalls ، البريد الإلكتروني: colin_walls@mentor.com
اقرأ المقالات
الأولى والثانية والثالثة في السلسلة المنشورة سابقًا.