माइक्रोकंट्रोलर के लिए परियोजनाओं में ऑपरेटिंग सिस्टम के उपयोग के दुरुपयोग के बारे में

आधुनिक माइक्रोकंट्रोलरों का प्रदर्शन काफी उच्च होता है और इससे कई प्रोग्रामर को लगभग निम्न शिराओं में सोचने का अवसर मिलता है: - "यह ठीक है यदि प्रदर्शन का 1-5% ऑपरेटिंग सिस्टम मेंटेनेंस के लिए जाता है। लेकिन मेरा कोड आसानी से डीबग और स्पष्ट हो जाएगा! " इन विचारों को बड़ी मात्रा में गैर-वाष्पशील (फ्लैश) मेमोरी द्वारा समर्थित किया जाता है ताकि प्रत्येक कार्य के लिए अपने स्वयं के स्टैक को आवंटित करने के लिए ऑपरेटिंग सिस्टम कोड और ऑपरेशनल (RAM / SRAM) मेमोरी को स्टोर किया जा सके। हालांकि, ज्यादातर मामलों में यह विचार गलत है। और इस लेख में मैं आपको बताऊंगा कि क्यों।

उन परियोजनाओं के बारे में जिनके साथ मैं काम करता हूं

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

इतना कहाँ है?

यहां उन कार्यों की एक छोटी सूची दी गई है जो प्रत्येक परियोजना में शामिल हैं :

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

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

स्पष्ट सादगी

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

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

इस तथ्य के अलावा, ऐसा लगता है कि ऑपरेटिंग सिस्टम का उपयोग केवल कोड के तर्क में सुधार करेगा और इसे स्पष्ट करेगा।

ऑपरेटिंग सिस्टम की कार्यक्षमता का दुरुपयोग

मुख्य समस्याएं उस समय शुरू होती हैं जब आप भूल जाते हैं कि आप विशेष रूप से माइक्रोकंट्रोलर के लिए क्या लिख ​​रहे हैं। ओएस अपनी लागतों को अपने स्वयं के संस्थानों (जैसे कि सेमाफोर, म्यूटेक्स, क्वीन्स) के साथ काम करने पर लगाता है। यहां टर्मिनल फ़ंक्शन को लागू करने के लिए UART वर्ग का एक उदाहरण है। बीच में, एक बाइट प्राप्त होता है, जिसके बाद, यदि यह वैध इनपुट वर्णों से सीमा पार करता है, तो इसे इसी प्रतिस्थापन के साथ कतार में जोड़ा जाता है (उदाहरण के लिए, "\ n" अनुक्रम "\ n \ r" में बदल जाता है)। यह भेजने के लिए पोर्ट को सुरक्षित करने के लिए किया गया था (चूंकि पोर्ट न केवल टर्मिनल के रूप में काम कर सकता है। इसके माध्यम से लॉग डेटा भी भेजा जा सकता है)। एक तरफ, यह सुनिश्चित करता है कि प्रतिक्रिया जल्द से जल्द भेजी जाएगी और उच्च प्राथमिकता डेटा भेजने के साथ हस्तक्षेप नहीं करेगी (इसके अलावा, उच्च प्राथमिकता डेटा भेजे जाने पर, यह बफर में जमा हो जाता है, जो डीएमए को प्रतिक्रिया भेजने के लिए उपयोग करने की अनुमति देता है)। हालाँकि, इस क्षण से शुरू करने से आप फिसलन भरे रास्ते पर पहुँच जाते हैं। कतार के माध्यम से एक गुच्छा लिखने के बजाय, कोई व्यक्ति गैर-रिक्त बफर पर रुकावट को सही ढंग से कॉन्फ़िगर कर सकता है जो वर्तमान में UART पर काम नहीं कर रहा है और जब DMA समाप्त होता है। इस दृष्टिकोण को स्पष्ट करने की आवश्यकता है कि परिधीय कैसे काम करते हैं। हालांकि, यह लागत को पूर्णतम तक कम कर देता है, जिससे इस तरह के समाधान की आवश्यकता शून्य हो जाती है।

माइक्रोकंट्रोलर हार्डवेयर कार्यक्षमता की अनदेखी

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

एक राज्य मशीन के बजाय एक अनंत लूप का उपयोग करना

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

"हार्डवेयर अनुसूचक" की उपेक्षा

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

परिणाम

इस लेख में मैंने उन बुनियादी समस्याओं के बारे में बात की जिन्हें आपको माइक्रोकंट्रोलर्स के लिए परियोजनाओं में ऑपरेटिंग सिस्टम का उपयोग करते समय सामना करना पड़ता है, और ऑपरेटिंग सिस्टम का उपयोग करने के सामान्य मामलों की भी जांच की गई है जब कोड की पठनीयता और तर्क को खोए बिना इससे बचा जा सकता था।