RTOS के बारे में पूरी सच्चाई। अनुच्छेद # 31 निदान और त्रुटि RTOS की जाँच

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

न्यूक्लियस एसई में, सामान्य रूप से, त्रुटि जाँच के तीन प्रकार होते हैं:

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

उपयोगकर्ता द्वारा निदान के संबंध में कुछ विचारों के साथ, इस लेख में सभी पर चर्चा की जाएगी।

सेटिंग्स सत्यापित करें

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

कॉन्फ़िगरेशन त्रुटियों की पहचान करने में मदद करने के लिए, #include के माध्यम से फ़ाइल nuse_config.c में फ़ाइल nuse_config_check.h शामिल है , जो #define निर्देशों पर अखंडता जांच करता है। निम्नलिखित इस फ़ाइल का एक स्निपेट है:

/*** Tasks and task control ***/ #if NUSE_TASK_NUMBER < 1 || NUSE_TASK_NUMBER > 16 #error NUSE: invalid number of tasks - must be 1-16 #endif #if NUSE_TASK_RELINQUISH && (NUSE_SCHEDULER_TYPE == NUSE_PRIORITY_SCHEDULER) #error NUSE: NUSE_Task_Relinquish() selected - not valid with priority scheduler #endif #if NUSE_TASK_RESUME && !NUSE_SUSPEND_ENABLE #error NUSE: NUSE_Task_Resume() selected - task suspend not enabled #endif #if NUSE_TASK_SUSPEND && !NUSE_SUSPEND_ENABLE #error NUSE: NUSE_Task_Suspend() selected - task suspend not enabled #endif #if NUSE_INITIAL_TASK_STATE_SUPPORT && !NUSE_SUSPEND_ENABLE #error NUSE: Initial task state enabled - task suspend not enabled #endif /*** Partition pools ***/ #if NUSE_PARTITION_POOL_NUMBER > 16 #error NUSE: invalid number of partition pools - must be 0-16 #endif #if NUSE_PARTITION_POOL_NUMBER == 0 #if NUSE_PARTITION_ALLOCATE #error NUSE: NUSE_Partition_Allocate() enabled – no partition pools configured #endif #if NUSE_PARTITION_DEALLOCATE #error NUSE: NUSE_Partition_Deallocate() enabled – no partition pools configured #endif #if NUSE_PARTITION_POOL_INFORMATION #error NUSE: NUSE_Partition_Pool_Information() enabled – no partition pools configured #endif #endif 

उपरोक्त कोड निम्नलिखित जांच करता है:

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

सभी मामलों में, त्रुटियों का पता लगाने के संकलन में #error निर्देश के निष्पादन की ओर जाता है। यह आमतौर पर संगत संदेश को रोकने और प्रदर्शित करने के लिए संकलन का कारण बनता है।

यह फ़ाइल गलत कॉन्फ़िगरेशन / कॉन्फ़िगरेशन बनाने की असंभवता की गारंटी नहीं देती है, लेकिन यह बहुत संभावना नहीं है।

एपीआई सेटिंग्स की जाँच करना

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

पैरामीटर जाँच NUE_API_PARAMETER_CHECKING पैरामीटर को nuse_config.h फ़ाइल में TRUE पर सेट करके सक्रिय किया गया है। इससे आवश्यक अतिरिक्त कोड का संकलन होता है। निम्नलिखित एक एपीआई फ़ंक्शन के मापदंडों की जांच करने का एक उदाहरण है:

 STATUS NUSE_Mailbox_Send(NUSE_MAILBOX mailbox, ADDR *message, U8 suspend) { STATUS return_value; #if NUSE_API_PARAMETER_CHECKING if (mailbox >= NUSE_MAILBOX_NUMBER) { return NUSE_INVALID_MAILBOX; } if (message == NULL) { return NUSE_INVALID_POINTER; } #if NUSE_BLOCKING_ENABLE if ((suspend != NUSE_NO_SUSPEND) && (suspend != NUSE_SUSPEND)) { return NUSE_INVALID_SUSPEND; } #else if (suspend != NUSE_NO_SUSPEND) { return NUSE_INVALID_SUSPEND; } #endif #endif 

मापदंडों की इस तरह की जांच इस तथ्य को जन्म दे सकती है कि एपीआई कॉल एक त्रुटि कोड का उत्पादन करेगा। यह NUSE_INVALID_xxx (उदाहरण के लिए, NUSE_INVALID_POINTER ) फ़ॉर्म का एक नकारात्मक मान है - परिभाषाओं का एक पूरा सेट nuse_codes.h फ़ाइल में समाहित है ।

त्रुटि मानों को संसाधित करने के लिए, एक अतिरिक्त एप्लिकेशन कोड (संभवतः सशर्त संकलन का उपयोग करके बनाया गया) जोड़ा जा सकता है, हालांकि, उनका पता लगाने के लिए, आधुनिक फर्मवेयर डीबगर्स के डेटा के निगरानी उपकरणों का उपयोग करना बेहतर है।

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

कार्य ढेर की जाँच करना

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

संस्करण की जानकारी

न्यूक्लियस आरटीओएस और न्यूक्लियस एसई का एक एपीआई फ़ंक्शन है जो केवल कर्नेल संस्करण / निर्माण जानकारी देता है।

न्यूक्लियस आरटीओएस एपीआई कॉल

सेवा कॉल प्रोटोटाइप:
CHAR * NU_Release_Information (VOID);

पैरामीटर: कोई नहीं।

वापसी मूल्य:
एक स्ट्रिंग के लिए सूचक एक शून्य बाइट के साथ समाप्त होने वाली संस्करण की जानकारी।

न्यूक्लियस एसई एपीआई कॉल

यह एपीआई कॉल न्यूक्लियस आरटीओएस एपीआई की मुख्य कार्यक्षमता का समर्थन करता है।

सेवा कॉल प्रोटोटाइप:
char * NUSE_Release_Information (शून्य);

पैरामीटर: कोई नहीं।

वापसी मूल्य:
एक स्ट्रिंग के लिए सूचक एक शून्य बाइट के साथ समाप्त होने वाली संस्करण की जानकारी।

न्यूक्लियस एसई विधानसभा जानकारी प्राप्त करने के लिए एक कॉल करना

इस एपीआई कॉल को लागू करना बहुत सरल है। एक पॉइंटर को निरंतर लाइन NUSE_Release_Info पर लौटाया जाता है , जिसे nuse_globals.c फ़ाइल में घोषित और आरंभ किया जाता है ।

इस रेखा के पास Nucleus SE - Xyymmmdd , जहां रूप है:
एक्स - बिल्ड स्थिति: ए = अल्फा; बी = बीटा; आर = जारी
yy - रिलीज़ का वर्ष
मिमी - रिलीज़ महीने
dd - रिलीज़ का दिन

नाभिक RTOS संगत

न्यूक्लियस आरटीओएस में वैकल्पिक इतिहास पत्रिका समर्थन होता है। कर्नेल विभिन्न सिस्टम क्रियाओं का विवरण रिकॉर्ड करता है। एपीआई कार्य हैं जो कार्यक्रमों की अनुमति देते हैं:

• लॉगिंग को सक्रिय / निष्क्रिय करना;
• एक जर्नल प्रविष्टि बनाएँ;
• एक जर्नल प्रविष्टि प्राप्त करें।

यह सुविधा न्यूक्लियस एसई में समर्थित नहीं है।

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

उपयोगकर्ता निदान

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

अनुप्रयोग-विशिष्ट निदान

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

मेमोरी की जाँच

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

रैम में होने वाली दो सबसे आम त्रुटियां हैं:

• "स्टिकी बिट्स" जब बिट में 0 या 1 का मान होता है, जिसे बदला नहीं जा सकता है;
• "क्रॉसस्टॉक" जब आसन्न बिट्स एक दूसरे के साथ हस्तक्षेप का कारण बनते हैं।

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

विभिन्न प्रकार के रॉम भी आवधिक त्रुटियों के कारण होते हैं, लेकिन उन्हें जांचने के लिए कई उपकरण नहीं हैं। कोड इकट्ठे होने के बाद गणना की गई चेकसम यहाँ उपयोगी हो सकती है। यह जाँच बूट समय पर की जा सकती है, और संभवतः रनटाइम पर भी।

मेमोरी एड्रेसिंग लॉजिक में एक त्रुटि ROM और RAM दोनों को प्रभावित कर सकती है। आप इस त्रुटि के लिए एक विशेष जांच विकसित कर सकते हैं, लेकिन यह सबसे ऊपर वर्णित चेक के भाग के रूप में पाया जाएगा।

परिधीय परीक्षण

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

प्रहरी सेवा

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

एक मल्टीटास्किंग वातावरण में एक प्रहरी का प्रभावी उपयोग एक जटिल समस्या है। यदि आप एक कार्य करते हैं जो समय-समय पर इसे (वॉचडॉग टाइमर) तक पहुँचाता है, तो यह पुष्टि करेगा कि यह विशेष कार्य काम कर रहा है। एक संभावित समाधान "डिस्पैचर कार्य" का कार्यान्वयन हो सकता है। ऐसे कार्य का एक उदाहरण नीचे दिया जाएगा।

ढेर अतिप्रवाह जांच

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

सामान्यतया, सत्यापन के ढेर के लिए दो दृष्टिकोण हैं। यदि आप एक परिष्कृत एम्बेडेड सॉफ़्टवेयर डीबगर का उपयोग करते हैं, तो स्टैक की सीमाओं की निगरानी की जा सकती है और सभी उल्लंघनों का पता लगाया जाएगा। नाभिक एसई स्टैक का स्थान और आकार वैश्विक ROM डेटा संरचनाओं में उपलब्ध हैं: NUSE_Task_Stack_Base [] और NUSE_Task_Stack_Size [] ।

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

पर्यवेक्षक कार्य

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

निम्नलिखित एक उदाहरण है कि एक समान कार्य कैसे कार्य कर सकता है।

डिस्पैचर कार्य के सिग्नल फ्लैग का उपयोग छह महत्वपूर्ण सिस्टम कार्यों के संचालन को ट्रैक करने के लिए किया जाता है। इनमें से प्रत्येक कार्य एक विशिष्ट ध्वज (बिट 0 से बिट 5 तक) का उपयोग करता है और इसे नियमित रूप से सेट करना चाहिए। डिस्पैचर कार्य सभी झंडे को रीसेट करता है, और फिर एक निश्चित अवधि के लिए अपना काम रोक देता है। जब वह काम फिर से शुरू करती है, तो उसे उम्मीद होती है कि उपयुक्त ध्वज को सेट करके सभी छह कार्यों को "चेक" किया जाता है, फिर वह b00111111 (फ़ाइल nuse_binary.h से ) के मूल्य के साथ सटीक मिलान की तलाश करती है । यदि सब कुछ आवश्यकताओं को पूरा करता है, तो यह झंडे को रीसेट करता है और फिर से रुकता है। यदि नहीं, तो यह क्रिटिकल एरर हैंडलिंग रूटीन को कॉल करता है, जो उदाहरण के लिए, सिस्टम को रिबूट कर सकता है।

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

अनुरेखण और प्रोफाइलिंग

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

1. कार्रवाई करने के लिए RTOS में एक अतिरिक्त कोड जोड़ा जाता है। आमतौर पर, यह सशर्त संकलन का उपयोग करने के लिए प्रीप्रोसेसर निर्देशों में लपेटा जाएगा। जब कोई महत्वपूर्ण घटना होती है (उदाहरण के लिए, एपीआई फ़ंक्शन को कॉल करना या संदर्भ को स्विच करना) तो यह कोड कई बाइट्स को रिकॉर्ड करता है। इस तरह की जानकारी में शामिल हो सकते हैं:
   
   • वर्तमान पता (पीसी);
   • वर्तमान कार्य की आईडी (सूचकांक);
   • अन्य प्रयुक्त वस्तुओं के सूचकांक;
   • ऑपरेशन के अनुरूप कोड।
   
   
2. आमतौर पर मेजबान कंप्यूटर को बाहरी भंडारण के लिए प्रोफ़ाइल जानकारी बफर उतारने के लिए आवंटित कार्य।

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

अगले लेख में, हम न्यूक्लियस एसई और न्यूक्लियस आरटीओएस की संगतता की विस्तार से जांच करेंगे।

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