🖖🏾 🐱 👰🏿 समय ट्रिगर डिजाइन - एम्बेडेड सिस्टम के लिए सॉफ्टवेयर डिजाइन करने के लिए एक और दृष्टिकोण 🦅 ⚒️ ☁️

एक बार मैंने एम्बेडेड सिस्टम के लिए एप्लिकेशन डिजाइन करने के सिद्धांतों के बारे में एक लेख लिखा था। फिर मैंने कहा कि दो बुनियादी सिद्धांत हैं - एक अनंत लूप और एक वास्तविक समय ओएस। लेकिन हाल ही में मैंने सुना कि एक तीसरा दृष्टिकोण भी है - तथाकथित टाइम ट्रिगर डिज़ाइन।

दृष्टिकोण के लिए एक परिचय के रूप में, माइकल जे। पोंट द्वारा पुस्तक "पैटर्न समय-ट्रिगर एम्बेडेड सिस्टम के लिए" का उपयोग किया गया था, उन लोगों के लिए - www.safetty.net/publications/pttes

मैं यहां अवधारणा को रेखांकित करने का प्रयास करूंगा।

अवधारणा निम्नलिखित विचारों पर आधारित है:

सिस्टम में एक एकल आवधिक रुकावट है - टिक;
कार्यों की कोई प्राथमिकता नहीं है;
वर्तमान में निष्पादित कार्य पूरा होने के बाद ही अगले कार्य का नियंत्रण स्थानांतरित किया जाता है।

सिद्धांतों के इस सेट को सहकारी कार्य अनुसूचक (सहकारी अनुसूचक) भी कहा जाता है। क्लासिक RTOS का उपयोग करता है जिसे प्रीमेप्टिव शेड्यूलर कहा जाता है।

लेखक कार्यान्वयन की सादगी के लाभों का हवाला देता है, बहुत कम ओवरहेड लागत और, चाहे कितना भी अजीब लगता हो, विश्वसनीयता।

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

स्यूडोकोड इस सिद्धांत का प्रदर्शन करता है।

void main(void) { scheduler_init(); add_task(Function_A, 2); add_task(Function_B, 10); add_task(Function_C, 15); scheduler_start(); while(1) { dispatch_tasks(); } }

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

संरचना जो कार्य के संदर्भ का वर्णन करती है:

 typedef struct { void (* pTask)(void); uint32 Period; uint32 PeriodCur; uint8 RunMe; } task_descriptor_t;

दरअसल, आरटीओएस की तुलना में, "ओवरहेड" बहुत कम है - एक फ़ंक्शन के लिए एक संकेतक, लॉन्च की आवृत्ति, वर्तमान मूल्य - लॉन्च के लिए इंतजार करने के लिए कितने अधिक टिक, और कितनी बार कार्य लॉन्च किया जाना चाहिए।

 task_descriptor_t all_task_list[MAX_TASKS];

कार्य सूची एक पूर्व निर्धारित लंबाई की एक नियमित सरणी है।

शेड्यूलर स्वयं टाइमर को बाधित करने के लिए लटका दिया गया है, किसी दिए गए आवृत्ति पर होने के लिए कॉन्फ़िगर किया गया है, उदाहरण के लिए, 1 एमएस - एक ही टिक।

 void scheduler_update(void) interrupt { foreach (task in all_task_list) { task.PeriodCur--; if (task.PeriodCur == 0) { task.PeriodCur = task.Period; task.RunMe++; } } }

हैंडलर में, हम कार्यों की पूरी सूची से गुजरते हैं, लॉन्च से पहले शेष टिकों के वर्तमान मूल्य में वृद्धि करते हैं, और यदि यह 0 तक पहुंचता है, तो हम इसे ओवरराइट करते हैं और लॉन्च काउंटर को बढ़ाते हैं।

और अंत में - डिस्पैचर। जो एक अंतहीन लूप में घूमता है।

 void dispatch_tasks(void) { foreach (task in all_task_list) { if (task.RunMe > 0) { task.pTask(); task.RunMe--; } } }

हम अभी भी कार्यों की सूची के माध्यम से जाते हैं, और यदि कार्य में शून्य से अधिक का काउंटर शुरू होता है, तो हम इस कार्य को सीधे इसके कार्य को प्रारंभ करके प्रारंभ काउंटर को घटाते हैं।

वास्तव में सब कुछ!

वास्तव में, कार्यान्वयन हास्यास्पद रूप से सरल है (और इसलिए आसानी से कहीं भी पोर्टेबल है)। वास्तव में, एक अनंत लूप से बेहतर है। वास्तव में, सेमाफोरेस-क्यूज़-क्रिटिकल सेक्शन जैसे कोई सिंक्रोनाइज़ेशन टूल की आवश्यकता नहीं होती है। वास्तव में, कोई संदर्भ स्विच आवश्यक नहीं है।

लेकिन मुझे यह पसंद नहीं है। और यहाँ क्यों है।

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

आखिरी पैराग्राफ के लिए, एक ही किताब में एक अद्भुत उदाहरण पाया गया था। वहाँ shedulers पर जोर देने के अलावा, पुस्तक का दो-तिहाई भाग एम्बेडेड सिस्टम के मूल के बारे में एक कहानी को समर्पित है, जो बाह्य उपकरणों और प्रोटोकॉल के साथ काम कर रहा है। यहाँ इस पुस्तक से SPI के साथ काम करने का एक उदाहरण दिया गया है।

 /*------------------------------------------------------------------*- SPI_X25_Write_Byte() Store a byte of data on the EEPROM. -*------------------------------------------------------------------*/ void SPI_X25_Write_Byte(const tWord ADDRESS, const tByte DATA) { // 0. We check the status register SPI_X25_Read_Status_Register(); // 1. Pin /CS is pulled low to select the device SPI_CS = 0; // 2. The 'Write Enable' instruction is sent (0x06) SPI_Exchange_Bytes(0x06); // 3. The /CS must now be pulled high SPI_CS = 1; // 4. Wait (briefly) SPI_Delay_T0(); // 5. Pin /CS is pulled low to select the device SPI_CS = 0; // 6. The 'Write' instruction is sent (0x02) SPI_Exchange_Bytes(0x02); // 7. The address we wish to read from is sent. // NOTE: we send a 16-bit address: // - depending on the size of the device, some bits may be ignored. SPI_Exchange_Bytes((ADDRESS >> 8) & 0x00FF); // Send MSB SPI_Exchange_Bytes(ADDRESS & 0x00FF); // Send LSB // 8. The data to be written is shifted out on MOSI SPI_Exchange_Bytes(DATA); // 9. Pull the /CS pin high to complete the operation SPI_CS = 1; }

सरल और स्पष्ट रैखिक कोड, ऐसा लगता है। लेकिन जब आप ऊपर वर्णित डिज़ाइन में इसे लागू करने का प्रयास करते हैं, तो निम्न समस्याएं दिखाई देंगी:

SPI_Exchange_Bytes () अंदर परिधीय तत्परता की प्रतीक्षा के अवरुद्ध चक्रों का उपयोग करता है - हमारे पास केवल मतदान है, याद है? (मैं कोड नहीं दूंगा, यहां पहले से ही बहुत कुछ है, बस विश्वास है कि वे वहां हैं)। और तब से परिधीय अचानक विफल हो सकते हैं; प्रत्येक प्रतीक्षा चक्र के लिए एक समयबाह्य समय निर्धारित है। जो इस फंक्शन में 5 ms के बराबर है! नतीजतन, एक साधारण फ़ंक्शन में, हमारे पास एसपीआई बाइट एक्सचेंज फ़ंक्शन के लिए पांच कॉल हैं, जिनमें से प्रत्येक सबसे खराब स्थिति में, 5 एमएस ले सकता है। उस आवश्यकता को याद रखें जो कार्य एक टिक के समय की तुलना में काफी कम समय में पूरा होता है (जो हमारे पास 1 एमएस है)? तो क्या, अब SPI EEPROM के साथ काम करने के लिए एक सरल और स्पष्ट कोड के बजाय, मुझे एक जटिल राज्य मशीन लिखना है ताकि एक से अधिक बाइट एक कॉल में स्थानांतरित न हो? और फिर भी, यहां तक कि SPI_Exchange_Bytes () में एक कॉल 5 एमएस को एक प्रतिकूल स्थिति में ले जा सकता है, और संभावित देरी को कम करने के लिए, आपको एसपीआई_ExchangeBytes () को भी सरल कार्य को फिर से लिखना होगा ताकि इसमें टाइमआउट 5 एमएस में एक से अधिक टुकड़ों से हो, लेकिन प्रत्येक कॉल के साथ 100 μs के छोटे टुकड़ों में? केवल एक चीज जो मैं कहना चाहता हूं: "क्या वे गंभीर हैं?"
अपनी वास्तविक परियोजना में, मुझे SPI के माध्यम से FLASH तक 1 मेगाबाइट डेटा स्थानांतरित करने की आवश्यकता है। अब गणना करते हैं - यदि कार्य के लिए एक कॉल प्रत्येक मिलीसेकंड पर एक बार होती है, और एक कॉल में मैं 1 बाइट से अधिक सूचना प्रसारित नहीं कर सकता - मैं 1 मेगाबाइट को कितने समय में स्थानांतरित करूंगा? बेशक, आप एक बाइट को स्थानांतरित करके इसके चारों ओर प्राप्त कर सकते हैं, लेकिन कई, लेकिन कोड और भी जटिल हो जाएगा - मुझे अभी भी यह सुनिश्चित करना है कि कुल खर्च किया गया समय, 300 μs से अधिक न हो, क्योंकि आवश्यकता यह है कि कार्य की चुनौती टिक से कम हो, अभी भी वैध है!
इस तथ्य का उल्लेख नहीं करने के लिए कि यदि एसपीआई से एक रुकावट को सक्षम करना संभव है, तो कार्य को और भी सरल किया जाएगा - मैं सिर्फ बफर को ट्रांसमिशन के लिए डेटा ब्लॉक लिखता हूं, पहले बाइट भेजता हूं, और बीच में हैंडलर बफर से अगला बाइट भेजता है ताकि वह पूरा हो सके। लेकिन सिस्टम में दूसरा व्यवधान टाइम ट्रिगर डिज़ाइन की नींव को तोड़ देगा, इसलिए आपको इसके बारे में भूलना होगा।

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

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

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

सामान्य तौर पर, दृष्टिकोण को शायद जीवन का अधिकार है। कहीं पर एक छोटा सा माइक्रोकंट्रोलर जो 99% समय के साथ कुछ भी नहीं करता है, बाहरी घटनाओं के एक जोड़े को संसाधित करता है जिन्हें किसी दिए गए समय के लिए तत्काल प्रतिक्रिया की आवश्यकता नहीं होती है। दूसरी ओर, यहां सुपर साइकिल ठीक काम करेगा, हालांकि, कई व्यवधानों का उपयोग किया जा सकता है।

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

समय ट्रिगर डिजाइन - एम्बेडेड सिस्टम के लिए सॉफ्टवेयर डिजाइन करने के लिए एक और दृष्टिकोण

More articles: