बूट लोडर क्या है, और मैं इसे कैसे विकसित करूंगा?


53

मैं कई परियोजनाओं से मिला हूँ जिसमें एक AVR माइक्रोकंट्रोलर एक बूटलोडर (जैसे कि Arduino) के साथ उपयोग करता है, लेकिन मैं अवधारणा को बहुत अच्छी तरह से नहीं समझता।

मैं एक बूटलोडर (किसी भी माइक्रोकंट्रोलर के लिए) कैसे बना सकता हूं?

मेरे बूटलोडर को लिखने के बाद, यह माइक्रोकंट्रोलर के लिए कैसे प्रोग्राम किया जाता है (जैसे किसी भी .hex प्रोग्राम को AVR के फ्लैश रोम, या किसी अन्य विधि से जलाया जाता है)?


10
आपने इसे बूटलोडर टैग के साथ टैग किया है, क्या आपने इसके माध्यम से पढ़ा है? यदि हां, तो क्या आपने Arduino Bootloader , Arduino Bootloader Follow On , Arduino बूटलोडर , बूटलोडर की संरचना को समझने के लिए अच्छे उपकरण या तरीके पढ़े हैं , और Arduino Bootloader विवरण प्रश्न? वे सभी आपके प्रारंभिक प्रश्न के कुछ हिस्सों को संबोधित करते हैं। मैंने इसे नए सामान के लिए ट्रिम किया है।
केविन वर्मर

बूटलोडर डिज़ाइन विधि के बारे में एक पेपर: beningo.com/wp-content/uploads/images/Papers/…
yahya tawil

2
@ केविनविमर मुझे लगता है कि उनका सवाल ज्यादा सीधा है।
ऋचीकुलियन

जवाबों:


103

एक बूटलोडर एक प्रोग्राम है जिसे प्रोग्राम करने के लिए माइक्रोकंट्रोलर में चलता है। यह कुछ संचार साधनों के माध्यम से बाहरी रूप से नई कार्यक्रम की जानकारी प्राप्त करता है और उस जानकारी को प्रोसेसर की प्रोग्राम मेमोरी में लिख देता है।

यह कार्यक्रम को माइक्रोकंट्रोलर में प्राप्त करने के सामान्य तरीके के विपरीत है, जो उस उद्देश्य के लिए माइक्रो में निर्मित विशेष हार्डवेयर के माध्यम से होता है। PICs पर, यह एक SPI जैसा इंटरफ़ेस है। अगर मुझे सही याद है, AVR Jtag का उपयोग करते हैं, या कम से कम उनमें से कुछ करते हैं। किसी भी तरह से, इसके लिए कुछ बाहरी हार्डवेयर की आवश्यकता होती है जो प्रोग्राम मेमोरी में सूचना लिखने के लिए प्रोग्रामिंग पिन को सही ठहराता है। कार्यक्रम मेमोरी सामग्री का वर्णन करने वाली एचईएक्स फ़ाइल एक सामान्य उद्देश्य कंप्यूटर पर उत्पन्न होती है, इसलिए यह हार्डवेयर एक तरफ कंप्यूटर से जुड़ता है और दूसरी तरफ माइक्रो के विशेष प्रोग्रामिंग पिन। मेरी कंपनी दूसरी चीजों के बीच PIC प्रोग्रामर को एक साइडलाइन के रूप में बनाती है, इसलिए मैं PICs पर इस प्रक्रिया से काफी परिचित हूं।

विशेष हार्डवेयर के माध्यम से बाहरी प्रोग्रामिंग का महत्वपूर्ण बिंदु यह है कि यह प्रोग्राम मेमोरी की मौजूदा सामग्री की परवाह किए बिना काम करता है। माइक्रोकंट्रोलर प्रोग्राम मेमोरी के मिटने या किसी अज्ञात स्थिति में शुरू होते हैं, इसलिए बाहरी प्रोग्रामिंग एक माइक्रो में पहला प्रोग्राम प्राप्त करने का एकमात्र साधन है।

यदि आप उस प्रोग्राम के बारे में सुनिश्चित हैं जिसे आप अपने उत्पाद में लोड करना चाहते हैं और आपके वॉल्यूम काफी अधिक हैं, तो आपके लिए निर्माता या वितरक प्रोग्राम चिप्स हो सकते हैं। चिप किसी भी अन्य चिप की तरह बोर्ड में मिलाया जाता है, और इकाई जाने के लिए तैयार है। यह खिलौने जैसी किसी चीज के लिए उपयुक्त हो सकता है, उदाहरण के लिए। एक बार फर्मवेयर हो जाने के बाद, यह बहुत अधिक हो जाता है, और इसे बड़े संस्करणों में उत्पादित किया जाएगा।

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

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

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

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

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

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

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

  1. मूल बूटलोडर। इस उपकरण में एक सीरियल लाइन थी और इसे एक होस्ट से जोड़ा जाएगा और आवश्यकतानुसार चालू किया जाएगा। बूटलोडर रीसेट से चला गया और मेजबान को कुछ अपलोड अनुरोध प्रतिक्रियाएं भेज दीं। यदि अपलोड कार्यक्रम चल रहा था, तो यह प्रतिक्रिया देगा और एक नई एप्लिकेशन छवि भेजेगा। यदि यह 500 एमएस के भीतर प्रतिक्रिया नहीं करता है, तो बूटलोडर मौजूदा ऐप को छोड़ देगा और चलाएगा। इसलिए फर्मवेयर को अपडेट करने के लिए, आपको पहले होस्ट पर अपडेटर ऐप चलाना होगा, फिर डिवाइस पर कनेक्ट और पावर करना होगा।

  2. प्रोग्राम मेमोरी अपलोडर। यहाँ हमने PIC के अगले आकार का उपयोग किया है जिसमें दो बार प्रोग्राम मेमोरी थी। कार्यक्रम मेमोरी को मोटे तौर पर 49% मुख्य ऐप, 49% नई ऐप छवि और 2% बूटलोडर में विभाजित किया गया था। बूटलोडर रीसेट से चलेगा और नई ऐप इमेज को सही परिस्थितियों में मौजूदा ऐप इमेज पर कॉपी करेगा।

  3. बाहरी EEPROM छवि। # 2 की तरह, सिवाय इसके कि नई ऐप छवि को स्टोर करने के लिए एक बाहरी EEPROM का उपयोग किया गया था। इस मामले में अधिक मेमोरी वाला प्रोसेसर भी शारीरिक रूप से बड़ा और एक अलग उप-परिवार में होता है जिसमें हमारे लिए आवश्यक बाह्य उपकरणों का मिश्रण नहीं होता है।

  4. टीसीपी बूटलोडर। यह उन सभी में सबसे जटिल था। एक बड़े PIC 18F का उपयोग किया गया था। स्मृति का अंतिम 1/4 या तो बूटलोडर रखा गया था, जिसकी टीसीपी नेटवर्क स्टैक की अपनी पूरी प्रति थी। बूटलोडर रीसेट से चला गया और पहले से कॉन्फ़िगर किए गए आईपी पते पर एक ज्ञात बंदरगाह पर एक विशेष अपलोड सर्वर से कनेक्ट करने का प्रयास किया। यह बड़े प्रतिष्ठानों के लिए था जहां हमेशा पूरे सिस्टम के लिए एक समर्पित सर्वर मशीन थी। प्रत्येक छोटा उपकरण रीसेट के बाद अपलोड सर्वर के साथ जांच करेगा और उपयुक्त के रूप में एक नया एप्लिकेशन कॉपी दिया जाएगा। बूटलोडर नई प्रतिलिपि के साथ मौजूदा ऐप को अधिलेखित कर देगा, लेकिन केवल इसे चलाएं यदि चेकसम चेक किया हो। यदि नहीं, तो यह अपलोड सर्वर पर वापस जाएगा और पुन: प्रयास करेगा।

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

उम्मीद है कि आप देख सकते हैं कि जोखिम, गति, लागत, उपयोग में आसानी, डाउनटाइम, आदि के साथ प्रत्येक अन्य संभावनाएं हैं।


1
Xmega परिवार (जिसमें नया 2-वायर इंटरफ़ेस है) को छोड़कर सभी AVRs रीसेट में रहते हुए SPI इंटरफ़ेस का उपयोग करते हैं। बड़े लोगों के पास जेटीजी भी है, कुछ में समानांतर प्रोग्रामिंग है, और छोटे लोगों को उच्च वोल्टेज की आवश्यकता हो सकती है यदि रीसेट को I / O के रूप में पुन: कॉन्फ़िगर किया गया है। कुछ MCUs, जैसे Parallax Propeller और Motorola / Freescale 68HC08 परिवार, ROM में न्यूनतम प्रोग्रामिंग हार्डवेयर लेकिन बूटलोडर नहीं है।
यन वर्नियर

यह वर्तमान और अपलोड किए गए एप्लिकेशन संस्करणों की तुलना करता है, उनके चेकसमों की जांच करता है, और यदि संस्करण भिन्न होते हैं और नई छवि चेकसम चेक की नई छवि को एप्लिकेशन क्षेत्र पर कॉपी करता है। हां लेकिन अगर इस कार्रवाई के बीच में शक्ति बाधित हो जाती है, तो "ऐप क्षेत्र" में एक दूषित छवि होगी। मुझे लगता है कि बूटलोडर-फेलसेफ़-ऐप होना बेहतर हो सकता है जो नए ऐप को mcu फ़्लैश में लिखता है और यदि चेकसम मान्य है, तो यह कहीं न कहीं "नए ऐप को बूट करने के लिए ठीक है" भी लिखता है। तो शुरू में, यह जाँचता है कि क्या यह नए ऐप को बूट करने के लिए ठीक है, अगर ऐसा नहीं है कि यह खुद को निष्पादित करना जारी रखता है (
विफल

@Erv: यदि वर्तमान में नए संस्करण की प्रतिलिपि बनाने के बीच में बिजली विफल हो जाती है, तो बिजली वापस आने पर वर्तमान संस्करण चेकसम विफल हो जाएगा और बूटलोडर फिर से चलता है। मैं आमतौर पर चेकसम शब्द को छवि के बहुत अंत में रखता हूं ताकि किसी भी आंशिक लेखन में चेकसम विफलता की बहुत अच्छी संभावना हो।
ओलिन लेथ्रोप

नमस्ते। मैं आपको 5 प्रकार के बूटलोडर की सिफारिश कर सकता हूं - टीसीपी स्टैक के बजाय, आप यूडीपी को लागू कर सकते हैं। फिर अद्यतन या देशी प्रोटोकॉल डाउनलोड करने के लिए TFTP का उपयोग करें।
.६

22

बूटलोडर की अवधारणा क्या है?

इस परिदृश्य को देखें: आपके पास अपने माइक्रोकंट्रोलर पर उचित मात्रा में भंडारण है - 2-3 से अधिक कार्यक्रमों या अनुप्रयोगों को संग्रहीत करने के लिए पर्याप्त है जो एक दूसरे से स्वतंत्र हैं। मान लीजिए कि जब आप अपने डिवाइस को बूट करते हैं, तो आप चुन सकते हैं कि कौन सा चुनना है। तो आपको इसके समर्थन की क्या आवश्यकता होगी? आपको एक शुरुआती कार्यक्रम की आवश्यकता होगी जो तब आपको बूट-टाइम पर दूसरों के बीच चयन करने की अनुमति देता है।

यह काम किस प्रकार करता है?

एक बूटलोडर वह प्रोग्राम है - यह चलाने के लिए पहली चीज है और अन्य एप्लिकेशन को मेमोरी में विशिष्ट स्थानों पर लोड कर सकता है (या तो फ़्लेश की तरह, या रैम की तरह अस्थिर) और फिर उस इच्छित प्रोग्राम में कूद जाता है, जहां से फिर इसे निष्पादित करेगा। ।

एवीआर बूटलोडर (या किसी भी माइक्रोकंट्रोलर के लिए) कैसे बनाएं?

मैंने कभी भी बूटलोडर नहीं बनाया है, लेकिन यह है कि मुझे लगता है कि मैं इसे करने के बारे में जाऊंगा: एक फर्मवेयर प्रोग्राम लिखना शुरू करें जैसा कि आप सामान्य रूप से करेंगे - लेकिन सुनिश्चित करें कि इसे एक ऐसे क्षेत्र में रखा गया है, जो हमेशा चलने वाली पहली चीज है डिवाइस बूट। मेरे सिर के ऊपर से, कुछ कार्यक्षमता जो मैं इस छोटे से कार्यक्रम से बाहर करना चाहता हूं: स्मृति में उपलब्ध स्थान पर एक नया कार्यक्रम अपलोड करने की क्षमता, पहले से अपलोड किए गए प्रोग्राम को मिटा दें, कौन सा प्रोग्राम चुनें (यदि इससे अधिक है एक), और कुछ प्रकार के भंडारण डेटा संरचना (ग्रो-सक्षम जंप टेबल?) को याद रखने में सक्षम होने के लिए जहां अन्य प्रोग्राम हैं और उनके लिए कूदें। UART पर इंटरैक्शन किया जा सकता है जहां यह आपको एक बहुत ही सरल टर्मिनल मेनू और उसी चैनल पर फर्मवेयर अपलोड करने की क्षमता पेश कर सकता है।

यह माइक्रोकंट्रोलर को कैसे प्रोग्राम किया जाता है (जैसे किसी भी .hex प्रोग्राम को एवीआर के फ्लैश रोम, या किसी अन्य विधि से जलाया जाता है)?

यदि यह पूरी तरह से एक खाली चिप है जिसमें कोई मौजूदा बूटलोडर नहीं है जो खुद को अपडेट कर सकता है, तो आपको फ्लेश को जलाने की आवश्यकता होगी जैसे आपने जो भी तकनीक का उपयोग करने के लिए आवश्यक है उसे पूरा करने के लिए कहा है (AVR के मामले में ICSP)।

यह किसी भी तरह से व्यापक नहीं है कि "बूटलोडर्स" क्या हैं। आप जिस एक या सिस्टम के लिए डिज़ाइन किए गए हैं, उसके आधार पर, आप FLASH के बजाय RAM में निर्दिष्ट स्थान पर सामान अपलोड करने के लिए डिज़ाइन कर सकते हैं, और किसी भी मनमाने स्मृति स्थान पर निष्पादन शुरू कर सकते हैं। या हो सकता है कि आप एक ऐसा चाहते हैं जो आपके पीसी बूट होने पर लोड करने के लिए कौन सा ऑपरेटिंग सिस्टम चुनने में सक्षम हो ( उदाहरण के लिए ग्रब देखें )। 8-बिट माइक्रोकंट्रोलर के लिए बूटलोडर्स बहुत सरल होते हैं।

Arduino के बारे में एक नोट: यह बूटलोडर केवल एक कार्यक्रम AFAIK का प्रबंधन करता है, यह फर्मवेयर अपलोडिंग और अन्य सामान का प्रबंधन करने के लिए सीरियल पोर्ट को भी संभालता है ।


FYI करें, मूल बुलेट बिंदुओं को संबोधित करने के लिए उत्तर लिखा गया था जिसे अब दूर संपादित किया गया है।
जॉन एल

3

एक "बूट" लोडर की अवधारणा एक पंप "प्राइमिंग" की अवधारणा के समान है। दूसरे शब्दों में, आपको "कुछ" चाहिए जो किसी प्रोग्राम को दिए गए पते पर लोड करता है और फिर उस दिए गए पते पर प्रोग्राम को निष्पादित करना शुरू करता है। वह कुछ है, बूट लोडर है। सबसे सरल मामले में, बूट लोडर "सीपीयू के निर्दिष्ट शुरुआती पते (शून्य, सबसे अधिक संभावना) पर" दिखाई देता है, कार्यक्रम को आवश्यक मेमोरी सेगमेंट में लोड करता है, इसे नियंत्रण स्थानांतरित करता है, और "गायब हो जाता है।" उपस्थिति और गायब होने को "बाहरी" हार्डवेयर द्वारा नियंत्रित किया जाता है। एक संभावित कार्यान्वयन एक "हार्डवेयर" रीसेट के माध्यम से सक्रिय रोम के उपयोग से होगा, और एक "सॉफ्टवेयर" रीसेट के साथ निष्क्रिय होगा। ROM में लोडर सरल या आवश्यकतानुसार जटिल हो सकता है, और द्विआधारी रूप में लिखने की आवश्यकता है जो विशेष रूप से सीपीयू समझता है। यदि ROM द्वारा उपयोग की जाने वाली पता स्थान की आवश्यकता नहीं है, तो ROM निष्क्रियता की आवश्यकता नहीं होगी। जाहिर है, ROM की जगह EEPROM, ePROM, फ्लैश PROM आदि का उपयोग किया जा सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.