एंबेडेड के लिए वैकल्पिक सॉफ्टवेयर डिजाइन दृष्टिकोण

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

मैं व्यक्तिगत रूप से RTOS का उपयोग क्यों नहीं करता

कॉमरेड ओलेक ने आरटीओएस के बारे में बात की, मैं इस पर ध्यान केंद्रित नहीं करूंगा। मैं उन कुछ बिंदुओं पर ध्यान दूंगा जिन्हें मैंने व्यक्तिगत रूप से अपने लिए उजागर किया है - मैं RTOS का उपयोग क्यों नहीं करता:

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

स्विच-केस दृष्टिकोण

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

डिवाइस में दो तापमान सेंसर हैं। पहले सेंसर का मतदान समय महत्वपूर्ण नहीं है: "मतदान किया, हाँ, ठीक है", इसे 0.2 एमएस होने दें। निर्धारित तापमान सीमा से अधिक होने के बाद, हम एलईडी प्रकाश करेंगे। इसके विपरीत दूसरे सेंसर की रीडिंग हमारे लिए बहुत महत्वपूर्ण है। इसे जितनी बार संभव हो उतनी बार पूछताछ करने की आवश्यकता होती है और एक असतत संकेत के साथ कूलिंग फैन को चालू करने के लिए निर्धारित सीमा से अधिक “1” प्रति पिन देना होता है। जब तापमान एक और सीमा तक गिर जाए, तो पंखे को बंद कर दें। हर 100 एमएस में, दूसरे सेंसर से मूल्य को ROM पर लिखा जाना चाहिए।
कार्यान्वयन के लिए एक हार्डवेयर टाइमर इंटरप्ट की आवश्यकता होगी। वास्तव में, केवल इस तरह से हम उन्हें आवंटित समय में कार्यों की पूर्ति की गारंटी दे सकते हैं। इस मामले में, अन्य अवरोधों का उपयोग करने की संभावनाएं तेजी से कम हो जाती हैं।
अधिकांश बाह्य उपकरणों के साथ काम बिना किसी रुकावट के किया जा सकता है, और बहुत महत्वपूर्ण संचार बाधित होता है (उदाहरण के लिए: UART / SCI) आमतौर पर टाइमर की तुलना में उच्च प्राथमिकता होती है और आमतौर पर प्राप्त / भेजे गए बाइट्स को ठीक करने के लिए सेवा करते हैं, अर्थात। उन्हें ज्यादा समय नहीं लगा।
दृष्टिकोण, जब टाइमर केवल कार्यों के लिए समय की गणना करता है, और कार्य स्वयं पृष्ठभूमि में (या सुपर साइकिल के बिना) बाधित किए बिना किए जाते हैं, निष्पादन की आवश्यक प्रतिक्रिया की गारंटी नहीं देते हैं।

सबसे पहले, हम एक तापमान सेंसर चालक बनाते हैं। इसका मुख्य कार्य एसपीआई द्वारा तापमान मान को पढ़ना है।

संरचना:

typedef struct { unsigned char SpiCh; //   SPI (A, B, C) unsigned int SpiBrr; //  SPI- unsigned int Value; //    void (*ChipSelect) (unsigned char level_); // Callback    … // -  }TSensor; 

तापमान जांच मतदान कार्य:

 void SensorDriver(TSensor *p) { p->ChipSelect(0); //   p->Value = SpiRead(p->SpiCh, p->SpiBrr); //    SPI p->ChipSelect(1); //    } 

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

 TSensor Sensor1; TSensor Sensor2; void Init(void) { Sensor1.ChipSelect = &ChipSelectFunc1; //      Sensor1.SpiCh = 0; //  SPI Sensor1.SpiBrr = 1000; //  SPI Sensor2.ChipSelect = &ChipSelectFunc2; Sensor2.SpiCh = 0; Sensor2.SpiBrr = 1000; } 

चालक का मुख्य कार्य तापमान को पढ़ना है। इस डेटा के साथ क्या करना है यह ड्राइवर के बाहर तय किया जाएगा।

हम एलईडी प्रकाश:

 void SensorLed(void) { if (Sensor1.Value >= SENSOR_LED_LIMIT) LedPin = 1; else If (Sensor1.Value < SENSOR_LED_LIMIT) LedPin = 0; } 

एक असतत पैर के साथ पंखे को चालू / बंद करें:

 void SensorCooler(void) { if (Sensor2.Value >= SENSOR_LED_LIMIT) CoolerPin = 1; else if (Sensor1.Value < SENSOR_LED_LIMIT) CoolerPin = 0; } 

अजीब है, लेकिन कार्यों आश्चर्यजनक रूप से समान हो गए :)
हम रॉम में निम्नानुसार लिखेंगे:
ROM ड्राइवर के कार्य को 1 kHz की आवृत्ति पर चक्रीय रूप से निष्पादित किया जाएगा, जबकि डेटा लिखे जाने की प्रतीक्षा में, निर्देश "उनके साथ क्या करना है" और स्मृति में किस पते पर। यानी यह हमारे लिए स्मृति की तत्परता की जांच करने और कार्यक्रम में कहीं से भी निर्देश के साथ डेटा भेजने के लिए पर्याप्त है।

 void SensorValueRecord() { unsigned int Data = Sensor2.Value; //     unsigned int Address = 0; //    if (EepromReady()) //    { //  ,   ,     EepromFunction(Address, Data, WRITE); } } 

हमने डेटा भेजा और जब मेमोरी ड्राइवर ऑपरेशन में आता है (और यह SensorValueRecord फ़ंक्शन की तुलना में 100 गुना तेज है), तो यह पहले से ही पता चल जाएगा कि क्या करना है।
हमारे कार्य तैयार हैं। अब उन्हें ठीक से व्यवस्थित करने की आवश्यकता है।
ऐसा करने के लिए, हम 10 kHz (100 μs) की आवृत्ति के साथ टाइमर का एक रुकावट शुरू करते हैं। यह कॉलिंग कार्यों की हमारी अधिकतम गारंटीकृत आवृत्ति होगी। वह पर्याप्त हो। हम कार्य शेड्यूलर के कार्यों को बनाते हैं, जिसमें हम यह निर्धारित करेंगे कि किस कार्य को कब चलाना है।

 #define MAIN_HZ 10000 #define TASK0_FREQ 1000 #define TASK1_FREQ 50 #define TASK2_FREQ 10 //    void AlternativeTaskManager(void) { SensorDriver(&Sensor2); //      SensorCooler(); //     Task0_Execute(); //     } //  1 void Task0_Execute(void) { switch (TaskIndex0) { case 0: EepromDriver(&Eeprom); break; case 1: Task1_Execute(); break; case 2: Task2_Execute(); break; } //   if (++TaskIndex0 >= MAIN_HZ / TASK0_FREQ) TaskIndex0 = 0; } //    50  void Task1_Execute(void) { switch (TaskIndex1) { case 0: SensorDriver(&Sensor1); break; case 1: SensorLed(); break; } if (++TaskIndex1 >= TASK0_FREQ / TASK1_FREQ) TaskIndex1 = 0; } //    10  void Task2_Execute(void) { switch (TaskIndex2) { case 0: SensorValueRecord(); break; case 1: break; } if (++TaskIndex2 >= TASK0_FREQ / TASK2_FREQ) TaskIndex2 = 0; } 

अब यह टाइमर रुकावट में अनुसूचक को चलाने के लिए बना हुआ है और आप काम कर रहे हैं।

 interrupt void Timer1_Handler(void) { AlternativeTaskManager(); } 

यह प्रणाली गियर के साथ एक प्रकार के तंत्र की तरह दिखती है: सबसे महत्वपूर्ण गियर सीधे मोटर शाफ्ट पर होता है और यह शेष गियर को घुमाता है।
कार्य "रिंग पर" किए जाते हैं। उनके निष्पादन की आवृत्ति कॉल की जगह पर निर्भर करती है। Task0_Execute फ़ंक्शन को 10 kHz की आवृत्ति के साथ निष्पादित किया जाएगा, क्योंकि हम इसे सीधे टाइमर इंटरप्ट (हमारे मुख्य गियर) में कहते हैं। फ़्रीक्वेंसी डिवीजन इसमें होता है और टास्कइंडैक्स 0 के साथ स्विच-केस का उपयोग करके यह निर्धारित किया जाता है कि किस कार्य का समय आ गया है। चुनौती की आवृत्ति 10kHz से कम होनी चाहिए।
हम टास्क 0_Execute चक्र के लिए 1 kHz के लिए कार्य आवृत्ति सेट करते हैं, जिसका अर्थ है कि 1 kHz की आवृत्ति के साथ 10 कार्य इसमें किए जा सकते हैं:

 #define MAIN_HZ 10000 #define TASK0_FREQ 1000 if (++TaskIndex0 >= MAIN_HZ / TASK0_FREQ) 

सिस्टम स्विच-केस संरचना


इसी तरह Task1_Execute और Task2_Execute के लिए। हम उन्हें 1 kHz की आवृत्ति के साथ कहते हैं। पहले चक्र में, कार्यों को 50 हर्ट्ज की आवृत्ति के साथ किया जाना चाहिए, और दूसरे में - 10 हर्ट्ज। हमें लगता है कि कुल मिलाकर क्रमशः 20 और 100 कार्य होंगे।
डिस्पैचर के कार्यों को पूरा करने के बाद, कार्यक्रम पृष्ठभूमि (पृष्ठभूमि सुपर साइकिल) पर लौटता है।
कोई भी प्रतिक्रिया जो समय के लिए महत्वपूर्ण नहीं है, उन्हें वहां रखना काफी संभव है।

 void main(void) { Init(); while (1) { DoSomething(); } } 

डिवाइस में एक डीएसी जोड़ा जाता है और, एलईडी के प्रज्वलन के साथ, क्या आपको 4-20 सिग्नल उत्पन्न करने की आवश्यकता है? कोई सवाल नहीं। DAC ड्राइवर बनाएं और उसे चलाएं। हम SensorLed फ़ंक्शन में दो पंक्तियाँ जोड़ते हैं, जो ड्राइवर को बताएगी कि इसका आउटपुट क्या मूल्य है और डिस्पैचर ड्राइवर फ़ंक्शन को कॉल करता है।

 void SensorLed(void) { if (Sensor1.Value >= SENSOR_LED_LIMIT) { LedPin = 1; Dac.Value = 20; //     } else If (Sensor1.Value < SENSOR_LED_LIMIT) { LedPin = 0; Dac.Value = 4; //     } } 

 //    50  void Task1_Execute(void) { switch (TaskIndex1) { case 0: SensorDriver(&Sensor1); break; case 1: SensorLed(); break; case 2: DacDriver(&Dac) break; //    } if (++TaskIndex1 >= TASK0_FREQ / TASK1_FREQ) TaskIndex1 = 0; } 

दो-पंक्ति संकेतक जोड़ा गया? समस्या भी नहीं। हम इसके चालक को 1 kHz की आवृत्ति पर लॉन्च करते हैं, क्योंकि पात्रों को जल्दी से स्थानांतरित करने की आवश्यकता है, और अन्य धीमी क्रियाओं में हम ड्राइवर को बताते हैं कि किन वर्णों और रेखाओं को प्रदर्शित करना होगा।

लोड रेटिंग

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

 unsigned int CpuTime = 0; unsigned int CpuTimeMax = 0; interrupt void Timer1_Handler(void) { Timer2.TimerValue = 0; //   AlternativeTaskManager(); //  switch-case   CpuTime = Timer2.Value; //    =  if (CpuTime > CpuTimeMax ) //    CpuTime = CpuTimeMax; } 

नतीजा क्या हुआ

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

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

इस लेख में, मैंने आरटीओएस का उपयोग किए बिना एम्बेडेड सिस्टम के लिए सॉफ्टवेयर डिजाइन करने के लिए एक वैकल्पिक दृष्टिकोण प्रकट करने की कोशिश की। मुझे आशा है कि किसी को कुछ उपयोगी मिला।

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