KolibriOS में USB समर्थन: अंदर क्या है? भाग 6: हब ड्राइवर

USB अवसंरचना का अंतिम भाग हब है। हालाँकि, हब अलग-अलग USB डिवाइस होते हैं, वे बुनियादी ढांचे के अन्य भागों से निकटता से संबंधित होते हैं ताकि हब विनिर्देश मुख्य USB विनिर्देश का हिस्सा हो और समर्थन कोड बस / usb / hub.inc फ़ाइल में स्थित कर्नेल का हिस्सा हो।

हब के कार्य इस प्रकार हैं।

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

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


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

कक्षा 9 इंटरफ़ेस की खोज करने के बाद, तार्किक डिवाइस परत usb_hub_callbacks संरचना को पढ़ता है जिसमें usb_hub_init और usb_hub_disconnect ड्राइवर फ़ंक्शन usb_hub_disconnect हैं। ड्राइवर तब शुरू होता है जब तार्किक डिवाइस स्तर usb_hub_init कॉल usb_hub_init , और तब समाप्त होता है जब चैनल समर्थन स्तर डिवाइस डिस्कनेक्ट करने के जवाब में usb_hub_disconnect को कॉल usb_hub_disconnect है।

प्रारंभ

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

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

• आकार और प्रकार, सभी विवरणों के साथ; हब डिस्क्रिप्टर टाइप 29h ;
• बंदरगाहों की संख्या
• विशेषता बिट्स। इन्फ्रास्ट्रक्चर के लिए एकमात्र विशेषता महत्वपूर्ण है टीटी द्वारा पेश किया गया जब गति स्विचिंग के साथ पैकेट प्रसारित करते हैं, तो इसे फुलस्पीड गति से 8 * (1 + बिट्स 6: 5) बिट्स के रूप में गणना की जाती है; आकृति के सभी विवरणों में, यह 8 एफएस-बिट्स के बराबर है;
• 2-मिलीसेकंड अंतराल में मापा सक्षम कमांड के बाद बंदरगाहों पर बिजली को स्थिर करने के लिए आवश्यक समय, 32h=50 100 एमएस से मेल खाती है;
• हब इलेक्ट्रॉनिक्स में, एमएए में बिजली की आवश्यकता;
• फिक्स्ड उपकरणों के बिटमास्क। आकार - प्रति बंदरगाह एक बिट, और आरक्षित कम से कम महत्वपूर्ण बिट, बाइट सीमा तक गठबंधन किया गया। आकृति से हब कीबोर्ड के लिए, बिट 3 - स्क्रैच से गिनती - सेट की जाती है, जो पोर्ट 3 पर एक गैर-हटाने योग्य डिवाइस से मेल खाती है - कीबोर्ड से ही - एक से गिनती। बंदरगाहों 3 और 6 के लिए, आपको क्रमशः 4 और 7 बिट्स की आवश्यकता होती है, जो बाइट के लिए गोल होती है; 8 बंदरगाहों को 9 बिट्स की आवश्यकता होती है, जो दो बाइट्स के लिए गोल है, और इसी तरह;
• चर आकार का एक और क्षेत्र, पिछले एक के समान, और पुराने सॉफ्टवेयर के साथ संगतता के लिए एफएफ से भरा हुआ।

हैंडल आकार में परिवर्तनशील है। अधिकतम आकार 255 बंदरगाहों पर प्राप्त होता है और 40 बाइट्स के बराबर होता है। usb_hub_init समापन बिंदु पैकेट के आकार को बचाता है - इसे आगे की आवश्यकता होगी - और हब विवरणक के 40 बाइट्स का अनुरोध करते हुए, एक छोटी प्रतिक्रिया की अनुमति देता है। हब डिस्क्रिप्टर प्राप्त करने के बाद, usb_hub_got_config रोचक डेटा को संग्रहीत करने के लिए पर्याप्त मेमोरी आवंटित करता है, और प्रत्येक पोर्ट के लिए दो चर: कनेक्टेड डिवाइस के लिए एक पॉइंटर और डिवाइस का कनेक्शन समय।

इससे पहले कि आप हब पोर्ट के साथ काम कर सकें, आपको SET_FEATURE(PORT_POWER) साथ उनकी शक्ति को चालू करना होगा। कमांड इनपुट पर एक पोर्ट नंबर स्वीकार करता है। 1. शारीरिक रूप से, हब प्रत्येक पोर्ट के लिए पावर ऑन और ऑफ कर सकता है या दो राज्यों तक सीमित हो सकता है: "सभी पोर्ट पर कोई पावर नहीं है" और "पावर सभी पोर्ट पर है" - संगठन को विशेषताओं के कम से कम दो महत्वपूर्ण बिट्स से मिल सकता है हब, 00 सामान्य बिजली की आपूर्ति से मेल खाती है, 01 से अलग एक, 10 और 11 आरक्षित हैं। लेकिन दोनों मामलों में, हब प्रत्येक पोर्ट के लिए एक अलग तार्किक स्थिति बनाए रखता है और बंदरगाहों पर होने वाली घटनाओं की तार्किक रूप से बिजली बंद करने की रिपोर्ट नहीं करेगा, इसलिए भौतिक संगठन की परवाह किए बिना, आपको प्रत्येक पोर्ट पर पावर चालू करने की आवश्यकता है। usb_hub_got_config और usb_hub_port_powered क्रमिक रूप से सभी पोर्ट के लिए एक पॉवर-ऑन कमांड usb_hub_port_powered करता है।

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

काम

संक्षेप में, हब पोलिंग स्कीम को निम्न विवरण में वर्णित किया गया है, USB विनिर्देश से लिया गया है:

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

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

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

• एक उपकरण बंदरगाह से जुड़ा है,
• हब जुड़ा डिवाइस के बिट सेट करता है और राज्य का बिट बदलता है,
• हब एक निश्चित बंदरगाह पर बदलाव के बारे में मेजबान को संकेत देता है,
• होस्ट GET_STATUS आदेश देता है और वर्तमान स्थिति में और राज्य परिवर्तन में डिवाइस का कनेक्शन देखता है;
• उपकरण बंद हो जाता है
• हब जुड़ा डिवाइस के बिट को रीसेट करता है, स्थिति परिवर्तन बिट सेट रहता है,
• होस्ट CLEAR_FEATURE आदेश भेजता है, हब परिवर्तन बिट को रीसेट करता है,
• हब का मानना ​​है कि मेजबान सभी परिवर्तनों के बारे में जानता है, मेजबान को वर्तमान स्थिति का एक गलत विचार है।

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

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

जब कोई उपकरण जुड़ा होता है, तो usb_hub_changed कनेक्शन समय को याद करता है, जिसके बाद usb_hub_process_deferred 100 मिलीसेकेंड के बाद जागने की योजना usb_hub_process_deferred । यदि 100 मिलीसेकंड के भीतर एक सिग्नल उसी पोर्ट पर डिवाइस को डिस्कनेक्ट करने के लिए आता है, तो आगे की कार्रवाई रद्द कर दी जाती है। दुर्भाग्य से, इस तरह के सिग्नल की अनुपस्थिति का मतलब यह नहीं है कि डिवाइस इन सभी 100 मिलीसेकंड के लिए जुड़ा हुआ है - शायद मतदान अंतराल काफी लंबा है, और सिग्नल अभी तक नहीं पहुंचा है। विश्वसनीयता के लिए, 100-मिलीसेकंड अंतराल के बाद, usb_hub_process_deferred एक स्पष्ट GET_STATUS अनुरोध भेजता है। यदि यह दिखाता है कि कनेक्शन की स्थिति में कोई बदलाव नहीं हुआ था, तो आगे की आरंभीकरण सक्षम है। आप समानांतर में एक ही बस में दो उपकरणों को रीसेट नहीं कर सकते हैं; अगर एक ही नियंत्रक से जुड़े कुछ अन्य डिवाइस का एक रीसेट है - जरूरी नहीं कि एक ही हब के लिए - तो पहले डिवाइस रीसेट करने के लिए अपनी बारी का इंतजार करता है। रीसेट को SET_FEATURE(PORT_RESET) द्वारा सक्रिय किया गया है और हब द्वारा निर्दिष्ट 10 एमएस के गुजर जाने के बाद स्वचालित रूप से अक्षम हो जाता है, जो रीसेट स्थिति परिवर्तन के एक बिट की स्थापना की ओर जाता है, जो कि समापन बिंदु को पढ़ते समय या समय पर ध्यान नहीं दिया जा सकता है, जो मतदान अंतराल पर निर्भर करता है। इस तरह की अनिश्चितता के कारण, usb_hub_process_deferred सेट समय और CLEAR_FEATURE बाद स्वतंत्र रूप से usb_hub_process_deferred भेजता है, और परिवर्तन प्रसंस्करण कोड, यदि यह रीसेट स्थिति में परिवर्तन नहीं देखता है, तो बस इसे अनदेखा करता है। एक साथ हब में रीसेट के अंत में डिवाइस में यातायात का संचरण शामिल है। एक रीसेट के बाद, usb_hub_process_deferred विनिर्देशन के अनुसार, usb_hub_process_deferred एक और 10 मिली सेकेंड इंतजार करता है, जिसके दौरान डिवाइस अनुकूलित कर सकता है, जिसके बाद यह usb_hardware_func.NewDevice कॉल करके होस्ट कंट्रोलर सपोर्ट कोड पर नियंत्रण स्थानांतरित करता है । हब ने रीसेट प्रक्रिया के दौरान usb_hardware_func.NewDevice के लिए डिवाइस की गति निर्धारित की और GET_STATUS जवाब में अन्य डिवाइस स्थिति के साथ वापस आ गया। usb_hardware_func.NewDevice से लौटे कनेक्टेड डिवाइस का एक पॉइंटर हब संरचना में संग्रहीत है।

जब डिवाइस काट दिया जाता है, तो usb_hub_changed usb_device_disconnected समर्थन स्तर के usb_device_disconnected फ़ंक्शन को कॉल करता है , इसे NewDevice से पहले सहेजे गए सूचक को NewDevice । यदि डिवाइस आरंभीकरण प्रक्रिया में था, तो प्रक्रिया समाप्त हो जाती है।

वियोग

usb_hub_disconnected हैंडलर, जिसे हब के डिस्कनेक्ट होने पर कॉल किया usb_device_disconnected , सभी जुड़े उपकरणों के लिए usb_device_disconnected को कॉल usb_device_disconnected है, रीसेट होने की प्रतीक्षा कर रहे उपकरणों की कतार को आगे बढ़ाता है - यदि इससे जुड़े उपकरणों में से एक रीसेट हो गया है, और हब संरचना के लिए आवंटित मेमोरी को मुक्त करता है।

आगे क्या है?

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


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

श्रृंखला के सभी लेख

भाग 1: सामान्य रूपरेखा
भाग 2: मेजबान नियंत्रकों के साथ काम करने की मूल बातें
भाग 3: होस्ट कंट्रोलर सपोर्ट कोड
भाग 4: चैनल समर्थन स्तर
भाग 5: तार्किक उपकरण स्तर
भाग 6: हब ड्राइवर