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

सब ठीक है जो अच्छी तरह से समाप्त होता है

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

मान लें कि हमें अपने उदाहरण से कमांड क्षेत्र के उच्च-क्रम बिट को अलग-अलग करने की आवश्यकता है। पहली बात जो मन में आती है वह है संघ, हालांकि यूनियनों में थोड़ी लंबाई नहीं हो सकती। रजिस्टर विवरण के दो संस्करण बनाने और उन्हें पहले से ही संयोजित करने का एक विकल्प है, और यह काम करता है:

#pragma bitfields=reversed typedef struct { unsigned :1; unsigned int code:3; unsigned :26; const unsigned flag1:1; unsigned flag:1; } tIO_STATUS; typedef struct { unsigned :1; unsigned int start:1; unsigned :30; } tIO_STATUSA; #pragma bitfields=default typedef union { tIO_STATUS; tIO_STATUSA; } tIO_STATUS2; #define IO_ADR 0x20000004 volatile tIO_STATUS2 * const pio_device = (tIO_STATUS2 *) (IO_ADR); pio_device->code = 3; while (pio_device->flag) {}; pio_device->start=1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, लेकिन दो अतिरिक्त प्रकार बनाना कुछ हद तक बेमानी है (मेरी राय में)।

एक समूह के व्यक्तिगत बिट्स में हेरफेर करने के लिए एक विकल्प सभी एक ही बिट मास्क हैं, और हम टाइप के costructures के लिए आते हैं:

 #define BITNUM 2 //      0 #define BITMASK (1<<BITNUM) pio_device->code |= (1<< BITNUM); //   pio_device->code &= ~BITMASK;; //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 #define SETBIT(DEST,MASK) (DEST) |= (MASK) #define CLRBIT(DEST,MASK) (DEST) &= ~(MASK)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

केवल उनका उपयोग करना जारी रखें।

  SETBIT(pio_device->code,1 << BITNUM); CLRBIT(pio_device->code,BITMASK);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



अब हम स्थिरांक के बारे में बात करते हैं। एक नियम के रूप में, VU रजिस्टरों के साथ संचार करने के लिए, एक निश्चित क्षेत्र मान है और एक अच्छी प्रोग्रामिंग शैली है इन विशेषताओं के विवरण पर सार्थक नामों के साथ स्थिरांक के रूप में विचार करना और असाइन करते समय मूल्य की वैधता की जांच करना (अब तक मैंने जादू नंबर 3 का उपयोग किया है, लेकिन यह विशेष रूप से है। प्रशिक्षण के उद्देश्य)। इस समस्या को हल करने के लिए सी भाषा क्या अवसर प्रदान करती है? उनमें से दो हैं - #define के माध्यम से स्थिरांक को परिभाषित करना और प्रगणित प्रकार बनाना। हम इनमें से प्रत्येक विकल्प का विश्लेषण करेंगे। मान लीजिए कि हमारा उपकरण केवल 2 आदेशों को स्वीकार करने में सक्षम है - कोड 3 के साथ "काम शुरू करें" और कोड 2 के साथ "काम रोकें" तब हम लिख सकते हैं:

 #define IO_DEVICE_START 3 #define IO_DEVICE_STOP 2 pio_device->code=IO_DEVICE_START;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, जो सबसे अधिक बार किया जाता है। तो जादू की संख्या गायब हो गई, यहां तक ​​कि बिट क्षेत्र के आकार के अनुपालन के लिए एक जांच है, लेकिन अभिव्यक्ति

  pio_device->code=1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

संकलक मान्य के रूप में छोड़ देगा। अर्थात्, स्वीकार्यता के मूल्य को नियंत्रित करने का कार्य डेवलपर के कंधों पर पड़ता है और इसे ASSERT द्वारा कार्यान्वित किया जाता है। विधि काफी व्यावहारिक है, हम अक्सर इसका उपयोग करते हैं और यह काफी स्वीकार्य है अगर यह अधिक सुविधाजनक नहीं था, अर्थात् एक एन्यूमरेटेड प्रकार का उपयोग:

 #pragma bitfields=reversed typedef struct { unsigned :1; enum { O_DEVICE_START=3, IO_DEVICE_STOP=2, } code:3; unsigned :26; const unsigned flag1:1; unsigned flag:1; } tIO_STATUS; #pragma bitfields=default pio_device->code=IO_DEVICE_START; SETBIT(pio_device->code,BITMASK); pio_device->code |= BITMASK; pio_device->code=pio_device | BITMASK;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



खैर, निष्कर्ष में, उनके लिए कार्यों और रैपर के बारे में कुछ विचार। अक्सर पुस्तकालयों को देखने पर आपको निम्नलिखित के समान कुछ मिलेगा:

 dev_data_r_w (int n, int data_command, int r_w, int *adr) { ... }; int dev_data(int n, int data_comand, iint *adr) { return dev_data_r_w (n, 1, 1, int *adr); int read_dev(int n, int *adr) { return dev_data(n,1,adr); }; int ch_read_dev( int *adr) { return read_dev(1,adr); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 #define dev_data(N,DC,ADR) dev_data_r_w ((N),(DC),1,(ADR)) #define read_dev(N,ADR) dev_data((N),1,(ADR)) #define ch_read_dev(ADR) read_dev(1,(ADR))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

 enum { SET=1, RESET=0 } ACTIVE;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

- यह अच्छा है। मैं अभी भी समझ सकता हूं कि इस प्रकार का उपयोग बिट्स के लिए मान लिखने के लिए किया जाता है, लेकिन इसके मूल्य को कब नियंत्रित किया जाए? यह मुझे लगता है कि बूल प्रकार पूरी तरह से इस प्रकार की जगह लेता है, हालांकि कौन जानता है, यह अन्य राय सुनने के लिए तैयार है।



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