हमें माइक्रोकंट्रोलर में हमारे एप्लिकेशन प्रोग्राम से अलग बूटलोडर की आवश्यकता क्यों है?


28

हमें माइक्रोकंट्रोलर की एक ही फ्लैश प्रोग्राम मेमोरी में एक अलग प्रोग्राम की आवश्यकता क्यों है, विशेष रूप से STM32F103, जिसे बूस्टर कहा जाता है?

इसे मुख्य एप्लिकेशन प्रोग्राम से अलग रखने के लिए इसके बारे में क्या खास है?

सामान्यतया, माइक्रोप्रोसेसर-आधारित प्रणाली का एक बूटलोडर (पावरपीसी MPC8270 कहते हैं) एक माइक्रोकंट्रोलर (एआरएम STM32F103 कहते हैं) के रूप में एक ही काम करते हैं या वे एक दूसरे के लिए मौलिक रूप से अलग-अलग काम कर रहे हैं और फिर भी दोनों को 'बूटलोडर' कहा जाता है ?


2
यही कारण है कि आपके पास अलग-अलग चिप्स और भाग हैं और एक विशाल अखंड संरचना नहीं है
Emobe

तुम नहीं। कंप्यूटर कंसोल पर स्विच और रोशनी के साथ बस अपना कार्यक्रम दर्ज करें।
हॉट लिक्स

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

जवाबों:


55

एक माइक्रोकंट्रोलर पर एक बूटलोडर प्रोग्रामिंग हेडर के अलावा अन्य संचार चैनल पर मुख्य फर्मवेयर को अपडेट करने के लिए जिम्मेदार है। यह BLE, UART, I2C, SD कार्ड, USB, आदि के क्षेत्र में फर्मवेयर को अपडेट करने के लिए उपयोगी है। ग्राहकों को प्रोग्रामर को अपने डिवाइस पर फर्मवेयर को अपडेट करने के लिए खरीदना आवश्यक होगा।

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

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


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

3
कुछ उदाहरणों में, माइक्रोप्रोसेसर के प्रोग्रामिंग हेडर वास्तव में उत्पाद की चेसिस को अलग किए बिना अप्राप्य हो सकते हैं, इसलिए अतिरिक्त हार्डवेयर के बिना इसे कॉम्स बस पर फिर से शुरू करने में सक्षम होना विश्वसनीयता के लिए एक महत्वपूर्ण कारक है।
जॉन गो-सोको जूल

6
@ ऑल्ट-रोज़ बूटलोडर और एप्लिकेशन प्रोग्राम अलग-अलग संकलित कार्यक्रम हैं, प्रत्येक अपने स्वयं के स्टार्टअप कोड और main()फ़ंक्शन के साथ। सत्ता में बूटलोडर स्टार्टअप कोड चलाता है और बूटलोडर को कॉल करता है main()। बूटलोडर प्रोग्राम एक वैध एप्लिकेशन प्रोग्राम के लिए जाँच करता है और फिर एप्लिकेशन प्रोग्राम के स्टार्टअप कोड पर कूदता है जो एप्लिकेशन प्रोग्राम को कॉल करता है main()। प्रत्येक प्रोग्राम का स्टार्टअप कोड संबंधित प्रोग्राम (यानी वैरिएबल, स्टैक आदि को शुरू करने के लिए) सी रन-टाइम एनवायरनमेंट को इनिशियलाइज़ करता है और आमतौर पर, प्रोग्राम का main()कभी भी स्टार्टअप कोड पर नहीं लौटता है।
kkrambo

1
@ alt-rose: उसी तरह से जिसमें CPU को बूटलोडर का शुरुआती पता मिलता है - यह नहीं है। इसके बजाय, CPU निर्दिष्ट करता है कि वह बूटलोडर के शुरुआती पते के रूप में क्या उपयोग करेगा, और बूटलोडर निर्दिष्ट करता है कि यह एप्लिकेशन प्रोग्राम के शुरुआती पते के रूप में क्या उपयोग करेगा।
MSalters

4
@kkrambo आमतौर पर सच होने पर, कोई आवश्यकता नहीं होती है (न ही सार्वभौमिक रूप से सत्य तथ्य) कि बूटलोडर को C या C- व्युत्पन्न भाषा में लिखा जाए main
यक ०

26
  1. ताकि लोडिंग प्रक्रिया त्रुटियों से उबर सके। मान लीजिए कि एक उन्नयन के दौरान एक संचार त्रुटि या पावर डिस्कनेक्ट है। यदि बूट लोडर आपके द्वारा अपग्रेड किए जा रहे एप्लिकेशन का हिस्सा था, तो उपयोगकर्ता बूट लोडर को वापस करने के लिए विशेष हार्डवेयर का उपयोग किए बिना फिर से प्रयास करने में सक्षम नहीं होगा।

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

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

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


4
बिंदु 2 के एक उदाहरण के रूप में, कुछ माइक्रोकंट्रोलर के पास स्टार्टअप में भी सुलभ रैम नहीं हो सकती है : उदाहरण के लिए, रास्पबेरी पाई अपने एसडी कार्ड से बूटलोडर को लोड करने के लिए अपने जीपीयू का उपयोग करता है, जो तब एआरएम प्रोसेसर और मेमोरी को सक्षम करता है।
एरिक एफएल

11

वे आम तौर पर आपको अपना मुख्य एप्लिकेशन प्रोग्राम अपडेट करने की अनुमति देते हैं।

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


9

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


2
तो इतना ही है। MCU केवल एक विशेष प्रोग्रामिंग सबसिस्टम (जैसे AVRICE या JTAG) के माध्यम से या पहले से ही फ्लैश में बूटलोडर होने से कोड प्राप्त कर सकता है। यह एक एप्लिकेशन निर्णय है कि बूटलोडर कितना जटिल है, उदाहरण के लिए कुछ सिस्टम वाईफाई से कोड लोड कर सकते हैं। ATTiny की तरह बहुत कम अंत में MCUs, एक बूटलोडर (और सीरियल पिन) एक बड़ा ओवरहेड है, इसलिए आप हमेशा एक प्रोग्रामर का उपयोग करते हैं।
रिच

7

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


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

@BenVoigt, यह माइक्रोकंट्रोलर पर निर्भर करता है। कुछ (मुख्य रूप से NOR फ्लैश वाले) आपको सीधे फ्लैश से बाहर निकलने देंगे, लेकिन अन्य (आमतौर पर नंद फ्लैश, जो अधिक सामान्य हो रहा है) आपको रैम से बाहर निकलने की आवश्यकता है। कभी-कभी कोई भी ऑन-बोर्ड फ्लैश नहीं होता है, और आपको कुछ भी निष्पादित करने से पहले बाहरी SR चिप में कोड को स्थानीय SRAM से कॉपी करना होगा।
नैट एस - मोनिका

2

संक्षिप्त उत्तर, क्योंकि सॉफ्टवेयर कमाल है।

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

इन कार्यों में "वास्तविक" सॉफ़्टवेयर चलाने के लिए हार्डवेयर स्थापित करना शामिल हो सकता है (उदाहरण के लिए, रास्पबेरी पाई (@ErikF के माध्यम से)), चलने से पहले "वास्तविक" प्रोग्राम को बदलने के लिए एक प्रोटोकॉल होता है (पिन की जाँच करें, यदि उस पिन को वास्तविक प्रोग्राम को फिर से सेट किया जाता है), या यहां तक ​​कि "वास्तविक" प्रोग्राम के लिए सॉफ्टवेयर वातावरण सेट करना।

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

एक माइक्रोकंट्रोलर में, कुछ कार्य जो एक बूटलोडर करता है, को प्रोग्राम में विभाजित किया जा सकता है। आपके प्लेटफ़ॉर्म के लिए कंपाइलर स्वचालित रूप से "सेटअप" कोड को हर निष्पादन योग्य में इंजेक्ट कर सकता है।

लेकिन, बूटलोडर में होने का मतलब है कि एक ही कंपाइलर अलग हार्डवेयर पर काम कर सकता है, क्योंकि बूटलोडर प्लेटफार्मों के बीच के अंतर को "छिपा" सकता है।

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


-1

एक उत्तर जो कवर नहीं किया गया है, वह सी भाषा की सीमाओं के कारण चिंताओं को अलग करने की आवश्यकता है।

आम तौर पर बूटलोडर्स विधानसभा और सी के मिश्रण में लिखे जाते हैं, विधानसभा में बहुत शुरुआती बूट चरण के साथ।

यह कुछ चीजों को सेटअप करने के लिए किया जाता है जैसे:

  • सी स्टैक का आवंटन
  • स्टैक पॉइंटर को रजिस्टर में पढ़ना
  • रजिस्टर में कार्यक्रम काउंटर पढ़ना
  • रीसेट वैक्टर की घोषणा
  • दूसरे चरण (initramfs) को RAM में लोड करना।

यह उठाए गए कदमों का एक बहुत मोटा अनुमान है और मैं एआरएम बूट प्रक्रिया का वर्णन कर रहा हूं, यह x86 और अन्य आर्किटेक्चर के लिए फिर से अलग है।

हालांकि, सिद्धांत कारण समान है: सी स्टैक का आवंटन विधानसभा से किया जाना चाहिए।


क्यों होता है पतन? यह प्रासंगिक और सटीक दोनों है।
बिटशिफ्ट

-1

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

microcontroller

अधिकांश माइक्रोकंट्रोलर्स में अंतर्निहित ROM मेमोरी होती है जिसमें उनका प्रोग्राम कोड होता है। इस कोड को बदलने के लिए आमतौर पर एक प्रोग्रामर डिवाइस की आवश्यकता होती है जो माइक्रोकंट्रोलर के प्रोग्रामिंग इंटरफेस से जुड़ती है (जैसे कि ATMega पर ISP)। लेकिन ये प्रोग्रामिंग इंटरफेस आमतौर पर अन्य इंटरफेस की तुलना में अक्सर उपयोग करने के लिए बहुत सुविधाजनक नहीं होते हैं, क्योंकि वे दिए गए संदर्भ में आसानी से उपलब्ध नहीं हो सकते हैं। उदाहरण के लिए, जबकि लगभग हर कंप्यूटर में USB पोर्ट्स होते हैं, ISP के लिए आवश्यक SPI इंटरफ़ेस बहुत दुर्लभ है, और ATXMega पर उपयोग किए जाने वाले PID इंटरफ़ेस जैसे अन्य इंटरफेस केवल समर्पित प्रोग्रामिंग हार्डवेयर द्वारा समर्थित हैं।

इसलिए, उदाहरण के लिए, यदि आप बिना किसी बाहरी हार्डवेयर के नियमित कंप्यूटर से सॉफ़्टवेयर को अपडेट करना चाहते हैं, तो आप एक बूटलोडर का उपयोग कर सकते हैं जो डिवाइस को प्रोग्राम करने के लिए एक अलग तरह के इंटरफ़ेस (जैसे RS232, USB या RS232 USB पर USB की तरह) से पढ़ता है। आम इंटरफेस पर।

यदि आपको इस कार्यक्षमता की आवश्यकता नहीं है, तो बूटलोडर पूरी तरह से वैकल्पिक है। माइक्रोकंट्रोलर अभी भी बूटलोडर के बिना पूरी तरह से कोड को चला सकता है।

माइक्रोप्रोसेसर

एक माइक्रोप्रोसेसर पर चीजें थोड़ी अलग होती हैं। जबकि अधिकांश माइक्रोप्रोसेसरों में एक ROM है जो एक बूटलोडर के लिए काफी बड़ा है, उन रोम एक पूर्ण ओएस को धारण करने के लिए लगभग पर्याप्त बड़े नहीं हैं। इसलिए बूटलोडर का उद्देश्य हार्डवेयर को इनिशियलाइज़ करना है, बूट करने योग्य ओएस की तलाश करें, इसे लोड करें और इसे चलाएं। इसलिए हर एक बूट के लिए बूटलोडर महत्वपूर्ण है।

X86 / x64 सिस्टम पर यह बूटलोडर या तो BIOS या UEFI (मूल रूप से एक BIOS का नया संस्करण) है।

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

  • BIOS / UEFI बूट करता है और GRUB स्थापित पाता है। इसके बाद यह GRUB (= ग्रैंड यूनिफाइड बूटलोडर) लोड करता है
  • GRUB कुछ प्रकार के लिनक्स और विंडोज बूटलोडर को ढूंढता है। उपयोगकर्ता विंडोज बूटलोडर का चयन करता है।
  • विंडोज बूटलोडर शुरू होता है और विंडोज 7 और विंडोज 10 स्थापित पाया जाता है। उपयोगकर्ता विंडोज 10 का चयन करता है।
  • विंडोज 10 अंत में जूते।

तो इस मामले में सॉफ्टवेयर के तीन टुकड़े थे जिन्हें एक बूटलोडर माना जा सकता है। GRUB और विंडोज बूटलोडर दोनों ही ज्यादातर उपयोगकर्ता को BIOS / UEFI की तुलना में अधिक सुविधाजनक बूट चयन विकल्प देने के लिए हैं। यह एक ही हार्ड ड्राइव या एक ही पार्टीशन से कई OS को लॉन्च करने की भी अनुमति देता है।

TLDR

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


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

बेशक एक माइक्रोकंट्रोलर और एक माइक्रोप्रोसेसर के बीच का अंतर एक कठिन सीमा नहीं है और कुछ माइक्रोकंट्रोलर माइक्रोप्रोसेसर और इसके विपरीत अधिक व्यवहार करते हैं। इसलिए मैंने AtMega / Arduino और x86 / x64 को उदाहरण के रूप में लिया, क्योंकि वे उस तरह से व्यवहार करते हैं।
११:०६ पर डेकरॉन

"माइक्रोप्रोसेसरों में एक ROM है जो एक बूटलोडर के लिए पर्याप्त है ... x86 / x64 सिस्टम पर यह बूटलोडर या तो BIOS या UEFI है"। BIOS या UEFI को ऑफ-चिप फ्लैश मेमोरी में संग्रहीत किया जाता है। ऑन-चिप रॉम, निचले स्तर के कार्यों के लिए भी है, जैसे कि माइक्रोकोड का प्रारंभ।
बेन वोइग्ट

@ डाकरॉन: मैं एक माइक्रोप्रोसेसर और माइक्रोकंट्रोलर के बीच की रेखा को इस आधार पर खींचता हूं कि क्या पता बस में किसी अन्य चीज के बिना गैर-तुच्छ प्रयोजनों के लिए प्रयोग करने योग्य डिज़ाइन किया गया है। 8031 को छोड़कर यह योग्य नहीं होगा कि यह कार्यात्मक रूप से 8051 (जो निश्चित रूप से एक माइक्रोकंट्रोलर है) जो आंतरिक रोम में कुछ भी उपयोगी होने के रूप में निर्दिष्ट नहीं है , लेकिन अन्यथा आंतरिक भंडारण से पूरी तरह से उपयोग करने के लिए डिज़ाइन किया जाएगा)। आरसीए / सीडीपी 1802 की तरह कुछ योग्य नहीं होगा, भले ही इसका उपयोग एलईडी
नीमटेग

... कोई बाहरी रैम और रॉम के साथ, क्योंकि रैमलेस / रोम रहित डिज़ाइन तुच्छ कार्यों तक सीमित हैं। एक टीएमएस 32050 जैसा कुछ अगर मुझे याद है कि एक बूटलोडर और कुछ हज़ार शब्दों की रैम के 16-बिट शब्द आंतरिक रूप से एक माइक्रोकंट्रोलर के रूप में योग्य होंगे; हालांकि कई अनुप्रयोगों में अधिक रैम जोड़ने की आवश्यकता होती है, अगर UART के माध्यम से किसी अन्य सिस्टम से जुड़ा होता है, तो यह अपनी मेमोरी बस पर बिना किसी उद्देश्य के कई उद्देश्यों की पूर्ति कर सकता है।
सुपरकैट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.