آموزش پروتکل usb

لوگوهای USB : در زیر انواع لوگو مربوط به سرعت های مختلف USB رو مشاهده میکنید، که برا بحث میکروکنترلرها، من ( تا تاریخ انتشار این مطلب ) فقط سرعت LS و FS نیازم هستش ( در حد همون LPC1768 )؛ این USB لوگو موگو زیاد داره، زیر این عکس، سورس تمام لوگو های USB با کیفیت بالا رو قرار میدم براتون، بعضی لوگو ها رو تو نت پیدا نکردم با کیفیت بالا، مجبور شدم دست به فوتوشاپ بشم که یکم دقت کنید متوجه میشید کدوماش حاصل خرابکاری های منه خخخخ؛ یه فایل PDF هم قرار میدم که از سایت usb.org با عنوان USB Logo Usage Guidelines قرار میدم که دوست داشتید میتویند دانلود کنید.

اختصارات مربوط به سرعت های USB :

1) LS = Low speed =سرعت پایین
2) FS = Full speed = سرعت بالا
3) HS = High speed = سرعت خیلی بالا
4) SS = SuperSpeed = سرعت سوپر
5) SSP = SuperSpeedPlus = سرعت سوپر پلاس

سرعت نسخه های مختلف USB : این بحث نسخه و سال انتشار هر نسخه و سرعتش داستان ماستان زیاد داره، به همین جدول زیر برا اطلاعات عمومی اکتفا کنید ^_^
توجه 2 : نسخه USB 3.2 با همین نام SSP و با سرعت 20Gbps در سال 2017 عرضه شده.

توجه 3 : این سرعت ها مقدار اسمی هستش، رسیدن به حداکثر سرعت به شونصدتا عامل وابسته هستش.

Differential signaling : خب، USB از روش differential جهت ارتباط استفاده میکند؛ که تا نسخه 2 USB برا این کار از 1 جفت پایه +D و -D ( که یکی قرینه دیگری هستش ) استفاده شده؛ که در نسخه 3 به بالا USB، غیر از این دو پایه فوق، از 1 جفت پایه Differential Transmitter و 1 جفت پایه Differential Receiver استفاده میکند؛ که خب حالا چرا از روش انتقال دیتا Differential جهت ارتباط استفاده شده خودش یه مطلب جدا هستش که باید ویژگی های این نوع انتقال داده رو بررسی کرد و ... منم زیاد اطلاعاتی ازش ندارم، یه سرچ کوچیک که کردم فهمیدم  که در حذف نویز خوب عمل میکنه؛ شما اگه دوست داشتید میتونید مطالب زیر رو بخونید :

1. Differential signaling
2. The Why and How of Differential Signaling
3. What Is Differential Signaling?
4. زوج های دیفرانسیلی چیست؟ و نحوه استفاده از آن ها در آلتیوم

Half Duplex : خب، USB یک پروتکول دوطرفه غیر همزمان هستش یعنی یا میتونی بفرستی یا میتونه بخونی، ولی این دو همزمان نمیتونن رخ بدن، لذا به پروتکول usb اصطلاح Half Duplex اطلاق میشه ( ولی پروتکول RS232 خودمون، Full Duplex هستش ولی خب سرعتش در مقابل سرعت USB یه چی تو مایه های سرعت دوچرخه به سرعت ماشین هستش ^_^ ---> سرعت USB بیشتره! )

Frame و MicroFrame چی هستند و کاربردشون چیه؟ : در پروتکول usb این دو واحد زمانی ایجاد شدن و مبنار کار transfer ها هستند ( مبنای زمان بندی تبادل اطلاعات / اصطلاحی تو این مایه ها؛ تو USB نمیتونی همینطوری اطلاعات رو یرخی پشت سر هم بدون هیچ محدودیت و قانونی ارسال کنی ^_^ اینجا برا خودش قانون داره خخخ )

در چه سرعتی استفاده میشه : در سرعت های LS و FS از Frame و در سرعت HS از MicroFrame استفاده میشه.

واحد زمانی : یک Frame حدود 1.000ms ± 500ns طول میکشد و یک MicroFrame حدود 125.0µs ± 62.5ns طول میکشه ( در هر 1ms یک Frame وجود داره / در هر 1ms هشت MicroFrame وجود داره )

پکیج SOF : پکیج SOF = Start of Frame در سرعت های LS/FS، اول هر Frame، یکبار ارسال میشه و در سرعت HS، اول هر MicroFrame، یکبار ارسال میشه؛ عکس های زیر گویای داستان هستند :

توجه : پکیج SOF حاوی شماره MicroFrame/Frame هستش.

این عکس رو تو نت پیدا کردم	این عکس هم تو دیتاشیت بود
	هر دو این عکس ها خوب بودن، لذا هردوشونو گزاشتم، هرچند که هردوشون یکسان هستند، روشون کلیک کنید و در اندازه اصلی ببینیدشون.

تعداد transfer در هر MicroFrame/Frame : در سرعت LS/FS که از Frame استفاده میشه، یک transfer در هر Frame وجود داره ولی در سرعت HS که از MicroFrame استفاده میکنه، این قابلیت وجود داره که تا سه transfer ( در مدهای isochronous یا interrupt ) در هر MicroFrame وجود داشته باشه!

نحوه ساخت ( ایجاد ) هر یک از MicroFrame/Frame ها : MicroFrame/Frame ها، توسط کنترل کننده های Host، از طریق ارسال پکیج SOF ایجاد میشوند.

توجه : همون طور که در عکس زیر مشاهده میکنید، در آخر هر فریم، یه دیتا با عنوان EOF = End of (micro)Frame ارسال میشه که پایان MicroFrame/Frame رو مشخص میکنه.

توجه : وقتی که Host Controller پکیج SOF رو تولید نمیکنه، میتونه به این دلیل باشه که به مد کاهش مصرف توان رفته ( power-reduced state )

خب اگه کارتون با میکروکنترلر ها هستش و تو پروژتون نیاز دارید که از usb استفاده کنید، یا در حال یادگیری پورت usb از ابتدا هستید ( مث من! ) یا در حال آموزش عملی پورت usb هستیش، شاید وجود دستگاهی برا عیب یابی و مانیتورینگ پورت usb واجب نباشه ولی قطعا بهتون خیلی کمک میکنه،دیدن اطلاعات رد و بدل شده، در صورت وجود مشکل، عیب یابیش و ...

نرم افزار ها : البته نرم افزارهایی تحت ویندوز دیدم که کارشون مانیتورینگ پورت usb ( نمایش اطلاعات رد و بدل شده ) هستش ولی تا جایی که من کار کردم، و دیدم، اصلا بدرد نمیخورن، و من به شخصه توصیه نمیکنم ازشون برا بحث مانیتورینگ استفاده کنید ( شاید هم نظر من اشتباه باشه و این نرم افزار ها خیلی هم عالی و ... باشن ولی خب من تجربم از کار کردن باهاشون رو گفتم ) ولی خب برا بحث دیدن "اطلاعات دستگاه" ( همون Descriptor های دستگاه، که کامپیوتر در مرحله راه اندازی دستگاه، اونا رو خونده ) خوب هستند؛ USBDeview و usbview مخصوص نمایش "اطلاعات دستگاه" هستند؛ USB Trace و USBlyzer علاوه بر نمایش "اطلاعات دستگاه" مانیتورینگ هم میکنند مثلا!؛ در زیر این 4 تا نرم افزار تحت ویندوز رو برا دانلود قرار میدم :

توجه : نسخه جدید این نرم افزار های فوق رو میتونید تو نت پیدا کنید، یا مخصوص سیستم عامل های دیگه و...

usbview و USBDeview که گفتم چی کارشون، بین این دو من خودم usbview رو ترجیح میدم، خوبی این نرم افزار پرتابل بودنشه، وگرنه USBlyzer و USB Trace "اطلاعات دستگاه" رو خیلی بهتر از usbview نشون میدن، نمونه دیتای خروجی این 4 تا نرم افزار رو در این فایل قرار دادم ( که دیتای مربوط به میکروکنترلر lpc1768 در راه اندازی کلاس CDC برا بحث VIRTUAL UART هستش ) : (USB Serial Device (COM6

همونطور که در فایل بالا میبینید، نرم افزار usbview توضیحات کلاس CDC رو شناسایی نکرده و نوشته Unknown Descriptor، که اصلا خوب نیست؛ این مشکل در  USBlyzer و USB Trace فک کنم وجود نداشت.

نرم افزار USBlyzer برا بحث مانیتورینگ USB، برا کلاس CDC که مشکل داره، من نتونستم تست بگیرم در حالت عادی!؛ ولی خب با USB Trace مشکلی نداشتم، ولی این نرم افزار هم خداییش برا من که اصلا مفید نبود - فقط نوع انتقال رو نشون میده - شماره Endpoint - جهت انتقال اطلاعات و تمام - و این موارد اصلا بکار من نمیاد! ( عکس زیر ) مشکل بزرگتری هم که تو اینجور نرم افزار ها هستش اینه که نمیشه اطلاعات مد کنترل رو ردگیری و تحلیل کرد.

در کل فقط ازشون برا نمایش "اطلاعات دستگاه" استفاده کنید ولاغیر.

توجه : اصل داستان اینه که این نرم افزار هایی که در بالا گفتم، اطلاعات رو در سطح Transfer نشون میدن و سخت افزار هایی که در زیر میگم، اطلاعات رو در سطح بیت!!!

سخت افزار ها ( که نرم افزار مختص خودشون رو هم دارن ) : خب بریم سراغ مدارها و دستگاه های مخصوص این کار ( برا بحث مانیتورینگ پورت usb )؛ چیزی که من دارم USB Logic 100MHz 16Ch هستش که سایت سازندش باید این باشه saleae؛ ولی خب این نسخه رو من پیدا نکرد تو قسمت محصولات این سایت، ممکنه از رده خارج باشه یا هر دلیل دیگه ای که مهم نیست! چندین نوع مختلف پروتکول ها رو پشتیبانی میکنه، از I2C , UART, SPI و... گرفته تا همین USB که ما باهاش کار داریم :

توجه : الان پشتیبانی سایت saleae جواب داد که این محصول ما نیست و یه نسخه غیر قانونی هستش که بدون مجوز از نام و نرم افزار ما استفاده میکنه  واقعا جای تاسف داره که بعضی فروشگاه های داخلی میرن همچین نسخه هایی رو میخرن و میارن برا فروشن ( چون ک یکم ارزون تره ! ) ---> الان که دوباره فروشگاه saleae قسمت محصولاتش رو دیدم، یه لاجیک 8 کاناله 100میگ سمپل داشت با قیمت 400 دلار ( به دلار 10 تومن میشه 4 میلیون ) در حالی که قیمت لاجیک عکس زیر فک کنم 40-50 دلار باشه ( 400 - 500 هزار تومن ) - تازه 16 کانال هم هستش - الان که فک میکنم، دم فروشگاه های داخلی گرم که این نسخه ارزان قیمت و در حد عالی کپی شده رو وارد کردن. خخخ

توجه : من با دستگاه های دیگه کار نکردم، نمیتونم بگم کدومشون بهترین هستن و یا مشکلات هر کدوم چی هستند، فلذا اگه میخواید یکی از این دستگاه ها رو بخرید، مدلی رو که میخواید بخرید، رو باید از کسی نظر بخواید که قبلا خریده و باهاش کار کرده، مثلا همینی که در بالا میبینی رو من دارم و باهاش کار هم کردم، چیز خوبیه، تنها مشکلش اینه که بر بحث مانیتورینگ پورت usb ییش یکم سخته وقتی مثلا بخوای 10-20 ثانیه اطلاعت رو با سرعت 50 مگا سپمل ذخیره کنی میشه چیزی حدود 2 میلیون نمونه، که بررسیش یکم سخته با این نوع خروجی که نرم افزار لاجیک آنالایزر فوق میده، هر چند که من خودم به سازندش ایمیل زدم و امیدوارم این مورد رو در نسخه های بعدی رفع کنند ولی خب... ( یعنی میخوام بگم که در نسخه های بعدی نرم افزارش که هر چند وقت یکبار بروز میکننش، ممکنه رفع بشه - البته خداییش دم تیم پشتیبانیشون گرم، حداقل جواب آدمو میدن، به بعضیاشون که ایمیل میزنی .... )

اینم یه عکس از محیط این نرم افزار، که 1 ثانیه اطلاعات پورت usb رو مانیتور کردم، در شکل زیر؛ وسط صفحه، بیت های پکیج SOF رو میبینید، در سمت راست هم فیلد ها رو میبینید. ( میبینید که دو کانال Channel1 و Channel2 قرینه همدیگه هستند که ایندو اطلاعات پایه های +D و -D هستند که در بخش "تکنیک انتقال داده در پروتکول USB" در این باره صحبت کردیم )

حالا باز میتونید، این اطلاعات رو در فایل اکسل خروجی بگیرید، میتونید تنظیم کنید اطلاعات ستون سمت راست در سطح سگنال ( K و J ) باشه، در سطح بایت باشه و یا در سطح فیلد باشه.

که میتونید اطلاعات توی اون ستون سمت راست رو هم در اکسل خروجی بگیرید که یه چی ساده بتون میده مث این ( که مشکل اصلی من با این نرم افزار همینه، باید اطلاعات رو زیباتر و مرتب نشون بده، و مشکل دیگه ای که من با این نرم افزار داریم اینه که در شکل بالا، ستون سمت راست، اطلاعات رو بر حسب پکیج و انتقال نشون نمیده ) :

اینم ویرایش من هستش ( چون نیاز داشتم که مث آدم بشینم و راحت تجزیه تحلیل کنم، لذا یکم نقاشی/خوشگل کردم فایل اکسل خروجی نرم افزار فوق رو که خب اینکار زمانبر هستش، مخصوصا زمانی که تعداد نمونه ها یکم زیاد میشه! توقع دارم که اینکارو خود نرم افزار انجام بده و نه من؛ توجه کنید که دیتای این دو عکس متفاوت هستند، عکس بالا رو همین الان تهیه کردم، عکس زیر مربوط به هفته پیشه! )

از ستون چپ به راست : زمان، فیلد ها، ترنزکشن، پکیج

در ستون دوم، اونایی که رنگشون آبی هستش یعنی میزبان به دستگاه فرستاده، و اون قرمزا هم یعنی دستگاه به میزبان فرستاده ( حالا پیدا کن رنگ قرمزو توی عکس خخخخ )

اینی که در زیر میبنید برا مطلب آموزش کلاس CDC و Virtual RS232 تهیه کرده بودم، دیدیم اینجا نیازه، گفتیم اینجا هم بزاریم 

توجه : تو این مطلب بیشتر از این نمیتونم توضیح بدم، چه برسه به لیست کردم انواع مدل لاجیک، و بررسیشون!!؛ لطف میکنید میرید سرچ میکنید

در هنگام خرید یک دستگاه Logic Analyzer مختص مانیتورینگ پورت USB به چه مواردی باید دقت کرد؟

0) USB Decoder : بررسی کنید که از پروتکل USB پشتیبانی کنه حتما.

1) چه سرعت هایی از USB رو پشتیانی میکنه : مثلا دستگاه من فقط سرعت Low-Speed و Full-Speed رو پشتیبانی میکنه فذا اگه یه موقع بخوام از High-Speed استفاده کنم بکارم نمیاد!

2) تعداد کانال : حداقل 2 کاناله باید باشه!

3) حداقل Sample Rate : خب این مورد بستگی به سرعت پروتکول USB داره، سرعت FS برابر 12Mbps هستش ( Mbps = Mega bit per second) فلذا تقریبا باید با سرعت 25MSps بخونیمش ( MSps = Mega Sample per second )؛ سرعت HS هم 480Mbps هستش فلذا تقریبا باید با سرعت 1GSps بخونیمش ( GSps = Giga Sample per second ) و... ( نمیدونم حس میکنم خیلی بد و به روش اشتباهی توضیح دادم )

توجه : اگه فرکانس داده مدنظر 1Mhz باشه، باید با سرعت 2Mhz بخونیمش ( اینو چند جا خوندم ولی دلیل علمی براش ندارم ! )

4) رنج ولتاژ ورودی : ؟؟؟؟؟؟

5) نرم افزار : باید اینو برید تو نت سرچ کنید که ببینید نرم افزارش چطوری هستش، دانلودش کنید، فیلم هایی ازش ببینید، سرعت تجزیه و تحلیل اطلاعاتش چقدر طول میکشه ( مثلا دستگاه خودم، اگه 10-20 ثانیه نمونه برداری کنه با سرعت 50 میگ، حدود 2 میلیون نمونه میگیره و حدود 5 دقیقه پردازش اطلاعاتش طول میکشه )، میشه ازش خروجی اکسل گرفت؟ چه فرمت های خروجی دیگه ای داره؟ نمایش اطلاعاتش به چه صورته؛ اطلاعات رو به چه صورت ذخیره میکنه؟ اطلاعات رو در چه سطح هایی نشون میده ( در سطح سیگنال/بیت/بایت/فیلد/پکیج/ترنسفر/انتقال )

معرفی یه آنالیزر خفن : تو نت میگشتم این آنالیزر رو دیدم که سرعت های LS / FS / HS / SS رو پشتیبانی میکنه، با نام  :

Beagle USB 5000 v2 SuperSpeed Protocol Analyzer - Ultimate Edition

که 75 دلار هستش ( با دلار 10 تومن حساب کنی میشه 750 تومن تقریبا )، البته باید نرم افزارشو هم بررسی کرد ( سخت افزار خوب باشه و امکانات زیادی داشته باشه ولی نرم افزار مزخرف باشه، بدرد نمیخوره )

کدنویسی : این که در چه سطحی از این مواردی که گفتم بخواید کار کنید بستگی به آیسی و مدارتون داره، مثلا اگه از میکرو LPC1768 بخواین استفاده کنید، شما در سطح Packet ها باید کدنویسی کنید، یا اگه میخواید با میکرو Mega16 این پروتکول رو راه بندازید، باید در سطح J و K کد نویسی کنید ( که داستانای خودشو داره و من از مطالب مربوط بهش، در این مطلب صرف نظر کردم )

وضعیت های باس ( پایه های +D و -D ) : در زیر فقط با مورد 1و2 کار داریم، توضیح کامل این 4 تا مطلب خودش چندتا مطلب میشه!!!

1) پایه +D صفر منطقی و -D یک  منطقی باشد ( دیفرانسلی 0 )
2) پایه +D یک  منطقی و -D صفر منطقی باشد ( دیفرانسلی 1 )
3) هر دو پایه، 1 منطقی باشند ( SE1 )
4) هر دو پایه، 0 منطقی باشند ( SE0 )

توجه : در ادامه مطلب، برای سادگی، به وضعیت پایه -D کاری نداریم دیگه ( چون وقتی وضعیت +D رو بگم، -D میشه معکوسش، D+ یک باشه، -D صفر میشه و بلعکس )؛ برای مثال هر قسمت، یک پکیج SOF رو به همون روش، اطلاعاتش رو نشون میدم. ( عکس ها مربوط به سرعت FS و پایه +D هستند )

1) (J & K State (bit : در دیتاشیت به جای استفاده از اصطلاح bit از "وضعیت J" و "وضعیت K" استفاده کرده که برا سادگی در فهم نحوه عملکرد اینکارو کرده ( وگرنه این دو وضعیت همون بیت 0 و 1 خودمون هستند، فقط اسمشون رو تغییر دادیم - همین )

طبق جدول بالا، میبینید که مقدا "وضعیت J" و "وضعیت K" در سرعت های مختلف، متفاومت هستش؛ نمونه نمایش اطلاعات به کمک ایندو وضعیت به صورت زیر هستش :

2) Byte : مجموعه ای از وضعیت های J و K، بایت ها رو تشکیل میدن.

3) Field : مجموعه ای از بایت ها رو میگن فیلد، حالا یه فیلد ممکنه 1 بایت باشه، یه فیلد 10 بایت

( در زیر نوشته فریم شماره 1869 که مقدار باینری 1869 میشه ‭011101001101‬ این مقدار رو در شکل میبینید؛ فیلد CRC این اینجا 5 بیتی هستش، و همون طور که میبینید مقدارش 4 هستش که به باینری میشه 00100 یه CRC دیگه هم داریم که اون 16 بیتی هستش )

4) Packet : مجموعه ای از فیلد ها، پکیج رو ایجاد میکنند ( در شکل بالا، به کل این مجموعه میگن : پکیج SOF )

5) Transaction : هر Transaction ( معامله ) از چند پکیج تشکیل شد.

6) Transfer : هر Transfer ( انتقال ) از چند Transaction تشکیل شده.

7) micro)Frame) : در هر فریم ( هر فریم 1ms هستش ) یک Transfer ارسال/دریافت میشه؛ در هر میکرو فریم ( هر میکرو فریم 125us هستش )، 1 الی 3 تا Transfer ارسال/دریافت میشه.

بعضی میکرو ها این قابلیت رو دارن خودشون، مثل LPC1768 که محصول NXP هستش یا مثل ATmega32U2 که محصول ATMEL هستش. ( هر دو موردی که گفتم تا سرعت FS پشتیبانی میکنند )؛ خب اگه میکرویی پروتکول USB رو پشتیبانی کرد که میرید دیتاشیتش رو میخونید و ... راش میندازدید و اگه پشتیبانی نکرد میرید دیتاشیت USB رو میخونید و در سطح J و K براش کد میزنید.

سوال : حداقل فرکانس میکرو چقدر باید باشه تا بتونه USB رو راه بندازه؟

جواب :  جوابـــــــــــــــــــــــ

endpoint ( نقطه پایانی، مختصرا EP بهش میگن ) : بافری که توانایی ذخیره کردن چندیدن بایت رو داره؛ داده هایی که در endpoint نوشته می شود، یا اطلاعات دریافتی است و یا اطلاعاتی است که می خواهیم انتقال دهیم؛ برا هر endpoint دو تا بافر داریم ( یه بافر برا اطلاعات دریافت شده و یکی هم برا اطلاعاتی که قراره ارسال بشه )؛ حالا یه دستگاهی ممکنه مث عکس زیر 3 تا endpoint داشته باشه یکی مث این میکروکنترلر lpc1768 حدود 16 تا

توجه : هر endpoint فقط میتونید یکی از بافراش رو فعال و استفاده کنید، یا بافر ورودی یا خرجی، هر دو نمیشه ولی برای Controll Endpoint ها همچن محدودیتی وجود نداره و از هر دو بافر ورودی/خروجی میشه فعال کردشون و استفاده کرد. ( که این موضوع در عکس زیر هم مشهود هستش )

endpoints vs pipe : تصویر زیر فک کنم گویای همه چیز باشه، به صورت خلاصه بگم : endpoint رو که میدونید چیه، pipe میتونه حداقل شامل 1 یا 2 تا endpoint باشه.

توجه : تا جایی که من میدونم هر endpoint منطقی غیر کنترلی فقط میتونه در یکی از نقش های ورودی یا خروجی باشه ولی چیزی که در شکل زیر میبینم دقیقا عکس این مورد هستش، مثلا یه pipe میتونه حاوی interrupt in ep1 و interrupt out ep2 باشه؛ این چیزی بود که دیتاشیت میکروکنترلر lpc1768 گفته بود، بگذریم، در هر صورت فعلا زیاد مهم نی.

هر دستگاه USB فقط یک Standard Device Descriptor داره؛ اگه دستگاه از سرعت FS و HS هم پشتیبانی کنه که از توضیح دهنده "Device Qualifier Descriptor" هم باید استفاده کنیم.

2) bcdUSB : این فیلد حاوی شماره نسخه با فرمت BCD هستش، که به فرم 0xJJMN هستش ( JJ : شماره نسخه اصلی، M : شماره نسخه جزئی، N : شماره نسخه زیر-جزئی )؛ برای مثال نسخه 2.1.3 به فرم 0x0213 به فیلد فوق داده میشه و یا نسخه 2.0 به فرم 0x0200 به فیلد فوق داده میشه. ( چیزی که فهمیدم باید نسخه USB باشه، اما چطور متوجه مدل دقیقش بشیم؟ )

7) bMaxPacketSize0 : حداکثر اندازه پکیج Endpoint0 ( که در جدول مربوط به مقایسه انواع مدهای ارتباطی، مقدار پکیج داده در مد کنترل رو برا سرعت های مختلف ذکر کردم )

17) bNumConfigurations : این فیلد حاوی تعداد Configuration های قابل پشتیبانی توسط دستگاه هستش ( البته در سرعت تعیین شده فعلی دستگاه )، لذا Configuration های مربوط به سرعت های دیگه، در شمارش تعداد Configuration ها لحاظ نمیشن.

بقیه موارد رو نفهمیدم

در قسمت توضح دهنده "Device Descriptor" دیدیم که یک فیلد با نام bNumConfigurations داریم که حداکثر تعداد Configuration ها رو تعیین میکرد؛ حالا به کمک توضیح دهنده "Configuration Descriptor" میایم این Configuration ها رو تعریف میکنیم.

هر یک از Configuration Descriptor ها، مختص یک Configuration خاص هستش که دربارش اطلاعاتی رو ارائه میده.

هر Configuration Descriptor حاوی 1 یا چند Interface هستش و هر Intercace هم حاوی 0 یا چند Endpoint.

هر Interface ممکنه مستقل عمل کنه، برای مثال، یک دستگاه ISDN میتونه با دو Interface پیکربندی بشه، که هر کدام، یک کانال دوطرفه 64Kb/s فراهم میکنند که منابع دیتا مجزا از هم دارند یا sinks on the host؛ پیکربندی های دیگه دستگاه ISDN ممکنه حظور داشته باشند در یک Interface، ترکیب دو کانال در یک کانال 128Kb/s دوطرفه. ( اصلاح توضیحات )

توجه : برا ارتباط دوطرفه در یک Interface باید حداقل 2 تا Logical Endpoint تعریف کرد که یکی در مد دریافت و یکی در مد ارسال اطلاعات باشه تا بشه گفت که Interface مدنظر به صورت دوطرفه تبادل داده انجام میده.

یک Endpoint رو نمیشه بین چندین Interface با یک Configuration یکسان به اشتراک گزاشت، مگر اینکه Endpoint توسط تنظیمات متناوب همان Interface استفاده شود ( نفهمیدم ) ولی Endpoint ها میتونن بین چندین Interface که Configuration یکسانی ندارند، بدون محدودیت به اشتراک گزاشته بشن.

3) wTotalLength : مجموع طول تمام Interface ها و Endpoint هاش، کلاس ها و یا vendor-specific که مربوط به Configuration فعلی هستند. ( معمولا وقتی میزبان درخواست خوندن Configuration Descriptor رو ارسال میکنه، دستگاه باید این مواردی که الان گفتیم رو ارسال کنه که طول همه اینا داخل این فیلد ذخیره میشه )

توجه : عکس زیر گویای همه چیز هستش :

4) bNumInterfaces : تعیین تعداد Interface های پشتیبانی شده توسط این Configuration ( حالا Interface چی هستش؟ )

5) bConfigurationValue : برا این که Configuration ها از همدیگه مجزا و قابل شناسایی بشن باید شماره بندی بشن، که این کار رو به کمک همین فیلد bConfigurationValue انجام میدیم. ( حالا شمارش از 0 شروع میشه یا 1 ؟ )

6) iConfiguration : آدرس موقعیت string مربوط به توضیح این Configuration رو در این فیلد قرار میدیم؛ این مورد اختیاری هستش و اگه نمیخواین باید مقدار 0 قرار بدین ( وگرنه باید موقعیت رشته مدنظر رو قرار بدید )، در ادامه مطلب و در قسمت "String Descriptor" این مبحث نحوه تعریف String و نحوه مقدار دهی فیلد هایی مثل همین iConfiguration  رو توضیح میدم. ( ایجاد یک رشته مخصوص توضیح Configuration چه سودی داره؟ )

7) bmAttributes :

• بیت 0 تا 4 رزرو شده هستش و باید 0 بنویسیم.
• بیت 5 با نام Remote Wakeup اگه دستگاه قراره از ویژگی Remote Wakeup پشتیبانی کنه، این بیت رو 1 میکنیم و گرنه 0 میکنیم.
• بیت 6 با نام Self-powered؛ اگه این بیت رو 1 کنیم، Self powered رو فعال کردیم.
• بیت 7 ام هم رزرو شده هستش که باید 1 بنویسیم.

توجه : برا بحث Remote Wakeup، مثلا برای کلاس CDC که گفتم یک کاربردش ساخت Virtual uart هستش، این ویژگی نمیتونه ویندوز10 رو وقتی به مد اسلیپ رفته رو بیدار کنه ولی Mouse میتونه اینکارو بکنه چون ویندوز10 این قابلیتو بهش داده، برا ویندوز های دیگه اطلاعاتی ندارم.

8) bMaxPower : حداکثر پاور مصرفی USB Device از bus در این Configuration زمانی که دستگاه به صورت کامل کار میکند، هر مقدار که در این فیلد قرار بدید ضربدر 2mA میشه، مثلا bMaxPower رو 50 بدید، یعنی 50*2 که میشه 100mA. ( که اسم این نوع تغذیه Bus Powered گفته میشه و هموراه فعال هستش )
سوال : این داستان Self powered و Bus Powered برا واحد USB میکروکنترلر به چه صورت میشه دقیقا؟ گیج شدم من.

سوال بعد : چرا باید این فیلد داخل این توضیح دهنده باشه؟ یعنی چی که هر Cofiguration مقدار جریان مصرفی متفاوتی داره آخه.

توجه : یک Configuration Descriptor گزارش میده که configuration فوق، bus-powered هستش یا self-powered؛ اگه دستگاه از منبع تغذیه خارجی خودش جدا بشه، میاد و وضعیت دستگاه رو بروزرسانی میکنه تا مشخص کنه که دستگاه دیگه در مد self-powered نیستش.

توجه : یه دستگاه وقتی که منبع تغذیه خارجیش قطع میشه ممکنه مقدار جریان مصرفیش از bus، از مقداری که قبلا تعیین کرده افزایش پیدا نکنه، که در این صورت به کارش ادامه میده ( وگرنه چی میشه؟ مثلا 100 میلی تعیین کرده و 200 تا میکشه - اون وقت چی میشه؟ )

Interface Descriptor درباره یک interface خاص در داخل یک configuration خاص توضیح میده؛ هر configuration حاوی 1 یا چند interface هستش و هر interface هم 0 یا چند endpoint داره.

درخواست SetDescriptor و یا GetDescriptor نمیتونن به صورت مستقیم به Interface Descriptor ها دسترسی داشته باشند.

یک interface میتونه شامل تنظیمات متفاوتی باشه که این اجازه رو به endpoint ها میده که ویژگی های آنها بعد از پیکربندی شدن دستگاه تغییر کنید. ( نفهمیدم )؛ مقدار پیشفرض alternate setting برای یک interface همیشه 0 هستش.

درخواست SetInterface جهت انتخاب یک alternate setting یا بردن به مقدار پیشفرض بکار میره.
درخواست GetInterface، مقدار alternate setting انتخاب شده رو برمیگردونه.

Alternate settings این اجازه رو میده که بخشی از device configuration تغییر کنه زمانی که دیگر interface ها در عملیات باقی میمانند ( نفهیمدم )؛ در یک configuration که alternate settings دارد برای یک یا چند interface، نیاز به Interface Descriptor های مجزا برای هر یک از تنظیمات مورد نیاز هستش ( بررسی ترجمه )

اگر پیکربندی device از یک interface با دو alternate setting پشتیبانی کنه، Configuration Descriptor به دنبال Interface Descriptor خواهد بود و فیلد bAlternateSetting و bAlternateSetting صفر تنظیم میشن و سپس Endpoint Descriptor ها میاد برای اون setting ( بررسی ترجمه )؛ Interface Descriptor دومی، فیلد bInterfaceNumber باید 0 تنظیم بشه اما فیلد bAlternateSetting باید 1 تنظیم بشه.

2) bInterfaceNumber : شماره این Interface برای Configuration فعلی، شماره بندی از 0 شروع میشه.

3) bAlternateSetting : درست متوجه نشدم.

4) bNumEndpoints : این فیلد بیانگر تعداد Endpoint های این Interface هستش ( به استثنای Endpoint0 )؛ اگه این فیلد 0 باشه، Interface فقط از Endpoint0 استفاده میکنه.

توجه : اگر یک Interface تنها از Endpoint0 استفاده کند، هیچ Endpoint Descriptor یی بعد از Interface Descriptor نمیاد؛ در این مورد، فیلد bNumEndpoints باید 0 تنظیم بشه؛ لذا در یک Interface Descriptor هیچگاه Endpoint0 در شمارش تعداد Endpoint ها لحاظ نمیشه.

8) iInterface : تعریف یک string که درباره این Interface توضح میده، در این فید میایم موقعیت string مد نظر رو قرار میدیم، اگه هم نیازی به string یی نداره که 0 قرار میدیم.

هر endpoint یی که در هر interface یی استفاده میشه، برای خودش descriptor یی داره؛ این descriptor حاوی اطلاعاتی هستش که مورد نیاز میزبان هستش جهت تعیین bandwidth هر endpoint؛ در هنگام استفاده از دستور GetDescriptor توسط میزبان، یک Endpoint Descriptor همیشه به عنوان جزئی از Configuration Descriptor ارسال میشه و به صورت مستقیم قابل دسترس نیستش توسط دستور های GetDescriptor و SetDescriptor؛ برای Endpoint0 هیچگاه Endpoint Descriptor تعریف نمیشه.

2) bEndpointAddress :

• بیت 0 تا 3 : شماره Endpoint
• بیت 4 تا 6 : رزرو شده و باید 0 نوشته بشن.
• بیت 7 جهت داده هستش که برای Endpoint0 مقدارش درنظر گرفته نمیشه، و برا Endpoint های دیگه به این صورت مقدار دهی میشه : 0=OUT endpoint و 1=IN endpoint

توجه : تو انتخاب شماره Endpoint دقت کنید، بعضی Endpoint ها برای یه مد خاصی هستند و بعضی دیگر برای مد دیگه ای، مثلا Endpoint0 کنترلی هستش؛ Endpoint1 از نوع interrupt و Endpoint2 از نوع bulk و .... لذا موقع مقدار دهی بیت 0 تا 3 فیلد bEndpointAddress، حواستون به این موضوع باشه. ( برای میکروکنترلر LPC1768 که اینطور هستش، برای دستگاه های دیگه رو نمیدونم )

3) bmAttributes :

• بیت 0 و 1 : تعیین مد انتقال.
• بیت 2 و 3 : تعیین نوع Synchronization ( یعنی چی؟ )
• بیت 4 و 5 : تعیین نوع استفاده ( نفهمیدم )
• بیت 6 و 7 : رزرو شده و باید 0 نوشته بشن.

توجه : بیت 2 تا 5 فقط برای مد Isochronous کاربرد دارند، فلذا اگه مد دیگه ای رو برا Endpoint مدنظر فعال کردید، بیت 2 تا 5 رو باید 0 بنویسید.

(bits 5..4=0x00) : این یک Data endpoint است ( انتقال طبیعی اطلاعات )
(bits 5..4=0x01) : برای انتقال اطلاعات بازخورد صریح برای یک یا چند endpoint داده ( بررسی ترجمه )
(bits 5..4=0x10) : این یک Data endpoint است که همچنین به عنوان endpoint بازخورد ضمنی برای یک یا چند Data endpoint عمل می کند ( بررسی ترجمه )

سوال : مگه isochronous خطایابی داره؟ پس داستان feedback چیه دیگه؟

یک feedback endpoint ( حالا صریح/explicit یا ضمنی/implicit ) نیاز داره که با یک ( یا چند ) isochronous data endpoint مرتبط بشه که در آن سرویس feedback ارائه میده ( بررسی ترجمه )؛ این ارتباط بر اساس تطابق شماره endpoint هستش؛ جهت feedback endpoint همیشه مخالف جهت data endpoint ( ها ) هستش؛ اگه یک feedback endpoint به چندین data endpoint سرویس ارائه میده، data endpoint ها باید به صورت صعودی مرتب بشن، اما الزاما شماره endpoint ها متوالی نیستند؛ اولین data endpoint و feedback endpoint باید شماره endpoint یکسانی داشته باشند ( و جهتی مخالف )؛ که این اطمینان رو میده که data endpoint میتونه به صورت منحصر به فرد feedback endpoint شو شناسایی کنه بوسیله جستجو برای اولین feedback endpoint یی که شماره endpoint اش برابر یا کمتر از شماره endpoint خود data endpoint باشه.

مثال : یه حالت فوق العاده رو درنظر بگیرید که نیاز به 5 گروه از OUT asynchronous isochronous endpoint ها هستش و در همان زمان 4 گروه از IN adaptive isochronous endpoint ها؛ هر گروه نیاز به feedback endpoint مجزایی داره، این دو گروه در شکل زیر نشان داده شده اند :

شماره endpoint ها میتونن در هم آمیخته بشن همانند شکل زیر :

نفهمیدم این دو تا شکل بالا رو ( توضیح بیشتر )

4) wMaxPacketSize : حداکثر اندازه packet مربوط به این endpoint که قادر به ارسال یا دریافت هستش وقتی این configuration انتخاب شده؛

For isochronous endpoints, this value is used to reserve the bus time in the schedule, required for the per-(micro)frame data payloads.
The pipe may, on an ongoing basis, actually use less bandwidth than that reserved.
The device reports, if necessary, the actual bandwidth used via its normal, non-USB defined mechanisms.

• بیت 0 تا 10 : تعیین حاکثر اندازه packet ( بر حسب بایت )؛ برای تمام Endpoint ها ( غیر از Endpoint0 )
• بیت 11 و 12 : تعیین تعداد transaction اضافی در هر microframe ( مخصوص endpoint های high-speed در مد isochronous و interrupt )
• بیت 13 تا 15 : رزرو شده و باید 0 نوشته بشن.

توجه 1 : در قسمت Standard Device Descriptor دیدیم که فیلدی با نام bMaxPacketSize0 وجود داره که حداکثر اندازه پکیج Endpoint0 رو تعیین میکرد؛ اما فیلد wMaxPacketSize در بالا ملاحظه میکنید، مخصوص تمام Endpoint ها ( غیر از Endpoint0 ) هستش ( گفتم بگم تا قاطی نکنید مث من یوقت، بگید این فیلد که قبلا تعریف شده بود، این با اون چه فرقی داره و از این جور سوالا )

توجه 2 : endpoint های interrupt و isochronous در سرعت High-speed از بیت 11 و 12 این فیلد استفاده میکنند.

6) bInterval : فاصله زمانی بین هر نمونه برداری انتقال داده ( بررسی ترجمه )؛

• برای isochronous endpoint ها در سرعت full-speed/high-speed، مقدار این فیلد باید بین 1 تا 16 باشه، که این مقدار در فرمول ​\( 2^{(bInterval-1)} \)​ استفاده میشه. ( به عنوان مثال، bInterval با مقدار 4 یعنی یک دوره زمانی 8 تایی - چیزی که فهمیدم )
• برای interrupt endpoint ها در سرعت low-speed/full-speed، مقدار این فیلد باید بین 1 تا 255 باشه.
• برای interrupt endpoint ها در سرعت high-speed، مقدار این فیلد باید بین 1 تا 16 باشه، که این مقدار در فرمول ​\( 2^{(bInterval-1)} \)​ استفاده میشه.
• برای control OUT endpoint ها و bulk endpoint در سرعت high-speed، مقدار این فیلد باید بین 1 تا 255 باشه؛ این فیلد حداکثر نرخ NAK مربوط به endpoint رو تعیین میکنه؛ مقدار 0 یعنی endpoint هیچ وقت NAK ارسال نمیکنه، مقادیر دیگه مشخص کننده این هستند که حداکثر یک NAK در هر تعداد bInterval بر حسب microframe ( بررسی ترجمه + نفهمیدم )
• برا bulk endpoint در سرعت full-speed و برا control endpoint در 3 سرعت low/full/high به چه صورت میشه پس؟

توجه : برای endpoint های bulk و control OUT، فیلد bInterval تنها برای هدف انطباق استفاده میشه؛ host controller نیازی نداره که تغییری در رفتارش ایجاد کنه برطبق مقدار این فیلد. ( یعنی چی؟ )

String descriptor ها اختیاری هستند؛ اگر device از String descriptor ها پشتیبانی نکنه، باید تمام فیلد های مربوط به index string ( که این فیلد ها در descriptor های device، configuration و interface وجود دارد / و descriptor های مربوط به کلاس و زیر کلاس ها ) رو 0 مقدار دهی بشه.

String descriptor ها از کدگزاری UNICODE به عنوان استاندارد، استفاده میکنند ( اسناد استاندارد UNICODE در سایت unicode.org موجود هستش )

string ها در USB device ممکنه از چندین زبان مختلف پشتیبانی کنند؛ وقتی از درخواست خوندن یک String Descriptor دریافت میشه، میزبان در یک فیلد با نام (language ID (LANGID که 6 بیت هستش، ID زبان مدنظرش رو تعیین میکنه که این موارد در سایت usb.org تعریف شده اند ( در کدوم فایل و صفحه این سایت تعریف شده نمیدونم | من چیزی پیدا نکردم )؛ اگه در درخواست خواندن String Descriptor، مقدار String index صفر بود، کد ( های ) LANGID مربوط به زبان ( های ) پشتیبانی شده توسط دستگاه رو ارسال میکنیم.

توجه : اون فایلی که گفتم رو من در سایت مایکروسافت پیدا کردم ( که امیدوارم همون باشه ) ولی من برا زبون فارسی نتونستم تو تست عملی جواب بگیرم : Language Identifier Constants and Strings

0) bLength : میدونم که میدونید کاربرد این فیلد چیه، برا محاسبه مقدار این فیلد میتونید از فرمول ​\( 2×N+2 \)​ استفاده کنید، که N تعداد زبان های پشتیبانی شده دستگاه ما هستش و چون هر فیلد wLANGID دو باید هستش، اومدم و در 2 ضربش کردم ( مثلا دستگاه ما از 3 زبان پشتیبانی میکنه، لذا طول توصیفگر STRING ما میشه ​\( 2×3+2 = 8 \)​ )

2 به بعد) wLANGID : خب در این فیلد لیست LANGID ( زبان های پشتیبانی شده توسط دستگاه ) رو قرار میدیم.

مثال : 

0x04, // bLength ( 8 )
DESCRIPTOR_STRING, // bDescriptorType
0x0409, // United States
0x0429, // Iran
0x041F // Turkey

برای تعریف string هامون از این Descriptor استفاده میکنیم.

The UNICODE string descriptor is not NULL-terminated.

توجه : ابتدا باید از String Descriptor استفاده کرد و زبان ( های ) پشتیبانی شده توسط دستگاه رو تعریف کرد، سپس بسراغ UNICODE String Descriptor رفته و string هامون رو تعریف کنیم.

مثال : یک مثال از نحوه استفاده از UNICODE String Descriptor به صورت زیر هستش ( مثلا Device ما نیاز به 3 تا string داره ) :

// ( string index = 1 )
0x0E, // bLength ( 14 )
DESCRIPTOR_STRING, // bDescriptorType
'L', 0, 'P', 0, 'C', 0, 'U', 0, 'S', 0, 'B', 0, // wLANGID

// ( string index = 2 )
0x14, // bLength ( 20 )
DESCRIPTOR_STRING, // bDescriptorType
'U', 0, 'S', 0, 'B', 0, 'S', 0, 'e', 0, 'r', 0, 'i', 0, 'a', 0, 'l', 0, // wLANGID

// ( string index = 3 )
0x12, // bLength ( 18 )
DESCRIPTOR_STRING, // bDescriptorType
'D', 0, 'E', 0, 'A', 0, 'D', 0, 'C', 0, '0', 0, 'D', 0, 'E', 0, // wLANGID

این درخواست، وضعیت گیرنده مشخص شده رو برمیگردونه.

توجه : اگه فیلد wValue صفر نباشه یا wLength دو نباشه، یا اگه فیلد wIndex ( برا حالتی که گیرنده رو Device تعیین کردیم ) مقدارش 0 نباشه، اونوقت رفتار دستگاه مشخص نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Get Status رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : اگه Inteface یا Endpoint یی غیر از Endpoint0 انتخاب شده باشه، دستگاه با یک Request Error پاسخ خواهد داد.

Configured state : اگه Inteface یا Endpoint یی که مشخص کردیم وجود نداشته باشد، دستگاه با یک Request Error پاسخ خواهد داد.

گیرنده Device : اگه به کمک دستور GetStatus، گیرنده Device رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :

فیلد Self_Powered بیانگر نوع تغذیه فعلی Device هستش :
D0 = 0 : دستگاه bus-powered هستش.
D0 = 1 : دستگاه self-powered هستش.
این فیلد ممکنه با استفاده از درخواست های ClearFeature و SetFeature هم تغییر نکنه!

فیلد Remote_Wakeup مشخص میکنه که آیا در حال حاظر ویژگی remote wakeup فعال هستش یا نه؛ پشتیبانی از ویژگی remote wakeup برای تمامی دستگاه ها به صورت پیشفرض غیر فعال هستش :
D1 = 0 : این ویژگی غیرفعال هستش.
D1 = 1 : این ویژگی فعال هستش.
این فیلد امکان اصلاح ( تغییر ) اش توسط درخواست های ClearFeature و SetFeature وجود داره ( تو این دوتا درخواست، فیلد wValue، باید مقدار DEVICE_REMOTE_WAKEUP رو بگیره، جداول 3-9 و 6-9 رو بررسی کنید ).
وقتی Device ریست میشه، این فیلد هم 0 میشه.

گیرنده Inteface : اگه به کمک دستور GetStatus، گیرنده Inteface رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :

خب همون طور که در شکل بالا میبینید، تمام بیت ها رزرو شده هستش، و در واقع فقط 0 میفرسته، لذا چیزی برای توضیح دادن وجود نداره خخخ.

گیرنده Endpoint : اگه به کمک دستور GetStatus، گیرنده Endpoint رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :

ویژگی Halt ( توقف ) برای تمام endpoint های interrupt و bulk نیاز هستش :
0 : endpoint در حال حاظر متوقف نشده است،
1 : endpoint در حال حاظر متوقف شده است،

توسط درخواست SetFeature میتونید ویژگی Halt رو فعال کنید؛ توسط این درخواست و چه توسط خود دستگاه میتونید این ویژگی رو فعال کنید، endpoint رفتار یکسانی نشان میده؛ اگه شرایط ایجاد Halt حذف بشه ( توسط درخواست ClearFeature میشه این ویژگی رو غیر فعال کرد )، endpoint یک STALL ارسال میکنه ( مشکل ترجمه )؛ برا endpoint هایی که از data toggle استفاده میکنند، طرف نظر از این که ویژگی Halt براشون فعال هستش، پاسخ یک درخواست ClearFeature همیشه با DATA0 شروع میشه ( مشکل ترجمه )؛ ویژگی Halt بعد از درخواست SetConfiguration و یا SetInterface صفر میشه حتی اگه این دو درخواست، مشابه configuration و یا interface فعلی باشن ( مشکل ترجمه ).

فعال کردن ویژگی Halt برای Endpoint0 ( اندپوینت کنترلی ) نه نیاز هستش و نه توصیه میشه؛ با این حال Device ممکنه ویژگی Halt رو برای Endpoint0 فعال کنه به منظور منعکس کردن functional error condition؛ اگر این ویژگی 1 بشه، Device میاد و STALL ارسال میکنه در مرحله Data و Status برای هر درخواست استانداردی بجز درخواستهای GetStatus ،SetFeature و ClearFeature ( چه سودی تو این کار هستش که دستگاه بجای ack و nak بیاد stall ارسال کنه - هدف از این کار چیه؟ )؛ Device نیازی نداره که STALL ارسال کنه برای درخواست های class-specific و vendor-specific. ( نفهمیدم )

چیزی که من فهیمدم : خب وقتی ویژگی Halt رو فعال کردیم، Endpoint متوقف میشه و طبیعی هستش که اگه تبادل دادی بخواد باهاش انجام بشه باید از این کار جلو گیری کرد با ارسال کد هندشیک STALL که به هاست میگه که اندپونیت متوقف شده.

این درخواست جهت پاک یا غیرفعال کردن یه ویژگی خاص بکار میره! ( اصلاح توضیحات + توضیح بهتر و بیشتر )

مقدار FeatureSelector در wValue باید متناسب با گیرنده باشد؛ تنها زمانی میشه از مقادیر FeatureSelector مربوط به Device استفاده کرد که گیرنده یک Device باشه؛ تنها زمانی میشه از مقادیر FeatureSelector مربوط به Interface استفاده کرد که گیرنده یک Interface باشه؛ تنها زمانی میشه از مقادیر FeatureSelector مربوط به Endpoint استفاده کرد که گیرنده یک Endpoint باشه ( در جدول 6-9 همش 3 تا مقدار داریم که دوتاش برا Device و یکیش برا Endpoint هستش؛ Interface از کجا اومد؟ ).
به جدول 6-9 مراجعه کنید و ببینید چه FeatureSelector هایی برای چه نوع گیرنده هایی تعریف شده.
یک درخواست ()ClearFeature ( که به یک ویژگی اشاره داره ) به دلیل ممکنه امکان پاک شدنش وجود نداشته باشه : یا اون درخواست کلا اشتباه هستش ( همچین درخواستی وجود نداره ) یا این که اشاره یه یک Interface یا Endpoint یی میکنه که وجود ندارند، لذا این موارد باعث میشن که Device با یک Request Error پاسخ بده.
اگه مقدار wLength صفر نباشه، نحوه رفتار Device مشخص نیست ( در جدول 3-9 میبینید که برای استفاده از درخواست ()ClearFeature باید مقدار wLength صفر باشه )

توجه : ویژگی Test_Mode قابل پاک شدن توسط درخواست ()ClearFeature نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Clear Feature رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : این درخواست زمانی معتبر هستش که دستگاه در "Address state" قرار داشته باشه؛ اشاره به Interface و یا Endpoint یی غیر از Endpoint0 باعث میشه دستگاه  با Request Error پاسخ بده.

Configured state : این درخواست معتبر هستش.

این درخواست جهت تنظیم و یا فعال نمون ویژگی های خاص بکار میره!

فیلد wValue حاوی Feature selector هستش ( جدول 6-9 رو ببینید ).

ویژگی TEST_MODE تنها برای دستگاه های گیرنده ( bmRequestType = 0 ) تعریف شده و بایت کم ارزش wIndex باید 0 باشد؛

Setting the TEST_MODE feature puts the device upstream facing port into test mode.
The device will respond with a request error if the request contains an invalid test selector.
The transition to test mode must be complete no later than 3 ms after the completion of the status stage of the request.
The transition to test mode of an upstream facing port must not happen until after the status stage of the request.
The power to the device must be cycled to exit test mode of an upstream facing port of a device.
See Section 7.1.20 for definitions of each test mode.
A device must support the TEST_MODE feature when in the Default, Address or Configured high-speed device states.

A SetFeature() request that references a feature that cannot be set or that does not exist causes a STALL to be returned in the Status stage of the request.

If the feature selector is TEST_MODE, then the most significant byte of wIndex is used to specify the specific test mode.
The recipient of a SetFeature(TEST_MODE…) must be the device;
i.e., the lower byte of wIndex must be zero and the bmRequestType must be set to zero.
The device must have its power cycled to exit test mode.
The valid test mode selectors are listed in Table 9-7.
See Section 7.1.20 for more information about the specific test modes.

توجه 1 : اگه فیلد wLength صفر نباید، اونوقت رفتار دستگاه مشخص نیست.

توجه 2 : اگه endpoint یا interface مشخص شده، موجود نبودند، دستگاه با یک Request Error پاسخ میده.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Set Feature رو دریافت میکنه :

Default state : وقتی دستگاهی در این مد هستش باید توانایی پذیرش درخواست (SetFeature(TEST_MODE, TEST_SELECTOR رو داشته باشه، به ازای درخواست های دیگه SetFeature، رفتار دستگاه مشخص نیست.

Address state : اگه یه interface یا یه endpoint غیر غز Endpoint0 مشخص بشه، اونوقت دستگاه با یک Request Error پاسخ میده.

Configured state : این درخواست معتبر هستش.

این درخواست، آدرس Device رو تعیین میکنه برای دسترسی ها و تبادلات بعدی Host با Device ( تا قیامت که نمیشه از آدرس کنترلی 0 استفاده کرد که خخخ )

فیلد wValue حاوی آدرس اختصاص داده شده به Device هستش ( که برا تبادلات بعدی بین Host و Device از این آدرس باید استفاده بشه و نه آدرس کنترلی 0 )
این درخواست ها همگی در مد کنترل کاربرد دارن؛ برا درخواست Set Address اگه ترنزکشن Data وجود نداشته باشه؛ در ترنزکشن Status پکیج Data، جهت پکیج Data از سمت Device به Host میباشد هر چند که اندازه فیلد Data این پکیج 0 هستش ( چون تنها در حالت CONTROL WRITE TRANSFER ما میتونیم ترنزکشن Data نداشته باشم و در این حالت، جهت انتقال داده در پکیج Data از ترنزکشن Status از سمت Device به Host میباشد )

توجه 1 : دستگاه باید صبر کنه تا ترنزکشن Status مربوط به Set Address با موفقیت انجام بشه و بعد آدرسشو تغییر بده؛ این مورد تنها تفاومت این درخواست با درخواست های دیگه هستش؛ برای درخواست های دیگر، دستگاه قبل از اتمام ترنزکشن Status باید عملیات هایی که توسط اون درخواست معین شده رو انجام بده. ( این مورد دیگه از بدیهیات هستش دیگه، چون اگه دستگاه که در مرحله Setup آدرس جدید رو دریافت میکنه، اگه بیاد آدرس جدید رو اعمال کنه، دیگه ترنزکشن Data و Status مربوط به درخواست Set Address رو نمیتونه دریافت کنه چون آدرس این دو ترنزکشن 0 هستش و آدرس دستگاه تغییر کرده و دیگه 0 نیست )

توجه 2 : اگه آدرس مشخص شده ( مقدار فیلد wValue ) بیش از 128 بود، یا اگر wIndex یا wLength صفر نبودند، اونوقت رفتار دستگاه مشخص نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Set Address رو دریافت میکنه :

Default state : اگه آدرس مشخص شده غیر 0 بود، دستگاه باید وارد "Address state" بشه؛ در غیر این صورت، دستگاه در "Default state" باقی خواهد ماند ( این یک وضعیت خطا نیست )

Address state : اگه آدرس مشخص شده 0 بود، اون وقت دستگاه باید به "Default state" بره؛ در غیر این صورت، دستگاه در "Address state" باقی میماند اما از آدرس جدید اختصاص داده شده استفاده نمیکند.

Configured state : رفتار دستگاه مشخص نیست.

این درخواست، descriptor مشخص شده رو برمیگردونه، البته اگه موجود باشه!

فیلد wValue ( که حاوی 2 بایت هستش ) در بایت پرارزش اش حاوی descriptor type هستش که به کمک جدول 5-9 ( در بالا قرار دادم ) مقدار دهی میشه و در بایت کم ارزش اش حاوی descriptor index هستش؛ که descriptor index جهت انتخاب descriptor مدنظر بکار میره زمانی که بیش از یک descriptor در دستگاه تعریف شده است ( descriptor index تنها برای Configuration Descriptor و String Descriptor کاربرد داره )؛ برای دیگر descriptor های استاندارد که توسط درخواست GetDescriptor قابل دریافت هستند، مقدار descriptor index باید 0 باشد؛ محدوده مقدار descriptor index از 0 شروع میشه تا یکی کمتر از تعداد descriptor های تعریف شده در دستگاه ( مثلا تو دستگاه 4 تا descriptor تعریف شده، خب طبیعی هستش که descriptor index از 0 شروع میشه تا 3؛ چون شمارش از 0 شروع شده و نه 1 )

فیلد wIndex حاوی Language ID برای String Descriptor هستش ( برا Descriptor های دیگه این مقدار باید 0 باشد )

فیلد wLength مشخص کننده تعداد بایتی هستش که باید برگشت داده بشه؛ اگه تعداد بایت descriptor بیش از این فیلد باشه، تنها بایت های اولیه descriptor ارسال میشه و اگه کمتر از این فیلد بود موردی نداره ( چیزی که من فهیمدم، ولی دیتاشیت یه 2-3 خط توضیحات داده بود )

توجه 1 : اگه این درخواست، درخواست خوندن Configuration خاصی رو بده، ابتدا Configuration Descriptor مدنظر ارسال میشه، سپس Interface Descriptor هاش بعد Endpoint Descriptor هاش ( و باز اگه Interface یی وجود داشت، این چرخه دوباره تکرار میشه ) بعد Descriptor های مربوط به بعضی کلاس های خاص ارسال میشه. ( چیزی که من فهیمدم در عمل، البته این کارا، در یک Transfer جدا، ابتدا Device Descriptor ارسال میشه و در یه Tranfer دیگه این موارد که الان ذکر شد یکجا ارسال میشه، البته خب بازم داستان داره که ... )

توجه 2 :تمام دستگاه ها باید یک "Device Descriptor" و حداقل یک "Configuration Descriptor" داشته باشند؛ اگه دستگاه این درخواست رو پشتیبانی نکنه ( حالا به هر دلیلی ) با یک Request Error پاسخ میدهد.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Get Descriptor رو دریافت میکنه :

Default state : این درخواست معتبر هستش.

Address state : این درخواست معتبر هستش.

Configured state : این درخواست معتبر هستش.

این درخواست اختیاری هستش و میتونه استفاده بشه چهت بروزرسانی Descriptor های موجود، و یا اضافه کردن Descriptor های جدید.

فیلد wValue در بایت پر ارزش اش descriptor type و در بایت کم ارزش اش descriptor index قرار میگیره؛ وقتی چندین descriptor از یک نوع در Device موجود هستش descriptor index جهت انتخاب descriptor مدنظر بکار ( تنها configuration و string descriptors )؛ برای مثال Device میتونه چندین configuration descriptor داشته باشه؛ برای descriptor های استاندارد دیگه که توسط دستور SetDescriptor قابل تنظیم شدن هستند، مقدار descriptor index باید 0 باشد ( توضیح بهتر )؛ محدوده فیلد wValue از 0 تا یکی کمتر از حداکثر تعداد descriptor type مد نظر ما؛
فیلد wIndex حاوی Language ID برای string descriptors هستش، برای descriptor های دیگه 0 هستش.
فیلد wLength مشخص کننده تعداد بایت هایی هستش که قراره از سمت host برا device ارسال بشه.
تنها مقادیر مجاز برای descriptor type عبارتند از : device، configuration و string ( جدول 5-9 )؛ اگر این درخواست پشتیبانی نشه، Device در پاسخ Request Error ارسال میکنه.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Set Descriptor رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : اگه این درخواست توسط دستگاه پشتیبانی بشه، این درخواست در این مد، معتبر هستش.

Configured state : اگه این درخواست توسط دستگاه پشتیبانی بشه، این درخواست در این مد معتبر هستش.

این درخواست، مقدار پیکربندی فعلی Device رو برمیگردونه.

اگه مقدار برگشت داده شده 0 بود، یعنی Device پیکربندی نشده؛ اگه مقادیر wValue و wIndex و یا wLength طبق جدول 3-9 مقدار دهی نشن، رفتار Device مشخص نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Get Configuration رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : مقدار 0 باید برگشت داده بشه.

Configured state : مقدار غیر صفر پیکربندی فعلی ( فیلد bConfigurationValue از Standard Configuration Descriptor ) باید برگشت داده بشه.

این درخواست Configuration دستگاه رو اعمال میکنه ( دستگاه رو پیکربندی میکنه )، که از اون چند تا پیکربندی که خود دستگاه ارائه میده، میزبان میاد یکیشو انتخاب میکنه.

بایت کم ارزش فیلد wValue، شماره Configuration دلخواه رو مشخص میکنه؛ که مقدارش باید 0 یا برابر مقدار یک "Configuration Descriptor" تعریف شده باشه؛ اگه مقدار 0 داده بشه، دستگاه به "Address state" میره؛ بایت پرارزش فیلد wValue هم رزرو شده هستش.

توجه : اگه فیلد wValue, wLength بایت پرارزش فیلد wValue صفر نباشد، رفتار دستگاه مشخص نشده است.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Set Configuration رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : اگه مقدار Configuration مشخص شده 0 باشد، اون وقت دستگاه در "Address state" باقی میمونه؛ اگه مقدار Configuration مشخص شده برابر مقدار یک "Configuration Descriptor" باشه، اونوقت اون Configuration انتخاب شده و دستگاه وارد "Configured state" میشه، در غیر این صورت دستگاه در پاسخ Request Error ارسال میکند.

Configured state : اگه Configuration مشخص شده 0 باشد، اون وقت دستگاه وارد "Address state" میشه؛ اگه مقدار Configuration مشخص شده برابر مقدار یک "Configuration Descriptor" باشه، اونوقت Configuration جدید انتخاب میشه و دستگاه در "Configured state" باقی میمونه، در غیر این صورت دستگاه در پاسخ Request Error ارسال میکند.

بعضی دستگاه ها configuration با interface هایی دارند که تنظیماتی منحصر به فرد دارند؛ این درخواست مقدار alternate setting انتخاب شده، مربوط به Interface انتخاب شده رو برمیگردونه.

توجه 1 : اگه فیلد wValue صفر نباشه یا فیلد wLength یک نباشه، اونوقت رفتار دستگاه مشخص نیست.

توجه 2 : اگه interface مشخص شده وجود نداشته باشد، اونوقت دستگاه با یک Request Error پاسخ میده.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Get Interface رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : دستگاه باید با یک Request Error پاسخ دهد.

Configured state : این درخواست معتبر هستش.

برخی دستگاه ها configuration هایی با interface هایی دارند که تنظیمات منحصر به فرد دارند؛ این درخواست این امکان رو به میزبان میده تا برا interface یی که مشخص کرده، alternate setting دلخواهشو انتخاب کنه؛ اگه دستگاه برا interface مشخص شده، فقط از setting پیشفرض ( یعنی alternate setting صفر باشه / به عبارت دیگه، هیچ تنظیم خاصی نداشته باشه ) پشتیبانی کنه، اونوقت در پاسخ به درخواست Status stage یه وضعیت STLL ارسال میشه.

توجه 1 : این درخواست نمیتونه برای تغییر interface ها استفاده بشه ( برای این کار باید از درخواست Set Configuration استفاده کنید. )

توجه 2 : اگه interface یا alternate setting وجود نداشته باشند، اونوقت دستگاه با یک Request Error پاسخ میده.

توجه 3 : اگه فیلد wLength صفر نباشه، اونوقت رفتار دستگاه مشخص نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Set Interface رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : دستگاه باید با یک Request Error پاسخ دهد.

Configured state : این درخواست معتبر هستش.

This request is used to set and then report an endpoint’s synchronization frame.

When an endpoint supports isochronous transfers, the endpoint may also require per-frame transfers to vary in size according to a specific pattern.
The host and the endpoint must agree on which frame the repeating pattern begins.
The number of the frame in which the pattern began is returned to the host.

If a high-speed device supports the Synch Frame request, it must internally synchronize itself to the zeroth microframe and have a time notion of classic frame.
Only the frame number is used to synchronize and reported by the device endpoint (i.e., no microframe number).
The endpoint must synchronize to the zeroth microframe.

This value is only used for isochronous data transfers using implicit pattern synchronization.

توجه 1 : اگه endpoint مشخص شده، این درخواست رو پشتیبانی نکنه، باید با یک Request Error پاسخ بده.

توجه 2 : اگه فیلد wValue صفر نباشه یا فیلد wLength دو نباشه، اونوقت رفتار دستگاه مشخص نیست.

رفتار دستگاه وقتی در هر یک از مدهای زیر قرار داره و درخواست Synch Frame رو دریافت میکنه :

Default state : رفتار دستگاه مشخص نیست.

Address state : دستگاه باید با یک Request Error پاسخ دهد.

Configured state : این درخواست معتبر هستش.

توجه : موارد زیر چیزایی هستش که من متوجه شدم ( ممکنه دقیق و یا صحیح نباشه ! )

Bus Enumeration = به مجموعه عملیاتی گفته میشه که دستگاه تازه متصل شده به درگاه رو تشخیص میده و آدرس یکتایی بهش میده و دستگاه رو شناسایی میکنه و دستگاهی هم که از درگاه جدا شده رو حذف میکنه و آدرسشو آزاد میکنه.

توجه : مراحل سرشماری بر عهده میزبان هستش!

مراحل سرشماری : وقتی دستگاه به پورت USB وصل میشه، عملیات زیر اجرا میشه :

1) وصل شدن دستگاه به پورت USB؛ دستگاه به Powered state میره ( وضعیت توان ).

2) شناسایی دستگاه توسط hub

3) تشخیص سرعت دستگاه ( برا بحث نحوه تشخیص سرعت دستگاه به مطلب "آموزش پیشرفته پروتکل usb" مراجعه کنید )

4) hub یک سیگنال reset ارسال میکنه و دستگاه به Default state میره ( وضعیت پیشفرض / وضعیتی که دستگاه هنوز آدرسی بهش داده نشده و پیکربندی یی براش انتخاب نشده ) و نمیتونه جریانی بیشتر از 10mA از VBUS بکشه و تمام رجیستر ها و وضعیت دستگاه باید ریست بشه و دستگاه باید به default address ( آدرس 0 و اندپوینت 0 ) پاسخ بده.

5) device descriptor توسط میزبان خونده میشه.

6) میزبان آدرس یکتایی رو به دستگاه میده، دستگاه به Address state میره ( وضعیت آدرس، وضعیتی که دستگاه آدرس دهی شده / بهش آدرس داده شده / دارای آدرس اختصاصی هستش )

7) میزبان اطلاعات مربوط به تمام Descriptor ها رو میخونه ( منجمله configuration های دستگاه )، این پردازش ممکن هستش چند mS طول بکشد تا کامل شود.

8) بر طبق اطلاعات configuration دستگاه و این که چگونه قراره استفاده بشه، میزبان یک configuration رو انتخاب میکنه و به دستگاه میگه، دستگاه اکنون در Configured state قرار داره ( وضعیت پیکربندی شده )

وقتی دستگاه از پورت USB جدا میشه، hub با یک پیام، میزبان رو از این موضوع آگاه میکنه و میزبان هم آدرس اختصاص داده شده رو آزاد میکنه.