एम्बेडेड में नकाबपोश

किसी भी सॉफ्टवेयर को विकसित करते समय प्लग अपरिहार्य हैं। एक एम्बेड में, उनके उदार पांच सेंट भी हार्डवेयर समस्याओं को फेंक सकते हैं, लेकिन यह एक अलग गीत है। लेकिन विशुद्ध रूप से प्रोग्राम किए गए घात, जब आप एक खाली जगह में फंस जाते हैं ... मेरे लिए उनमें से तीन प्रकार हैं।

सबसे आसान तरीका है जब मैनुअल, मानक, या, कहें, तो लोहे के लिए पुस्तकालय को कॉन्फ़िगर करने की प्रक्रिया पूरी तरह से समझ में नहीं आती है। यहां यह स्पष्ट है: सभी चालें समाप्त नहीं हुई हैं, धैर्य और काम, एक और पांच या दो प्रयोग, और यह जीवन में आएगा। मदद करने के लिए आस्टसीलस्कप और वैज्ञानिक tyk।


कैन बस सेटिंग्स के लिए एक आवृत्ति विभक्त का चयन करना

इससे भी बदतर, जब समस्या एक टाइपो या तर्क में एक गलती है, जिसे आप बिंदु खाली नहीं देख सकते हैं जब तक कि आप इस जगह से बीस बार अपनी आंखों और कदम-दर-कदम डिबगिंग के माध्यम से नहीं चलते हैं। तब यह मर जाता है, माथे पर एक जोरदार झटका, एक रोना, "ठीक है, आप एक तरह का बाबई!", संपादन। यह काम करता है।

और एक उदास तीसरा दृश्य: एक गड़बड़ एक विदेशी पुस्तकालय में और लोहे के साथ जंक्शन पर रेंगने। शेक्सपियर के जुनून एक मॉनिटर की स्थिर रोशनी को जन्म देता है। "क्यों, यह नहीं कर सकता, सिस्टम इस तरह से व्यवहार नहीं कर सकता, क्योंकि यह कभी नहीं हो सकता! खैर, सच में! आह! ” नहीं। प्राप्त करना, हस्ताक्षर करना।

परिणामस्वरूप, वास्तविकता अपेक्षा से अधिक व्यापक, व्यापक और व्यापक है। कुछ उदाहरण:

इतिहास नंबर 1। माइक्रोएसडी फ्लैश ड्राइव और डीएमए काम करते हैं

इतिहास

आपको एसडी कार्ड पर फ़ाइल को डेटा डंप करने की आवश्यकता है। बेशक, मेरे पास न तो समय है और न ही फाइल सिस्टम और एसडीआईओ ड्राइवर को लिखने की इच्छा है, इसलिए मैं तैयार लाइब्रेरी लेता हूं। मैंने इसे लोहे के लिए स्थापित किया, और सब कुछ ठीक काम करता है। सबसे पहले। और फिर यह पता चला कि डेटा बेतहाशा दर्ज किया गया है: वॉल्यूम सटीक हैं, लेकिन फाइलों में स्वयं, ट्रिपल बाइट्स के अलग-अलग जोड़े डुप्लिकेट होते हैं, फिर बिना किसी नियमितता के गायब हो जाते हैं। अच्छा नहीं है!

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

कुत्ते को खोदने में कुछ दिन लगे।

निदान

समस्या डीएमए उपकरणों के साथ पुस्तकालय की बातचीत में थी।

एसडी कार्ड की ख़ासियत है: वे केवल 512 बाइट्स के ब्लॉक में लिखे गए हैं। ऐसा करने के लिए, पुस्तकालय 512-बाइट सरणी में डेटा को बफ़र करता है, और इसे भरने के लिए डीएमए के माध्यम से वहां से फ्लश करता है। लेकिन!

अगर मैं लाइब्रेरी बफ़र <बाइट में रिक्त स्थान <512xN + से बड़ा अंश रिकॉर्ड करता हूं, तो लाइब्रेरी (जाहिर है, ताकि मेमोरी को आगे और पीछे न धकेलें) ऐसा करता है: यह अपने बफर को फिर से भरता है, इसे फ़्लैश के लिए लिखता है , और अगले 512xN बाइट मेरे बफर से सीधे मेरे डीएमए में फेंक दिए जाते हैं! खैर, अगर कुछ अधूरा छोड़ दिया जाता है - यह फिर से अपने आप को कॉपी करता है, अगली बार तक।

और यह सब ठीक होगा, लेकिन डीएमए नियंत्रक को यह आवश्यक है कि डेटा को 4-बाइट सीमा पर संरेखित मेमोरी में रखा जाए। लाइब्रेरी बफ़र हमेशा इतना संरेखित होता है, भाषा इसकी गारंटी देती है। लेकिन किस पते के साथ, डेटा के एक हिस्से को कॉपी करने के बाद, एक छोटी बाइट के साथ शेष 512xN मेरे साथ शुरू होता है - भगवान जानता है। और पुस्तकालय इसकी बिल्कुल भी जांच नहीं करता है: पता, जैसा कि है, डीएमए नियंत्रक को दिया गया है।

"उन्होंने कुछ अनाड़ी भेजा ... एक कुत्ता उसके साथ।" नियंत्रक चुपचाप प्रेषित पते के निचले 2 बिट्स को रीसेट करता है। और ट्रांसफर शुरू करता है।


पता, शुरू में 4 का एक बहु नहीं है, एक मल्टीपल वॉयला द्वारा प्रतिस्थापित किया जाता है, लाइब्रेरी बफ़र से अंतिम तीन बाइट्स तक मेरा से फाइल में फिर से लिखा जाता है, और मेरे बफ़र से समान बाइट्स एक ट्रेस के बिना खो जाते हैं। नतीजतन, डेटा की कुल मात्रा सही है, संचालन सुचारू रूप से चलते हैं, लेकिन डिस्क बकवास है।

इलाज

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

इतिहास नंबर २ रंटाइम और एक गुच्छा

प्रस्तावना

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

पहली धारणा "बीवर मर चुका है, चिप प्रतिस्थापन के लिए है।" और फिर प्रोग्रामर ने ओक को दिया। लेकिन नहीं, फर्मवेयर का पुराना संस्करण काफी हद तक काम करता है, लेकिन नया लॉन्च और मेरे कोड के बीच कुछ अस्पष्ट विधानसभा गहराई में लगातार गिरता है। मुझे कोई अनुमान नहीं था कि यह किस तरह का विधर्म है।

अध्याय 1

कम से कम कुछ अतिरिक्त जानकारी कैसे प्राप्त करें, यह देखने के लिए इंटरनेट की मदद की। हार्ड डिफ़ॉल्ट के परिणामों को पार्स करने की प्रक्रिया को गुगली किया गया था: रजिस्टरों की स्थिति, डंप स्टैक। मैं समाप्त हो गया। इसका इस्तेमाल किया।

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

विश्लेषण की निरंतरता ने दिखाया कि गड़बड़ स्थानीय स्थैतिक चर को आरंभ करने के प्रयास का परिणाम है।

अध्याय 2

एक बार जब रनवे चर के निर्माण में लगा होता है, तो यह उसके लिए भी होता है कि वह प्रोग्राम के पूरा होने पर डिस्ट्रक्टर्स को बुलाए (भले ही प्रोग्राम वास्तव में काम पूरा नहीं करता है, जो माइक्रोकंट्रोलर्स के लिए पूर्ण मानदंड है)। ऐसा करने के लिए, उसे उन सभी चरों के बारे में जानकारी संग्रहीत करने के लिए कहीं न कहीं ज़रूरत है, जिसे वह शुरू करने में कामयाब रहा।

यह उस जगह पर सही है जहां इस तरह की जानकारी किसी प्रकार की आंतरिक सूची में संग्रहीत की जाती है, रनटाइम भी गिर गया। क्योंकि मॉलॉक () फ़ंक्शन, जिसके माध्यम से इस सूची के तत्वों के लिए मेमोरी आवंटित की गई थी और जो मानक के अनुसार, कम से कम 8 बाइट सीमा में गठबंधन होने की गारंटी देता है, एक n-वें नंबर की सफल कॉल के बाद, यह एक टुकड़ा पैदा करता है जो इस सीमा में गठबंधन नहीं होता है।



नए फर्मवेयर कोड में बदलाव से मॉलॉक टूट गया?! लेकिन यह कैसे भी संभव है? मैंने वास्तव में मॉलफ़ॉक को फिर से परिभाषित नहीं किया है, मुझे स्वयं इसकी आवश्यकता कहीं और नहीं है!

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

अध्याय 3

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

और ओह, एक चमत्कार!

सभी सफल कॉल रैम स्पेस (इस पत्थर के लिए 0x20000000 और पुराने) से पते जारी किए गए हैं, क्रमिक रूप से कॉल से कॉल तक बढ़ रहे हैं। और पहला असफल 0x00000036 वापस आ गया। यही है, पता न केवल यह है कि इसे संरेखित नहीं किया गया था, बल्कि रैम के पते के स्थान पर बिल्कुल भी नहीं था! प्रोसेसर ने वहां कुछ लिखने की कोशिश की और स्वाभाविक रूप से गिर गया।

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

उपसंहार

कॉन्फ़िगरेशन फ़ाइल में ढेर का आकार बढ़ा, और सब कुछ तय हो गया।

लेकिन उस क्षण से पहले मैंने इसकी मात्रा के बारे में भी नहीं सोचा। क्या नर्क ने मुझे आत्मसमर्पण किया, मैंने सोचा। वैसे भी, मेरे पास सभी चर और वस्तुएं स्थिर या स्टैक पर हैं। इसलिए, केवल जड़ता द्वारा, मैंने इसके तहत 0x300 बाइट्स छोड़े, क्योंकि ढेर के नीचे कुछ मात्रा सभी टेम्पलेट परियोजनाओं में आवंटित की गई है। लेकिन नहीं, सी ++ रनटाइम को अभी भी गतिशील रूप से आवंटित स्मृति की आवश्यकता है, और काफी ध्यान देने योग्य मात्रा में, नियंत्रकों के मानकों द्वारा।

जियो और सीखो।