RTOS के बारे में पूरी सच्चाई। अनुच्छेद # 33। न्यूक्लियस एसई रियल-टाइम ऑपरेटिंग सिस्टम का उपयोग करना

लेखों की इस श्रृंखला में अब तक हम देख रहे हैं कि न्यूक्लियस एसई क्या सुविधाएँ प्रदान करता है। अब यह देखने का समय है कि वास्तविक फर्मवेयर एप्लिकेशन में इसका उपयोग कैसे किया जा सकता है।

न्यूक्लियस एसई क्या है?

हम जानते हैं कि न्यूक्लियस एसई एक वास्तविक समय ऑपरेटिंग सिस्टम का मूल है, लेकिन आपको यह समझने की आवश्यकता है कि यह बाकी एप्लिकेशन में कैसे फिट बैठता है। और यह सिर्फ फिट बैठता है, क्योंकि एक डेस्कटॉप ऑपरेटिंग सिस्टम (उदाहरण के लिए, विंडोज) के विपरीत, एप्लिकेशन न्यूक्लियस एसई पर शुरू नहीं होता है; कर्नेल एक एम्बेडेड डिवाइस पर चलने वाले प्रोग्राम का हिस्सा है। यह RTOS के लिए सबसे आम उपयोग का मामला है।

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

न्यूक्लियस एसई (और कई अन्य समान गुठली) का उपयोग करते समय, अंतर यह है कि मुख्य () फ़ंक्शन कर्नेल कोड का हिस्सा है। यह फ़ंक्शन केवल कर्नेल की डेटा संरचनाओं को प्रारंभ करता है, और फिर शेड्यूलर को कॉल करता है, जो एप्लिकेशन कोड (कार्यों) के लॉन्च की ओर जाता है। उपयोगकर्ता मुख्य () फ़ंक्शन के लिए कोई भी मूल आरंभीकरण कोड जोड़ सकता है।

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

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

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

सीपीयू और टूल सपोर्ट

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

न्यूक्लियस एसई ऐप की स्थापना

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

Nuse_config.h सेटिंग

यह फ़ाइल #define निर्देश का केवल एक वर्ण सेट है, जिसे आवश्यक कर्नेल कॉन्फ़िगरेशन प्राप्त करने के लिए उपयुक्त मान असाइन किए गए हैं। Nuse_config.h फ़ाइल में , डिफ़ॉल्ट रूप से, सभी वर्ण मौजूद हैं, लेकिन उन्हें न्यूनतम सेटिंग्स असाइन की गई हैं।

ऑब्जेक्ट काउंटर
प्रत्येक प्रकार की कर्नेल ऑब्जेक्ट की संख्या को NUSE_SEMAPHORE_NUMBER के प्रतीक मानों द्वारा सेट किया जाता है । अधिकांश वस्तुओं के लिए, यह मान 0 से 15 तक भिन्न हो सकता है। कार्य एक अपवाद हैं, कम से कम एक होना चाहिए। सिग्नल, वास्तव में, स्वतंत्र ऑब्जेक्ट नहीं हैं, क्योंकि वे कार्यों से जुड़े हैं और NUSE_SIGNAL_SUPPOR T को TRUE पर सेट करके चालू हैं।

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

शेड्यूलर चयन और सेटिंग्स
न्यूक्लियस एसई चार प्रकार के अनुसूचियों का समर्थन करता है, जैसा कि पिछले लेख में वर्णित है। उपयोग किए गए शेड्यूलर को NUSE_SCHEDULER_TYPE को निम्न मानों में से एक पर सेट करके सेट किया गया है: NUSE_RUN_TO_COMPLETION_SCHEDULER , NUSE_TIME_SLICE_SCHEDULER , NUSE_ROUND_ROBIN_SCHEDULER या NUSE_PRIORITY_SCH ।

आप अन्य अनुसूचक मापदंडों को कॉन्फ़िगर कर सकते हैं:
NUSE_TIME_SLICE_TICKS टाइम स्लाइस शेड्यूलर के लिए प्रति स्लॉट टिक की संख्या इंगित करता है। यदि किसी अन्य शेड्यूलर का उपयोग किया जाता है, तो यह पैरामीटर 0 पर सेट होना चाहिए।
शेड्यूल काउंटर तंत्र को सक्षम / अक्षम करने के लिए NUSE_SCHEDULE_COUNT_SUPPORT TRUE या FALSE पर सेट किया जा सकता है।
NUSE_SUSPEND_ENABLE कई API फ़ंक्शन के लिए कार्य लॉकिंग (निलंबन) सक्षम करता है। इसका मतलब यह है कि इस तरह के फ़ंक्शन को कॉल करने पर संसाधन जारी होने तक कॉलिंग कार्य का निलंबन हो सकता है। इस विकल्प को चुनने के लिए, NUSE_SUSPEND_ENABLE को भी TRUE पर सेट करना होगा ।

अन्य विकल्प
अन्य कर्नेल फ़ंक्शन को सक्रिय / निष्क्रिय करने के लिए कई अन्य मापदंडों को TRUE या FALSE मान भी दिए जा सकते हैं:
NUSE_API_PARAMETER_CHECKING API फ़ंक्शन कॉल पैरामीटर सत्यापन कोड जोड़ता है। आमतौर पर डिबगिंग के लिए उपयोग किया जाता है।
NUSE_INITIAL_TASK_STATE_SUPPORT NUSE_READY या NUSE_PURE_SUSPEND के रूप में सभी कार्यों की प्रारंभिक स्थिति सेट करता है। यदि यह पैरामीटर अक्षम है, तो सभी कार्यों में प्रारंभिक स्थिति NUSE_READY होगी ।
NUSE_SYSTEM_TIME_SUPPORT - सिस्टम समय के लिए समर्थन।
NUSE_INCLUDE_EVERYTHING - एक ऐसा पैरामीटर जो न्यूक्लियस एसई के कॉन्फ़िगरेशन में अधिकतम संख्या में फ़ंक्शन जोड़ता है। यह सभी वैकल्पिक कार्यक्षमता और कॉन्फ़िगर की गई वस्तुओं के प्रत्येक एपीआई फ़ंक्शन के सक्रियण की ओर जाता है। कर्नेल कोड के एक नए पोर्टिंग को सत्यापित करने के लिए न्यूक्लियस एसई कॉन्फ़िगरेशन को जल्दी से बनाने के लिए उपयोग किया जाता है।

Nuse_config.c सेट करना

Nuse_config.h में कर्नेल कॉन्फ़िगरेशन को निर्दिष्ट करने के बाद , रॉम में संग्रहीत विभिन्न डेटा संरचनाओं को प्रारंभ करना आवश्यक है। यह nuse_config.c फ़ाइल में किया जाता है। डेटा संरचनाओं की परिभाषा सशर्त संकलन द्वारा नियंत्रित की जाती है, इसलिए सभी संरचनाएं डिफ़ॉल्ट nuse_config.c फ़ाइल की एक प्रति में निहित हैं।

टास्क डेटा
NUSE_Task_Start_Address [] सरणी को प्रत्येक कार्य के शुरुआती पतों के मूल्य के साथ आरंभ किया जाना चाहिए। यह आमतौर पर केवल कोष्ठकों के बिना फ़ंक्शन नामों की एक सूची है। कार्य प्रविष्टि कार्यों के प्रोटोटाइप भी दिखाई देने चाहिए। डिफ़ॉल्ट फ़ाइल में, कार्य NUSE_Idle_Task () नाम से कॉन्फ़िगर किया गया है, इसे एप्लिकेशन कार्य में बदला जा सकता है।

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

यदि फ़ंक्शन को कार्य की प्रारंभिक स्थिति ( NUSE_INITIAL_TASK_STATE_SUPPORT पैरामीटर का उपयोग करते हुए ), NUSE_Task_Initial_State [] सरणी को NUSE_READY या NUSE_PURE_SUSPEND स्थिति के साथ आरंभीकृत किया जाना चाहिए।

विभाजन पूल डेटा
यदि कम से कम एक विभाजन पूल कॉन्फ़िगर किया गया है, तो ROM में उनमें से प्रत्येक के लिए एक सरणी (प्रकार U8 ) बनाई जानी चाहिए। इन सरणियों के आकार की गणना निम्नानुसार की जाती है: (विभाजन की संख्या * (विभाजन आकार + 1))। इन अनुभागों के पते (अर्थात, उनके नाम) संबंधित NUSE_Partition_Pool_Data_Address [] तत्वों को निर्दिष्ट किए जाने चाहिए। प्रत्येक पूल के लिए, विभाजन की संख्या और उनके आकार को क्रमशः NUSE_Partition_Pool_Partition_Number [] और NUSE_Partition_Message_Size [] में रखा जाना चाहिए।

कतार डेटा
यदि कम से कम एक कतार कॉन्फ़िगर की गई है, तो RAM में उनमें से प्रत्येक के लिए एक सरणी ( ADDR प्रकार की) बनाई जानी चाहिए। इन सरणियों का आकार प्रत्येक कतार में तत्वों की संख्या है। इन सरणियों के पते (अर्थात, उनके नाम) को संबंधित NUSE_Queue_Data [] तत्वों को सौंपा जाना चाहिए। प्रत्येक कतार का आकार संबंधित NUSE_Queue_Size [] तत्व को सौंपा जाना चाहिए।

डेटा लिंक डेटा
यदि कम से कम एक डेटा चैनल कॉन्फ़िगर किया गया है, तो इसके लिए (या उनमें से प्रत्येक के लिए) RAM में एक सरणी (प्रकार U8 ) बनाई जानी चाहिए। इन सरणियों के आकार की गणना निम्न प्रकार से की जाती है: (चैनल आकार * चैनल में संदेश का आकार)। इन सरणियों के पते (अर्थात, उनके नाम) को संबंधित NUSE_Pipe_Data [] तत्वों को सौंपा जाना चाहिए। प्रत्येक चैनल के लिए, उसके संदेश का आकार और आकार क्रमशः NUSE_Pipe_Size [] और NUSE_Pipe_Message_Size [] तत्वों को सौंपा जाना चाहिए।

सेमफोर डेटा
यदि कम से कम एक सेमाफ़ोर कॉन्फ़िगर किया गया है, तो NUSE_Semaphore_Initial_Value [] सरणी को काउंटडाउन के प्रारंभिक मूल्यों के साथ आरंभीकृत किया जाना चाहिए।

अनुप्रयोग टाइमर डेटा
यदि कम से कम एक टाइमर कॉन्फ़िगर किया गया है, तो NUSE_Timer_Initial_Time [] सरणी को काउंटरों के प्रारंभिक मूल्यों के साथ आरंभीकृत किया जाना चाहिए। इसके अलावा, NUSE_Timer_Reschedule_Time [] को पुनरारंभ मान निर्दिष्ट करना चाहिए। ये टाइमर मान पहले टाइमर चक्र समाप्त होने के बाद उपयोग किए जाएंगे। यदि पुनरारंभ मान 0 पर सेट हैं, तो काउंटर एक चक्र के बाद बंद हो जाएगा।

यदि खाता पूर्णता तंत्र के लिए समर्थन कॉन्फ़िगर किया गया है ( NUSE_TIMER_EXPIRATION_ROUTINE_SUPPORT पैरामीटर को TRUE पर सेट करके), तो दो और सरणियाँ बनानी होंगी । पूरा करने के तंत्र के पते (बस फंक्शन नामों की सूची, बिना कोष्ठक के) को NUSE_Timer_Expiration_Routine_Address [] में रखा जाना चाहिए। सरणी NUSE_Timer_Expiration_Routine_Parameter [] पूर्ण मापदंडों के मूल्यों के साथ आरंभ किया जाना चाहिए।

कौन सी एपीआई?

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

यह स्पष्ट लग सकता है कि न्यूक्लियस एसई का उपयोग करते हुए आवेदन लिखते समय, आपको पिछले लेखों में वर्णित एपीआई का उपयोग करने की आवश्यकता है। हालांकि, यह हमेशा मामला नहीं होता है।

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

कुछ उपयोगकर्ताओं के लिए, एक वैकल्पिक एपीआई एक अधिक आकर्षक विकल्प हो सकता है। तीन स्पष्ट स्थितियां हैं जहां यह संभव है।

1. न्यूक्लियस एसई एक प्रणाली का एक हिस्सा है जो अन्य घटकों के लिए अन्य ऑपरेटिंग सिस्टम का उपयोग करता है। इसलिए, कोड की पोर्टेबिलिटी और, अधिक महत्वपूर्ण बात, विभिन्न ऑपरेटिंग सिस्टम का उपयोग करने का अनुभव बहुत ही आकर्षक लगता है।
2. उपयोगकर्ता के पास एक अन्य ऑपरेटिंग सिस्टम के एपीआई का उपयोग करने का व्यापक अनुभव है। इस अनुभव का उपयोग करना भी बहुत उचित है।
3. उपयोगकर्ता किसी अन्य ऑपरेटिंग सिस्टम के एपीआई के लिए लिखे गए कोड का पुन: उपयोग करना चाहता है। एपीआई कॉल को बदलना संभव है, लेकिन समय लगता है।

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

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

नाभिक एसई अनुप्रयोग डिबगिंग

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

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

डिबगर का उपयोग करना

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

यह ध्यान देने योग्य है कि आमतौर पर एक डिबगर केवल एक कार्यक्रम नहीं, बल्कि उपकरणों का एक परिवार है। डीबगर ऑपरेशन के विभिन्न मोड हो सकते हैं, जिसके माध्यम से वर्चुअल सिस्टम या वास्तविक हार्डवेयर पर कोड विकसित करते समय यह मदद करता है।

कार्य-संवेदनशील विराम बिंदु

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

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

कर्नेल ऑब्जेक्ट जानकारी

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

इसका उपयोग आपके एप्लिकेशन में अतिरिक्त डिबगिंग कोड जोड़कर किया जा सकता है, जो "सूचनात्मक" एपीआई कॉल (जैसे NUSE_Queue_Information ) का उपयोग करेगा। बेशक, इसका मतलब यह होगा कि आपके आवेदन में अब अतिरिक्त कोड है, जो आवेदन के कार्यान्वयन के बाद आवश्यक नहीं होगा। का उपयोग करते हुए #define सक्षम या इस कोड को निष्क्रिय करने के लिए सशर्त संकलन का उपयोग कर एक तार्किक समाधान हो जाएगा।

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

एक वैकल्पिक, अधिक लचीला, लेकिन कम "नॉन-एजिंग" दृष्टिकोण कर्नेल ऑब्जेक्ट्स के डेटा संरचनाओं तक सीधी पहुंच है। सबसे अधिक संभावना है, डिबगर स्क्रिप्ट का उपयोग करके ऐसा करना सबसे अच्छा है। हमारे उदाहरण में, कतार आकार NUSE_Queue_Size [] से प्राप्त किया जा सकता है , और NUSE_Queue_Data [] से इसका वर्तमान उपयोग किया जा सकता है । इसके अलावा, कतार में संदेश कतार डेटा क्षेत्र ( NUSE_Queue_Data [] ) के पते का उपयोग करके प्रदर्शित किया जा सकता है ।

एपीआई कॉल रिटर्न मान

कई API फ़ंक्शन एक स्थिति मान लौटाते हैं जो यह दर्शाता है कि कॉल सफलतापूर्वक कैसे पूरा हुआ। इन मूल्यों पर नज़र रखना और ऐसे मामलों को चिह्नित करना उपयोगी होगा, जिनमें वे NUSE_SUCCESS के बराबर नहीं हैं (यानी, उनका मूल्य शून्य है)। चूंकि यह ट्रैकिंग केवल डिबगिंग के लिए है, इसलिए सशर्त संकलन काफी उपयुक्त है। एक वैश्विक चर की परिभाषा (कहते हैं, NUSE_API_Call_Status ) सशर्त रूप से संकलित की जा सकती है (#define निर्देश प्रतीक के नियंत्रण में)। फिर, API कॉल की परिभाषा का हिस्सा, अर्थात् NUSE_API_Call_Status = , सशर्त रूप से संकलित किया जा सकता है। उदाहरण के लिए, डिबगिंग उद्देश्यों के लिए, एक कॉल जो आमतौर पर इस तरह दिखता है:

NUSE_Mailbox_Send (mbox, msg, NUSE_SUSPSEND);

निम्नलिखित फॉर्म लेंगे:

NUSE_API_Call_Status = NUSE_Mailbox_Send (mbox, msg, NUSE_SUSPEND);

यदि कार्य लॉकिंग सक्रिय है, तो कई एपीआई फ़ंक्शन कॉल केवल एक सफल कॉल पूरा होने के बारे में जानकारी वापस कर सकते हैं या ऑब्जेक्ट रीसेट हो गया है। हालाँकि, यदि API पैरामीटर जाँच सक्रिय है, तो API कॉल कई अन्य मानों को वापस करने में सक्षम होगा।

कार्य स्टैक और स्टैक ओवरफ़्लो का आकार सेट करना

स्टैक ओवरफ्लो सुरक्षा के विषय पर पिछले लेख (# 31) में चर्चा की गई थी। डिबगिंग के दौरान कई अन्य संभावनाएं हैं।

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

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

न्यूक्लियस एसई कॉन्फ़िगरेशन चेकलिस्ट

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

1. Nucleus SE. , Nucleus SE , Nucleus SE .
2. CPU/. .
3. . , , .
4. . . . , . 16 .
5. . - main() ?
6. . 4 , .
7. , .
8. .
9. . , .
10. . , .
11. . , . . — 16 .
12. . , .
13. . , (, ).
14. API. API, .

अगला लेख (इस श्रृंखला में अंतिम) न्यूक्लियस एसई के साथ पूरी कहानी को संक्षेप में प्रस्तुत करेगा, और यह जानकारी भी प्रदान करेगा जो न्यूक्लियस एसई कार्यान्वयन और उनके उपयोग को बनाने में मदद करेगा।

लेखक के बारे में: कॉलिन वाल्स तीस वर्षों से इलेक्ट्रॉनिक्स उद्योग में काम कर रहे हैं, अपने अधिकांश समय को फर्मवेयर के लिए समर्पित करते हैं। वह अब मेंटर एंबेडेड (मेंटर ग्राफिक्स का एक प्रभाग) में एक फर्मवेयर इंजीनियर है। कॉलिन वॉल्स अक्सर सम्मेलनों और सेमिनारों में बोलते हैं, कई तकनीकी लेखों के लेखक और फर्मवेयर पर दो किताबें। ब्रिटेन में रहता है। कॉलिन का पेशेवर ब्लॉग , ई-मेल: colin_walls@mentor.com।