PIC32 बनाम dsPIC बनाम एआरएम बनाम AVR, क्या आर्किटेक्चर मायने रखता है जब हम सी-भाषा वैसे भी प्रोग्रामिंग कर रहे हैं? [बन्द है]


10

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

अब PIC32 के लिए हम MPLAB का उपयोग करते हैं लेकिन ARM कॉर्टेक्स-M0 के लिए, हम Atmel स्टूडियो का उपयोग करेंगे। हम दोनों प्लेटफार्मों में सी-भाषा का उपयोग करेंगे। मेरी चिंता का विषय यह है, हम दो 32 बिट माइक्रोकंटोलर (एक ही कंपनी से) का उपयोग कर रहे होंगे, लेकिन अलग-अलग आर्किटेक्चर होंगे। इसके लिए हमें दो अलग-अलग उपकरणों को सीखने की आवश्यकता होगी और हमारे "सीखने की अवस्था" + वितरण समय को बढ़ाएगा। लेकिन दूसरी ओर, मुझे यह भी लगता है कि चूंकि हम दोनों ही मामलों में सी-लैंग्वेज का उपयोग कर रहे हैं, इसलिए एआरएम के लिए सीखने की अवस्था को नहीं सुना जाना चाहिए और यह उस प्रोसेसर को भी देखने लायक है।

मेरा मुख्य प्रश्न यह है कि जब हम C-Language में प्रोग्रामिंग कर रहे हैं, तो यह माइक्रोकंट्रोलर के इंटर्ल्स के अमूर्त होने पर आर्किटेक्चर में कितना बड़ा अंतर है। और MPLAP और Atmel स्टूडियो में मुख्य अंतर क्या हैं , सी-भाषा प्रोग्रामिंग पर विचार कर रहे हैं।


2
अगर चीजें PIC32 के साथ काम कर रही हैं, तो स्विचिंग का क्या मतलब है? यहां तक ​​कि अगर कोड पूरी तरह से पोर्ट करता है (यह नहीं होगा), अभी भी उपयोग करने के लिए नई टूल चेन और आईडीई है। क्या बात है? धार्मिक कारणों से स्विच करना या "एआरएम आधारित" (या कुछ और आधारित) मूर्खतापूर्ण है। आपके पास एक अच्छा कारण होना चाहिए, लेकिन आपने हमें नहीं दिखाया है।
ओलिन लेट्रोप 14

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

एक बात जो मुझे पता चली कि Atmel Studio MPLAB youtube वीडियो की
इंजीनियर

जवाबों:


20

यह काफी विचारणीय विषय है। मैं अपने लिए (AVR, ARM, MSP430) बोल सकता हूं।

अंतर 1 (सबसे महत्वपूर्ण) परिधीय में है। MCU में से प्रत्येक में UART, SPI, टाइमर आदि समान हैं - बस रजिस्टर नाम और बिट्स अलग हैं। अधिकांश समय यह मुख्य मुद्दा था जब मुझे चिप्स के बीच कोड को स्थानांतरित करते समय सामना करना पड़ता था। समाधान: अपने ड्राइवरों को एक सामान्य एपीआई के साथ लिखें, ताकि आपका एप्लिकेशन पोर्टेबल हो सके।

अंतर 2 मेमोरी आर्किटेक्चर है। यदि आप एक एवीआर पर लगातार फ़्लैश डालना चाहते हैं तो आपको उन्हें पढ़ने के लिए विशेष विशेषताओं और विशेष कार्यों का उपयोग करना होगा। एआरएम दुनिया में आप सिर्फ एक पॉइंटर को रोकते हैं क्योंकि एक ही एड्रेस स्पेस होता है (मुझे नहीं पता कि छोटे PIC इसे कैसे हैंडल करते हैं, लेकिन मान लेंगे कि वे AVR के करीब हैं)।

अंतर 3 डिक्लेरेशन डिक्लेरेशन और हैंडलिंग है। avr-gccहै ISR()मैक्रो। ARM का सिर्फ एक फ़ंक्शन नाम है (जैसे someUART_Handler () - यदि आप CMSIS हेडर और स्टार्टअप कोड का उपयोग करते हैं)। एआरएम इंटरप्ट वैक्टर को कहीं भी (रैम सहित) रखा जा सकता है और रनटाइम पर संशोधित किया जा सकता है (यदि आपके पास दो अलग-अलग यूएआर प्रोटोकॉल हैं जो स्विच किए जा सकते हैं)। AVR में केवल "मुख्य फ़्लैश" या "बूटलोडर सेक्शन" में वैक्टर का उपयोग करने का विकल्प होता है (इसलिए यदि आप अलग से व्यवधान को हैंडल करना चाहते हैं तो आपको ifस्टेटमेंट का उपयोग करना होगा )।

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

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

मेरी राय में, एआरएम के बारे में अच्छी बात "मोनोकल्चर" है - कई कंपाइलरों की उपलब्धता (जीसीसी, केइल, आईएआर ... कुछ नाम रखने के लिए), कई मुफ्त और न्यायिक रूप से समर्थित आईडीई (कम से कम एनएक्सपी, एसटीएम 32, सिलिकॉन लैब्स के लिए) नॉर्डिक), कई डिबग टूल (SEGGER - विशेष रूप से ओजोन, ULINK, OpenOCD ...) और कई चिप विक्रेता (मैं उन्हें नाम देना भी शुरू नहीं करूंगा)। PIC32 ज्यादातर माइक्रोचिप तक ही सीमित है (लेकिन यह केवल तभी मायने रखता है जब आपको उनके उपकरण पसंद न हों।

जब सी कोड की बात आती है। यह 99% समान है, एक ifबयान समान है, एक लूप उसी तरह से काम करता है। हालाँकि आपको मूल शब्द आकार के बारे में ध्यान रखना चाहिए। उदाहरण के लिए forयदि आप uint8_tकाउंटर के लिए उपयोग करते हैं तो एवीआर पर एक लूप सबसे तेज़ होता है , जबकि एआरएम पर uint32_tसबसे तेज़ टाइप (या int32_t) होता है। यदि आप छोटे प्रकार का उपयोग करते हैं तो एआरएम को हर बार 8-बिट ओवरफ्लो की जांच करनी होगी।

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


3
“AVR सबसे तेज़ है यदि आप काउंटर के लिए uint8_t का उपयोग करते हैं, जबकि ARM पर uint32_t सबसे तेज़ प्रकार (या int32_t) है। यदि आपने छोटे प्रकार का उपयोग किया है तो एआरएम को हर बार 8-बिट ओवरफ्लो की जांच करनी होगी। " यदि आपको केवल कम से कम 8 बिट की आवश्यकता है तो आप uint_fast8_t का उपयोग कर सकते हैं।
माइकल

@ मिसेल - सुनिश्चित करें कि आप _fast प्रकारों का उपयोग कर सकते हैं, लेकिन आप अतिप्रवाह व्यवहार पर भरोसा नहीं कर सकते। मेरे gcc के stdint.h में मेरे पास "typedef unsign int uint_fast8_t" है, जो मूल रूप से uint32_t :) है
filo

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

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

11

मैंने चार अलग-अलग निर्माताओं से कई एमसीयू का उपयोग किया है। हर बार फिर से मुख्य काम बाह्य उपकरणों से परिचित होना है।

उदाहरण के लिए एक UART स्वयं भी जटिल नहीं है और मुझे अपने ड्राइवर पोर्ट आसानी से मिल जाते हैं। लेकिन आखिरी बार मुझे घड़ियों को पाने में लगभग एक दिन लगा, I / O पिन्स इंटरप्ट, इनेबल आदि।

GPIO बहुत जटिल हो सकता है। बिट-सेट, बिट-क्लियर, बिट-टॉगल, विशेष कार्य सक्षम / अक्षम, त्रि-स्थिति। आगे आपको रुकावट मिलती है: कोई भी बढ़त, वृद्धि, गिरावट, स्तर-निम्न, स्तर-उच्च, आत्म समाशोधन या नहीं।

फिर I2C, SPI, PWM, टाइमर और दो दर्जन से अधिक प्रकार के परिधीय प्रत्येक अपनी घड़ी सक्षम बनाता है और हर बार रजिस्टर नए बिट्स के साथ अलग होते हैं। उन सभी के लिए डेटाशीट पढ़ने में कई घंटे लगते हैं कि किस परिस्थिति में किस तरह सेट किया जाए।

पिछले निर्माता के पास बहुत सारे कोड उदाहरण थे जो मुझे अनुपयोगी लगे। सब कुछ अमूर्त था। लेकिन जब मैंने इसे ट्रेस किया, तो कोड छह हो गया! फ़ंक्शन का स्तर GPIO बिट सेट करने के लिए कॉल करता है। यदि आपके पास 3GHz प्रोसेसर है, लेकिन 48MHz के MCU पर नहीं है तो अच्छा है। अंत में मेरा कोड एक पंक्ति था:

GPIO->set_output = bit.

मैंने अधिक सामान्य ड्राइवरों का उपयोग करने की कोशिश की है लेकिन मैंने हार मान ली है। एक MCU पर आप हमेशा अंतरिक्ष और घड़ी चक्र के साथ संघर्ष कर रहे हैं। मैंने पाया कि यदि आप 10KHz पर एक इंटरप्ट रूटीन में एक विशिष्ट तरंग उत्पन्न करते हैं तो एब्सट्रैक्शन लेयर सबसे पहले खिड़की से बाहर जाती है।

इसलिए अब मेरे पास काम करने के लिए सब कुछ है और मैं योजना नहीं बना रहा हूं कि जब तक एक बहुत, बहुत अच्छे कारण के लिए फिर से स्विच न करें।

उपरोक्त सभी को आपके द्वारा बेचे जाने वाले कितने उत्पादों पर परिशोधन किया जाना चाहिए और आप क्या बचाते हैं। एक मिलियन बेचना: एक अलग प्रकार पर स्विच करने के लिए 0.10 की बचत का मतलब है कि आप सॉफ्टवेयर मैन-घंटे पर 100.000 खर्च कर सकते हैं। 1000 बेचना आपके पास खर्च करने के लिए केवल 100 है।


1
व्यक्तिगत रूप से यही कारण है कि मैं असेंबलर के साथ रहना। लवली बाइनरी, कोई अमूर्त नहीं।
इयान ब्लांड

सी के प्रीप्रोसेसर सामान के साथ बहुत अच्छा कर सकते हैं, खासकर जब __builtin_constant आंतरिक के साथ संयुक्त। यदि प्रत्येक आई / ओ के लिए एक परिभाषित स्थिरांक प्रपत्र (पोर्ट संख्या * 32 + बिट संख्या) के सा है, यह एक मैक्रो के लिए लिखने के लिए संभव है OUTPUT_HI(n)जो कोड बराबर निकलेगा को GPIOD->bssr |= 0x400;अगर n0x6A की तरह एक निरंतर है, लेकिन अगर एक साधारण सबरूटीन फोन nहै स्थिर नहीं है। कहा गया है कि, सबसे अधिक विक्रेता एपीआई मैं औसत दर्जे और भयानक के बीच की सीमा को देखा है।
सुपरकैट

8

यह एक उत्तर से अधिक एक राय / टिप्पणी है।

आप नहीं चाहते हैं और सही तरीके से उपयोग किए जाने पर C. C ++ में प्रोग्रामिंग नहीं की जानी चाहिए , यह कहीं बेहतर है। (ठीक है, मुझे स्वीकार करना होगा, जब गलत तरीके से उपयोग किया जाता है तो यह सी से कहीं अधिक खराब होता है) जो आपको उन चिप्स तक सीमित करता है जिनके पास एक (आधुनिक) सी ++ कंपाइलर है, जो कि जीसीसी द्वारा समर्थित है, जो AVR (साथ) कुछ सीमाओं, फिलो में एक गैर-समान पता स्थान की समस्याओं का उल्लेख किया गया है), लेकिन लगभग सभी PIC (PIC32 का समर्थन किया जा सकता है, लेकिन मुझे अभी तक कोई भी अच्छा पोर्ट नहीं मिला है)।

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

जब आप हार्डवेयर को कोड कर रहे होते हैं तो आप या तो कुछ अमूर्त परत (अक्सर निर्माता द्वारा प्रदान की जाती हैं) का उपयोग कर सकते हैं या अपना खुद का लिख ​​सकते हैं (डेटाशीट और / या उदाहरण कोड के आधार पर)। IME मौजूदा C एब्स्ट्रक्शन (mbed, cmsis, ...) अक्सर फ़ंक्शनली (लगभग) सही होते हैं, लेकिन प्रदर्शन में बुरी तरह से विफल हो जाते हैं (एक पिन सेट ऑपरेशन के लिए अप्रत्यक्ष की 6 परतों के बारे में पुराने पड़ाव की जाँच करें), प्रयोज्य और पोर्टेबिलिटी। वे आपके लिए विशेष चिप की सभी कार्यक्षमता को उजागर करना चाहते हैं, जो लगभग सभी मामलों में आपको ज़रूरत नहीं होगी और इसके बारे में परवाह नहीं है, और यह आपके कोड को उस विशेष विक्रेता (और शायद उस विशेष चिप) को लॉक कर देता है।

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

मेरे द्वारा उपयोग की जाने वाली कोडिंग शैली का एक स्निपेट, जो या तो आपको उत्साही बना सकता है या डरावनी स्थिति में ला सकता है:

// GPIO part of a HAL for atsam3xa
enum class _port { a = 0x400E0E00U, . . . };

template< _port P, uint32_t pin >
struct _pin_in_out_base : _pin_in_out_root {

   static void direction_set_direct( pin_direction d ){
      ( ( d == pin_direction::input )
         ? ((Pio*)P)->PIO_ODR : ((Pio*)P)->PIO_OER )  = ( 0x1U << pin );
   }

   static void set_direct( bool v ){
      ( v ? ((Pio*)P)->PIO_SODR : ((Pio*)P)->PIO_CODR )  = ( 0x1U << pin );    
   }
};

// a general GPIO needs some boilerplate functionality
template< _port P, uint32_t pin >
using _pin_in_out = _box_creator< _pin_in_out_base< P, pin > >;

// an Arduino Due has an on-board led, and (suppose) it is active low
using _led = _pin_in_out< _port::b, 27 >;
using led  = invert< pin_out< _led > >;

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

target::led::init();
target::led::set( 1 );

संकलक उन सभी परतों से भयभीत नहीं है, और क्योंकि कोई वर्चुअल फ़ंक्शन शामिल नहीं हैं जो कि अनुकूलक सब कुछ के माध्यम से देखता है (कुछ विवरण, छोड़े गए, जैसे परिधीय घड़ी को सक्षम करना):

 mov.w  r2, #134217728  ; 0x8000000
 ldr    r3, [pc, #24]   
 str    r2, [r3, #16]
 str    r2, [r3, #48]   

जो कि मैंने इसे असेंबलर में कैसे लिखा होगा - अगर मुझे पता चला है कि पीआईओ रजिस्टर का उपयोग आम आधार से ऑफसेट के साथ किया जा सकता है। इस मामले में मैं शायद करूंगा, लेकिन कंपाइलर इस तरह की चीजों का अनुकूलन करने से कहीं बेहतर है।

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

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

(संपादित करें - "तो प्रदर्शन वार, C या C ++ की प्रतिक्रिया समान स्तर पर होगी?"

समान निर्माणों के लिए, C और C ++ समान हैं। C ++ में एब्सट्रैक्शन (बस कुछ: क्लासेस, टेम्प्लेट, कॉन्स्टैक्स) के लिए बहुत अधिक निर्माण हैं, जो किसी भी टूल की तरह, अच्छे या बुरे के लिए उपयोग किए जा सकते हैं। चर्चाओं को अधिक रोचक बनाने के लिए: हर कोई इस बात से सहमत नहीं है कि अच्छा या बुरा क्या है ...


तो प्रदर्शन वार, C या C ++ समान स्तर पर होगा? मुझे लगता है कि C ++ में अधिक अधिभार होगा। निश्चित रूप से आपने मुझे सही दिशा में इंगित किया, C ++ नहीं जाने का रास्ता है। C
इंजीनियर

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

1
आप दावा करते हैं कि C ++ बेहतर है, लेकिन तब आप जाते हैं और C- शैली की कास्ट का उपयोग करते हैं। शर्म की बात है।
JAB

@ जेएबी मुझे नई शैली की जातियों के लिए कभी महसूस नहीं हुआ, लेकिन मैं उन्हें कोशिश करूंगा। लेकिन मेरी वर्तमान प्राथमिकता इस पुस्तकालय के अन्य हिस्सों पर है। वास्तविक समस्या यह है कि मैं बिंदुओं को टेम्पलेट मापदंडों के रूप में पारित नहीं कर सका।
राउटर वैन ऊइजेन

@ हँसो माय कॉटो (कम्पाइल टाइम ऑब्जेक्ट्स) शैली का एक संकीर्ण उपयोग-मामला है (हार्डवेयर के समीप, संकलन-समय ज्ञात स्थिति), यह वर्चुअल-आधारित ओओ के ट्रैंडामिकल उपयोगों के लिए प्रतिस्थापन की तुलना में अधिक सी-हत्यारा है। एक उपयोगी उपोत्पाद यह है कि अप्रत्यक्ष की अनुपस्थिति स्टैक आकार की गणना करना संभव बनाती है।
राउटर वैन ऊइजेन

4

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

सी पहले से ही काफी लचीला है क्योंकि यह एक "पोर्टेबल असेंबलर" है। आपके द्वारा चयनित सभी प्लेटफ़ॉर्म में GCC / वाणिज्यिक कंपाइलर उपलब्ध हैं जिनके पास C89 और C99 भाषा मानकों के लिए समर्थन है, जिसका अर्थ है कि आप सभी प्लेटफ़ॉर्म पर समान कोड चला सकते हैं।

कुछ विचार हैं:

  • कुछ आर्किटेक्चर वॉन न्यूमैन (ARM, MIPS) हैं, अन्य हार्वर्ड हैं। मुख्य सीमाएं तब उत्पन्न होती हैं जब आपके C प्रोग्राम को ROM से डेटा पढ़ने की आवश्यकता होती है, जैसे स्ट्रिंग्स को प्रिंट करने के लिए, डेटा को "कास्ट" या समान के रूप में परिभाषित किया जाता है।

कुछ प्लेटफ़ॉर्म / कंपाइलर इस "सीमा" को दूसरों से बेहतर छिपा सकते हैं। AVR पर जैसे आपको ROM डेटा को पढ़ने के लिए विशिष्ट मैक्रो का उपयोग करने की आवश्यकता होती है। PIC24 / dsPIC पर भी समर्पित tblrd इंस्टॉलेशन उपलब्ध हैं। हालाँकि इसके अलावा कुछ हिस्सों में "प्रोग्राम स्पेस विजिबिलिटी" (PSVPAG) सुविधा भी उपलब्ध है जो FLASH के एक पेज को रैम में मैप करने की अनुमति देती है, जिससे तत्काल डेटा पते बिना tblrd के उपलब्ध होते हैं। संकलक यह काफी प्रभावी ढंग से कर सकता है।

एआरएम और एमआईपीएस वॉन न्यूमैन हैं, जिसमें 1 बस में रोम, रैम और बाह्य उपकरणों के लिए मेमोरी क्षेत्र हैं। आप रैम या "रोम" से डेटा पढ़ने के बीच कोई अंतर नहीं देखेंगे।

  • यदि आप C के नीचे गोता लगाते हैं, और कुछ कार्यों के लिए उत्पन्न निर्देशों को देखते हैं, तो आपको I / O के आसपास कुछ बड़े अंतर मिलेंगे। एआरएम और एमआइपी आरआईएससी लोड-स्टोर रजिस्टर आर्किटेक्चर हैं । इसका मतलब यह है कि मेमोरी बस में डेटा एक्सेस एमओवी निर्देशों के माध्यम से जाना चाहिए। इसका अर्थ यह भी है कि परिधीय मूल्य के किसी भी संशोधन से रीड-मॉडिफाई-राइट (आरएमडब्ल्यू) ऑपरेशन को बढ़ावा मिलेगा। कुछ एआरएम भाग हैं जो बिट-बैंडिंग का समर्थन करते हैं, जो कि मैप सेट / क्लर-बिट रजिस्टरों को I / O परिधीय स्थान में स्थापित करता है। हालाँकि आपको इस एक्सेस को स्वयं कोड करने की आवश्यकता है।

दूसरी ओर एक PIC24, ALU परिचालनों को अप्रत्यक्ष रूप से संबोधित (सीधे सूचक संशोधनों के साथ ..) के माध्यम से डेटा को पढ़ने और लिखने की अनुमति देता है। CISC की वास्तुकला की तरह इसमें कुछ विशेषताएं हैं, इसलिए 1 निर्देश अधिक काम कर सकता है। यह डिजाइन अधिक जटिल सीपीयू कोर, कम घड़ियां, उच्च बिजली की खपत आदि का कारण बन सकता है, सौभाग्य से आपके लिए यह हिस्सा पहले से ही डिज़ाइन किया गया है। ;-)

इन अंतरों का मतलब यह हो सकता है कि PIC24 समान रूप से देखे गए एआरएम या एमआइपी चिप की तुलना में "अधिक छिद्रयुक्त" I / O संचालन हो सकता है। हालाँकि, आपको समान मूल्य / पैकेज / डिज़ाइन की कमी के लिए बहुत अधिक क्लॉकर ARM / MIPS हिस्सा मिल सकता है। मैं व्यावहारिक शब्दों के लिए अनुमान लगाता हूं, मुझे लगता है कि "प्लेटफॉर्म सीखने" का एक बहुत कुछ पकड़ में आ रहा है कि वास्तुकला क्या कर सकती है और क्या नहीं कर सकती है, ऑपरेशन के कुछ सेट कितनी तेजी से होंगे आदि।

  • परिधीय, घड़ी प्रबंधन, आदि भागों के प्रति परिवार भिन्न होते हैं। कड़ाई से बोलते हुए, यह विक्रेताओं के बीच एआरएम ईको-सिस्टम के भीतर भी बदल जाएगा, केवल कुछ कॉर्टेक्स एम बाध्य बाह्य उपकरणों जैसे कि NVIC और SysTick को छोड़कर।

इन मतभेदों को डिवाइस चालकों द्वारा कुछ हद तक समझाया जा सकता है, लेकिन अंत में एम्बेडेड फर्मवेयर में हार्डवेयर के साथ युग्मन का एक उच्च स्तर होता है, इसलिए कस्टम काम को कभी-कभी टाला नहीं जा सकता है।

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

  • इसके अलावा, यदि आप पहले से ही नहीं हैं, तो लाइब्रेरी जैसे कि stdint.h, stdbool.h आदि का उपयोग करने का प्रयास करें। ये पूर्णांक प्रकार चौड़ाई को स्पष्ट करते हैं, जो प्लेटफार्मों के बीच कोड व्यवहार को सबसे अधिक अनुमानित करता है। इसका मतलब 8-बिट AVR पर 32-बिट पूर्णांक का उपयोग हो सकता है; लेकिन अगर आपके कोड को इसकी आवश्यकता है तो ऐसा हो।

3

हां और ना। एक प्रोग्रामर के नजरिए से आप आदर्श रूप से निर्देश सेट का विवरण छिपा रहे हैं। लेकिन यह कुछ हद तक पहले से ही प्रासंगिक नहीं है परिधीय जो कार्यक्रम लिखने का पूरा बिंदु निर्देश सेट का हिस्सा नहीं है। अब एक ही समय में आप केवल उन निर्देश सेटों में 4096Byte फ़्लैश भागों की तुलना नहीं कर सकते हैं, खासकर यदि C का उपयोग करते हुए, फ्लैश / मेमोरी की खपत की मात्रा निर्देश सेट और कंपाइलर द्वारा भारी रूप से निर्धारित की जाती है, तो कुछ को एक कंपाइलर (खांसी PIC) नहीं देखना चाहिए खांसी) के कारण उन संसाधनों की बर्बादी संकलन द्वारा कितनी खपत होती है। अन्य फ्लैश की खपत एक छोटे ओवरहेड है। एमसीयू अनुप्रयोगों में उच्च स्तरीय भाषा और प्रदर्शन मामलों का उपयोग करते समय प्रदर्शन भी एक मुद्दा है, इसलिए यह एमसीयू या $ 1 के लिए प्रति बोर्ड 3 डॉलर खर्च करने के बीच अंतर कर सकता है।

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

नीचे की रेखा निर्देश सेट आपकी चिंताओं से कम से कम है, वास्तविक मुद्दों पर आगे बढ़ें।

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