टीआई के सवाल पर

"अब मैं आपको एक चित्र दिखाऊंगा ... हम्म ... मैं आपको चेतावनी देता हूं कि यह एक चित्र है ... वैसे भी, कृपया उसे एक चित्र की तरह व्यवहार करें ...

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

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

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

तो, TI वेबसाइट हमें क्या सिखाती है - मूल्यांकन मॉड्यूल के साथ काम करना शुरू करने के लिए, आपको तीन आवश्यक कदम उठाने होंगे:

1. मूल्यांकन मॉड्यूल खरीदें - किया।
   
   मार्जिन पर ध्यान दें (पीएनपी): आपको यह भी करना होगा, क्योंकि प्रश्न में प्रोग्रामिंग वातावरण में मैं व्यक्तिगत रूप से (दुर्भाग्य से) डिबगिंग के लिए हार्डवेयर का अनुकरण करने की क्षमता खोजने का प्रबंधन नहीं करता था, कम से कम जहां मैं देख रहा था।
2. विकास पर्यावरण स्थापित करें - डाउनलोड करें, इंस्टॉलर चलाएं, सब कुछ काम किया। हम मूल्यांकन मॉड्यूल को यूएसबी से जोड़ते हैं - जलाऊ लकड़ी खुद से उगता है और सब कुछ फिर से काम करता है - किया। जब आप डिवाइस को प्रोग्राम करने की कोशिश करते हैं, तो हमें फर्मवेयर को अपडेट करने की आवश्यकता के बारे में एक संदेश मिलता है, हम सहमत होते हैं और फिर से सबकुछ बदल जाता है। सामान्य तौर पर, यह लिखने के लिए कुछ भी नहीं है कि क्या यह हमेशा और हर जगह था ...
3. जाओ और पाठ्यक्रम का अध्ययन करें SimpleLink CC13x0 SDK 3.10 के लिए TI SimpleLink अकादमी 3.10.01 - एक अजीब सुझाव है, यह मुझे सिखाने के लिए लगता है - बस खराब करने के लिए, लेकिन ऐसा ही हो, मैं इसी लिंक को खोलता हूं और स्तब्ध हूं - यहां कितनी चीजें भरी हुई हैं।

यहां हम SYS / BIOS हार्डवेयर ड्राइवरों के साथ काम करने और TI-RTOS ऑपरेटिंग सिस्टम के साथ और USB सहित NDK नेटवर्क स्टैक का उपयोग करने और कंपनी द्वारा उत्पादित विभिन्न एमके परिवारों के प्रतिनिधियों के साथ काम करने के कई और पहलुओं पर प्रशिक्षण सामग्री देखते हैं। और यह सब धन तैयार-से-उपयोग के उदाहरणों के साथ है, और यदि हम उपयोगकर्ता मैनुअल और मॉड्यूल विवरणों की उपस्थिति को ध्यान में रखते हैं, तो शायद इसके लिए इच्छा करने के लिए अधिक कुछ नहीं है। लेकिन ऐसी उपयोगिताएँ भी हैं जो विभिन्न तरीकों से प्रोग्राम कोड, फ्लैशिंग और डीबगिंग को तैयार करने और कॉन्फ़िगर करने के काम की सुविधा प्रदान करती हैं, और यह धन भी काफी प्रलेखित है।

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

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

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

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

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

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

Pnp: लेकिन मुझे MISRA-C अनुपालन जाँच सक्षम करने के लिए विकल्प मिले।

Pnp: बाद के असेंबली के साथ "क्लीन ..." कमांड का उपयोग करने का एक और तरीका है, किसी कारण से "बिल्ड ऑल" कमांड संबंधित प्रोजेक्ट को प्रभावित नहीं करता है।

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

पीएनपी: रॉम में सबरूटीन को संक्रमण बहुत मज़ेदार लगता है - कमांड सिस्टम में कोई लंबा संक्रमण नहीं होता है, इसलिए पहले संक्रमण कम पते वाले क्षेत्र (0x0000) में मध्यवर्ती बिंदु पर लौटने के साथ किया जाता है, और पहले से ही पीसी बूट कमांड निहित है, जिसके मापदंडों को डिस्सेम्बलर द्वारा मान्यता प्राप्त नहीं है। कुछ ऐसा जो मैं विश्वास नहीं कर सकता, जैसे कि इस तरह के ओवरहेड लागत के साथ आप गति में जीत सकते हैं, हालांकि लंबी दिनचर्या के लिए - क्यों नहीं।

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

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

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

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

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

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

शुरू करने से पहले कार्य मापदंडों को निर्धारित करने की प्रक्रिया काफी अपेक्षित है:

1. एक पैरामीटर संरचना बनाएं (स्थानीय, निश्चित रूप से),
2. इसे डिफ़ॉल्ट मान दें,
3. मानक के अलावा अन्य पैरामीटर सेट करें, और
4. कार्य बनाते समय संरचना का उपयोग करें।

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

PNP: जाने-माने FREE-RTOS में, कार्य निर्माण कार्य के एपीआई के कॉल के शरीर में सीधे संकेतित कार्य मापदंडों के साथ थोड़ा अलग दृष्टिकोण लिया जाता है। इन दृष्टिकोणों के नियम और विपक्ष निम्नानुसार हैं:

1. + आपको स्पष्ट रूप से उन मापदंडों को निर्दिष्ट करने की अनुमति नहीं देता है जो डिफ़ॉल्ट मानों से मेल खाते हैं, + को पैरामीटर के क्रम को याद रखने की आवश्यकता नहीं है, -more क्रिया, -Larger स्मृति लागत, -आपको डिफ़ॉल्ट मापदंडों को जानने की आवश्यकता है, एक नामित मध्यवर्ती ऑब्जेक्ट को बनाता है
2. - सभी मापदंडों को निर्दिष्ट करने की आवश्यकता है, -सीमाओं के मापदंडों के क्रम को याद करते हुए, + अधिक कॉम्पैक्ट है, + कम मेमोरी की आवश्यकता है, + के लिए मध्यवर्ती वस्तुओं के नाम की आवश्यकता नहीं है।
   
   एक तीसरा तरीका है, इस पोस्ट के लेखक (TURBO की शैली में) की वकालत, जिसका अपना एक सेट है
3. + आपको मानकों को स्पष्ट रूप से निर्दिष्ट करने की अनुमति नहीं देता है, जो मानक से मेल खाते हैं, + को मापदंडों के क्रम को याद रखने की आवश्यकता नहीं है, -मुल्ती-मौखिक, -मूलर मेमोरी लागत, -आपको डिफ़ॉल्ट मापदंडों को जानने की जरूरत है, + लंबोदर शैली में काम करता है, + मानक त्रुटियों को लागू करने के लिए मुश्किल बनाता है, -सच में दिखता है कई सही कोष्ठक के कारण अजीब है।

खैर, एक और चौथा विकल्प है, किसी भी कमियों से रहित, लेकिन 14 से कम नहीं सी ++ की आवश्यकता है - हम अपने होंठ चाटते हैं और गुजरते हैं।

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

Pnp: हम डिबगिंग की एक और विशेषता पर ध्यान देते हैं, ठीक है, यह किसी भी विकास के माहौल के लिए सही है - जब हम एक शेड्यूलर के साथ कार्यों को स्विच करते हैं, तो हम फ़ोकस फोकस खो देते हैं, ब्रेकपॉइंट्स हमें इस समस्या को हल करने में मदद करेंगे।

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

सूत्रों का सावधानीपूर्वक अध्ययन से पता चलता है कि सब कुछ इतना अच्छा नहीं है। समस्या क्या है - आरंभीकरण फ़ंक्शन उस ऑब्जेक्ट से डिफ़ॉल्ट मानों की प्रतिलिपि बनाता है जो हमारे नियंत्रण संरचना में निरंतर क्षेत्र में निहित है, और यह अद्भुत है, लेकिन किसी कारण के लिए:

1. ऑब्जेक्ट वैश्विक है, हालांकि यह मापदंडों को इनिशियलाइज़ करने के लिए एकमात्र फ़ंक्शन द्वारा उपयोग किया जाता है (एक समय में एक समान अभ्यास लागत टोयोटा एक सभ्य राशि) - ठीक है, स्थिर निर्देश जोड़ना आसान है;
2. नियंत्रण वस्तु का नाम है, सी में इस समस्या का कोई सुंदर समाधान नहीं है, या यों कहें कि एक अनाम प्रति के साथ एक समाधान है और मैंने इसे एक लंबे समय के बाद दिया है, लेकिन बहुत सारे सही कोष्ठक इस विकल्प को वास्तव में सुंदर कहने की अनुमति नहीं देते हैं, प्लस में भयानक सुंदरता का एक समाधान है, लेकिन क्या एक पाइप सपने का सपना देखने के लिए;
3. ऑब्जेक्ट के सभी फ़ील्ड स्पष्ट रूप से बिट गहराई में बेमानी हैं, यहां तक ​​कि बिट फ़ील्ड (दो संभव मानों की गणना) 32-बिट शब्दों में संग्रहीत हैं;
4. प्रगणित मोड स्थिरांक को परिभाषित के रूप में परिभाषित किया जाता है, जो संकलन चरण में और रन समय में आवश्यक जांचना असंभव बनाता है;
5. संभावित विफलताओं के विभिन्न स्थानों में एक अनंत लूप के अनुभाग को दोहराते हुए, एक (इस मामले में खाली) हैंडलर बनाने के लिए यह अधिक सही होगा;
6. ठीक है, एक कार्य को शुरू करने और शुरू करने के लिए सभी संचालन (और चाहिए) एक फ़ंक्शन या एक मैक्रो में भी छिपाया जा सकता है।

लेकिन प्राप्त बफर की आरंभीकरण अच्छी तरह से किया जाता है - हम पूर्व-आरक्षित मेमोरी का उपयोग करते हैं, ढेर का कोई हेरफेर नहीं होता है, कॉल चेन कुछ जटिल है, लेकिन सब कुछ पठनीय है।

Pnp: डिबग विंडो में, हमारी आंखों के सामने, कॉल स्टैक, सब कुछ वैसा ही किया जाता है जैसा कि उसे और ध्वनि से - सम्मान और सम्मान। केवल एक चीज जो कुछ आश्चर्यचकित करती है वह है इस विंडो को छिपाने का प्रयास डिबगिंग सत्र के अंत में होता है।

खैर, और एक और कुछ अप्रत्याशित निर्णय - संयुक्ताक्षरों में धारावाहिक बंदरगाहों के लिए और इस डिबग बोर्ड के लिए 1 के बराबर शैली में वस्तुओं की संभावित संख्या निर्धारित करना।

typedef enum CC1310_LAUNCHXL_UARTName { CC1310_LAUNCHXL_UART0 = 0, CC1310_LAUNCHXL_UARTCOUNT } CC1310_LAUNCHXL_UARTName; 

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

एक रनिंग टास्क में, हम एक क्लासिक अनंत लूप का निरीक्षण करते हैं जिसमें एक सीरियल पोर्ट के डेटा को फ़ंक्शन द्वारा पढ़ा जाता है

 UART_read(uart, &input, 1); 

और तुरंत समारोह से वापस भेज दिया

 UART_write(uart, &input, 1); 

। आइए पहले एक में जाएं और प्राप्त बफर से पात्रों को पढ़ने का प्रयास देखें

 return (handle->fxnTablePtr->readPollingFxn(handle, buffer, size)) 

(मैं इस तरह की चीजों से कैसे नफरत करता हूं, लेकिन सी में यह असंभव है अन्यथा, हम गहराई से जाते हैं और UARTCC26XX_read में खुद को पाते हैं, और इससे हम रिंग बफर के कार्यान्वयन में आते हैं - एक फ़ंक्शन

 RingBuf_get(&object->ringBuffer, &readIn) 

। यहां, सामान्य जीवन एक तीव्र चरण में चला जाता है।

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

1) रीड / राइट पॉइंट्स के री-रोल को डिविजन के शेष भाग के माध्यम से लागू किया जाता है

 object->tail = (object->tail + 1) % object->length; 

और इस ऑपरेशन को करते समय संकलक का कोई अनुकूलन नहीं होता है, जैसे कि एक बिट मास्क को ओवरले करना, क्योंकि बफर की लंबाई एक स्थिर नहीं है। हां, इस MK में एक हार्डवेयर डिवीजन ऑपरेशन है और यह बहुत तेज़ है (मैंने इसके बारे में लिखा है), लेकिन फिर भी यह कभी भी 2 घड़ी चक्र नहीं लेता है, जैसा कि सही री-रोल के साथ सही कार्यान्वयन में होता है (और मैंने इसके बारे में भी लिखा था)

Pnp: मैंने हाल ही में कार्यान्वयन में नई M7 वास्तुकला का विवरण देखा और मुझे किसी को याद नहीं है, इसलिए किसी कारण से, 32 को 32 से विभाजित करने पर 2-7 के बजाय 2-12 चक्रों में प्रदर्शन किया जाने लगा। या तो यह एक अनुवाद त्रुटि है, या ... मैं यह भी नहीं जानता कि क्या सोचना है।

2) इसके अलावा, इस कोड के टुकड़े को एक से अधिक स्थानों पर दोहराया जाता है - मैक्रोज़ और वाइम्प्स, ctrl + C और ctrl + V नियम के लिए, DRY सिद्धांत जंगल से होकर जाता है

3) भरे हुए बफर स्थानों का एक पूरी तरह से निरर्थक काउंटर लागू किया गया था, जो निम्नलिखित दोष को पूरा करता है,

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

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

6) एक ही समय में, बफर अतिप्रवाह प्रसंस्करण पूरी तरह से अनुपस्थित है (इस स्थिति के बारे में -1 रिटर्न सिग्नलिंग है) - यहां तक ​​कि अरुडिनो में भी, हम इस प्रसंस्करण की गुणवत्ता को छोड़ देंगे, लेकिन इसकी अनुपस्थिति और भी बदतर है। या लेखक प्रसिद्ध तथ्य से प्रेरित थे कि कोई भी धारणा अपेक्षाकृत खाली सेट के बारे में सच है, इस तथ्य सहित कि यह खाली नहीं है?

सामान्य तौर पर, मेरी टिप्पणियाँ पूरी तरह से कोड की समीक्षा "कोड की 10 पंक्तियों -" अन्य टिप्पणियों के विषय पर डिमोनेटिवेटर की पहली पंक्ति के अनुरूप हैं। "

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

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

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

 *(unsigned char *)object->writeBuf); 

2) काम का तर्क पूरी तरह से अपारदर्शी है और थोड़ा भ्रमित है। लेकिन यह सब इतना महत्वपूर्ण नहीं है, क्योंकि यह उपयोगकर्ता से छिपा रहता है और "अधिकतम गति को प्रभावित नहीं करता है।"

अनुसंधान की प्रक्रिया में, हम एक और विशेषता के साथ आते हैं - हम डिबग मोड में कुछ आंतरिक कार्यों के स्रोत कोड को नहीं देखते हैं - यह विभिन्न संकलन विकल्पों (ROM / NO_ROM) के लिए नामों के परिवर्तन के कारण है। आवश्यक स्रोत फ़ाइल को बदलें (C: \ Jenkins \ jobs \ FWGroup-DriverLib \ Workspace \ output \ आउटपुट \ cc13xx_cha_2_0_ext \ driverlib \ bin \ ccs /.//../../// driverlib / uart.c--) मैं विफल रहा (लेकिन मैं वास्तव में कोशिश नहीं कर रहा था), हालांकि मुझे स्रोत मिला (बेशक, uart.c फ़ाइल में फ़ाइल में, धन्यवाद, कप्तान), सौभाग्य से, यह टुकड़ा सरल है और सी में स्रोत कोड के साथ कोडांतरक कोड की पहचान करना आसान है (खासकर यदि आप ITxxx टीम की विशेषताओं को जानते हैं)। मुझे नहीं पता कि जटिल कार्यों के साथ पुस्तकालयों के लिए इस समस्या को कैसे हल किया जाए, हम सोचेंगे कि जब आवश्यकता होती है।

और अंत में, एक छोटी सी टिप्पणी - मैं यह मानने के लिए तैयार हूं कि एमके CC13x0 मॉडल के लिए धारावाहिक चैनल कार्यान्वयन का हार्डवेयर CC26x0 के लिए समान है, और UARTCC26XX.c नामक एक फ़ाइल की सामग्री का दोहराव --- सही समाधान नहीं कहा जा सकता है, लेकिन समावेशन के साथ एक मध्यवर्ती परिभाषा फ़ाइल बनाना। मैं स्रोत फ़ाइल का स्वागत करता हूं, फ़ंक्शन और संबंधित टिप्पणी को ओवरराइड करता हूं, क्योंकि यह कार्यक्रम को और अधिक समझने योग्य बना देगा, और यह हमेशा स्वागत योग्य होना चाहिए।

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

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

Pnp: अभी भी नाम से एक खोज है, इसे (स्वाभाविक रूप से) Ctrl-F संयोजन द्वारा कहा जाता है, यह केवल संदर्भ मेनू में मौजूद है, लेकिन सामान्य तौर पर इसे रद्द कर दिया जाता है, मैं डेवलपर्स से माफी मांगता हूं।

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

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

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

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

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

हम प्रयोग शुरू करते हैं, पहला भाग (निष्पादन समय की प्रतीक्षा कर रहा है) ने काउंटरों के अनुपात पर डेटा दिया था 406181 / 58015 = 7 - यह काफी अपेक्षित है। दूसरा भाग (~ 10 सेकंड के लिए लगातार 10 अक्षरों के साथ) परिणाम 351234k-50167k * 7 = 63k / 20 = 3160 चक्र देता है, अंतिम अंक एमके चक्र में संदर्भ स्विचिंग प्रक्रिया से जुड़ा समय है। व्यक्तिगत रूप से, यह मूल्य मुझे उम्मीद से कुछ बड़ा लगता है, हम अनुसंधान जारी रख रहे हैं, ऐसा लगता है कि अभी भी कुछ क्रियाएं हैं जो आंकड़ों को खराब करती हैं।

PNP: एक प्रयोगकर्त्ता की एक सामान्य गलती पहले से अपेक्षित परिणामों का मूल्यांकन करना और प्राप्त कचरे पर विश्वास करना है (737 डेवलपर्स के लिए नमस्ते)।

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

और यहां इस तरह के मुश्किल जोड़तोड़ के परिणाम हैं: हम पैकेट द्वारा इनपुट बनाते हैं और लापता उपाय छोटे हो जाते हैं - 2282, आउटपुट बंद करें और लागत 1222 उपायों तक गिर जाती है - यह बेहतर है, हालांकि मैं 300 चक्रों के लिए उम्मीद कर रहा था।

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

PNP: वैसे भी, बहुत कुछ - मैंने संदर्भ को बचाने के लिए 100: 30 पर चक्र गिना, 40 को समाप्त कार्य निर्धारित करने के लिए और 30 संदर्भ को बहाल करने के लिए, लेकिन हमें परिमाण का एक आदेश अधिक मिला। हालाँकि अब अनुकूलन बंद कर दिया गया है, -ओ 2 चालू करें और परिणाम देखें: यह बहुत अधिक नहीं बदला है - यह 3160 के बजाय 2894 हो गया है।

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

इस बार पोस्ट के अंत में पारंपरिक सर्वेक्षण प्रस्तुति के स्तर के लिए समर्पित नहीं होगा (यह किसी भी निष्पक्ष पाठक के लिए स्पष्ट है कि वह किसी भी प्रशंसा से परे है और किसी भी अपेक्षा से अधिक है), लेकिन अगले पोस्ट के विषय के लिए।