8-बिट माइक्रोकंट्रोलर पर वेबसाइट होस्ट करना

 (maurycyz.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • केवल AVR64DD32 8-बिट MCU से एक वेबसाइट होस्ट की गई, जो 24MHz CPU, 8KB RAM और 64KB Flash जैसे छोटे वातावरण में चलती है
  • सीधे Ethernet सिग्नल बनाना संभव नहीं था, क्योंकि 10BASE-T भी इसके लिए बहुत तेज़ है; इसलिए Linux द्वारा समर्थित SLIP का उपयोग कर USB-Serial लिंक को नेटवर्क इंटरफ़ेस की तरह इस्तेमाल किया गया
  • SLIP पैकेट को 0xC0 से घेरने और विशेष बाइट्स को escape करने का सरल तरीका है, इसलिए यह MCU और आधुनिक Linux को जोड़ने के लिए उपयुक्त है
  • fragmentation बंद होने की वजह से IP सरल हो गया, लेकिन TCP implementation में connection state, retransmission और exception handling की ज़रूरत पड़ी; इसे बनाने में कई दिन लगे और अभी भी bugs बाकी हैं
  • बाहरी access के लिए VPS, WireGuard और proxy का उपयोग कर केवल /mcu requests को forward करने वाली एक workaround संरचना बनाई गई, और public IPv4 की लागत व IPv6 की कमी मुख्य सीमाएँ बनकर सामने आईं

8-बिट AVR पर वेबसाइट होस्ट करने की संरचना

  • AVR64DD32 एक 8-बिट AVR परिवार का MCU है, जो Arduino में प्रसिद्ध Atmega328 जैसा है; समान memory के आधार पर यह सस्ता है और single programming pin व बेहतर peripherals देता है
    • अधिकतम 24MHz single 8-bit AVR core
    • 8KB static RAM, 64KB Flash, 256 byte EEPROM
    • 1.8~5.5V voltage range, $1~$2 की कीमत
  • MCU को अकेले सीधे इंटरनेट से जोड़ने के लिए Ethernet सिग्नल बनाना पड़ता, लेकिन सबसे धीमा 10BASE-T भी इस वातावरण के लिए बहुत तेज़ है
    • 10BASE-T 10Mbit/s पर चलता है, और Manchester encoding के कारण वास्तविक line rate 20Mbit हो जाता है
    • AVR64DD32 का CPU 24MHz तक जा सकता है, लेकिन peripherals और IO pins के लिए 12MHz clock ही अधिकतम है, इसलिए सीधे सिग्नल बनाना कठिन है
    • dedicated Ethernet chip का उपयोग करना सामान्य तरीका है, लेकिन इससे project पूरा करने के लिए कई हफ्ते इंतज़ार करना पड़ता
  • विकल्प के रूप में SLIP(Serial Line Internet Protocol, RFC 1055) का उपयोग कर serial link के ऊपर नेटवर्क चलाया गया
    • पैकेट की शुरुआत और अंत 0xC0 byte से घेरा जाता है
    • पैकेट के अंदर का 0xC0, 0xDB 0xDC में और मौजूदा 0xDB, 0xDB 0xDD में बदला जाता है ताकि ambiguity न रहे
    • यह उसी पुराने तरीके से जुड़ता है जिसमें dial-up modems फोन लाइन पर serial link बनाते थे और कंप्यूटर उसके ऊपर networking संभालता था
    • आधुनिक Linux भी SLIP को support करता है, इसलिए USB-Serial adapter को network interface बनाया जा सकता है
    • उदाहरण के तौर पर stty -F /dev/ttyUSB0 115200 raw cs8, slattach -m -F -L -p slip /dev/ttyUSB0 का उपयोग होता है
  • MCU पक्ष का hardware सरल है और बाहरी components के बिना भी काम करता है
    • www.c: source code
    • www.elf: prebuilt binary
    • LED और reverse power connection से बचाने के लिए diode जोड़ा गया है
    • power consumption कुछ mW के स्तर पर है, इसलिए केवल USB-Serial adapter की 5V rail से server चलाया जा सकता है

प्रोटोकॉल implementation और public access का प्रबंधन

  • आधुनिक वातावरण की सीमाओं की वजह से IP implementation अपेक्षाकृत सरल हो गई
    • किसी web page को उपयोगकर्ता के कंप्यूटर तक पहुँचने के लिए packets को कई networks से गुजरना पड़ता है, और हर packet में source व destination address जैसी जानकारी वाला 40-byte IP header चाहिए
    • पुराने IP में packet fragmentation जैसी सुविधाएँ थीं, जिनके कारण उसे सही ढंग से संभालने के लिए काफी memory चाहिए होती थी
    • आधुनिक operating systems fragmentation को बंद रखते हैं, और IPv6 ने fragmentation को हटा दिया है, इसलिए इसे सीधे संभालने की ज़रूरत नहीं पड़ती
    • आए हुए packet के source और destination को उलटकर तथा TTL counter reset करके response header बनाया जा सकता है
  • TCP implementation कहीं अधिक कठिन है, क्योंकि इसमें connection state tracking, lost packets का retransmission और कई exceptional situations को संभालना पड़ता है
    • custom TCP implementation को पर्याप्त रूप से चलने योग्य बनाने में कई दिन लगे, और अभी भी कुछ bugs बाकी हैं
    • HTTP को अलग से implement नहीं किया गया; server हमेशा client को hardcoded “response” भेजता है
    • यदि साइट में केवल एक ही URL हो, तो यह तरीका पर्याप्त रूप से काम करता है
    • loading process को Video 3 में देखा जा सकता है
  • बाहरी access के लिए publicly routable IPv4 address चाहिए, लेकिन लागत और घर के इंटरनेट connection की गुणवत्ता बाधा बनती है
    • publicly routable address वाला machine Helsinki के पास एक data center के VPS में है
    • Linux के WireGuard से इंटरनेट के ऊपर virtual network link बनाया गया, ताकि एक ओर CGNAT के पीछे होने पर भी यह काम करे
    • इस तरह Linux router box VPS से जुड़कर अधिक उपयुक्त इंटरनेट connection प्राप्त करता है
  • MCU के पास अब भी अपना public IP नहीं है, इसलिए VPS address पर आने वाली सभी requests आगे भेजने से मौजूदा website टूट जाती
    • इसके बजाय server को इस तरह configure किया गया कि वह केवल /mcu के नीचे आने वाली requests को local address block का उपयोग करके MCU server तक proxy करे
    • आगंतुक सीधे MCU के TCP/IP stack से नहीं जुड़ते, लेकिन यह Vape Server जैसी ही संरचना है
    • SYN packets से इसे बिगाड़ना थोड़ा कठिन हो जाता है, लेकिन वास्तव में यह लगभग dial-up जैसी link पर चलने वाला server है, इसलिए DDoS के प्रति कमजोर है
  • IPv6 की कमी इस पूरी workaround संरचना का मूल कारण बनी रहती है
    • IPv6 को आए 30 साल हो चुके हैं, फिर भी आज भी अधिकांश लोग उस तक पहुँच नहीं रखते
    • /mcu: MCU पर होस्ट किया गया पेज
    • http://ewaste.fka.wtf/: ई-कचरे से निकाले गए 32-बिट MCU पर होस्ट किया गया Vape Server
    • https://lcamtuf.substack.com/p/psa-if-youre-a-fan-of-atmega-try: AVR Dx लाइन पर lcamtuf का लेख

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News टिप्पणियाँ

  • 25 साल से भी पहले सबसे छोटा web server बनाने की शेखीबाज़ी वाली प्रतिस्पर्धा हुआ करती थी: https://web.archive.org/web/20000815063022/http://www-ccs.cs...
    ACE1101 microcontroller इस्तेमाल करने वाले ने “जीत” हासिल की थी, लेकिन मूल लेख नहीं मिल रहा, और यह भी है: https://conceptlab.com/fly/
    यह मक्खी पर चलने वाला web server था

    • ACE1101 version मैंने बनाया था, और pre-programmed chip डाक से Saskatoon के एक artist को भेजी थी. मूल विवरण अभी भी Archive.org पर बचा हुआ है: https://web.archive.org/web/20020605032321/http://d116.com/a...
      कोड को ठूँस-ठूँसकर छोटा करने की प्रक्रिया वाकई मज़ेदार थी, और ping हटाने पर bit-banged I2C और EEPROM में UDP upload के लिए जगह बन गई, फिर भी सब कुछ 1024 bytes से कम था
    • कुछ दिन पहले भी मुझे वह छोटा web server याद आया था और मैंने यहाँ भी पोस्ट किया था, लेकिन खास प्रतिक्रिया नहीं मिली. तब भी और अब भी, मुझे यह काफ़ी प्रभावशाली लगता है

  • मुझे AVR DD, EA, EB series पसंद हैं, लेकिन Microchip के हाल के chip releases AVR fans के लिए थोड़ा चिंताजनक लगते हैं: https://www.microchip.com/en-us/products/microcontrollers/32...
    PIC32 CM में event system, MVIO, 5V operation जैसी AVR DD की ज़्यादातर खूबियाँ हैं, और साथ में बड़ा, ज़्यादा standard ARM 32-bit M0+ core भी मिलता है
    इसी वजह से चिंता होती है कि AVR DD कुछ पुराना न पड़ जाए. AVR EA और AVR EB में 16x programmable gain वाला 12-bit ADC है, और थोड़ा noise होने के बावजूद यह लगभग 50 microvolts तक sensitive है, इसलिए यह बेहिसाब अच्छा ADC/current sensor होने के कारण सुरक्षित लगता है
    दूसरी ओर, इससे AVR family और लोकप्रिय भी हो सकती है. यह जानना दिलचस्प होगा कि pin-compatible ARM32 Cortex M0+ का होना AVR platform पर build करने की संभावना बढ़ाता है या घटाता है
    मेरी नज़र में peripherals सबसे ज़्यादा मायने रखते हैं. AVR DD शायद कम power consume करता हो, खासकर 1.8V operation में, लेकिन क्या सिर्फ इतना काफ़ी है, यह पता नहीं
    project खुद बहुत दिलचस्प है, और AVR DD वैसे भी शानदार chip है, इसलिए इसे वास्तव में इस्तेमाल होते देखना अच्छा लगा
    10BASE-T 10 megabits/second पर चलता है, और Manchester encoding की वजह से wire पर यह 20 megabits हो जाता है. AVR EB में x2 PLL timer है, इसलिए अगर लंबे समय तक इसमें हाथ डालें तो शायद यह Manchester encoding output कर सके
    LUT, UART peripherals, और PLL से तेज़ किए गए timer circuit को जोड़ें तो शायद high-speed Manchester encoding निकाली जा सके, लेकिन 20Mbit तक पहुँचेगा या नहीं, इस पर और सोचना होगा

    • Microchip के बारे में माना जाता है कि वह ज़्यादातर कंपनियों की तुलना में chips को लंबे समय तक support करता है. जब तक demand रहती है, वह उन्हें लगभग हमेशा बनाता रहता है, और Dx series भी काफ़ी हाल की product line है
      Cortex-M0 रास्ते के साथ प्रयोग करना शायद इस बात का संकेत हो कि वे Dx के बाद 8-bit platform की अगली पीढ़ी को विकसित करते रहना नहीं चाहते. अगर वही features किसी दूसरे CPU core पर ले जाए जाएँ, तो मुझे वह ठीक लगता है

  • पेज पर HTML को real time में stream होते हुए देखना अच्छा लगा. इससे पुराने dial-up दौर की याद आती है, जब images ऊपर से नीचे तक धीरे-धीरे render होती थीं

    • यादें ताज़ा हो गईं. स्कूल का घटिया dial-up, मेरे पिता के दफ़्तर के 128 ISDN की तुलना में, असहनीय रूप से धीमा था
      वहाँ FTP पर, और बाद में Napster पर, एक बार connect होकर कई गाने download किए जा सकते थे

  • शीर्षक देखकर मेरा पहला ख़याल था, “embedded/IoT devices में तो ऐसे बहुत से काम होते हैं”
    10/100 Ethernet built-in 8051 का एक उदाहरण है: https://www.asix.com.tw/public/index.php/en/product/Microcon...

  • दो बातें दिलचस्प लगीं. पहली, यहाँ के www.c में शामिल नहीं है, लेकिन RFC 1055 की 2025 errata मौजूद है. वह errata काफ़ी भरोसेमंद ढंग से दिखाती है कि decoding algorithm को कैसे बदलना चाहिए, और इस मामले में link के दूसरी तरफ वास्तव में Linux है
    दूसरी, अगला पड़ाव शायद RFC 1144 होगा

  • ENC28J60 + PIC18 वाला setup ठीक यही काम करता था, 20 साल पहले Microchip के आम demo distributions में

  • यह अच्छा लगा कि proxy ने पेज के server: header को overwrite नहीं किया

  • मैंने पहले Arduino Mega से कुछ ऐसा ही बनाया था. हैरानी की बात यह थी कि client बहुत सारा काम कर देता है, इसलिए यह काफ़ी भरोसेमंद दिख सकता है, जबकि controller बस uSD card से content serve कर रहा होता है