RP2040 पर RTOS की ओर बदलाव

 (blog.brixit.nl)
1 पॉइंट द्वारा GN⁺ 2024-07-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Raspberry Pi Pico आधारित वीडियो उपकरण कंट्रोलर में एक साथ कई काम की जरूरत बढ़ने लगी, और केवल pico-sdk तथा dual-core विभाजन से सॉफ़्टवेयर संरचना को संभालना मुश्किल हो गया
  • कंट्रोलर को RS-485 VISCA, Ethernet, 9 RGB बटन, joystick और display को साथ संभालना है, साथ ही DHCP, mDNS और UDP-आधारित ATEM protocol को भी प्रोसेस करना है
  • FreeRTOS में scheduler और task के बीच communication से कुछ implementation संभव हुआ, लेकिन printf रुक जाने की समस्या और hardware abstraction की कमी के कारण debugging और code reuse कठिन था
  • Apache NuttX ने shell, filesystem, /dev/i2c0 जैसे device abstraction और Kconfig configuration दी, लेकिन I2C समस्या बाद में configuration mistake निकली, इसलिए उस समय का काफी मूल्यांकन अमान्य हो सकता है
  • Zephyr में 5GB repository, SDK, board definitions और build complexity बाधा बने, और अंततः वही दिशा अधिक व्यावहारिक लगी कि FreeRTOS को ही आगे आजमाया जाए, क्योंकि उसे मौजूदा environment में सबसे सरल तरीके से जोड़ा जा सकता था

RTOS की जरूरत क्यों पड़ी

  • कई छोटे microcontroller project Raspberry Pi Pico board के आसपास बनाए जा रहे हैं
    • Pico में ठीक-ठाक SDK, सस्ता hardware और gdb/openocd debugging support होने से IDE integration आसान है
  • मौजूदा project कई video उपकरणों को नियंत्रित करने वाला एक hardware controller है
    • यह motor वाले 2 PTZ camera, 1 fixed camera और जुड़े हुए video switching उपकरण को नियंत्रित करता है
  • मौजूदा PTZ camera controller Marshall VS-PTC-200 जैसा दिखने वाला एक बिना-ब्रांड का panel है
    • कुछ साल पहले इसकी कीमत €650 थी, लेकिन बटन का feel और analog joystick की quality अच्छी नहीं है
    • कई बटन वर्तमान में इस्तेमाल हो रहे कैमरों पर काम नहीं करते, और यह security camera के लिए optimized लगता है
    • कैमरों से यह RS-485 bus के जरिए जुड़ा है
  • ATEM video switcher का नियंत्रण अभी केवल कंप्यूटर के software panel से किया जाता है
    • Blackmagic Design के hardware panel बहुत महंगे हैं

कंट्रोलर hardware की संरचना

  • न्यूनतम design में 9 बटन, एक joystick और user interface के लिए एक display रखा गया
  • 1 साल तक कई बार hardware design दोहराने के बाद PCB तैयार हुआ
    • 9 RGB बटन
    • Marshall clone panel में भी इस्तेमाल हुआ $10 joystick
    • PTZ camera से RS-485 पर बात करने के लिए TP8485E
    • Ethernet के जरिए video switcher से बात करने के लिए Wiznet W5500 module
  • board में संशोधन पूरे करने के बाद hardware के सारे हिस्से चलने लगे, लेकिन असली मुश्किल software में थी

जब केवल pico-sdk पर्याप्त नहीं रहा

  • पहले की RP2040 projects की तरह cmake project में pico-sdk लाकर शुरुआत की गई
  • काम करने लायक स्थिति बनाने के लिए Pico का दूसरा core Wiznet module को संभालने के लिए दिया गया और पहला core user interface I/O के लिए रखा गया
    • LED blink कराना और दूसरे core पर DHCP client चलाना संभव हुआ
    • लेकिन बाकी system बनाना इससे कहीं ज्यादा जटिल निकला
  • एक साथ संभाले जाने वाले काम बहुत तेजी से बढ़ने लगे
    • display पर कुछ हद तक smooth user interface draw करना
    • RS-485 interface से VISCA command भेजना
    • button input पर प्रतिक्रिया देना
    • कई connection सहित network stack को बनाए रखना
  • network पक्ष को अलग background task चाहिए था
    • standards-compliant DHCP support में expiry time track करना और lease बनाए रखने के लिए DHCP server से कभी-कभी बात करना शामिल है
    • mDNS की जरूरत ATEM video switcher का IP अपने आप खोजने के लिए है, और control panel की मौजूदगी announce करना भी अच्छा होगा
    • ATEM protocol सरल है, लेकिन कभी-कभी Wiznet module buffer size से बड़ा data मिलता है, और अगर UDP datagram transmission रुक जाए तो disconnect timeout बहुत छोटा है
  • ऐसी स्थिति में खुद और loop जोड़ते जाने के बजाय RTOS के जरिए कामों को बांटना ज्यादा उचित लगा

FreeRTOS: सरल, लेकिन abstraction की कमी

  • FreeRTOS तकनीकी रूप से pico-sdk में शामिल है, लेकिन tutorial एक नई copy download करने को कहते हैं, इसलिए वही किया गया
  • देखे गए RTOS में यह सबसे सरल लगा, और मुख्य रूप से scheduler तथा task के बीच communication देता है
    • xTaskCreate से task बनते हैं और vTaskStartScheduler से scheduler शुरू होता है
    • queue का उपयोग करके button state को LED task तक पहुंचाने जैसे IPC का उपयोग किया जा सकता है
  • कुछ दिनों के उपयोग के बाद codebase अभी वास्तविक functionality में छोटा होने के बावजूद कई task में बंट गया
    • buttonsTask: I2C GPIO expander को poll करके button input देखता है और button queue में message डालता है
    • ledTask: ledQueue message के आधार पर किसी खास button का RGB रंग सेट करता है
    • mainTask: button input के अनुसार project state update करने वाला main loop चलाता है
    • networkTask: Wiznet module से communication करता है
    • dhcpTask: network cable connect होने पर networkTask इसे बनाता है
    • mdnsTask: IP address मिलने के बाद dhcpTask इसे बनाता है
    • atemTask: mDNS को ATEM device से response मिलने पर बनाया जाता है
    • viscaTask: अभी कुछ नहीं करता, लेकिन RS-485 port पर data भेजना होगा
  • hardware अभी network पर दिखाई देने के अलावा कुछ नहीं कर रहा, फिर भी task की संख्या काफी हो गई
  • सबसे परेशान करने वाली बात यह थी कि printf हर बार रुकावट पैदा करता था
    • gdb debugger काम करता है, लेकिन DHCP traffic print करके देखने के लिए वह उपयुक्त नहीं है
  • FreeRTOS hardware abstraction नहीं देता, इसलिए अलग-अलग chip से बात करने के लिए लिखा गया code आसानी से reuse नहीं किया जा सकता
  • बाद में एक साफ FreeRTOS project बनाकर functionality को उसमें ले जाने की कोशिश की गई, लेकिन serial output के बिना अंधेरे में debugging करनी पड़ती, इसलिए दूसरे विकल्प देखे गए

Apache NuttX: Unix-जैसी संरचना और configuration गलती

  • Apache NuttX एक सामान्य operating system के ज्यादा करीब लगा, और microcontroller को Unix system की तरह मानता है
  • tutorial में pico-sdk लाने और environment variable set करने को कहा गया
    • SDK पहले से /usr/share में था और environment variable भी set थे, लेकिन NuttX ने pico-sdk की version.h file को overwrite करने की कोशिश की, जिससे permission issue के कारण build fail हो गया
  • न्यूनतम NuttX firmware build करने के बाद serial port से जुड़ने पर सचमुच shell दिखाई दिया
    • uptime, uname, uname -a जैसे command काम करते हैं
    • दिखाया गया version NuttX 12.5.1 था और target arm raspberrypi-pico था
  • Unix तरीके के कारण लगा कि application लिखकर boot पर auto-run कराया जा सकता है
    • filesystem है और hardware /dev/i2c0, /dev/adc0 जैसे abstraction के रूप में दिखता है
  • जो हिस्सा पसंद आया, वह menuconfig/Kconfig आधारित configuration था
    • Linux development में यह परिचित तरीका है
    • इसमें वास्तविक hardware driver system है, और बटन में इस्तेमाल हुए GPIO expander chip का driver भी पहले से मौजूद है
    • RP2040 pin mux setting भी menuconfig में की जा सकती है, इसलिए pin number constants अलग से रखने या I2C bus initialization code बहुत लिखने की जरूरत नहीं होती
    • I2C test utility भी firmware में शामिल की जा सकती है
  • शुरुआत में लगा कि I2C की बुनियादी functionality काम नहीं कर रही
    • बाद के update में स्पष्ट किया गया कि असल में वह ठीक काम कर रही थी, और configuration mistake की वजह से I2C bus खराब हुई थी
    • यह भी कहा गया कि NuttX वाले उस हिस्से का बाकी मूल्यांकन संभवतः अधिकतर अमान्य है
  • उस समय यह समझ नहीं आया कि NuttX को कैसे बताया जाए कि GPIO button, GPIO expander के पीछे हैं, और GPIO expander को I2C bus से कैसे जोड़ा जाए
  • configure.sh fail होने के बाद repository असंगत स्थिति में चली जाती थी, इसलिए NuttX repository को कई बार दोबारा clone करना पड़ा
    • distclean भी इसी वजह से कभी-कभी ठीक से काम नहीं करता था
  • Unix-like approach शुरू में अच्छी लगी, लेकिन microcontroller पर नकली filesystem path के साथ काम करने की इच्छा नहीं थी
    • production system में shell की भी जरूरत नहीं है, बस code चलना चाहिए

Zephyr: बड़ा SDK और board definition की बाधा

  • अगला विकल्प Zephyr था, जो project setup के लिए Python utility देता है
  • पहले ही कदम पर लगभग 5GB की Git repository डाउनलोड हुई
    • इसमें कई chip के लिए HAL library शामिल हैं
    • यह user की global cmake settings को भी प्रभावित करती है
  • tutorial में Zephyr SDK install करने को कहा गया
    • Zephyr SDK में supported architecture के लिए toolchain, compiler, assembler, linker और build tools शामिल हैं
    • QEMU और OpenOCD जैसे host tools भी शामिल हैं
  • पहले से कई ARM toolchain होने के कारण हर architecture के लिए compiler build करना या prebuilt package लाना नहीं चाहा गया
  • Zephyr SDK के बिना build करने के लिए cross compile option set किए गए
    • ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
    • CROSS_COMPILE=/usr/bin/arm-none-eabi-
    • west build -p always -b sparkfun_pro_micro_rp2040 samples/basic/blinky
  • Raspberry Pi Pico वास्तव में supported नहीं है, केवल वही SoC इस्तेमाल करने वाले दूसरे board supported हैं
    • उसी SoC के कारण इसे व्यवहारिक रूप से समान board मानकर आगे बढ़ा गया
  • तुरंत ही blinky demo build न होने की समस्या आई
    • demo को blink करने के लिए led0 definition चाहिए होती है
    • Sparkfun Pro Micro RP2040 में साधारण GPIO LED नहीं, बल्कि WS2812B addressable LED है
  • custom board manual के अनुसार दूसरे board definition की copy बनाकर आगे बढ़ा गया, लेकिन build error और warning ठीक करने के बाद भी target board के लिए सफल build नहीं हो पाया

अंत में फिर FreeRTOS पर वापसी

  • तीनों RTOS में वास्तविक application का कुछ हिस्सा बन पाने वाला केवल FreeRTOS था
  • printf समस्या शायद online guidance के अनुसार कोई दूसरा printf implementation लगाकर और जरूरत वाली जगहों पर अलग function call करके सुलझानी होगी
  • आगे की योजना FreeRTOS को ही जारी रखने की है
    • क्योंकि दूसरे RTOS की तरह development environment को RTOS के हिसाब से ढालने के बजाय, इसे मौजूदा environment में अपेक्षाकृत सरल तरीके से integrate किया जा सकता था

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

1 टिप्पणियां

 
GN⁺ 2024-07-07
Hacker News टिप्पणियां

  • लगता है लेखक ने RTOS को Arduino environment जैसा समझा, या ऐसी चीज़ माना जिसे बस थोड़ा छेड़कर चलने की उम्मीद की जा सकती है। ज़्यादातर मामलों में ऐसा नहीं होता
    आजकल कई Arduino के अंदर mbed या FreeRTOS लगा होता है और उसे expose करने के तरीके भी हैं, इसलिए लेखक की style के लिए शायद वही बेहतर होता
    Zephyr इस्तेमाल में आसान है और CLion support भी अच्छा है, लेकिन toolchain install किए बिना सब कुछ चलने की उम्मीद नहीं कर सकते। Pi Pico को भी निश्चित रूप से support करता है, और मैंने खुद इस्तेमाल किया तो कोई समस्या नहीं आई
    संक्षेप में कहें तो FreeRTOS लगभग हर जगह support होता है, लेकिन drivers आम तौर पर SoC/device-specific होते हैं, इसलिए झंझट है; API भी बहुत friendly नहीं है, पर इसकी आदत पड़ सकती है। Bluetooth इस्तेमाल करना हो तो stack खुद ढूंढना पड़ेगा
    Zephyr असली hardware abstraction support करता है और ज़्यादातर SoC support करता है, लेकिन board पर थोड़ा काम करना पड़ सकता है। Bluetooth stack दिया जाता है और HCI support थोड़ा जोड़ना पड़ सकता है
    NuttX का support शानदार नहीं है, लेकिन अगर आप उसे चलवा सकें तो यह काफ़ी बढ़िया विकल्प है। Industry support अभी मजबूत नहीं है। mbed भी है, लेकिन यहां उसे छोड़ रहा हूं
    असली RTOS वाली दुनिया में आम तौर पर वही चुना जाता है जिसे SoC vendor support करता है। जैसे Nordic हो तो Zephyr, NXP हो तो FreeRTOS; ऐसा करने पर support बेहतर मिलता है

    • जल्दी से पूछूं तो, क्या आप prototyping board के लिए develop कर रहे हैं या OEM device firmware बना रहे हैं?
      OEM device के firmware projects में मैंने developers को Zephyr से जूझे बिना काम करते कभी नहीं देखा। Released product का असली firmware बनाने वाले developers में भी अभी तक ऐसा कोई नहीं मिला जिसे लगे कि Zephyr का hardware abstraction मददगार है
      इसका मतलब यह नहीं कि ऐसे लोग हैं ही नहीं, लेकिन पिछले करीब 5 सालों में मेरा सामना उनसे नहीं हुआ
    • “Zephyr इस्तेमाल में आसान है” यह मेरे अनुभव से अलग है
      मेरी नज़र में Zephyr की marketing material बहुत सुंदर है। लेकिन उस चमक-दमक के पीछे बहुत ज़्यादा bloat, बहुत धीमा compile, और शुरुआत करने में मुश्किल environment है
    • mbed को क्यों छोड़ दिया? वही तो इसका “सबसे अच्छा” हिस्सा है

  • पारंपरिक UNIX तरीके की तरह toolchain को पूरे system में install करना दर्दनाक है, और सच कहूं तो बहुत समझदार approach भी नहीं है
    अगर अकेले सब ठीक चले तो अच्छा है, लेकिन कई developers जब अलग-अलग targets वाले projects पर काम करते हैं, तो build और configuration issues समझने में बहुत समय चला जाता है
    Tools में लगातार Python इस्तेमाल करना भी मदद नहीं करता। अपनी version problems लेकर आने वाली और हर developer की machine पर अलग तरह से behave करने वाली language को आखिर क्यों इस्तेमाल करना चाहेंगे, समझ नहीं आता
    Embedded development को hobby और job दोनों रूप में करीब 10 साल किया है, और किसी project में सबका environment एक जैसा करने में एक हफ्ता खर्च करने के बाद भी इसे समस्या न मानने वाला रवैया मुझे समझ नहीं आता
    यह सचमुच की समस्या है, irritate करती है, समय बर्बाद करती है, और अनावश्यक है
    Tools statically linked binaries होने चाहिए। वे Rust, Go, C, C++ किसी में भी लिखे हों, फर्क नहीं पड़ता, लेकिन मैं temporary workaround वाली development के बजाय ऐसे मजबूत tools को प्राथमिकता देना चाहूंगा जिन पर भरोसा हो कि वे computer पर installed चीज़ों से स्वतंत्र होकर एक ही तरह काम करेंगे
    Python यह नहीं कर पाता, और इस issue को ज़्यादा गंभीरता से लेने के बजाय गुस्सा होकर defensive हो जाना भी मददगार नहीं है
    फिर भी PlatformIO जैसी चीज़ सही दिशा में है। मुझे पता है कि यह Python project है और कभी-कभी समस्या बनता है, लेकिन दूसरे tools से कम, और idea सही है
    Toolchain, SDK, libraries managed होनी चाहिए, project setup सरल होना चाहिए, और build कहीं भी, कभी भी reproducible होना चाहिए
    काश embedded industry साझा structured effort की value को ज़्यादा समझे। मैं बड़े MCU manufacturers में काम करने वाले कई लोगों को जानता हूं, लेकिन वे आम तौर पर अपनी तत्काल समस्या सुलझाने में इतने व्यस्त दिखते हैं कि developer needs को लेकर उनका दृष्टिकोण संकीर्ण लगता है, जो हमेशा निराश करता है

    • अब मैं ऐसी चीज़ें इस्तेमाल नहीं करता जिनमें Python tools हों। पहली कोशिश में ठीक से काम करना बहुत कम होता है
      RP2040 पर चलने वाला एक keyboard project है और firmware Rust में है। केवल repository हो और Rust toolchain न हो, तो flash करने की प्रक्रिया यह है
      (rustup install करें)
      $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
      $ rustup target add thumbv6m-none-eabi
      $ cargo install elf2uf2-rs
      * keyboard को bootloader mode में switch करें *
      $ cargo run --release
      यहां rustup और Cargo toolchain management और build का ज़्यादातर हिस्सा संभाल लेते हैं, और ये दोनों वाकई शानदार हैं। Python projects इनके आसपास भी नहीं आते
    • Docker या दूसरे container tools अच्छे candidate नहीं हो सकते? Toolchain को local पर install करने के बजाय, ज़रूरी exact toolchain वाली image-based container में build कर लें
    • Android app development करते-करते इस मामले में मेरी expectations ऊंची हो गई हैं
      बस एक command चलाने पर local हो या CI, build tools और libraries के समान version के साथ पूरी तरह एक ही तरीके से setup और काम करता है
      इसलिए जब फिर CMake और Make से जूझते हुए libraries install करने की कोशिश करता हूं तो तकलीफ होती है। compile 'library-name-here' जैसे तरीके से यह बहुत अलग है
    • मुझे नहीं लगता लोग Python को tool language के तौर पर उसके गुणों की वजह से चुनते हैं। उस नजरिए से यह शानदार नहीं है, और statically linked binary बेहतर है
      बल्कि वे इसे library ecosystem की वजह से चुनते हैं। Data analysis, visualization, scientific computing में इसके बराबर विकल्प किसी और language में नहीं हैं
      ये वे क्षेत्र हैं जिन्हें शुरू से फिर implement नहीं करना चाहेंगे। Numerical stability जैसी चीज़ों में bugs डालना आसान है, जिससे 99% मामलों में सही result मिले और 1% में ऐसा result मिले जो देखने में plausible हो लेकिन पूरी तरह गलत हो
    • 2011 में C# में लिखा हुआ एक command-line tool है जो आज भी बस ठीक-ठाक चल जाता है

  • निजी तौर पर मैंने अपने RP2040 projects को Rust और Embassy पर ले जाना शुरू कर दिया है
    Rust में ढलने में थोड़ा समय लगा, लेकिन यह मुझे काफी पसंद आया. यह RTOS नहीं है, लेकिन RTOS की जरूरत पैदा करने वाली कई आवश्यकताओं को पूरा कर देता है

    • अगर आप इस रास्ते पर जाते हैं, तो शुरुआत में rp2040-hal crate से शुरू करने और जब कई tasks manage करने में दर्द होने लगे तो Embassy या RTIC देखने की सलाह दूंगा
      Rust और Cargo, RP2040 या STM32 build और flash करने की तकलीफ दूर कर देते हैं. अब तक इस्तेमाल किए embedded environments में यह सबसे आरामदायक रहा है
    • मैं भी इसे कुछ इसी तरह देखता हूं. लोग आम तौर पर RTOS की ओर इसलिए जाते हैं क्योंकि library और dependency management चाहिए होता है, और Rust, Cargo, crates.io इस्तेमाल करने पर ये चीजें लगभग out-of-the-box मिल जाती हैं
      कई applications MPU का इस्तेमाल नहीं करतीं. इसके साथ Rust की memory safety और RTOS न होने से firmware की कुल complexity कम होने वाली बात जोड़कर देखनी चाहिए
    • पूरी तरह सहमत. कुल मिलाकर embedded Rust मेरे लिए शानदार अनुभव रहा है
      Embassy executor की async functionality भी बहुत अच्छी तरह काम करती है, जिससे RTOS design process का काफी दर्द कम हो जाता है
    • 100% सहमत. Embassy शानदार है और मुझे सच में बहुत पसंद है
      RP2040 के लिए PIO interface भी जोड़ दें, तो code बहुत simple और सुंदर हो जाता है, और ऐसी configuration बनती है जिसे दूसरे processors पर पाना मुश्किल है

  • Pi Pico, Zephyr में 100% supported है. https://github.com/zephyrproject-rtos/zephyr/tree/main/board... क्या documentation नहीं देखा? https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi...
    इसके अलावा, कई स्थितियों में एक “main” Zephyr installation इस्तेमाल करना नहीं, बल्कि project के west.yml में जरूरी external modules शामिल करना ही intended usage है
    कई projects का एक ही Zephyr installation share करना अलग चर्चा है, लेकिन हर संभव toolchain और HAL install करना ही एकमात्र तरीका नहीं है

    • अगर Zephyr SDK install नहीं करना चाहते थे, तो GNU Arm Embedded toolchain से build करना भी मामूली बात होनी चाहिए थी; समझ नहीं आता कि ऐसा क्यों नहीं हुआ

  • आजकल open source हो चुके ThreadX का जिक्र नहीं हुआ
    https://github.com/eclipse-threadx/threadx/

    • RIOT भी एक दूसरा alternative हो सकता है
      https://github.com/RIOT-OS/RIOT
    • समझ नहीं आता कि ऐसी lists में ThreadX का जिक्र ज्यादा बार क्यों नहीं होता. इसे इस्तेमाल करना और समझना तुलनात्मक रूप से simple है

  • RTOS options की तुलना अच्छी लगी
    निजी तौर पर मुझे MicroPython ज्यादा आसान रास्ता लगता है. async/await आधारित cooperative multitasking मेरे लिए अच्छी तरह काम करती है
    हाल के project में मैंने 6 stepper motors, कई LEDs और button scanning सब handle किया, और user को यह real-time जैसा दिखा

    • ये mini computers, 8-bit और 16-bit home computers से कहीं ज्यादा powerful हैं, इसलिए MicroPython शुरुआती systems के BASIC use cases को अच्छी तरह replace कर सकता है
      हैरानी होती है कि आज भी बहुत लोग ठीक से नहीं समझते कि उस समय हमारे पास resources कितने कम थे, फिर भी हम high-level language इस्तेमाल करते थे
    • अगर PTZ controller जैसी strong real-time requirement नहीं है और application की memory usage कम है, तो MicroPython productive choice लगता है
      ESP32 पर MicroPython इस्तेमाल करते समय मुझे यह पसंद आया कि यह interrupt handlers को Python-जैसे तरीके से support करता है. लगता है RP2040 में भी ऐसा ही support होगा
    • इस मामले में stepper motor signals शायद Python code सीधे generate नहीं कर रहा, बल्कि ESP32 के RMT जैसे hardware peripheral generate करते हैं, ऐसा मानना चाहिए न?
      मेरे microscope में लगभग real-time stepper motor control FluidNC board संभालता है, और मैं उसे हल्के serial protocol से control करता हूं
      हालांकि मैं https://pypi.org/project/micropython-stepper/ देख रहा हूं, और यह hardware timers व Python code इस्तेमाल करता हुआ लगता है
    • सही, यह एक simple MicroPython project होगा ऐसा लगता है

  • किसी proper project में Hubris एक बार आजमाना चाहता हूं (https://hubris.oxide.computer/reference/)
    इसका architecture approach embedded क्षेत्र में मैं जिस दिशा में जाना चाहता हूं, उससे काफी मेल खाता है. बस मैं इसे C में करके ज्यादा तकलीफ झेल रहा हूं
    hosted environment में Erlang/Elixir से किए जाने वाले तरीके से भी यह बहुत अलग नहीं है
    जहां memory ज्यादा constrained हो और multiple stacks afford न किए जा सकें, वहां Embassy अच्छा option लगता है

  • नया embedded project हमेशा, सच में हमेशा, virtual machine में शुरू होना चाहिए. tools को एक ही system में mix नहीं करना चाहिए
    मेरे commercial project में quality issues का नंबर 1 कारण यही था
    अगर नए chipset, नए vendor के साथ project शुरू कर रहे हैं, तो नई VM बनाएं, उस VM में सिर्फ vendor tools install करें, और वहीं build करें
    experimental development अपनी local non-VM machine पर करना ठीक है. लेकिन release हमेशा VM से होना चाहिए. और कृपया VM और development workstation को sync रखिए
    अभी original developer के छुट्टी पर होने के दौरान एक जरूरी firmware build fix करने में बहुत दर्द झेल रहा हूं. किसी के पास उसकी workstation access नहीं है, तैयार VM 6 महीने पीछे है, और customer पूछ रहा है कि ऐसी चीज के लिए पूरी team का खर्च क्यों दे, जिसे दुनिया में सिर्फ एक खास programmer ही कर सकता है

    • इससे बेहतर containers इस्तेमाल करना है. कई सालों से virtual machines इस्तेमाल नहीं कीं, और उनकी कोई कमी महसूस नहीं होती
    • क्या Nix और flakes reproducible build environment में मदद करेंगे?
    • वह दर्द महसूस हो रहा है
      मेरे हिसाब से releases CI system से build होने चाहिए. git में release tag लगाते ही tests pass होने के बाद binary निकलनी चाहिए

  • FreeRTOS चुनने पर बहुत ज़्यादा गलत होने की संभावना कम है। इस समय यह व्यावहारिक रूप से industry standard है

    • printf() को काम करवाने की समस्या का क्या समाधान हो सकता है?
      यह काफ़ी सिरदर्द भरा लग रहा है

  • मूल लेख जैसा अनुभव मुझे भी हुआ था
    इसलिए मैंने खुद एक साधारण green thread timer बनाया था
    यह असली kernel की तरह वास्तविक process management को support नहीं करता और कोई guarantee भी नहीं देता, लेकिन इसने bare-metal scheduling से आगे जाने में मदद की और RTOS वाली अव्यवस्था से बचा लिया
    इसे C में optional context struct लेने वाले JavaScript timer callback जैसा समझा जा सकता है
    अलग-अलग sensors को query करना, incoming signals को process करना, control decisions लेना, और commands भेजना—इन सबको अलग-अलग intervals पर संभाल पाना संभव हुआ
    ऐसी धीमी और abstract architecture से अपनी ज़िंदगी मुश्किल बनाने से पहले, मैं strongly recommend करूँगा कि पहले यह तरीका आज़माएँ