कुछ माइक्रोकंट्रोलर्स के पास इतनी बड़ी सिंक्रोनाइज़ेशन में देरी क्यों होती है?


11

Atmel SAM-D21 श्रृंखला माइक्रोकंट्रोलर्स पर, कई परिधीय एक घड़ी का उपयोग करते हैं जो मुख्य सीपीयू घड़ी के लिए अतुल्यकालिक है, और इन बाह्य उपकरणों तक पहुंच को सिंक्रनाइज़ेशन तर्क के माध्यम से जाना चाहिए; बाह्य उपकरणों पर जिनकी घड़ी CPU समय के सापेक्ष धीमी होती है, इससे कुछ बहुत बड़ी देरी हो सकती है। उदाहरण के लिए, यदि RTC को 1024Hz क्लॉक का उपयोग करने के लिए कॉन्फ़िगर किया गया है (जैसा कि डिजाइन के इरादे से प्रतीत होता है) और CPU 48Mhz पर चल रहा है, तो "वर्तमान समय" रजिस्टर को पढ़ने से बस तर्क 200,000 से अधिक प्रतीक्षा अवस्थाओं को सम्मिलित करने का कारण होगा (एक न्यूनतम 1024Hz घड़ी के पाँच चक्र)। हालाँकि सीपीयू को रीड रिक्वेस्ट जारी करना, कुछ अन्य असंबंधित कोड को निष्पादित करना और 200,000+ चक्र बाद में वापस लाने के लिए संभव है, लेकिन वास्तव में किसी भी समय तेजी से पढ़ने के लिए कोई रास्ता नहीं दिखता है।

सिंक्रोनाइज़ेशन की मेरी समझ से, एक सिंगल-बिट सिंकिंग सर्किट डेस्टिनेशन क्लॉक के 2-3 चक्रों द्वारा सिग्नल में देरी करेगा; एक बहु-बिट मात्रा को सिंक्रनाइज़ करना थोड़ा कठिन है, लेकिन विभिन्न प्रकार के दृष्टिकोण हैं जो गंतव्य घड़ी के पांच चक्रों के भीतर विश्वसनीय व्यवहार की गारंटी दे सकते हैं यदि यह स्रोत घड़ी की तुलना में तेज है, और केवल कुछ चक्र अधिक है अगर यह नहीं है। Atmel SAM-D21 क्या कर रहा है कि सिंक्रनाइज़ेशन के लिए स्रोत घड़ी डोमेन में छह चक्रों की आवश्यकता होगी , और कौन से कारक एक डिजाइन का पक्ष लेंगे जिसके तुल्यकालन में देरी इतनी लंबी है कि "सिंक्रनाइज़ेशन किया" रुकावट, बनाम एक को सुनिश्चित करता है। तुल्यकालन में देरी इतनी कम है कि इस तरह के व्यवधान अनावश्यक प्रस्तुत करना?


2
इस सवाल के लिए धन्यवाद। इसने मेरे मुद्दे को आखिरकार मेरे हाथ में समझा। मैं यहाँ आया क्योंकि मैं यह नहीं समझ सका कि वॉचडॉग टाइमर (WDT) को साफ़ करने में SAMD20 / 21 पर लगभग 5 जबरदस्त मिलीसेकंड लगेंगे। अब मुझे पता है कि यह हार्डवेयर डिज़ाइन द्वारा किया गया है, न कि किसी त्रुटि के कारण। (WDT को 1024 हर्ट्ज पर देखा जाता है, जो एकमात्र समझदार विकल्प है।) अब मैं कम से कम इसके अनुसार काम कर सकता हूं।
टी-बुल

2
@ टी-बुल: उन हिस्सों पर प्रहरी के बारे में वास्तव में मजेदार बात यह है कि यह समय सॉफ्टवेयर के बीच अक्षम है जो रीसेट कमांड जारी करता है और समय सिंक्रनाइज़ेशन से गुजरता है। यदि डिवाइस उस अंतराल के दौरान सो जाता है, तो वॉचडॉग तब तक नहीं चलेगा जब तक कि कुछ और भाग नहीं उठता।
सुपरकैट

जवाबों:


2

यह मेरे लिए चीजों को करने का एक अलग तरीका है, मैं अपने आर्किटेक्चर के लिए उपयोग किया जाता हूं, जहां मेरे रजिस्टर मेरे सीपीयू घड़ी पर या उस घड़ी के कम से कम 1/2 हैं। तो आप अपने रजिस्टर लिखें और वे तुरंत तैयार हैं। शायद वे इसे बिजली की बचत के लिए कर रहे हैं? यदि वे परिधीय रजिस्टरों को अपने स्वयं के अलग-अलग धीमी गति से घड़ी डोमेन में डाल रहे हैं, तो शायद उन्हें मुख्य थरथरानवाला या सीपीयू घड़ी को जगाने और चलाने की ज़रूरत नहीं है, लेकिन परिधीय पर मूल्यों को अद्यतन रख सकते हैं।

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

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

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

मुझे लगता है कि यह एक निश्चित उत्तर नहीं है, लेकिन डेटाशीट के माध्यम से थोड़ा देखने के बाद मेरे विचार हैं।


2
"छह चक्र" परिधीय घड़ी के छह चक्र हैं; अगर एक सेट जैसे कि 1024Hz (जिसे Atmel की सिफारिश लगती है) में खिलाया जाने वाला वास्तविक समय घड़ी मॉड्यूल है और CPU घड़ी 48MHz पर है, परिधीय घड़ी के छह चक्र सीपीयू घड़ी के 281,250 चक्र होंगे जो एक भयानक लंबी है कताई करने का समय, विशेष रूप से यदि कोई व्यवधान हो, जिसमें सर्विसिंग की आवश्यकता हो। स्पिनिंग केवल मध्यम रूप से भयानक होती है अगर धीमी घड़ी 8Mhz (एक 36-सीपीयू-चक्र स्पिन) का अर्थ है, लेकिन एक कठिन गलती 1024Hz घड़ी पर स्पिन से बेहतर होगी।
सुपरकाट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.