कई माइक्रोकंट्रोलर के बीच संचार

Question

मैं एन माइक्रोकंट्रोलर्स (एन> = 2 एमसीयू) से मिलकर एक प्रणाली को लागू करना शुरू करना चाहता हूं, लेकिन मैं उन्हें एक दूसरे के साथ संवाद करने की संभावनाओं को जानना चाहूंगा।

आदर्श रूप से, (N-1) माइक्रोकंट्रोलर्स को घर के अंदर ग्राहकों के रूप में काम करने के लिए रखा जाता है, जबकि अंतिम ("सर्वर") एक USB के माध्यम से एक पीसी से जुड़ा होता है। मेरे पास अभी जो समस्याएं हैं, उन्हें इन (एन -1) माइक्रोकंट्रोलरों को "सर्वर" से कैसे जोड़ा जाए। क्लाइंट MCUs बहुत सरल कार्य करते हैं, इसलिए एआरएम का उपयोग करने के लिए यह एक अच्छा समाधान नहीं हो सकता है कि वे ऐसे सरल कार्य करें क्योंकि वे CAN / PHY-MAC प्रदान करते हैं ।

अधिकांश उपकरणों के लिए और दूसरों की मांग पर संचार हर कुछ मिनटों में एक बार से अधिक नहीं होगा। गति बहुत महत्वपूर्ण नहीं है (संदेश छोटा है): 1 Mbit / s मुझे लगता है कि मेरे उद्देश्यों के लिए WAY ओवरकिल है।

जिन MCU का उपयोग करने की मेरी योजना है, वे निम्नलिखित हैं।

• Atmel AVR टिनी / मेगा
• TI MSP430
• एआरएम कोर्टेक्स एम 3 / एम 4
• (संभवतः Atmel AVR UC3 - 32-बिट)

अगर संभव हो तो (व्यक्तिगत पसंद), मैं PIC से बचना चाहूंगा , क्योंकि उन्हें प्रोग्राम करने की संभावनाएं कम हैं (उपरोक्त सभी में अधिक या कम ओपन सोर्स टूल के साथ-साथ कुछ आधिकारिक टूल भी हैं)।

मुझे पता है कि कुछ एआरएम कैन को कार्यक्षमता प्रदान कर सकते हैं और दूसरों के बारे में इतना निश्चित नहीं हूं।

अभी मैं इन संभावनाओं के साथ आया हूं:

1. साधारण GPIO डेटा भेजने के लिए (संदेश के प्रारंभ को इंगित करने के लिए उच्च पर 16 बिट्स,> संदेश के अंत को इंगित करने के लिए कम से कम 16 बिट्स)। हालाँकि, यह सभी बिट्स का पता लगाने में सक्षम होने के लिए एक मानक आवृत्ति << (frequency_client, frequency_server) पर होना चाहिए। केवल एक केबल प्रति क्लाइंट MCU की आवश्यकता है।
2. RS-232 : मुझे लगता है कि यह अब तक का सबसे अधिक इस्तेमाल किया जाने वाला संचार प्रोटोकॉल है, लेकिन मुझे नहीं पता कि यह कितना अच्छा है। मैं अभी 64 क्लाइंट MCUs पर विचार कर रहा हूं (शायद बाद में)
3. USB: AFAIK यह ज्यादातर RS-232 की तरह है, लेकिन मुझे नहीं लगता कि यह इस मामले में बहुत अच्छी तरह से मापता है (हालाँकि USB बहुत सारे उपकरणों का समर्थन करता है - 255 अगर मुझे सही याद है - यह इस एप्लिकेशन के लिए अत्यधिक जटिल हो सकता है)
4. RJ45 / ईथरनेट: यह वह है जिसे मैं वास्तव में उपयोग करना पसंद करूंगा, क्योंकि यह एक समस्या के बिना लंबी दूरी पर संचरण की अनुमति देता है (कम से कम परिरक्षित> कैट 6 केबल)। समस्या लागत (PHY, MAC, ट्रांसफार्मर, ...) है। मैं नहीं जानता कि क्या आप वास्तव में घर पर इसे अच्छी तरह से मिलाप कर सकते हैं। इस तरह मुझे एक क्लाइंट MCU की आवश्यकता नहीं होगी
5. वायरलेस / ZigBee : मॉड्यूल बहुत महंगे हैं, हालांकि यह डेस्क के पीछे "स्पेगेटी" से बचने के लिए जाने का तरीका हो सकता है
6. आरएफ मॉड्यूल / ट्रांसीवर: मैं 300 मेगाहर्ट्ज - 1 गीगाहर्ट्ज बैंड में उन लोगों की बात कर रहा हूं, इसलिए उन्हें घर पर सोल्डर करना मुश्किल होना चाहिए। मॉड्यूल सभी बिल्ट-इन हैं, लेकिन वे ZigBee के रूप में काफी महंगे हैं (कम से कम RF के मॉड्यूल Mouser पर, स्पार्कफुन में सस्ते होते हैं)।
7. कर सकते हैं? यह बहुत मजबूत लग रहा है। भले ही मैं इसे मोटर वाहन अनुप्रयोगों में उपयोग करने की योजना नहीं करता, फिर भी यह एक अच्छा विकल्प हो सकता है।
8. I / C / SPI / UART ? फिर - यदि संभव हो तो केबलों के साथ "स्पेगेटी" से बेहतर बचें
9. पीएलसी वास्तव में एक विकल्प नहीं हैं। लंबाई बढ़ने के साथ प्रदर्शन बहुत तेजी से घटता है और पावर नेटवर्क के कैपेसिटेंस लोड पर निर्भर करता है। मुझे लगता है कि मूल्य-वार ईथरनेट के समान है।

इसके अलावा, कौन सा प्रोटोकॉल एक साथ प्रसारण के मामले में "बेहतर" होगा (चलो दुर्लभ मामला मान लें कि बहुत ही तत्काल दो उपकरणों पर प्रसारण शुरू होता है: कौन सा प्रोटोकॉल सर्वोत्तम "संघर्ष प्रबंधन प्रणाली" / "टक्कर प्रबंधन प्रणाली" प्रदान करता है?

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

समाधान मैं अभी इमेजिंग कर रहा हूं, GPIO या RS-232 ( सस्ते !) द्वारा MCUs के पास बुनियादी संचार करना होगा और सर्वर ( महंगा) के साथ संवाद करने के लिए "MCU" पर एक MCU प्रति ईथरनेट / ZigBee / Wi-Fi का उपयोग करना होगा , लेकिन यह अभी भी प्रत्येक क्लाइंट MCU प्रति एक ईथरनेट मॉड्यूल से बहुत सस्ता है)।

केबलों के बजाय फाइबर ऑप्टिक / ऑप्टिकल फाइबर का उपयोग करना संभव हो सकता है। हालांकि अतिरिक्त रूपांतरण आवश्यक हैं, और मुझे यकीन नहीं है कि यह इस मामले में सबसे अच्छा समाधान होगा। मैं उन पर अतिरिक्त विवरण सुनना चाहूंगा।

Comments

CAN कार्यक्षमता वाले PIC हैं और प्रलेखन के साथ उन्हें प्रोग्राम करने के लिए मुफ्त आधिकारिक उपकरण हैं।

— आंद्रेजाको जू

@AndrejaKo PIC में वास्तव में AVRs या कम से कम MSP430s जैसे खुले स्रोत संकलक नहीं हैं। यह सच है कि वे अक्सर एक ही कीमत के लिए ऊपर सूचीबद्ध MCUs की तुलना में अधिक सुविधाएँ प्रदान करते हैं। मैं वास्तव में 12/16/18/24/32 परिवारों के बीच इन बड़े अंतरों को पसंद नहीं करता हूं और उनमें से कुछ में मुफ्त कंपाइलर नहीं है (मुझे लगता है कि यह PIC18 है)।

— user51166

वास्तव में PIC18 में ग्रिड कंपाइलर होते हैं और इसलिए दूसरे करते हैं। अन्य परिवारों का मुख्य बोनस यह है कि वे जीसीसी के साथ काम करते हैं। ओपन सोर्स कैंप में, स्मॉल डिवाइस C कंपाइलर है जो PIC 16 और PIC 18 डिवाइस को सपोर्ट करना चाहिए।

— आंद्रेजाको

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

— ओली ग्लेसर

@OliGlaser खैर ... जबकि यह सच है कि एआरएम के लिए ओपन सोर्स टूल्स का उपयोग करना थोड़ा मुश्किल हो सकता है (मैंने एक एसटीएम 32 डिस्कवरी बोर्ड की कोशिश की है और यह बहुत अच्छी तरह से काम नहीं कर पाया है), कई विक्रेता एक आईडीई की पेशकश करते हैं जो है - साथ इसके पेशेवरों और विपक्ष - ग्रहण आधारित और मुफ्त-सीमित: LPCXpresso (NXP) और कोड संगीतकार स्टूडियो (TI) उदाहरण के लिए (खुले-स्रोत नहीं हैं, लेकिन वे कम से कम समर्थित हैं)। AVRs दूसरी तरफ खुले स्रोत की ओर से समर्थित बहुत अच्छे हैं, साथ ही ATMEL स्टूडियो में भी हैं। तस्वीर जो कोई भी अनुभव नहीं है। केवल AVR (कोडांतरक) और ARM (C, NDS पर) को कोड किया गया।

— user51166

Answer 1

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

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

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

PIC से बचने के लिए आपके कारणों का कोई मतलब नहीं है। अपने स्वयं के निर्माण के लिए प्रोग्रामर के लिए कई डिजाइन हैं। एक मेरा LProg है , उस पृष्ठ के नीचे से योजनाबद्ध उपलब्ध है। हालाँकि, अपना खुद का निर्माण तब तक प्रभावी नहीं होगा जब तक कि आप पेनी / घंटा पर अपना समय न दें। यह भी सिर्फ प्रोग्रामर से अधिक के बारे में है। आपको डिबगिंग के साथ एड्स की आवश्यकता होगी। माइक्रोचिप पिकिट 2 या 3 बहुत कम लागत वाले प्रोग्रामर और डिबगर हैं। हालाँकि मुझे उनके साथ कोई व्यक्तिगत अनुभव नहीं है, फिर भी मैं दूसरों का नियमित उपयोग करके सुनता हूँ।

जोड़ा गया:

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

तो कर सकते हैं और रुपये -485 बहुत ज्यादा वैसा ही लाभ विद्युत है। CAN का बड़ा फायदा उस लेयर के ऊपर है। RS-485 के साथ उस परत के ऊपर कुछ भी नहीं है। आप अकेले है। एक प्रोटोकॉल डिजाइन करना संभव है जो बस मध्यस्थता, पैकेट सत्यापन, टाइमआउट, रिट्रीज, आदि से संबंधित है, लेकिन वास्तव में यह अधिकार प्राप्त करने के लिए अधिकांश लोगों की तुलना में बहुत अधिक मुश्किल है।

कैन प्रोटोकॉल पैकेट, चेकसम, टकराने की हैंडलिंग, रिट्रीज़ आदि को परिभाषित करता है। न केवल यह पहले से ही वहाँ है और सोचा और परीक्षण किया गया है, लेकिन वास्तव में बड़ा लाभ यह है कि यह कई माइक्रोकंट्रोलर पर सीधे सिलिकॉन में लागू किया जाता है। फर्मवेयर पैकेट भेजने और प्राप्त करने के स्तर पर CAN परिधीय में इंटरफेस करता है। भेजने के लिए, हार्डवेयर टकराव का पता लगाने, बैकऑफ, रिट्री और सीआरसी चेकसम जनरेशन करता है। प्राप्त करने के लिए, यह पैकेट का पता लगाने, घड़ी तिरछा समायोजन और सीआरसी चेकसम सत्यापन करता है। हाँ, कैन परिधीय एक UART की तुलना में ड्राइव करने के लिए अधिक फर्मवेयर लेगा, जैसे कि अक्सर RS-485 के साथ उपयोग किया जाता है, लेकिन यह समग्र रूप से बहुत कम कोड लेता है क्योंकि सिलिकॉन निम्न स्तर के प्रोटोकॉल विवरण का इतना संभाल करता है।

संक्षेप में, RS-485 एक बीते युग से है और आज नई प्रणालियों के लिए बहुत कम समझ में आता है। मुख्य मुद्दा ऐसे लोगों का लगता है जिन्होंने अतीत में आरएस -485 का इस्तेमाल किया था और सोच रहे थे कि कैन किसी तरह "जटिल" है। CAN का निम्न स्तर जटिल है, लेकिन कोई सक्षम RS-485 कार्यान्वयन है। ध्यान दें कि RS-485 पर आधारित कई प्रसिद्ध प्रोटोकॉल CAN के आधार पर नए संस्करणों द्वारा प्रतिस्थापित किए गए हैं। NMEA2000 ऐसे नए CAN- आधारित मानक का एक उदाहरण है। एक अन्य मोटर वाहन मानक J-J1708 (RS-485 पर आधारित) है जो CAN-OBD-II और J-1939 के साथ अब बहुत अप्रचलित है।

Comments

अपने स्वयं के कस्टम बोर्ड का निर्माण तब उपयोगी होता है जब MCU को उसके चारों ओर लगे हार्डवेयर के साथ एकीकृत किया जाता है। विकास के उद्देश्यों के लिए मैं मानता हूं कि एक विकास किट एक बेहतर तरीका है। PIC से बचने का मेरा कारण उनके ओपन सोर्स कंपाइलर्स की कमी है (कुछ मुफ्त हैं, लेकिन उदाहरण के लिए PIC18 के लिए नहीं) सार्वजनिक उपलब्ध योजनाबद्धताओं की कमी के बजाय, हालांकि वे कुछ अतिरिक्त सुविधाएँ प्रदान करते हैं जो आपको अन्य MCU में नहीं मिल सकती हैं (ईथरनेट, कर सकते हैं, ...)। और I2C एक बस AFAIK है।

— user51166

@ user51166 - माइक्रोचिप द्वारा प्रदान की गई मुफ्त PIC18 संकलक हैं। देखें MPLAB XC संकलनकर्ता उत्पाद पृष्ठ। यह 16bit और 32bit uC के लिए संकलक को भी सूचीबद्ध करता है।

— पेटपल्सेन

@ user51166 नि: शुल्क C18 संकलक भी है।

— आंद्रेजाको जूल

@PetPaulsen अजीब बात है। मुझे पूरा यकीन है कि मैंने एक महीने पहले एक पेज देखा था जो सभी कंपाइलरों को स्वतंत्र रूप से डाउनलोड करने के लिए उपलब्ध था (PIC16 / 24/32), PIC18 के अपवाद के साथ जो कुछ लाइसेंसिंग समस्या के कारण उनके पास नहीं था। संभवतः वह संक्रमण MPLAB C कंपाइलर -> MPLAB XC कंपाइलर से हल किया गया था, हालाँकि मुझे यकीन नहीं है। इसके अलावा वे "केवल" एक फ्रीवेयर संस्करण प्रदान करते हैं जो आपके कोड का अनुकूलन नहीं करता है, न कि पूरी तरह से खुला स्रोत संकलक। फिर भी यह कुछ भी नहीं से बेहतर है;)

— user51166

@user: मेरा मानना ​​है कि सभी माइक्रोचिप संकलक के मुक्त संस्करण हैं जो केवल पूर्ण से भिन्न होते हैं जिसमें कुछ अनुकूलन अक्षम हैं। कोडांतरक, लाइब्रेरियन, लिंकर और सिम्युलेटर सभी मुफ्त MPLAB पैकेज में शामिल हैं। यहाँ वास्तव में कोई मुद्दा नहीं है।

— ओलिन लेट्रोप

Answer 2

मैं कैन के साथ नियंत्रक की सिफारिश करूंगा क्योंकि यह सुविधा नियंत्रक नेटवर्किंग उद्देश्य के लिए है।

RS232 को आसानी से लागू किया जा सकता है लेकिन यह वास्तविक चुनौतीपूर्ण होगा यदि आप 2 से अधिक नोड्स संचार को लागू करने का प्रयास करते हैं (क्योंकि यह इस उद्देश्य के लिए नहीं है)।

ईथरनेट एक मीठा विकल्प भी हो सकता है क्योंकि आपने कुछ होस्ट और क्लाइंट इंटरकनेक्ट का उल्लेख किया है जो ईथरनेट कार्यान्वयन के लिए स्वाभाविक है।

Comments

उदाहरण के लिए CAN पर ईथरनेट के फायदे क्या हैं? सस्ता शायद, लेकिन इसके अलावा और क्या?

— user51166

@ user51166 - कैन केवल सस्ता नहीं है, लेकिन बहुत सस्ता है। यह न केवल आसान है, बल्कि बहुत आसान है।

— Rocketmagnet

@Rocketmagnet: कृपया थोड़ा और समझाएं। ज्यादातर मामलों में आपको वैसे भी एक एकीकृत आईसी की आवश्यकता होती है (हालांकि PIC और ARM और अन्य; अक्सर CAN सुविधा को एकीकृत कर सकते हैं, वे थोड़े महंगे हैं)। देखने के एक हार्डवेयर बिंदु से मैं यह नहीं देखता कि यह बहुत सस्ता कैसे हो सकता है क्योंकि IC को 0.5-1.0 $ एक टुकड़े के लिए पाया जा सकता है। मुझे लगता है कि आप एक सॉफ्टवेयर दृष्टिकोण से आसान मतलब है, है ना? कैन की अधिकतम दूरी ~ 500 मीटर है जो निश्चित रूप से मेरे मामले में पर्याप्त है, लेकिन - बस जानकारी के लिए - क्या लंबी दूरी के लिए समान विकल्प होंगे (ऑप्टिक फाइबर शायद)?

— उपयोगकर्ता 51166

Answer 3

कई तारों का उपयोग करके RS-485 यहां अच्छी तरह से काम कर सकता है, अगर सभी उपकरणों के लिए एक ही लाइन तार करने की संभावना है।

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

Comments

बहुत लंबी दूरी के बारे में चिंता न करने के लिए, मैं इस समय 100 मीटर से अधिक की योजना नहीं बना रहा हूं।

— user51166

आज बीटीडब्ल्यू स्टैकएक्सचेंज को @ <यूजरनाम> क्यों स्वीकार नहीं करता है? हर बार जब मैं एक डाल देता हूं, तो यह पूरी तरह से डिलीट हो जाता है (न कि सिर्फ @ सिंबल) ...

— user51166

@ user51166 - उत्तर के निर्माता को स्वचालित रूप से सूचित किया जाता है, इसलिए "\ @ - शोर" स्वचालित रूप से हटा दिया जाता है। (मेरे My @ user51166 को हटाया नहीं गया था, क्योंकि आप इस उत्तर के निर्माता नहीं हैं)

— पेटेपल्सन

दिलचस्प बात यह है कि मुझे यहां किसी भी टिप्पणी के लिए सूचनाएं नहीं मिलीं।

— आंद्रेजाको जू

Answer 4

मैं मैनचेस्टर एनकोडिंग डेटा के साथ काम करने वाला RS-485 बस चुनूंगा ।

RS-485 क्योंकि:

• सस्ता है
• लागू करना आसान है
• लो पावर का उपयोग करता है
• लंबी दूरी (1200 मीटर तक) की अनुमति देता है
• उच्च डेटा दर (10 एमबीपीएस तक)
• हस्तक्षेप के लिए उच्च प्रतिरक्षा
• ऐसे ट्रांससेवर्स हैं जो एक ही बस में 256 उपकरणों तक की अनुमति देते हैं
• कम भाग की गिनती

मैनचेस्टर एन्कोडिंग क्योंकि:

• लागू करना आसान है
• सेल्फ सिंक्रोनाइज है

डेटा अखंडता के लिए संदेश में एक लंबाई और एक सीआरसी क्षेत्र शामिल हो सकता है।

CRC फ़ंक्शन का उदाहरण:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITऔर CRC_POLYसीआरसी की गणना करने के लिए उपयोग किए जाने वाले मनमाने मूल्य हैं।

लंबाई और CRC फ़ील्ड वाले संदेश का उदाहरण:

Comments

इस तरह के अच्छे ट्रांससीवर्स के लिए कोई सुझाव, संभवतः सस्ता है?

— user51166

इसके अलावा @AndrejaKo ने सुझाव दिया कि RS-485 संघर्ष समाधान प्रोटोकॉल की पेशकश नहीं करता है।

— user51166

ट्रांससीवर्स की पसंद उस वोल्टेज पर निर्भर करती है जिसका आप उपयोग करने का इरादा रखते हैं। संघर्ष रिज़ॉल्यूशन सीआरसी चेक, लाइन मॉनिटरिंग या दोनों के साथ सॉफ्टवेयर में बनाया जाना है।

— ब्रूनो फेरेरा

यदि आपके पास एक मास्टर है तो आप किसी प्रकार के पते को भी लागू कर सकते हैं, या आधारित ट्रांसमिशन को चालू कर सकते हैं।

— ब्रूनो फेरेरा

वास्तव में गुरु नहीं। बस "सर्वर" जो यूएसबी के माध्यम से पीसी के लिए एक इंटरफेस की तरह काम करता है। हालांकि ग्राहकों को स्वचालित रूप से उसे संदेश भेजना होगा ...

— user51166

Answer 5

मुझे अपनी पसंद, ईथरनेट, मेरी पसंद के साथ, तुलना कर सकते हैं।

आवश्यक घटक:

• ईथरनेट: RJ45 कनेक्टर, मैग्नेटिक्स, Phy चिप (जब तक MCU में एकीकृत नहीं किया जाता)। इसके अलावा स्विच और प्रत्येक नोड पर स्विच से एक केबल की आवश्यकता होती है। प्रत्येक पीसीबी को काफी कुछ कैपेसिटर और टर्मिनेटिंग रेसिस्टर्स की आवश्यकता होती है, संभवतः फेराइट्स भी। अच्छा पीसीबी डिजाइन की जरूरत है।
• कर सकते हैं: ट्रांसीवर चिप (सस्ते), किसी भी कनेक्टर, सस्ते केबल साइट के चारों ओर एक लूप में एक नोड से अगले तक हॉप कर सकते हैं। ट्रान्सीवर के लिए केवल एक संधारित्र की आवश्यकता है, और बस के प्रत्येक छोर पर एक समाप्ति रोकनेवाला है।

आप $ 1 माइक्रोकंट्रोलर के बारे में बात कर रहे हैं। MCU की तुलना में बस की लागत बहुत अधिक है। वास्तव में सस्ता है, यह जानने के लिए आपको प्रत्येक समाधान की कुल लागत को जोड़ना होगा। MCU, कनेक्टर्स, ट्रांससीवर्स, पैसिव कंपोनेंट्स, PCB, केबल्स आदि का खर्च जोड़ें।

Answer 6

NXP से LPC11C24 में tha CAN ट्रान्सीवर एकीकृत हो सकता है, और CANOpen ROM में समर्थित है (आपके 32 K डेटा फ्लैश को दूर नहीं खा रहा है)। LPCXpresso 11c24 बोर्ड 20 EUR है (DB9 कनेक्टर के लिए स्थान प्रदान किया गया है), इसलिए आप वास्तव में सिर्फ तार जोड़ते हैं :-)

Answer 7

इसी तरह के एक और सवाल का जवाब दें। दो माइक्रोकंट्रोलर के बीच कम लागत वाला सरल संचार

TLDR : कुछ उपयोग के मामलों में विशेष रूप से सस्ता लेकिन विश्वसनीय फिट नहीं है।

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

IO- लिंक अनुप्रयोगों के लिए मास्टर और डिवाइस समाधान

L6360   Master
L6362A  Device

जब आप इस तरह से एक समाधान पर विचार करेंगे:

1. सीमांत चिप्स पूरी तरह से संरक्षित हैं जो महत्वपूर्ण होगा यदि आपके पास प्रत्येक MCU एक अलग बोर्ड पर है और उजागर पिंस जैसे पेंच टर्मिनल के साथ काम कर रहा है।
   • विपरीत ध्रुवता
   • कट-ऑफ फ़ंक्शन के साथ ओवरलोड
   • ज्यादा तापमान
   • अंडरवॉल्टेज और ओवरवॉल्टेज
   • GND और VCC खुला तार
2. इंटरोऑपरेबिलिटी। अगर कोई और व्यक्ति दूसरी ओर को डिज़ाइन करने जा रहा है, तो उसे पता होना चाहिए कि आईओ-लिंक के माध्यम से डेटा को फ़नल करना है।
3. एकीकृत नियामक Vcc(in) 7~30v, Vdd(out) 3.3/5v

यह मेरे लिए दिलचस्प लग रहा था, इसलिए मैंने सोचा कि मैं इसे वहाँ रख दूँगा।

Answer 8

यह आपके एप्लिकेशन और आपके माइक्रोकंट्रोलर्स के पैमाने पर निर्भर करता है। आपने Atmel को छोटे / मेगा का उल्लेख किया है, वे काफी छोटे हैं। उनके मामले में I2C / SPI / UART का फायदा है कि वे हार्डवेयर में लागू होते हैं और इसलिए उपयोग में आसान होते हैं।

Comments

ठीक है, लेकिन यह ओपी की समस्या को कैसे संबोधित करता है? IIC एक बस है, लेकिन वास्तव में एक घर की तरह लंबी दूरी के लिए बिल्कुल भी अनुकूल नहीं है। यह सिंगल एंडेड है और अपेक्षाकृत उच्च प्रतिबाधा है। एसपीआई एक बस है, लेकिन एक एकल मास्टर द्वारा प्रत्येक डिवाइस के लिए एक अलग दास चयन लाइन के साथ नियंत्रित किया जाता है। आप प्रत्येक लाइन को लाइन ड्रायवर और रिसीवर के साथ एक अंतर जोड़ी के रूप में लागू कर सकते हैं, लेकिन आपके पास अभी भी बिंदु को चुनने के लिए दास को इंगित करने के लिए बिंदु है। UART सख्ती से इंगित करने वाला बिंदु है। यह स्पष्ट नहीं है कि आप ओपी की स्थिति में इनका उपयोग कैसे करना चाहते हैं।

— ओलिन लेथ्रोप