सीरियल प्रोटोकॉल परिसीमन / सिंक्रनाइज़ेशन तकनीक

Question

जैसा कि आजकल एसिंक्रोनस सीरियल संचार व्यापक रूप से इलेक्ट्रॉनिक उपकरणों के बीच फैला हुआ है, मेरा मानना ​​है कि हम में से कई ने समय-समय पर इस तरह के सवाल का सामना किया है। एक इलेक्ट्रॉनिक डिवाइस Dऔर PCसीरियल लाइन (RS-232 या इसी तरह) से जुड़े कंप्यूटर पर विचार करें और लगातार सूचनाओं का आदान-प्रदान करें । यानी PCप्रत्येक एक कमांड फ्रेम भेज रहा है X ms, और Dस्टेटस रिपोर्ट / टेलीमेट्री फ्रेम प्रत्येक के साथ उत्तर दे रहा है Y ms(रिपोर्ट को अनुरोध या स्वतंत्र रूप से प्रतिक्रिया के रूप में भेजा जा सकता है - वास्तव में यहां कोई फर्क नहीं पड़ता)। संचार फ़्रेम में कोई भी मनमाना बाइनरी डेटा हो सकता है । मान लें कि संचार फ़्रेम निश्चित लंबाई के पैकेट हैं।

समस्या:

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

आवश्यक समाधान

विश्वसनीय परिसीमन / तुल्यकालन योजना लघु वसूली समय के साथ SOF का पता लगाने के लिए (यानी इसे अधिक से अधिक नहीं लेना चाहिए, 1 फ्रेम को resynchronize कहना)।

मौजूदा तकनीकों से मैं अवगत हूँ (और कुछ का उपयोग करके):

1) हैडर / चेकसम - पूर्वनिर्धारित बाइट मान के रूप में एसओएफ। फ्रेम के अंत में चेकसम।

• पेशेवरों: सरल।
• विपक्ष: विश्वसनीय नहीं है। अज्ञात वसूली का समय।

2) बाइट स्टफिंग:

• पेशेवरों: विश्वसनीय, तेजी से वसूली, किसी भी हार्डवेयर के साथ इस्तेमाल किया जा सकता है
• विपक्ष: तय-आकार के फ्रेम-आधारित संचार के लिए उपयुक्त नहीं है

3) 9 वीं बिट मार्किंग - अतिरिक्त बिट के साथ प्रत्येक बाइट को प्रीपेन्ड करें, जबकि एसओएफ के साथ चिह्नित 1और डेटा बाइट्स के साथ चिह्नित हैं 0:

• पेशेवरों: विश्वसनीय, तेजी से वसूली
• विपक्ष: हार्डवेयर समर्थन की आवश्यकता है। सीधे PCहार्डवेयर और सॉफ्टवेयर के अधिकांश द्वारा समर्थित नहीं है ।

4) 8 वीं बिट अंकन - उपरोक्त प्रकार का अनुकरण, जबकि 9 के बजाय 8 बिट का उपयोग करते हुए, जो प्रत्येक डेटा शब्द के लिए केवल 7 बिट छोड़ रहा है।

• पेशेवरों: विश्वसनीय, तेजी से वसूली, किसी भी हार्डवेयर के साथ इस्तेमाल किया जा सकता है।
• विपक्ष: पारंपरिक 8-बिट प्रतिनिधित्व / से / 7-बिट प्रतिनिधित्व के लिए / से एन्कोडिंग / डिकोडिंग योजना की आवश्यकता है। कुछ हद तक बेकार।

5) टाइमआउट आधारित - कुछ परिभाषित निष्क्रिय समय के बाद आने वाले पहले बाइट के रूप में एसओएफ मान लें।

• पेशेवरों: कोई डेटा ओवरहेड, सरल नहीं।
• विपक्ष: विश्वसनीय नहीं है। विंडोज पीसी जैसे खराब टाइमिंग सिस्टम के साथ अच्छा काम नहीं करेगा। संभावित थ्रूपुट ओवरहेड।

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

Comments

4 केवल 1/8 वां अधिक बेकार है। 3.

— निक जॉनसन

@ निकीजॉनसन सहमत हैं, लेकिन यह केवल सुझाव दे रहा है कि मैं (3) में "अपशिष्टपूर्ण" चीज को भी जोड़ दूं :)

— यूजीन श।

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

— gulmer

Beceiver एक बाइट के बीच में शामिल हो सकता है और उदाहरण के लिए बिट 8 की बिट 4 की व्याख्या कर सकता है। 9 वीं बिट अंकन इसलिए अविश्वसनीय है।

— टिमोथी बाल्डविन

@gbulmer मूल धारणा यह है कि चैनल एकदम सही है और प्रारंभिक प्रक्षेपास्त्रीकरण के कारण ही समस्या उत्पन्न हो सकती है। इन मान्यताओं के तहत "विश्वसनीयता" जिसका मैं जिक्र कर रहा था, वह केवल रिंकस से संबंधित है। उपरोक्त सूची में ये सभी तकनीकें पहले वाले को छोड़कर 100% सफलता की गारंटी दे रही हैं। लेकिन शायद त्रुटि जाँच योजना और फ्रेमिंग को इस तरह अलग नहीं किया जाना चाहिए।

— यूजीन श।

Answer 1

कैसे आप (या आप) अपने सिस्टम प्रोटोकॉल को डिजाइन करेंगे?

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

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

स्क्रैच से अपने खुद के संचार प्रोटोकॉल को लिखना बहुत ही सामान्य समस्याओं में से कई के खिलाफ स्लैम की संभावना है जो हर किसी के पास है जब वे एक नया प्रोटोकॉल लिखते हैं।

कंप्यूटर संचार के लिए एम्बेडेड RS232- आधारित प्रोटोकॉल में सूचीबद्ध एक दर्जन एम्बेडेड सिस्टम प्रोटोकॉल हैं - जो आपकी आवश्यकताओं के सबसे करीब है?

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

बुरी खबर

जैसा कि मैंने पहले कहा है :

दुर्भाग्य से, किसी भी संचार प्रोटोकॉल के लिए इन सभी सुविधाओं का अच्छा होना असंभव है:

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

मुझे आश्चर्य होगा और खुशी होगी अगर संचार प्रोटोकॉल के लिए इन सभी विशेषताओं के लिए कोई रास्ता नहीं था।

खुशखबरी

समस्या के समाधान के लिए अन्य संभावित तकनीक / समाधान मौजूद हैं?

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

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

कुछ लोगों को लगता है कि केवल मुद्रण योग्य वर्णों का उपयोग करने के लिए एक प्रोटोकॉल को सीमित करना "बेकार" है, लेकिन डिबगिंग समय में बचत अक्सर इसे सार्थक बनाती है।

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

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

क्या आप उपर्युक्त सूची में विपक्ष की ओर इशारा कर सकते हैं, जो आसानी से चारों ओर काम कर सकता है, इस प्रकार उन्हें हटा सकता है?

जैसा कि निकोलस क्लार्क ने बताया, सुसंगत-ओवरहेड बाइट स्टफिंग (COBS) में एक निश्चित ओवरहेड होता है, जो निश्चित आकार के फ्रेम के साथ अच्छी तरह से काम करता है।

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

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

सौभाग्य।

Comments

यह उत्तर पहले स्वीकार किए गए उत्तर (क्षमा करें, @DaveTweed) पर पुनर्विचार करने के लायक है, और जुड़ा हुआ लेख निश्चित रूप से विषय पर एक व्यापक है। समय देने और इसे लिखने के लिए धन्यवाद।

— यूजीन श।

अच्छा है कि आप COBS को इंगित करते हैं, इसलिए मुझे एक उत्तर लिखने की ज़रूरत नहीं है :-)

— Nils Pipenbrinck

Answer 2

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

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

बाइट-स्टफिंग के ओवरहेड के लिए, क्या आपने COBS प्रोटोकॉल को देखा है? यह प्रत्येक 254 प्रेषित (साथ ही आपके फ्रेमिंग, सीआरसी, LEN, आदि) 1 बाइट के एक निश्चित ओवरहेड के साथ बाइट-स्टफिंग करने का एक प्रतिभाशाली तरीका है।

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

Comments

यह सबसे अच्छा तरीका है कि बाइट-स्टफिंग को सबसे खराब स्थिति में डेटा को 2x में विस्फोट करने से बचाएं। मैंने समान लेकिन अधिक एप्लिकेशन-विशिष्ट योजनाओं का उपयोग किया है, लेकिन मानक रूप से वर्णित इसे देखना बहुत अच्छा है। मैं अब से COBS का उपयोग करने जा रहा हूं ...

— wjl

COBS को इंगित करने के लिए मेरी ओर से भी धन्यवाद - एक बहुत साफ-सुथरा अल्गोरिथम।

— निक जॉनसन

Answer 3

आपका विकल्प # 1, एसओएच प्लस चेकसम, आईएस विश्वसनीय है, और यह अगले अनियंत्रित फ्रेम पर ठीक हो जाता है।

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

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

ध्यान दें कि यदि कोई संदेश वास्तव में डेटा त्रुटियों के कारण है, तो यह एल्गोरिथ्म इसे छोड़ देगा - लेकिन आप शायद वैसे भी ऐसा करने जा रहे थे। यदि आपके चेक एल्गोरिदम में फॉरवर्ड एरर करेक्शन शामिल है, तो आप प्रत्येक संभावित मैसेज एलाइनमेंट को सही त्रुटियों के लिए चेक कर सकते हैं।

यदि संदेश निश्चित लंबाई के होते हैं, तो आप SOH बाइट के साथ पूरी तरह से दूर हो सकते हैं - एक वैध मान मूल्य के लिए हर संभव स्थिति का परीक्षण करें।

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

Comments

मुझे लगता है कि विश्वसनीयता कुछ संभावित है? त्रुटि जाँच / सुधार कोड की ताकत के आधार पर हम उन फ़्रेमों का सामना कर सकते हैं जो एक यादृच्छिक / मनमाने बाइट स्ट्रीम में सही लगते हैं।

— यूजीन श।

यकीन है, यह संभव है। लेकिन व्यवहार में, एक चेक एल्गोरिथ्म चुनना अपेक्षाकृत आसान है जो पर्याप्त मजबूत है।

— डेव ट्वीड

यदि आपके पास डेटा त्रुटियों की एक नॉनज़ेरो दर है, तो हमेशा एक ग़ैरज़रूरी मौका होता है जिसे आप वैसे भी अमान्य संदेश स्वीकार करेंगे।

— निक जॉनसन

@NickJohnson पूरी तरह से स्वच्छ चैनल मानते हुए, इस दृष्टिकोण के साथ अभी भी (सैद्धांतिक रूप से) बेमेल रहेगा। बेशक उनकी संभावना नगण्य हो सकती है।

— यूजीन श।

मुझे पता है कि आप यह पहले से ही जानते हैं, और पहले से ही इसे पारित करने में उल्लेख किया है, लेकिन वह संस्करण जहां आप एक संपूर्ण संदेश को बफर नहीं करते हैं, या आप कैसे डिकोड करते हैं, इसके बारे में केवल आलसी हैं, कम विश्वसनीय है। यदि आप "गलत" SOH के बाद अगले SOH बाइट के बजाय अगले SOH बाइट के बाद अगले SOH बाइट पर फिर से टाइप करते हैं, तो आपके पास असली संदेश शुरू करने और कई संदेशों के लिए सिंक से बाहर रहने का एक बहुत अच्छा मौका है या में सबसे खराब मामला, हमेशा के लिए।

— हॉब्स

Answer 4

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

टेक्स्ट एन्कोडिंग का लाभ यह है कि आप फ्रेमन के लिए गैर-मुद्रण योग्य वर्णों का उपयोग कर सकते हैं। उदाहरण के लिए, सबसे सरल 0x00फ्रेम की शुरुआत के 0xffलिए और फ़्रेम के अंत के लिए कुछ का उपयोग करना पसंद होगा ।

मैंने देखा है कि दो मुख्य तरीके डेटा पाठ के रूप में एन्कोडेड हैं:

1. जब एक हार्डवेयर / असेंबली लड़के को ऐसा करने के लिए कहा जाता है, तो इसे संभवतः हेक्स एन्कोडिंग के रूप में लागू किया जाएगा। यह केवल ASCII में बाइट्स को उनके हेक्स मान में परिवर्तित कर रहा है। ओवरहेड बड़ा है। मूल रूप से आप हर वास्तविक डेटा बाइट के लिए दो बाइट्स प्रसारित करेंगे।

2. जब एक सॉफ्टवेयर आदमी को ऐसा करने के लिए कहा जाता है तो इसे संभवतः बेस 64 एनकोडिंग के रूप में लागू किया जाएगा। यह इंटरनेट की वास्तविक संरचना है। ईमेल MIME संलग्नक से URL डेटा एन्कोडिंग के लिए सब कुछ के लिए इस्तेमाल किया। ओवरहेड बिल्कुल 33% है। सरल हेक्स एन्कोडिंग की तुलना में बहुत बेहतर है।

वैकल्पिक रूप से, आप बाइनरी डेटा को पूरी तरह से छोड़ सकते हैं और पाठ को प्रसारित कर सकते हैं। इस मामले में सबसे आम तकनीक न्यूलाइन (या तो "\n"या "\r\n") के साथ डेटा का परिसीमन करना है । NMEA (GPS), मॉडेम AT कमांड्स और Adventech ADAM सेंसर इसके कुछ सबसे सामान्य उदाहरण हैं।

इन सभी पाठ-आधारित प्रोटोकॉल / फ़्रेमिंग में निम्नलिखित पेशेवरों और विपक्ष हैं:

समर्थक:

• डिबग करना आसान है
• स्क्रिप्टिंग भाषा में लागू करना आसान है
• हार्डवेयर को केवल हाइपरटेर्मिनल / मिनिकॉम का उपयोग करके परीक्षण किया जा सकता है
• हार्डवेयर पर लागू करना आसान है (जब तक कि यह PIC की तरह वास्तव में छोटा माइक्रो न हो)
• या तो निश्चित आकार का फ्रेम या भिन्न आकार हो सकता है।
• भविष्य कहनेवाला और तेजी से सिंक रिकवरी टाइम (वर्तमान फ्रेम के अंत में पुनर्प्राप्त)

कोन:

• शुद्ध बाइनरी ट्रांसमिशन की तुलना में बहुत बड़ा ओवरहेड (तब फिर से, टेक्स्ट I / O भी "0"चार बाइट्स 0x00000000 के बजाय एक बाइट (0x30) भेजने की तरह "सेक" कर सकता है )
• PIC की तरह बहुत छोटे माइक्रोस पर लागू करने के लिए इतना साफ नहीं है (जब तक कि आपके पुस्तकालय में कोई sprintf()फ़ंक्शन शामिल न हो )

मेरे लिए व्यक्तिगत रूप से पेशेवरों ने विपक्ष को भारी पछाड़ दिया। अकेले डिबगिंग की आसानी 5 बिंदुओं के रूप में गिना जाता है (ताकि अकेले एकल बिंदु दोनों विपक्ष से आगे निकल जाएं)।

---

फिर सॉफ्टवेयर वालों की ओर से अक्सर ध्यान से सोचे जाने वाले समाधान नहीं होते हैं: एन्कोडिंग के बारे में सोचे बिना एनकोडेड डेटा भेजें।

मुझे हार्डवेयर के साथ इंटरफेस करना पड़ा है जो अतीत में कच्चा XML भेजा था। XML वहाँ था सभी तैयार था। सौभाग्य से, <xml></xml>टैग द्वारा फ्रेम की सीमाओं का पता लगाना काफी आसान है । मेरे लिए बड़ी बात यह है कि यह फ्रेमिंग के लिए एक से अधिक बाइट का उपयोग करता है। साथ ही, फ़्रेमिंग स्वयं तय नहीं की जा सकती क्योंकि टैग में विशेषताएं हो सकती हैं: <tag foo="bar"></tag>इसलिए आपको फ्रेम की शुरुआत का पता लगाने के लिए सबसे खराब स्थिति के लिए बफर करना होगा।

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

Comments

टेक्स्ट एनकोडिंग के लिए, वहाँ भी base85 है , जिसमें 33% के बजाय केवल 25% ओवरहेड है।

— डेव ट्वीड

मैं इसे 4 वीं विधि का सबसेट / भिन्नता मानूंगा।

— यूजीन श।

@ यूजीनश: तकनीकी रूप से यह उप-विभाजन का उपसमूह है। फिर से जब से आप इसे बिट मार्किंग का सबसेट मानते हैं तो आप समझ सकते हैं कि यह अस्पष्टता इसे अपने आप में एक श्रेणी क्यों बनाती है। इसके अलावा, आप थोड़ा अंकन क्योंकि अंकन बिट्स (उदाहरण के लिए, मैं आमतौर पर उपयोग करें इस्तेमाल कभी नहीं कर रहे हैं के एक सबसेट के रूप में पाठ एन्कोडिंग के सबसे कार्यान्वयन पर विचार नहीं कर सकते <और >डिलीमीटर के रूप में और मेरा मानना है कि ईमेल का उपयोग करता है नई-पंक्तियों नोट:। हाँ, ईमेल एक ठीक से बनाए गए प्रारूप है RS232 के माध्यम से प्रेषित किया जा सकता है। मेरे एक दोस्त ने RS232 का उपयोग करके अपने घर के लिए एक मेल वितरण सर्वर चलाया)

— स्लीबेटमैन

Answer 5

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

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

Comments

त्रुटि सुधार कोड प्रश्न से थोड़ा हटकर हैं। उन्हें इनमें से किसी भी योजना में जोड़ा जाना चाहिए। "बैंड जानकारी से बाहर" जिसका आप जिक्र कर रहे हैं, वही "हार्डवेयर फ्लो कंट्रोल" है जो मुझे लगता है?

— यूजीन श।

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

— डेव ट्वीड

@DaveTweed ठीक है, यह बहुत ज्यादा है जो मैं पहली तकनीक से मतलब था। या मैं तुम्हें गलत समझ रहा हूं?

— यूजीन श।

नहीं, आप गलतफहमी में नहीं हैं; यही मैं बात कर रहा था। हालांकि, आपका "कोन" गलत है - यह विश्वसनीय है, और इसे वास्तविक ट्रांसमिशन त्रुटियों के संबंध में भी मजबूत बनाया जा सकता है।

— डेव ट्वीड

@DaveTweed पुनर्प्राप्ति समय के बारे में क्या? क्या आपके पास कोई उदाहरण है कि इसे कैसे मजबूत बनाया जा सकता है?

— यूजीन श।

Answer 6

एक अन्य विकल्प है जिसे लाइन कोडिंग के रूप में जाना जाता है । लाइन कोडिंग संकेत कुछ विद्युत विशेषताओं को देता है जो संचारित करना आसान बनाता है (डीसी संतुलित और अधिकतम रन लंबाई की गारंटी) और वे फ्रेमन और घड़ी सिंक्रनाइज़ेशन के लिए नियंत्रण वर्णों का समर्थन करते हैं। लाइन कोड सभी आधुनिक उच्च गति के सीरियल प्रोटोकॉल में उपयोग किए जाते हैं - 10M, 100M, 1G, और 10G ईथरनेट, सीरियल ATA, फायरवायर, USB 3, PCIe, आदि। कॉमन लाइन कोड 8b / 10b , 64b / 66b और 128b / 130b हैं।। ऐसे सरल रेखा कोड भी हैं जो केवल डीसी बैलेंस और क्लॉक सिंक की जानकारी नहीं देते हैं। इनके उदाहरण हैं माचस्टर और एनआरजेड। आप शायद 8b / 10b का उपयोग करना चाहते हैं यदि आप जल्दी से सिंक करना चाहते हैं; अन्य लाइन कोड जल्दी में सिंक करने के लिए डिज़ाइन नहीं किए गए हैं। ऊपर की पेशकश करने वाले एक लाइन कोड का उपयोग करके प्रेषित और प्राप्त करने के लिए कस्टम हार्डवेयर का उपयोग करना होगा।

आपके विकल्प 5 के लिए, मानक RS232 धारावाहिक ब्रेक भेजने और प्राप्त करने का समर्थन करने वाला है, जहां लाइन बाइट के समय के लिए बेकार है। हालाँकि, यह सभी सिस्टम पर समर्थित नहीं हो सकता है।

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

Comments

यह निक जॉनसन के जवाब के समान है।

— डेव ट्वीड