एक्वा RTOS बासकॉम AVR वातावरण में एमके AVR के लिए वास्तविक समय ओएस

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

यदि प्रणाली की जटिलता बढ़ती है, तो अन्योन्याश्रित झंडों की संख्या तेजी से बढ़ती है, और परियोजना जल्दी से खराब पठनीय और प्रबंधनीय "पास्ता कोड" में बदल जाती है।

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

इस कमी को ठीक करने के लिए, मैंने बासकॉम एवीआर प्रोग्रामिंग वातावरण के लिए एक सरल आरटीओएस विकसित किया, जिसे मैं पाठकों के ध्यान में लाता हूं।



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

नीचे दिए गए उदाहरण में, हम जांचना चाहते हैं कि बटन दबाया गया है या नहीं :

do ' -  if button = 1 then '     '  -  loop 

जाहिर है, अगर "कुछ कोड" लंबे समय तक काम करता है, तो एमके एक बटन के एक छोटे प्रेस को नोटिस नहीं कर सकता है।

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

 on button button_isr '    enable interrupts ' ***  *** do ' -  loop end '   button_isr: '  -    return 

हालांकि, इंटरप्ट का उपयोग करने से एक नई समस्या उत्पन्न होती है: इंटरप्ट हैंडलर कोड जितना संभव हो उतना तेज़ और कम होना चाहिए; अंदर रुकावट, एमके कार्यक्षमता सीमित है। चूंकि AVR MKs में एक पदानुक्रमित व्यवधान प्रणाली नहीं है, एक और व्यवधान एक अवरोध के अंदर नहीं हो सकता है - वे इस समय हार्डवेयर अक्षम हैं। इसलिए बाधा को जितनी जल्दी हो सके निष्पादित किया जाना चाहिए, अन्यथा अन्य व्यवधान (और संभवतः अधिक महत्वपूर्ण) को छोड़ दिया जाएगा और संसाधित नहीं किया जाएगा।


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

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

इस प्रकार, जटिलता का अगला स्तर उठता है - एक सुपर साइकिल जिसमें बाधाएं और झंडे होते हैं ।

निम्नलिखित कोड दिखाया गया है:

 on button button_isr '    enable interrupts ' ***  *** do ' -  if button_flag = 1 then '     button_flag = 0 '     end if '  -  loop end ' ***    *** button_isr: button_flag = 1 return 

एमके के लिए बहुत सारे कार्यक्रम इसके द्वारा सीमित हैं। हालांकि, ऐसे कार्यक्रम आमतौर पर कम या ज्यादा सरल होते हैं। यदि आप कुछ अधिक जटिल लिखते हैं, तो झंडे की संख्या स्नोबॉल की तरह बढ़ने लगती है, और कोड अधिक से अधिक भ्रमित और अपठनीय हो जाता है। इसके अलावा, ऊपर के उदाहरण में, देरी के साथ समस्या का समाधान नहीं किया गया है। बेशक, आप टाइमर पर एक अलग रुकावट को "लटका" सकते हैं, और इसमें ... विभिन्न झंडे को भी नियंत्रित करते हैं। लेकिन यह कार्यक्रम को पूरी तरह से बदसूरत बना देता है, अन्योन्याश्रित झंडों की संख्या तेजी से बढ़ रही है, और यहां तक ​​कि खुद डेवलपर शायद ही इस तरह के "पास्ता कोड" का पता लगा सकते हैं। एक गलती खोजने या कोड को संशोधित करने की कोशिश अक्सर एक नई परियोजना को विकसित करने के प्रयासों में बराबर हो जाती है।

"पास्ता कोड" की समस्या को कैसे हल करें और इसे अधिक पठनीय और प्रबंधनीय बनाएं? ऑपरेटिंग सिस्टम (OS) बचाव के लिए आता है। इसमें, एमके को लागू करने वाली कार्यक्षमता को उन कार्यों में विभाजित किया गया है जिनके संचालन को ओएस द्वारा नियंत्रित किया जाता है।

एमके के लिए ऑपरेटिंग सिस्टम के प्रकार

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

 1: goto 1 

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

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

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

टास्क स्विचिंग बेसकॉम एवीआर में

बेसक AVR वातावरण में कार्य स्विचिंग को लागू करने के लिए, कार्य कोड, जिसमें से प्रत्येक को एक सामान्य प्रक्रिया के रूप में लागू किया गया है, को किसी स्थान पर डिस्पैचर को कॉल करना चाहिए - एक सामान्य प्रक्रिया के रूप में भी लागू किया जाता है।
कल्पना करें कि हमारे पास दो कार्य हैं, जिनमें से प्रत्येक को इसके कोड के किसी स्थान पर डिस्पैचर द्वारा बुलाया जाता है।

 sub task1() do '  1 '  loop end sub ' ---------------------------------- sub task2() do '  2 '  loop end sub 

मान लीजिए कि कार्य 1 को निष्पादित किया गया था। आइए देखें कि स्टैक पर क्या होता है जब यह "डिस्पैचर कॉल" निष्पादित करता है:

मुख्य कोड पर पता वापस (2 बाइट्स)
स्टैक के शीर्ष -> टास्क 1 पर वापसी पता जिसे डिस्पैचर कहा जाता है (2 बाइट्स)

स्टैक के शीर्ष टास्क 1 में निर्देश के पते को इंगित करेगा, जो डिस्पैचर कॉल (हमारे उदाहरण में लूप इंस्ट्रक्शन) का अनुसरण करता है।

सबसे सरल मामले में डिस्पैचर का लक्ष्य टास्क 2 पर नियंत्रण स्थानांतरित करना है। सवाल यह है कि यह कैसे किया जाए? (मान लें कि डिस्पैचर पहले से ही टास्क 2 का पता जानता है)।

ऐसा करने के लिए, डिस्पैचर को स्टैक (और कहीं न कहीं याद करने के लिए) से टास्क 1 पर लौटने का पता खींचना चाहिए, और स्टैक 2 के पते को स्टैक पर इस जगह पर रखना चाहिए, और फिर रिटर्न कमांड दें। प्रोसेसर स्टैक से वहां रखे पते को निकाल देगा और, टास्क 1 पर लौटने के बजाय, टास्क 2 के निष्पादन के लिए आगे बढ़ेगा।

बदले में, जब टास्क 2 डिस्पैचर को कॉल करता है, तो हम स्टैक को भी बाहर निकालते हैं और उस पते को बचाते हैं जहां टास्क 2 पर वापस जाना संभव होगा, और स्टैक पर पहले से सहेजे गए कार्य 1 पते को लोड करें। रिटर्न कमांड दें और हम टास्क 1 के निरंतर बिंदु पर होंगे। ।

नतीजतन, हमें ऐसी गड़बड़ मिलती है:

टास्क 1 -> डिस्पैचर -> टास्क 2 -> डिस्पैचर -> टास्क 1 ...।

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

एक्वा RTOS

वर्णित विचार को लागू करने के लिए, सहकारी ओएस एक्वा आरटीओएस विकसित किया गया था, जो कार्यों को आवश्यक सेवाएं प्रदान करता है और बेसकॉम एवीआर वातावरण में सहकारी मल्टीटास्किंग को लागू करने की अनुमति देता है।

एक्वा RTOS कार्य स्थिति

एक्वा RTOS में कार्यों के लिए निम्नलिखित स्थितियां परिभाषित की गई हैं:

 OSTS_UNDEFINE OSTS_READY OSTS_RUN OSTS_DELAY OSTS_STOP OSTS_WAIT OSTS_PAUSE OSTS_RESTART 

यदि कार्य अभी तक आरंभ नहीं हुआ है, तो उसे OSTS_UNDEFINE का दर्जा दिया गया है ।
आरंभीकरण के बाद, कार्य की स्थिति OSTS_STOP है ।
यदि कार्य निष्पादन के लिए तैयार है , तो उसे OSTS_READY का दर्जा दिया जाता है ।
वर्तमान में चल रहे कार्य को OSTS_RUN का दर्जा प्राप्त है ।
इससे वह OSTS_STOP, OSTS_READY, OSTS_DELAY, OSTS_WAIT, OSTS_PAUSE की स्थिति में जा सकता है ।
स्थिति OSTS_DELAY में देरी को पूरा करने वाला कार्य है।
स्थिति OSTS_WAIT उन कार्यों के लिए असाइन की गई है जो किसी सेमाफ़ोर , ईवेंट, या संदेश की प्रतीक्षा कर रहे हैं (नीचे उनके बारे में अधिक)।

OSTS_STOP और OSTS_PAUSED स्थितियों में क्या अंतर है?
यदि किसी कारण से कार्य को OSTS_STOP की स्थिति प्राप्त होती है , तो कार्य का बाद का पुनः आरंभ ( OSTS_READY की स्थिति प्राप्त होने पर) इसके प्रवेश बिंदु से बाहर किया जाएगा, अर्थात शुरू से ही। OSTS_PAUSE की स्थिति से , कार्य उस स्थान पर कार्य करना जारी रखेगा जहां इसे निलंबित किया गया था।

कार्य स्थिति प्रबंधन

ओएस सेवाओं को कॉल करके दोनों ओएस खुद ही कार्यों, साथ ही उपयोगकर्ता का प्रबंधन कर सकते हैं। कई कार्य प्रबंधन सेवाएं हैं (सभी OS सेवाओं के नाम OS_ उपसर्ग के साथ शुरू होते हैं):

 OS_InitTask(task_label, task_prio) OS_Stop() OS_StopTask(task_label) OS_Pause() OS_PauseTask(task_label) OS_Resume() OS_ResumeTask(task_label) OS_Restart() 

उनमें से प्रत्येक के पास दो विकल्प हैं: OS_service और OS_serviceTask ( OS_InitTask सेवा को छोड़कर, जिसमें केवल एक ही विकल्प है; OS_Init सेवा ओएस को ही प्रारंभ करती है)।

OS_service और OS_serviceTask के बीच अंतर क्या है? पहला तरीका उस कार्य पर कार्य करता है जो इसके कारण होता है; दूसरा आपको एक तर्क को दूसरे कार्य के लिए एक संकेतक के रूप में सेट करने की अनुमति देता है और इस प्रकार, एक कार्य से दूसरे को प्रबंधित करने के लिए।

प्राथमिकता और कार्य कतार

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

एक्वा आरटीओएस में, प्राथमिकता को एक कार्य को सौंपा जाता है जब इसे OS_InitTask सेवा पर कॉल के माध्यम से शुरू किया जाता है, जो कि कार्य का पता पहले तर्क के रूप में प्राप्त करता है और दूसरे तर्क के रूप में 1 से 15 तक की संख्या । एक निचली प्राथमिकता का मतलब उच्च प्राथमिकता है । ओएस के संचालन के दौरान, कार्य को सौंपी गई प्राथमिकता में परिवर्तन प्रदान नहीं किया जाता है।

विलंब

प्रत्येक कार्य में, देरी को अन्य कार्यों से स्वतंत्र रूप से संसाधित किया जाता है।
इस प्रकार, जबकि ओएस एक कार्य की देरी से काम कर रहा है, दूसरों को निष्पादित किया जा सकता है।
प्रदान की गई सेवाओं के संगठन के लिए OS_Delay | OS_DelayTask । तर्क वह मिलीसेकंड की संख्या है जिसके लिए कार्य में देरी हो रही है । चूंकि तर्क का आयाम कम है, इसलिए अधिकतम देरी 4294967295 एमएस या लगभग 120 घंटे है, जो कि अधिकांश अनुप्रयोगों के लिए पर्याप्त लगती है। विलंब सेवा को कॉल करने के बाद, डिस्पैचर को स्वचालित रूप से कहा जाता है, जो देरी की अवधि के लिए अन्य कार्यों पर नियंत्रण स्थानांतरित करता है।

सेमाफोर

एक्वा RTOS में सेमाफोरेस कुछ ऐसे हैं जैसे झंडे और चर कार्यों के लिए उपलब्ध हैं। वे दो प्रकार के होते हैं - द्विआधारी और गणनीय। पहले में केवल दो राज्य हैं: मुक्त और बंद। दूसरा एक बाइट काउंटर है (एक्वा आरटीओएस के वर्तमान संस्करण में सेमाफोर्स की गिनती की सेवा लागू नहीं है (मैं एक आलसी गधा हूं), इसलिए नीचे कहा गया सब कुछ केवल द्विआधारी सेमाफोर पर लागू होता है)।

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

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

 hBSem OS_CreateBSemaphore() OS_WaitBSemaphore(hBSem) OS_WaitBSemaphoreTask(task_label, hBSem) OS_BusyBSemaphore(hBSem) OS_FreeBSemaphore(hBSem) 

उपयोग करने से पहले एक semaphore बनाया जाना चाहिए। यह OS_CreateBSemaphore सेवा को कॉल करके किया जाता है, जो बनाए गए hBSem सेमाफोर की विशिष्ट बाइट पहचानकर्ता (हैंडल) को लौटाता है , या उपयोगकर्ता द्वारा परिभाषित हैंडलर के माध्यम से एक OSERR_BSEM_AX_REACHED त्रुटि उत्पन्न करता है, जो दर्शाता है कि बाइनरी सेमाफोर की अधिकतम संभव संख्या तक पहुंच गई है।

आप प्राप्त किए गए पहचानकर्ता के साथ इसे अन्य अर्ध-सेवाओं के तर्क के रूप में पारित करके काम कर सकते हैं।

सेवा OS_WaitBSemaphore | OS_WaitBSemaphoreTask एक अवस्था में (वर्तमान निर्दिष्ट) कार्य डालता है hBSem सेमाफोर की रिहाई के लिए प्रतीक्षा करने के लिए यदि यह सेमीफोर व्यस्त है, और फिर डिस्पैचर को नियंत्रण स्थानांतरित करता है ताकि यह अन्य कार्यों को शुरू कर सके। यदि सेमाफोर मुक्त है, तो नियंत्रण हस्तांतरण नहीं होता है, और कार्य बस जारी रहता है।

OS_BusyBSemaphore और OS_FreeBSemaphore सेवाएं क्रमशः व्यस्त या मुफ्त में hBSem सेमाफ़ोर सेट करती हैं।

ओएस को सरल बनाने और कोड की मात्रा को कम करने के लिए सेमाफोर का विनाश प्रदान नहीं किया गया है। इस प्रकार, सभी बनाए गए सेमीफोर स्थिर हैं।

घटनाओं

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

कार्य किन घटनाओं पर प्रतिक्रिया दे सकता है? खैर, उदाहरण के लिए:

• रुकावट;
• एक त्रुटि की घटना;
• संसाधन की रिहाई (कभी-कभी इसके लिए एक सेमाफोर का उपयोग करना अधिक सुविधाजनक होता है);
• I / O लाइन की स्थिति बदलने या कीबोर्ड पर एक कुंजी दबाने;
• RS-232 के माध्यम से एक चरित्र प्राप्त करना या भेजना;
• एप्लिकेशन के एक भाग से दूसरे में सूचना स्थानांतरण (संदेश भी देखें)।

ईवेंट सिस्टम को निम्नलिखित सेवाओं के माध्यम से कार्यान्वित किया जाता है:

 hEvent OS_CreateEvent() OS_WaitEvent(hEvent) OS_WaitEventTask(task_label, hEvent) OS_WaitEventTO(hEvent, dwTimeout) OS_SignalEvent(hEvent) 

किसी घटना का उपयोग करने से पहले, आपको इसे बनाने की आवश्यकता है । यह OS_CreateEvent फ़ंक्शन को कॉल करके किया जाता है, जो hEvent इवेंट के लिए एक अद्वितीय बाइट पहचानकर्ता (हैंडल) लौटाता है , या उपयोगकर्ता परिभाषित हैंडलर के माध्यम से OSERR_EVENT_MAX_REACHED त्रुटि फेंकता है, यह दर्शाता है कि OS में उत्पन्न होने वाली घटनाओं की सीमा (अधिकतम 255 विभिन्न घटनाओं) तक पहुंच गई है।

किसी कार्य को hEvent ईवेंट के लिए प्रतीक्षा करने के लिए, अपने कोड में OS_WaEEvent को तर्क के रूप में ईवेंट हैंडल से कॉल करें। इस सेवा को कॉल करने के बाद, नियंत्रण स्वचालित रूप से डिस्पैचर को स्थानांतरित कर दिया जाएगा।

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

कार्य या पृष्ठभूमि कोड OS_SignalEvent सेवा को कॉल करके किसी दिए गए ईवेंट की घटना का संकेत दे सकता है , जो एक तर्क के रूप में ईवेंट हैंडल को प्राप्त करता है। इस स्थिति में, इस घटना की प्रतीक्षा करने वाले सभी कार्य, ओएस निष्पादन के लिए तैयार स्थिति को निर्धारित करेगा , ताकि वे प्राथमिकता और प्राथमिकता के क्रम में निष्पादित करना जारी रख सकें।

संदेशों

मैसेज सिस्टम सामान्य रूप से ईवेंट सिस्टम के समान काम करता है, लेकिन यह अधिक विकल्पों और लचीलेपन के साथ कार्य प्रदान करता है: यह न केवल एक निर्दिष्ट विषय पर एक संदेश की उम्मीद प्रदान करता है, बल्कि जिस तरह से संदेश स्वयं एक कार्य से दूसरे में प्रसारित होता है - एक संख्या या एक स्ट्रिंग।
यह निम्नलिखित सेवाओं के माध्यम से कार्यान्वित किया जाता है:

 hTopic OS_CreateMessage() OS_WaitMessage(hTopic) OS_WaitMessageTask(task_label, hTopic) OS_WaitMessageTO(hTopic, dwTimeout) OS_SendMessage(hTopic, wMessage) word_ptr OS_GetMessage(hTopic) word_ptr OS_PeekMessage(hTopic) string OS_GetMessageString(hTopic) string OS_PeekMessageString(hTopic) 

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

कार्य को hTopic विषय पर एक संदेश के लिए प्रतीक्षा करने के लिए बताने के लिए , तर्क के रूप में विषय के हैंडल को पास करते हुए, इसके कोड में OS_WitMessage को कॉल करें । इस सेवा को कॉल करने के बाद, नियंत्रण स्वचालित रूप से कार्य प्रबंधक को स्थानांतरित कर दिया जाएगा। इस प्रकार, यह सेवा एक राज्य में वर्तमान कार्य करती हैएक hTopic संदेश के लिए प्रतीक्षा करें । OS_WaitMessageTO

टाइमआउट के साथ प्रतीक्षा सेवा इवेंट सिस्टम के OS_WaitEventTO सेवा के समान कार्य करती है। संदेश भेजने के लिए, OS_SendMessage सेवा प्रदान की जाती है । पहला तर्क उस विषय को हैंडल है जिससे संदेश प्रेषित किया जाएगा, और दूसरा शब्द आयाम तर्क है । यह या तो एक स्वतंत्र संख्या या स्ट्रिंग के लिए एक संकेतक हो सकता है , जो बदले में, पहले से ही एक संदेश है। एक स्ट्रिंग के लिए सूचक पाने के लिए, यह उपयोग करने के लिए पर्याप्त होता निर्मित BASCOM में समारोह VarPtr , इसलिए की तरह:

 strMessage = "Hello, world!" OS_SendMessage hTopic, varptr (strMessage) 

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

यदि कार्य को तुरंत स्ट्रिंग की आवश्यकता है, न कि सूचक की, तो आप सेवाओं का उपयोग कर सकते हैं OS_GetMessageString या OS_PeekMessageString , जो पिछले दो के समान काम करते हैं, लेकिन एक स्ट्रिंग लौटाते हैं, इसके लिए कोई संकेतक नहीं।

आंतरिक टाइमर सेवा

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

एक्वा RTOS के साथ काम करने के उदाहरण

प्रारंभिक सेटिंग्स

उपयोगकर्ता कोड की शुरुआत में, आपको यह निर्धारित करने की आवश्यकता है कि क्या कोड अंतर्निहित सिम्युलेटर में या वास्तविक हार्डवेयर पर निष्पादित किया जाएगा। निरंतर OS_SIM = TRUE को परिभाषित करें FALSE , जो सिमुलेशन मोड सेट करता है।

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

ओएस आरंभीकरण

शुरू करने से पहले, एक्वा आरटीओएस को आरंभीकृत किया जाना चाहिए। ऐसा करने के लिए, OS_Init सेवा को कॉल करें । यह सेवा प्रारंभिक OS सेटिंग्स को कॉन्फ़िगर करती है। इससे भी महत्वपूर्ण बात, इसका एक तर्क है - उपयोगकर्ता द्वारा परिभाषित दिनचर्या को संभालने में त्रुटि। बदले में, उसके पास एक तर्क भी है - एक त्रुटि कोड।

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

इसलिए, AQUA RTOS के साथ काम करने में पहला कदम है ओएस प्रोग्राम में ओएस इनिशियलाइज़ेशन कोड और एरर हैंडलर प्रक्रिया जोड़ना।

 OS_Init my_err_trap '... '... '... sub my_err_trap(err_code as byte) print err_code end sub 

टास्क आरंभीकरण

दूसरा कदम उनके नाम और प्राथमिकता को निर्दिष्ट करके कार्यों को आरंभ करना है:

 OS_InitTask task_1, 1 OS_InitTask task_2 , 1 '... OS_InitTask task_N , 1 

परीक्षण कार्य

एलईडी चमकती हुई

तो, आइए एक परीक्षण एप्लिकेशन बनाएं जिसे एक मानक Arduino नैनो V3 बोर्ड में डाउनलोड किया जा सकता है। ओएस फ़ाइल के साथ फ़ोल्डर में एक फ़ोल्डर बनाएं (उदाहरण के लिए, परीक्षण), और वहां निम्न बेस-फ़ाइल बनाएं:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_1() declare sub task_2() '       led_1 alias portd.4 led_2 alias portd.5 config portd.4 = output config portd.5 = output ' ***    *** '   OS_Init my_err_trap '   OS_InitTask task_1, 1 OS_InitTask task_2 , 1 '      «» (OSTS_STOP) '    ,     ' «  » (OSTS_READY)   OS_ResumeTask OS_ResumeTask task_1 OS_ResumeTask task_2 '      OS_Sheduler end ' ***  *** sub task_1 () do toogle led_1 '   1 OS_delay 1000 '   1000  loop end sub sub task_2 () do toogle led_2 '   2 OS_delay 333 '   333  loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

Arduino बोर्ड के D4 और D5 पिन (या कोड में संबंधित परिभाषा लाइनों को बदलकर अन्य पिन) को एल ई डी के एनोड से कनेक्ट करें । 100 ... 500 ओम के माध्यम से कैथोड को कनेक्ट करें GND बस को प्रतिरोधक । फर्मवेयर को बोर्ड पर संकलित और अपलोड करें। एलईडी 2 और 0.66 एस की अवधि के साथ एसिंक्रोनस रूप से स्विच करना शुरू कर देंगे।

कोड को देखते हैं। इसलिए, पहले हम उपकरण को इनिशियलाइज़ करते हैं (हम कंपाइलर ऑप्शन्स, पोर्ट्स का मोड और एलियसेस असाइन करते हैं), फिर ओएस ही, और आखिरकार टास्क।

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

अब कार्य निष्पादन के लिए तैयार हैं, लेकिन अभी तक पूरा नहीं हुआ है। उन्हें कौन लॉन्च करेगा? बेशक, डिस्पैचर! ऐसा करने के लिए, हमें सिस्टम की पहली शुरुआत में इसे कॉल करना होगा। अब, यदि सब कुछ सही ढंग से लिखा गया है, तो डिस्पैचर एक-एक करके हमारे कार्यों का प्रदर्शन करेगा, और हम कार्यक्रम के मुख्य भाग को अंतिम विवरण के साथ समाप्त कर सकते हैं।

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

यदि आप कोड की शुरुआत में निरंतर OS_SIM = TRUE सेट करते हैं और कोड को वास्तविक चिप पर नहीं, बल्कि एक सिम्युलेटर में चलाते हैं, तो आप यह पता लगा सकते हैं कि OS कैसे काम करता है।

डिस्पैचर जिसे हम कहते हैं, यह देखेंगे कि क्या स्थिति वाले कार्य "निष्पादन के लिए तैयार हैं" और उन्हें प्राथमिकता के अनुसार लाइन करें। यदि प्राथमिकता समान है, तो प्रेषणकर्ता "हिंडोला पर कार्यों को रोल करेगा", नए पूर्ण किए गए कार्य को कतार के बहुत अंत तक ले जाना।

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

टास्क task_1 , इसकी LED को स्विच करता है, OS_delay सेवा को कॉल करता है , जो आवश्यक क्रियाओं को पूरा करने के बाद डिस्पैचर में जाती है।

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

टास्क task_2 , इसकी एलईडी को स्विच करते हुए, OS_delay सेवा को कॉल करता है , जो आवश्यक क्रियाओं को करने के बाद डिस्पैचर में जाता है।

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

संदेश भेजें

अब एक कार्य से दूसरे कार्य पर संदेश भेजने का प्रयास करें।

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_1() declare sub task_2() const OS_SIM = TURE '       '   dim hTopic as byte '     dim task_1_cnt as byte '    1 dim strMessage as string * 16 '  ' ***    *** OS_CreateMessage hTopic OS_Init my_err_trap OS_InitTask task_1 , 1 OS_InitTask task_2 , 1 OS_ResumeTask task_1 OS_ResumeTask task_2 OS_Sheduler end ' ***  *** sub task_1() do print "task 1" OS_Sheduler incr task_1_cnt '    1 if task_1_cnt > 3 then print "task 1 is sending message to task 2" strMessage = "Hello, task 2!" '    2 OS_SendMessage hTopic , varptr(strMessage) task_1_cnt = 0 end if loop end sub sub task_2() do print "task 2 is waiting messages..." '      1 OS_WaitMessage hTopic print "message recieved: " ; OS_GetMessageString (hTopic) loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

सिम्युलेटर में प्रोग्राम चलाने का परिणाम टर्मिनल विंडो में निम्नलिखित आउटपुट होगा:

task 1
task 2 is waiting messages…
task 1
task 1
task 1
task 1 is sending message to task 2
task 1
message recieved: Hello, task 2!
task 2 is waiting messages…
task 1
task 1
...

उस क्रम पर ध्यान दें जिसमें कार्य और कार्य स्विचिंग होते हैं। जैसे ही प्रिंट कार्य के रूप में 1 कार्य 1 , नियंत्रण नियंत्रक को स्थानांतरित कर रहा है, ताकि वह दूसरे काम शुरू कर सकता है। टास्क 2 प्रिंट्स टास्क 2 मेसेजिंग वेटिंग है ... , फिर hTopic विषय पर संदेश प्रतीक्षा सेवा को कॉल करता है , और नियंत्रण स्वचालित रूप से डिस्पैचर को स्थानांतरित कर दिया जाता है, जो फिर से टास्क 1 कहता है। यह टास्क 1 को फिर से प्रिंट करता है और डिस्पैचर को नियंत्रण देता है। हालाँकि, जब डिस्पैचर पता लगाता है कि टास्क 2 अब संदेशों की प्रतीक्षा कर रहा है, तो यह डिस्पैचर कॉल के बाद incr स्टेटमेंट पर टास्क 1 पर नियंत्रण लौटाता है ।
जब काउंटर कार्य_1_cntटास्क 1 में, यह निर्दिष्ट मूल्य से अधिक होगा, कार्य एक संदेश भेजता है, लेकिन फिर से निष्पादित करता है - लूप स्टेटमेंट और प्रिंट कार्य 1 को फिर से निष्पादित करता है । उसके बाद, वह डिस्पैचर को कॉल करती है, जो अब पता चलता है कि टास्क 2 के लिए एक संदेश है, और उसे नियंत्रण स्थानांतरित करता है। इसके बाद, प्रक्रिया को चक्रीय रूप से निष्पादित किया जाता है।

इवेंट हैंडलिंग

जब आप संबंधित बटन दबाते हैं, तो निम्न कोड दो बटन का चुनाव करता है और एलईडी को स्विच करता है:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_scankeys() declare sub task_led_1() declare sub task_led_2() '        led_1 alias portd.4 led_2 alias portd.5 config portd.4 = output config portd.5 = output button_1 alias pind.6 button_2 alias pind.7 config portd.6 = input config portd.7 = input '   dim eventButton_1 as byte dim eventButton_2 as byte ' ***    *** eventButton_1 = OS_CreateEvent '       eventButton_2 = OS_CreateEvent OS_Init my_err_trap OS_InitTask task_scankeys , 1 OS_InitTask task_led_1 , 1 OS_InitTask task_led_2 , 1 OS_ResumeTask task_scankeys OS_ResumeTask task_led_1 OS_ResumeTask task_led_2 OS_Sheduler end ' ***  *** sub task_scankeys() do debounce button_1 , 0 , btn_1_click , sub debounce button_2 , 0 , btn_2_click , sub OS_Sheduler loop btn_1_click: OS_SignalEvent eventButton_1 return btn_2_click: OS_SignalEvent eventButton_2 return end sub sub task_led_1() do OS_WaitEvent eventButton_1 toggle led_1 loop end sub sub task_led_2() do OS_WaitEvent eventButton_2 toggle led_2 loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

एक्वा RTOS के तहत एक वास्तविक आवेदन उदाहरण

आइए कल्पना करने की कोशिश करें कि कॉफी वेंडिंग मशीन कार्यक्रम कैसा दिख सकता है। मशीन को कॉफी विकल्पों की उपस्थिति और बटन में एलईडी की पसंद का संकेत देना चाहिए; सिक्का रिसीवर से संकेत प्राप्त करते हैं, आदेशित पेय तैयार करते हैं, परिवर्तन बदलते हैं। इसके अलावा, मशीन को आंतरिक उपकरणों को नियंत्रित करना होगा: उदाहरण के लिए, 95 पर वॉटर हीटर का तापमान बनाए रखना ... 97 ° C; उपकरण की खराबी और सामग्री के स्टॉक पर डेटा संचारित करें और रिमोट एक्सेस के माध्यम से कमांड प्राप्त करें (उदाहरण के लिए, जीएसएम मॉडेम के माध्यम से), साथ ही साथ सिग्नल बर्बरता भी।

घटना प्रेरित दृष्टिकोण

सबसे पहले, एक डेवलपर के लिए कार्यों और घटनाओं के आधार पर सामान्य "सुपर साइकिल + झंडे + बाधित" योजना से स्विच करना मुश्किल हो सकता है। इसके लिए उन बुनियादी कार्यों को उजागर करना होगा जो डिवाइस को प्रदर्शन करना चाहिए।
आइए हमारी मशीन के ऐसे कार्यों को रेखांकित करने का प्रयास करें:

• हीटर नियंत्रण और प्रबंधन - ControlHeater ()
• उपलब्धता और पेय की पसंद का संकेत - ShowGoods ()
• सिक्कों / बिलों और उनके योग की स्वीकृति - AcceptMoney ()
• मतदान बटन - ScanKeys ()
• परिवर्तन वितरण - MakeChange ()
• ड्रिंक लीव - रिलीज़कॉफ़ी ()
• बर्बरता संरक्षण - अलार्म ()

आइए हम कार्यों के महत्व की डिग्री और उनकी कॉल की आवृत्ति का अनुमान लगाते हैं।
कंट्रोलहाइटर () स्पष्ट रूप से महत्वपूर्ण है क्योंकि हमें कॉफी बनाने के लिए हमेशा उबलते पानी की आवश्यकता होती है। लेकिन इसे बहुत बार नहीं किया जाना चाहिए, क्योंकि हीटर में उच्च जड़ता होती है, और पानी धीरे-धीरे ठंडा होता है। यह एक मिनट में एक बार तापमान की जांच करने के लिए पर्याप्त है। इस कार्य को प्राथमिकता
दें 5. ShowGoods () बहुत महत्वपूर्ण नहीं है। माल जारी होने के बाद ही प्रस्ताव बदल सकता है, अगर किसी भी सामग्री की आपूर्ति समाप्त हो जाती है। इसलिए, हम इस कार्य को 8 की प्राथमिकता देंगे, और मशीन के शुरू होने पर और हर बार माल जारी होने पर इसे निष्पादित किया जाएगा।
स्कैनकेय ()बटन दबाने की जल्दी से प्रतिक्रिया देने के लिए मशीन के लिए एक उच्च पर्याप्त प्राथमिकता होनी चाहिए। इस कार्य को प्राथमिकता 3 दें, और हम इसे हर 40 मिलीसेकंड पर निष्पादित करेंगे।
AcceptMoney () भी यूजर इंटरफेस का हिस्सा है। हम इसे ScanKeys () के समान प्राथमिकता देंगे , और इसे हर 20 मिलीसेकंड पर निष्पादित करेंगे।
MakeChange () माल जारी होने के बाद ही निष्पादित किया जाता है। हम इसे रिलीज़कॉफ़ी () के साथ जोड़ेंगे और प्राथमिकता देंगे 10.
रिलीज़कॉफ़ी () की आवश्यकता तभी है जब उचित मात्रा में धन स्वीकार किया गया हो और पेय चयन बटन दबाया गया हो। त्वरित प्रतिक्रिया के लिए, हम इसे प्राथमिकता देते हैं। 2.
चूंकि बर्बर प्रतिरोध मशीन का एक महत्वपूर्ण कार्य है, अलार्म () कार्यआप सर्वोच्च प्राथमिकता निर्धारित कर सकते हैं - 1, और झुकाव या छेड़छाड़ सेंसर की जांच करने के लिए एक सेकंड में एक बार सक्रिय करें।

इस प्रकार, हमें विभिन्न प्राथमिकताओं के साथ सात कार्यों की आवश्यकता होगी। शुरू होने के बाद, जब प्रोग्राम ने EEPROM से सेटिंग्स को पढ़ा और उपकरणों को इनिशियलाइज़ किया, तो यह ओएस को इनिशियलाइज़ करने और टास्क शुरू करने का समय है।

 '    declare sub ControlHeater() declare sub ShowGoods() declare sub AcceptMoney() declare sub ScanKeys() declare sub MakeChange () declare sub ReleaseCoffee() declare sub Alarm() 

RTOS के हिस्से के रूप में काम करने के लिए, प्रत्येक कार्य के लिए एक निश्चित संरचना होनी चाहिए: इसमें डिस्पैचर के लिए कम से कम एक कॉल होनी चाहिए (या एक OS सेवा जो स्वचालित रूप से डिस्पैचर पर नियंत्रण स्थानांतरित करती है) - यह सहकारी मल्टीटास्किंग सुनिश्चित करने का एकमात्र तरीका है।

उदाहरण के लिए, रिलीज़कॉफ़ी () कुछ इस तरह दिख सकती है:

 sub ReleaseCoffee() do OS_WaitMessage bCoffeeSelection wItem = OS_GetMessage(bCoffeeSelection) Release wItem loop end sub 

अनन्त लूप में रिलीज़कॉफ़ी कार्य , bCfishSelection विषय पर एक संदेश की उम्मीद करता है और जब तक यह नहीं आता है (नियंत्रण स्वचालित रूप से डिस्पैचर में वापस आ जाता है ताकि वह अन्य कार्यों को शुरू कर सके)। एक बार जब संदेश भेजा है, ReleaseCoffee () चलाने के लिए तैयार हो जाता है, और जब ऐसा होता है, कार्य संदेश (चयनित पेय के कोड) की सामग्री हो जाता है wItem सेवा के माध्यम से OS_GetMessage और ग्राहकों के लिए विज्ञप्ति माल। चूंकि रिलीज़कॉफ़ी () संदेश सबसिस्टम का उपयोग करता है, मल्टीटास्किंग शुरू करने से पहले एक संदेश बनाया जाना चाहिए:

 dim bCoffeeSelection as byte bCoffeeSelection = OS_CreateMessage() 

जैसा कि ऊपर उल्लेख किया गया है, शो-गुड्स () को एक बार स्टार्ट-अप और हर बार जब माल जारी किया जाता है, तब निष्पादित किया जाना चाहिए। इसे रिलीज़ प्रक्रिया रिलीज़कॉफ़ी () के साथ जोड़ने के लिए , हम ईवेंट सेवा का उपयोग करते हैं। ऐसा करने के लिए, मल्टीटास्किंग शुरू करने से पहले एक घटना बनाएं:

 dim bGoodsReliased as byte bGoodsReliased = OS_CreateEvent() 

और इस प्रक्रिया में ReleaseCoffee () पंक्ति के बाद रिलीज wItem ऐड अलार्म घटना bGoodsReliased :

 OS_SignalEvent bGoodsReliased 

ओएस आरंभीकरण

काम के लिए ओएस तैयार करने के लिए, हमें इसे प्रारंभ करना होगा, त्रुटि हैंडलर के पते को इंगित करना, जो उपयोगकर्ता कोड में है। हम OS_Init सेवा का उपयोग करके ऐसा करते हैं :

 OS_Init Mailfuncion 

उपयोगकर्ता कोड में, आपको एक हैंडलर जोड़ने की आवश्यकता है - एक प्रक्रिया जिसका बाइट तर्क त्रुटि कोड है:

 sub Mailfuncion (bCoffeeErr) print "Mailfunction! Error #: "; bCoffeeErr if isErrCritical (bCoffeeErr) = 1 then CallService(bCoffeeErr) end if end sub 

यह प्रक्रिया एक त्रुटि कोड प्रिंट करती है (या इसे किसी अन्य तरीके से प्रदर्शित कर सकती है: स्क्रीन पर, जीएसएम मॉडम, आदि के माध्यम से), और यदि त्रुटि गंभीर है, तो इसे सेवा विभाग कहता है।

कार्य का शुभारंभ

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

 OS_InitTask ControlHeater , 5 OS_InitTask ShowGoods , 8 OS_InitTask AcceptMoney , 3 OS_InitTask ScanKeys , 3 OS_InitTask MakeChange, 10 OS_InitTask ReleaseCoffee , 2 OS_InitTask Alarm , 1 

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

 OS_ResumeTask ControlHeater OS_ResumeTask ShowGoods OS_ResumeTask AcceptMoney OS_ResumeTask ScanKeys OS_ResumeTask MakeChange OS_ResumeTask ReleaseCoffee OS_ResumeTask Alarm 

जैसा कि पहले ही उल्लेख किया गया है, मल्टीटास्किंग लॉन्च होने पर सभी कार्यों को आवश्यक रूप से शुरू नहीं करना चाहिए; उनमें से कुछ किसी भी समय "बंद" स्थिति में रह सकते हैं और केवल कुछ शर्तों के तहत तत्परता प्राप्त कर सकते हैं। OS_ResumeTask सेवा को कोड (पृष्ठभूमि या कार्य) में कहीं से भी किसी भी समय कॉल किया जा सकता है जब मल्टीटास्किंग पहले से ही चल रहा हो। मुख्य बात यह है कि जिस कार्य को संदर्भित करता है वह प्रारंभिक-प्रारंभिक है।

मल्टीटास्किंग शुरू

अब सब कुछ मल्टीटास्किंग शुरू करने के लिए तैयार है। हम इसे डिस्पैचर बुलाकर करते हैं:

 OS_Sheduler 

उसके बाद, हम प्रोग्राम कोड में सुरक्षित रूप से अंत डाल सकते हैं - ओएस अब कोड के आगे निष्पादन का ख्याल रखता है।

आइए देखें पूरा कोड:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $include "coffee_hardware.bas" '      '       Coffee_ $regfile = "m328pdef.dat" ' Arduino Nano v3 $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 Coffee_InitHardware '    '   declare sub Mailfuncion (byval bCoffeeErr as byte) '   declare sub ControlHeater () '   declare sub ShowGoods () '    declare sub AcceptMoney () '   declare sub ScanKeys () '   declare sub MakeChange () '      declare sub ReleaseCoffee () '   declare sub Alarm () '    '     Coffee_InitHardware () '   dim wMoney as long '    dim wGoods as long '   ' ***    *** '   OS_Init Mailfuncion '       dim bCoffeeSelection as byte bCoffeeSelection = OS_CreateMessage() '     dim bGoodsReliased as byte bGoodsReliased = OS_CreateEvent() '   OS_InitTask ControlHeater , 5 OS_InitTask ShowGoods , 8 OS_InitTask AcceptMoney , 3 OS_InitTask ScanKeys , 3 OS_InitTask MakeChange, 10 OS_InitTask ReleaseCoffee , 2 OS_InitTask Alarm , 1 '     OS_ResumeTask ControlHeater OS_ResumeTask ShowGoods OS_ResumeTask AcceptMoney OS_ResumeTask ScanKeys OS_ResumeTask MakeChange OS_ResumeTask ReleaseCoffee OS_ResumeTask Alarm '   OS_Sheduler end ' ***   *** ' ----------------------------------- sub ControlHeater() do select case GetWaterTemp() case is > 97 Coffee_HeaterOff '   case is < 95 Coffee_HeaterOn '   case is < 5 CallServce (WARNING_WATER_FROZEN) '   end select OS_Delay 60000 '  1  loop end sub ' ----------------------------------- sub ShowGoods() do LEDS = Coffee_GetDrinkSupplies() '    D, '         '   LEDS OS_WaitEvent bGoodsReliased '   " " loop end sub ' ----------------------------------- sub AcceptMoney() do wMoney = wMoney + ReadMoneyAcceptor() OS_Delay 20 loop end sub ' ----------------------------------- sub ScanKeys() do wGoods = ButtonPressed() if wMoney >= GostOf(wGoods) then OS_SendMessage bCoffeeSelection, wGoods '     bCoffeeSelection,  '     end if OS_Delay 40 loop end sub ' ----------------------------------- sub MakeChange() do OS_WaitEvent bGoodsReliased '   " " Refund wMoney loop end sub ' ----------------------------------- sub ReleaseCoffee() do OS_WaitMessage bCoffeeSelection '  bCoffeeSelection wItem = OS_GetMessage(bCoffeeSelection) '   Release wItem '    wMoney = wMoney – CostOf (wItem) '     OS_SignalEvent bGoodsReliased '     '  ,       : ' MakeChange  ShowGoods '  ,  ,     loop end sub ' ----------------------------------- sub Alarm() do OS_Delay 1000 if Hijack() = 1 then CallPolice() end if loop end sub ' ----------------------------------- ' ***    *** sub Mailfuncion (bCoffeeErr) print "Mailfunction! Error #: "; bCoffeeErr if isErrCritical (bCoffeeErr) = 1 then CallService() end if end sub 

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

एक्वा RTOS स्रोत कोड

संस्करण 1.05 का स्रोत कोड यहां डाउनलोड के लिए उपलब्ध है

उपसंहार

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

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