الحقيقة الكاملة عن RTOS. المادة رقم 8. Nucleus SE: التصميم الداخلي والنشر



تستمر هذه المقالة في مراجعة Nucleus SE.

الخدمات


يوفر Nucleus SE مجموعة من الأدوات التي يمكن توقعها من أي RTOS.
أولاً ، يحتوي Nucleus SE على جدولة بسيطة إلى حد ما ، ومع ذلك ، وبفضل الخيارات الأربعة المتاحة ، فإنه يوفر المرونة. يدعم المجدول خوارزميات Run to Completion و Round Robin و Carousel و Time Slice و Priority.

تتضمن واجهة برمجة تطبيقات Nucleus SE حوالي 50 مكالمة مساعدة توفر للمطورين إمكانية الوصول إلى إدارة المهام وأقسام الذاكرة والإشارات ومجموعات علامات الأحداث والأشارات وصناديق البريد وقوائم الانتظار وخطوط الأنابيب ووقت النظام وموقتات التطبيق والتشخيصات.

بالإضافة إلى جدولة المهام البسيطة ، يدعم Nucleus SE (اختياري) إيقاف المهمة مؤقتًا. يمكن أن تكون هذه الوظيفة "نظيفة" (على سبيل المثال ، نتيجة لمكالمة API لخدمة التعليق التي تم تعيينها بشكل صريح) ، يمكن أن تكون وظيفة "سكون" (عندما يتم تعليق المهمة لفترة معينة من الوقت) ، أو يمكن أن تكون نتيجة مكالمة API أخرى يتم فيها حظر المهمة (ما يسمى بالتعليق "المشروط") ، بانتظار الوصول إلى مورد النواة. على عكس Nucleus RTOS ، لا يدعم Nucleus SE المهلات عند حظر مكالمات API.

تتيح لك مجموعة الآليات المتنوعة الاختيار من بين تسلسل هرمي لوسائل التزامن والتواصل بين المهام: من الإشارات إلى الإشارات وعلامات الأحداث وصناديق البريد وقوائم الانتظار / خطوط الأنابيب.

المقالات السابقة في السلسلة:
المادة رقم 7. Nucleus SE: مقدمة
المادة رقم 6. خدمات RTOS الأخرى
المادة رقم 5. تفاعل المهام والمزامنة
المادة رقم 4. المهام وتبديل السياق والمقاطعات
المادة رقم 3. المهام والتخطيط
المادة رقم 2. RTOS: البنية ووضع الوقت الحقيقي
المادة رقم 1. RTOS: مقدمة.

التحقق من المعلمات


عند اختيار تكوين NUSE_API_PARAMETER_CHECKING ، يتم تضمين رمز التحقق من المعلمات في جميع وظائف واجهة برمجة التطبيقات: التحقق من المؤشرات الخالية ومؤشرات الكائن وما إلى ذلك ، نظرًا لأن هذا رمز إضافي يتطلب ذاكرة إضافية ، فمن الحكمة تمكين هذه الوظيفة أثناء التصحيح ، ولكن إيقاف تشغيلها في تجميع الإصدار.

التكوين


يتميز Nucleus SE بهيكل مرن يمنحنا نقطتين إيجابيتين. من ناحية ، يمكن أن يكون للنواة تكوين دقيق يفي بمهام تطبيق معين بسبب التكوين البسيط للوظائف المتاحة والإدارة البسيطة لاستخدام الذاكرة. من ناحية أخرى ، فإن كود Nucleus SE سهل الحمل بين كل من الأدوات وبين المعالجات.

اصطلاحات التسمية


نظرًا لأن الوضوح وسهولة الفهم كانا مهمين عند تطوير Nucleus SE ، فقد تم التفكير بعناية في اصطلاحات التسمية. يكون كل حرف في الرمز مسبوقًا بـ NUSE_. كل ما يتبع هذه البادئة يطيع مجموعة من القواعد البسيطة.

مكالمات API


تبدأ كل وظيفة استدعاء لواجهة برمجة التطبيقات في Nucleus SE بـ NUSE_ ، والذي يتبعه دائمًا نوع كائن ، متبوعًا بعملية ذات حالة مختلطة ، مفصولة بشرطة سفلية. مثال على ذلك هو الدالة NUSE_Queue_Send () ، التي تضع الرسائل في قائمة انتظار .

وظائف ومتغيرات أخرى


تستخدم بقية الوظائف والمتغيرات (العامة) في كود Nucleus SE أيضًا البادئة NUSE_ ، لكن باقي الاسم لا يحتوي دائمًا على "بنية". هذا غير مهم بالنسبة لمستخدم kernel العادي ، حيث سيكون لديه وظائف API كافية.

رموز التكوين


نظرًا لتهيئة Nucleus SE بأحرف #define ، فإنها تطيع أيضًا اصطلاحات التسمية. إنها مكتوبة فقط في حالة الأحرف الكبيرة. أسماء منشط مكالمات API هي نفس أسماء الوظائف ويتم كتابتها أيضًا بأحرف كبيرة ، على سبيل المثال ، NUSE_QUEUE_SEND.

# تعريف شخصيات أخرى


أي أحرف أخرى #define (على سبيل المثال ، معلمات استدعاء API وقيم حالة الإرجاع) التي يمكن استخدامها بواسطة رمز التطبيق تخضع للقواعد نفسها ، تبدأ بـ NUSE_ ويتم كتابتها بأحرف كبيرة. على سبيل المثال ، NUSE_SUCCESS.

هياكل البيانات


تحتوي جميع أنظمة RTOS على مجموعة من هياكل البيانات التي تصف كائنات kernel. في معظم التطبيقات ، فهي عبارة عن هياكل بيانات في C تشكل قوائم مرتبطة ، غالبًا مع اتصال ثنائي الاتجاه وحتى دائري. هذا أمر منطقي ، حيث يتم تغليف البيانات المهمة بشكل ملائم ، ويمكن إضافة عناصر القائمة أو حذفها أثناء إنشاء الكائنات وحذفها.

في Nucleus SE ، تكون جميع الكائنات ثابتة ، لذلك كان تنظيم جميع هياكل هذه الكائنات في قائمة بسيطة هو الحل الواضح. هذا يقلل من حجم وتعقيد المؤشرات الأمامية والعكسية. ومع ذلك ، قررت تعزيز الاستفادة المثلى من النظام ورفضت استخدام الهياكل على الإطلاق. في Nucleus SE ، يتم تمثيل جميع البيانات من كائنات kernel بعدة صفائف بسيطة (تسمى أيضًا الجداول) من أنواع مختلفة ، واحدة أو أكثر لكل نوع من الكائنات. هناك العديد من الحجج المؤيدة لهذا القرار:

  • تم تصميم Nucleus SE مع مراعاة التوافق مع الهياكل ذات 8 بت. لا تحتوي معظم وحدات المعالجة المركزية الصغيرة على الأدوات المثلى لتنفيذ هياكل البيانات في المترجم C. المصفوفات البسيطة هي أكثر كفاءة.
  • نظرًا لأن الحد الأقصى المسموح به من الكائنات من كل نوع هو 16 ، والوصول إلى عناصر كل صفيف يتطلب أربعة بتات ، غالبًا ما يتم استخدام بايت واحد. يعد هذا أكثر فاعلية من العنوان الذي يستغرق عادة 16 أو 32 بت.
  • يجب تخزين بيانات الكائن الدائم في ROM وعدم نسخها إلى ذاكرة الوصول العشوائي. نظرًا لأنه لا يمكن تقسيم البنية بين ROM و RAM (في لغة C التقليدية المحمولة) ، يمكن أن يكون لكل نوع من الكائنات هيكلان ، معقدان بشكل مفرط. في Nucleus SE ، يمكن العثور على جداول وصف الكائنات في كل من ROM و RAM ، حسب الحاجة.
  • نظرًا للتكوين العالي لـ Nucleus SE ("قابلية التوسع الفائقة") ، قد تكون بعض بيانات وصف الكائن اختيارية ، اعتمادًا على الأدوات المحددة. هذا يؤدي إلى استخدام واسع النطاق للترجمة المشروطة. من الصعب للغاية فهم التعريف الهيكلي مع توجيهات الترجمة الشرطية المضمنة. إن التحكم في إنشاء المصفوفات الفردية باستخدام هذه الطريقة ، سهل الفهم.


تخضع جميع جداول بيانات الكائنات لاتفاقية التسمية الهرمية المذكورة أعلاه. وبالتالي ، من السهل جدًا فهم الجداول المرتبطة منطقيًا.

الاختلافات الرئيسية عن Nucleus RTOS


على الرغم من تصميم Nucleus SE بدرجة عالية من التوافق مع Nucleus RTOS ، لا يمكن تجنب بعض الاختلافات الصغيرة والكبيرة. سيتم وصفها بالتفصيل في المقالات ذات الصلة ، ويرد وصف موجز أدناه.

بيانات الكائن


في Nucleus RTOS ، يتم إنشاء الكائنات وحذفها عند الطلب. في Nucleus SE ، يتم إنشاء جميع الكائنات بشكل ثابت وتحديدها أثناء التجميع.

عدد الأشياء


يدعم Nucleus RTOS عددًا غير محدود من العناصر من كل نوع. يدعم Nucleus SE بحد أقصى ستة عشر جسمًا من كل نوع.

أسماء الكائنات


يسمح لك Nucleus RTOS بتعيين أنواع نصية لبعض أنواع الكائنات التي يمكن استخدامها لتصحيح الأخطاء. لا تحتوي Nucleus SE على هذه الميزة.

آلية قفل المهام


آلية حظر المهام باستخدام مكالمة API في Nucleus SE بسيطة جدًا. عند تحرير مورد ، يتم استئناف جميع المهام المعلقة وتتنافس مع بعضها البعض (باستخدام برنامج جدولة المهام) على الموارد. يتم تعليق المهام الخاسرة مرة أخرى (حظر). في Nucleus RTOS ، تكون الآلية أكثر تعقيدًا ، ولا تستمر سوى المهام المهمة فيها ، وهو أكثر فعالية.

مهلة مكالمة API


عند استدعاء واجهة برمجة التطبيقات للحظر ، يسمح Nucleus RTOS للمطور بتحديد فترة المهلة التي سيتم بعدها استئناف المكالمة حتى إذا لم يتم تحرير المورد. لا تحتوي Nucleus SE على هذه الميزة.

جدولة المهام


يتميز Nucleus RTOS Scheduler بالمرونة والفعالية وتحديده جيدًا. تقدم Nucleus SE مجموعة من الجداول ، كل منها بسيط وفعال بما يكفي لعدد أقل من المهام المدعومة: من 1 إلى 16.

أولويات المهمة


يمكن أن يكون للنظام الذي يستخدم Nucleus RTOS عددًا عشوائيًا من المهام التي يمكن تعيينها على مستوى 256 أولوية ، بينما يمكن أن يكون للعديد من المهام مستوى أولوية واحد. يمكن أيضًا تغيير مستويات أولوية المهمة في وقت التشغيل. في Nucleus SE ، إذا تم تحديد جدولة أولوية ، يجب أن يكون لكل مهمة مستوى أولوية فريد لا يمكن تغييره ديناميكيًا. يمكن أن يكون هناك مستوى أولوية واحد فقط لكل مهمة.

معالجة المقاطعة


يدعم Nucleus RTOS البنية المتطورة لمعالج المقاطعة ذي المستويين الذي يتيح إمكانية التشغيل المتداخل بين معالج النواة وخدمات kernel. يستخدم Nucleus SE أسلوبًا مشابهًا يدعم معالجات المقاطعة البسيطة غير kernel (المقاطعات غير المُدارة) ومعالجات المقاطعة التي تدرك السياق تمامًا والتي يمكنها استخدام مكالمات API (المقاطعات المُدارة).

برامج تشغيل الجهاز


يتميز Nucleus RTOS ببنية تشغيل برنامج تشغيل الجهاز جيدة التصميم. لا يمتلك Nucleus SE مثل هذه البنية ، مما يترك للمطور مهمة توزيع التحكم في الجهاز بين المهام ورمز معالج المقاطعة.

توزيع Nucleus SE


سيتم نشر أكواد مصدر Nucleus SE مع تطور هذه السلسلة من المقالات. ستكون الملفات المتاحة متاحة عند الطلب عن طريق البريد الإلكتروني. في نهاية سلسلة المقالات ، سيتم إنشاء مستودع لتنزيل جميع الملفات المنشورة.

عن المؤلف
يعمل كولين وولز في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، حيث يقضي معظم وقته في البرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). غالبًا ما يتحدث كولين وولز في المؤتمرات والندوات ، مؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة. البريد الإلكتروني للمدونة المهنية لكولين

Source: https://habr.com/ru/post/ar422617/


All Articles