मेरा मतलब है कि कैसे और क्यों रीयलटाइम ओएस कभी भी उन्हें याद किए बिना समय सीमा को पूरा करने में सक्षम हैं? या यह सिर्फ एक मिथक है (कि वे समय सीमा याद नहीं करते हैं)? वे किसी भी नियमित ओएस से अलग कैसे हैं और नियमित ओएस को आरटीओएस होने से रोकता है?रीयल टाइम ऑपरेटिंग सिस्टम कैसे काम करते हैं?
बैठक की समयसीमा आपके द्वारा लिखे गए एप्लिकेशन का एक कार्य है। आरटीओएस बस ऐसी सुविधाएं प्रदान करता है जो समय सीमा को पूरा करने में आपकी सहायता करते हैं। आप एक बड़े मुख्य पाश में "नंगे धातु" (डब्ल्यू/ओ आरटीओएस) पर भी प्रोग्राम कर सकते हैं और आपको समय सीमाएं मिल सकते हैं।
यह भी ध्यान रखें कि एक अधिक सामान्य उद्देश्य ओएस के विपरीत, एक आरटीओएस में कार्यों और प्रक्रियाओं का एक बहुत ही सीमित सेट होता है।
सुविधाओं का RTOS प्रदान से कुछ:
प्राथमिकता के आधार पर समयबद्धक
अधिकांश आरटीओएस के बीच है व्यक्तिगत कार्यों/प्रक्रियाओं के लिए 32 और 256 संभावित प्राथमिकताओं। शेड्यूलर कार्य को सर्वोच्च प्राथमिकता के साथ चलाएगा। एक चल रहा कार्य सीपीयू देता है, अगले सर्वोच्च प्राथमिकता कार्य चलाता है, और इतने पर ...
प्रणाली में सर्वोच्च प्राथमिकता कार्य सीपीयू तक होगा:
डेवलपर के रूप में, कार्य की प्राथमिकताओं को असाइन करना आपका काम है जैसे कि आपकी समयसीमा पूरी की जाएगी।
सिस्टम घड़ी बाधा routines
RTOS आम तौर पर सिस्टम घड़ी (100ms के लिए 500 हम से कहीं भी) है कि आप समय के प्रति संवेदनशील कार्रवाई करने की अनुमति देता है किसी प्रकार का प्रदान करेगा। यदि आपके पास 1 एमएमएस सिस्टम घड़ी है, और आपको हर 50ms में एक कार्य करने की आवश्यकता है, तो आमतौर पर एक एपीआई है जो आपको "50ms में, मुझे जगाएं" कहने की अनुमति देती है। उस बिंदु पर, जब तक आरटीओएस इसे जगाता है तब तक कार्य सो जाएगा।
ध्यान दें कि केवल जागने के लिए बीमा नहीं है कि आप उस समय बिल्कुल ठीक चलेंगे। यह प्राथमिकता पर निर्भर करता है। यदि उच्च प्राथमिकता वाले कार्य वर्तमान में चल रहे हैं, तो आप देरी हो सकती हैं।
नियतात्मक व्यवहार
RTOS सुनिश्चित करें कि आप 10 कार्य, या 100 कार्य है या नहीं, यह किसी भी अब नहीं ले करता है, संदर्भ स्विच निर्धारित आगे क्या सर्वोच्च प्राथमिकता काम है करने के लिए महान लंबाई करने के लिए चला जाता है, आदि ...
सामान्य रूप से, आरटीओएस ऑपरेशन ओ (1) होने का प्रयास करता है।
आरटीओएस में निर्धारक व्यवहार के लिए प्रमुख क्षेत्रों में से एक अंतःस्थापित हैंडलिंग है। जब एक इंटरप्ट लाइन को संकेत दिया जाता है, तो आरटीओएस तुरंत सही इंटरप्ट सेवा रूटीन पर स्विच करता है और बिना किसी देरी के बाधा को नियंत्रित करता है (वर्तमान में चल रहे किसी भी कार्य की प्राथमिकता के बावजूद)।
ध्यान दें कि अधिकांश हार्डवेयर-विशिष्ट आईएसआर परियोजना पर डेवलपर्स द्वारा लिखे जाएंगे। आरटीओएस पहले से ही धारावाहिक बंदरगाहों, सिस्टम घड़ी, शायद नेटवर्किंग हार्डवेयर के लिए आईएसआर प्रदान कर सकता है लेकिन कुछ विशेष (पेसमेकर संकेत, actuators, आदि ...) आरटीओएस का हिस्सा नहीं होगा।
यह एक सकल सामान्यीकरण है और जैसा कि बाकी सब कुछ है, वहां आरटीओएस कार्यान्वयन की एक बड़ी विविधता है। कुछ आरटीओएस चीजें अलग-अलग करते हैं, लेकिन ऊपर दिया गया विवरण मौजूदा आरटीओएस के बड़े हिस्से पर लागू होना चाहिए।
"यह कार्य पूरा होने के लिए चला जाएगा" विंडोज 3.1 की तरह लगता है! तो आप का मतलब है कि आरटीओएस गैर प्रीपेप्टिव हैं? –
नहीं, यदि आप स्वेच्छा से हारने तक उच्चतम प्राथमिकता रखते हैं, या आप तैयार होने की तुलना में उच्च प्राथमिकता कार्य करते हैं, तो उस समय (पुरानी) उच्च प्राथमिकता पूर्व-खाली हो जाती है। मैं मुख्य पाठ में स्पष्टीकरण दूंगा। धन्यवाद! – Benoit
ऐसा नहीं है कि वे समय सीमा को पूरा करने में सक्षम हैं, बल्कि यह है कि उनके पास समय सीमा तय है जबकि नियमित ओएस में ऐसी कोई समयसीमा नहीं है।
नियमित ओएस में कार्य शेड्यूलर वास्तव में सख्त नहीं है। प्रोसेसर प्रति सेकंड इतने सारे निर्देश निष्पादित करेगा, लेकिन कभी-कभी ऐसा नहीं हो सकता है। उदाहरण के लिए एक कार्य पूर्व-खाली हो सकता है ताकि उच्च प्राथमिकता को निष्पादित करने की अनुमति दी जा सके (और लंबे समय तक हो सकता है)। आरटीओएस में प्रोसेसर हमेशा कार्यों की संख्या को निष्पादित करेगा।
इसके अतिरिक्त आमतौर पर कार्यों को पूरा करने के लिए समय सीमा होती है जिसके बाद विफलता की सूचना दी जाती है। यह नियमित ओएस में नहीं होता है।
स्पष्ट रूप से व्याख्या करने के लिए बहुत अधिक जानकारी है, लेकिन उपरोक्त दो महत्वपूर्ण डिजाइन पहलुओं का उपयोग आरटीओएस में किया जाता है।
असल में, आपको आरटीओएस में प्रत्येक "कार्य" को कोड करना होगा जैसे कि वे एक सीमित समय में समाप्त हो जाएंगे।
इसके अतिरिक्त आपका कर्नेल प्रत्येक कार्य को विशिष्ट समय आवंटित करेगा, यह गारंटी देने के प्रयास में कि कुछ चीजें निश्चित समय पर होती हैं।
ध्यान दें कि यह करना एक आसान काम नहीं है। आभासी फ़ंक्शन कॉल जैसी चीजों की कल्पना करो, ओओ में इन चीजों को निर्धारित करना बहुत मुश्किल है। प्राथमिकता के संबंध में एक आरटीओएस सावधानी से कोड किया जाना चाहिए, इसके लिए यह आवश्यक हो सकता है कि उच्च प्राथमिकता कार्य को सीपीयू को x मिलीसेकंड के भीतर दिया जाए, जो आपके शेड्यूलर के काम के आधार पर करना मुश्किल हो सकता है।
"असल में, आपको आरटीओएस में प्रत्येक" कार्य "को कोड करना होगा जैसे कि वे एक सीमित समय में समाप्त हो जाएंगे" - फिर उसका एप्लिकेशन जिसे रीयलटाइम कहा जाना चाहिए और ओएस नहीं। –
जब कोई कार्य समय समाप्त हो जाता है तो क्या होता है? –
कार्य को जबरन पूर्ववत किया गया है और अगली बार स्लाइस पर पुनरारंभ किया गया है। एक अच्छा आरटीओएस एक त्रुटि उठाएगा या सूचित करेगा कि यह हुआ था। – Spence
रीयलटाइम ओएस नहीं, रीयलटाइम एप्लिकेशन महत्वपूर्ण है। आम तौर पर रीयलटाइम अनुप्रयोग अनुमानित होते हैं: कई परीक्षण, निरीक्षण, डब्ल्यूसीईटी विश्लेषण, सबूत, ... प्रदर्शन किए गए हैं जो दिखाते हैं कि किसी निर्दिष्ट परिस्थितियों में समय सीमाएं पूरी की जाती हैं।
ऐसा होता है कि आरटीओएस इस काम को करने में मदद करते हैं (आवेदन बनाते हैं और इसकी आरटी बाधाओं को सत्यापित करते हैं)। लेकिन मैंने ओएस डिज़ाइन की तुलना में हार्डवेयर हॉर्स पावर पर अधिक निर्भर करते हुए, मानक लिनक्स पर चलने वाले रीयलटाइम एप्लिकेशन देखे हैं।
एक आरटीओएस महत्वपूर्ण चीजों पर बहुत सख्त गारंटी देता है, जैसे कि सर्विसिंग समय में बाधा, कार्य स्विचिंग विलंबता आदि, वास्तविक आरटीओएस के बिना रीयल-टाइम एप्लिकेशन संभव नहीं हैं। –
मैं बस जो मैंने देखा है उसके बारे में बात कर रहा हूं। और अक्सर से अधिक, रीयलटाइम समस्याओं को बड़ी सीपीयू आवृत्तियों और बहुत समय मार्जिन द्वारा हल किया जाता है। – mouviciel
मैंने आरटीओएस का उपयोग नहीं किया है, लेकिन मुझे लगता है कि यह इस तरह काम करता है।
"हार्ड रीयल टाइम" और "सॉफ्ट रीयल टाइम" के बीच एक अंतर है। आप Windows की तरह एक गैर RTOS पर वास्तविक समय एप्लिकेशन लिख सकते हैं, लेकिन वे 'नरम' वास्तविक समय कर रहे हैं:
एक आवेदन के रूप में, मैं एक धागा या टाइमर जो मैं हे पूछना हो सकता है/एस प्रति सेकंड 10 बार चलाने के लिए ... और शायद ओ/एस ऐसा करेगा, ज्यादातर समय, लेकिन इस बात की कोई गारंटी नहीं है कि यह हमेशा सक्षम रहेगा ... गारंटी की कमी यह है कि इसे 'मुलायम' कहा जाता है । ओ/एस ऐसा करने में सक्षम क्यों नहीं हो सकता है कि एक अलग थ्रेड सिस्टम को कुछ और करने में व्यस्त रख सकता है। एक आवेदन के रूप में, मैं HIGH_PRIORITY_CLASS उदाहरण के लिए अपनी थ्रेड प्राथमिकता को बढ़ा सकता हूं, लेकिन अगर मैं ऐसा करता हूं तो ओ/एस में अभी भी कोई एपीआई नहीं है जिसका उपयोग मैं की गारंटी के लिए कर सकता हूं कि मैं निश्चित समय पर चलाउंगा।
ए 'हार्ड' रीयल-टाइम ओ/एस करता है (मुझे कल्पना है) में एपीआई हैं जो मुझे गारंटीकृत निष्पादन स्लाइस का अनुरोध करने देती हैं। आरटीओएस ऐसी गारंटी क्यों दे सकता है कि वह थ्रेड को रोकना चाहता है जो अपेक्षाकृत अपेक्षाकृत अधिक समय लेता है।
यह केवल शेड्यूलिंग नहीं है - ओएस को यह सुनिश्चित करना होगा कि कोई यादृच्छिक चीजें कचरा संग्रह या मेमोरी एड्रेस स्पेस डीफ्रैग्मेंटेशन जैसी नहीं लगती हैं, ताकि आप जान सकें कि malloc() हमेशा देरी के बिना वापस आ जाएगा, इसलिए (उदाहरण के लिए) हवाई जहाज ऑटोपिलोट नियंत्रण कर रहा है दुर्घटनाग्रस्त नहीं होगा। –
और संभावित रूप से हार्डवेयर इंटरप्ट भी। – ChrisW
आपका RTOS इस तरह से है कि यह महत्वपूर्ण घटनाओं के लिए समय गारंटी ले सकते हैं, हार्डवेयर बाधा से निपटने और वास्तव में सो रही प्रक्रियाओं जागने जब वे होने की जरूरत है की तरह में बनाया गया है।
यह सटीक समय प्रोग्रामर को यह सुनिश्चित करने की इजाजत देता है कि उसका (कहता है) पेसमेकर एक पल्स आउटपुट करने जा रहा है, जब इसे कुछ मिलियनकंड बाद में नहीं किया गया क्योंकि ओएस एक अन्य अक्षम कार्य के साथ व्यस्त था।
यह आमतौर पर पूरी तरह से लिनक्स या विंडोज की तुलना में एक बहुत ही सरल ओएस है, क्योंकि सरल कोड के व्यवहार का विश्लेषण और भविष्यवाणी करना आसान है। आरटीओएस पर्यावरण में लिनक्स का इस्तेमाल पूरी तरह से ओएस को रोकने के लिए कुछ भी नहीं है, और इसमें आरटीओएस एक्सटेंशन हैं। कोड बेस की जटिलता के कारण यह अपने समय को छोटे ओएस के रूप में छोटे पैमाने पर गारंटी देने में सक्षम नहीं होगा।
आरटीओएस शेड्यूलर सामान्य उद्देश्य शेड्यूलर से भी अधिक सख्त है। यह जानना महत्वपूर्ण है कि शेड्यूलर आपकी कार्य प्राथमिकता को बदलने वाला नहीं है क्योंकि आप लंबे समय से चल रहे हैं और आपके पास कोई इंटरैक्टिव उपयोगकर्ता नहीं है। अधिकांश ओएस शॉर्ट-टर्म इंटरैक्टिव प्रोग्राम्स के पक्ष में इस प्रकार की प्रक्रिया की प्राथमिकता को आंतरिक रूप से कम कर देगा जहां इंटरफेस को अंतराल में नहीं देखा जाना चाहिए।
आपको एक सामान्य आरटीओएस के स्रोत को पढ़ने में मदद मिल सकती है। वहाँ कई खुला स्रोत उदाहरण सारे हैं, और त्वरित खोज का एक छोटा सा में निम्नलिखित झुकेंगे लिंक:
एक वाणिज्यिक RTOS है कि अच्छी तरह से प्रलेखित है, में उपलब्ध स्रोत कोड फॉर्म, और µC/OS-II के साथ काम करने में आसान है। इसका शैक्षिक उपयोग के लिए एक बहुत ही अनुमोदित लाइसेंस है, और (इसके हल्के ढंग से पुराने संस्करण) के स्रोत को वास्तविक कार्यान्वयन का उपयोग करके ऑपरेशन के सिद्धांत का वर्णन करने वाली पुस्तक में बाध्य किया जा सकता है उदाहरण कोड के रूप में। जीन लैब्रोसे द्वारा पुस्तक MicroC OS II: The Real Time Kernel है।
मैंने वर्षों से कई परियोजनाओं में μC/OS-II का उपयोग किया है, और इसकी अनुशंसा कर सकते हैं।
... अच्छी तरह से ...
एक रीयल-टाइम ऑपरेटिंग सिस्टम नियतात्मक हो सकता है और समय सीमा को पूरा करने के प्रयास करता है, लेकिन यह सब जिस तरह से आप अपने आवेदन लिखने पर निर्भर करता है। यदि आप "उचित" कोड लिखना नहीं चाहते हैं तो आप एक आरटीओएस बहुत गैर-वास्तविक समय बना सकते हैं।
भले ही आप उचित कोड लिखने के बारे में जानते हों: यह तेजी से होने से निर्धारक होने की कोशिश करने के बारे में अधिक है।
जब हम नियतिवाद के बारे में बात यह
1) घटना नियतिवाद
अगले राज्यों और एक प्रणाली के आउटपुट
2 में जाना जाता है आदानों के प्रत्येक सेट के लिए) अस्थायी नियतिवाद
है ... आउटपुट के प्रत्येक सेट के लिए प्रतिक्रिया समय भी
इसका मतलब है कि यदि आपके जैसे असीमित घटनाएं हैं I nterrupts आपके सिस्टम सख्ती से अस्थायी निर्धारणा नहीं बोल रहा है। (और अधिकांश सिस्टम इंटरप्ट्स का उपयोग करते हैं)
यदि आप वाकई निश्चित रूप से सब कुछ निर्धारित करना चाहते हैं।
... लेकिन शायद यह 100% नियतात्मक
"यदि आप वास्तव में निर्धारिती चुनाव सब कुछ बनना चाहते हैं।" - क्या होगा यदि आप सर्वेक्षण चक्रों के बीच उच्च प्राथमिकता की घटना को याद करते हैं? क्या यह ओएस प्रतिक्रिया उन घटनाओं के लिए वास्तविक समय नहीं बनायेगा? –
बेशक यह होगा, लेकिन आपने अपना विश्लेषण किया और सुनिश्चित किया कि ओएस के बाहर से सभी घटनाएं कुछ समय सीमाओं (आपके इनपुट के लिए स्पोरैडिक सर्वर की तरह) के भीतर आती हैं। एक गलती की स्थिति में (क्रैक केबल) आपको किसी भी तरह से घटनाओं को फेंक देना चाहिए। मतदान करके और आप किसी भी इंटरप्ट का उपयोग न करके सुनिश्चित करते हैं कि तथ्य यह है कि आप अंतःक्रिया का उपयोग करते हैं, यह अब निर्धारकता को कम नहीं कर रहा है। –
क्या आप यह कहने की कोशिश कर रहे हैं कि यह विलंबता और निर्धारणा के बीच प्रभावी रूप से एक व्यापार बंद है? आईएमओ "अच्छी तरह परिभाषित सीमाओं पर घटनाओं" मॉडल विफल रहता है जब आपके पास कोई ईवेंट पदानुक्रम होता है (यानी प्राथमिकता वाले ईवेंट)। ऐसा कोई कारण नहीं है कि पूरी तरह से असंबंधित घटना को कम प्राथमिकता (एलपी) घटना/कार्य की समय सीमाओं का सम्मान करना चाहिए। एचपी घटना टी 0 + डीटी पर होने पर भी एलपी कार्य को छूट दी जानी चाहिए। जहां डीटी एक infinitesimally छोटी अवधि है और टी 0 वह समय है जब एलपी कार्य शुरू हुआ। –
पाठ्यपुस्तक/साक्षात्कार जवाब होने के लिए आवश्यक नहीं है "नियतात्मक शुफ़ा" है। सिस्टम को समय की सीमा के भीतर नियंत्रण स्थानांतरित करने की गारंटी दी जाती है यदि उच्च प्राथमिकता प्रक्रिया चलाने के लिए तैयार है (तैयार कतार में) या एक बाधा डाली जाती है (आमतौर पर सीपीयू/एमसीयू के लिए बाहरी इनपुट)।
वे वास्तव में मीटिंग की समय सीमा की गारंटी नहीं देते हैं; वे क्या करते हैं जो उन्हें सचमुच आरटीओएस बनाता है, समय सीमा ओवररन्स को पहचानने और निपटने के साधन प्रदान करना है। 'हार्ड' आरटी सिस्टम आम तौर पर वे हैं जहां एक समयसीमा गुम हो जाती है और कुछ प्रकार की शटडाउन की आवश्यकता होती है, जबकि 'सॉफ्ट' आरटी सिस्टम एक ऐसा होता है जहां अपर्याप्त कार्यक्षमता जारी रहती है। किसी भी तरह से एक आरटीओएस आपको इस तरह के ओवररन्स के जवाब को परिभाषित करने की अनुमति देता है। गैर आरटी ओएस का ओवररन्स भी नहीं पता है।
"मूल रूप से, आपको आरटीओएस में प्रत्येक" कार्य "को कोड करना होगा जैसे कि वे एक सीमित समय में समाप्त हो जाएंगे।"
यह वास्तव में सही है। आरटीओएस में आर्किटेक्चर द्वारा परिभाषित एक सिस्टम टिक होगा, 10 मिलीसेक कहें। सभी कार्यों (धागे) के साथ विशिष्ट समय के भीतर पूरा करने के लिए डिज़ाइन और मापा गया है। उदाहरण के लिए वास्तविक समय ऑडियो डेटा को प्रोसेस करने में, जहां ऑडियो नमूना दर 48kHz है, वहां ज्ञात समय (मिलीसेकंड में) है जिस पर प्रीबफर किसी भी डाउनस्ट्रीम कार्य के लिए खाली हो जाएगा जो डेटा को संसाधित कर रहा है। इसलिए आरटीओएस का उपयोग करके बफर के सही आकार की आवश्यकता होती है, अनुमान लगाया जाता है और मापता है कि यह कितना समय लगता है, और सिस्टम में सभी सॉफ़्टवेयर परतों के बीच विलंबता को मापने की आवश्यकता है। फिर समय सीमा पूरी हो सकती है। अन्यथा आवेदन समय सीमा याद करेंगे। इसके लिए पूरे स्टैक में सबसे बुरी स्थिति डेटा प्रोसेसिंग के विश्लेषण की आवश्यकता होती है, और एक बार सबसे खराब स्थिति ज्ञात होने के बाद, सिस्टम को 5% निष्क्रिय समय के साथ 95% प्रोसेसिंग समय के लिए डिज़ाइन किया जा सकता है (यह प्रसंस्करण कभी भी नहीं हो सकता है कोई वास्तविक उपयोग, क्योंकि समय-समय पर किसी भी पल में सभी परतों के भीतर सबसे खराब केस डेटा प्रोसेसिंग एक स्वीकृत स्थिति नहीं हो सकती है)।
उदाहरण समय एक वास्तविक समय ऑपरेटिंग सिस्टम नेटवर्क एप्लिकेशन के डिजाइन के लिए आरेख, EE टाइम्स में इस लेख में कर रहे हैं उत्पाद कैसे-करें: एक वीओआईपी आधारित टेलीफोनी डिजाइन में वास्तविक समय आवाज की गुणवत्ता को सुधारना http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
आरटीओएस में सबसे महत्वपूर्ण पैरामीटर जिन्हें देखभाल की जानी चाहिए, कम लेटेंसी और समय निर्धारण है। कुछ नीतियों और चालों का पालन करके यह सुखद रूप से करता है।
जबकि जीपीओएस में स्वीकार्य विलंबता के साथ महत्वपूर्ण पैरामीटर उच्च थ्रूपुट है। आप समय निर्धारण के लिए जीपीओएस पर भरोसा नहीं कर सकते हैं।
आरटीओएस में ऐसे कार्य होते हैं जो जीपीओएस में प्रक्रियाओं/धागे से अधिक हल्के होते हैं।
मुलायम 'वास्तविक समय प्रणाली और' हार्ड 'वास्तविक समय प्रणाली के बीच अंतर को ध्यान में रखना भी महत्वपूर्ण है। – Thomas