सी, भाग 1 में बाहरी डिवाइस रजिस्टरों के साथ काम करना

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



उच्च स्तर की भाषा में एमके प्रोग्रामिंग में, बाहरी उपकरणों के रजिस्टरों के साथ बातचीत करने का लगातार उठने वाला कार्य है (यह मुझे लगता है कि एम्बेडेड इसकी विशेषता है)। सबसे पहले, इस बातचीत को व्यवस्थित करने के लिए, इन रजिस्टरों को किसी तरह इस्तेमाल की जाने वाली भाषा के माध्यम से निर्दिष्ट किया जाना चाहिए (मान लें कि यह सी है)। किसी भी VU रजिस्टर को उसके पते और रचना की विशेषता होती है, जिसे भाषा के माध्यम से व्यक्त किया जाना चाहिए। तुरंत, हम ध्यान दें कि मानक C स्मृति में चर के स्थान के लिए एक विशिष्ट पते को निर्दिष्ट करने के लिए किसी भी संभावना का प्रतिनिधित्व नहीं करता है (कम से कम मुझे इस तरह के बारे में पता नहीं है), इसलिए या तो मानक एक्सटेंशन का उपयोग करना या चालें लागू करना आवश्यक है। मान लीजिए कि हमें 0x40000004 पते पर स्थित बाहरी डिवाइस के 32-बिट रजिस्टर में 3 से मान लिखने की आवश्यकता है। निम्नलिखित छोटी बैसाखी हमें भाषा उपकरणों का उपयोग करके ऐसा करने की अनुमति देती है:

*(uint32_t *) (0x40000004)=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

आइए इस रेखा पर अधिक बारीकी से विचार करें। कहीं ऊपर (stdint.h फ़ाइल में) एक परिभाषा है

 typedef unsigned int uint32_t;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, जो हमें C संकलक के हमारे संस्करण में 32-बिट संख्याओं के प्रतिनिधित्व के बारे में सोचने की अनुमति नहीं देता है। यदि हमें संकलक के किसी अन्य संस्करण पर स्विच करना है, तो इसकी अपनी एक stdint फ़ाइल होगी और हमारे पास कोई पोर्टेबिलिटी समस्या नहीं होगी। यह अभ्यास बहुत उपयोगी है, और मैं केवल उन लेखकों में शामिल हो सकता हूं जो एम्बेडेड प्रोग्रामिंग में इसके उपयोग की दृढ़ता से अनुशंसा करते हैं।

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

 #define IO_DATA_ADRESS 0x40000004 #define WORD(ADR) *(uint32_t *) (ADR) WORD(IO_DATA_ADRESS)=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यहां सब कुछ पहले से ही लगभग ठीक है, केवल एक चीज जो महान नहीं है, पाठ में एक मैक्रो का उपयोग करने की आवश्यकता है, इसलिए (स्वाभाविक रूप से) एक और मैक्रो:

 #define IO_DATA WORD(IO_DATA_ADRESS) IO_DATA=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

हमें एक पूरी तरह से कार्यात्मक कोड मिला है, और हम सभी ने इसे मानक भाषा टूल का उपयोग करके लागू किया है, जो बेहतर प्रतीत होगा? फिर भी, यह संभव है और बेहतर है (ठीक है, मुझे यह बेहतर लगता है) - यदि हम प्रीप्रोसेसर के बाद कोड को देखते हैं, तो हमारे रजिस्टर तक कोई भी पहुंच विस्तारित रूप में दो तारांकन के साथ एक ही बदसूरत रेखा में बदल जाएगी। और यहाँ संकेत हमारी सहायता के लिए आते हैं (नहीं, चिप और डेल नहीं)। निम्नलिखित कोड पर विचार करें

 volatile uint32_t *pIO_DATA = (uint32_t *) (IO_DATA_ADRESS); *pIO_DATA=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब, जब रजिस्टर तक पहुँचते हैं, तो कोई मैक्रोज़ नहीं होते हैं, सब कुछ भाषा के माध्यम से व्यक्त किया जाता है, कोड बिल्कुल पारदर्शी और (मेरी राय में) अधिक तार्किक है। केवल एक ही चीज़ एक बहुत ही आवश्यक सितारा नहीं है, लेकिन बाद में उस पर और अधिक।

अभी के लिए, मैं इस तरह के कार्यान्वयन के लिए दोनों विकल्पों में से एक कमियां नोट करूंगा - कोई भी और कुछ भी हमें लिखने से रोक नहीं सकता है

 #define IO_DATA_ADRESS 0x40000003
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और प्रोग्राम एक्जीक्यूशन के दौरान एक अपवाद मिलता है, क्योंकि कंपाइलर टाइप टाइप कन्वर्सेशन चेक नहीं करता है और न ही पैर में होने से हस्तक्षेप करता है (यह C, बेबी है, ADA नहीं है, मेरा विश्वास करो)। आप ASSERT की मदद से रस्सी की लंबाई कम कर सकते हैं, लेकिन ईमानदार होने के लिए, वे हमेशा नहीं लिखे जाते हैं, हर जगह और अपर्याप्त मात्रा में नहीं।

दोनों निर्माणों के निष्पादन की दक्षता के लिए (जो लोग मेरे पदों को पहले से ही महसूस कर चुके हैं कि यह मेरी सनक है), फिर मेरे कंपाइलर पर (एआरएम 6.60.1.5097 के लिए IAR C / C ++ कंपाइलर) एक पॉइंटर के साथ विकल्प लंबा हो जाता है (अत्यधिक अनुक्रमण के कारण) ), जिसे निम्नलिखित निर्माण का उपयोग करके इलाज किया जाता है

 volatile uint32_t * const pIO_DATA = (uint32_t *) (IO_DATA_ADRESS);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जिसके बाद संकलक के परिणाम अप्रभेद्य हो जाते हैं।

 LDR.N R0, DATA_TABLE1 MOVS R1,#3 STR R1,[R0] ... DATA_TABLE: DC32 0x40000004
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

वैसे, कास्ट कीवर्ड जोड़ना एक अच्छी प्रोग्रामिंग शैली से मेल खाता है, क्योंकि हमारा सूचक स्पष्ट रूप से अपरिवर्तित है, और यह हमें आक्रामक (और लंबे समय से वांछित) त्रुटियों से भी बचाएगा:

 pIO_DATA=&i;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस रूप में, रजिस्टरों के साथ काम करने का हमारा तरीका काफी अच्छा है, और अगर यह मूल्यों के सत्यापन की कमी के साथ दोष के लिए नहीं था, तो यह लगभग आदर्श है (जैसा कि आप जानते हैं, कोई आदर्श चीजें नहीं हैं, लेकिन लगभग)। फिर भी, एक समस्या है और मुझे यह दिखाने में खुशी होगी कि इसे कैसे हल किया जाता है (ज्ञान दिखाने के लिए एक उत्कृष्ट अवसर)। सी भाषा के विस्तार में, एमके के साथ काम करने के लिए उन्मुख, पते के पूर्ण मूल्यों को इंगित करने के लिए साधन शुरू किए गए हैं। मेरे मामले में, यह @ ऑपरेटर (और #pragma स्थान निर्देश) है, जिसे निम्न उदाहरण का उपयोग करके दिखाया जा सकता है

 volatile uint32_t io_data @ IO_DATA_ADRESS; volatile uint32_t * const pIO_DATA = &io_data; i0_data=3; *pIO_DATA=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

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

 #define IO_DATA_ADRESS 0x40000004 #define IO_STATUS_ADRESS 0x40000008 ( - #define IO_STATUS_ADRESS IO_DATA_ADRESS +4) volatile uint32_t pIO_DATA = (uint32_t *) (IO_DATA_ADRESS); volatile uint32_t pIO_STATUS = (uint32_t *) (IO_STATUS_ADRESS); while {*pIO_STATUS) {}; *pIO_DATA=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 #define IO_DATA_ADRESS 0x40000004 typedef struct { uint32_t data; uint32_t status; } IO_DEVICE; volatile IO_DEVICE * const pio_device = (IO_DEVICE *) (IO_DATA_ADRESS); while (pio_device->status==0) {}; pio_device->data=3;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

यह संबोधित करने के बारे में बहुत अधिक निकला, इसलिए हम भाग 2 में बिट क्षेत्रों के साथ काम करने पर विचार करेंगे यदि विषय दिलचस्प है।