🌋 🔌 😭 Arduino में गति और इसे मापने के सवाल पर 👐🏼 👨🏻‍🔧 💚

विभिन्न आदेशों को निष्पादित करते समय (एक अलग पोस्ट में उस पर अधिक) अरुडिनो के प्रदर्शन के अध्ययन में यह समस्या उत्पन्न हुई। अध्ययन के दौरान, अलग-अलग आदेशों के काम के समय की स्थिरता के बारे में संदेह पैदा हुआ जब ऑपरेंड्स का मूल्य बदल गया (जैसा कि बाद में पता चला, अनुचित नहीं) और एक अलग कमांड के निष्पादन समय का अनुमान लगाने की कोशिश करने का निर्णय लिया गया। इसके लिए, एक छोटा कार्यक्रम लिखा गया था (किसने कहा कि स्केच को कक्षा को छोड़ना है), जिसने पहली नज़र में, परिकल्पना की पुष्टि की। निष्कर्ष में, आप 16 और 20 के मान देख सकते हैं, लेकिन कभी-कभी 28 और यहां तक कि 32 माइक्रोसेकंड पाए जाते हैं। यदि हम प्राप्त आंकड़ों को 16 (एमके घड़ी आवृत्ति) से गुणा करते हैं, तो हमें एमके चक्र (256 से 512 तक) में निष्पादन का समय मिलता है। दुर्भाग्य से, मुख्य कार्यक्रम चक्र (एक ही प्रारंभिक डेटा के साथ) का एक दोहराया रन, समग्र तस्वीर को बनाए रखते हुए, पहले से ही निष्पादन समय का एक अलग वितरण देता है, इसलिए वास्तविक समय भिन्नताएं प्रारंभिक डेटा से संबंधित नहीं हैं। मूल परिकल्पना अस्वीकृत है, लेकिन यह दिलचस्प हो जाता है, और वास्तव में इस तरह के एक महत्वपूर्ण बिखराव के साथ जुड़ा हुआ है।

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

इसलिए, समय बदल रहा है, और बहुत महत्वपूर्ण रूप से, हम इस घटना के कारणों की तलाश कर रहे हैं। सबसे पहले, हम प्राप्त मूल्यों की बहुलता पर ध्यान देते हैं, समय के साथ काम के पुस्तकालय के विवरण को देखते हैं और देखते हैं कि 4 andsec माप की मात्रा है, इसलिए क्वांटा में जाना बेहतर है और यह समझना कि हम 4 या 5 (बहुत बार) और 6 या 7 या 7 हैं। 8 (बहुत दुर्लभ) इकाइयाँ। पहले छमाही के साथ, सब कुछ आसान है - यदि मापा मूल्य 4 और 5 इकाइयों के बीच है, तो बिखराव अपरिहार्य हो जाता है। इसके अलावा, नमूनों को स्वतंत्र मानते हुए, हम सांख्यिकीय तरीकों से माप सटीकता बढ़ा सकते हैं, जो कि हम करते हैं, स्वीकार्य परिणाम प्राप्त करते हैं।

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

हम 1 परिकल्पना को आगे रखना शुरू करते हैं - सबसे सुविधाजनक (सुविधा और बहुमुखी प्रतिभा में यह केवल निर्माता के सीधे हस्तक्षेप के लिए दूसरा है) - सॉफ्टवेयर ग्लिच, निश्चित रूप से मेरा नहीं, मेरे कार्यक्रम कभी भी विफल नहीं होते हैं, लेकिन कनेक्टेड लाइब्रेरी (कंपाइलर, ऑपरेटिंग सिस्टम, ब्राउज़र, आदि) । - आवश्यक स्थानापन्न)। इसके अलावा, चूंकि मैं www.tinkercad.com पर एमुलेटर में प्रोग्राम चलाता हूं, आप अभी भी एमुलेटर बग्स को संदर्भित कर सकते हैं और विषय को बंद कर सकते हैं, क्योंकि स्रोत कोड हमारे लिए उपलब्ध नहीं है। इस परिकल्पना के विपक्ष:

चक्र से चक्र तक, विचलन का स्थान बदलता है, जो संकेत देता है।
यह साइट अभी भी AutoDesk का समर्थन करती है, हालांकि तर्क बल्कि कमजोर है।
"हमने यह स्वीकार किया कि जो हो रहा है वह मतिभ्रम नहीं है, अन्यथा यह केवल निर्बाध होगा।"

अगली धारणा माप परिणाम पर कुछ पृष्ठभूमि प्रक्रियाओं का प्रभाव है। हम कुछ भी नहीं कर रहे हैं, लेकिन विश्वास करते हैं, हालांकि ... हम सीरियल में परिणामों का उत्पादन कर रहे हैं। परिकल्पना 2 उत्पन्न होती है - आउटपुट समय कभी-कभी (जैसा होता है ... लेकिन ऐसा होता है) कमांड के निष्पादन समय में जोड़ा जाता है। हालांकि यह संदिग्ध है कि आउटपुट कितना है, लेकिन वैसे भी - फ्लश को जोड़ने से मदद नहीं मिली, आउटपुट को पूरा करने में देरी को जोड़ा और मदद नहीं की, आमतौर पर आउटपुट को लूप से बाहर ले जाना - वैसे भी, समय कूदता है - यह निश्चित रूप से सीरियल नहीं है।

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

परिकल्पना 3 - कभी-कभी समय गणना की दूसरी कॉल पहले की तुलना में अधिक समय लेती है, या समय गणना के साथ जुड़ी क्रियाएं कभी-कभी परिणाम को प्रभावित करती हैं। हम समय के साथ काम करने के कार्य के स्रोत कोड को देखते हैं (arduino-1.8.4 \ हार्डवेयर \ arduino \ avr \ cores \ arduino \ तारों) - मैंने बार-बार ऐसी बातों पर अपना रुख व्यक्त किया है, मैंने अपने आप को दोहराया नहीं है और हम देखते हैं कि 256 में से 1 समय काउंटर के छोटे हिस्से की हार्डवेयर वृद्धि के चक्र काउंटर के पुराने हिस्से को बढ़ाने के लिए बाधित है।

हमारे चक्र का निष्पादन समय 4 से 5 तक है, इसलिए हम 170 मापों के एक खंड में 170 * (4..5) / 256 = से तीन से चार विषम मूल्यों की उम्मीद कर सकते हैं। हम देखते हैं - यह बहुत समान दिखता है, वास्तव में उनमें से 4 हैं। पहले और दूसरे कारणों को अलग करने के लिए, हम निषिद्ध रुकावट के साथ महत्वपूर्ण खंड द्वारा गणना करते हैं। परिणाम बहुत अधिक नहीं बदलता है, उत्सर्जन में अभी भी एक जगह है, जिसका अर्थ है कि अतिरिक्त समय माइक्रो () द्वारा लाया जाता है। यहां हम कुछ नहीं कर सकते, हालांकि स्रोत कोड उपलब्ध है, हम इसे बदल नहीं सकते हैं - पुस्तकालयों को बायनेरिज़ में शामिल किया गया है। बेशक, हम समय के साथ काम करने के अपने कार्यों को लिख सकते हैं और उनके व्यवहार को देख सकते हैं, लेकिन एक सरल तरीका है।

चूंकि अवधि के "लंबे" प्रसंस्करण की अवधि में वृद्धि का एक संभावित कारण है, हम माप प्रक्रिया के दौरान इसकी घटना की संभावना को बाहर करते हैं। ऐसा करने के लिए, इसकी अभिव्यक्ति की प्रतीक्षा करें और उसके बाद ही हम माप चक्र का संचालन करते हैं। चूंकि हमारे माप चक्र की तुलना में रुकावट बहुत कम होती है, इसलिए हम इसकी अनुपस्थिति की गारंटी दे सकते हैं। हम प्रोग्राम के संबंधित खंड (स्रोत कोड से निकाली गई जानकारी के ~~साथ गंदे हैक~~ का उपयोग करके) लिखते हैं, और, "यह एक ऐसी सड़क जादू है", सब कुछ सामान्य हो जाता है - हम 166 घड़ी चक्र के पीटी के साथ अतिरिक्त ऑपरेशन के निष्पादन समय के औसत मूल्य के साथ 4 और 5 क्वांटा के निष्पादन समय को मापते हैं, जो पहले से मापा मूल्य से मेल खाती है। परिकल्पना की पुष्टि की जा सकती है।

एक और सवाल बना हुआ है - और रुकावटों में इतना लंबा समय क्या लगता है, यह क्या लेता है
(7.8) - (5) ~ 2 क्वांटा = * 4 = 8msec * 16 = 128 प्रोसेसर चक्र? हम स्रोत कोड की ओर मुड़ते हैं (अर्थात, गॉडबोल्ट.कॉम पर कंपाइलर द्वारा बनाए गए कोडांतरक कोड पर) और हम देखते हैं कि व्यवधान को लगभग 70 चक्र, उनमें से 60 लगातार निष्पादित किए जाते हैं, और जब पढ़ते हैं तो 10 चक्रों की अतिरिक्त लागत होती है, जब हिट पर कुल 70 रुकावट - प्राप्त की तुलना में कम है, लेकिन काफी करीब है। हम संकलक या उनके उपयोग के साधनों के बीच के अंतर का अंतर बताते हैं।

खैर, अब हम विभिन्न तर्कों के साथ पीटी के अतिरिक्त कमांड के वास्तविक निष्पादन समय को माप सकते हैं और यह सुनिश्चित कर सकते हैं कि तर्कों को बदलते समय यह वास्तव में बहुत बदल जाता है: 136 उपायों के लिए 0.0 से 190 के लिए 0.63 (जादू की संख्या), और यह 10.63 के लिए केवल 162 है। 99.9% की संभावना के साथ, यह संरेखण की आवश्यकता और इस विशेष पुस्तकालय में इसके कार्यान्वयन की विशेषताओं के कारण है, लेकिन यह अध्ययन स्पष्ट रूप से विचाराधीन समस्या के दायरे से परे जाता है।

परिशिष्ट - कार्यक्रम पाठ:

void setup() { Serial.begin(9600); } volatile float t; //   void loop() { int d[170]; unsigned long time,time1; float dt=1/170.; for (int i=0; i<170; ++i) { { //       time1=micros(); long time2; do { time2=micros(); } while ((time2 & ~0xFF) == (time1 & ~0xFF)); }; /**/ time1=micros(); //   /* cli(); //       -   */ t=10.63; //     t=t+dt; //   /* sei(); //    */ time = micros(); //   time1=time-time1; d[i]=time1/4; /* Serial.print(time1); //      Serial.flush(); //     Delay(20); //    */ }; //   ,     float sum=0; for (int i=0; i<170; ++i) { sum+=d[i]; Serial.println(d[i]); }; Serial.println((sum/170-2.11)*4*16); //2.11 –     Serial.flush(); //    ,     }

Arduino में गति और इसे मापने के सवाल पर

More articles: