माइक्रोकंट्रोलर प्रोग्रामिंग बनाम ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

Question

मैंने C ++ (B-Tree, Hashing Algorithms, Double Linked Lists) बनाते हुए कुछ बेसिक ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की है और मैंने C में छोटे प्रोजेक्ट किए हैं (जैसे वैज्ञानिक कैलकुलेटर बनाना आदि)

सॉफ्टवेयर प्रोग्रामिंग (विशेष रूप से माइक्रो नियंत्रकों के लिए) सॉफ्टवेयर / ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग से कितना अलग है मानसिकता और "सोच" जो प्रोग्रामर के पास है?

क्या आमतौर पर दूसरे को मेरे अधिकांश लोगों की तुलना में कठिन माना जाता है?

मेरी पृष्ठभूमि के साथ (जैसा कि ऊपर वर्णित है) क्या मुझे हार्डवेयर प्रोग्रामिंग में जाने के लिए बहुत अधिक तैयारी की आवश्यकता होगी या क्या मैं बहुत अधिक तैयारी के बिना सीधे गोता लगा सकता हूं?

Comments

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

— drxzcl

@rrazd, मैंने देखा कि आपने arduino टैग को शामिल किया है। क्या यह इसलिए है क्योंकि आप arduino वायरिंग भाषा और पुस्तकालयों का उपयोग करना चाहते हैं? या आप अपने एम्बेडेड अनुप्रयोगों को शुद्ध सी में लिख रहे होंगे? यदि आप arduino वातावरण के साथ रहना चाहते हैं, तो यह बहुत सुरक्षित है और चारों ओर खेलना आसान है क्योंकि उन्होंने हार्डवेयर से दूर कुछ सार किया है।

— जॉन एल

@ मैं शुरुआत के लिए एक arduino बोर्ड का उपयोग करने की योजना है। क्या यह सी भाषा के समान नहीं है? मुझे लगा कि इसमें वही मूल अवधारणाएँ शामिल हैं ....

— rrazd

मैं सोच रहा हूं कि क्या आप का मतलब है कि कितने लोग 'I / O प्रोग्रामिंग' कहेंगे, या यदि आप कोड के साथ हार्डवेयर को फिर से व्यवस्थित करने का अनुमान लगाते हैं। आर्डिनो निश्चित रूप से पूर्व है; बाद वाला FPGAs का डोमेन होगा।

— JustJeff

@ श्राद्ध - मैंने शीर्षक बदल दिया; "हार्डवेयर प्रोग्रामिंग" बहुत अधिक लगता है जैसे एचडीएल (हार्डवेयर विवरण भाषा), जैसे वीएचडीएल और वेरिलोग, जो एफपीजीए और सीपीएलडी प्रोग्राम करने के लिए उपयोग किए जाते हैं।

— स्टीवनवह

Answer 1

अधिकांश माइक्रोकंट्रोलर्स के साथ काम करते समय आपको ऑब्जेक्ट-ओरिएंटेड प्रतिमान को पूरी तरह से त्यागना होगा।

माइक्रोकंट्रोलर आम तौर पर रजिस्टर होते हैं- और रैम-सीमित, धीमी घड़ी की दरों के साथ और कोई पाइपलाइनिंग / समानांतर कोड पथ नहीं। उदाहरण के लिए, आप एक PIC पर जावा के बारे में भूल सकते हैं।

आपको विधानसभा-भाषा की मानसिकता में उतरना होगा, और प्रक्रियात्मक रूप से लिखना होगा।

आपको अपना कोड अपेक्षाकृत सपाट रखना होगा और पुनरावृत्ति से बचना होगा, क्योंकि रैम सीमाएं अक्सर स्टैक मुद्दों को जन्म दे सकती हैं।

आपको यह सीखना होगा कि इंटरप्ट सर्विस रूट को कैसे लिखना है जो कुशल हो (आमतौर पर असेंबली लैंग्वेज में)।

आपको कोड को मैन्युअल रूप से, असेंबली भाषा में, कार्यक्षमता को कार्यान्वित करने के लिए कोड को रिफ्लेक्टर करना पड़ सकता है जो कंपाइलर समर्थन नहीं करता (या खराब समर्थन करता है)।

आपको गणितीय कोड लिखना होगा जो शब्द के आकार और अधिकांश माइक्रोकंट्रोलर की एफपीयू क्षमताओं की कमी को ध्यान में रखता है (यानी 8-बिट माइक्रो = बुराई पर 32-बिट गुणा करना)।

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

Comments

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

— क्रिस स्ट्रैटन

यह सब वस्तु-उन्मुखता को छोड़कर सच है। आप संभवतः OO विशेषताओं वाली भाषा का उपयोग नहीं करेंगे लेकिन यह ऑब्जेक्ट ओरिएंटेशन से इंकार नहीं करता है। माइक्रोकंट्रोलर्स के लिए आप सभी हार्डवेयर बाह्य उपकरणों (ADCs, सीरियल बस नियंत्रकों, PWM, आदि) के लिए ड्राइवरों को लिखने जा रहे हैं। इस तरह के ड्राइवर को हमेशा ऑब्जेक्ट-ओरिएंटेड तरीके से लिखा जाना चाहिए ताकि यह 1) स्वायत्त हो और बाकी प्रोग्राम के बारे में पता न चले / परवाह न हो और 2) प्राइवेट इनकैप्सुलेशन को लागू करना ताकि बाकी का प्रोग्राम न हो सके अंदर जाओ और इसके साथ बेला। यह C में 100% संभव है और प्रदर्शन को प्रभावित नहीं करेगा।

— लंडिन

मैं पहले वाक्य से दृढ़ता से असहमत हूं, मेरे सभी माइक्रोकंट्रोलर प्रोजेक्ट्स C ++ और ऑब्जेक्ट ओरिएंटेड अप्रोच के साथ बनाए गए थे, और हमारे द्वारा उपयोग किया जाने वाला माइक्रोस बहुत बड़ा नहीं था (ROM का 32kB), ऑब्जेक्ट ओरिएंटेड बूटलोडर 2kB से कम में था, मैं वास्तव में सीमा नहीं देखते हैं। आप पागल सामान नहीं कर सकते, लेकिन डिजाइन वस्तु उन्मुख हो सकता है कोई समस्या नहीं है।

— आर्सेनल

@ अर्सेनल नोट मैंने कहा 'सबसे', और ध्यान दें कि आप चार साल पुराने धागे पर टिप्पणी कर रहे हैं। :)

— एडम लॉरेंस

मैं पहले और आखिरी वाक्य से पूरी तरह असहमत हूं। और असेंबली का उपयोग बहुत कम ही किया जाता है और, ज्यादातर, केवल 8-बिट MCU के लिए (बस इस फ़ोरम की जाँच करें, असेंबली कोड के साथ कितने पद आप पा सकते हैं?)। आप निश्चित रूप से कर सकते हैं और (IMHO) को 32bit MCUs के लिए OO शैली में लिखना चाहिए

— रूसियों Gasilovs

Answer 2

आपको कई चीजों के बारे में सोचने की जरूरत है:

• आप C का उपयोग भाषा के रूप में करेंगे
• आप फ़ंक्शन पॉइंटर्स का उपयोग करके अभी भी ऑब्जेक्ट ओरिएंटेशन की भावना पैदा कर सकते हैं ताकि आप फ़ंक्शन आदि को ओवरराइड कर सकें। मैंने पिछले और वर्तमान प्रोजेक्ट्स में इस पद्धति का उपयोग किया है और बहुत अच्छी तरह से काम करता है। इसलिए OO आंशिक रूप से है लेकिन C ++ अर्थ में नहीं है।

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

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

सूची आगे बढ़ती है, मैं सॉफ्टवेयर प्रोग्रामिंग के मामले में औसत से नीचे हूं, मुझे यकीन है कि बेहतर अभ्यास हैं।

Comments

+1 के लिए "यदि आप चाहें तो OO प्रतिमानों का उपयोग कर सकते हैं"। दरवाजे पर आपको जो जांचने की आवश्यकता है वह ओओ डिजाइन नहीं है। OOD एक दर्शन है जो आपको संबंधित कोड और डेटा को एक साथ रखने के लिए प्रोत्साहित करता है। ओओ को जिस तरह से पीछे छोड़ने की जरूरत है, वह यह है कि उद्यम प्रणालियों में ओओ को लागू किया जाता है, जिसमें अमूर्तता की कई परतें होती हैं, नियंत्रण का उलटा और यह सब जाज है। आपके फर्मवेयर का कार्य हार्डवेयर को चलाना है, बस।

— drxzcl

Answer 3

मैं दोनों करता हूं, इसलिए यहां मेरा विचार है।

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

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

अनुभवी एम्बेडेड लोग डिबगिंग के लिए ले जाते हैं ... ज्यादातर लोग जो इसे अच्छी तरह से नहीं कर सकते हैं (या बड़ी कंपनियों में काम करते हैं जो बस स्वीकार करते हैं "फर्मवेयर कठिन है" क्यों एक निश्चित विशेषता के लिए एक उत्तर के रूप में। देर हो रही है)

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

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

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

Answer 4

मैं मान रहा हूँ कि आपका C ++ अनुभव PC- आधारित है।

पीसी से माइक्रोकंट्रोलर पर जाने वाले प्रोग्रामर द्वारा अक्सर की गई त्रुटि यह है कि उन्हें एहसास नहीं है कि सीमित संसाधन कैसे हो सकते हैं। जब आप 100 000 प्रविष्टियों के साथ एक तालिका बनाते हैं, तो एक पीसी पर कोई भी आपको नहीं रोकेगा, या एक प्रोग्राम लिखेगा जो 1MB मशीन कोड के लिए संकलित करता है।
वहाँ रहे हैं माइक्रोकंट्रोलर्स जो विशेष रूप से उच्च अंत में स्मृति संसाधनों का खजाना है, लेकिन यह अभी भी क्या आप करने के लिए इस्तेमाल किया जाएगा से एकदम अलग है। एक शौक परियोजना के लिए आप शायद हमेशा अधिकतम के लिए जा सकते हैं, लेकिन एक पेशेवर परियोजना में आपको अक्सर छोटे डिवाइस के साथ काम करने के लिए मजबूर किया जाएगा क्योंकि यह सस्ता है ।
एक परियोजना पर मैं एक TI MSP430F1101 के साथ काम कर रहा था। प्रोग्राम मेमोरी का 1KB, कॉन्फ़िगरेशन फ्लैश का 128 बाइट्स, रैम का 128 बाइट्स। कार्यक्रम 1K में फिट नहीं था, इसलिए मुझे कॉन्फ़िगरेशन फ्लैश में 23 बाइट्स फ़ंक्शन लिखना था। इन छोटे नियंत्रकों के साथ आप बाइट द्वारा गणना करते हैं । एक अन्य अवसर पर कार्यक्रम मेमोरी 4 बाइट्स बहुत छोटा था। बॉस मुझे अधिक मेमोरी वाले कंट्रोलर का उपयोग नहीं करने देगा, लेकिन इसके बजाय मुझे अतिरिक्त 4 बाइट्स को फिट करने के लिए पहले से ही अनुकूलित मशीन कोड (इसे पहले से असेंबलर में लिखा गया था) को ऑप्टिमाइज़ करना होगा। आपको तस्वीर मिल जाएगी।

जिस प्लेटफ़ॉर्म पर आप काम कर रहे हैं, उसके आधार पर आपको बहुत कम स्तर I / O से निपटना होगा । कुछ विकास परिवेशों में एक एलसीडी पर लिखने के लिए कार्य होते हैं, लेकिन दूसरों पर जो आप अपने दम पर कर रहे हैं, और एलसीडी के डेटशीट को पढ़ने के लिए शुरू से अंत तक यह जानना होगा कि इसे कैसे नियंत्रित किया जाए।
आपको एक रिले को नियंत्रित करना पड़ सकता है, जो कि एलसीडी की तुलना में आसान है, लेकिन इसके लिए आपको माइक्रोकंट्रोलर के रजिस्टर स्तर पर जाने की आवश्यकता होगी। फिर से एक डेटशीट या उपयोगकर्ता पुस्तिका। आपको माइक्रोकंट्रोलर की संरचना को जानना होगा, जिसे आप एक ब्लॉक आरेख में पाएंगे, फिर से डेटशीट में। माइक्रोप्रोसेसर के दिनों में हमने एक प्रोग्रामिंग मॉडल के बारे में बात की, जो मूल रूप से प्रोसेसर के रजिस्टरों का एक लाइनअप था। आज के माइक्रोकंट्रोलर इतने जटिल हैं कि सभी रजिस्टरों का विवरण 100 पृष्ठों के डेटाशीट का सबसे अच्छा हिस्सा ले सकता है। IIRC सिर्फ MSP430 के लिए घड़ी मॉड्यूल का वर्णन 25 पृष्ठों लंबा था।

$\mu$

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

Comments

मैंने अटारी 2600 के लिए गेम लिखा है, जो एक सीमित मंच है; मेरा पहला प्रकाशित गेम अनिवार्य रूप से 4K कोड था (चूंकि मेरे पास 32K कार्ट था, मैंने कुछ अतिरिक्त उपहार जोड़े, लेकिन 4K संस्करण पूरी तरह से खेला गया); रैम 128 बाइट्स है। मुझे यह चिंतन करना दिलचस्प लगता है कि जिस वर्ष मैंने उस खेल (2005) को लिखा था, अन्य खेल प्रकाशित हुए थे, जो कि शाब्दिक रूप से एक लाख गुना बड़े थे।

— सुपरकैट

@ सुपरकैट - हाँ, लेकिन यह उम्मीद की जानी थी, 2005 में अटारी 2600 पहले से ही 200 साल पुराना था! मैंने कभी भी एफ़पीएस जैसे एक्शन गेम नहीं खेले हैं, लेकिन जब मुझे लगता है कि उन्हें खेलने के लिए क्या चाहिए, तो आपके सीपीयू की तुलना में बहुत अधिक शक्तिशाली एक GPU, दोनों प्रोग्रामेटिक और विद्युत रूप से, मैं मदद नहीं कर सकता लेकिन अपने सिर को हिलाऊ :-)। मैंने 16k TRS-80 IIRC पर शतरंज (सरगुन) खेला। मेरे भाई के फ्लाइट सिमुलेटर की अधिक आवश्यकता नहीं थी।

— स्टीवन्वह

काफी 200 साल पुराना नहीं है। यह 1977 में शुरू हुआ, इसलिए यह 30 भी नहीं था। जबकि मैं मानता हूं कि तकनीकी शब्दों में यह पहले से था, मैं अभी भी इस तथ्य से उड़ा रहा हूं कि न केवल सौ-होल्ड वृद्धि है, और न ही एक हजार गुना वृद्धि , लेकिन RAM और कोड आकार दोनों में एक लाख गुना वृद्धि। 2600 के बाद से स्पीड ने इतना बढ़ावा नहीं दिया, क्योंकि 1.19MHz और नए सिस्टम केवल कम GHz रेंज में हैं। वे 2600 की तुलना में प्रति चक्र बहुत अधिक कर सकते हैं (जो प्रत्येक चक्र में 1/76 एक वीडियो लाइन उत्पन्न कर सकता था) लेकिन मुझे नहीं लगता कि वे उपवास के रूप में 1,000,000x हैं।

— सुपरकैट

Answer 5

"हार्डवेयर प्रोग्रामिंग" का अर्थ बहुत सारी चीजें हो सकती हैं। एक बहुत छोटी चिप प्रोग्रामिंग (10F200, 512 निर्देश, कुछ बाइट्स RAM) का प्रोग्रामिंग लगभग एक इलेक्ट्रॉनिक सर्किट डिजाइन करने जैसा हो सकता है। दूसरी तरफ प्रोग्रामिंग एक बड़ा कोर्टेक्स माइक्रोकंट्रोलर (1 एमबी फ्लैश, 64 केबी रैम) एक बड़े जीयूआई टूलकिट का उपयोग करके पीसी / जीयूआई प्रोग्रामिंग की तरह हो सकता है। IMHO एक अच्छा एंबेडेड / रियल-टाइम प्रोग्रामर को सॉफ्टवेयर एंवायरिंग साइड से और सर्किट डिज़ाइन साइड से कौशल की आवश्यकता होती है। बड़े यूसी के लिए सी ++ एक अच्छी भाषा विकल्प है, बहुत छोटे लोगों के लिए सी एकमात्र विकल्प हो सकता है। असंबद्ध ज्ञान आसान हो सकता है, लेकिन मैं पूरी तरह से विधानसभा में गंभीर परियोजनाओं को करने की सिफारिश नहीं करूंगा।

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

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

Answer 6

प्रत्येक arduino लाइब्रेरी विधि के लिए जिसे आप कहते हैं कि C / C ++ कोड का एक धन है जो इसे संभव बनाता है, यह केवल एपीआई के रूप में उपयोग करने के लिए आपके लिए अच्छी तरह से पैक किया गया है। निर्देशिका हार्डवेयर / arduino / * के तहत arduino स्रोत कोड पर एक नज़र डालें और आपको आपके लिए लिखे गए सभी C / C ++ दिखाई देंगे जो सीधे AVR माइक्रोकंट्रोलर के रजिस्टरों के साथ इंटरैक्ट करते हैं। यदि आपका उद्देश्य इस तरह से (सीधे हार्डवेयर के लिए) सामान लिखना सीखना है, तो कवर करने के लिए बहुत कुछ है। यदि आपका उद्देश्य उनके पुस्तकालयों का उपयोग करके काम करने के लिए कुछ प्राप्त करना है, तो इस बारे में बात करने के लिए बहुत कुछ नहीं हो सकता है क्योंकि आपके लिए अधिकांश कड़ी मेहनत की जाती है और उनके पुस्तकालयों और विकास पर्यावरण का उपयोग करना बहुत आसान है।

अंगूठे के कुछ नियम हालांकि संसाधन विवश उपकरणों के साथ काम करते हैं जो या तो आर्दीनो पर्यावरण या अन्य पर लागू हो सकते हैं:

इस बात से अवगत रहें कि आप कितनी मेमोरी का उपयोग कर रहे हैं। दोनों कोड आकार (जो फ्लैश मेमोरी में चला जाता है) और स्थिर रैम उपयोग (आपके कोड में निरंतरता जो हमेशा रैम में मौजूद होती है)। मैं तर्क दूंगा कि स्थिर रैम उपयोग थोड़ा अधिक महत्वपूर्ण है, क्योंकि यह ओवर लुक करना आसान है। आपके स्टैक, ढेर, और स्थिरांक के साथ काम करने के लिए आपके लिए केवल 1000 बाइट्स होना असामान्य नहीं है। इस बात में समझदारी रखें कि आप इसे कैसे खर्च करते हैं, इसलिए जब बाइट्स या अहस्ताक्षरित चार (प्रत्येक बाइट प्रत्येक) पर्याप्त होगा तब पूर्णांक (4-बाइट्स) की लंबी सरणियों जैसी चीजों से बचें। यहाँ एक और उत्तर कुछ अन्य महत्वपूर्ण बिंदुओं को बहुत अच्छी तरह से कवर करता है इसलिए मैं यहाँ रुक जाऊँगा, मैं मुख्य रूप से इस बिंदु को प्राप्त करना चाहता था कि अगर आप arduino लाइब्रेरी का उपयोग नहीं कर रहे हैं और अपनी स्वयं की सी लाइब्रेरी लिख रहे हैं तो बहुत कुछ है ।

Answer 7

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

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

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

नए हार्डवेयर से निपटने के दौरान बहुत सारे डेटाशीट पढ़ने के लिए तैयार रहें - मुझे लगता है कि यह "मानसिकता" प्रश्न भाग से संबंधित हो सकता है :) निश्चित रूप से कुछ ईई और हार्डवेयर ज्ञान की आवश्यकता होगी।

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

Comments

चिंताओं के संदर्भ में, डायनेमिक मेमोरी (री) आवंटन के आसपास के लोग समय की तुलना में पारंपरिक OO के लिए एक बड़ा बाधा हैं ।

— क्रिस स्ट्रैटन

शायद आप सही हैं। लेकिन ऐसे लोग हैं जो एमएसडीओएस वास्तविक मोड सॉफ़्टवेयर के लिए 80-90 के दशक में प्रोग्राम करते हैं, 64K (डेटा मेमोरी सेगमेंट) रैम स्पेस उपलब्ध है और उनके लिए यह "प्राकृतिक" था। हो सकता है कि MSDOS पीसी अधिक "एम्बेडेड" था आज STM32F4 से पर्यावरण :)

— गढ़

STM32F4 में आमतौर पर फ्लैश के रूप में अधिक प्रोग्राम मेमोरी होती है, लेकिन पीसी आमतौर पर म्यूटेबल रनटाइम ऑब्जेक्ट्स को स्टोर करने के लिए अधिक रैम मेमोरी के साथ आता है। जबकि खंडित संबोधन द्वारा मजबूर की गई पूरी दूर की बात एक पीड़ा थी, दोनों में एक सच्चे एमएमयू की कमी थी, और यह कम रैम के साथ सिस्टम पर एक चिंता का विषय है, जो एसटीएम 32 एफ 4 है। इसके अलावा पीसी अपटाइम्स कम और स्वीकार्य विफलता दर अधिक है।

— क्रिस स्ट्रैटन