एक इंजीनियरिंग जांच का अनुभव

इस पोस्ट का विषय लगभग दुर्घटना से बना था, विशेष रूप से सॉफ्टवेयर के विकास के दृष्टिकोण के बारे में एक आसान चर्चा की प्रक्रिया में और सामान्य रूप से एमके पर डिवाइस। जो लोग रुचि रखते हैं, वे खुद चर्चा habrahabr.ru/company/coolrf/blog/222801 से परिचित कर सकते हैं। यद्यपि दोनों पक्ष स्पष्ट रूप से अपनी राय में बने हुए थे, फिर भी एक निश्चित चुनौती थी। मैं चुनौतियों से नहीं डरता, कोई भी चुनौती अपने आप में अच्छी होती है, क्योंकि इसका जवाब देना, आप किसी तरह से बदल रहे हैं और, एक नियम के रूप में, बेहतर विकल्प के लिए (जैसे कि "एक समय में 10 लीटर बीयर पीना कमजोर", जो स्पष्ट रूप से एक व्यक्ति को बदलता है बेहतर नहीं है, मेरी उम्र में यह अब रोल नहीं करता है)। इसलिए, हम शुरू कर रहे हैं।



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



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



हम एक मोड़ पर देरी के साथ चक्रीय डिमिंग एल्गोरिथ्म के एक सरल कार्यान्वयन के छद्म कोड को रेखांकित करते हैं:

while (1) { _; timer=_; while (timer) { if ~signal() { timer++}; timer--;}; //     0 timer=_; while (timer) { timer--}; //    ; _ ; ;  ; timer=_; while (timer && ) { timer--}; //      };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



मान लीजिए कि हम वास्तव में आवश्यक ZIG प्रसंस्करण प्रदान नहीं कर सकते। तो क्या? मानक को चतुर लोगों द्वारा विकसित किया गया था (हमेशा वार्ताकार को अपने से अधिक बेवकूफ न समझें जब तक कि वह आपके विपरीत साबित न हो, और यहां तक ​​कि इस मामले में आपसे गलती हो सकती है), जो पूरी तरह से जानते हैं कि 2.4 गीगाहर्ट्ज बैंड में हवा क्या है, और मुझे कभी भी विश्वास नहीं होगा कि यह मानक समयावधि सहित पुनरावर्तन और विफलताओं के सुधार के लिए उपाय प्रदान नहीं करता है। इसलिए, हमें दीपक चमक मापदंडों में बदलाव के बारे में संदेश छोड़ने के लिए क्या धमकी देता है? कि हम इसे अगले चक्र में स्वीकार करेंगे जब रुकावटों को हल किया जाएगा, या अगले और इतने पर। यही है, दीपक की चमक को बदलने में देरी हो सकती है (मैं उदार हूं) ऑपरेशन के 10 चक्रों तक, यानी 10 * 1/50/2 = 1/10 सेकंड। मुझे यह समझ में नहीं आया कि उपयोगकर्ता द्वारा इस तरह की देरी को कैसे नोट किया जा सकता है।



अब मान लीजिए कि हम जिस लाइब्रेरी का उपयोग कर रहे हैं (ATMEL से, वैसे) घुमावदार हाथों वाले प्रोग्रामर्स द्वारा किया गया था (हालांकि यह मेरे सिद्धांतों का खंडन करता है, लेकिन आपने एक सोचा प्रयोग के क्रम में क्या नहीं किया), और यह वास्तव में अगर इसे 65 μs के बाद नहीं कहा जाता है संदेश का आगमन। यही है, हम ZIG से नियंत्रण जानकारी प्राप्त करते समय लाइनों 1 और 2 के निष्पादन की अवधि की गारंटी नहीं दे सकते। तो क्या? यही है, जब दीपक की चमक को बदलने की आवश्यकता के बारे में जानकारी प्राप्त करते हैं, तो हम अगले नियंत्रण चक्र को गलत तरीके से जारी कर सकते हैं (हम पूरी तरह से बंद होने तक चमक की अवधि को छोटा कर सकते हैं)। यदि जानकारी को केवल तब ही प्रेषित किया जाता है जब उसे बदलने की आवश्यकता होती है, तो फिर से मैं एक ऐसे उपयोगकर्ता की कल्पना नहीं कर सकता जो इस तरह की दुर्लभ खराबी के कारण दीपक की चमक में बदलाव को नोटिस करेगा।



अब मान लीजिए कि सब कुछ वास्तव में खराब है, यानी जानकारी हमारे पास बहुत बार आती है और हम इसे प्राप्त करने के बाद जितनी जल्दी हो सके इसे संसाधित करने के लिए बाध्य होते हैं, अर्थात, हमारे छद्म कोड का निष्पादन समय पूरी तरह से अप्रत्याशित हो जाता है (बढ़ती अवधि की दिशा में)। स्थिति वास्तव में अप्रिय है, और हमारे पास लागू सरल और समझने योग्य कार्यान्वयन को छोड़ने के अलावा कोई विकल्प नहीं है। हम एक अतिरिक्त एमके (<व्यंग्य>) पास में रखे बिना क्या कर सकते हैं। खैर, शुरुआत के लिए, इंटरप्ट, टाइमर और पीडब्लूएम-संबंधित मॉड्यूलेटर के रूप में ऐसी चीजों के अस्तित्व को याद रखें (इस एमके में यह सब बहुत सारे हैं)। मैं निम्नलिखित समाधान का प्रस्ताव करता हूं: हम चक्र की अवधि निर्धारित करते हैं और स्टार्टअप मोड में इसी अवधि के लिए या एकल मोड (चक्र समय की तुलना में थोड़ा कम समय के लिए) में से एक को निर्धारित करते हैं। हम PWM मोड को कॉन्फ़िगर करते हैं और triac को नियंत्रित करने के लिए आउटपुट सिग्नल का उपयोग करते हैं। हम मुख्य वोल्टेज चक्र के साथ टाइमर के संचालन को सिंक्रनाइज़ करते हैं। हम संक्रमण के बारे में 0 से एक अवरोध के बारे में संकेत शुरू करते हैं और उस पर टाइमर (स्टार्टअप के लिए) की अवधि को सही करने या टाइमर (एक बार के लिए) को फिर से शुरू करने के लिए एक सबरूटीन पर डालते हैं। चूँकि यह हैंडलर स्पष्ट रूप से सरल और अल्पकालिक होता है (एक अंतरायन के वास्तविक आगमन समय की गणना करने के लिए लंबा ऑपरेशन) (कैप्चर मोड के बारे में मत भूलना), औसत गणना, और इसी तरह हैंडलर के निचले आधे हिस्से को सौंपा जा सकता है), हम लाइब्रेरी लॉन्च करने की आवश्यकताओं को पूरा करते हैं। सामान्य तौर पर, हर कोई खुश है, हर कोई हंस रहा है।



फिर भी, मैं भविष्य में एक पुस्तकालय का उपयोग करने के बारे में गंभीरता से सोचूंगा जो साझा सॉफ्टवेयर के विकास के लिए इस तरह की कठोर आवश्यकताओं को आगे बढ़ाता है। केवल एक चीज जो ध्यान में आती है: फिर भी, डेवलपर्स द्वारा पुस्तकालय में इस तरह के प्रतिबंध नहीं लगाए गए थे, लेकिन उन प्रोग्रामरों द्वारा इसके विवरण की गलत व्याख्या का परिणाम था जिन्होंने इसका उपयोग किया था। मैं 2 से 8 के रूप में पहले और दूसरे विकल्पों की संभावना अनुपात को दर करूंगा, खासकर अगर हम उपकरण के विस्तारित मोड के एमसी के विवरण में उल्लेख करते हैं, जो "अनुमेय देरी के लिए आवश्यकताओं को कम करता है।" लेकिन यहाँ हम अनुमान और अटकलों की एक अस्थिर जमीन पर चल रहे हैं, हालांकि मुझे ZIG के विषय में दिलचस्पी थी, और मैं उपयुक्त पुस्तकालय लिखने के साथ इसके गहन अध्ययन के बारे में सोच रहा हूं। सच है, चर्चा में कुछ प्रतिभागियों के बयानों के बावजूद, इस तरह के एक पुस्तकालय (एक साधारण डिवाइस के मामले में ZIG शब्द है) ATMEL से स्रोत कोड में स्वतंत्र रूप से उपलब्ध है।



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