الحقيقة كاملة حول RTOS. المادة رقم 33. باستخدام نظام التشغيل Nucleus SE في الوقت الحقيقي

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



المقالات السابقة في السلسلة:
المادة رقم 32. Nucleus SE Migration: ميزات غير محققة وتوافق
المادة رقم 31. التشخيص والخطأ التحقق من RTOS
المادة رقم 30. نواة SE التهيئة وإجراءات بدء التشغيل
المادة رقم 29. انقطاع في نواة SE
المادة رقم 28. توقيت البرمجيات
المادة رقم 27. وقت النظام
المادة رقم 26. القنوات: الخدمات المساعدة وهياكل البيانات
المادة رقم 25. قنوات البيانات: مقدمة والخدمات الأساسية
المادة رقم 24. قوائم الانتظار: الخدمات المساعدة وهياكل البيانات
المادة رقم 23. قوائم الانتظار: مقدمة والخدمات الأساسية
المادة رقم 22. صناديق البريد: الخدمات المساعدة وهياكل البيانات
المادة رقم 21 صناديق البريد: مقدمة والخدمات الأساسية
المادة رقم 20. Semaphores: الخدمات المساعدة وهياكل البيانات
المادة رقم 19. الإشارات: مقدمة والخدمات الأساسية
المادة رقم 18. مجموعات علم الحدث: خدمات المساعدة وهياكل البيانات
المادة رقم 17. مجموعات علم الحدث: مقدمة والخدمات الأساسية
المادة رقم 16. إشارات
المادة رقم 15. أقسام الذاكرة: الخدمات وهياكل البيانات
المادة رقم 14. أقسام الذاكرة: مقدمة والخدمات الأساسية
المادة رقم 13. بنيات بيانات المهمة ومكالمات API غير المدعومة
المادة رقم 12. خدمات للعمل مع المهام
المادة رقم 11. المهام: التكوين ومقدمة ل API
المادة رقم 10. المجدول: ميزات متقدمة والحفاظ على السياق
المادة رقم 9. المجدول: التنفيذ
المادة رقم 8. نواة SE: التصميم الداخلي والنشر
المادة رقم 7. نواة SE: مقدمة
المادة رقم 6. خدمات RTOS الأخرى
المادة رقم 5. مهمة التفاعل والتزامن
المادة رقم 4. المهام ، تبديل السياق ، و المقاطعات
المادة رقم 3. المهام والتخطيط
المادة رقم 2. RTOS: هيكل ووضع في الوقت الحقيقي
المادة رقم 1. RTOS: مقدمة.

ما هو Nucleus SE؟


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

من وجهة نظر رفيعة المستوى ، فإن التطبيق المضمن هو نوع من التعليمات البرمجية التي تبدأ عند بدء تشغيل وحدة المعالجة المركزية. في هذه الحالة ، تتم تهيئة بيئة البرامج والأجهزة ، ثم تسمى الوظيفة الرئيسية () ، والتي تطلق رمز التطبيق الرئيسي.

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

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

يتم توفير جميع برامج Nucleus SE ككود مصدر (بشكل أساسي في C). لتكوين الكود وفقًا لمتطلبات تطبيق معين ، يتم استخدام الترجمة الشرطية. يتم وصف هذا بالتفصيل في هذه المقالة في قسم التكوين.

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

وحدة المعالجة المركزية ودعم أداة


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

إعداد تطبيق Nucleus SE


مفتاح الاستخدام الفعال لـ Nucleus SE هو الإعداد المناسب. قد يبدو الأمر معقدًا ، ولكن في الواقع ، كل شيء منطقي تمامًا ويتطلب فقط منهجية منهجية. يتم إجراء جميع التكوينات تقريبًا عن طريق تحرير ملفين: nuse_config.h و nuse_config.c .

إعداد Nuse_config.h


هذا الملف هو مجرد مجموعة أحرف من التوجيه #define ، والتي تم تعيين القيم المناسبة للحصول على تكوين kernel اللازم. في ملف nuse_config.h ، بشكل افتراضي ، جميع الأحرف موجودة ، لكن يتم تعيين الحد الأدنى من الإعدادات لها.

عدادات الكائن
يتم تعيين عدد الكائنات kernel من كل نوع بواسطة قيم رمز النموذج NUSE_SEMAPHORE_NUMBER . بالنسبة لمعظم الكائنات ، يمكن أن تختلف هذه القيمة من 0 إلى 15. تعتبر المهام استثناء ، يجب أن يكون هناك واحد على الأقل. الإشارات ، في الواقع ، ليست كائنات مستقلة ، لأنها ترتبط بالمهام ويتم تشغيلها عن طريق تعيين NUSE_SIGNAL_SUPPOR T إلى TRUE .

المنشطات وظيفة API
يمكن تنشيط كل وظيفة من وظائف Nucleus SE API بشكل منفصل عن طريق تعيين رمز يطابق اسمه اسم الوظيفة (على سبيل المثال ، NUSE_PIPE_JAM ) على TRUE . هذا يؤدي إلى إدراج رمز الوظيفة في التطبيق.

اختيار جدولة والإعدادات
يدعم Nucleus SE أربعة أنواع من برامج الجدولة ، كما هو موضح في مقال سابق. يتم تعيين المجدول المستخدم من خلال تعيين NUSE_SCHEDULER_TYPE إلى إحدى القيم التالية: NUSE_RUN_TO_COMPLETION_SCHEDULER أو NUSE_TIME_SLICE_SCHEDULER أو NUSE_ROUND_ROBIN_SCHEDULER أو NUSE_PRIORITY_SCHEDULER .

يمكنك تكوين معلمات جدولة أخرى:
يشير NUSE_TIME_SLICE_TICKS إلى عدد علامات التجزئة في الفتحة لجدولة Time Slice. إذا تم استخدام جدولة أخرى ، فيجب تعيين هذه المعلمة على 0.
يمكن تعيين NUSE_SCHEDULE_COUNT_SUPPORT على TRUE أو FALSE لتمكين / تعطيل آلية عداد المجدول.
NUSE_SUSPEND_ENABLE يتيح تأمين المهام (تعليق) للعديد من وظائف API. هذا يعني أن استدعاء هذه الوظيفة يمكن أن يؤدي إلى تعليق مهمة الاستدعاء حتى يتم تحرير المورد. لتحديد هذا الخيار ، يجب أيضًا تعيين NUSE_SUSPEND_ENABLE على TRUE .

خيارات أخرى
يمكن أيضًا تعيين عدة معلمات أخرى قيم TRUE أو FALSE لتنشيط / إلغاء تنشيط وظائف kernel الأخرى:
يضيف NUSE_API_PARAMETER_CHECKING رمز التحقق من معلمة استدعاء دالة API. يشيع استخدامها لتصحيح الأخطاء.
يقوم NUSE_INITIAL_TASK_STATE_SUPPORT بتعيين الحالة الأولية لجميع المهام على أنها NUSE_READY أو NUSE_PURE_SUSPEND . إذا تم تعطيل هذه المعلمة ، فستكون جميع المهام هي الحالة الأولية NUSE_READY .
NUSE_SYSTEM_TIME_SUPPORT - دعم لوقت النظام.
NUSE_INCLUDE_EVERYTHING - معلمة تضيف الحد الأقصى لعدد الوظائف إلى تكوين Nucleus SE. إنه يؤدي إلى تنشيط جميع الوظائف الاختيارية وكل وظيفة API للكائنات المكونة. يستخدم لإنشاء تكوين Nucleus SE بسرعة للتحقق من ترقية جديدة لرمز kernel.

تحديد nuse_config.c


بعد تحديد تكوين kernel في nuse_config.h ، من الضروري تهيئة بنيات البيانات المختلفة المخزنة في ROM. يتم ذلك في ملف nuse_config.c . يتم التحكم في تعريف بنيات البيانات عن طريق الترجمة الشرطية ، بحيث يتم تضمين جميع الهياكل في نسخة من ملف nuse_config.c الافتراضي.

بيانات المهمة
يجب تهيئة الصفيف NUSE_Task_Start_Address [] بقيمة عناوين البدء لكل مهمة. عادة ما تكون هذه مجرد قائمة بأسماء الوظائف ، بدون أقواس. يجب أن تكون النماذج الأولية لوظائف إدخال المهام مرئية أيضًا. في الملف الافتراضي ، يتم تكوين المهمة باسم NUSE_Idle_Task () ، ويمكن تغيير هذا إلى مهمة التطبيق.

إذا كنت تستخدم أي برنامج جدولة ما عدا Run to Complete ، فإن كل مهمة تتطلب مكدسها الخاص. لكل مكدس مهمة ، يجب عليك إنشاء صفيف في RAM. يجب أن تكون هذه المصفوفات من نوع ADDR ، ويجب تخزين عنوان كل منها في NUSE_Task_Stack_Base [] . من الصعب التنبؤ بحجم المصفوفة ، لذلك من الأفضل استخدام القياسات (راجع قسم "تصحيح الأخطاء" لاحقًا في هذه المقالة). يجب أن يتم تخزين حجم كل صفيف (أي ، عدد الكلمات على المكدس) في NUSE_Task_Stack_Size [] .

إذا تم تمكين دالة للإشارة إلى الحالة الأولية للمهمة (باستخدام المعلمة NUSE_INITIAL_TASK_STATE_SUPPORT ) ، فيجب تهيئة الصفيف NUSE_Task_Initial_State [] مع NUSE_READY أو NUSE_PURE_SUSPEND .

قسم تجمع البيانات
إذا تم تكوين تجمع قسم واحد على الأقل ، يجب إنشاء صفيف (من النوع U8 ) لكل منها في ROM. يتم حساب حجم هذه المصفوفات على النحو التالي: (عدد الأقسام * (حجم القسم + 1)). يجب تعيين عناوين هذه الأقسام (أي ، أسماءهم) لعناصر NUSE_Partition_Pool_Data_Address [] المقابلة. بالنسبة لكل تجمع ، يجب وضع عدد الأقسام وحجمها في NUSE_Partition_Pool_Partition_Number [] و NUSE_Partition_Message_Size [] ، على التوالي.

قائمة انتظار البيانات
إذا تم تكوين قائمة انتظار واحدة على الأقل ، فيجب إنشاء صفيف (من نوع ADDR ) لكل منها في RAM. حجم هذه المصفوفات هو عدد العناصر في كل قائمة انتظار. يجب تعيين عناوين هذه المصفوفات (أي ، أسمائها) إلى عناصر NUSE_Queue_Data المقابلة. يجب تعيين حجم كل قائمة انتظار إلى العنصر NUSE_Queue_Size [] المقابل.

بيانات وصلة البيانات
إذا تم تكوين قناة بيانات واحدة على الأقل ، فيجب إنشاء مصفوفة (من النوع U8 ) في ذاكرة الوصول العشوائي (RAM) لكل منها (أو لكل منها). يتم حساب حجم هذه المصفوفات على النحو التالي: (حجم القناة * حجم الرسالة في القناة). يجب تعيين عناوين هذه المصفوفات (أي ، أسمائها) لعناصر NUSE_Pipe_Data [] المقابلة. لكل قناة ، يجب تعيين حجم الرسالة وحجمها لعناصر NUSE_Pipe_Size [] و NUSE_Pipe_Message_Size [] المقابلة ، على التوالي.

إشارة البيانات
إذا تم تكوين إشارة واحدة على الأقل ، فيجب تهيئة الصفيف NUSE_Semaphore_Initial_Value [] مع القيم الأولية للعد التنازلي.

بيانات التطبيق الموقت
إذا تم تكوين مؤقت واحد على الأقل ، فيجب تهيئة الصفيف NUSE_Timer_Initial_Time [] مع القيم الأولية للعدادات. بالإضافة إلى ذلك ، يجب تعيين NUSE_Timer_Reschedule_Time [] لقيم إعادة التشغيل. سيتم استخدام قيم المؤقت هذه بعد انتهاء دورة المؤقت الأول. إذا تم ضبط قيم إعادة التشغيل على 0 ، فسيتوقف العداد بعد دورة واحدة.

إذا تم تكوين دعم لآليات إكمال الحساب (عن طريق تعيين المعلمة NUSE_TIMER_EXPIRATION_ROUTINE_SUPPORT على TRUE ) ، يجب إنشاء صفيفين آخرين. يجب وضع عناوين آليات الإكمال (مجرد قائمة بأسماء الوظائف ، بدون أقواس) في NUSE_Timer_Expiration_Routine_Address [] . يجب تهيئة الصفيف NUSE_Timer_Expiration_Routine_Parameter [] مع قيم معلمات الإكمال.

أي API؟


جميع أنظمة التشغيل في شكل أو آخر لها واجهة برمجة تطبيقات (واجهة برمجة التطبيقات). Nucleus SE ليست استثناء ، وقد تم وصف الوظائف التي تشكل API بالتفصيل في هذه السلسلة من المقالات.

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

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

بالنسبة لبعض المستخدمين ، قد تكون واجهة برمجة التطبيقات البديلة خيارًا أكثر جاذبية. هناك ثلاث حالات واضحة حيث يكون ذلك ممكنًا.
  1. Nucleus SE هو جزء فقط من نظام يستخدم أنظمة تشغيل أخرى لمكونات أخرى. لذلك ، تبدو قابلية نقل الشفرة ، والأهم من ذلك ، تجربة استخدام أنظمة تشغيل مختلفة مغرية للغاية.
  2. يتمتع المستخدم بخبرة واسعة في استخدام واجهة برمجة التطبيقات لنظام تشغيل آخر. باستخدام هذه التجربة هو أيضا من المستحسن جدا.
  3. يريد المستخدم إعادة استخدام التعليمات البرمجية المكتوبة لواجهة برمجة التطبيقات لنظام تشغيل آخر. من الممكن تغيير مكالمات واجهة برمجة التطبيقات ، لكن تستهلك الكثير من الوقت.


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

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

تصحيح أخطاء تطبيقات Nucleus SE


تعد كتابة تطبيق مضمن باستخدام نواة تعدد المهام مهمة معقدة. قد يكون التأكد من عمل التعليمات البرمجية واكتشاف الأخطاء مهمة شاقة. على الرغم من أن هذا هو مجرد رمز يتم تشغيله على معالج ، إلا أن التنفيذ المتزامن لعدة مهام يجعل من الصعب التركيز على خيط تنفيذ معين. هذا الأمر معقد عندما تشترك عدة مهام في كود مشترك. الأسوأ من ذلك كله ، عندما يكون لمهمتين نفس الرمز بالضبط (لكن العمل مع بيانات مختلفة). ومما يزيد الأمر تعقيدًا أيضًا الكشف عن هياكل البيانات التي يتم استخدامها لتنفيذ كائنات kernel من أجل الاطلاع على معلومات مفيدة.

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

باستخدام مصحح أخطاء


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

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

نقاط التوقف الحساسة للمهمة


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

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

معلومات كائن Kernel


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

يمكن استخدام ذلك عن طريق إضافة كود تصحيح أخطاء إضافي إلى التطبيق الخاص بك ، والذي سيستخدم مكالمات API "المعلوماتية" (مثل NUSE_Queue_Information ). بالطبع ، هذا يعني أن التطبيق الخاص بك يحتوي الآن على رمز إضافي ، وهو ما لن يكون ضروريًا بعد تطبيق التطبيق. استخدام #define لتشغيل هذا الرمز وإيقاف تشغيله باستخدام الترجمة الشرطية سيكون قرارًا منطقيًا.

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

هناك طريقة بديلة أكثر مرونة ، ولكنها أقل "غير متقادمة" تتمثل في الوصول المباشر إلى هياكل البيانات الخاصة بالكائنات kernel. على الأرجح ، من الأفضل القيام بذلك باستخدام البرامج النصية المصحح. في مثالنا ، يمكن الحصول على حجم قائمة الانتظار من NUSE_Queue_Size [] ، واستخدامه الحالي من NUSE_Queue_Data [] . بالإضافة إلى ذلك ، يمكن عرض الرسائل في قائمة الانتظار باستخدام عنوان منطقة بيانات قائمة الانتظار (من NUSE_Queue_Data [] ).

قيم إرجاع استدعاء API


ترجع العديد من وظائف واجهة برمجة التطبيقات (API) قيمة حالة تشير إلى مدى نجاح المكالمة بنجاح. قد يكون من المفيد تتبع هذه القيم ووضع علامة على الحالات التي لا تساوي فيها NUSE_SUCCESS (أي ، لها قيمة صفر). نظرًا لأن هذا التتبع مخصص للتصحيح فقط ، فإن الترجمة الشرطية مناسبة تمامًا. يمكن تجميع تعريف المتغير العام (على سبيل المثال ، NUSE_API_Call_Status ) بشكل مشروط (تحت سيطرة رمز التوجيه #define). بعد ذلك ، يمكن أيضًا تجميع جزء من تعريف مكالمات API ، وهي NUSE_API_Call_Status = ، بشروط. على سبيل المثال ، لأغراض تصحيح الأخطاء ، فإن المكالمة التي عادة ما تبدو كما يلي:

NUSE_Mailbox_Send (mbox ، msg ، NUSE_SUSPSEND) ؛

سوف تتخذ الشكل التالي:

NUSE_API_Call_Status = NUSE_Mailbox_Send (mbox ، msg ، NUSE_SUSPEND) ؛

إذا تم تنشيط تأمين المهام ، فبإمكان العديد من استدعاءات وظائف واجهة برمجة التطبيقات (API) فقط إرجاع معلومات حول إكمال المكالمة بنجاح أو إعادة تعيين الكائن. ومع ذلك ، إذا تم تنشيط التحقق من معلمة API ، فستتمكن مكالمات API من إرجاع العديد من القيم الأخرى.

تحديد حجم مكدس المهمة وتجاوز مكدس الذاكرة المؤقتة


تمت مناقشة موضوع حماية تجاوز سعة المكدس في مقالة سابقة (# 31). هناك العديد من الاحتمالات الأخرى أثناء تصحيح الأخطاء.

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

كما هو موضح في المادة رقم 31، عند تنفيذ التشخيص ، يمكن أن توجد مناطق إضافية ، "كلمات وقائية" ، على أي من حواف منطقة الذاكرة المكدس. يمكن استخدام مصحح الأخطاء لتتبع الوصول إلى هذه الكلمات ، لأن أي محاولة للكتابة إليها تعني تجاوز سعة أو استنفاد المكدس.

قائمة التحقق من تكوين SE في Nucleus


منذ أن تم تصميم Nucleus SE كنظام مرن للغاية وقابل للتخصيص لتلبية متطلبات التطبيق ، فإنه يتطلب عددًا كبيرًا من المعلمات القابلة للتخصيص. هذا هو السبب في أن هذه المقالة بأكملها ، في الواقع ، مكرسة لتكوين Nucleus SE. للتأكد من عدم تفويت أي شيء ، فيما يلي قائمة مرجعية بجميع الخطوات الأساسية التي تحتاج إلى اتباعها لإنشاء تطبيق Nucleus SE المضمّن.
  1. Nucleus SE. , Nucleus SE , Nucleus SE .
  2. CPU/. .
  3. . , , .
  4. . . . , . 16 .
  5. . - main() ?
  6. . 4 , .
  7. , .
  8. .
  9. . , .
  10. . , .
  11. . , . . — 16 .
  12. . , .
  13. . , (, ).
  14. API. API, .


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

نبذة عن الكاتب: يعمل Colin Walls في صناعة الإلكترونيات لأكثر من ثلاثين عامًا ، حيث خصص معظم وقته للبرامج الثابتة. وهو الآن مهندس برامج ثابتة في Mentor Embedded (قسم من Mentor Graphics). يتحدث Colin Walls غالبًا في المؤتمرات والندوات ، ومؤلف العديد من المقالات الفنية وكتابين عن البرامج الثابتة. يعيش في المملكة المتحدة. مدونة كولن المهنية ، البريد الإلكتروني: colin_walls@mentor.com.

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


All Articles