आरटीओएस में वॉचडॉग टाइमर का उपयोग कैसे करें?

Question

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

कोई RTOS के साथ सरल अनुप्रयोगों में मैं हमेशा मुख्य पाश से प्रहरी स्पर्श होता है और यह हमेशा पर्याप्त था। हालांकि, यहां, ऐसी कई प्रक्रियाएं हैं जो संभावित रूप से लटका सकती हैं। यह सुनिश्चित करते हुए कि प्रत्येक प्रक्रिया अच्छे स्वास्थ्य में है, समय-समय पर वॉचडॉग टाइमर को छूने के लिए एक साफ विधि क्या है?

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

Answer 1

एक आम दृष्टिकोण प्रहरी एक विशेष कार्य के लिए लात (अक्सर या तो सबसे-प्राथमिक या सबसे कम प्राथमिकता, तालमेल/प्रत्येक दृष्टिकोण के लिए मंशा) को सौंपने के लिए, और उसके बाद अन्य सभी कार्य है "चेक इन" है इस काम के साथ।

इस तरह:

• यदि व्यवधान लटका दिया जाता है (100% सीपीयू), किकर काम नहीं चलेगा, आप रीसेट

• अगर किकर कार्य लटका दिया जाता है, तो आप

  रीसेट

• यदि किसी अन्य कार्य लटका दिया जाता है, किकर कार्य में, किकर कार्य WDG लात नहीं है कोई चेक देखता है, आप रीसेट

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

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

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

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

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

Answer 2

पारंपरिक विधि न्यूनतम संभव प्राथमिकता

PROCESS(watchdog, PRIORITY_LOWEST) { while(1){reset_timer(); sleep(1);} } 

और जहां वास्तविक हार्डवेयर टाइमर सीपीयू हर 3 या 5 सेकंड शायद रीसेट करता है के साथ एक निगरानी प्रक्रिया है।

व्यक्तिगत प्रक्रियाओं ट्रैकिंग उलटा तर्क द्वारा प्राप्त किया जा सकता है: प्रत्येक प्रक्रिया एक टाइमर जिसका कॉलबैक प्रहरी एक 'स्टॉप' संदेश भेजता है सेटअप होगा। फिर प्रत्येक प्रक्रिया को पिछले टाइमर ईवेंट को रद्द करने और 'क्यूई से संदेश/संदेश प्राप्त करने' में कहीं नया सेट अप करने की आवश्यकता होगी।

PROCESS(watchdog, PRIORITY_LOWEST) { 
    while(1) { 
     if (!messages_in_queue()) reset_timer(); 
     sleep(1); 
    } 
} 
void wdg_callback(int event) { 
    msg = new Message(); 
    send(&msg, watchdog); 
}; 
PROCESS(foo, PRIORITY_HIGH) { 
    timer event=new Timer(1000, wdg_callback); 
    while (1) { 
     if (receive(msg, TIMEOUT)) { 
      // handle msg  
     } else { // TIMEOUT expired 
      cancel_event(event); 
      event = new Timer(1000,wdg_callback); 
     } 
    } 
} 

Answer 3

एक समाधान पैटर्न:

• हर धागा कि स्पष्ट रूप से निगरानी धागा है, जो इस तरह के कॉलबैक की एक सूची रखता के साथ अपने कॉलबैक पंजीकृत करता है की जाँच की जानी चाहती है।
• जब प्रहरी यह पंजीकृत कार्यों
• प्रत्येक कॉलबैक खुद की सूची पुनरावृति सकता है निर्धारित है iteratively कहा जाता है जब तक यह एक स्वस्थ स्थिति देता है।
• सूची के अंत में हार्डवेयर वॉचडॉग लात मार दिया गया है।

इस तरह से कोई भी थ्रेड जो स्वस्थ स्थिति कभी नहीं लौटाता है, तब तक घड़ी के कार्य को रोक देगा जब तक हार्डवेयर वॉचडॉग टाइमआउट नहीं होता है।

एक प्रीपेप्टिव ओएस में, वॉचडॉग थ्रेड सबसे कम प्राथमिकता या निष्क्रिय धागा होगा। सहकारी शेड्यूलर में, इसे कॉल-बैक कॉल के बीच उपज चाहिए।

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

Answer 4

प्रत्येक कार्य में अपना स्वयं का अनुरूपित निगरानी होना चाहिए। और वास्तविक निगरानी केवल उच्च प्राथमिकता वाले वास्तविक समय के कार्य द्वारा फ़ीड की जाती है यदि सभी अनुरूपित निगरानीकर्ताओं के पास समय-समय पर नहीं है।

यानी:

void taskN_handler() 
{ 
    watchdog *wd = watchdog_create(100); /* Create an simulated watchdog with timeout of 100 ms */ 
    /* Do init */ 
    while (task1_should_run) 
    { 
     watchdog_feed(wd); /* feed it */ 
     /* do stuff */ 
    } 
    watchdog_destroy(wd); /* destroy when no longer necessary */ 
} 

void watchdog_task_handler() 
{ 
    int i; 
    bool feed_flag = true; 
    while(1) 
    { 
     /* Check if any simulated watchdog has timeout */ 
     for (i = 0; i < getNOfEnabledWatchdogs(); i++) 
     { 
      if (watchogHasTimeout(i)) { 
        feed_flag = false; 
        break; 
      } 
     } 

     if (feed_flag) 
      WatchdogFeedTheHardware(); 

     task_sleep(10); 
} 

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

Answer 5

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

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

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