आप यह कैसे निर्धारित करते हैं कि आपको माइक्रोकंट्रोलर के लिए कितनी फ्लैश / रैम की आवश्यकता है?

Question

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

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

क्या आपके पास एक प्रोटोटाइप के लिए सिर्फ एक मांसल माइक्रोकंट्रोलर है और फिर आपके पास एक काम करने वाला उत्पाद है?

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

अच्छा अभ्यास क्या माना जाता है?

Comments

यह मुझे लगता है कि यह संभव होना चाहिए, एक सूचना सिद्धांत के दृष्टिकोण से, कार्य विनिर्देश से रैम आवश्यकता का अनुमान लगाने के लिए (परिमाण तर्क शैली)। हम्मम ...

— लिंडन व्हाइट

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

— jwsc

Answer 1

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

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

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

हालांकि उत्पादन उद्देश्यों के लिए यह आपको प्रत्येक इकाई से उचित मात्रा में दाढ़ी बनाने देगा।

Comments

अपनी व्यक्तिगत परियोजनाओं के लिए मैं एक समान दृष्टिकोण का उपयोग करने के लिए हूं। इसी तरह की विधि मेरे साथ ही कार्यालय में रेंगती है। यह गलत नहीं है, यह काम करता है, लेकिन क्या बेहतर तरीके हैं आदि। इनपुट की सराहना करें!

— efox29

"वास्तविक" वातावरण में निश्चित रूप से बेहतर तरीके होंगे, चलो अन्य उत्तरों की प्रतीक्षा करें!

— डेविड

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

— स्कॉट सीडमैन

Answer 2

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

हालाँकि यदि आप एक उद्धरण जीतना चाहते हैं, तो आपको अपने ग्राहक को कुछ भी लागू करने के लिए पैसे देने से पहले एक कीमत बतानी होगी ।

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

इस "कैसे" में एक सॉफ्टवेयर डिजाइन के बारे में सोचना भी शामिल है, जैसे सवालों का जवाब देना:

• क्या आपको एक ऑपरेटिंग सिस्टम की आवश्यकता है? कौनसा? उसे किन संसाधनों की आवश्यकता है?
• क्या आप एक स्तरित वास्तुकला करना चाहते हैं? इसके लिए इंटरफेस की आवश्यकता होती है, जो रैम का उपभोग कर सकते हैं
• आपके उद्देश्य के लिए कौन सी लाइब्रेरी पहले से उपलब्ध और उपयोगी / आवश्यक हैं, और उन्हें कितनी मेमोरी की आवश्यकता है (एक अच्छा लाइब्रेरी डॉक्यूमेंटेशन इसका उत्तर कम से कम एक संदर्भ बिल्ड पर आधारित है)?
• आपको अपने स्वयं के ड्राइवरों और आपके आवेदन के लिए किन संरचनाओं और चर को लागू करना है?

उन सभी मूल्यों को समेटना आपको एक मोटा अनुमान देता है। आप कितनी दूर तक भरोसा कर सकते हैं कि आपका विश्लेषण कितना विस्तृत है, और यह आपके अनुभव पर निर्भर करता है :-)
आपके अनुमान का कम से कम 30..50% का मार्जिन जोड़ना निश्चित रूप से एक अच्छा विचार है।

एक बार जब आपका उत्पाद समाप्त हो जाता है और आपके पास लगभग 80..90% रैम का उपयोग होता है, तो आप यह सुनिश्चित कर सकते हैं कि आपका चयन सही था - कम से कम रैम के बारे में।

Comments

पुन: "उपयोग में 80..90% रैम"। मानक अभ्यास यह सुनिश्चित करने के लिए है कि आप केवल सीपीयू और मेमोरी दोनों में अधिकतम 50% उपयोग का उपयोग करें ताकि भविष्य के उन्नयन और बग फिक्स को समायोजित करने में सक्षम हो सकें।

— डंक

@ डंक: व्यवसाय पर निर्भर करता है। मोटर वाहन में, एसओपी में सभी संसाधनों (सीपीयू, रैम, फ्लैश) का 80% आमतौर पर स्वीकार किया जाता है। उदाहरण के लिए, सस्ते उपभोक्ता इलेक्ट्रॉनिक्स यह और भी अधिक हो सकता है: केवल 2-3 साल के जीवनकाल के साथ सिस्टम में अपग्रेड होने की कितनी संभावना है?

— माइक

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

— एरोनडी

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

— हारून

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

— मार्क बूथ

Answer 3

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

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

अगर वह काम नहीं करता है, तो अगली चीज जो आप करेंगे वह है एक उच्च स्तरीय सॉफ्टवेयर डिजाइन और मॉड्यूल को कार्यक्षमता में तोड़ना। आप सिस्टम में प्रत्येक मॉड्यूल के लिए प्रत्येक फ़ंक्शन के लिए कोड की पंक्तियों का अनुमान लगाते हैं। फिर आप कोड की पंक्तियों को कोड मेमोरी की ballpark अनुमान में परिवर्तित करने के लिए एक सूत्र का उपयोग कर सकते हैं। आप किसी भी असामान्य मेमोरी आवश्यकताओं (बड़े सरणियों की तरह) की भी जांच करेंगे और इसे समायोजित करने के लिए कुछ अनुमान जोड़ेंगे। फिर उस कुछ के ऊपर कुछ प्रतिशत जोड़कर जो कुछ भी आप चूक गए हैं उसे कवर करने के लिए। फिर डबल कि 50% उपयोग की आवश्यकता को पूरा करने के क्रम में।

हाँ, समय लगता है। हां, सभी हुप्स के माध्यम से कूदना आवश्यक है क्योंकि हार्डवेयर को बदलने के बाद वास्तव में कठिन होता है।

Comments

हम कोड की लाइनों को कोड मेमोरी में बदलने का फॉर्मूला कहां से पा सकते हैं?

— ईज़ीओहम

यह इस बात पर निर्भर करता है कि आप किस भाषा और संकलक का उपयोग करते हैं। यदि आप असेंबलर का उपयोग करते हैं तो एक पंक्ति लगभग एक शब्द मेमोरी के बराबर होती है (जो भी आपके चिप का शब्द आकार है)। यदि आप C का उपयोग करते हैं तो यह लगभग 3-5 शब्द एक पंक्ति हो सकता है और यदि आप C ++ या कुछ और भी अधिक जटिल उपयोग करते हैं तो यह अभी भी बहुत अधिक हो सकता है। सबसे अच्छी बात यह है कि उस भाषा में लिखे गए कुछ कार्यक्रमों को संकलित करना और औसत पाने के लिए कोड लाइनों की तुलना कोड मेमोरी से करना।

— डेकरॉन

Answer 4

आम तौर पर, माइक्रोकंट्रोलर विक्रेताओं ने अपने उपकरणों में स्मृति की एक सीमा रखी है जो विशिष्ट अनुप्रयोगों के लिए उपयुक्त है। इसलिए, यदि आपको एक छोटे पदचिह्न डिवाइस में केवल कुछ I / O पिन और एक SPI की आवश्यकता है, तो आपको 500 kBytes Flash और 64 kBytes RAM वाले कुछ भी जहाज मिलने की संभावना नहीं होगी। बड़े उपकरणों के साथ, जो एसओसी पैकेज के करीब हैं, यहां तक ​​कि सबसे छोटा लगभग निश्चित रूप से काफी बड़ा है जब तक कि आप कुछ गंभीर संख्या को क्रंच करने की योजना नहीं बना रहे हैं जैसे कि छवि प्रसंस्करण।

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

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

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