मुझे एक इंटरप्ट हैंडलिंग मॉड्यूल मिला है जो एक एम्बेडेड प्रोसेसर पर इंटरप्ट नियंत्रक हार्डवेयर को नियंत्रित करता है। अब मैं इसमें और परीक्षण जोड़ना चाहता हूं। वर्तमान में, परीक्षण केवल तभी परीक्षण करते हैं जब इंटरप्ट्स का घोंसला एक आईएसआर के भीतर से दो सॉफ्टवेयर इंटरप्ट्स बनाकर काम करता है, एक कम प्राथमिकता वाला और एक उच्च प्राथमिकता वाला। मैं इस मॉड्यूल का परीक्षण कैसे कर सकता हूं?आप अपने इंटरप्ट हैंडलिंग मॉड्यूल का परीक्षण कैसे करते हैं?
मेरा सुझाव है कि आप अन्य उत्तेजना भी बनाने का प्रयास करें।
अक्सर, हार्डवेयर इंटरप्ट को सॉफ़्टवेयर (स्वचालित परीक्षण) या ध्वज सेट करके डीबगर द्वारा ट्रिगर किया जा सकता है। या I/O के माध्यम से एक बाधा के रूप में। या एक टाइमर बाधा। या आप केवल एक चरणबद्ध होने पर डीबगर के माध्यम से एक इंटरप्ट नियंत्रक में इंटरप्ट बिट सेट कर सकते हैं।
आप उन चीजों पर कुछ रनटाइम चेक जोड़ सकते हैं जो होने वाले नहीं हैं। कभी कभी मैं उत्पादन पिन सेट करने के लिए बाहर से नजर रखने के लिए चुनाव (अच्छा आप एक आस्टसीलस्कप या तर्क विश्लेषक ... अगर)
low_prio_isr(void)
{
LOW_PRIO_ISR=1;
if (1 == HIGH_PRIO_ISR)
{ this may never happen. dummy statement to allow breakpoint in debugger }
}
high_prio_isr(void)
{
HIGH_PRIO_ISR=1
}
सॉफ्टवेयर व्यवधान का नुकसान यह है कि इस समय ठीक हो गई है है; हमेशा एक ही निर्देश। मेरा मानना है कि आप सबूत देखना चाहते हैं कि यह हमेशा काम करता है; डेडलॉक मुफ्त।
इंटरप्ट सेवा दिनचर्या के लिए मुझे कोड समीक्षा बहुत मूल्यवान मिलती है। अंत में आप केवल उन परिस्थितियों का परीक्षण कर सकते हैं जिन्हें आपने कल्पना की है और किसी बिंदु पर परीक्षण का प्रयास बहुत अधिक होगा। आईएसआर को डीबग करना बेहद मुश्किल है।
मुझे लगता है कि निम्नलिखित के लिए परीक्षण प्रदान करने के लिए उपयोगी है: - ISR के लिए कम प्राथमिकता बीच में बाधित नहीं है - ISR ही प्राथमिकता बीच में के लिए बाधित नहीं है - ISR उच्च प्राथमिकता के लिए बाधित है बीच में - अधिकतम नेस्टिंग गिनती ढेर सीमाओं के भीतर।
अपने परीक्षण के कुछ उपकरण के रूप में कोड में रह सकते हैं (ताकि आप उदाहरण के अधिकतम नेस्टिंग स्तर के लिए निगरानी कर सकते हैं
ओह, और एक और बात:। मैं आम तौर पर ISRs इतना कम था कि मैं यह कर सकते हैं रखने के लिए प्रबंधित किया है घोंसला बनाने से बचना .... अगर आप इस आप अतिरिक्त सादगी और अधिक प्रदर्शन मिलेगा कर सकते हैं।
[संपादित करें] बेशक , ISRs प्रणाली में भी हार्डवेयर पर परीक्षण किया जाना चाहिए। इसके अलावा बिट द्वारा -बीबी, चरण-दर-चरण दृष्टिकोण आप साबित करना चाहते हैं: - अधिकतम इंटरप्ट लोड पर सिस्टम की स्थिरता (अधिमानतः कई बार वें ई अधिकतम भार की भविष्यवाणी की; यदि आपका 115 केबीपीएस सीरियल ड्राइवर 2 एमबीपीएस को भी संभाल सकता है तो आप ठीक होंगे!) - आईएसआर को सक्षम/अक्षम करने का सही पल, खासकर अगर सिस्टम नींद मोड - # इंटरप्ट्स में प्रवेश करता है। यदि आप मैकेनिकल स्विच, मैकेनिकल रोटरी (स्थिर स्थिति तक पहुंचने से पहले सैकड़ों ब्रेक/संपर्क पलों) जोड़ते हैं तो आश्चर्यचकित हो सकते हैं
मैं एक एम्बेडेड डेवलपर नहीं हूं, इसलिए मुझे नहीं पता कि यह संभव है, लेकिन कॉलबैक-पंजीकरण तंत्र से इंटरप्ट को संभालने वाले कोड को डीकॉप्लिंग करने के बारे में कैसे? यह आपको सिम्युलेटर कोड को बाधित करने की इजाजत देता है जैसे आप इसे पसंद करते हैं ...
संभावना है कि कोई कॉलबैक-पंजीकरण तंत्र नहीं है। एक बाधा उत्पन्न होती है, और उपयुक्त इंटरप्ट सेवा दिनचर्या (संकलन समय पर तय) को बुलाया जाता है। –
मैं वास्तविक हार्डवेयर परीक्षण की अनुशंसा करता हूं। हस्तक्षेप हैंडलिंग स्वाभाविक रूप से यादृच्छिक और अप्रत्याशित है।
सिग्नल जेनरेटर का उपयोग करें और उचित इंटरप्ट पिन में स्क्वायर वेव फ़ीड करें। एकाधिक आईआरक्यू लाइनों का परीक्षण करने और प्राथमिकता प्रबंधन को सत्यापित करने के लिए एकाधिक जेनरेटर (या एकाधिक आउटपुट वाले एक) का उपयोग करें।
सिग्नल जनरेटर पर & आवृत्ति डायल करने के साथ प्रयोग (उनके बीच की दरों में भिन्नता), और देखें कि क्या होता है। विभिन्न राज्यों में इंटरप्ट नियंत्रक की स्थिति को सत्यापित करने के लिए बहुत सारे डायग्नोस्टिक कोड हैं।
वैकल्पिक: यदि आपके प्लेटफ़ॉर्म में टाइमर हैं जो इंटरप्ट को ट्रिगर कर सकते हैं, तो आप बाहरी हार्डवेयर की बजाय उनका उपयोग कर सकते हैं।
बिल्कुल सही है कि आईएसआर को हार्डवेयर में परीक्षण करने की आवश्यकता है, हालांकि मेरा अनुभव यह है कि एक प्रसिद्ध माहौल में इसकी शुद्धता साबित करने के लिए बहुत कुछ किया जा सकता है। मैंने देखा है कि आईएसआर अजीब लक्षणों के साथ एक परियोजना के माध्यम से आधे रास्ते में विफल रहा है, जिसके कारण शुरुआती हार्डवेयर परीक्षण के दौरान दिखाई नहीं दे रहा था, लेकिन कोड समीक्षा और इकाई परीक्षण द्वारा इसका खुलासा किया गया था। – Adriaan
इस तरह की सामग्री के लिए मैं अत्यधिक SPIN model checker की तरह कुछ अनुशंसा करता हूं। आप एल्गोरिदम का परीक्षण करते हैं, कोड नहीं, लेकिन परीक्षण संपूर्ण है। इस तकनीक का उपयोग कर दिन में वापस I found a bug in gdb।
+1 अच्छा सारांश, विशेष रूप से लघु आईएसआर के बारे में टिप्पणी और घोंसले से परहेज। – DrAl
+1 अल के रूप में +1, साथ ही मैं सहमत हूं कि कोड समीक्षाओं के लिए आईएसआर विशेष रूप से अच्छे विषय हैं। –