الثعبان في الوقت الحقيقي نظام التشغيل (RTOS)

Question

وأنا على التخطيط لتنفيذ نطاق صغير نظام الحصول على البيانات على RTOS منصة.(إما على QNX أو RT-نظام لينكس.)

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

أو على الأقل التفاف التعليمات البرمجية C باستخدام بيثون لتوفير سهولة الوصول إلى النظام.

الطريقة التي تنصح مني أن أعمل ؟ سأكون سعيدا إذا كنت تشير بعض تصميم مماثل الحالات قراءات أخرى كذلك.

شكرا لك

NOTE1: سبب التأكيد على QNX هو بسبب أن لدينا بالفعل QNX 4.25 بناء نظام الحصول على البيانات (M300) لدينا الغلاف الجوي قياس التجارب.هذا هو نظام الملكية و لا يمكننا الوصول إلى الأجزاء الداخلية منها.تبحث زيادة على QNX قد يكون من المفيد لنا منذ 6.4 مجاني الترخيص الأكاديمي الخيار يأتي مع بايثون 2.5 و مؤخرا النسخة دول مجلس التعاون الخليجي.أنا لم تختبر RT-نظام لينكس, لا أعرف كيف للمقارنة إلى QNX من حيث الاستقرار والكفاءة ، ولكن أعلم أن جميع أعضاء الثعبان الموئل وغير الثعبان أدوات (مثل Google Earth) أن النظام الجديد يمكن أن تكون وضعت على يعمل معظم الوقت خارج منطقة الجزاء.

Answer 1

لا أستطيع أن أتكلم عن كل الحصول على البيانات الإعداد هناك ، ولكن معظم منهم يقضون معظم "في الوقت الحقيقي العمليات" في انتظار البيانات تأتي في-على الأقل تلك التي كنت قد عملت على.

ثم عندما البيانات لا تأتي في ، تحتاج إلى تسجيل الفور الحدث أو الرد عليه, ثم عاد إلى لعبة الانتظار.هذا هو عادة معظم الوقت جزء هام من نظام الحصول على البيانات.ولهذا السبب أود أن عموما أقول العصا مع C I/O أجزاء من الحصول على البيانات, ولكن لم تكن هناك أي مقنعة لا سيما أسباب عدم استخدام الثعبان في غير الوقت الحرج أجزاء.

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

إذا كنت بحاجة إلى التحديد المتعددالمهمة (ليس متعددةالموضوع), Stackless الثعبان قد تكون مفيدة أيضا.انها مثل متعدد خيوط, ولكن المواضيع (أو tasklets في Stackless لغة) لا على مستوى نظام التشغيل المواضيع, ولكن الثعبان/مستوى التطبيق ، لذلك النفقات العامة من التبديل بين tasklets هو بشكل كبير تخفيض.يمكنك تكوين Stackless إلى تعدد المهام بشكل تعاوني أو وقائيا.الجانب السلبي الأكبر هو أن حجب IO عموما منع مجموعة كاملة من tasklets.على أي حال, معتبرا أن QNX بالفعل في الوقت الحقيقي النظام ، فإنه من الصعب التكهن ما إذا كان Stackless سوف يكون من المفيد استخدام.

رأيي هو أن اتخاذ مثل-كثيرا-الثعبان-كما-طريق ممكن -- أرى أنها منخفضة التكلفة وعالية فائدة.إذا كنت بحاجة إلى إعادة كتابة C, سوف يكون لديك بالفعل العامل رمز لبدء من.

Answer 2

لقد بنيت عدة كل الثعبان لينة في الوقت الحقيقي (RT) نظم الابتدائي دورة مرات من 1 مللي ثانية إلى 1 ثانية.هناك بعض الاستراتيجيات والتكتيكات التي تعلمتها على طول الطريق:

1. استخدام خيوط/المعالجة المتعددة فقط افراغ غير RT العمل من ترابط الأساسي ، حيث طوابير بين المواضيع مقبولة التعاونية خيوط ممكن (لا استباقية المواضيع!).

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

3. استخدام C الوحدات عندما العملي.أشياء (عادة) بشكل أسرع مع C!ولكن أساسا إذا لم يكن لديك لكتابة الخاص بك:البقاء في بيثون ما لم يكن هناك حقا لا يوجد بديل.تحسين ج نمطية أداء بيتا ، خاصة عند ترجمة عبر بيثون C-واجهة يصبح أغلى جزء من التعليمات البرمجية.

4. استخدام بيثون مسرعات لتسريع التعليمات البرمجية الخاصة بك.أول RT الثعبان المشروع استفادت كثيرا من Psyco (نعم, أنا أعمل هذا الوقت).سبب واحد أنا باق مع بيثون 2.× اليوم هو PyPy:الأشياء دائما أسرع مع LLVM!

5. لا تخافوا مشغول انتظر متى التوقيت الحرج هو مطلوب.استخدام الوقت.النوم() إلى التسلل في الوقت المطلوب ، ثم مشغول انتظر خلال آخر 1-10 ms.لقد كنت قادرا على الحصول على أداء قابل للتكرار مع الذات توقيت بناء على أمر من 10 ميكروثانية.تأكد من الخاص بك الثعبان يتم تشغيل مهمة في max OS الأولوية.

6. Numpy الصخور!إذا كنت تفعل 'يعيش' تحليلات أو طن من الإحصاءات ، هناك لا طريقة الحصول على المزيد من العمل المنجز أسرع وأقل العمل (رمز أقل, أقل البق) من خلال استخدام Numpy.ليس في أي لغة أخرى ، بما في ذلك C/C++.إذا كانت غالبية الكود يتكون من Numpy المكالمات سوف تكون سريعة جدا.أنا لا يمكن أن تنتظر Numpy ميناء PyPy أن تكتمل!

7. تكون على علم كيف ومتى الثعبان لا جمع القمامة.مراقبة استخدام الذاكرة و قوة GC عند الحاجة.تأكد من تعطيل صراحة GC أثناء العمليات الحرجة.كل من بلدي RT الثعبان أنظمة تشغيل مستمر, و الثعبان يحب خنزير الذاكرة.الحرص على الترميز يمكن القضاء على ما يقرب من جميع ديناميكية تخصيص الذاكرة, في هذه الحالة يمكنك تعطيل تماما GC!

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

9. أنا لم أذكر استخدام PyPy?حسنا, الجدير بالذكر مرتين.

هناك العديد من المزايا الأخرى لاستخدام الثعبان على RT التنمية.على سبيل المثال, حتى لو كنت إلى حد ما اللغة الهدف الخاص بك لا يمكن أن يكون الثعبان, أنها يمكن أن تدفع فوائد ضخمة لتطوير وتصحيح النموذج في بيثون ، ثم استخدامها على حد سواء قالب واختبار أداة النظام النهائي.وقد تم استخدام بيثون لخلق نماذج سريعة من "الأجزاء الصلبة" نظام السنوات ، وخلق سريعة'n'dirty اختبار واجهات.هكذا أول RT الثعبان النظام إلى حيز الوجود:النموذج (+Psyco) كان سريع بما فيه الكفاية ، حتى مع اختبار واجهة المستخدم الرسومية على التوالي!

-BobC

تحرير:نسيت أن أذكر عبر منصة الفوائد:قانون بلدي يعمل في كل مكان تقريبا مع) أي إعادة تصنيف (أو المترجم تبعيات أو الحاجة عبر المجمعين) و ب) تقريبا لا تعتمد على منصة رمز (أساسا misc الاشياء مثل التعامل مع الملف و المسلسل I/O).أنا يمكن أن تتطور على Win7 x86 ونشر على لينكس-ذراع (أو أي الأخرى POSIX OS, كل منها الثعبان في هذه الأيام).PyPy هو في المقام الأول إلى x86 الآن ولكن الذراع المنفذ يتطور بوتيرة لا تصدق.

Answer 3

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

Answer 4

لدينا فريق عمل الجمع بين عدة لغات على QNX و كان الكثير من النجاح مع هذا النهج.باستخدام بيثون يمكن أن يكون لها تأثير كبير على الإنتاجية والأدوات مثل جرعة كبيرة و ctypes تجعل من السهل حقا لتحسين رمز الجمع بين ميزات من لغات مختلفة.

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

كما الثعبان على QNX لا يميل إلى 100 ٪ متوافق مع التوزيعات الأخرى (أي/ في بعض الأحيان هناك وحدات في عداد المفقودين).

Answer 5

ملاحظة هامة:بيثون على QNX عموما هو متاح فقط ل x86.

أنا متأكد من أنك يمكن ترجمة ذلك على قدرة شرائية وغيرها archs لكن ذلك لن ينجح في الخروج من مربع.