RTOS के बारे में पूरी सच्चाई। अनुच्छेद # 6 अन्य RTOS सेवाएं

पिछले लेखों में, हमने प्रदर्शन किए गए कार्यों और उनके बीच की बातचीत के संदर्भ में कर्नेल की कार्यक्षमता पर चर्चा की। इस लेख में, हम देखते हैं कि कर्नेल और क्या कर सकता है, जो काफी हद तक अन्य उपलब्ध एपीआई कॉलों में प्रकट होता है। हम इस सवाल का भी जवाब देंगे कि क्या कर्नेल ऑपरेटिंग सिस्टम में बदल जाता है?

श्रृंखला में पिछले लेख:
अनुच्छेद # ५ कार्य सहभागिता और सिंक्रनाइज़ेशन
अनुच्छेद # 4 कार्य, संदर्भ स्विचिंग, और व्यवधान
अनुच्छेद # ३ कार्य और योजना
अनुच्छेद # 2 आरटीओएस: संरचना और वास्तविक समय मोड
अनुच्छेद # 1। आरटीओएस: परिचय।

कार्य प्रबंधन

कार्य शेड्यूलिंग और उनके बीच बातचीत के अलावा, RTOS में विभिन्न तरीकों से कार्यों के प्रबंधन के लिए कार्यक्षमता (एपीआई कॉल) शामिल होगी। आइए कुछ संभावनाओं पर विचार करें।

कार्य बनाएं और हटाएं

"डायनेमिक" RTOS में फ़ंक्शन कॉल होते हैं जो आपको आवश्यक होने पर कार्य (और अन्य RTOS ऑब्जेक्ट) बनाने की अनुमति देते हैं। ऐसी कॉल में कई प्रकार के पैरामीटर शामिल होते हैं जो कार्य को परिभाषित करते हैं, उदाहरण के लिए, प्रवेश बिंदु, स्टैक आकार और प्राथमिकता। इसी कार्य को हटाने वाली एपीआई कॉल आपको कार्य पूरा होने के बाद संसाधनों को मुक्त करने की अनुमति देती है।

"स्थैतिक" RTOS में, कार्य के परिभाषित मापदंडों को विधानसभा के दौरान एक तरह की कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर किया गया है।

किसी कार्य को रोकें और फिर से शुरू करें

जैसा कि हमने देखा, अधिकांश RTOS में कार्यों की "निलंबित" स्थिति की अवधारणा है। यह विभिन्न तरीकों से हासिल किया जा सकता है। उनमें से एक सस्पेंड टास्क एपीआई फ़ंक्शन के लिए एक स्पष्ट कॉल है। यह स्वयं या किसी अन्य कार्य के कारण हो सकता है। संबंधित "पुनरारंभ कार्य" कॉल योजना के लिए कार्य को फिर से पंक्तिबद्ध करने की अनुमति देता है।

नींद की अवस्था

एक वास्तविक समय प्रणाली के लिए, समय नियंत्रण एक महत्वपूर्ण आवश्यकता है और विभिन्न रूप ले सकता है। एक साधारण दृश्य "सो जाने" के लिए कार्य की क्षमता है, अर्थात, कार्य को एक निश्चित अवधि के लिए निलंबित कर दिया जाता है। जब समय समाप्त होता है, तो कार्य "उठता है" और फिर से योजना के लिए कतारबद्ध होता है। इस उद्देश्य के लिए एक एपीआई कॉल आमतौर पर उपलब्ध होगी। बेशक, यह कार्यक्षमता टाइमर की उपलब्धता पर निर्भर करती है।

रिहाई

राउंड रॉबिन शेड्यूलर ("हिंडोला") का उपयोग करते समय, एक कार्य श्रृंखला में अगले कार्य के लिए प्रोसेसर को नियंत्रित करने से मना कर सकता है। ऐसा करने के लिए, "रिलीज़ कार्य" एपीआई फ़ंक्शन उपलब्ध होगा। कार्य निलंबित नहीं है, यह अपनी बारी आने पर नियोजन के लिए उपलब्ध होगा। टाइम स्लाइस शेड्यूलर का उपयोग करते समय, यह संभव है कि कोई कार्य अपने समय अंतराल के हिस्से को मुक्त कर सकता है यदि उसके पास तुरंत काम करने के लिए महत्वपूर्ण कार्य नहीं है। रन पूरा करने या प्राथमिकता शेड्यूलरों को चलाने के दौरान किसी कार्य को जारी करने का कोई तार्किक अर्थ नहीं है।

कार्य पूर्ण होना

पिछले लेख में, हमने पाया कि "रेडी" या "सस्पेंडेड" राज्यों के अलावा, RTOS अन्य कार्य राज्यों का समर्थन कर सकता है। कार्य "समाप्त" हो सकता है, जिसका अर्थ है कि इसका मुख्य कार्य बस छोड़ दिया गया: कोई विशेष एपीआई कॉल की आवश्यकता नहीं है। एक कार्य "समाप्त" हो सकता है, जिसका अर्थ है कि यह योजना के लिए उपलब्ध नहीं है और इसे फिर से लॉन्च करने के लिए उपलब्ध होने के लिए रीसेट किया जाना चाहिए, नीचे "कार्य रीसेट करना" देखें। इसके लिए एक विशेष एपीआई कॉल की आवश्यकता होती है। इन अतिरिक्त कार्य की उपलब्धता, उपयोग की गई शब्दावली और उनकी सटीक परिभाषा आरटीओएस के आधार पर अलग-अलग होगी।

कार्य रीसेट करें

कई RTOS “रीसेट टास्क” एपीआई फ़ंक्शन के लिए एक कॉल प्रदान करते हैं, जो आपको कार्य को उसकी मूल स्थिति में वापस करने की अनुमति देता है। वह एक निलंबित स्थिति में हो सकता है और योजना के लिए कतार लगाने के लिए फ़ंक्शन "पुनरारंभ कार्य" को निष्पादित करने की आवश्यकता होती है।

प्राथमिकता कार्य, आदि।

"डायनामिक" RTOS में, रन समय में कई कार्य मापदंडों को कॉन्फ़िगर करने के लिए एपीआई कॉल उपलब्ध हो सकती है। उदाहरणों में प्राथमिकता और समय अंतराल की अवधि शामिल है।

सिस्टम जानकारी

RTOS में, कार्य के बारे में जानकारी के साथ सिस्टम प्रदान करने के लिए कई API कॉल होंगे, जिनमें शामिल हैं:
कार्यों के बारे में जानकारी । सिस्टम में कितने कार्य हैं, उनका विन्यास और वर्तमान स्थिति।
अन्य कर्नेल ऑब्जेक्ट के बारे में जानकारी। प्रत्येक प्रकार की कितनी वस्तुएं सिस्टम में हैं, उनका कॉन्फ़िगरेशन और वर्तमान स्थिति के बारे में जानकारी। उदाहरण के लिए:

• कतार की वर्तमान क्षमता क्या है? क्या मैं और संदेश जोड़ सकता हूं?
• किसी विशेष मेलबॉक्स पर कितने कार्य निलंबित हैं?

RTOS संस्करण के बारे में जानकारी । एक एपीआई कॉल समान डेटा प्रदान कर सकता है।

मेमोरी आवंटन

कई अनुप्रयोगों में, यह महत्वपूर्ण है कि प्रोग्राम गतिशील रूप से कुछ मेमोरी को आवश्यकता होने पर कैप्चर कर सकता है, और इसे तब फ्री कर सकता है जब इसकी आवश्यकता नहीं होती है। फर्मवेयर में भी यही बात होती है। हालांकि, पारंपरिक दृष्टिकोण उन समस्याओं से ग्रस्त हैं जो डेस्कटॉप अनुप्रयोगों में संभावना या असुविधाजनक हैं, लेकिन वे एक एम्बेडेड सिस्टम के लिए विनाशकारी हो सकते हैं। फिर भी, ऐसी सेवाओं को लागू करने के तरीके हैं, यहां तक ​​कि एक स्थिर आरटीओएस में भी।

मॉलॉक () और मुफ्त () कार्यों के साथ समस्याएं

डेस्कटॉप सी प्रोग्राम में, एक फ़ंक्शन मॉलोक () को कॉल कर सकता है, यह दर्शाता है कि मेमोरी कितनी आवश्यक है, और स्टोरेज क्षेत्र के लिए एक पॉइंटर वापस प्राप्त करें। मेमोरी का उपयोग करके, इसे मुफ्त () कॉल करके मुक्त किया जा सकता है। मेमोरी को ढेर नामक क्षेत्र से आवंटित किया जाता है। इस दृष्टिकोण के साथ समस्या यह है कि इन कार्यों के लिए एक अनजाने अनुक्रम के साथ, ढेर क्षेत्र आसानी से खंडित हो सकता है, और फिर मेमोरी आवंटन विफल हो जाएगा, भले ही पर्याप्त मेमोरी उपलब्ध हो, क्योंकि आस-पास के क्षेत्र पर्याप्त बड़े नहीं हैं। कुछ सिस्टम (जैसे जावा और विज़ुअल बेसिक) डीफ़्रैग्मेन्ट करने के लिए परिष्कृत "कचरा संग्रह" योजनाओं का उपयोग करते हैं। समस्या यह है कि इन योजनाओं से रनटाइम में महत्वपूर्ण अप्रत्याशित देरी हो सकती है और अप्रत्यक्ष पॉइंटर्स (जो सी में काम नहीं करता है) का उपयोग करने की आवश्यकता होती है।

यदि मॉलोक () और नि: शुल्क () को आरईएनटीआर कार्यों द्वारा एक रीएन्ट्रेंट तरीके (आमतौर पर नहीं) और कार्यान्वित किया जाता है, तो विखंडन बहुत जल्दी होगा, और सिस्टम विफलता लगभग अपरिहार्य हो जाएगी। C ++ में, नए और डिलीट ऑपरेटर्स हैं जो आम तौर पर मॉलोक () और फ्री () के समान कार्य करते हैं। वे समान सीमाओं और समस्याओं के अधीन हैं।

स्मृति के खंड

गतिशील रूप से सुलभ मेमोरी के साथ एक वास्तविक समय प्रणाली प्रदान करने के लिए, स्मृति प्रबंधन के लिए एक ब्लॉक दृष्टिकोण का उपयोग किया जा सकता है। ऐसे ब्लॉकों को आमतौर पर "विभाजन" कहा जाता है; विभाजन "विभाजन पूल" से आवंटित किया जा सकता है।

विभाजन पूल में कुछ निश्चित ब्लॉक होते हैं, जिनमें से प्रत्येक का आकार समान होता है। एक विभाजन में ब्लॉकों की संख्या और आकार तब निर्धारित किया जाता है जब विभाजन पूल बनाया जाता है। यह गतिशील हो सकता है यदि सिस्टम स्वयं इसे अनुमति देता है, या विधानसभा के दौरान सांख्यिकीय रूप से। आमतौर पर, एक एप्लिकेशन में कई विभाजन पूल शामिल हो सकते हैं जो विभिन्न आकारों के ब्लॉक प्रदान करते हैं।

यदि किसी कार्य को मेमोरी की आवश्यकता है, तो यह एक एपीआई को कॉल करता है जो एक विशिष्ट पूल से ब्लॉक का अनुरोध करता है। यदि यह कॉल सफल होता है, तो कार्य चयनित ब्लॉक को एक पॉइंटर प्राप्त करेगा। यदि कॉल विफल रहता है क्योंकि संकेतित पूल में उपलब्ध विभाजन नहीं हैं, कार्य में त्रुटि प्रतिक्रिया प्राप्त हो सकती है। वैकल्पिक रूप से, कार्य को तब तक अवरुद्ध (निलंबित) किया जा सकता है जब तक कि कोई अन्य कार्य खंड में खंड को जारी नहीं करता है।

आमतौर पर, एक कार्य केवल एक पॉइंटर को किसी भी कोड में मेमोरी के एक ब्लॉक में भेजता है जो ब्लॉक का उपयोग करता है। इससे एक समस्या आती है जब ब्लॉक की आवश्यकता नहीं होती है। यदि कोड में केवल एक ब्लॉक करने के लिए एक पॉइंटर है, तो यह एपीआई कॉल के माध्यम से आरटीओएस को कैसे बता सकता है, जिसमें से विभाजन पूल मेमोरी को मुक्त करना चाहता है? इसका उत्तर यह है कि अधिकांश RTOS एक समर्पित ब्लॉक में अतिरिक्त डेटा (आमतौर पर पॉइंटर से एक नकारात्मक ऑफसेट) का समर्थन करते हैं जो आवश्यक जानकारी प्रदान करते हैं। इस प्रकार, एपीआई को एक ब्लॉक से मुक्त करने के लिए, केवल इसके पते की आवश्यकता है।

निम्नलिखित लेख में मेमोरी विभाजन के बारे में अधिक जानकारी होगी।

समय

समय के उपयोग और नियंत्रण से जुड़ी कार्यक्षमता वास्तविक समय के ओएस में उपलब्ध होने की संभावना है। RTOS के आधार पर अवसर अलग-अलग होंगे, लेकिन हम सार्वजनिक रूप से उपलब्ध लोगों पर विचार करेंगे। किसी भी मामले में, वास्तविक समय टाइमर इनमें से किसी भी सेवा के कामकाज के लिए एक अनिवार्य तत्व है।

सिस्टम का समय

सरल प्रणाली समय, या "घड़ी टाइमर", लगभग हमेशा उपलब्ध है। यह सिर्फ एक काउंटर (आमतौर पर 32 बिट्स) है, जो वास्तविक समय की बाधा सेवा दिनचर्या का उपयोग करके बढ़ाया जाता है और एपीआई कॉल के साथ सेट और पढ़ा जा सकता है।

सर्विस कॉल टाइमआउट

आमतौर पर, एक आरटीओएस एपीआई कॉल को अवरुद्ध करने की अनुमति देता है, अर्थात, अनुरोध किए गए सेवा प्रदान किए जाने तक कॉलिंग कार्य निलंबित (अवरुद्ध) है। आमतौर पर यह लॉक अस्पष्ट होता है, लेकिन कुछ RTOS एक समयबाह्य प्रदान करते हैं, जिसके दौरान समय समाप्त होने पर कॉल वापस आ जाती है यदि सेवा अनुपलब्ध रहती है। API कॉल टाइमआउट सभी RTOS द्वारा समर्थित नहीं हैं।

नींद की अवस्था

आमतौर पर, कार्यों में एक निश्चित अवधि के लिए खुद को रोकने की क्षमता होती है। टास्क प्रबंधन अनुभाग में पहले इस पर चर्चा की गई थी।

सॉफ्टवेयर टाइमर

कार्यक्रम कार्यों के लिए समय गिनती कार्यों को पूरा करने के लिए, अधिकांश आरटीओएस टाइमर ऑब्जेक्ट की पेशकश करते हैं। ये वास्तविक समय टाइमर इंटरप्ट हैंडलर द्वारा अद्यतन स्वतंत्र टाइमर हैं, जिन्हें एपीआई कॉल द्वारा नियंत्रित किया जा सकता है। ऐसे कॉल टाइमर के संचालन को कॉन्फ़िगर, मॉनिटर और मॉनिटर करते हैं। एक नियम के रूप में, उन्हें एकल सक्रियण या स्वचालित पुनरारंभ के लिए सेट किया जा सकता है। एक समाप्ति दिनचर्या भी आमतौर पर समर्थित है, एक फ़ंक्शन जो हर बार एक टाइमर को पूरा करता है एक चक्र पूरा करता है। अगला लेख सॉफ्टवेयर टाइमर और उनके कार्यान्वयन के विवरण के बारे में अधिक जानकारी प्रदान करेगा।

बाधित, ड्राइवर, और मैं / ओ

RTOS इंटरप्ट से जुड़े हुए हैं और I / O बहुत अलग हैं। इसी तरह, कुछ RTOS में डिवाइस ड्राइवर्स के लिए एक बहुत ही स्पष्ट संरचना होती है, जो एक विशिष्ट उत्पाद का चयन करते समय समस्याओं को जोड़ सकते हैं।

बीच में आता है

रुकावट दो कारणों से RTOS के लिए एक समस्या पेश करता है।

• किसी भी सावधानियों के बिना, बाधा हैंडलर (ISR) प्रोसेसर समय को चुरा लेगा, जिससे वास्तविक समय आरटीओएस व्यवहार बाधित हो जाएगा।
• यदि ISR कार्य शेड्यूलिंग को प्रभावित करने वाली API कॉल करता है, तो इस पर नजर रखी जानी चाहिए, और RTOS को अपने शेड्यूलिंग एल्गोरिदम को चलाने में सक्षम होना चाहिए।

इस तरह के एक एपीआई कॉल का एक उदाहरण एक कार्य है जिसे बाधित होने पर लॉन्च की गई तुलना में अधिक प्राथमिकता के साथ जागने की प्रक्रिया है।

कुछ RTOS पूरी तरह से सभी अवरोधों को नियंत्रित करते हैं। आईएसआर कार्यक्रमों को "रजिस्टर" करने के लिए एपीआई कॉल की एक श्रृंखला उपलब्ध है। यह दृष्टिकोण अनुसूचक को हस्तक्षेप करने में सक्षम होने पर इंगित करने की अनुमति देता है, और आईएसआर से अधिकांश एपीआई कॉल के उपयोग की सुविधा देता है।

उदाहरण के लिए, न्यूक्लियस आरटीओएस "कम प्राथमिकता" और "उच्च प्राथमिकता" बाधित हैंडलर की अवधारणा को लागू करता है, जो अनावश्यक ओवरहेड के बिना विश्वसनीय व्यवधान प्रबंधन प्रदान करता है (अर्थात, बाधा देरी में वृद्धि)।

अन्य RTOS इंटरप्ट के लिए स्वचालित "हैंड्स ऑफ" मोड का उपयोग कर सकते हैं, जो डेवलपर्स को अधिक विकल्प प्रदान करता है ताकि यह सुनिश्चित हो सके कि बाधा हैंडलर सही तरीके से काम करें। एक नियम के रूप में, अतिरिक्त आईएसआर उपसर्ग (प्रस्तावना) और प्रत्यय (उपसंहार) इसमें दी गई एपीआई कॉल की सुरक्षा के लिए प्रदान किए जाते हैं।
न्यूक्लियस एसई एक हल्के बाधित दिनचर्या का उपयोग करता है, जिसे भविष्य के लेख में वर्णित किया जाएगा।

ड्राइवरों

अधिकांश RTOS डिवाइस ड्राइवर की संरचना निर्धारित करते हैं। विवरण RTOS के आधार पर भिन्न हो सकते हैं, लेकिन ड्राइवर में आमतौर पर दो इंटरेक्टिंग घटक होते हैं: एम्बेडेड कोड (एपीआई कॉल) और आईएसआर। आमतौर पर, ड्राइवरों को प्रबंधित और पंजीकृत करने के लिए अन्य एपीआई कॉल उपलब्ध होंगे।

इनपुट / आउटपुट

वर्तमान में, बाजार में अधिकांश आरटीओएस उच्च-स्तरीय इनपुट / आउटपुट के बारे में परवाह नहीं करते हैं, लेकिन उनमें से कुछ एक इनपुट / आउटपुट स्ट्रीम को परिभाषित करते हैं, जो मूल रूप से संबंधित डिवाइस ड्राइवर और मानक सी भाषा फ़ंक्शन, जैसे कि प्रिंटफ () के बीच एक संबंध स्थापित करता है।
ऐतिहासिक रूप से, RTOS अक्सर "कंसोल" का समर्थन करता है, धारावाहिक चैनल के माध्यम से RTOS के लिए उपयोगकर्ता इंटरफ़ेस। यह मुख्य रूप से निदान और डिबगिंग के लिए उपयोग किया गया था। आरटीओएस के साथ डिबगिंग अनुप्रयोगों का समर्थन करने वाले आधुनिक डिबगर्स का उपयोग करना ऐसी वस्तुओं की आवश्यकता को समाप्त करता है।

निदान

आमतौर पर, RTOS को न्यूनतम मेमोरी फुटप्रिंट के साथ अधिकतम प्रदर्शन की आवश्यकता होती है। इसलिए, अखंडता की जाँच एक उच्च प्राथमिकता नहीं है। आरटीओएस की विशेषताओं को ध्यान में रखने वाली आधुनिक डिबगिंग प्रौद्योगिकियों की सहायता से, अधिकांश चेक आरटीओएस के बाहर ही किए जा सकते हैं।

एपीआई कॉल पैरामीटर की जाँच करना

एपीआई कॉल में कई जटिल पैरामीटर हो सकते हैं। इससे त्रुटियाँ हो सकती हैं। कई RTOS गलत पैरामीटर के मामले में एक त्रुटि कोड की वापसी के साथ रनटाइम मापदंडों की जांच प्रदान करते हैं। चूंकि इसके लिए अतिरिक्त कोड की आवश्यकता होती है, और चेक स्वयं प्रदर्शन पर प्रतिकूल प्रभाव डालते हैं, इसलिए असेंबली या कॉन्फ़िगरेशन के दौरान मापदंडों की जांच करना बेहतर होता है।

ढेर की जांच

अधिकांश प्रकार के अनुसूचक के लिए (रन टू कंप्लीशन को छोड़कर) प्रत्येक कार्य का अपना स्टैक होता है, जिसका आकार व्यक्तिगत रूप से निर्धारित किया जाता है। कुछ RTOS में, कर्नेल का एक अलग स्टैक होता है, दूसरों में, कार्य स्टैक एक एपीआई कॉल के दौरान "उधार" होता है। जाहिर है, समग्र सिस्टम विश्वसनीयता के लिए स्टैक अखंडता महत्वपूर्ण है। इसलिए, RTOS अक्सर रनटाइम पर स्टैक अखंडता की जाँच के लिए उपकरण प्रदान करते हैं। कई विकल्प हैं:

• एक एपीआई कॉल जो वर्तमान या निर्दिष्ट कार्य के लिए स्टैक स्थान की मात्रा लौटाता है।
• स्टैक के बाउंडिंग पैरामीटर। उन्हें एक अद्वितीय (आमतौर पर विषम और गैर-शून्य) मान दिया जाता है, जो समय-समय पर पुनर्लेखन के लिए जाँच की जाती है।

अनुप्रयोग निदान

इस तथ्य के बावजूद कि यह फ़ंक्शन सीधे RTOS में समर्थित नहीं है, संपूर्ण सिस्टम की अखंडता की जांच के लिए एक आवेदन कार्य आवंटित किया जा सकता है। वॉचडॉग टाइमर को रीसेट करने के लिए ऐसा कार्य जिम्मेदार हो सकता है। प्रत्येक महत्वपूर्ण कार्य से एक कार्य आवधिक इनपुट डेटा (उदाहरण के लिए, सिग्नल पैरामीटर) प्राप्त कर सकता है। वॉचडॉग टाइमर को रीसेट करना (जो सिस्टम को रिबूट करने से रोकेगा) सभी कार्यों के डेटा आने के बाद ही किया जाएगा।

गैर कर्नेल सेवाएँ

RTOS सिर्फ उस कोर से अधिक है जिस पर हमने अभी तक ध्यान केंद्रित किया है। यह डेस्कटॉप ऑपरेटिंग सिस्टम एम्बेडेड आरटीओएस से काफी अलग है। आमतौर पर, एक डेस्कटॉप ओएस में, सभी अतिरिक्त घटकों को बंडल किया जाता है या स्थापित किया जा सकता है (सभी डेस्कटॉप पीसी में एक ग्राफिकल यूजर इंटरफेस है, और उनमें से केवल कुछ में नेटवर्क एक्सेस नहीं है)। डेस्कटॉप पीसी में वास्तविक संसाधन सीमाएँ नहीं होती हैं: हमेशा मुफ्त मेमोरी, हार्ड डिस्क स्थान और अप्रयुक्त सीपीयू संसाधन होता है। सीमित संसाधनों के साथ एम्बेडेड सिस्टम की दुनिया में, अतिरिक्त घटकों जैसे वीडियो कार्ड, नेटवर्क घटकों और फ़ाइल सिस्टम की आवश्यकता हो सकती है, लेकिन स्मृति पदचिह्न को कम करने के लिए उन्हें डिस्कनेक्ट और स्केलेबल होना चाहिए।

नेटवर्किंग सुविधाएँ

अधिकांश एम्बेडेड सिस्टम किसी तरह नेटवर्क से संबंधित हैं। इस प्रकार, यह उम्मीद की जाती है कि एम्बेडेड सिस्टम के लिए नेटवर्किंग समाधानों में महत्वपूर्ण रुचि है, जिसके कारण बाजार पर बड़ी संख्या में उत्पाद हैं।

टीसीपी / आईपी एक मानक प्रोटोकॉल है जो व्यापक रूप से उपयोग किया जाता है और कई अनुप्रयोगों के लिए स्पष्ट विकल्प है। आमतौर पर, टीसीपी / आईपी का उपयोग ईथरनेट प्रोटोकॉल (IEEE802.3) के लिए किया जाता है, जो 10 एमबी / एस की औसत गति प्रदान करता है। आज, 100 एमबी / एस काफी सामान्य हैं, और दृष्टिकोण 1 जीबी / एस पर। इसके अलावा, टीसीपी / आईपी का उपयोग अन्य प्रोटोकॉल के लिए किया जा सकता है। उदाहरण के लिए, PPP (प्वाइंट-टू-पॉइंट प्रोटोकॉल) सीरियल डेटा ट्रांसफर के लिए एक टीसीपी / आईपी कार्यान्वयन है जिसे ब्रॉडबैंड इंटरनेट कनेक्शन के लिए अनुकूलित किया गया है।

हाल तक तक, आईपी प्रोटोकॉल (IPv4) के संस्करण v4 का उपयोग किया गया था। हालाँकि, यह अप्रचलित हो जाता है क्योंकि मुफ्त पते निकल जाते हैं। समाधान IPv6 है, संभव पते की संख्या में काफी वृद्धि और रखरखाव और सुरक्षा के लिए अधिक कुशल उपकरण प्रदान करता है। IPv6 व्यापक रूप से उपलब्ध है और इसका उपयोग कई देशों के उपकरणों के साथ-साथ दुनिया भर में सैन्य प्रणालियों में भी किया जाता है।
एक विकल्प उपयोगकर्ता डेटाग्राम प्रोटोकॉल (यूडीपी) है। यह प्रोटोकॉल अधिकतम प्रदर्शन के लिए उपयोग किया जाता है। यूडीपी टीसीपी के समान विश्वसनीयता और स्थिरता प्रदान नहीं करता है, लेकिन यह हल्का और अत्यधिक कुशल है।

USB यूनिवर्सल सीरियल बस है, जिसे व्यापक रूप से डेस्कटॉप कंप्यूटर से कनेक्ट करने के लिए उपकरणों में उपयोग किया जाता है। यह एक बहुत ही आसानी से उपयोग होने वाला प्लग-एंड-प्ले इंटरफ़ेस प्रदान करता है जो काफी परिष्कृत सॉफ़्टवेयर को छुपाता है।एक एम्बेडेड डिवाइस जो एक पीसी से जुड़ा होना चाहिए, उसे यूएसबी फ़ंक्शन के रूप में लागू किया जाना चाहिए, जिसमें सॉफ़्टवेयर घटकों के एक विशिष्ट सेट की आवश्यकता होती है। यदि डिवाइस को USB (एक नियमित पीसी की तरह) से जुड़े अन्य उपकरणों का प्रबंधन करना चाहिए, तो उसे होस्ट-प्रकार सॉफ़्टवेयर का एक सेट चाहिए।

IEEE1394 , धारावाहिक इंटरफेस के लिए एक और मानक जो बड़ी मात्रा में डेटा के बीच उपकरणों को जल्दी से स्थानांतरित करने के लिए उपयोग किया जाता है (उदाहरण के लिए, वीडियो डेटा स्थानांतरित करने के लिए), फायरवायर और आई.लिंक के रूप में भी जाना जाता है।

वायरलेस प्रोटोकॉल - उपभोक्ताओं के बीच विभिन्न वायरलेस प्रौद्योगिकियों की सुविधा और व्यापकता ने एम्बेडेड उपकरणों में वायरलेस क्षमताओं की उच्च मांग को जन्म दिया है। वाई-फाई (मानकों का IEEE802.11) नेटवर्क क्षमताओं का एक पूरा सेट प्रदान करता है, जिससे आप सहकर्मी और बुनियादी ढाँचे दोनों को पर्याप्त दूरी पर लागू कर सकते हैं। ऐसे नेटवर्क में डेटा सुरक्षा में रुचि बढ़ रही है, जिसका अर्थ है कि यह सॉफ्टवेयर को प्रभावित करना चाहिए। अन्य रेडियो प्रौद्योगिकियां, विशेष रूप से ब्लूटूथ और ज़िगबी, कम दूरी के पॉइंट-टू-पॉइंट वायरलेस संचार प्रदान करती हैं।

प्रोटोकॉल सत्यापन

चूंकि नेटवर्किंग के अवसर उच्च मांग में हैं, इसलिए कई आपूर्तिकर्ता अपने समाधान पेश कर रहे हैं। ग्राहकों के पास उपलब्ध उत्पादों की गुणवत्ता की जांच करने की चुनौती है। RTOS कर्नेल के विपरीत, प्रोटोकॉल स्टैक की कार्यक्षमता और प्रदर्शन की पूरी जांच एक आसान काम नहीं है। सौभाग्य से, टूलकिट प्रोटोकॉल की जांच के लिए उपलब्ध हैं (यद्यपि काफी कीमत पर), और एक संभावित खरीदार आपूर्तिकर्ता से पता लगा सकता है जो सेट करते थे कि वे जांच करते थे।

ग्राफिक्स

एम्बेडेड उपकरणों के बीच एक ग्राफिकल इंटरफ़ेस आम होता जा रहा है। यह एक बहुत ही सरल, छोटा मोनोक्रोमेटिक एलसीडी (जैसे पुराने फोन, एमपी 3 प्लेयर, अलार्म आदि) हो सकता है। दूसरी ओर, एक डिजिटल टेलीविजन रिसीवर की अपनी उच्च-रिज़ॉल्यूशन वाली एचडीटीवी स्क्रीन हो सकती है। ऐसी स्क्रीन के लिए सॉफ़्टवेयर समर्थन की आवश्यकता होती है जो RTOS कर्नेल में पूरी तरह से एकीकृत होता है।
चूंकि स्क्रीन में आमतौर पर किसी प्रकार का इनपुट डिवाइस होता है, ऐसे उपकरणों के लिए समर्थन अक्सर ग्राफिक्स पैकेज में शामिल होता है। ऐसा पैकेज पॉइंटिंग डिवाइस (उदाहरण के लिए, एक माउस), टचस्क्रीन, कीपैड और पूर्ण कीबोर्ड का समर्थन कर सकता है।
ग्राफिक्स का उपयोग विभिन्न तरीकों से किया जा सकता है। यह बस सूचना आउटपुट प्रदान कर सकता है (उदाहरण के लिए, इलेक्ट्रॉनिक स्कोरबोर्ड की तरह)। या प्रदर्शन मेनू, विंडोज, आइकन और इसी तरह के तत्वों के साथ एक ग्राफिकल यूजर इंटरफेस का हिस्सा हो सकता है। किसी भी मामले में, सॉफ़्टवेयर के बजाय विशिष्ट सेट की आवश्यकता होती है, और आरटीओएस के साथ आपूर्ति किए गए ग्राफिक्स पैकेज को आवश्यक लचीलेपन प्रदान करना चाहिए, जिसमें उपयोग की गई स्मृति की मात्रा में वृद्धि के बिना आवश्यक लचीलापन हो।

फ़ाइल सिस्टम

जब एक एम्बेडेड एप्लिकेशन को महत्वपूर्ण मात्रा में डेटा संग्रहीत और संसाधित करने की आवश्यकता होती है, तो यह स्पष्ट है कि यह डेटा को किसी प्रकार की फ़ाइल सिस्टम में व्यवस्थित करने के लिए समझ में आता है। डेटा रैम में हो सकता है, अंतर्निहित फ्लैश मेमोरी में, यूएसबी फ्लैश ड्राइव पर, नियमित हार्ड डिस्क पर या ऑप्टिकल डिस्क (सीडी-रॉम या डीवीडी-रॉम) पर। फिर से, इस तरह के एक अवसर के लिए सॉफ़्टवेयर समर्थन पूरी तरह से आरटीओएस में एकीकृत होना चाहिए। मल्टी-टास्किंग सिस्टम की रीवेंट्री आवश्यकताओं को पूरा करने के लिए फ़ाइल सिस्टम को सावधानीपूर्वक डिज़ाइन किया जाना चाहिए।

फ़ाइल सिस्टम के लिए अनुपालन विशेष रूप से महत्वपूर्ण है। उदाहरण के लिए, MS-DOS संगत डिस्क प्रारूप का उपयोग डेवलपर्स को अच्छी तरह से स्थापित वास्तुकला का उपयोग करने की अनुमति देता है और डेस्कटॉप सिस्टम के साथ पूर्ण विकसित डेटा एक्सचेंज प्रदान करता है।