एसडी कार्ड का धीमा संचालन - किसे दोष देना है और क्या करना है?

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



इसलिए, एक विकास में मुझे प्रसंस्करण केंद्र के लिए नेटवर्क के माध्यम से प्रसारण के उद्देश्य के लिए महत्वपूर्ण मात्रा में जानकारी को बचाने की आवश्यकता थी। चूंकि परिणामी उपकरण बड़े पैमाने पर उत्पादन के लिए अभिप्रेत था, इसलिए एक संस्करण को अपेक्षाकृत सस्ती घटकों का उपयोग करके चुना गया था, और विशेष रूप से, सिस्टम के केंद्रीय तत्व के रूप में माइक्रोकंट्रोलर। चूंकि उस समय (मध्य 2012) में बोर्ड पर ईथरनेट PHY के साथ माइक्रोकंट्रोलर्स की पेशकश विविधता में भिन्न नहीं थी (और अब स्थिति ज्यादा बेहतर नहीं है), मैंने स्टेलारिस परिवार की TI कंपनी को चुना, विशेष रूप से LM3S8962, खासकर जब से मेरे पास इसके लिए एक डीबग बोर्ड है वहाँ था उस समय एमके अपेक्षाकृत नया था, टीआई द्वारा सक्रिय रूप से प्रचारित किया गया था (इसे 2013 के अंत में पूरी श्रृंखला को एनआरएनडी श्रेणी में स्थानांतरित कर दिया गया था), और इसमें ऐसे पैरामीटर हैं जो इस समस्या को हल करने के लिए काफी पर्याप्त हैं। जानकारी संग्रहीत करने के लिए, मुख्य रूप से उनकी उपलब्धता और सस्तेपन के कारण, एसडी कार्ड के साथ एक विकल्प चुना गया था, और यह भी क्योंकि डिबग बोर्ड पर उनके लिए एक संपर्क उपकरण था, और डीबग कार्ड के साथ आपूर्ति की गई सीडी पर कई उदाहरण थे, जिसमें शामिल थे एसडी कार्ड। कार्ड का इंटरफ़ेस सबसे सरल तरीके से लागू किया गया था - एसपीआई, प्रस्तावित उदाहरणों ने तुरंत काम किया, निर्णय ने डेटा को पीसी कार्ड रीडर में बस कार्ड से स्थानांतरित करके इंटरफ़ेस को लिखने से पहले प्राप्त डेटा को संसाधित करना संभव बना दिया, इसलिए नियंत्रण ऑब्जेक्ट के साथ इंटरैक्शन एल्गोरिदम के प्रारंभिक डिबगिंग ने समस्या का कारण नहीं बनाया, कम से कम परियोजना के इस हिस्से में। जैसा कि सभी समझते हैं, बाद में समस्याएं पैदा हुईं ...





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



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



दूसरा चरण - मैं एसपीआई इंटरफ़ेस के संचालन की जांच करता हूं और पाता हूं कि यह 12.5 मेगाहर्ट्ज की आवृत्ति पर काम करता है, हालांकि विवरण आपको 25 मेगाहर्ट्ज (50 मेगाहर्ट्ज की प्रोसेसर घड़ी की गति का आधा) तक संचरण आवृत्ति सेट करने की अनुमति देता है। यह पता चला है कि पुस्तकालय से एसपीआई मॉड्यूल की आवृत्ति सेट करने की दिनचर्या अधिकतम संभव आवृत्ति 12.5 मेगाहर्ट्ज तक सीमित करती है, और माइक्रोकंट्रोलर इंटरफ़ेस मॉड्यूल के लिए प्रलेखन में ऐसा कोई प्रतिबंध नहीं है।

i = ROM_SysCtlClockGet() / 2; if(i > 12500000) { i = 12500000; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम कोड बदलते हैं और रिकॉर्डिंग समय में 7 सेकंड - 1 TI बिंदु पर 2 गुना कमी प्राप्त करते हैं।



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

 void xmit_spi(BYTE dat) { uint32_t ui32RcvDat; SSIDataPut(SDC_SSI_BASE, dat); /* Write */ SSIDataGet(SDC_SSI_BASE, &ui32RcvDat); /* flush data */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मैंने एक ज्ञात त्रुटि को ठीक किया (मैं इसे और क्या कह सकता हूं?) और 3 सेकंड का फ़ाइल स्थानांतरण समय प्राप्त कर सकता हूं - 1 TI बिंदु।

और यहां अनुकूलन के परिणामस्वरूप ऐसा हुआ है जो कार्य की विशेषताओं को ध्यान में नहीं रखता है।

 static void xmit_spi_my (BYTE const *dst, int length) { int i, *p, *d; d=(int*)(SDC_SSI_BASE+SSI_O_DR); p=(int*)(SDC_SSI_BASE+SSI_O_SR); do { while (!(*p & SSI_SR_TNF)) {} *d=*dst++; } while (--length); while (*p & SSI_SR_RNE) i=*d; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

चौथा चरण - मैं उच्च-स्तरीय मॉड्यूल का अध्ययन करता हूं और पता लगाता हूं कि, चूंकि इंटरफ़ेस से डेटा ट्रांसफर केवल मेमोरी से प्रदान किया जाता है, मुझे एक डबल काम करना होगा - पहले कंट्रोल ऑब्जेक्ट से डेटा स्ट्रीम पढ़ें और इसे माइक्रोकंट्रोलर की रैम (और इस तरह से, 32 किलोबाइट करें) बफर), और फिर मेमोरी से SPI रजिस्टरों तक। मैं रजिस्टर से रजिस्टर करने के लिए सीधे डेटा स्थानांतरित करने के लिए अपना खुद का मॉड्यूल लिख रहा हूं, और मुझे 1.6 सेकंड का रिकॉर्डिंग समय मिलता है। उसी समय, मैं एक मानक कॉल के अंदर अपने मॉड्यूल को कॉल मास्क कर रहा हूं ताकि फ़ाइल सिस्टम समझता है कि 32 किलोबाइट को स्थानांतरित किया जाता है - 1 टीआई बिंदु।



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



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



नीचे की रेखा - समस्या हल हो गई है, उपकरणों को उपभोक्ता को भेज दिया जाता है और विफलताओं के बिना काम किया जाता है, ज्ञात और निर्धारित समस्याओं की संख्या के लिए कुल स्कोर: एसडी कार्ड - 2, टीआई से पुस्तकालय - 3, माइक्रोकंट्रोलर सुविधाएँ -1। और पूर्वगामी से, हम निम्नलिखित निष्कर्ष निकाल सकते हैं:

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

2. हम विभिन्न उपकरणों के प्रदर्शन के बारे में विशिष्टताओं के बारे में सावधान हैं, अर्थात्, हम ध्यान से विनिर्देशों को पढ़ते हैं कि कौन से मोड और कौन से नंबर हासिल किए गए हैं, और न केवल मापदंडों के 1-2 अंकों को देखें और तय करें कि वे हमारे अनुरूप होंगे।

3. माइक्रोकंट्रोलर मॉड्यूल के लिए सावधानीपूर्वक प्रलेखन पढ़ें, उनकी आंतरिक संरचना को समझने की कोशिश करें, एक वास्तविक बोर्ड पर वास्तविक प्रक्रियाओं का अध्ययन करने के लिए आस्टसीलस्कप के बारे में मत भूलना।



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