डिबगिंग बटन


32

मैंने हाल ही में बटन डिबगिंग के बारे में एक लेख पढ़ा और सोच रहा था कि क्या मुझे इस बात को ध्यान में रखना चाहिए, उदाहरण के लिए, एक Arduino (ATMega mC)? मुझे लगता है कि यह एक मुद्दा है, खासकर जब इंटरप्ट के साथ काम करना।

तो क्या कोड में उछाल का पता लगाना बेहतर है, या हार्डवेयर के साथ इस बात का ध्यान रखा जाना चाहिए? कृपया विस्तार से बताएं।


जवाबों:


17

मैं आपके स्विच तक एक गुंजाइश (आमतौर पर आपके पास एक या अपने हाथों को उपयोग करने के लिए प्राप्त कर सकता है) को हुक करने की अत्यधिक अनुशंसा करेगा। मैंने एक छात्र की परियोजना देखी है, जिसमें उनके स्विच पर उछाल था, जो 5v से 5v तक चला गया, -5v से 4v नीचे -3v तक फिर 2v तक और फिर वापस 0v तक। जब हमने मौजूदा ड्रॉ को एक दायरे में देखा तो कुछ बहुत बड़े स्पाइक थे।

अपने विशेष मामले में हार्डवेयर में अपने स्विच की आलोचना करना उसके लिए बहुत आवश्यक था।

हालाँकि, दूसरी ओर, मैंने ऐसे स्विच देखे हैं जिनका प्रभाव बहुत कम होता है जिन्हें आसानी से सॉफ्टवेयर में हटाया जा सकता है।

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


मैंने स्विच बाउंस की एक छवि बनाई और इसे विकिपीडिया: en.wikipedia.org/wiki/File:Switch_bounce.JPG
थॉमस ओ

@ थोमस ओ कि उछाल की एक बहुत ही मजेदार तस्वीर है। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि @Vincent Van Den Berghe समझता है कि सभी उछाल इस तरह नहीं दिखेंगे। यह उछाल 0-5v तक सीमित है, यह हमेशा ऐसा नहीं लगेगा।
कालेनजब

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

@Kellenjb, मुझे अपने दायरे के लिए जल्द ही एक प्रिंटर मिल रहा है जो HP-IB का समर्थन करता है। इसके अलावा मैंने अपने कैमरे पर "स्पोर्ट्स" मोड की खोज की है, बिना फ्लैश के और बिना किसी धुंधलापन के स्कोप स्क्रीन की अच्छी तस्वीरें ले सकता हूं।
थॉमस ओ

1
@ लुंडिन एक वास्तविक समय के माहौल में आप बहुत कुछ बाधित करते हैं। यदि आपके पास एक बटन दबाया गया है तो आप वास्तव में नहीं चाहते हैं कि आपका वास्तविक समय सिस्टम एक ही बटन प्रेस द्वारा कई बार बाधित हो। तुम भी 10 एमएस के लिए इंतजार करने के लिए संसाधनों को समर्पित करने की जरूरत नहीं है।
कालेनजब 18

15

यदि आप एक पेशेवर इलेक्ट्रॉनिक्स डिज़ाइनर हैं, तो आपका बॉस आपको हार्डवेयर में ऐसा नहीं करने देगा। कारण सरल है: यदि आपका उत्पादन बैच काफी बड़ा है, तो सॉफ्टवेयर लगभग मुफ्त है , जबकि आपके द्वारा उत्पादित प्रत्येक इकाई के लिए हार्डवेयर का भुगतान किया जाना है। और जब रेसिस्टर्स और कैपेसिटर सस्ते होते हैं, तो उन्हें पीसीबी पर रखने से उनकी खरीद कीमत 20 गुना तक बढ़ सकती है।

चाहे आप सॉफ़्टवेयर में या हार्डवेयर में बहस करते हैं, फिर भी आपको गुणवत्ता पुशबटन का चयन करना होगा। लेख से बदनाम 157ms बटन बस किसी भी आवेदन के लिए फिट नहीं है ।
मैं आमतौर पर 32ms के अंतराल पर बटन का नमूना लेता हूं , जो किसी भी अच्छे बटन के डिब्यू टाइम को पाटने के लिए पर्याप्त है। मैं आल्प्स SKQG TACT स्विचेस का काफी प्रशंसक हूं ।

आल्प्स चातुर्य स्विच

मैंने जिन कुछ उपकरणों का परीक्षण किया, उनमें 10ns से कम की शुरुआती उछाल का समय था। जबकि इसमें 100 000 चक्रों का परिचालन जीवन है, हमने इसे 200 000 चक्रों के लिए परीक्षण किया था और तब भी 32ms की बहस पर्याप्त थी। (मुझे लगता है कि मुझे बहस के वास्तविक स्तर को मापा जाना चाहिए था, लेकिन उस समय हमारी मुख्य रुचि अंतिम उत्पाद का व्यवहार था। किसी भी तरह, हम इसका इस्तेमाल कर रहे थे।)

यदि आप वास्तव में एक हार्डवेयर समाधान चाहते हैं, तो मैं तकनीकी रूप से सबसे अच्छा समाधान के रूप में आलेख में उल्लिखित SR फ्लिप-फ्लॉप समाधान का उपयोग करता हूं:

डेब्यू सर्किट

फ्लिप-फ्लॉप का निर्माण एक दोहरे NAND गेट के साथ किया जा सकता है , जो उदाहरण के लिए एक छोटे VSSOP8 पैकेज में उपलब्ध है। इस समाधान का मुख्य दोष यह है कि आपको SPDT पुशबटन की आवश्यकता होती है, जहां SPST अधिक सामान्यतः उपलब्ध होता है।


12

बटन डिबेट करने के विभिन्न तरीकों के बहुत सारे (और बहुत सारे) हैं। आप सॉफ्टवेयर या हार्डवेयर में करते हैं या नहीं, यह आपकी परियोजना की आवश्यकताओं और स्विच प्रकार पर निर्भर करता है।

यहां विभिन्न तरीकों के कुछ लिंक दिए गए हैं:

http://www.ganssle.com/debouncing.htm

http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/


जब मैंने प्रश्न देखा तो मैं गैंसल का लिंक लेने जा रहा था।
कोर्तुक

गन्सल लेख वह कारण था जो मैंने यह सवाल पूछा था, यह मेरे प्रश्न में जुड़ा हुआ है :) डिब्यूज़ कोड स्निपेट्स के लिंक के लिए धन्यवाद।
विन्सेन्ट वान डेन बर्घे

क्या आप नरम / हार्डवेयर का उपयोग करने के लिए उदाहरण के लिए कुछ मामलों का उपयोग करने के लिए सोचेंगे? (यह शायद व्यक्तिपरक है, लेकिन मैं वैसे भी कुछ उदाहरण चाहूंगा)
विंसेंट वान डेन बर्घे

1
@ विंसेंट, केलेंजेब ने अपने जवाब में कहा कि इसे कैसे तय किया जाए। मैंने आपके लिंक पर क्लिक नहीं किया क्योंकि इसमें एक अजीब नाम था, अब जब मैंने इसे क्लिक किया तो मुझे गैंस दिखाई दिया!
Kortuk

यदि वह सर्वसम्मति / सामान्य नियम है तो वास्तव में, अधिक उदाहरणों की आवश्यकता नहीं है।
विन्सेन्ट वान डेन बर्घे

6

यह लेख बहस करने पर "बाइबल" है। संपर्क उछाल किसी भी आवेदन के साथ एक समस्या हो सकती है।

यह आम तौर पर सॉफ़्टवेयर में स्विचेस को डिबेट करने के लिए सबसे अच्छा है क्योंकि विशेष स्विच के लिए देरी के लिए समायोजित करना आसान है, क्योंकि वे संपर्क बाउंस की मात्रा में भिन्न होते हैं। प्रमुख रिलीज़ को डिबेट करना अक्सर आवश्यक होता है, साथ ही साथ। स्विच निर्माता अक्सर अपने उत्पादों के लिए उछाल की मात्रा निर्दिष्ट करते हैं, यह आमतौर पर लगभग 10ms - 20ms है।


लोग इसे क्यों वोट कर रहे हैं?
टोबी जाफेई

प्रमुख रिलीज डिबगिंग के बारे में अच्छी बात!
विंसेंट वान डेन बर्घे

1
मैंने इसे कम नहीं किया, लेकिन सिर्फ सॉफ्टवेयर में करने के लिए कहना एक भयानक विचार है। चरित्र चित्रण करना एक अच्छा विचार है।
कोर्तुक

मैंने कहा "आम तौर पर", जो मामला है, और कारण दिया। यह BOM लागत को कम करता है और विश्वसनीयता बढ़ाता है।
लियोन हेलर

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

1

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

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


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

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

0

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

सॉफ्टवेयर में डेब्यू करने का सबसे सही तरीका है कि आप समय के सबसे लंबे उछाल वाले समय के अलावा कुछ क्षणों में बटनों की जांच करें। 50 एमएस 'सामान्य' स्विच के उछाल समय पर एक ऊपरी सीमा लगती है, इसलिए जब आप अपने सॉफ़्टवेयर को इस तरह व्यवस्थित कर सकते हैं जैसे आप स्पष्ट हैं:

forever loop
   wait (at least) 50 ms
   check buttons
   do procesing
end loop

और इसके लिए अपने MCU पर ऑन-चिप टाइमर का उपयोग करें।
लंडिन

यह निश्चित रूप से संभव है, लेकिन आप बहुत सारे कार्यक्रम बिना लिख ​​सकते हैं।
राउटर वैन ओइजन

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

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

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

0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.