एक सिस्टम से दूसरे सिस्टम में डेटा ट्रांसफर के लिए जनरल प्रोटोकॉल?


18

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


4
आप क्या ठोस काम करना चाहते हैं?
starblue

बस एक छोटे से बॉक्स में एक दूसरे को डेटा पास करने के लिए एक सिस्टम के विभिन्न टुकड़ों को कैसे प्राप्त किया जाए, यह सोचकर, इसलिए दूरी को बहुत कम माना जा सकता है। एक बॉक्स में अलग-अलग टुकड़े होने का कारण कार्यों को सरल बनाना है ताकि प्रत्येक टुकड़े का अपना कार्य हो (उम्मीद है कि समझ में आता है ..)
O_O

2
ऐसा नहीं है कि लोग आमतौर पर एक प्रणाली कहते हैं। वे वे हैं जो मैं उप-प्रणालियों के रूप में परिभाषित करता हूं। वे उन कार्यों का एक हिस्सा बनाते हैं जिन्हें आप एकल प्रणाली को कार्यों के एक सेट को पूरा करने पर विचार कर सकते हैं। यह शब्दार्थ है, लेकिन मुझे लगता है कि आपके कई उत्तर बहुत व्यापक हैं क्योंकि उन्हें इस बात का बिल्कुल सही अंदाजा नहीं है कि आप प्रश्न से क्या ढूंढ रहे हैं।
कर्टुक

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

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

जवाबों:


10

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

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

बेशक, यह हर समय एक खतरनाक सीमा बन रहा है। पीसीआई और आईएसए जैसी चीजें निर्विवाद रूप से बसें हैं; I2C, SPI, USB यकीनन बसें हैं; जबकि RS232, RS485, और ईथरनेट निश्चित रूप से संचार इंटरफेस हैं। लेकिन फिर कैन बस और 1553 जैसी चीजें हैं, जो निश्चित रूप से घूमने वाले डेटा के बारे में हैं, लेकिन बहुत ही तरह से शामिल हैं।


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

@ कोरटुक - 232 की तरह कुछ भी सहकर्मी सहकर्मी समरूपता का एक प्रकार है, जबकि 1553 या मास्टर / दास संबंध को लागू कर सकता है, हाँ। मुझे विश्वास नहीं होता कि मैंने कहा कि ईथरनेट सरल है, बस यह है कि यह अंतिम बिंदुओं पर बस नियंत्रक / बस डिवाइस भेद नहीं करता है।
जस्टजेफ

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

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

11

डेटा भेजने का कोई एक तरीका नहीं है, दूरी, डेटा दर, पर्यावरण, अनुप्रयोग के आधार पर संवाद करने के कई अलग-अलग तरीके हैं ...

सबसे निचली परत भौतिक परत है , जो वास्तव में बिट्स को चारों ओर ले जाती है।

  • SPI और I ,C एक उपकरण के अंदर कम दूरी के लिए होते हैं, जहां इतना शोर नहीं होता जो ट्रांसमिशन को परेशान कर सकता है।

  • RS-232 के माध्यम से कुछ दसियों मीटर के धारावाहिक संचार तक की दूरी पर बहुत तेज़ संचार के लिए अच्छा विकल्प नहीं है।

  • यदि अधिक शोर है या लंबी दूरी के अंतर सिग्नल का उपयोग किया जाता है, उदाहरण के लिए RS-485 में। तेज डेटा ट्रांसमिशन के लिए ईथरनेट है, जो अधिक से अधिक लोकप्रिय हो रहा है।

  • फिर विभिन्न वायरलेस मानक भी हैं।

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


7

एक साधारण धारावाहिक UART का उपयोग किया जा सकता है (कोई असतत घड़ी के साथ एक Tx और एक Rx लाइन) और ऑप्टोइसोलरेटरों या चुंबकीय आइसोलेटर्स के साथ आसानी से विभिन्न संभावितों (यहां तक ​​कि प्राथमिक और माध्यमिक सर्किट) के बीच पार करने के लिए अनुकूलित किया जा सकता है ।

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

PMBus , उदाहरण के लिए, एक बिजली आपूर्ति संचार प्रोटोकॉल है जो I2C को इसके भौतिक माध्यम के रूप में उपयोग करता है।


6

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

इस आवेदन के बारे में कुछ प्रश्न:

  1. क्या इस परियोजना में 2 से अधिक सूक्ष्म नियंत्रक होंगे?
  2. आपकी गति और थ्रूपुट आवश्यकताएं क्या हैं? सूचना कितनी तेजी से मिलती है और कितनी बार आप डेटा भेज / प्राप्त कर रहे हैं?

यदि आपने प्रश्न 1 का उत्तर नहीं दिया है:

यदि इस परियोजना में केवल 2 माइक्रो-नियंत्रक हैं, तो आप निश्चित रूप से उनके बीच UART का उपयोग कर सकते हैं। यदि वे दोनों संचार शुरू करने की जरूरत है, प्रवाह नियंत्रण का उपयोग करें, अन्यथा यह एक दिशा में डेटा भेजने के लिए तुच्छ होना चाहिए। अधिकांश भाग के लिए "तेज पर्याप्त" होना चाहिए, यह देखते हुए कि आप उच्च बॉड दरों में से एक का चयन करते हैं। I2C और SPI आमतौर पर केवल मास्टर / दास वास्तुकला के लिए अच्छे होते हैं।

यदि आपने प्रश्न 1 के लिए हाँ (2 से अधिक नियंत्रक) का उत्तर दिया है:

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

तो अब आपको कुछ और अधिक स्केलेबल की आवश्यकता है जहां आप एक सामान्य बस पर पता करने योग्य उपकरणों को छोड़ सकते हैं। इन अनुवर्ती प्रश्नों का उत्तर आपको I2C और SPI (मास्टर-स्लेव) या CAN (मल्टी-मास्टर) जैसे कुछ के बीच का निर्णय लेने में मदद करेगा।

आपके माइक्रो-नियंत्रक में सबसे अधिक UART परिधीय है, अन्य (विशेषकर CAN) केवल अधिक उच्च अंत चिप्स पर उपलब्ध हो सकते हैं। किसी भी स्थिति में, बाइट्स को स्थानांतरित करने के लिए इन परिधीयों का उपयोग करने के तरीके के बारे में बहुत सारे दस्तावेज होने चाहिए।


5

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

I2C वास्तव में एक अद्भुत प्रोटोकॉल है। सबसे बड़ी सीमाएं जो इसे सबसे सटीक प्रोटोकॉल होने से रोकती हैं, कल्पनाशील हैं

  1. इसकी गति कुछ सीमित है; एसपीआई बहुत तेजी से जा सकता है, और यहां तक ​​कि यूएआरटी कभी-कभी थोड़ा तेज हो सकता है
  2. (2) जबकि यह बहुत सुविधाजनक है कि I2C को केवल दो तारों की आवश्यकता है, दोनों तारों को द्विदिश खुले-कलेक्टर संचार में सक्षम होना चाहिए। इससे I2C को रिपीटर्स के माध्यम से भेजना मुश्किल हो जाता है।

व्यक्तिगत रूप से, मैं नियंत्रक वेंडर को SPI के तीन-तार संस्करण का समर्थन करना चाहता हूं जिसमें हैंडशेकिंग शामिल था। मैं किसी भी नियंत्रक से अनजान हूं जो ऐसा करता है, हालांकि।


अजीब बात है कि आपको इसका उल्लेख करना चाहिए ... मैं एक गैर-द्विदिश I2C की तरह एक SPI इंटरफ़ेस को चालू करने वाला हूं (पहला बाइट एक पता है) बस पर भाग लेने के लिए कई और उपकरणों को सक्षम करने की तुलना में जिनके लिए मैंने चिप का चयन किया है । यह काम करता है अगर आपके गुलाम डिवाइस सभी FPGAs हैं। :) मैंने भी चाहा है कि उन दो प्रमुख तुल्यकालिक मानकों के बीच कुछ था।
डार्रोन

ओह, मुझे लगता है कि मुझे स्पष्ट करना चाहिए कि आउटपुट दास पर सक्षम बनाता है जब तक कि यह पता बाइट प्राप्त नहीं हो जाता है और वे तब तक बने रहते हैं जब तक कि एकल चिप का चयन नहीं किया जाता है ... इसलिए यह स्पष्ट रूप से सामान्य एसपीआई + उच्च स्तर से थोड़ा अलग है मसविदा बनाना। हालांकि, यह पूरी तरह से एक मास्टर डिवाइस के दृष्टिकोण से मानक एसपीआई के साथ संगत है। (एक माइक्रोप्रोसेसर की तरह)
डारोन

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

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

@ डार्रॉन: ... एक डेटा बाइट। यदि पांच या अधिक से अधिक, बाइट को नजरअंदाज कर दिया जाएगा (गुलाम यह मान लेगा कि मास्टर को डेटा बाइट प्राप्त करने में दिलचस्पी थी, लेकिन वास्तव में ऐसा कुछ नहीं कहना चाहता था)। यह लगभग उतना महत्वपूर्ण नहीं होगा, हालांकि, जब घड़ी कम थी तब गुलाम की रिपोर्ट अंतिम-बाइट की स्थिति में थी, (यदि गुलाम डिवाइस एक प्रोसेसर था, तो मास्टर को यह जानने की अनुमति दें कि दास तैयार नहीं हुआ था और आखिरी 'लेन-देन का मौका' चूक गया था।
सुपरकैट

3

किसी विशेष क्रम में, एक ही बॉक्स में 2 सीपीयू के लिए सबसे लोकप्रिय भौतिक-परत उदाहरण हैं:

  • डेज़ी-चेन एसपीआई (जैसे कि जेटीजी द्वारा उपयोग किया जाता है)
  • चयन-तार-प्रति-दास एसपीआई
  • "टीटीएल-स्तर RS-232" उर्फ ​​"अतुल्यकालिक स्टार्ट-स्टॉप सीरियल संचार" (एक सीपीयू के UART TX पिन को सीधे दूसरे सीपीयू के UART RX पिन से कनेक्ट करना)
  • I2C
  • 8-बिट डेटा + स्ट्रोब (जैसे IEEE 1284 प्रिंटर पोर्ट समानांतर पोर्ट)
  • साझा-मेमोरी (केवल एक सीपीयू एक समय में पता / डेटा / नियंत्रण बस चलाता है)

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

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

एक सीपीयू से दूसरे सीपीयू में सूचना भेजने का प्रोटोकॉल लगभग हमेशा पैकेट की एक श्रृंखला के रूप में बाइट्स की धारा की व्याख्या करता है:

  1. प्रस्तावना
  2. हैडर
  3. (संभवतः बच गया) क्रमबद्ध डेटा
  4. ट्रेलर

कुछ लोगों को मिक्स-एंड-मैचिंग (2a) के कई प्रकारों में से एक (3a) के कई प्रकार के क्रमबद्ध डेटा के साथ (3 बी) के कई प्रकारों में से एक को मिलाकर पूरी तरह से नया, कस्टम, असंगत प्रोटोकॉल बनाने का आनंद लेने लगता है। (4) ट्रेलर के कई प्रकारों में से एक के साथ उस क्रमबद्ध डेटा से बचना।

पैकेट में डेटा एनकैप्सुलेट करने के कुछ सरलतम प्रोटोकॉल शामिल हैं:

पैकेट में डेटा एनकैप्सुलेट करने के लिए थोड़ा अधिक जटिल प्रोटोकॉल में शामिल हैं:

प्रोटोकॉल की एक लंबी सूची है

आपको राडिया पर्लमैन द्वारा "प्रोटोकॉल डिज़ाइन लोककथा" पढ़ने का आनंद मिल सकता है जो बताता है कि प्रोटोकॉल डिज़ाइन कैसे गलत हो सकता है।


3

कोई एकल 'सामान्य' प्रोटोकॉल नहीं। पसंद (उदाहरण के लिए) इस पर निर्भर कर सकती है:

  • दूरी
  • आवश्यक थ्रूपुट
  • विशेष बाह्य उपकरणों की उपलब्धता
  • शोर का स्तर
  • ऑप्टिकल अलगाव की आवश्यकता है
  • महत्वपूर्णता (सहन करने योग्य विफलता दर)
  • दोनों सिरों पर avialable CPU शक्ति
  • उपलब्ध I / O दोनों सिरों पर पिन

बहुत सारे मामलों में आपको डेटा लिंक परत (+/- जिस तरह से डेटा इनकोड किया गया है) से भौतिक परत (सिग्नल स्तर) को मिटा देना चाहिए (OSI मॉडल, निचली 2 ..4 परतें)। संभावित फ़िस्कल परतें उदाहरण के लिए हैं:

  • सरल 5V या 3.3V या यहां तक ​​कि 1.8V TTL
  • पुश-पुल के बजाय उपरोक्त लेकिन खुले कलेक्टर में से कोई भी
  • संतुलित लव वोल्टेज संकेत (अक्सर FPGA के साथ प्रयोग किया जाता है)
  • संतुलित व्याघ्र खंड (RS485, RS432)
  • एकल समाप्त उच्च वोल्टेज (RS232)
  • संतुलित ट्रैफ़ो-युग्मित (विभिन्न ईथरनेट संस्करण, PDIF ऑडियो)
  • ऑप्टिकल (ऑप्टिकल ईथरनेट, toslink)

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

वहाँ एक लाइन पर डेटा और घड़ी सांकेतिक शब्दों में बदलना करने के लिए बहुत सारे हैं। RS232 पारंपरिक रूप से NRZ का उपयोग करता है, इसमें माचस्टर एन्कोडिंग है, विभिन्न स्वरूपों का उपयोग करता है हार्डडिस्क पर उत्सुक नाम रेखा 2.7 RLL।

इसे योग करने के लिए: सिस्टीम के बीच संचार करने के लिए एक गज़िलियन तरीके हैं। और मैंने कनेक्टर या उच्च-स्तरीय पहलुओं जैसे त्रुटि का पता लगाने और पुनर्प्राप्ति, डेटा एन्कोडिंग, संपीड़न, और एन्क्रिप्शन का उल्लेख नहीं किया है ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.