उत्पादन में माइक्रोकंट्रोलर के लिए परियोजनाओं के लिए C ++ का उपयोग करने के पांच साल

इस लेख में मैं आपको बताऊंगा कि मैंने माइक्रोकंट्रोलर्स के लिए C से C ++ तक के प्रोजेक्ट्स को मैनेज करने से लेकर पांच साल तक काम करने वाली कंपनियों को कैसे ट्रांसफर किया और इसका क्या हुआ (स्पॉइलर: सब कुछ खराब है)।

थोड़ा अपने बारे में

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

प्रथम वर्ष

मेरे पास सी की प्रक्रियात्मक शैली के खिलाफ कुछ भी नहीं था, लेकिन वास्तविक परियोजनाओं पर अपना वास्तविक अभ्यास शुरू करने वाले उद्यम ने "सी-प्रोग्रामिंग को एक वस्तु-उन्मुख शैली में इस्तेमाल किया।" कुछ ऐसा दिख रहा था।

typedef const struct _uart_init { USART_TypeDef *USARTx; uint32_t baudrate; ... } uart_cfg_t; int uart_init (uart_cfg_t *cfg); int uart_start_tx (int fd, void *d, uint16_t l); int uart_tx (int fd, void *d, uint16_t l, uint32_t timeout); 

इस दृष्टिकोण के निम्नलिखित फायदे थे:

1. कोड सी कोड होना जारी रहा। निम्नलिखित लाभ इस से आते हैं:
   • "वस्तुओं" को नियंत्रित करना आसान है, क्योंकि यह पता लगाना आसान है कि कौन और कहां किस कारण से और किस क्रम में (रुकावट के अपवाद के साथ, लेकिन इस लेख में नहीं);
   • "ऑब्जेक्ट के लिए पॉइंटर" को स्टोर करने के लिए यह लौटी हुई एफडी को याद करने के लिए पर्याप्त है;
   • यदि "ऑब्जेक्ट" हटा दिया गया था, तो जब आप इसका उपयोग करने का प्रयास करते हैं, तो आपको फ़ंक्शन के रिटर्न वैल्यू में एक संबंधित त्रुटि प्राप्त होगी;
2. HAL के ऊपर इस तरह की वस्तुओं के अमूर्त उपयोग ने वहाँ वस्तुओं को अपनी स्वयं की आरंभीकरण संरचना (और एचएएल कार्यक्षमता की कमी के मामले में अनुकूलन के लिए लिखना संभव बना दिया है, एक "ऑब्जेक्ट्स") के अंदर रजिस्टरों तक पहुंच छिपा सकता है।

विपक्ष:

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

यह पूछे जाने पर कि संपूर्ण बुनियादी ढांचे का निर्माण करते समय C ++ का चयन क्यों नहीं किया गया था, उन्होंने कुछ इस तरह से उत्तर दिया: "ठीक है, C ++ मजबूत अतिरिक्त लागत, अनियंत्रित मेमोरी लागत, साथ ही एक भारी निष्पादन योग्य फर्मवेयर फ़ाइल की ओर जाता है।" शायद वे सही थे। दरअसल, डिजाइनिंग की शुरुआत के समय, केवल GCC 3.0.5 था, जो C ++ के लिए विशेष मित्रता के साथ चमक नहीं था (हमें अभी भी QNX6 के तहत कार्यक्रम लिखने के लिए इसके साथ काम करना है)। कोई बाधा नहीं थी और C ++ 11/14, आपको वैश्विक ऑब्जेक्ट बनाने की अनुमति देता है, जो संक्षेप में .data क्षेत्र में डेटा थे, उनकी गणना चरण और उनके लिए विधियों पर गणना की गई थी।

प्रश्न के लिए, रजिस्टरों पर क्यों नहीं लिखा - मुझे स्पष्ट जवाब मिला कि "ऑब्जेक्ट्स" का उपयोग आपको एक ही प्रकार के एप्लिकेशन को "एक दिन में" कॉन्फ़िगर करने की अनुमति देता है।

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

वर्ष दो और तीन

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

चौथा और पांचवां वर्ष

• सभी ऑब्जेक्ट वैश्विक हैं और संकलन चरण (परियोजना की वास्तुकला के अनुसार) में एक दूसरे से लिंक शामिल हैं;
• सभी वस्तुओं को लेआउट के चरण में मेमोरी आवंटित की जाती है;
• प्रत्येक पिन के लिए क्लास ऑब्जेक्ट द्वारा;
• एक ऐसी वस्तु जो सभी पिनों को एक विधि से आरंभ करने के लिए एनकैप्सुलेट करती है;
• एक RCC कंट्रोल ऑब्जेक्ट जो उन सभी ऑब्जेक्ट्स को एनकैप कर देता है जो हार्डवेयर बसों पर हैं;
• CAN <-> ग्राहक प्रोटोकॉल के अनुसार RS485 कनवर्टर प्रोजेक्ट में 60 ऑब्जेक्ट हैं;
• यदि किसी वस्तु के एचएएल या वर्ग स्तर पर कुछ ऐसा है, तो आपको न केवल "समस्या को ठीक करना" होगा, बल्कि यह भी सोचना चाहिए कि इसे कैसे ठीक किया जाए ताकि यह फिक्स इस मॉड्यूल के सभी संभावित विन्यासों पर काम करे ;
• उपयोग किए गए टेम्प्लेट और कॉन्स्टैक्स की गणना अंतिम फर्मवेयर के मानचित्र, एएसएम और बिन फ़ाइलों (या माइक्रोकंट्रोलर में डीबगिंग लॉन्च) को देखने से पहले नहीं की जा सकती;
• टेम्पलेट में त्रुटि के मामले में, जीसीसी से परियोजना कॉन्फ़िगरेशन के एक तिहाई की लंबाई के साथ एक संदेश आउटपुट है। इससे कुछ पढ़ना और समझना एक अलग उपलब्धि है।

परिणाम

अब मैं निम्नलिखित को समझता हूं:

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

संक्षेप में, हम कह सकते हैं कि C ++ का उपयोग करने की स्पष्ट सादगी गति या स्मृति में किसी भी लाभ के बिना परियोजना की जटिलता को बार-बार बढ़ाने के लिए सिर्फ एक बहाना बन गई।