होममेड USB डिवाइस के लिए ड्राइवर लिखना

इस लेख का उद्देश्य USB के माध्यम से कंप्यूटर के साथ घर में बने डिवाइस के संचार को व्यवस्थित करने के लिए आवश्यक सॉफ्टवेयर के पूरे सेट की विकास प्रक्रिया का एक कदम-दर-चरण प्रदर्शन है।

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

चूंकि हमें USB डिवाइस ड्राइवर लिखने की प्रक्रिया को प्रदर्शित करने के लिए डिवाइस की आवश्यकता होती है, इसलिए हम रूस में उपलब्ध आम डिबग बोर्डों में से एक का चयन करेंगे। मेरे पास OLIMEX मॉडल LPC-P2148 द्वारा निर्मित यह बोर्ड है। बोर्ड का आधार ARM7TDMI आर्किटेक्चर का NXP माइक्रोकंट्रोलर LPC2148 आर्किटेक्चर है। बोर्ड की सभी जानकारी निम्न लिंक पर निर्माता की वेबसाइट पर प्राप्त की जा सकती है । इस तरह वह दिखती है।



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

समझने में आसानी के लिए, हम मंच पर आगे की कार्रवाई को विभाजित करेंगे और क्रम में उनके माध्यम से जाएंगे।

1. यह सुनिश्चित करने के लिए कि बोर्ड काम कर रहा है और USB चैनल भी काम कर रहा है, हमारे बोर्ड के लिए USB डिवाइस के तैयार उदाहरण को अपनाना। यह हमारे शुरुआती बिंदु जैसा होगा।
2. बोर्ड के फर्मवेयर को बदलना ताकि यह विंडोज के लिए एक अज्ञात डिवाइस बन जाए जिसे निर्माता के ड्राइवर की आवश्यकता होती है।
3. एक बुनियादी टेम्पलेट, एक खाली ड्राइवर को अपनाना, ताकि विंडोज हमारे डिवाइस को सेवा देने के लिए इसे सही ढंग से स्थापित कर सके।
4. उपयोगकर्ता अनुप्रयोग के साथ चालक बातचीत का कार्यान्वयन।
5. हमारे ड्राइवर के साथ काम करने के लिए एक विंडोज कंसोल एप्लिकेशन लिखना, और इसलिए कनेक्टेड यूएसबी डिवाइस।
6. पूरे सिस्टम को आवश्यक कार्यों के साथ भरना।

इस लेख में क्या नहीं होगा। मैं ओएस के ऑपरेटिंग तंत्र का वर्णन नहीं करूंगा जो मुझे सही ड्राइवर खोजने और स्थापित करने की अनुमति देता है। KEIL वातावरण में फर्मवेयर का निर्माण करने का कोई विवरण नहीं होगा। यूएसबी डिस्क्रिप्टर के मापदंडों का कोई विवरण नहीं होगा और आम तौर पर फर्मवेयर कैसे काम करता है, इसके बारे में कुछ नहीं कहा जाएगा। अंत में, मैं जानकारी के सभी स्रोतों, मेरे स्रोत कोड और एकत्रित बायनेरिज़ के लिंक प्रदान करूँगा। इस प्रकार, इस लेख द्वारा कवर नहीं किए गए किसी भी क्षण का विवरण संकेतित स्रोतों पर आसानी से पाया जा सकता है। सही ढंग से समझें, इन सभी विषयों पर एक लेख में विस्तृत जानकारी देना अवास्तविक है। इसके अलावा, अधिक सक्षम स्रोत हैं।

1. OLIMEX LPC-P2148 बोर्ड में RTX_Memory उदाहरण को अपनाना

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

परियोजना ARM \ Boards \ Keil \ MCB2140 \ RL \ USB \ फ़ोल्डर में स्थित है। इसके बाद के रास्ते मैं उस मुख्य फ़ोल्डर के सापेक्ष इंगित करूँगा जहाँ KEIL वातावरण स्थापित है।

हम परियोजना को एक अलग स्थान पर कॉपी करते हैं, इसे KEIL पर अपलोड करते हैं और इसे इकट्ठा करते हैं। त्रुटियों के बिना एक साथ मिलना चाहिए। नतीजतन, हमें एक हेक्स फ़ाइल मिली जिसे हम फ्लैशमैजिक उपयोगिता का उपयोग करके फ्लैश कर सकते हैं।
सच है, आप इसे अभी तक फ्लैश नहीं कर सकते हैं, क्योंकि यह स्पष्ट है कि यह हमारे बोर्ड पर काम नहीं करेगा।
यदि हम अपने बोर्ड और उस बोर्ड के सर्किट की तुलना करते हैं जिसके लिए एक उदाहरण लिखा गया था, और यह KEIL मॉडल MCB2140 है, तो हम D + लाइन के सस्पेंडर के कनेक्शन में अंतर देख सकते हैं।
MCB2140 पर, इसे हमेशा 3.3V तक खींचा जाता है, और LPC-P2148 पर, इस पुल-अप को एक ट्रांजिस्टर के माध्यम से एक माइक्रोकंट्रोलर द्वारा नियंत्रित किया जाता है।

दोनों बोर्ड के स्कैमेटिक्स क्रमशः www.olimex.com और www.keil.com पर उपलब्ध हैं।

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

इसके अलावा, हमारे बोर्ड में MCB2140 की तुलना में कम एल ई डी हैं। इसलिए, उनके उद्देश्य को भी नए सिरे से परिभाषित करने की आवश्यकता है। इस बिंदु पर, मैंने उन्हें केवल पढ़ने / लिखने की प्रक्रियाओं को इंगित करने के लिए पुन: असाइन किया।
चूंकि हमारे पास LED_CFG और LED_SUSP संकेतक नहीं हैं, हम प्रोजेक्ट कोड के अनुसार हर जगह उनके उपयोग की टिप्पणी करते हैं।
अब आप प्रोजेक्ट को इकट्ठा कर सकते हैं और इसे कंट्रोलर में फ्लैश कर सकते हैं। बोर्ड को कंप्यूटर से जोड़ने से, यह स्पष्ट है कि यह इसे एक बाहरी ड्राइव के रूप में पहचानता है और सिस्टम में एक और डिस्क दिखाई देती है जो आकार में केवल लगभग 25KB होती है और readme.txt फ़ाइल के साथ होती है।

इस बिंदु पर, पहले चरण को पूरा माना जा सकता है।

2. USB ड्राइव से एक अद्वितीय डिवाइस में संक्रमण।

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

यदि आप usbdesc.c फ़ाइल खोलते हैं और इस पैरामीटर को वहां पाते हैं, तो आप देखेंगे कि इसका मान USB_DEVICE_CLASS_STORAGE है।

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

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

3. एक मूल चालक बनाएँ।

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

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

आरंभ करने के लिए, आपको Microsoft वेबसाइट से ड्राइवर विकास किट डाउनलोड करना होगा। इसे विंडोज ड्राइवर किट कहा जाता है। मैं WDK संस्करण 7600.16385.1 का उपयोग कर रहा हूं।

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

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

मैं Windows XP से x86 चेक्ड बिल्ड पर्यावरण का उपयोग करना जारी रखूंगा। यह मुझे एक सार्वभौमिक ड्राइवर देगा जो विंडोज एक्सपी और नए से सिस्टम पर सही ढंग से काम करता है।

अब आइए एक ऐसे टेम्पलेट की तलाश करें जिसके साथ शुरू करना सबसे सुविधाजनक होगा।

सबसे उपयुक्त उम्मीदवार एक निश्चित OSR USB-FX2 लर्निंग किट के लिए एक उदाहरण था। यह किस तरह का बोर्ड है, मुझे पूरी तरह से पता नहीं है, लेकिन हमें जिस उदाहरण की आवश्यकता है वह WDK में पथ src \ usb \ osrusbfx2 \ के साथ है। सबसे दिलचस्प बात यह है कि यह केवल एक उदाहरण नहीं है, बल्कि इस बोर्ड के लिए एक ड्राइवर बनाने के लिए एक कदम-दर-चरण ट्यूटोरियल है। बस हमें जो चाहिए। चलो kmdf \ sys निर्देशिका में गहराई से जाते हैं और देखते हैं कि सभी चरण हैं और डैडीज़ में हैं। आप osrusbfx2.htm फ़ाइल में स्थित उदाहरण विवरण में उनके बारे में अधिक पढ़ सकते हैं।

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

हम पहले चरण से शुरू करते हैं। "X86 चेक्ड बिल्ड एनवायरनमेंट" लॉन्च करें और WinDDK \ 7600.16385.1 \ src \ usb \ osrusbfx2 \ kmdf \ sys \ step1 \ फ़ोल्डर में जाने के लिए "cd" कमांड का उपयोग करें।

बिल्ड -ceZ कमांड चलाएँ।

बिल्ड प्रक्रिया होती है, और परिणामस्वरूप, objchk_wxp_x86 फ़ोल्डर बनाया जाता है (इसका नाम चयनित वातावरण पर निर्भर करता है), जहां हम फ़ाइल को sys एक्सटेंशन के साथ पाते हैं। यह हमारा ड्राइवर है। इसे स्थापित करने के लिए, हमें एक INF फ़ाइल की आवश्यकता है। इसे उसी प्रोजेक्ट के अंतिम फ़ोल्डर में ढूंढें। इसे osrusbfx2.inf कहा जाता है। एकमात्र समस्या यह है कि यह उदाहरण के लिए बोर्ड के लिए डिज़ाइन किया गया है। हमारे बोर्ड के लिए ड्राइवर को स्थापित करने में सक्षम होने के लिए इस फ़ाइल के लिए, बस इसमें VID और PID मानों को उन सभी में बदलें, जो USB डिवाइस डिस्क्रिप्टर में usbdesc.c फ़ाइल में लिखे गए हैं। अपनी आंखों के साथ INF फ़ाइल के माध्यम से देखते हुए, आप देखेंगे कि WdfCoInstaller01009.dll फ़ाइल को अभी भी ड्राइवर स्थापित करने के लिए आवश्यक है। यह WDK की आपूर्ति में भी है।

इसलिए, हम तीन फ़ाइलों को एक अलग फ़ोल्डर में कॉपी करते हैं: इकट्ठे SYS, INF, WdfCoInstaller01009.dll।

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

हम ड्राइवर फ़ाइलों की प्रतिलिपि बनाने की सामान्य प्रक्रिया का निरीक्षण करते हैं और हमारा डिवाइस डिवाइस मैनेजर में नमूना डिवाइस वर्ग के अंतर्गत आता है। सब कुछ, ऑपरेटिंग सिस्टम संतुष्ट है!

और यहां एक सवाल उठ सकता है, लेकिन हमें कैसे पता चलेगा कि हमारा कोड निष्पादित हो रहा है। और दूसरे शब्दों में, मैं ड्राइवर से किसी तरह की प्रतिक्रिया प्राप्त करना चाहूंगा। यह सही है, चालक को डिबगिंग जानकारी जोड़ने का समय आ गया है ताकि यह समझ सकें कि क्या हो रहा है।

कर्नेल मोड में, KdPrint () फ़ंक्शन सूचना डिबगिंग जानकारी को आउटपुट करता है। इसका उपयोग प्रसिद्ध प्रिंटफ () के समान है। इसके आउटपुट को देखने के लिए, आपको प्रोग्राम DbgView को इंस्टॉल करना होगा। यह http://technet.microsoft.com/en-us/sysinternals/bb896647 पर Microsoft वेबसाइट पर उपलब्ध है। बस इसे चालू रखें और आप ओएस के कर्नेल मोड से सभी डिबगिंग जानकारी का आउटपुट देखेंगे। मैं आमतौर पर फ़िल्टर को कॉन्फ़िगर करता हूं ताकि केवल मेरे द्वारा आवश्यक मॉड्यूल के संदेश प्रदर्शित हों। Step_1 के मेरे संस्करण में, मैंने आउटपुट को DeviceEntry () और DeviceAdd () प्रक्रियाओं में जोड़ा ताकि यह केवल यह लिख सके कि किस फ़ंक्शन को कहा गया था। बोर्ड को कनेक्ट और डिस्कनेक्ट करके, DbgView विंडो में आप स्पष्ट रूप से देख सकते हैं कि यह किस क्रम में होता है।

4. कर्नेल और उपयोगकर्ता मोड के बीच सहभागिता।

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

हम रिकॉर्ड किए गए डेटा को सहेजेंगे ताकि बाद में हम उन्हें रीड ऑपरेशन के दौरान वापस दे सकें।

पहली बात यह है कि EvtDevicePrepareHardware इवेंट के लिए अपने कॉलबैक फ़ंक्शन को पंजीकृत करें, जिसे PnP प्रबंधक डिवाइस को D0 के अनइंस्टाल्यूटेड स्टेट में प्रवेश करने और ड्राइवर को उपलब्ध कराने से पहले कॉल करेगा। वास्तव में, इसका मतलब एक बहुत ही सरल बात है, हमने डिवाइस को अटका दिया, ड्राइवर ने बूट किया, लेकिन शायद आपके डिवाइस को इसके साथ काम करने से पहले कुछ कॉन्फ़िगरेशन की आवश्यकता होती है। हम इस आयोजन में इस तरह की ट्यूनिंग करेंगे। जैसा कि यूएसबी पर लागू होता है, कम से कम आपको वांछित कॉन्फ़िगरेशन का चयन करने की आवश्यकता होती है। इसलिए, हम अपने फ़ंक्शन को पंजीकृत करते हैं। ऐसा करने के लिए, DriverEntry में निम्न कोड जोड़ें:

WDF_PNPPOWER_EVENT_CALLBACKS_INIT(&pnpPowerCallbacks);
pnpPowerCallbacks.EvtDevicePrepareHardware = EvtDevicePrepareHardware;
WdfDeviceInitSetPnpPowerEventCallbacks(DeviceInit, &pnpPowerCallbacks);


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

इसलिए, हम एक संदर्भ संरचना बनाएंगे, और इसके साथ आरंभीकरण करेंगे, विशेषता पैरामीटर, WdfDeviceCreate के आगे पारित किया गया:

typedef struct _DEVICE_CONTEXT {
WDFUSBDEVICE UsbDevice;
WDFUSBINTERFACE UsbInterface;
WDFUSBPIPE BulkReadPipe;
WDFUSBPIPE BulkWritePipe;
} DEVICE_CONTEXT, *PDEVICE_CONTEXT;
WDF_DECLARE_CONTEXT_TYPE_WITH_NAME(DEVICE_CONTEXT, GetDeviceContext)

WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, DEVICE_CONTEXT);


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

DEFINE_GUID(GUID_DEVINTERFACE_OSRUSBFX2, // Generated using guidgen.exe
0x573e8c73, 0xcb4, 0x4471, 0xa1, 0xbf, 0xfa, 0xb2, 0x6c, 0x31, 0xd3, 0x84);
// {573E8C73-0CB4-4471-A1BF-FAB26C31D384}

status = WdfDeviceCreateDeviceInterface(device,
(LPGUID) &GUID_DEVINTERFACE_OSRUSBFX2,
NULL);// Reference String


आखिरी वाला। पहले पैराग्राफ में, हमने एक ऐसी प्रक्रिया पंजीकृत की जो EvtDevicePrepareHardware इवेंट को प्रोसेस करती है। अब आपको इसे लिखने की आवश्यकता है। मैं एक लेख में इसके पाठ को फिर से नहीं लिखूंगा, मुझे लगता है कि स्रोत कोड में देखना आसान होगा। मैं केवल यह कह सकता हूं कि इस प्रक्रिया में, हम कनेक्टेड डिवाइस के साथ ड्राइवर के बाद के संचालन के लिए आवश्यक सब कुछ तैयार करते हैं। विशेष रूप से, हम USB डिवाइस ऑब्जेक्ट बनाते हैं, वांछित कॉन्फ़िगरेशन का चयन करते हैं, और डिवाइस के संदर्भ में डिवाइस में लागू इंटरफ़ेस के BULK समापन बिंदु से संबंधित चैनल पहचानकर्ताओं को बचाते हैं। डेटा ट्रांसफर को लागू करने के लिए हमें बाद में इन पहचानकर्ताओं की आवश्यकता होगी। स्पष्टता के लिए, मैंने DbgView में चैनल पैरामीटर आउटपुट जोड़ा। आप देख सकते हैं कि उनके पैरामीटर समान मानों से अधिक कुछ नहीं हैं जो हमने फ़र्मवेयर के usbdesc.h फ़ाइल में समापन बिंदु वर्णनकर्ताओं में निर्दिष्ट किए हैं।
तो, अब आप ड्राइवर को फिर से बना सकते हैं, और इसे सिस्टम में अपडेट कर सकते हैं। फिलहाल, हमारा ड्राइवर अब केवल बूट नहीं कर सकता है। वह पहले से ही जानता है कि कनेक्टेड डिवाइस को कैसे कॉन्फ़िगर किया जाए, और, सबसे महत्वपूर्ण बात, उपयोगकर्ता मोड से कार्यक्रमों के लिए उपलब्ध हो गया है।


5. हम उपयोगकर्ता मोड से ड्राइवर के साथ काम करते हैं।

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

उपकरणों के साथ काम उन्हें नियमित फ़ाइल के रूप में खोलने, और सामान्य WriteFile और ReadFile प्रक्रियाओं का उपयोग करके डेटा लिखने और पढ़ने में किया जाता है। ड्राइवर के साथ बातचीत के आयोजन के लिए एक बहुत ही उपयोगी DeviceIoControl प्रक्रिया है, जो फ़ाइलों के साथ काम करने के प्रारूप से परे है, लेकिन हम इसका उपयोग नहीं करेंगे। फ़ाइल को सामान्य कॉल द्वारा CreateFile पर खोला जाता है, केवल हमें फ़ाइल नाम की आवश्यकता होती है। और यहां हमें एक GUID की आवश्यकता है, जिसे हमने ड्राइवर इंटरफ़ेस से जोड़ा है। मैं एक GUID के माध्यम से नाम प्राप्त करने के लिए पूरी प्रक्रिया का वर्णन नहीं करूंगा, और मैं ईमानदारी से मानता हूं कि मैंने इसे पूरी तरह से WDK उदाहरणों से लिया है। GetDevicePath प्रक्रिया एक GUID प्राप्त करती है और इसके अनुरूप पूरा पथ लौटाती है।

फाइल खुली है। कुछ कॉल जोड़ें जो रिकॉर्ड करेगा और फ़ाइल से दस बाइट्स पढ़ेगा।

लेकिन वापस हमारे ड्राइवर के पास। उपयोगकर्ता कार्यक्रम में, हम पहले से ही ड्राइवर को लिखते हैं और उससे पढ़ते हैं, लेकिन ड्राइवर कोड को इसके बारे में कुछ भी नहीं पता है। स्थिति को ठीक करें।

यहाँ तर्क EvtDevicePrepareHardware के साथ जैसा है। हमें कॉलबैक फ़ंक्शंस को पंजीकृत करने की आवश्यकता है, जिसे तब कहा जाएगा जब ड्राइवर से पढ़ने या इसे लिखने की प्रक्रियाएं होती हैं। यह EvtDeviceAdd में किया जाता है। I / O कतार को इनिशियलाइज़ करना आवश्यक है, हमारे कॉलबैक फ़ंक्शंस पर पॉइंटर्स के साथ उसके फ़ील्ड्स भरें, और इसे डिवाइस ऑब्जेक्ट से अटैच करके बनाएं। आइए जाने:

WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&ioQueueConfig,
WdfIoQueueDispatchParallel);

ioQueueConfig.EvtIoRead = EvtIoRead;
ioQueueConfig.EvtIoWrite = EvtIoWrite;

status = WdfIoQueueCreate(device,
&ioQueueConfig,
WDF_NO_OBJECT_ATTRIBUTES,
WDF_NO_HANDLE);


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


6. चालक को उपयोगी बनाना।

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

चलो डेटा रिसेप्शन इवेंट के प्रसंस्करण में कोड को बदलते हैं ताकि यदि पहले प्राप्त बाइट 0x01 है, तो LED_1 चालू करें, और यदि यह 0x02 है, तो LED_2 चालू करें। और कब से डिवाइस पर लिखने के बाद, हम तुरंत इसे से 10 बाइट्स पढ़ते हैं, फिर हम इस कोड को भी जोड़ देंगे। कृपया ध्यान दें कि हम पैकेट को आने वाले पैकेट के प्रसंस्करण कार्यक्रम में संचरण के लिए भेजते हैं। यह USB मॉड्यूल की एक ऐसी विशेषता है। हमें उसे ट्रांसमिशन के लिए पहले से डेटा देने की जरूरत है ताकि वह IN लेन-देन कर सके। और स्पष्टता के लिए, हम दो अलग-अलग सरणियों को पारित करेंगे। MSC_BulkOut () की सामग्री इस प्रकार बदलें:

void MSC_BulkOut (void) {

BulkLen = USB_ReadEP(MSC_EP_OUT, BulkBuf);

LED_Off( LED_RD | LED_WR );
if( BulkBuf[ 0 ] == 0x01 )
{
USB_WriteEP( MSC_EP_IN, (unsigned char*)aBuff_1, sizeof( aBuff_1 ) );
LED_On( LED_RD );
}
else
if( BulkBuf[ 0 ] == 0x02 )
{
USB_WriteEP( MSC_EP_IN, (unsigned char*)aBuff_2, sizeof( aBuff_1 ) );
LED_On( LED_WR );
}
}


और MSC_BulkIn () प्रक्रिया में हम सभी कोड को टिप्पणी करते हैं, जिससे यह पूरी तरह से खाली हो जाता है।

स्क्रीनशॉट में देखे गए पूरे गुच्छा का परिणाम।
उसी समय, बोर्ड स्वयं दो एलईडी के साथ झपकाता है।


बस इतना ही। हमने फर्मवेयर और अपने स्वयं के यूएसबी डिवाइस के लिए एक पूर्ण ड्राइवर लिखा है। यदि आप 4k के ब्लॉक में स्थानांतरण शुरू करते हैं, तो आप 800 Kb / s की गति प्राप्त कर सकते हैं।
जैसा कि आप देख सकते हैं, ड्राइवर पाठ काफी सरल है और इसमें लगभग 250 लाइनें हैं।

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

स्रोत कोड के साथ पूरा संग्रह यहां डाउनलोड किया जा सकता है।
संग्रह में बिंदुओं द्वारा नामित फ़ोल्डर होते हैं, प्रत्येक में अंतिम परिणाम होता है, जिसे हमने संबंधित पैराग्राफ में प्राप्त किया।

मुझे उम्मीद है कि लेख "उल्लू को कैसे आकर्षित किया जाए" गाइड के विपरीत निकला, और कोई इसे उपयोगी पाएगा।