كان المطلب الرئيسي لتطوير Nucleus SE هو درجة عالية من التوافق مع منتج Mentor RTOS الرئيسي - Nucleus RTOS. يدعم Nucleus SE جزءًا معينًا من وظائف Nucleus RTOS ، والتي تمت مناقشتها عدة مرات في مقالات سابقة ، ولكن في هذه المقالة سأحاول جمع كل الاختلافات الرئيسية في مكان واحد. تم تصميم هذه المقالة لتكون مرجعًا سريعًا لكل شخص سينتقل من قلب إلى آخر أو في عملية اختيار نواة لمشروع معين.
بالإضافة إلى وظائف محدودة أو مبسطة ، مقارنةً بـ Nucleus RTOS ، تم تصميم Nucleus SE أيضًا مع التركيز على زيادة استخدام الذاكرة إلى أقصى حد مع خيارات التخصيص الشاملة. جزء مهم من هذا النهج هو قابلية التوسع. يمكن تنشيط العديد من ميزات وظيفة kernel أو تعطيلها عند الضرورة. من الواضح أن تعطيل الوظيفة في تطبيق معين يزيد من عدم توافقها مع Nucleus RTOS.
في Nucleus RTOS ، يمكن إنشاء نظام بعدد غير محدد من كائنات kernel ؛ والقيد الوحيد هنا هو مقدار الموارد المتاحة (أي الذاكرة). يحتوي Nucleus SE على ستة عشر كائنًا من كل نوع ؛ يمكن أن يحتوي النظام من مهمة إلى ستة عشر مهمة ومن الصفر إلى ستة عشر كائنًا من كل نوع (صناديق البريد وقوائم الانتظار وما إلى ذلك). على الرغم من إمكانية زيادة هذا الحد ، ستكون هناك حاجة إلى بذل جهد كبير ، لأن Nucleus SE تستخدم بشكل مكثف القدرة على تخزين فهرس كائن في nibble (أربعة بتات). بالإضافة إلى ذلك ، مع أكثر من ستة عشر مهمة ، من المحتمل أن يصبح برنامج جدولة الأولوية غير فعال للغاية. إن التطبيق الذي تعاني وظيفته بشكل خطير من هذه القيود غير مناسب لـ Nucleus SE ، وفي هذه الحالة يعد Nucleus RTOS خيارًا أكثر ملاءمة.
المقالات السابقة في السلسلة: مخطط
مثل كل النوى الحديثة في الوقت الحقيقي ، Nucleus RTOS لديه جدولة مرنة للغاية توفر عدة مستويات من الأولوية (مع عدد غير محدد من المهام في كل مستوى من مستويات الأولوية) ، وكذلك القدرة على اختيار جدولة Round Robin و Time Slice. يعد Nucleus SE أكثر بساطة ويقدم أربعة أجهزة جدولة يجب تحديدها في وقت الإنشاء: تشغيل إلى الاكتمال ، و Round Robin ، و Time Slice ، و Priority. من المستحيل الجمع بين برامج جدولة مختلفة (أي ، لا يوجد برنامج جدولة مركب). على سبيل المثال ، لا يمكنك تحديد مجموعة من Time Slice و Priority Scheduls. بالإضافة إلى ذلك ، يتيح لك جدولة الأولوية تعيين مهمة واحدة فقط لكل مستوى من مستويات الأولوية ، أي أن هناك العديد من مستويات الأولوية كما توجد مهام. يتم تعيين أولوية المهمة أثناء الإنشاء ولا تتغير بعد الآن (مثل الفاصل الزمني إذا تم تحديد جدولة Time Slice).
مكالمات API
واجهة برمجة التطبيقات (API) - "الوجه" المرئي لنظام التشغيل. ليس من المستغرب أن يكون الاختلاف بين Nucleus RTOS و Nucleus SE أكثر وضوحًا.
يختلف Nucleus SE API عن Nucleus RTOS API. ومع ذلك ، فقد تم تصميم واجهة برمجة تطبيقات Nucleus SE بعناية بحيث يمكن نقلها إلى جزء واجهة برمجة تطبيقات RTOS من Nucleus. يمكن لحاملي Nucleus RTOS المرخص لهم الحصول على "shell" (ملف رأس يحتوي على وحدات الماكرو
#define ) التي ستنفذ عملية النقل مباشرة تقريبًا.
من حقيقة أن Nucleus SE API يمكن أن يطلق عليه "مجموعة فرعية" من Nucleus RTOS API ، يستتبع ذلك أن بعض مكالمات API مفقودة. هذا صحيح وهو نتيجة حتمية لمعايير تطوير Nucleus SE. بعض مكالمات واجهة برمجة التطبيقات ببساطة لا معنى لها ، لأنها مرتبطة بوظيفة غير موجودة ؛ تم استبعاد مكالمات أخرى من أجل تبسيط تنفيذ بعض كائنات kernel. كل هذا موصوف بالتفصيل في الأقسام التالية من هذه المقالة.
وظائف API المشتركة
يحتوي Nucleus RTOS على وظائف API الشائعة لعدة أنواع مختلفة من كائنات kernel ، أو حتى جميع أنواع الكائنات. تم تنفيذ بعضها أيضًا في Nucleus SE ، وتم إعادة ضبط مثال جيد على هذه الوظيفة. وظائف أخرى غير قابلة للتطبيق على تنفيذ كائنات kernel في Nucleus SE.
إنشاء وحذففي Nucleus RTOS ، جميع كائنات kernel ديناميكية ؛ يتم إنشاؤها وحذفها حسب الحاجة. لذلك ، هناك استدعاءات API لهذا. في Nucleus SE ، تكون جميع الكائنات ثابتة (يتم إنشاؤها أثناء التجميع) ، لذلك ليست هناك حاجة إلى استدعاءات API هذه.
إعادة المؤشرات إلى الكائناتالمعرف الرئيسي (واصف) كائنات kernel في Nucleus RTOS هو مؤشر إلى كتلة التحكم في الكائن ، والذي يتم تعيينه عند إنشاء الكائن. لذلك ، هناك أيضًا مجموعة من استدعاءات API التي تُرجع قائمة بالمؤشرات إلى كائنات من كل نوع. نظرًا لأن Nucleus SE يستخدم فهرسًا بسيطًا لتحديد كائنات kernel ، فإن هذه المكالمات ليست ضرورية. يمكن للبرنامج استقصاء النواة لمعرفة عدد مثيلات الكائنات من نوع معين التي تم تكوينها (باستخدام مكالمة مثل
NUSE_Mailbox_Count () ) ؛ إذا كانت هذه القيمة هي
n ، فسيكون لمؤشرات الكائنات من هذا النوع قيم من الصفر إلى
n-1 .
تدفق البياناتبالنسبة لبعض أنواع كائنات kernel لـ Nucleus RTOS (مثل صناديق البريد وقوائم الانتظار والأنابيب) ، يتم توفير حمولة API لترجمة البيانات. هذا يسمح لك بإرسال البيانات إلى كل مهمة تتوقع البيانات من الكائن. تم استبعاد هذا الاحتمال من Nucleus SE لتبسيطه ، حيث أن الوصول إلى بيانات هذه الكائنات يتم دائمًا في سياق مهمة محددة ، والتي تحرر الكائن بعد ذلك. لذلك ، لتنفيذ الترجمة ، ستكون هناك حاجة إلى آلية إشارة إضافية.
ميزات فريدة من نوعها كائنات API
تحتوي العديد من كائنات kernel على مكالمات API فريدة من نوعها لنوع معين من الكائنات وتختلف في Nucleus RTOS و Nucleus SE.
المهامنظرًا لأن Nucleus RTOS Scheduler أكثر تعقيدًا بكثير من Nucleus SE ، فإن بعض وظائف API ليست ضرورية:
- تغيير موضع مقاطعة المهمة - غير معتمد في Nucleus SE.
- تغيير أولوية المهمة - في Nucleus SE ، يتم تعيين أولوية المهمة أثناء التكوين ولا يمكن تغييرها.
- تغيير فتحة وقت المهمة - في Nucleus SE ، تعد قيمة فتحة الوقت شائعة في جميع المهام ويتم ضبطها أثناء التهيئة.
- إتمام المهمة - لا تدعم Nucleus SE حالة المهمة "المكتملة".
الذاكرة الديناميكيةنظرًا لأن كل شيء يتم إنشاؤه بشكل ثابت في Nucleus SE ، فإن الذاكرة الديناميكية غير مدعومة (وغير مطلوبة). لذلك ، وظائف API المرتبطة ليست ضرورية أيضًا.
إشاراتيدعم Nucleus RTOS معالجات الإشارات ، والبرامج التي تعمل (مثل معالجات المقاطعة) عندما تتغير إشارات المهام. تم استبعاد هذه الميزة من Nucleus SE ، لذلك ، ليست هناك حاجة إلى استدعاءات API لإدارة الإشارات وإنشاء معالج إشارة.
المقاطعاتيستخدم Nucleus SE أسلوب عدم مقاطعة المقاطعات ، ويوفر ببساطة القدرة على إجراء بعض مكالمات API من معالج المقاطعة. لذلك ، لا يتم دعم بعض استدعاءات Nucleus RTOS API التي تحدد الطريقة التي يجب أن يتعامل بها kernel مع المقاطعات.
التشخيصيتمتع Nucleus SE بخدمات تشخيصية متواضعة للغاية ، يتبع أسلوب التطوير "المقيد" ، ويقصر نفسه على التحقق من المعلمات (اختياري) وإخراج رمز إصدار المنتج. لذلك ، لا يتم دعم استدعاءات Nucleus RTOS API المتعلقة بتسجيل السجل وتأكيد الخطأ.
السائقينيحتوي Nucleus RTOS على هيكل برنامج تشغيل رسمي واضح المعالم والعديد من وظائف API المتعلقة بإدارة السائق. لا يحتوي Nucleus SE على هذه البنية ؛ وبالتالي ، فإن مكالمات واجهة برمجة التطبيقات المقابلة ليست ضرورية.
وظيفة استدعاء API
بعض جوانب وظيفة Nucleus SE ، والتي يتم تنفيذها في شكل مبسط ، تؤدي إلى اختلافات عن Nucleus RTOS. يؤثر بعضها على كيفية استخدام مكالمات API والخدمات المتاحة.
مهلة
عند استخدام Nucleus RTOS ، غالبًا ما تكون هناك مواقف يمكن فيها لمكالمة واجهة برمجة التطبيقات (API) إيقاف مهمة في انتظار الوصول إلى مورد: يتم حظر المهمة. يمكن أن يكون تعليق المهمة هذا ضمنيًا (أي ، حتى يصبح المورد متاحًا) ، أو يمكن تحديد قيمة مهلة. يوفر Nucleus SE الحجب بواسطة مكالمات واجهة برمجة التطبيقات كخيار ، ومع ذلك ، يمكن استخدام التعليق الضمني فقط (أي ، يمكن للمكالمة فقط استخدام
NUSE_SUSPEND أو
NUSE_NO_SUSPEND ، وليس قيمة مهلة). هذه الميزة بسيطة للغاية لإضافتها إلى Nucleus SE.
إجراءات التعليق
عند إنشاء أنواع كائنات متعددة في Nucleus RTOS ، يمكن تعيين أمر تعليق. هذا هو التسلسل الذي سيتم فيه استئناف العديد من المهام المحظورة عند توفر الموارد. يوجد خياران متاحان: FIFO ، أول من يخرج أولاً (أولاً من الأول) ، حيث يتم استئناف المهام بنفس الترتيب الذي تم حظره به ؛ أو حسب الأولوية ، حيث تستأنف المهمة التي لها أعلى أولوية دائمًا أولاً. Nucleus SE لا تقدم مثل هذا الاختيار. ينفذ فقط ترتيب الأولويات. في الواقع ، من الأصح قول الترتيب حسب فهرس المهام ، حيث يمكن تطبيق أمر التعليق ليس فقط عند استخدام جدولة الأولوية ، ولكن أيضًا عند استخدام جدولة Round Robin و Time Slice.
وظيفة ميزة فريدة من نوعها
في بعض الحالات ، كانت التغييرات الوظيفية المتعلقة بأنواع معينة من الأشياء ضرورية.
معالجات الإشارةكما ذكر أعلاه ، فإن تنفيذ الإشارة في Nucleus SE لا يدعم إجراءات معالجة الإشارات.
إعدادات توقيت التطبيقللموقت مدة أولية / مدة تشغيل أولية ومدة إعادة تشغيل ويمكن أن يؤدي اختيارياً وظيفة معرفة من قبل المستخدم عند الانتهاء. هذه الوظيفة مدعومة في كل من Nucleus RTOS و Nucleus SE. ومع ذلك ، فإن Nucleus SE ، بخلاف Nucleus RTOS ، لا يسمح بتغيير المعلمات الموصوفة أعلاه عند استدعاء وظيفة API لإعادة التعيين. بالإضافة إلى ذلك ، في Nucleus SE ، كل دعم لإجراءات إتمام الموقت اختياري.
أعلام الحدثNucleus RTOS لديه خيار "لاستيعاب" أعلام الحدث. هذا يعني أنه يتم إعادة تعيين الإشارات التي تطابق المعايير التي حددتها المهمة. هذه الوظيفة غير مدعومة في Nucleus SE ، لأن القدرة على البحث عن معايير للعديد من المهام تزيد بشكل كبير من تعقيد النظام.
أحجام البيانات
أدى معياران لتطوير Nucleus SE: الحفاظ على البساطة وتقليل استخدام الذاكرة إلى بعض الاختلافات في أحجام عناصر البيانات مقارنةً بـ Nucleus RTOS. تجدر الإشارة إلى أن Nucleus RTOS عادةً ما يستخدم بيانات
غير موقعة ، وهو على الأرجح 32 بت. بينما يستخدم Nucleus SE أنواع بيانات انسيابية مثل
U32 و
U16 و
U8 وما إلى ذلك. (
ملاحظة المترجم: في رأيي ، المؤلف مناسب للأنظمة ذات 8 بت. في الأنظمة الحديثة ، لا تزال السجلات 32 بت ، لذلك فإن قطع الجزء الأقدم يستهلك ذاكرة لدورات التعليمات البرمجية ودورات الساعة لتنفيذها ، والبيانات متساوية مع 32 بت عند تخزينها في الذاكرة ، وإلا فإن أداء النظام سينخفض ، لذلك لا يعطي هذا الأسلوب مكسبًا للأنظمة الحديثة ، ويمكن أن تؤدي الخسارة بسبب الإرشادات التي أضافها المترجم والتي قطعت الجزء الأقدم بشكل جيد. ).
صناديق البريد
في Nucleus RTOS ، يخزن صندوق البريد رسالة تتكون من أربعة عناصر بيانات غير موقعة. في Nucleus SE ، يخزن صندوق البريد عنصر بيانات
ADDR . في رأيي ، تستخدم صناديق البريد غالبًا لنقل عنوان (يشير إلى بيانات محددة) من مهمة إلى أخرى.
طوابير
في Nucleus RTOS ، تقوم قائمة الانتظار بمعالجة الرسائل من عنصر أو أكثر من عناصر البيانات
غير الموقعة . يمكن أيضًا تكوين قائمة الانتظار لمعالجة الرسائل ذات الطول المتغير. في Nucleus SE ، تقوم قائمة الانتظار بمعالجة الرسائل التي تتكون من عنصر بيانات
ADDR واحد. في رأيي ، يتم استخدام قوائم الانتظار بطريقة مماثلة مع صناديق البريد. بالإضافة إلى ذلك ، في Nucleus RTOS ، يتم تحديد الحجم الإجمالي لقائمة الانتظار (أي إجمالي عدد العناصر غير الموقعة التي يمكن وضعها في قائمة الانتظار) كقيمة غير موقعة. في Nucleus SE ، هذه القيمة من النوع
U8 . لذلك ، يمكن أن تحتوي قائمة الانتظار على بيانات أقل.
قنوات البيانات
في Nucleus RTOS ، تعالج القناة الرسائل من بايت واحد أو أكثر ؛ يمكن أيضًا تكوين القناة للتعامل مع الرسائل ذات الطول المتغير. في Nucleus SE ، تقوم القناة بمعالجة الرسائل التي تتكون من عنصر أو أكثر من عناصر البيانات من النوع
U8 . يتم ضبط حجم الرسالة أثناء الإعداد لكل قناة. بالإضافة إلى ذلك ، في Nucleus RTOS ، يتم تحديد الحجم الكلي للقناة (أي إجمالي عدد البايتات التي يمكن وضعها في قناة) كقيمة غير
ملحوظة . في Nucleus SE ، هذه القيمة من النوع
U8 وتمثل عدد الرسائل (في استدعاء API
NUSE_Pipe_Information () ). وبالتالي ، يمكن أن تحتوي القناة على بيانات أقل.
مجموعات علم الحدث
في Nucleus RTOS ، تحتوي مجموعة علم الأحداث على 32 علامة ؛ في Nucleus SE ، يتم تقليل عددهم إلى ثمانية. لقد تم اختيار هذا الحجم لأن الهدف المحتمل لمعالجات Nucleus SE يمكن معالجة بيانات 8 بت بكفاءة. في الوقت نفسه ، لن يكون تغيير عدد العلامات في مجموعات العلم للأحداث التي تتم معالجتها بواسطة Nucleus SE أمرًا صعبًا.
إشارات
في Nucleus RTOS ، تحتوي كل مهمة على مجموعة من 32 إشارة إشارة. في Nucleus SE ، الإشارات اختيارية ، ولكل مهمة مجموعة من 8 أعلام. لقد تم اختيار هذا الحجم نظرًا لأن المعالجات المحتملة المستهدفة Nucleus SE يمكنها معالجة بيانات 8 بت بكفاءة. في الوقت نفسه ، لن يكون تغيير عدد الأعلام في مجموعات إشارة الإشارات التي تتم معالجتها بواسطة Nucleus SE أمرًا صعبًا.
أقسام الذاكرة
في Nucleus RTOS ، لم يتم
توقيع عدد وحجم الأقسام. في Nucleus SE ، عدد الأقسام هو معلمة من النوع
U8 ، وحجم القسم هو
U16 . هذا يؤدي إلى بعض القيود حجم التقسيم وحجم.
توقيت
في Nucleus RTOS ، تعمل أجهزة ضبط الوقت (كلاً من مؤقتات التطبيق وموقتات نوم المهام) مع القيم
غير الموقعة . في Nucleus SE ، هم من النوع
U16 . تم اختيار هذا النوع لأن الهدف المحتمل لمعالجات Nucleus SE يمكنه معالجة البيانات ذات 16 بت بكفاءة (وثمانية بتات لا تكفي بوضوح لاستخدام جهاز ضبط الوقت). في الوقت نفسه ، لن يكون تغيير حجم أجهزة ضبط الوقت في Nucleus SE أمرًا صعبًا.
سوف تدرس المقالة التالية كيف يمكن استخدام Nucleus SE في مشروع برنامج مضمن.
نبذة عن الكاتب: يعمل Colin Walls في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، حيث خصص معظم وقته للبرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). يتحدث Colin Walls غالبًا في المؤتمرات والندوات ، ومؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة.
مدونة كولن المهنية ، البريد الإلكتروني: colin_walls@mentor.com.