एक माइक्रोकंट्रोलर में छोटे मल्टीटास्किंग प्रयोग

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

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

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

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

मुझे आपको याद दिलाने के लिए, हम कॉर्टेक्स-एम 3,4,7 कोर के साथ नियंत्रकों के बारे में बात कर रहे थे। आज एक बहुत ही सामान्य परिवार है। नीचे दिए गए उदाहरणों में, हमने STM32F303 माइक्रोकंट्रोलर का उपयोग किया, जो कि STM32F3DISCOVERM बोर्ड का हिस्सा है।

स्विच एक एकल कोडांतरक फ़ाइल है।
कोडांतरक लेखक से डरता नहीं है, लेकिन, इसके विपरीत, आशा करता है कि अधिकतम गति प्राप्त होगी।

प्रारंभ में, स्विच ऑपरेशन का सबसे सरल तर्क की योजना बनाई गई थी, जिसे आठ कार्यों के लिए चित्र 1 में प्रस्तुत किया गया है।

इस योजना में, कार्य एक-एक करके समय का एक हिस्सा लेते हैं और केवल अपने टिक के शेष भाग दे सकते हैं और यदि आवश्यक हो, तो उनके कुछ टिकों को छोड़ दें। यह तर्क अच्छा साबित हुआ, क्योंकि क्वांटम का आकार छोटा बनाया जा सकता है। और यह ठीक वही है जो एक कार्य को तत्काल करने के लिए आवश्यक नहीं है जिसके लिए एक व्यवधान अभी-अभी हुआ है, और अपनी प्राथमिकता को कम करने और फिर बढ़ाने के लिए भी। पैकेट जो अभी प्राप्त किया गया है वह चुपचाप 200-300 माइक्रोसेकंड तक इंतजार करेगा जब तक कि उसके कार्य को उसकी टिक नहीं मिलती। और अगर हमारे पास 216 मेगाहर्ट्ज की आवृत्ति पर एक कॉर्टेक्स-एम 7 ऑपरेटिंग है, तो एक टिक के लिए 20 माइक्रोसेकंड काफी उचित है, क्योंकि इसे स्विच करने के लिए आधे से कम माइक्रोसेकंड का समय लगेगा। और ऊपर के उदाहरण से कोई भी कार्य देर से 140 माइक्रोसेकंड से अधिक नहीं होगा।

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

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

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

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

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

IAR के तहत दो परीक्षण परियोजनाएं और उपयोग किए गए STM32F3DISCOVERY बोर्ड का विवरण यहां देखा जा सकता है । पहले प्रोजेक्ट में, ATS303 ने केवल अपने प्रदर्शन की जाँच की और इसे डीबग किया। इस बोर्ड में स्थापित सभी एलईडी काम में आए। किसी को चोट नहीं आई।

BTS303 के दूसरे ड्राफ्ट ने दो उल्लिखित संसाधन आवंटन विकल्पों का परीक्षण किया। इसमें, कार्य 1 और 2 ऑपरेटर द्वारा प्राप्त किए गए परीक्षण संदेश उत्पन्न करते हैं। ऑपरेटर के साथ संवाद करने के लिए, मुझे TTL COM पोर्ट के साथ एक स्कार्फ जोड़ना था, जैसा कि नीचे दी गई तस्वीर में दिखाया गया है।

ऑपरेटर एक टर्मिनल एमुलेटर का उपयोग करता है। मुझे लगता है कि पाठक नरम ट्यूब रंग के लिए लेखक को बहाना देगा। ऐसा दिखता है।

रुकावटों को हल करने से पहले पूरे सिस्टम के संचालन को शुरू करने के लिए, शून्य कार्य मुख्य () के शरीर में प्रारंभिक चरणों की आवश्यकता होती है, जो नीचे प्रस्तुत किए गए हैं।

void main_start_task_switcher(U8 border); U8 task_run_and_return_task_number((U32)t1_task); U8 task_run_and_return_task_number((U32)t2_task); U8 task_run_and_return_task_number((U32)t3_human_link); U8 task_run_and_return_task_number((U32)t4_human_answer); U8 task_run_and_return_task_number((U32)task_5); U8 task_run_and_return_task_number((U32)task_6); U8 task_run_and_return_task_number((U32)task_7); 

इन पंक्तियों में, स्विच पहले शुरू होता है, और फिर, बदले में, शेष सात कार्य।

यहां नौकरी के लिए आवश्यक कॉल का न्यूनतम सेट है।

  void task_wake_up_action(U8 taskNumber); 

इस कॉल का उपयोग उपयोगकर्ता हार्डवेयर टाइमर से एक बाधा में किया जाता है। खुद के लिए बोलने वाले कार्यों से चुनौती।

  void release_me_and_set_sleep_steps(U32 ticks); U8 get_my_number(void); 

ये सभी फ़ंक्शन कोडांतरक स्विच फ़ाइल में हैं। कई और कार्य हैं जो परीक्षण के लिए उपयोगी हैं, लेकिन आवश्यक नहीं हैं।

BTS303 प्रोजेक्ट में, टास्क 3 बाहर से ऑपरेटर कमांड प्राप्त करता है और उसे कार्य 4 से आने वाले उत्तर भेजता है। टास्क 4 ऑपरेटर 3 से टास्क 3 से कमांड प्राप्त करता है और उन्हें संभावित उत्तरों के साथ निष्पादित करता है। टास्क 3 भी कार्यों 1 और 2 से संदेश प्राप्त करता है और इसे UART के माध्यम से टर्मिनल एमुलेटर (उदाहरण के लिए, पोटीन) में भेजता है।

टास्क 0 (मुख्य) कुछ सहायक काम करता है, उदाहरण के लिए, प्रत्येक कार्य के स्टैक्ड क्षेत्र में अप्रभावित छोड़ दिए गए शब्दों की संख्या की जांच करता है। यह जानकारी ऑपरेटर द्वारा अनुरोध की जा सकती है और स्टैक के उपयोग का विचार प्राप्त कर सकती है। प्रारंभ में, प्रत्येक कार्य के लिए, 512 बाइट्स (128 शब्द) का एक स्टैक क्षेत्र आवंटित किया जाता है और यह निगरानी करना आवश्यक है (कम से कम डिबगिंग चरण में) कि ये क्षेत्र ओवरफ्लो के करीब नहीं आते हैं।

कार्य 5 और 6 कुछ सामान्य फ्लोटिंग पॉइंट वैरिएबल पर गणना करते हैं। ऐसा करने के लिए, वे टास्क 7 से इसे एक्सेस करने का अनुरोध करते हैं।

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

  void wake_me_up_after_milliSeconds(U32 timeMS); 

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

जैसा कि आप देख सकते हैं, सभी आवश्यक कॉल की सूची एक पृष्ठ पर फिट होती है।