Vusb लाइब्रेरी का आविष्कार

परिचय

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

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

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

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

चरण 0. लोहा और अन्य तैयारी

परीक्षण के रूप में, आइए 12 MHz क्वार्ट्ज के साथ ATmega8 पर आधारित एक होममेड डिबगिंग बोर्ड लें। मैं स्कीम नहीं दूंगा, यह काफी मानक है (आधिकारिक vusb वेबसाइट देखें), उल्लेख के लायक केवल एक चीज है जिसका उपयोग किया गया है। मेरे मामले में, आउटपुट D + PD2, आउटपुट D- PD3 से मेल खाता है, और निलंबित PD4 पर लटका हुआ है। सिद्धांत रूप में, एक पुल-अप रोकनेवाला बिजली से जुड़ा हो सकता है, लेकिन मैनुअल नियंत्रण मानक के साथ थोड़ा अधिक सुसंगत लगता है।

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

चूंकि हम कार्यान्वयन का "आविष्कार" कर रहे हैं, इसलिए यह देखना अच्छा होगा कि नियंत्रक के दिमाग में क्या होता है, यानी कम से कम किसी तरह की डिबगिंग जानकारी की आवश्यकता होती है। मेरे मामले में, ये PD6, PD7 पर दो LED हैं और सबसे महत्वपूर्ण बात, PD0, PD1 पर UART, को 115200 पर कॉन्फ़िगर किया गया है, ताकि आप नियंत्रक स्क्रीन के माध्यम से नियमित स्क्रीन या COM पोर्ट के साथ काम करने के लिए किसी अन्य प्रोग्राम को सुन सकें:

$ screen /dev/ttyUSB0 115200 

इसके अलावा, उपयुक्त मॉड्यूल वाला एक तारक यूएसबी डिबगिंग के लिए एक उपयोगी उपयोगिता बन जाएगा (यह हमेशा बॉक्स से शुरू नहीं होता है, लेकिन ऐसी समस्याओं को हल करना इंटरनेट पर काफी सफलतापूर्वक स्थित है और इस लेख का काम नहीं है)।

यहां प्रोग्रामर, मेकफाइल्स और अन्य चीजों के विवरण पर पाठ का एक और किलोबाइट खर्च करना संभव होगा, लेकिन यह शायद ही समझ में आता है। इसी तरह, मैं परिधीय सेटिंग्स पर ध्यान केंद्रित नहीं करूंगा जो यूएसबी से संबंधित नहीं हैं। अगर कोई इसका पता नहीं लगा सकता है, तो क्या सॉफ्टवेयर यूएसबी के बॉल्स में प्रवेश करना जल्दबाजी होगी?

जीथब पर सभी चरणों के लिए स्रोत कोड उपलब्ध है।

चरण 1. कम से कम कुछ स्वीकार करें

प्रलेखन के अनुसार, USB कई निश्चित गति का समर्थन करता है, जिनमें से AVR केवल सबसे कम खींचेगा: 1.5 मेगाबिट्स प्रति सेकंड। यह पुल-अप रोकनेवाला और बाद के संचार द्वारा निर्धारित किया जाता है। हमारी चुनी हुई आवृत्ति के लिए, रोकनेवाला को एक 3.3 V बिजली की आपूर्ति के साथ D- कनेक्ट करना चाहिए और 1.5 kOhm का नाममात्र मूल्य होना चाहिए, लेकिन व्यवहार में इसे +5 V के साथ जोड़ा जा सकता है और नाममात्र मूल्य थोड़ा भिन्न हो सकता है। 12 मेगाहर्ट्ज की एक नियंत्रक आवृत्ति के साथ, प्रति बिट केवल 8 घड़ी चक्र। यह स्पष्ट है कि ऐसी सटीकता और गति केवल कोडांतरक में ही प्राप्त होती है, इसलिए हम drvasm.S फ़ाइल खोलेंगे। यह भी एक बाइट की शुरुआत को पकड़ने के लिए एक बाधा का उपयोग करने की आवश्यकता का मतलब है। मुझे खुशी है कि USB के माध्यम से प्रसारित पहली बाइट हमेशा एक ही है, SYNC, इसलिए यदि आप शुरुआत में आते हैं, तो यह ठीक है। नतीजतन, बाइट की शुरुआत से लेकर इसके अंत तक, नियंत्रक के केवल 64 चक्र होते हैं (वास्तव में, मार्जिन और भी छोटा है), इसलिए आपको अन्य गैर-यूएसबी अवरोधों का उपयोग नहीं करना चाहिए।

तुरंत कॉन्फ़िगरेशन को एक अलग usbconfig.h फ़ाइल में डालें। यह वहाँ है कि यूएसबी के लिए जिम्मेदार पिन सेट किए जाएंगे, साथ ही बिट्स, कॉन्स्टेंट और रजिस्टरों का उपयोग किया जाएगा।

सैद्धांतिक सम्मिलित करें
USB के माध्यम से स्थानांतरण प्रत्येक में कई बाइट्स के पैकेट में किया जाता है। पहला बाइट हमेशा SYNC सिंक्रोनाइज़ेशन बाइट होता है, 0b10000000 के बराबर, दूसरा पीआईडी ​​पैकेट का बाइट पहचानकर्ता होता है। प्रत्येक बाइट का स्थानांतरण कम से कम महत्वपूर्ण बिट से सबसे महत्वपूर्ण एक तक जाता है (यह पूरी तरह सच नहीं है, लेकिन vusb में इस सूक्ष्मता को अनदेखा किया जाता है, कहीं और दिया जाता है) NRZI एन्कोडिंग का उपयोग कर। इस पद्धति में इस तथ्य को समाहित किया गया है कि तार्किक स्तर को विपरीत स्तर पर बदलकर एक तार्किक शून्य प्रसारित किया जाता है, और एक तार्किक इकाई को गैर-परिवर्तन द्वारा प्रेषित किया जाता है। इसके अलावा, सिग्नल स्रोत और रिसीवर के डेसिंक (जिसे हम उपयोग नहीं करेंगे, लेकिन इसे ध्यान में रखना चाहिए) से सुरक्षा शुरू की गई है: यदि संचरित अनुक्रम में एक पंक्ति में छह इकाइयां हैं, अर्थात्, टर्मिनलों की स्थिति लगातार छह समय तक नहीं बदलती है, तो एक मजबूर उलटा संचरण में जोड़ा जाता है, जैसे कि शून्य प्रसारित होता है। इस प्रकार, बाइट का आकार 8 या 9 बिट्स हो सकता है।
यह भी ध्यान देने योग्य है कि यूएसबी में डेटा लाइनें अंतर हैं, अर्थात, जब डी + उच्च है, डी- यह कम है (इसे के-स्टेट कहा जाता है) और इसके विपरीत (जे-स्टेट)। यह उच्च आवृत्ति पर बेहतर शोर प्रतिरक्षा के लिए किया जाता है। सच है, एक अपवाद है: पैकेट के अंत में संकेत (इसे एसई 0 कहा जाता है) दोनों सिग्नल लाइनों को जमीन पर खींचकर प्रेषित किया जाता है (डी + = डी- = 0)। D + लाइन पर कम वोल्टेज और D + लाइन पर एक उच्च वोल्टेज को अलग-अलग समय के लिए रखने से दो और संकेत प्रेषित होते हैं। यदि समय छोटा है (एक बाइट की लंबाई या थोड़ी लंबी) तो यह आइडल है, पैकेट के बीच एक ठहराव है, और यदि यह बड़ा है, तो रीसेट सिग्नल।

इसलिए, ट्रांसमिशन एक अंतर जोड़ी पर है, एसई 0 के विदेशी मामले की गिनती नहीं कर रहा है, लेकिन हम अभी तक इस पर विचार नहीं करेंगे। इसलिए USB बस की स्थिति निर्धारित करने के लिए, हमें केवल एक पंक्ति, D + या D- की आवश्यकता है। द्वारा और बड़े, कोई अंतर नहीं है जिसे किसी को चुनना है, लेकिन निश्चितता के लिए डी- होना चाहिए।

पैकेट की शुरुआत एक लंबे आइडल के बाद SYNC बाइट प्राप्त करके निर्धारित की जा सकती है। आइडल अवस्था D- लाइन (यह भी J- स्टेट है) पर log.1 से मेल खाती है, और SYNC बाइट 0b100000 है, लेकिन इसे सबसे महत्वपूर्ण बिट से सबसे महत्वपूर्ण एक में स्थानांतरित किया जाता है, इसके अलावा, इसे NRZI में एन्कोड किया गया है, अर्थात प्रत्येक शून्य का मतलब सिग्नल इनवर्जन है, और एक का अर्थ है समान स्तर बनाए रखना। तो राज्यों का क्रम D- निम्नानुसार होगा:

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

दरअसल, UART के बाद के आउटपुट के साथ दो और बाइट्स पढ़ने के लिए सभी और कोड का इरादा है। खैर, SE0 की स्थिति का इंतजार कर रहे हैं ताकि गलती से अगले पैकेज में न आ सकें।

अब आप परिणामी कोड को संकलित कर सकते हैं और देख सकते हैं कि हमारा उपकरण क्या स्वीकार करता है। व्यक्तिगत रूप से, मेरे पास निम्नलिखित अनुक्रम हैं:

 4E 55 00 00 4E 55 00 00 4E 55 00 00 4E 55 00 00 4E 55 00 00 

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

शून्य को डीकोड करने का कोई मतलब नहीं है, क्योंकि एक पैकेट में 16 समान मूल्यों को एक पैकेट में शामिल नहीं किया जा सकता है।

इस प्रकार, हम फर्मवेयर लिखने में सक्षम थे जो पैकेट के पहले दो बाइट्स को स्वीकार करता है, हालांकि अब तक डिकोडिंग के बिना।

चरण 2. NRZI का डेमो संस्करण

मैन्युअल रूप से पुनरावृत्ति न करने के लिए, आप इसे नियंत्रक को सौंप सकते हैं: XOR ऑपरेशन ठीक वही करता है, जिसकी आपको आवश्यकता है, हालांकि परिणाम उलटा है, इसलिए इसके बाद एक और उलटा जोड़ें:

 mov temp, shift lsl shift eor temp, shift com temp rcall uart_hex 

परिणाम काफी अपेक्षित है:

 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 2D 00 FF FF 

चरण 3. बाइट प्राप्त चक्र से छुटकारा पाएं

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

पिछले विकल्प से परिणाम अलग नहीं है।

चरण 4. बफर को पढ़ें

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

USB में पैकेट संरचना मानकीकृत है और इसमें निम्न भाग शामिल हैं: SYNC बाइट, PID + CHECK बाइट (प्रत्येक के 4 बिट्स के 2 फ़ील्ड), डेटा फ़ील्ड (कभी-कभी 11 बिट्स, लेकिन अधिक बार 8-बिट बाइट्स की एक मनमानी संख्या) और सीआरसी या तो 5 का चेक योग () 11-बिट डेटा फ़ील्ड के लिए), या 16 (शेष के लिए) बिट्स। अंत में, पैकेट इंडिकेशन (EOP) का अंत दो पॉज़ बिट्स है, लेकिन यह अब डेटा नहीं है।

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

चरण 5. बफर के साथ मानवीय रूप से कार्य करना

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

 >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF >03 2D 00 10 >01 FF 

चरण 6. एक योजक शून्य योजक जोड़ना

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

 unstuff0: ;1 (  breq) andi x3, ~(1<<0) ;1 [15]  0-  .     mov x1, x2 ;1 [16]      () in x2, USBIN ;1 [17] <-- 1-   .     ori shift, (1<<0) ;1 [18]  0-   .1      rjmp didUnstuff0 ;2 [20] ;<---//---> rxLoop: eor shift, x3 ;1 [0] in x1, USBIN ;1 [1] st y+, shift ;2 [3] ldi x3, 0xFF ;1 [4] nop ;1 [5] eor x2, x1 ;1 [6] bst x2, USBMINUS ;1 [7]     0-   shift bld shift, 0 ;1 [8] in x2, USBIN ;1 [9] <--  1- (, ) andi x2, USBMASK ;1 [10] breq se0 ;1 [11] andi shift, 0xF9 ;1 [12] didUnstuff0: breq unstuff0 ;1 [13] eor x1, x2 ;1 [14]; bst x1, USBMINUS ;1 [15]     1-   shift bld shift, 1 ;1 [16] rxbit2: in x1, USBIN ;1 [17] <--  2-  (, ) andi shift, 0xF3 ;1 [18] breq unstuff1 ;1 [19] didUnstuff1: 

नेविगेशन की सुविधा के लिए, वर्णित कमांड के पते दाईं ओर लेबल द्वारा गिने जाएंगे। कृपया ध्यान दें कि उन्हें नियंत्रक के घड़ी चक्र की गणना के लिए पेश किया गया था, इसलिए वे क्रम में नहीं हैं। अगला बाइट rxLoop लेबल पर पढ़ा जाता है, पिछली बाइट को उल्टा किया जाता है और बफर को लिखा जाता है [0, 3]। अगला, लेबल [1] पर, डी-लाइन की स्थिति पढ़ी जाती है, पिछले स्वीकृत स्थिति के साथ XOR के अनुसार, हम NRZI को डिकोड करते हैं (मुझे याद है कि साधारण XOR अपना व्युत्क्रम जोड़ता है, जिसे ठीक करने के लिए हम मास्क रजिस्टर x3 में प्रवेश करते हैं, इकाइयों 0xFF के साथ आरंभीकृत करते हैं) और 0- लिखते हैं। [बिट शिफ्ट रजिस्टर [7,8]। फिर मज़ा शुरू होता है - हम जांचते हैं कि प्राप्त बिट छठे अपरिवर्तित था। डी के साथ प्राप्त निरंतर बिट - शून्य लिखने से मेल खाती है (एक नहीं! हम रजिस्टर में एक, एक्सओआर में बदल जाएंगे)। इसलिए, आपको यह जांचने की आवश्यकता है कि बिट्स 0, 7, 6, 5, 4, 3 शून्य हैं या नहीं। शेष दो बिट्स कोई फर्क नहीं पड़ता, वे पिछले बाइट से बने रहे और पहले चेक किए गए थे। उनसे छुटकारा पाने के लिए, हमने मास्क [12] द्वारा रजिस्टर को काट दिया, जहां हमारे लिए सभी बिट्स 1: 0b11111001 = 0xF9 पर सेट हैं। यदि मुखौटा लगाने के बाद सभी बिट्स शून्य हो गए, तो थोड़ा जोड़ने की स्थिति तय हो गई है और unstuff0 लेबल के लिए एक संक्रमण है। एक और बिट [17] वहां पढ़ा जाता है जो पहले पढ़ा गया था, अन्य ऑपरेशन के बीच के अंतराल में, एक अतिरिक्त [9]। हम वर्तमान और पिछले मानों X1, x2 के रजिस्टरों की अदला-बदली भी करते हैं। तथ्य यह है कि प्रत्येक बिट पर एक रजिस्टर में मूल्य पढ़ा जाता है, और फिर XOR दूसरे के साथ होता है, जिसके बाद रजिस्टरों को स्वैप किया जाता है। तदनुसार, वृद्धिशील रजिस्टर पढ़ते समय, इस ऑपरेशन को भी करने की आवश्यकता होती है। लेकिन सबसे दिलचस्प बात यह है कि शिफ्ट डेटा रजिस्टर में हम शून्य नहीं लिखते हैं, जिसे हम ईमानदारी से प्राप्त करते हैं, लेकिन जिस इकाई ने मेजबान को स्थानांतरित करने की कोशिश की थी [18]। यह इस तथ्य के कारण है कि अगले बिट्स प्राप्त करते समय, शून्य के मूल्य को भी ध्यान में रखना होगा, और अगर हमने शून्य दर्ज किया, तो मास्क चेक यह पता नहीं लगा सका कि अतिरिक्त बिट को पहले ही ध्यान में रखा गया है। इस प्रकार, शिफ्ट रजिस्टर में, सभी बिट्स उल्टे होते हैं (मेजबान द्वारा प्रेषित के सापेक्ष), और शून्य नहीं है। बफर में इस तरह की गड़बड़ी को रोकने के लिए, हम Xx के साथ 0xFF [0] के अनुसार एक उलटा उलटा प्रदर्शन करेंगे, लेकिन 0xFE के साथ, अर्थात्, एक रजिस्टर जिसमें संबंधित बिट को 0 पर रीसेट किया जाएगा और तदनुसार, उलटा करने के लिए नेतृत्व नहीं करेगा। नमूना [15] पर ऐसा करने के लिए और शून्य बिट को रीसेट करें।

इसी तरह की स्थिति बिट्स 1-5 के साथ होती है। कहते हैं, 1 बिट 1, 0, 7, 6, 5, 4 की जांच करने के लिए मेल खाती है, जबकि बिट्स 2, 3 को अनदेखा किया जाता है। यह मास्क 0xF3 से मेल खाता है।
लेकिन 6 और 7 बिट्स की प्रोसेसिंग अलग है:

 didUnstuff5: andi shift, 0x3F ;1 [45]   5-0 breq unstuff5 ;1 [46] ;<---//---> bld shift, 6 ;1 [52] didUnstuff6: cpi shift, 0x02 ;1 [53]   6-1 brlo unstuff6 ;1 [54] ;<---//---> bld shift, 7 ;1 [60] didUnstuff7: cpi shift, 0x04 ;1 [61]   7-2 brsh rxLoop ;3 [63] unstuff7: 

6 बिट के लिए मुखौटा संख्या 0b01111110 (0x7E) है, लेकिन आप इसे शिफ्ट रजिस्टर पर सुपरइम्पोज़ नहीं कर सकते, क्योंकि यह 0 बिट को रीसेट कर देगा, जिसे सरणी में लिखा जाना चाहिए। इसके अलावा, उलटी गिनती में [45], एक मुखौटा पहले से ही सुपरिंपोज किया गया था, जिसमें 7 बिट्स को रीसेट किया गया था। इसलिए, अतिरिक्त बिट को संसाधित करना आवश्यक है यदि बिट्स 1-6 शून्य के बराबर हैं, और 0 वें कोई फर्क नहीं पड़ता। यही है, रजिस्टर का मूल्य 0 या 1 होना चाहिए, जो "2 से कम" [53, 54] की तुलना करके पूरी तरह से जाँच की जाती है।

उसी सिद्धांत का उपयोग 7 वें बिट के लिए किया गया था: 0xFC मास्क लगाने के बजाय, "4 से कम" [61, 63] के लिए एक चेक किया जाता है।

चरण 7. पैकेज को क्रमबद्ध करें

चूँकि हम 0x2D (SETUP) के बराबर पहले बाइट (PID) के साथ एक पैकेट प्राप्त कर सकते हैं, हम प्राप्त किए गए को छाँटने की कोशिश करेंगे। वैसे, मैंने ACK होने पर पैकेज को 0x2D SETUP क्यों कहा? तथ्य यह है कि कम से कम महत्वपूर्ण बिट से सबसे महत्वपूर्ण एक तक यूएसबी ट्रांसमिशन प्रत्येक क्षेत्र के भीतर किया जाता है, और बाइट नहीं, जबकि हम बाइट-बाय-बाइट स्वीकार करते हैं। पहला महत्वपूर्ण क्षेत्र, पीआईडी, केवल 4 बिट्स लेता है, उसके बाद 4 और CHECK बिट्स, PID फ़ील्ड के एक बिटवाइज़ इनवर्टर का प्रतिनिधित्व करता है। इस प्रकार, प्राप्त पहली बाइट PID + CHECK नहीं होगी, बल्कि CHECK + PID होगी। हालांकि, बहुत अंतर नहीं है, क्योंकि सभी मूल्यों को पहले से जाना जाता है, और स्थानों में निबल्स को फिर से व्यवस्थित करना आसान है। तुरंत, हम मुख्य कोड लिखेंगे जो usbconfig.h फ़ाइल में हमारे लिए उपयोगी हो सकता है।

हमने अभी तक पीआईडी ​​प्रसंस्करण कोड जोड़ना शुरू नहीं किया है, ध्यान दें कि यह तेज होना चाहिए (जो कि असेंबलर में है), लेकिन घड़ियों द्वारा संरेखण की आवश्यकता नहीं है, क्योंकि हमने पहले ही पैकेट स्वीकार कर लिया है। इसलिए, बाद में इस अनुभाग को asmcommon.inc फ़ाइल में स्थानांतरित कर दिया जाएगा, जिसमें कोडांतरक कोड होगा जो आवृत्ति से बंधा नहीं है। इस बीच, केवल टिप्पणी पर प्रकाश डालें।
अब प्राप्त पैकेट को छाँटने के लिए आगे बढ़ते हैं।

सैद्धांतिक सम्मिलित करें
USB बस पर डेटा पैकेट को लेनदेन में जोड़ा जाता है। प्रत्येक लेनदेन होस्ट द्वारा एक विशेष मार्कर पैकेट भेजने के साथ शुरू होता है जो मेजबान को डिवाइस के साथ क्या करना चाहता है के बारे में जानकारी देता है: कॉन्फ़िगर करें (SETUP), डेटा (OUT) भेजें या इसे प्राप्त करें (IN)। मार्कर पैकेट प्रसारित होने के बाद, दो बिट्स का एक विराम इस प्रकार है। इसके बाद एक डेटा पैकेट (DATA0 या DATA1) होता है, जिसे मार्कर पैकेट के आधार पर होस्ट और डिवाइस दोनों द्वारा भेजा जा सकता है। अगला, लंबाई में दो बिट्स का एक और ठहराव और जवाब है, एक पुष्टि पैकेट (ACK, NAK, STALL, हम उन्हें एक और समय पर विचार करेंगे)।

सेटअप		DATA0		हाथ मिलाना
यजमान-> यंत्र	ठहराव	यजमान-> यंत्र	ठहराव	डिवाइस-> होस्ट

बाहर		DATA0 / DATA1		हाथ मिलाना
यजमान-> यंत्र	ठहराव	यजमान-> यंत्र	ठहराव	डिवाइस-> होस्ट

में		DATA0 / DATA1		हाथ मिलाना
यजमान-> यंत्र	ठहराव	डिवाइस-> होस्ट	ठहराव	यजमान-> यंत्र

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

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

इसके अलावा, यह बीच में कहीं से लॉग्स भेजने के लायक है, कहीं मुख्य में।

हम इन परिवर्तनों को करने के बाद जो हुआ उससे डिवाइस को फ्लैश करते हैं और प्राप्त बाइट्स के निम्नलिखित अनुक्रम का निरीक्षण करते हैं:

 2D|80|06|00|01|00|00|40|00 C3|80|06|00|01|00|00|40|00 2D|80|06|00|01|00|00|40|00 C3|80|06|00|01|00|00|40|00 

और इसके अलावा - दोनों जलते एलईडी। इसलिए, हमने SETUP और OUT को पकड़ा।

चरण 8. लिफाफे पर पता पढ़ें

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

मैदान	समन्वयन	addr	endpoint	सीआरसी	EOP
USB बिट्स	0-7	0123456	0123	01234	01
बिट्स प्राप्त किया		0123456	7012	34567

, - ( - PID = SETUP OUT) (IN) , .

, (-) (Handshake) :

• : , , NAK
• -: SETUP OUT, , IN — ,
• . , , ,

« — » . PID', , . «PID» . usbCurrentTok. PID' (DATA0, DATA1) , . , ? : , ( 0 usbCurrentTok ), , . ( SE0) , - , D+, D- . , SYNC, . , , . «» , . .

, . x3, (, , , ).

, USB , , . , , , CRC ( ). , [21]. 0- . , [26]. , CRC, .

9.

, , « », ACK. NAK', ( cnt — ). USB , , SYNC PID. Y, cnt ( ). , — ACK. x3 — 1 , . x3 ( r20) 20.

( SETUP, ), ACK' , , , . , .

, D+, D- ( ), — . XOR , , , , - .

, , , , . , , , . . vusb : txBitloop 2 ([00], [08]). 3 , 6 . , . 1 3 : 171. ( 171, 11 , ), — , . cnt=4:

4 — 171 = -167 = ( ) 89 (+ )
89 — 171 = -82 = ( ) 174 (+ )
174 — 171 = 3. ,
, .

, 3 , 1. 6 , , x4. D+, D- , . .
:

 2D|80|06|00|01|00|00|40|00 69|00|10|00|01|00|00|40|00 

C3 . , , UART . , , IN , . , .

10. NAK

NAK , . , . , - .

, . , , - , . usbRxBuf, . , — , USB_BUFSIZE. usbInputBufOffset, . .

NAK handleData , [22]. (usbRxLen), - . ( — ), usbRxLen, , — usbRxToken, SETUP OUT - . : , , ACK .

. , , - , -, . ? , , , , - .

,

 2D|80|06|00|01|00|00|40|00 

, NAK`, , .

11.

, , . — . , , , , , . . . , USB, usbPoll. — , . — . SETUP , PID CRC, SETUP 5- , 16-. 3 «» . «» PID usbRxToken, CRC , , . usbProcessRx, , .

, , — , SE0. , USB .

. SETUP, . . SETUP usbRequest_t 8 . : ( USB-) , - . , . .
, , , .

12. SETUP'

, , . . usbDriverSetup, . , . , ( , , ) . , : ACK NAK, .

13.

, SETUP + DATAx, DATAx 8 . IN DATAx, . , . , ACK NAK. , . — usbTxBuf, , usbTxLen . low-speed USB 8 ( PID, CRC), usbTxLen 11. PID, , . , 16, , 0x0F, . PID , . IN, , (handshake , ).

:
SETUP + DATAx, ACK NAK . , , usbPoll, , ( PID=DATA1 ( DATA0 DATA1 , , DATA1). CRC . , , - . — 4 . , 3 , 4. , SYNC . « IN NAK?» NAK. , , DATA1 .

, — USBRQ_SET_ADDRESS ( , ). . (drvsdm.S, make SE0). , , , DATA1 , , . , , , , , . , , .

14.

, . , USBRQ_GET_DESCRIPTOR USBRQ_SET_ADDRESS, , . usbDriverDescriptor, . , USBRQ_GET_DESCRIPTOR. , , :

USBDESCR_DEVICE — : USB (1.1 ), , , . .
USBDESCR_CONFIG — , , . .
USBDESCR_STRING — , .
, , USBDESCR_DEVICE, , .

15.

. -, . , - - , , HID, , . Vendor ID Product ID, USB, . , vusb .

, , - . , , , (, ) usbMsgPtr, — len, usbMsgLen. ( ) 18 , 8. , , 3 . - , STALL.

usbDeviceRead. , memcpy_P, , , .

, , , . , , .

, , .

PID' DATA0 DATA1 . PID' , , - .

, DATA0 / DATA1 ( ), , , 3 , . XOR PID', . , , XOR' . PID DATA1, XOR PID , XOR DATA0 .

, , USBDESCR_CONFIG.

16. - !

USBDESCR_CONFIG USBDESCR_DEVICE. ( , ) . , - USB-, , D+, D-.

, : , , . , ( , ). , UTF-16, . USB UTF-8 .

vusb , lsusb . VID, PID , . , VID, PID, — .

, , ( ). SETUP: , , . 0, , — . , , , .
.

17. (HID)

HID — human interface device, , , . HID , . , , , , , . «» . HID ( low-speed 800 ), .

HID , USBDESCR_HID_REPORT. vusb, . , usbDriverSetup ( ) usbFunctionSetup ( ). , SETUP, OUT. , , , usbFunctionWrite.

, usbDeviceRead usbFunctionRead, . , , usbFunctionSetup ( , ) USB_FLG_USE_USER_RW, usbDriverSetup .

— — usbFunctionWrite usbFunctionRead. . — , .

usbDriverSetup.

18.

, , . HID, , , ( udev - ). , , . , , , .
UPD: ramzes2 , HIDAPI

.

19. vusb

vusb , .

drvasm.S - usbdrvasm.S asmcommon.inc, -, , usbdrvasm12.inc — usbdrvasm20.inc.

main.c main.c ( ) usbdrv.c ( vusb)
usbconfig.h ( ), , , usbconfig.h.

निष्कर्ष

vusb, , , . , , . . , , , USB-HID. , , , vusb, , , , .

https://www.obdev.at/products/vusb/index.html ( vusb)
http://microsin.net/programming/arm-working-with-usb/usb-in-a-nutshell-part1.html
.. USB:
https://radiohlam.ru/tag/usb/
http://we.easyelectronics.ru/electro-and-pc/usb-dlya-avr-chast-1-vvodnaya.html
http://usb.fober.net/cat/teoriya/

PS - (, ) ,