लोग माइक्रोकंट्रोलर पर वेब सर्वर क्यों बनाते हैं?


13

मैं माइक्रोकंट्रोलर्स का उपयोग करके वेब सर्वर बनाने वाले लोगों के सामने आया हूं, कोई ऐसा क्यों करेगा? इसके अनुप्रयोग क्या हैं? ऐसे सर्वर बनाने के लिए C भाषा के अलावा क्या कौशल निर्धारित किया जाता है? मैं इन छोटे सर्वरों के बारे में काफी उत्सुक हूं जिनके पास ऐसी छोटी रैम है।


यह प्रश्न बहुत व्यापक है, कृपया किसी विशिष्ट तकनीकी प्रश्न पर ध्यान केंद्रित करने का प्रयास करें।
कोरटुक

10
फिर से मतदान करना। यह सवाल काफी अच्छा है।
निक एलेक्सीव

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

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

@ क्वांटम 231 कृपया एक ताजा प्रश्न पूछें यदि आपके पास एक ताजा प्रश्न है। :-)
अनिंदो घोष

जवाबों:


15

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

एक HTTP सर्वर का बड़ा फायदा यह है कि अंतिम उपयोगकर्ता के लिए एक उचित यूजर इंटरफेस प्रस्तुत करने के लिए किसी विशेष हार्डवेयर या सॉफ्टवेयर की आवश्यकता नहीं होती है। सभी के पास पहले से एक वेब ब्राउज़र है, इसलिए यह ग्राहक के लिए कोई परेशान नहीं है। अन्य विकल्पों के बारे में सोचें। आप एक RS-232 पोर्ट प्रदान कर सकते हैं, लेकिन फिर आपको या तो एक कस्टम ऐप प्रदान करना होगा या किसी को समझाना होगा कि सही बॉड रेट के साथ टर्मिनल प्रोग्राम कैसे सेट किया जाए, बिट्स, स्टॉप बिट्स, और पैरिटी। आपको या तो एक केबल की आपूर्ति करनी होगी या आशा है कि ग्राहक के पास एक है, और किसी को इकाई में जाना है और इसे भौतिक रूप से कनेक्ट करना है। USB में समान कॉन्फ़िगरेशन समस्या नहीं है, लेकिन आम तौर पर उत्पाद में एक पूरी तरह से अलग माइक्रो का मतलब होगा और ग्राहक को जो भी प्लेटफॉर्म हो सकता है, उस पर चलने के लिए आपको एक कस्टम प्रोग्राम की आवश्यकता है।

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

अब तक मैंने इन सभी मामलों में PIC 18 का उपयोग किया है। जबकि कम है तो 4 kbytes RAM एक सीमा है, अभी भी बहुत कुछ है जो आप कर सकते हैं। ROM स्थान भी किसी समस्या के करीब नहीं है। PIC 18 के लिए मेरा नेटवर्क स्टैक ( www.embedinc.com/pic/dload.htm पर मेरे PIC डेवलपमेंट टूल्स रिलीज़ में उपलब्ध है ) 18F67J60 के ROM स्पेस का केवल एक छोटा सा हिस्सा लेता है, जो इस तरह की चीजों के लिए एक अच्छा हिस्सा है इसमें एक पूर्ण ईथरनेट मैक / PHY बनाया गया है। एक मामले में मेरे पास है कि PIC एक साथ 6 टीसीपी कनेक्शन के लिए सर्वर है। यह वास्तव में इतना भारी नहीं है जितना लोग सोचते हैं।


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

सूचना: मैंने "install_picdev.exe" डाउनलोड करने की कोशिश की, लेकिन फ़ायरफ़ॉक्स (या विंडोज सुरक्षा अनिवार्य) ने कहा कि यह मैलवेयर है। उसे खोलने वाला नहीं।
आहोजन

14

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

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

आगे की अंतर्दृष्टि के लिए, कोई भी " इंटरनेट ऑफ थिंग्स " की खोज कर सकता है और विचारों की विस्तृत श्रृंखला को देख सकता है जो लाता है।

" ऐसे छोटे रैम वाले छोटे सर्वर " के बारे में , यह ध्यान देने योग्य है कि HTTP प्रोटोकॉल बहुत कम रैम पर कार्यान्वयन योग्य होने के लिए काफी सरल है, जिसमें बहुत कम प्रसंस्करण शक्ति होती है। इसके अलावा, आज के माइक्रोकंट्रोलर की तुलना में, या कुछ मामलों में अधिक शक्तिशाली हैं, प्रारंभिक व्यक्तिगत कंप्यूटरों पर प्रोसेसर, जिस पर लोगों ने न केवल वेब को लागू किया है, बल्कि विभिन्न इंटरैक्टिव कार्यों को भी किया है, यहां तक ​​कि खेल भी खेले हैं।


अच्छा उत्तर। अनुप्रयोगों के बारे में मुझे कुछ सामान्य उपभोक्ता इलेक्ट्रॉनिक्स का उल्लेख याद आता है जिन्हें अक्सर ब्राउज़र का उपयोग करके भी एक्सेस और कॉन्फ़िगर किया जा सकता है। प्रिंटर, टीवी सेट, होम सिनेमा ऑडियो रिसीवर्स, राउटर ... मैं शर्त लगाता हूं कि यहां तक ​​कि दूर से सुलभ कॉफी मशीनें भी हैं :) EDIT: दी, उनमें से कुछ के पास आधुनिक पीसी की प्रोसेसिंग पावर है और वे माइक्रो कंट्रोलर आधारित नहीं हैं।
Rev1.0

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

4

कई नेटवर्क डिवाइस कॉन्फ़िगरेशन मापदंडों की जांच और सेटिंग के लिए एक वेब सर्वर प्रदान करते हैं, डिवाइस की स्थिति की जांच कर रहे हैं। उदाहरण के लिए, मैं अपने ब्राउज़र को इंगित करके अपने सिस्टम में राउटर को कॉन्फ़िगर कर सकता हूं http:///192.168.0.254(यदि मुझे सही याद है ...)।


3
  1. क्योंकि वे कर सकते हैं।

  2. क्योंकि वे बहुत कम शक्ति वाले हो सकते हैं। जैसे 1W अंडर कुछ पीक ड्रॉ। आधा amp के तहत। बड़े कंप्यूटरों के विपरीत, बैटरी और सौर ऊर्जा व्यावहारिक है।

  3. भौतिक आकार। एक माइक्रोकंट्रोलर + वाईफ़ाई या ईथरनेट चिप एक अंगूठे ड्राइव का आकार हो सकता है।

  4. लागत। इसके लिए उपयुक्त एक माइक्रोकंट्रोलर एकल डॉलर रेंज में हो सकता है। नेटवर्किंग के हिस्से लगभग सस्ते हैं।

  5. डिस्पोजेबल। आप उन्हें एक बंद परियोजनाओं में रख सकते हैं और यदि वे मर जाते हैं, तो यह उतना बुरा नहीं है जितना कि एक महंगा कंप्यूटर करता है।

  6. बस इसीलिये।

दसियों डॉलर (100 डॉलर से मुक्त) के लिए पूर्ण विकसित कंप्यूटरों के आगमन के साथ (श्रेवप्लग, रास्पबेरी पाई, स्मार्टफ़ोन, लिनक्स अंगूठे ड्राइव, एंड्रॉइड स्टिक, रोटर), आप शायद भविष्य में माइक्रोट्रोलर वेब सर्वरों में कम देखेंगे, क्योंकि वहाँ है अब ड्राइविंग कारक के रूप में COST और आकार नहीं है। एक 35 डॉलर रास्पबेरी पाई या 45 डॉलर बीगलबोन लागत, प्रदर्शन, सेटअप में आसानी के लिए एक Arduino + ईथरनेट या वाईफ़ाई ढाल को बेहतर बना सकता है। यह आर्डिनो से बमुश्किल बड़ा है। केवल बात यह है कि arduino यह कर सकते हैं बिजली दक्षता 0.1W (0.5mA से 50 mA नींद पूर्ण कंप्यूटिंग शक्ति [5v, 16mhz, 100% सीपीयू] ATMEGA द्वारा अकेले) बनाम 4W RPI के लिए बिना ईथरनेट / hdmi / usb बेकार में उपयोग।

इसलिए माइक्रोकंट्रोलर वेब्सवर्कर्स कम चालू खपत के कारण बैटरी चालित हो सकते हैं। फिर भी, एक वेबसर्वर के साथ पॉकेट राउटर जैसे कुछ नए लिनक्स एसओसी उनके करीब हो सकते हैं।


माइक्रोकंट्रोलर्स के टेक्सास इंस्ट्रूमेंट्स MSP430 परिवार पर भी विचार करें: वेब की सेवा के लिए अत्यधिक कम बिजली की खपत और पर्याप्त क्षमता। 16 बिट प्रसंस्करण। कुछ विकल्पों में बॉक्स से बाहर वायरलेस नेटवर्किंग शामिल है। आकार: वायरलेस कनेक्टिविटी के साथ एक पूर्ण बोर्ड एक अंगूठे ड्राइव में फिट हो सकता है।
अनिंद घोष

ये उत्तर प्रश्न के केवल एक भाग का उत्तर देते हैं। यह हम क्यों करते है? अगले भाग के बारे में क्या; हम यह कैसे करते हैं? क्या कौशल सेट की आवश्यकता है?
अंशुल

1
@Anshul आपको http सर्वर विनिर्देशन को कोड करने की आवश्यकता है, और आपको एक नेटवर्क स्टैक (IP / tcp / udp) या समान की आवश्यकता है, जिसके आधार पर आप जिस नेटवर्क IC को चुनते हैं।
राहगीर

2

ओलिन का जवाब हर कारण से बहुत हिट होता है मैंने एक एम्बेडेड वेब सर्वर का उपयोग किया है। मैं औद्योगिक नियंत्रण विकसित करने का काम करता हूं और हमारे द्वारा उत्पादित लगभग हर उत्पाद में एक एम्बेडेड वेब सर्वर होता है।

अधिकांश ग्राहकों के पास विभिन्न कारणों से पहले से ही उनके नेटवर्क पर उनके सभी उपकरण होंगे। इसलिए दर्जनों कस्टम प्रोग्राम इंस्टॉल करने के बजाय वेब ब्राउज़र के माध्यम से इसे कॉन्फ़िगर और / या नियंत्रित करने में सक्षम होना अत्यधिक वांछनीय है।

भले ही वे PROFINET जैसे औद्योगिक प्रोटोकॉल का उपयोग कर रहे हों , भौतिक परत उनके ईथरनेट के बाकी हिस्सों की तरह ही है और फिर उन्हें दर्जनों मशीनों को नियंत्रित करने के लिए केवल एक टुकड़ा सॉफ्टवेयर (PROFINET IO पर्यवेक्षक) की आवश्यकता होती है। मेरे अनुभव में, यह सेट अप कई उद्योगों में काफी मानक है।

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

वेब चिप वेब केबल

सॉफ्टवेयर

मूल सॉफ़्टवेयर के लिए कुछ कोड आँकड़े। मैं मूल रूप से ऑन-चिप 64 बाइट "डेटा इप्रोम" को योग में शामिल करना भूल गया था, जिसके कारण टीबीटीएफ पर 1010 बाइट्स आंकड़ा उद्धृत किया गया था।

Startup       36 bytes
Serial       179
SLIP          91
IP           144
ICMP          47
TCP          188
Checksum     132
Application  257
Total       1074 bytes

Comprising:
  454 instructions
  912 instruction bytes
  162 data bytes
 2.01 bytes/instruction average

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

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


2

चुनौती के लिए कारणों में से एक है। अधिक यदि आप माइक्रोकंट्रोलर बोर्ड विकसित करते हैं और / या अपना खुद का सॉफ़्टवेयर लिखते हैं।


3
यह शायद ही कोई चुनौती है। आप डेमो डाउनलोड कर सकते हैं जिसमें एक वेब सर्वर बनाया गया है।
ओलिन लेट्रोप

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