نمایش/عدم نمایش سایدبار
رفتن به بالای صفحه
آزادی حجاز از دست نااهلان
مهدی دمیرچیلو

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

به نام خدا : تو این مطلب میخوام درباره پروتکل USB توضیحاتی بدم، که متاسفانه تو نت فارسی بهش پرداخته نشده به اون صورت که نیاز هستش! حس توضیح بیشتر ندارم، بریم سراغ مطلب laugh

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

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

 

لوگو و سرعت نسخه های مختلف USB

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

لوگوهای USB

 

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

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

 

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

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

تکنیک انتقال داده در پروتکول USB

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. زوج های دیفرانسیلی چیست؟ و نحوه استفاده از آن ها در آلتیوم

Differential signaling

Differential signaling

Half Duplex

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

USB Pinout

USB Pinout : نسخه 1و2 usb کلا 4 تا پایه داره ولی usb3 حدود 9 تا پایه داره ( در زیر 3 تا عکس میزارم، هر 3 تاش هم یکی هستش ولی خب هر 3 عکس دیدم جالب و مفیده، لذا هر 3تاشو گزاشتم )
پایه های پورت USB نسخه 1 تا 2 ( USB Pinout )؛ ترتیب پایه های کانکورهای USB به صورت زیر هستش - البته برا نسخه 1 تا 2 USB
USB Pinout
اینم یه عکس دیگه :
usb pinout

تو عکس زیر، پایه 1 تا 4 تو تمام usb ها مشترک هستش، پایه های 5 تا 9 رو فقط usb3 داره :
پایه های usb

خب چون این مطلب مخصوص USB2 هستش، لذا بریم سراغ توضیح پایه های USB2؛ پایه GND که معلومه، +D و -D جفت پایه دیفرانسیلی برا انتقال داده هستش، میمونه پایه VBUS ...

پایه VBUS : این پایه تغذیه هستش که 5 ولت هستش، که زمانی که دستگاه BUS Powered ( تغذیشو از دیتاشیت میگیره، مثل موس، کیبیورد، دسته بازی و ... ) این پایه تغذیه مدار فوق رو تامین میکنه ( که به کمک Descriptor ها، دستگاه میتونه تغیین کنه که BUS Powered هستش یا نه و اگه BUS Powered هستش چقدر جریان نیاز داره؟ بین 0 تا 500 میلی آمپر )؛ و اگه دستگاه Sef Powered هستش ( خودش منبع تغذیه خارجی داره )، فلذا نیازی به این پایه VBUS نداره ( اون وقت یعنی هیچ جریانی نمیکشه؟ )

این قسمت از دیتاشیت مطالعه بشه - کلی داستان داره که باید گفته بشه

Frame and Microframe - SOF and EOF

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 هستش.

این عکس رو تو نت پیدا کردم این عکس هم تو دیتاشیت بود
Frame and MicroFrame Relationship between Frames and Microframes
هر دو این عکس ها خوب بودن، لذا هردوشونو گزاشتم، هرچند که هردوشون یکسان هستند، روشون کلیک کنید و در اندازه اصلی ببینیدشون.

 

تعداد 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 رو مشخص میکنه.

Frame and Microframe Creation

 

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

نحوه عیب یابی و مانیتورینگ پورت usb

خب اگه کارتون با میکروکنترلر ها هستش و تو پروژتون نیاز دارید که از 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 - جهت انتقال اطلاعات و تمام - و این موارد اصلا بکار من نمیاد! ( عکس زیر ) مشکل بزرگتری هم که تو اینجور نرم افزار ها هستش اینه که نمیشه اطلاعات مد کنترل رو ردگیری و تحلیل کرد.

USB Trace

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

 

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

 

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

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

USB Logic 100MHz 16Ch

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

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

Saleae Logic 1.2.18

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

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

Saleae Logic - Sample Data Output

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

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

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

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

Saleae Logic - Sample Data Output - my edit

 

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

 

در هنگام خرید یک دستگاه 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

Beagle USB 5000 v2 SuperSpeed Protocol Analyzer - Ultimate Edition

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

J & K State (bit) / Byte / Field / Packet / Transaction / Transfer / (micro)Frame

کدنویسی : این که در چه سطحی از این مواردی که گفتم بخواید کار کنید بستگی به آیسی و مدارتون داره، مثلا اگه از میکرو 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 خودمون هستند، فقط اسمشون رو تغییر دادیم - همین )

K State and J State in LS FS HS

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

Sample Data J & K State

 

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

Sample Data Byte

 

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

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

Sample Data Field

 

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

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

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

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

راه اندازی پروتکول usb با میکروکنترلر هایی که از پروتکول usb پشتیبانی نمیکنند

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

 

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

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

اختصارات، اصطلاحات و اطلاعات مفید مربوط به پروتکل USB

Active Device : A device that is powered and is not in the Suspend state.

Asynchronous Data : Data transferred at irregular intervals with relaxed latency requirements.

Asynchronous RA : The incoming data rate, Fsi , and the outgoing data rate, Fso, of the RA process are independent (i.e., there is no shared master clock). See also rate adaptation.

Asynchronous SRC : The incoming sample rate, Fsi , and outgoing sample rate, Fso, of the SRC process are independent (i.e., there is no shared master clock). See also sample rate conversion.

Audio Device : A device that sources or sinks sampled analog data.

AWG# : The measurement of a wire’s cross section, as defined by the American Wire Gauge standard.

Babble : Unexpected bus activity that persists beyond a specified point in a (micro)frame.

Bit Stuffing : Insertion of a “0” bit into a data stream to cause an electrical transition on the data wires, allowing a PLL to remain locked.

Characteristics : Those qualities of a USB device that are unchangeable; for example, the device class is a device characteristic.

Client : Software resident on the host that interacts with the USB System Software to arrange data transfer between a function and the host. The client is often the data provider and consumer for transferred data.

Configuring Software : Software resident on the host software that is responsible for configuring a USB device. This may be a system configurator or software specific to the device.

Control Endpoint : A pair of device endpoints with the same endpoint number that are used by a control pipe. Control endpoints transfer data in both directions and, therefore, use both endpoint directions of a device address and endpoint number combination. Thus, each control endpoint consumes two endpoint addresses.

Control Pipe : Same as a message pipe.

Default Address : An address defined by the USB Specification and used by a USB device when it is first powered or reset. The default address is 00H.

Default Pipe : The message pipe created by the USB System Software to pass control and status information between the host and a USB device’s endpoint zero.

Device Address : A seven-bit value representing the address of a device on the USB. The device address is the default address (00H) when the USB device is first powered or the device is reset. Devices are assigned a unique device address by the USB System Software.

Device Endpoint : A uniquely addressable portion of a USB device that is the source or sink of information in a communication flow between the host and device. See also endpoint address.

Device Resources : Resources provided by USB devices, such as buffer space and endpoints. See also Host Resources and Universal Serial Bus Resources.

Device Software : Software that is responsible for using a USB device. This software may or may not also be responsible for configuring the device for use.

Downstream : The direction of data flow from the host or away from the host. A downstream port is the port on a hub electrically farthest from the host that generates downstream data traffic from the hub. Downstream ports receive upstream data traffic.

Driver : When referring to hardware, an I/O pad that drives an external load. When referring to software, a program responsible for interfacing to a hardware device, that is, a device driver.

Dynamic Insertion and Removal : The ability to attach and remove devices while the host is in operation.

End User : The user of a host.

Endpoint : See device endpoint.

Endpoint Address : The combination of an endpoint number and an endpoint direction on a USB device. Each endpoint address supports data transfer in one direction.

Endpoint Direction : The direction of data transfer on the USB. The direction can be either IN or OUT. IN refers to transfers to the host; OUT refers to transfers from the host.

Endpoint Number : A four-bit value between 0H and FH, inclusive, associated with an endpoint on a USB device.

Envelope detector : An electronic circuit inside a USB device that monitors the USB data lines and detects certain voltage related signal characteristics.

External Port : See port.

Eye pattern : A representation of USB signaling that provides minimum and maximum voltage levels as well as signal jitter.

False EOP : A spurious, usually noise-induced event that is interpreted by a packet receiver as an EOP.

Frame Pattern : A sequence of frames that exhibit a repeating pattern in the number of samples transmitted per frame. For a 44.1 kHz audio transfer, the frame pattern could be nine frames containing 44 samples followed by one frame containing 45 samples.

Function : A USB device that provides a capability to the host, such as an ISDN connection, a digital microphone, or speakers.

Host Controller : The host’s USB interface

Host Controller Driver (HCD) : The USB software layer that abstracts the Host Controller hardware. The Host Controller Driver provides an SPI for interaction with a Host Controller. The Host Controller Driver hides the specifics of the Host Controller hardware implementation.

Host Resources : Resources provided by the host, such as buffer space and interrupts. See also Device Resources and Universal Serial Bus Resources.

Hub : A USB device that provides additional connections to the USB.

Hub Tier : One plus the number of USB links in a communication path between the host and a function. See Figure 4-1.

Interrupt Request (IRQ) : A hardware signal that allows a device to request attention from a host. The host typically invokes an interrupt service routine to handle the condition that caused the request.

I/O Request Packet (IRP ) : An identifiable request by a software client to move data between itself (on the host) and an endpoint of a device in an appropriate direction.

Isochronous Data : A stream of data whose timing is implied by its delivery rate.

Isochronous Device : An entity with isochronous endpoints, as defined in the USB Specification, that sources or sinks sampled analog streams or synchronous data streams.

Isochronous Sink Endpoint : An endpoint that is capable of consuming an isochronous data stream that is sent by the host.

Isochronous Source Endpoint : An endpoint that is capable of producing an isochronous data stream and sending it to the host.

Jitter : A tendency toward lack of synchronization caused by mechanical or electrical changes. More specifically, the phase shift of digital pulses over a transmission medium.

LOA : Loss of bus activity characterized by an SOP without a corresponding EOP.

Message Pipe : A bi-directional pipe that transfers data using a request/data/status paradigm. The data has an imposed structure that allows requests to be reliably identified and communicated.

Non Return to Zero Invert (NRZI) : A method of encoding serial data in which ones and zeroes are represented by opposite and alternating high and low voltages where there is no return to zero (reference) voltage between encoded bits. Eliminates the need for clock pulses.

Object : Host software or data structure representing a USB entity.

Phase : A token, data, or handshake packet. A transaction has three phases.

Phase Locked Loop (PLL) : A circuit that acts as a phase detector to keep an oscillator in phase with an incoming frequency.

Physical Device : A device that has a physical implementation; e.g., speakers, microphones, and CD players.

Pipe : A logical abstraction representing the association between an endpoint on a device and software on the host. A pipe has several attributes; for example, a pipe may transfer data as streams (stream pipe) or messages (message pipe). See also stream pipe and message pipe.

Polling : Asking multiple devices, one at a time, if they have any data to transmit.

Port : Point of access to or from a system or circuit. For the USB, the point where a USB device is attached.

Power On Reset (POR) : Restoring a storage device, register, or memory to a predetermined state when power is applied.

Programmable Data Rate : Either a fixed data rate (single-frequency endpoints), a limited number of data rates (32 kHz, 44.1 kHz, 48 kHz, …), or a continuously programmable data rate. The exact programming capabilities of an endpoint must be reported in the appropriate class-specific endpoint descriptors.

Protocol : A specific set of rules, procedures, or conventions relating to format and timing of data transmission between two devices.

Rate Adaptation (RA) : The process by which an incoming data stream, sampled at Fsi , is converted to an outgoing data stream, sampled at Fso,with a certain loss of quality, determined by the rate adaptation algorithm. Error control mechanisms are required for the process. Fsi and Fso can be different and asynchronous. Fsi is the input data rate of the RA; Fso is the output data rate of the RA.

Retire : The action of completing service for a transfer and notifying the appropriate software client of the completion.

Root Hub : A USB hub directly attached to the Host Controller. This hub (tier 1) is attached to the host.

Root Port : The downstream port on a Root Hub.

Sample : The smallest unit of data on which an endpoint operates; a property of an endpoint.

Sample Rate (Fs) : The number of samples per second, expressed in Hertz (Hz).

Sample Rate Conversion (SRC) : A dedicated implementation of the RA process for use on sampled analog data streams. The error control mechanism is replaced by interpolating techniques.

Service : A procedure provided by a System Programming Interface (SPI).

Service Interval : The period between consecutive requests to a USB endpoint to send or receive data.

Service Jitter : The deviation of service delivery from its scheduled delivery time.

Service Rate : The number of services to a given endpoint per unit time.

Split transaction : A transaction type supported by host controllers and hubs. This transaction type allows full- and low-speed devices to be attached to hubs operating at high-speed.

Stream Pipe : A pipe that transfers data as a stream of samples with no defined USB structure.

Synchronization Type : A classification that characterizes an isochronous endpoint’s capability to connect to other isochronous endpoints.

Synchronous RA : The incoming data rate, Fsi , and the outgoing data rate, Fso, of the RA process are derived from the same master clock. There is a fixed relation between Fsi and Fso.

Synchronous SRC : The incoming sample rate, Fsi , and outgoing sample rate, Fso, of the SRC process are derived from the same master clock. There is a fixed relation between Fsi and Fso.

System Programming Interface (SPI) : A defined interface to services provided by system software.

Termination : Passive components attached at the end of cables to prevent signals from being reflected or echoed.

Time Division Multiplexing (TDM) : A method of transmitting multiple signals (data, voice, and/or video) simultaneously over one communications medium by interleaving a piece of each signal one after another.

Time Domain Reflectometer (TDR) : An instrument capable of measuring impedance characteristics of the USB signal lines.

Timeout : The detection of a lack of bus activity for some predetermined interval.

Transaction translator : A functional component of a USB hub. The Transaction Translator responds to special high-speed transactions and translates them to full/low-speed transactions with full/low-speed devices attached on downstream facing ports.

Turn-around Time : The time a device needs to wait to begin transmitting a packet after a packet has been received to prevent collisions on the USB. This time is based on the length and propagation delay characteristics of the cable and the location of the transmitting device in relation to other devices on the USB.

Universal Serial Bus Driver (USBD) : The host resident software entity responsible for providing common services to clients that are manipulating one or more functions on one or more Host Controllers.

Universal Serial Bus Resources : Resources provided by the USB, such as bandwidth and power. See also Device Resources and Host Resources.

Upstream : The direction of data flow towards the host. An upstream port is the port on a device electrically closest to the host that generates upstream data traffic from the hub. Upstream ports receive downstream data traffic.

Virtual Device : A device that is represented by a software interface layer. An example of a virtual device is a hard disk with its associated device driver and client software that makes it able to reproduce an audio .WAV file.

SOP : Start-of-Packet.

Big Endian : A method of storing data that places the most significant byte of multiple-byte values at a lower storage address. For example, a 16-bit integer stored in big endian format places the least significant byte at the higher address and the most significant byte at the lower address. See also little endian.

Little Endian : Method of storing data that places the least significant byte of multiple-byte values at lower storage addresses. For example, a 16-bit integer stored in little endian format places the least significant byte at the lower address and the most significant byte at the next address. See also big endian.

 

Bandwidth : مقدار دیتای انتقال داده شده در هر واحد زمان، به صورت عمومی بیت بر ثانیه ( b/s ) یا بایت بر ثانیه ( B/s )

 

اختصارات، اصطلاحات و اطلاعات مفید مربوط به پروتکل USB

شکل زیر مربوط به دیتاشیت هستش که اومده یه چند تایی از اختصارات رو گفته :
USB related acronyms, abbreviations, and definitions
یه چندتا اصطلاح دیگه که در فصل ( مطلب ) استفاده شده ولی در جدول بالا نیستش رو در ادامه میگم :

2)
LSb  : کم ارزش ترین بیت.
MSb : پر  ارزش ترین بیت.
LSB  : کم ارزش ترین بایت.
MSB : پر  ارزش ترین بایت.

1) FIFO : به حافظه هایی که مدل خوندنشون First In, First Out هستش فیفو میگن.

2)
device ( دستگاه ) : -
host ( میزبان ) : میزبان به دستگاه دیتا میده یا ازش درخواست دیتا میکنه ( میزبان شروع کننده هر انتقالی هستش )

3) word برابر 4 بایت هستش ( تو این مطلب - بررسی بشه این مورد )
Word : دو بایت دیتا ( 16 بیت )
(DWORD (Double word : چهار بایت ( 32 بیت )

4) (Advanced High-performance Bus (AHB

5) (Advanced Peripheral Bus (APB

6) field : فیلد به یه مجموعه بیت گفته میشه، مثلا به جای این که بگن بیت 1 تا 4 رجیستر abc ( که مثلا اسم این 4 تا بیت fff هستش )؛ میان و میگن : فیلد fff از رجیستر abc، ولی خب اگه تک بیت باشه، همون بیت اطلاق میشه.

8) IN : معنی کلمه ورودی، معنی کاربردی تو USB : انتقال دیتا از device به host ( البته قبلش host به device میگه که برام دیتا بفرست )
9) OUT : معنی کلمه خروجی، معنی کاربردی تو USB : انتقال دیتا از host به device

16) فرق USB با USB OTG
USB : یه دستگاه device میشه و یکی دیگه host
USB OTG : دستگاه ها میتوانند هم DEVICE و هم HOST باشند
توضیح بیشتر + عکس

17) حداکثر طول کابل USB : حداکثر طولی که کابل USB میتونه داشته باشه حدود 5 متر هستش.
توضیحات بیشتر + نحوه افزایش طول

18) USB Topology : در شکل زیر نحوه اتصال دستگاه ها به هاست رو مشاهده میکنید :
USB Topology
هر host یک root hub داره که ( بسته به host ) میتونید چند تا device بهش وصل کنید ( چطوری میشه فهمیدم که چندتا میشه وصل کرد؟ )؛ مثلا 4 تا، خب حالا اگه خواستیم 10 تا device به root hub هاست وصل کنیم چیکار باید کنیم؟ خب میایم از hub استفاده میکنیم؛ که بهش usb hub میگن که کارش افزایش تعداد پورت های usb هستش که خب انواع مختلفی داره در زیر یک مدل usb hub با حدود 10 خروجی مشاهده میکنید ( که میتویند تو نت سرچ کنید و ببینیید، خودم یه 4-5 خروجی شو دارم، حدود 30 تومن خریدم فک کنم پارسال، لبتابم 3 تا پروت usb داره، یکی که همیشه موس هستش، که خب 2 تا پورت usb برا کار من کم هستش لذا رفتم یه usb hub خریدم تا مشکل حل بشه )؛ حداکثر تا 127 تا دستگاه رو میتونیم به host وصل کنیم ( این حالت تئوریش هستش، در عملی نمیدونم واقعا میشه نمیشه، غیر از بحث تغذیه چه مشکلاتی پیش میاد و .... )؛ شکل بالا حدود 9 تا device به host وصل هستش ( به کمک usb hub ها )
USB HUB

19) ارتباط نسخه های مختلف root hub/hub/device با همدیگه : در این باره خودم هم زیاد ریز نشدم و مطالبشو نخوندم ولی خب گفتم دو تا عکس ازش بزارم شاید بعدا اومدم سراغش تا کاملش کنم و همچین شاید شما علاقه مند بشید که برید مطالعه کنید دربارش ( که خب تو خواب برید سراغش ^_^ )؛ که خب قاعده عملکرد در دو عکس زیر واضع هستش و نیازی به گفتن فک نکنم باشه ( ارتباط بر مبنای حداکثر توانایی root hub / hub / device هستش، مثلا یه Device نسخه 2.0 به یه hub 1.x وصل کردید توقع سرعت USB3 نداشته باشید، حداکثر سرعت همون سرعت hub 1.x هستش؛ یا مثلا یه device نسخه 3.0 به یه root hub نسخه 1 کردید، دیگه سرعت در حد همون usb1 میشه دیگه - اینا فک نکنم نیاز به گفتن داشته باشن )
ROOT HUB USB2
ROOT HUB USB3

20) Data Toggle : مقدار data-toggle قادر به شناسایی بسته های داده تکراری و یا از دست رفته در مدهای control، bulk و interrupt میباشد؛ transaction های IN و OUT یک مقدار data-toggle در فیلد PID بسته های دیتا دارند؛ که برا این کار از PID های زیر استفاده میشه :
DATA0 ( مخصوص تمام سرعت ها )،
DATA1 ( مخصوص تمام سرعت ها )،
DATA2 ( سرعت high فقط )،
MDATA ( سرعت high فقط )
USB Data Toggle
توضیح بیشتر درباره نحوه کارکرد Data Toggle

 

endpoint ( نقطه پایانی، مختصرا EP هم میگن بهش )

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

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

انواع endpoint ( انواع مد ارتباطی )

انواع endpoint ( انواع مد ارتباطی )

توجه : بعضی سایت ها و کتب ها رو که دیدم هر کدومشون از یه اصطلاح و جمله ای استفاده کردن، لذا من هم گفتم "انواع endpoint" و هم گفتم "انواع مد ارتباطی"،
Data Flow Types؛ Endpoint Types؛ Data Transfer Types و...
که خب همه این موارد درسته؛ حالا باز مطلب رو بخونید دوهزاریتون میوفته کامل؛ هر دستگاهی یه سری endpoint ارائه میده، مثلا میکرو lpc1768 واحد usb ییش حدود 16 تا endpoint ارائه میده، که خب endpoint0 اش مخصوص مد Controll هستش ( تمام دستگاه ها endpoint0 شون مخصوص مد Controll هستش ) و بقیه endpoint هاش بعضیاشون برا مد Interrupt بعضی برا مد Bulk و بقیه برا مد Isochronous هستند؛ به نظر من اصطلاح "انواع endpoint" یکم بهتره ولی خب بگذریم - زیاد مهم نی.

4 نوع مد تبادل داده ( 4 نوع endpoint ) تعریف شده که هر مد ( هر نوع endpoint ) کاربرد خاص خودشو داره، در ادامه یه توضیح مختصری درباره هر مد داده میشه :

1) مد کنترل ( Control ) : جهت پیکربندی دستگاه مورد استفاده قرار میگیره.
2) مد انتقال وقفه ای ( Interrupt ) : جهت ارسال دوره ای داده ها مورد استفاده قرار میگیرند.
3) مد انتقال توده/فله ای ( Bulk ) : وقتی مورد استفاده قرار مگیره که نرخ انتقال داده مهم نیست.
4) مد انتقال همزمان ( Isochronous ) : وقتی مورد استفاده قرار مگیره که نرخ انتقال داده مهم است؛ زمان تحویل داده اش ضمانت شده اما هیچ تصحیح خطایی وجود ندارد ( یعنی اگه به هر دلیلی دیتایی از بین بره نمیتونیم متوجه بشیم )

تشخیص و تصحیح خطا

غیر از مد Isochronous، بقیه مدها دارای سیستم خطایابی هستند ( دارای پکیج/بسته HANDSHAKE هستند )؛ دو نکته مهم رو باید بدونید :

1) اگه دستگاه هیچ نوع پاکت HANDSHAKE یی ( تایید متقابل، خطایابی، هر اسمی که روش میزارید ) رو نفرسته، میزبان تا 2 بار دیگر تلاش میکنه.

2) اگه دستگاه NAK ارسال کنه؛ میزبان میتونه بدون محدودیت درخواستشو تکرار کنه ( البته تا زمانی که دستگاه NAK ارسال میکنه )
این دو تا نکته تو مطالب بعدی بکارمون میاد؛ مثلا تو مطلب مربوط به کلاس CDC ( که مربوط به ساخت پورت کام مجازی هستش / یعنی پورت USB رو مثل پورت UART استفاده میکنید با این تفاوت که دیگه ماژول مبدل USB TO TTL نیاز نداریم ) که ان شاء الله به زودی قرارش میدم، این دو تا نکته تو درک نحوه عملکرد مدار و کدهای پروژه ( کدهای کتابخونه ) و آنالیز کردن اطلاعات رد و بدل شده بین میکرو و PC توسط Logic Analyzer و نرم افزارهای مانیتورینگ پورت USB بهمون کمک میکنه.

جدول مقایسه تمام مدها در سرعتهای مختلف

در شکل زیر، تقریبا تعداد زیادی از ویژگی های 4 مد فوق رو به صورت جدول قرار دادم، که میشه گفت خلاصه کل داستان این 4 تا مد هستش :

Compare all transfers mode

 

endpoints vs pipe

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

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

endpoints vs pipe

 

فرم کلی یک Transfer ( انتقال )

فرم کلی یک  Transfer ( انتقال )

Transfer Transaction Packet
خب میبینید که هر Transfer ( انتقال ) از چند Transaction ( ترنزکشن / معامه ) تشکیل شده و هر Transaction از چند Packet ( پاکت / بسته ) و هر Packet هم شامل Field ( فیلد / رشته / نخ ) های مختلفی هستش ( که بسته به نوع مد و چند تا عامل دیگه، تعداد این Transaction ها Packet ها Field ها و ... ممکنه کم و زیاد بشن و تغییر کنن ولی کلیت ماجرا مثل عکس بالا هستش )

انواع Transcation ( معامله )
خب در عنوان قبل دیدم که 4 تا مد ارتباطی در USB داریم، حالا هر کدوم از این مدها جهت تبادل دادشون، از تعدادی Transcation استفاده میکنن که در ادامه برای هر مد به صورت جدا توضیح میدم.

انواع Transcation ( معامله )

انواع Transcation به صورت مقابل هستش :
1) SETUP
2) DATA
3) STATUS
4) IN
5) OUT
توجه : هر Transaction در 1 (میکرو) فریم قرار میگیره ( برای سرعت LS و FS هر Transaction در یک فریم که 1ms هستش قرار میگیره و برا سرعت HS هر Transaction در یک میکرو فریم که 125us هستش قرار میگیره )

در ادامه میبینیم که هر مد از چه Transcation هایی استفاده میکنه.

توجه : عکس هایی که در ادامه قرار میدم، مربوط به سرعت های LS و FS هستش، برا سرعت های HS به بالا، یکم فرق میکنه که اگه دوست داشتیت میرید فایل USB Specification مربوط به نسخه USB مدنظرتون رو دانلود میکنید و میخونید ( ته مطلب هم گزاشتم لینک دانلودش رو )؛ خب، فرمت تبادل داده در هر مد رو در زیر نمودارشو قرار میدم و یه توضیح کوچیک هم میدم.

مد CONTROL : دارای 3 ترنزکشن SETUP، DATA, STATUS هستش ( که در حالت نوشتن، تعداد ترنزکشن DATA از 0 به بالا هستش و در حالت خوندن، تعداد ترنزکشن DATA از 1 به بالا هستش )
مد BULK و INTERRUPT : دارای 1 ترنزکشن IN یا OUT هستش ( برا حالت نوشتن OUT و برا حالت خوندن IN ).
مد ISOCHRONOUS : دارای 1 ترنزکشن  IN یا OUT هستش ( برا حالت نوشتن OUT و برا حالت خوندن IN ).
توجه : در تمام مدهای فوق غیر از ISOCHRONOUS هر ترنزکشن دارای 3 بسته TOKEN, DATA, HANDSHAKE هستش اما مد ISOCHRONOUS فقط 2 بسته TOKEN, DATA رو داره ( این مد با توجه به کاربردش، نیازی به بسته خطایابی یا همون HANDSHAKE نداره )

نکته 1 و 2 در "CONTROL WRITE TRANSFER" و "CONTROL READ TRANSFER" مشترک هستن و نکته 3 برای تمام مدهای 4 گانه برقرار هستش و نکته 4 هم مختص "CONTROL WRITE TRANSFER" هستش :
نکته 1 : مقدار PID پکیج DATA در ترنزکشن SETUP برابر DATA0 هستش و در ترنزکشن DATA برابر DATA1 ( و برا ترنزکشن های DATA بعدی به صورت DATA0 بعد DATA1 و... ) و در ترنزکشن STATUS برابر DATA1 هستش
نکته 2 : در ترنزکشن STATUS، در پکیج DATA، فیلد DATA وجود نداره ( اما بقیه فیلد های پکیج Data، وجود دارند )
نکته 3 : در ترنزکشن DATA، پکیج DATA، اگه تعداد بایت فیلد DATA از "حداکثر اندازه فیلد DATA" ( مثلا "حداکثر اندازه فیلد DATA" در مد CONTROL در سرعت LS برابر 8 بایت هستش و در سرعت FS یکی از مقادیر 8، 16، 32 و 64 که قابل انتخاب هستش، معمولا هم 64 بایت در نظر میگیرن ) بیشتر شد، به این صورت عمل میشه : مثلا طول فیلد دیتا 789 بایت بود و "حداکثر اندازه فیلد DATA" در مد CONTROL و در سرعت FS رو هم 64 تنظیم کردیم، باید 789 بایت رو در بسته های 64 تایی ارسال کنیم که میشه 12 تا بسته 64 بایتی + 1 بسته 21 بایتی؛ که بعد از ارسال ترنزکشن SETUP، میاد و 12 ترنکشن DATA با طول فیلد دیتا 64 بایت ارسال میشه و در آخر یه ترنزکشن DATA با طول فیلد دیتا 21 بایت ارسال میشه.
نکته 4 : ترنزکشن DATA ممکن است وجود نداشته باشد. ( همونطور که در عکس CONTROL WRITE TRANSFER میبینید، در قسمت ترنزکشن DATA نوشته 0 یا بیشتر )

در زیر دیگه فقط عکس های مربوطه رو قرار میدم، در شکلهای زیر اسم مد و وضعیتشو با رنگ قرمز، Transcation ها رو با رنگ آبی و  Packet ها که با رنگ نارنجی مشخص کردم؛ الان فقط ببینید که هر مد چند تا Transcation داره و هر Transcation چند تا Packet داره و ...؛ توضیحات بیشتر رو در عناوین بعدی میدم :
1.1) CONTROL WRITE TRANSFER
CONTROL WRITE TRANSFER

1.2) CONTROL READ TRANSFER
CONTROL READ TRANSFER

2و3) BULK AND INTERRUPT TRANSFER
BULK AND INTERRUPT TRANSFER

4) ISOCHRONOUS TRANSFER
ISOCHRONOUS TRANSFER

انواع Packet ( بسته )
خب در بالا دیدیم که هر مد شامل Transcation هایی هستش و هر Transcation یی هم شامل Packet هایی، در این قسمت لیست تمام Packet ها رو بیان میکنم.

انواع Packet ( بسته )

توجه مهم 1 : دیتای SYNC در اول همه بسته ها قرار داره ( SYNC = Synchronization )
توجه مهم 2 : دیتای EOP آخر همه بسته ها قرار داره ( EOP = End of Packet )

1) Data : در این بسته، دیتا ارسال/دریافت میشه.

فیلد PID : این فیلد مقادیر DATA0 و DATA1 رو میگیره ( مخصوص تمام سرعت ها)؛ وقتی که تعداد دیتاها زیاد هستن، به کمک این فیلد، توالی ( پشت سر هم ) دیتا ها شناسایی میشه؛ برا سرعت Endpoint ها isochronous در سرعت High-Speed غیر از DATA0 و DATA1، از DATA2 و MDATA هم استفاده میشه ( برا اطلاعات بیشتر، به بخش Data Toggle Synchronization و Data PID Sequencing از مطلب "آموزش پیشرفته پروتکل usb" مراجعه کنید )
Data Packet Format

2) Token : هاست ( میزبان ) خواسته خودش رو از طریق این بسته ارسال میکنه.

فیلد PID : به کمک این فیلد، نوع بسته Token رو تعیین میکنیم؛ 4 نوع بسته Token وجود داره :
1) In : درخواست Host را مبنی بر خواندن اطلاعات از دستگاه، را به دستگاه می رساند.
2) Out : درخواست Host را مبنی بر فرستادن اطلاعات به دستگاه، را به دستگاه می رساند.
3) Setup : به منظور شروع نوع انتقال کنترل استفاده میشود.
4) SOF : این قسمت رو من به عنوان یه بسته جدا در ادامه مطلب توضیح میدم؛ در فرمت Token برای 3 مورد بالا به صورت شکل زیر هستش ولی برا SOF یکم فرق داره ( که بجای فیلد ADDR و ENDP از فیلد FrameNumber استفاده کرده؛ فیلد FrameNumber حاوی 11 بیت هستش و مجموع دو فیلد ADDR و ENDP هم 11 بیت هستش )
Token Packet Format

3) Handshake : در هر اتصال رایانه‌ای مقداری بار اضافی وجود دارد که در اصطلاح دست‌دهی ( handshaking ) نامیده می‌شود؛ پروتکول USB برای این که مطمئن بشه که انتقال داده با موفقیت انجام شده از قابلیت تایید متقابل استفاده میکنه؛ مثلا host از device میپرسه که دیتا رو گرفتی یا نه، که device جوابشو میده ( برعکسش هم وجود داره )
توجه : مد Isochronous، بسته Handshake رو نداره ( چون این مد خطایابی نداره، برا بعضی کاربرد ها خطایابی نیاز نی )

فیلد PID : دستگاه/میزبان به کمک این فیلد، پاسخشون رو ارسال میکنن، که هر پاسخ معنای خاص خودشو داره؛ پاسخ دستگاه/میزبان یکی از 4 حالت زیر هستش ( برا سرعت های بالاتر، انواع تعداد پاسخ ها بیش از 4 تا هستش ) :
1) تصدیق کردن ( ACK = Acknowledge ) : میزبان/دستگاه داده را بدون خطا دریافت کرده. ( میزبان فقط این نوع Handshake رو برای دستگاه ارسال میکنه )
2) عدم تصدیق ( NAK = Acknowlege Negative ) : دستگاه مشغولیت ( Busy ) داشته و یا این که داده ای آماده فرستادن نداشته است ( میزبان هیچگاه مشخصه NAK را نمی فرستد )
3) STALL : تایید متقابل STALL می تواند یکی از این دو معنا را داشته باشد : 1) خواسته کنترلی پشتیبانی نمی شود ( یا اشتباه است ) 2) اندپوینت مشکل دارد ( یا متوقف شده )
4) NYET : هیچ پاسخی از گیرنده، دریافت نشد.
Handshake Packet Format

4) SOF : این کمله مخفف Start of Frame هستش؛ بسته SOF هر 1.00ms±0.0005ms یکبار در سرعت FS ( و هر 125µs±0.0625µs در سرعت HS ) توسط هاست ارسال میشه؛ به عبارت دیگه SOF اولین ترنزکشن هر (میکرو)فریم هستش ( کار این بسته دقیقا چیه؟ سرعت LS پس چی؟ )

فیلد PID : مقدار این فیلد برای بسته SOF برابر 5 هستش.
SOF Packet Format
انواع Field های موجود در Packet ها

انواع Field های موجود در Packet ها

در شکل زیر انواع مقدار ممکن برای فیلد PID رو مشاهده میکنید که بسته به مد ارتباط، نوع ترنزکشن، بسته مد نظر، مقدار این PID میتونه متفاوت باشه :
توجه 1 : تمام این PID ها توسط تمام نسخه های USB ممکنه پشتیبانی نشه، مثلا USB1.1 که فقط سرعت LS و FS رو داره و HS رو نداره نمیتونه از PID های : DATA2 و MDATA و NYET و ERR و SPLIT و PING استفاده کنه؛ ولی USB2.0 به بالا، از تمام این PID ها پشتیبانی میکنند.
توجه 2 : اگه توجه کنید تو قسمت Special، مقدار PID های PRE و ERR یکسان هستش که PRE برا سرعت FS کاربرد داره و ERR برا سرعت HS

usb PID provide information

خب در عنوان قبل دیدید که 4 نوع Packet داریم و هر Packet هم از Field هایی تشکیل شده که در ادامه توضیح میدم هر کدومشون رو :

1) SYNC : این کلمه مخفف Synchronization هستش؛ این فید برا سنکرون (همزمان) شدن داده های انتقالی و گیرنده بکار میره؛ در اول همه Packet ها قرار میگیره. توضیح بیشتر

2) PID ( مشخصه پاکت ) : این کلمه مخفف Packet ID هستش؛ که نوع Packet رو مشخص میکنه؛ و شامل 4 بیت هستش.
توجه : طول فیلد PID برابر 4 بیت هستش ولی به منظور اطمینان بیشتر در یک فیلد 8 بیتی بـه صورت دو 4 بیت پشت سر هم تکرار میشوند ( بسته دوم به صورت نات بسته اول هستش ) مثلا برا PID = 0101 دیتایی که داخل فیلد PID قرار میگیره به این صورت هستش :
4 بیت اول : 0101
4 بیت دوم : 1010
فیلد PID به صروت کامل : 10100101
فرمت فیلد PID رو در شکل زیر مشاهده میکنید :
PID Format

3) DATA : دیتایی که هاست داره ارسال میکنه یا دریافت میکنه، که در قسمت های قبلی دیدیم که بسته به سرعت انتقال ( LS یا FS ) و مد ارتباط حداکثر تعداد بیتهای فیلد دیتا متفاوت هستش.

4) ADDER : این کلمه مخفف Address هستش؛ کار فیلد آدرس، تعیین مقصد Transcation هستش؛ طول ایـن فیلد 7 بیته و مقدار آدرس صفر به هیچ دستگاهی نسبت داده نمیشه؛ بنابراین حداکثر 127 دستگاه رو میشه آدرس دهی کرد؛ دستگاههایی که به گذرگاه متصل هستند ولی هـیچ آدرسی بـه آنهـا تعلق نگرفته، باید به بسته هایی که با آدرس صفر می رسند پاسخ بدن. ( بعد از سرشماری دستگاه های متصل به ROOT HUB، هاست به هر دستگاهی یه آدرس میده، و برای ارتباط های بعدی از اون آدرس استفاده میکنه )

5) ENDP : این کلمه مخفف Endpoint هستش؛ طول این فیلد 4 بیت هستش لذا میشه 16 تا Endpoint رو کنترل کرد؛ که به کمک این فیلد، Endpoint مد نظر رو انتخاب میکنید تا دیتا توش ذخیره بشه ( دیتا ازش خونده بشه )

6) FrameNumber : همونطور که از اسمش معلومه بیانگر شماره فریم هستش؛ این فیلد 11 بیت هستش، که مقدارش میشه 0 تا 2047؛ این فیلد فقط در "SOF Packet" استفاده میشه ( توضیحات "SOF Packet" رو بخونید )

7) CRC : کلمه CRC مخفف Cyclic Redundancy Check هستش که برا بحث خطایابی بکار میره، فرمول هایی داره که در دیتاشیت USB ذکر شده و چون نیازی بهش نداریم ازش صرف نظر میکنیم ( بسته Data از CRC16 استفاده میکنه که خب 16 بیت هستش و بسته های Token و SOF از CRC5 استفاده میکنند که 5 بیت هستش؛ برای مطالعه بیشتر در این باره به مطلب "آموزش پیشرفته پروتکل usb" مراحعه کنید )

8) EOP : این کلمه مخفف End of packet هستش که در پایان تمام Packet ها قرار میگیره.

فرمت فیلد DATA از پکیج DATA از ترنزکشن SETUP

فرمت فیلد DATA از پکیج DATA از ترنزکشن SETUP

توجه : سخت ترین قسمت پروتکول USB همین قسمت هستش dash از بس طولانی هستش. laugh خودش به تنهایی میتونه 10 تا مطلب بشه !!! focus 
توجه : این عنوان در دیتاشیت USB2 به صورت "Format of Setup Data" ذکر شده که هر دو درست هستن؛ چون تو ترنزکشن SETUP فقط پکیج DATA حاوی فیلد DATA هستش؛ بقیه پکیج های این ترنزکشن فیلد DATA ندارند؛ لذا اگه بگیم "فرمت دیتای SETUP" هم درسته؛ هر چند من عنوانی رو که خودم نوشتم رو بیشتر میپسندم؛ بنظرم اینظور بهتره؛ بگذریم زیاد مهم نی.
توجه : خب همون طور که میبینید فیلد دیتای ما حاوی 8 بیت هستش ( که این موضوع هم قبلا در عنوان "انواع Transcation" در عکس های مربوط به مد Control ذکر شده بود ).
Format of Setup Data
خب همونطور که میبینید، فیلد data مد نظر ما، خودش از 5 فیلد تشکیل شده؛ که در ادامه هر فیلد رو توضیح میدم :

1) bmRequestType :
بیت 7، جهت انتقال داده در پکیج DATA از ترنزکشن DATA رو تعیین میکنه؛ اگه wLength = 0 باشه، این بیت درنظر گرفته نمیشه ( چون دیگه کاربری نداره، چون دیگه دیتایی قرار نی تبادل بشه تا بخواد جهت انتقال داشته باشه؛ به عبارت دیگه چون ترنزکشن DATA وجود نداره )

بیت 0 تا 4 بیت 5 و 6 بیت 7
گیرنده
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4...31 = Reserved
نوع
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
تعیین جهت انتقال داده
0 = Host به device
1 = Device به host
فیلد های 2 تا 5 که در ادامه قرارشون دادم، مقدارشون بستگی به این فیلد داره، اگه مقدار بیت 5 و 6 برابر 0 باشه ( Standard )؛ فیلد های دیگه همانند عکس ( جدول ) یی که در ادامه قرار میدم، مقدار دهی میشن؛ حالا اگه مقدار بیت 5و6 فیلد bmRequestType برابر 0 نبود چی؟ اون موقع فیلدهای زیر چطور مقدار دهی میشن؟
2) bRequest : -
3) wValue : -
4) wIndex :  اگه مقدار بیت 0 تا 4 فیلد bmRequestType، برابر Interface یا Endpoint بشه؛ فیلد wIndex جهت شناسایی Interface یا Endpoint بکار میره ( شماره Interface یا Endpoint در این فیلد قرار میگیره )؛ که در زیر فرمت فیلد wIndex ( که 2 بایت هستش ) رو برای حالت Interface و Endpoint مشاهده میکنید :

Word-sized field that varies according to request; typically used to pass an index or offset

اگه مقدار بیت 0 تا 4 فیلد bmRequestType، برابر Endpoint باشه، فرمت فیلد wIndex به صورت زیر میشه؛ همونطور که میبینیید بیت 0 تا 3 این فیلد حاوی شماره Endpoint هستش :
wIndex Format when Specifying an Endpoint
اگه مقدار بیت 0 تا 4 فیلد bmRequestType، برابر Interface باشه، فرمت فیلد wIndex به صورت زیر میشه؛ همونطور که میبینیید بیت 0 تا 7 این فیلد حاوی شماره Interface هستش :
wIndex Format when Specifying an Interface
5) wLength : حداکثر تعداد بایت قابل انتقال در ترنزکشن بعدی یعنی ترنزکشن DATA ( البته اگه مرحله DATA ( OUT ) TRANSCATION وجود داشته باشه )؛ اگه این فیلد 0 باشه، ترنزکشن DATA وجود ندارد؛ در یک درخواست IN، دستگاه ( Device ) هرگز نباید بیش از مقدار مشخص شده توسط فیلد wLength دیتا ارسال کند؛ ولی کمتر میتونه ارسال کنه؛ برای یک درخواست OUT، فیلد wLength همیشه مقدار دقیق دیتایی که قراره توسط HOST ارسال بشه رو مشخص میکنه؛ رفتار Device تعریف نشده اگه HOST بیش از مقدار تعیین شده توسط wLength بخواد دیتا بفرسته. ( خب اگه بخواد بیش از این مقدار دیتا بفرسته چیکار کنه؟ )
تکمیل توضیحات...

 

Standard USB Descriptor Definitions

Standard USB Descriptor Definitions

USB device ها، ویژگی هاشون رو از طریق descriptor ( توضیح دهنده ) ها گزارش میدن؛ چندین نوع مختلف descriptor داریم که اینایی که در زیر میگم همون طور که از عنوان این قسمت معلوم، descriptor های Standard هستند که در همه USB device ها استفاده میشه، حالا هر کلاس و زیر کلاسی میتونه descriptor های مختص خودشو داشته باشه ( که فعلا مربوط به بحث نیست و نیازی هم نیست )؛ هر descriptor از چندین فیلد ( مجموعه ای از بایت ها ) تشکیل شده که هر فیلد اطلاعات خاصی رو در خودش ذخیره میکنه.

خب 8 جدول تو دیتاشت USB برا این بحث هستش با نام های :

  1. Standard Device Descriptor
  2. Device Qualifier Descriptor ( for High-Speed )
  3. Standard Configuration Descriptor
  4. Other Speed Configuration Descriptor ( for High-Speed )
  5. Standard Interface Descriptor
  6. Standard Endpoint Descriptor
  7. String Descriptor
  8. UNICODE String Descriptor

 

توجه 1 : تو Descriptor های مورد 1 تا 6 میتونن string هایی داشته باشند ( مثلا نام دستگاه : "adfg" ) که ممکنه هر device یی بین 0 تا n تا string داشته باشه، لذا اگه device مدنظر، هیچ string یی نداشت، باید فیلد های مربوطه رو 0 مقدار بدیم ( فعلا در همین حد بدونید در ادامه مطلب بیشتر توضیح میدم )، وگرنه که شماره index مربوط به اون String رو به فیلد مد نظر میدیم ( Descriptor مورد 7 و 8 برا تعریف String ها بکار میاد )  ===> که میایم به Descriptor های مورد 1 تا 6 و Descriptor های مربوط به کلاس و زیرکلاس ها رو تعریف میکنیم و در انتها String ها رو تعریف میکنیم، که string اول ایندکس 1 و String بعدی ایندکس 2 و ... میگیرن؛ و در Descriptor ها میایم میگیم برا این فیلد مقدار string با ایندکس 2 رو مثلا قرار بده. ( میدونم گیج شدید - زیاد مهم نی - فقط بخونید - تو فیلم و در ادامه مطلب متوجه داستان میشید )

 

توجه 2 : اگه دستگاه، Descriptor با تعداد بایت کمتر از مقدار تعیین شده ( توسط فیلد bLength همون Descriptor ) ارسال کنه، Descriptor فوق نامعتبر هستش و باید توسط میزبان نادیده گرفته بشه؛ حالا اگه دستگاه Descriptor یی با تعداد بایت بیشتر از مقدار تعیین شده ارسال کند، ....

the extra bytes are ignored by the host, but the next descriptor is located using the length returned rather than the length expected.

 

A device may return class- or vendor-specific descriptors in two ways :

1. If the class or vendor specific descriptors use the same format as standard descriptors (e.g., start with a length byte and followed by a type byte), they must be returned interleaved with standard descriptors in the configuration information returned by a GetDescriptor(Configuration) request. In this case, the class or vendor-specific descriptors must follow a related standard descriptor they modify or extend.

2. If the class or vendor specific descriptors are independent of configuration information or use a nonstandard format, a GetDescriptor() request specifying the class or vendor specific descriptor type and index may be used to retrieve the descriptor from the device. A class or vendor specification will define the appropriate way to retrieve these descriptors.

 

توجه 2 : مورد 2 و 4 برای سرعت High-Speed هستند و کاری بهشون نداریم ( فعلا ملاک و نیاز ما سرعتهای LS و FS هستند / با HS به بالا کاری نداریم )

  1. Standard Device Descriptor ( مخصوص سرعت LS و FS، برا سرعت HS از Device Qualifier Descriptor استفاده میشه )
  2. Standard Configuration Descriptor ( مخصوص سرعت LS و FS، برا سرعت HS از Other Speed Configuration Descriptor استفاده میشه )
  3. String Descriptor ( مخصوص تمام سرعت ها )

 

در زیر یه چند تا فیلد که بین همه descriptor ها مشترک هستند رو توضیح بدم :

 

فیلد bLength : این فیلد، اولین فیلد هر descriptor یی هستش ( حالا چه descriptor های استاندارد و چه descriptor های کلاسها و زیر کلاس ها )؛ که حاوی تعداد بایت ها ی اون descriptor هستش.

 

فیلد bDescriptorType : این فیلد، دومین فیلد هر descriptor یی هستش ( حالا چه descriptor های استاندارد و چه descriptor های کلاسها و زیر کلاس ها ) که حاوی نوع descriptor هستش؛ جدول زیر برا انتخاب مقدار bDescriptorType مربوط به Descriptor های استاندارد هستش ( جدول انتخاب مقدار bDescriptorType برای کلاس و زیرکلاس ها، در مطالب مربوط به هر کلاس/زیرکلاس ذکر میشود )

توجه : جدول مربوط به توضیح دهنده INTERFACE_POWER در دیتاشت USB تعریف نشده، احتمالا باید یه Document جدا براش باشه، که دوس داشتید میرید سایت usb.org رو زیر و رو میکنید و آمارشو در میارید.
usb bDescriptorType

 

توجه : برا تعیین Class و SubClass و Protocol مورد استفاده به 2 صورت میشه اقدام کرد :

(1) در Device Descriptor بیام موارد فوق رو مشخص کنیم ( در فیلدهای bDeviceClass و bDeviceSubClass و bDeviceProtocol )؛ چیزی که من فهمیدم اینه که بهتره این 3 تا موردی که گفتم رو در این قسمت اصلا تعریف نکنیم و 0 بزاریمشون.

(2) تعریف 3 مورد فوق در Interface Descriptor ها ( در فیلد bInterfaceClass و bInterfaceSubClass و bInterfaceProtocol )، اینطوری میشه از چند کلاس استفاده کرد و هر Interface کلاس خودشو داره ( چیزی که تا الان من فهمیدم )

 

جدول مقادیر Class و SubClass و Protocol : البته این جدول برا بعضی Class ها مقادیر SubClass و Protocol رو به صورت xxH نمایش داده که باید اسناد مربوط به اون کلاس رو بررسی کرد تا بر حسب نیازمون، این دو رو مقدار دهی کنیم ( که ان شاء الله در مطالب جداگانه ای اسناد مربوط به کلاس ها رو ترجمه میکنم و آموزششو میزارم تو سایت و پروژه هایی هم میبندم تا در کنار بحث تئوری، بحث عملی رو هم پیش ببریم )
bDeviceClass _ bDeviceSubClass _ bDeviceProtocol

 

خب یه عکس پیدا کردم چیز جالبی هستش، فرم کلی Descriptor های استاندارد هر دستگاهی به صورت زیر هستش، که 1 دونه Standard Device Descriptor داره و چندین Standard Configuration Descriptor که هر Configuration میتونه تعدادی Standard Interface Descriptor داشته باشه و هر Interface هم میتونه چندین Standard Endpoint Descriptor داشته باشه.

فرم کلی Standard Descriptor

 

در ادامه Descriptor های فوق رو مورد به مورد توضیح میدم :

1) Standard Device Descriptor

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

Standard Device Descriptor

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

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

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

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

2) Standard Configuration Descriptor

در قسمت توضح دهنده "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 یکسانی ندارند، بدون محدودیت به اشتراک گزاشته بشن.

Standard Configuration Descriptor

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

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

فیلد wTotalLength

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 تا میکشه - اون وقت چی میشه؟ )

3) Standard Interface Descriptor

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 تنظیم بشه.

Standard Interface Descriptor

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 قرار میدیم.

4) Standard Endpoint Descriptor

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

Standard 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 بنویسید.

بیت 0 و 1 بیت 2 و 3 بیت 4 و 5
00 = Control
01 = Isochronous
10 = Bulk
11 = Interrupt
00 = No Synchronization
01 = Asynchronous
10 = Adaptive
11 = Synchronous
00 = Data endpoint
01 = Feedback endpoint
10 = Implicit feedback Data endpoint
11 = Reserved

(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 مجزایی داره، این دو گروه در شکل زیر نشان داده شده اند :

Example of Feedback Endpoint Numbers

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

Example of Feedback Endpoint Relationships

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

 

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 نوشته بشن.
انواع حالت مقداردهی بیت 11 و 12
00 = None (1 transaction per microframe)
01 = 1 additional (2 per microframe)
10 = 2 additional (3 per microframe)
11 = Reserved

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

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

Allowed wMaxPacketSize Values for Different Numbers of Transactions per Microframe

 

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 نیازی نداره که تغییری در رفتارش ایجاد کنه برطبق مقدار این فیلد. ( یعنی چی؟ )

5) String Descriptor

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

String Descriptor Zero, Specifying Languages Supported by the Device

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

6) UNICODE String Descriptor

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

The UNICODE string descriptor is not NULL-terminated.

UNICODE String Descriptor

توجه : ابتدا باید از 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

 

Standard Device Requests

Standard Device Requests

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

Standard Device Requests

 

توجه 1 : مقدار wValue وقتی که مقدار bRequest برابر GET_DESCRIPTOR یا SET_DESCRIPTOR هستش، از طریق جدول زیر محاسبه میشه :
usb bDescriptorType

 

توجه 2 : نحوه مقدار دهی فیلد wValue ( مربوط به درخواست های Clear Feature و Set Feature )، از طریق جدول زیر محاسبه میشه :

Standard Feature Selectors

 

توجه 3 : 3 تا اصطلاح رو توضیح بدم که در ادامه نیاز خواهید داشت ( که مربوط هستن به بحث سرشماری ولی خب اینجا هم نیاز داریم بهشون )

1) Default state : بعد از این که دستگاه به هاست وصل میشه و هنوز دیتایی رد و بدل نشده، دستگاه تو این وضعیت قرار داره، که بهش  "وضعیت پیشفرض" و یا "Default state" میگن؛ چیزی که من فهمیدم اینه ( توضیح بهتر و معتبر )

2) Address state : همونطور که میدونید وقتی هنوز دستگاه به هاست وصل نشده، دستگاه آدرسی نداره، وقتی به هاست وصل میشه بعد از چند تا تبادل داده بین این دوتا ( به کمک آدرس 0 )، هاست میاد و یه آدرس مختص به این دستگاه بهش میده ( در ضمن آدرس تا زمانی که دستگاه به هاست وصله، معتبر هستش ) و از اون به بعد به کمک این آدرس جدید با هم تبادل داده میکنند، بعد از اختصاص آدرس به دستگاه توسط هاست، دستگاه به "وضعیت آدرس" یا همون "Address state" میره که یعنی هاست به دستگاه آدرس یکتا داده.

3) Configured state : در طول مرحله سرشماری، بعد از دادن آدرس اختصاصی به دستگاه، هاست میاد یک مقدار پیکربندی به دستگاه میده تا دستگاه پیکربندی بشه؛ بعد از این میگن دستگاه در "وضعیت پیکربندی" یا "Configured state" قرار داره.

خب بریم سراغ توضیح تک تک مدهای جدول 3-9 :

1) Get Status

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

Get Status

 

توجه : اگه فیلد 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 رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :

Information Returned by a GetStatus() Request to a 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 رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :
Information Returned by a GetStatus() Request to an Interface
خب همون طور که در شکل بالا میبینید، تمام بیت ها رزرو شده هستش، و در واقع فقط 0 میفرسته، لذا چیزی برای توضیح دادن وجود نداره خخخ.

 

گیرنده Endpoint : اگه به کمک دستور GetStatus، گیرنده Endpoint رو انتخاب کرده باشیم، فرمت دیتای برگشت داده شده به صورت زیر هستش :
Information Returned by a GetStatus() Request to an 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 که به هاست میگه که اندپونیت متوقف شده.

2) Clear Feature

این درخواست جهت پاک یا غیرفعال کردن یه ویژگی خاص بکار میره! ( اصلاح توضیحات + توضیح بهتر و بیشتر )
Clear Feature
مقدار 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 : این درخواست معتبر هستش.

3) Set Feature

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

Set Feature
فیلد 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.

Test Mode Selectors

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 : این درخواست معتبر هستش.

4) Set Address

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

Set Address
فیلد 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 : رفتار دستگاه مشخص نیست.

5) Get Descriptor

این درخواست، descriptor مشخص شده رو برمیگردونه، البته اگه موجود باشه!
Get 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 : این درخواست معتبر هستش.

6) Set Descriptor

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

Set 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 : اگه این درخواست توسط دستگاه پشتیبانی بشه، این درخواست در این مد معتبر هستش.

7) Get Configuration

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

 

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

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

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

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

8) Set Configuration

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

Set 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 ارسال میکند.

9) Get Interface

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

Get Interface

 

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

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

 

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

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

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

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

10) Set Interface

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

Set Interface

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

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

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

 

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

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

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

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

11) Synch Frame

This request is used to set and then report an endpoint’s synchronization frame.
Synch 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 : این درخواست معتبر هستش.

 

Enumeration ( سرشماری )

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

 

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 با یک پیام، میزبان رو از این موضوع آگاه میکنه و میزبان هم آدرس اختصاص داده شده رو آزاد میکنه.

Enumeration Flow

 

 

 

موارد کمبود و کارام! ( اینا رو برا خودم نوشتم تا بعدا برم سراغشون، برا شما ننوشتم خخخ ) : 

مدار راه انداز مورد نیاز پروتکول USB

============

Actual data rate < bitrate for protocol overhead and bus sharing

============

ترنزکشن در سرعت های مختلف :

8.6.5 Low-speed Transactions

==================

Transaction Limits

==================

درایور usb سمت pc ( عنوان مطلب )

فایل inf. چیست

مشخصات این فایل

این فایل مخصوص چه دستگاه هایی و چه کلاس هایی هستش؟

به VID و PID مربوطه؟

===========

تکمیل مطلب “آموزش پیشرفته پروتکل usb”

==============

تکمیل و تصحیح مطلب “usb cdc class قسمت rs232”

==============

تکمیل و تصحیح نهایی مطلب زیر :

  1. آموزش آرم میکروکنترلر lpc1768 جلسه 15 usb device controller
  2. آموزش آرم میکروکنترلر lpc1768 جلسه 16 usb device controller

=============

 

 

 

منابع تهیه این مطلب
1) دیتاشیت :
1.1) USB : فایل با نام "Universal Serial Bus Specification Revision 2.0"
2) کتاب :
2.1) "اصول و راهنمای استفاده از پورت USB"؛ اثر جان اکسلسون؛ ترجمه شهرام ظریف
2.2) USB COMPLETE اثر Jan Axelson؛ ویرایش 4 ( نسخه 5 کتاب هم اومده ولی لینک دانلودشو پیدا نکردم، هر چند میومد هم فک نکنم زیاد بدردمون میخورد، چون ما اوج کارمون USB2 هستش برا بحث میکروکنترلر LPC؛ همین ویرایش 4 هم زیادی هستش )
3) مقالات فارسی :
3.1) مقاله "همه چیز درباره usb"
3.2) مقاله "چگونگی انتقال اطلاعات بین پورت USB و سخت افزار جانبی"
3.3) مقاله "USB در چند کلمه"
3.4) مقاله "USB"
4) وبسایت : usb.org
اصول و راهنمای استفاده از پورت USB
توجه : کتابی که در بالا عکسشو مشاهده میکنید رو باید برید بخرید؛ لینک زیر، مربوط به دانلود مقالات usb و کتب انگلیسی هستش و نه کتابی که در بالا عکسشو میبینید.
USB COMPLETE E4 Jan Axelson

 

 

توجه : این مطلب درحال تکمیل هستش، فعلا دارم رو کلاس های USB مطالعه میکنم، این مطلب رو هم به مرور زمان تکمیل و مشکلاتشو رفع میکنم، حقیقتا مطلب تا الان تقریبا حدود 16 هزار واژه شده، بررسی کردن دوبارش برام سخته که بیام کل مطلبو بخونم و مشکلاتشو رفع کنم، گفتم مطلبو منتشر کنم فعلا، تا مشکلات مطلب رو کاربران پیدا کنن ( اگه مشکلی باشه – غیر از اون موارد صورتی رنگ ) و حلشون کم تا مطلب کم کم تکمیل بشه – خداییش اتمام درست کار از شروعش هم سخت تره laugh

گروه پرسش و پاسخ الکترونیکی در سروش
مهدی دمیرچیلو
ارسال دیدگاه
11

1) نظرات غیر فارسی به صورت خودکار حذف میشوند ( حداقل 5 حرف فارسی وارد کنید ).

2) به موارد درخواست پروژه/کد آماده و سوالاتی که بلد نباشم پاسخ داده نمیشه.

3) برای گزاشتن کدهاتون از این سایت استفاده کنید ( طبیعتا لینک کدتون رو باید برای من بفرستید! ) : debian

4) پسورد فایل های سایت : www.dmf313.ir

  1. Avatar

    مهمان

    اکبرزاده

    دوست عزیز واقعا دست مریزاد داره.امثال شما کمک زیادی به پیشرفت ایران و ایرانی می کنند.امیدوارم در این مسیر همیشه پر انرژی و موفق باشید

  2. Avatar

    مهمان

    محمدرضا غلامزاده

    عرض سلام و خسته نباشید، اول از همه متشکرم بابت زحماتتون ، یه سوال داشتم این که نسخه های مختلف usb به غیر از قضیه frame , micro frame چه تفاوت های با هم دارند که انقدر سرعت هاشون با هم متفاوت هست؟ اگر همه نسخه ها در یک رنج باودریت در یک مد با هم ارتباط برقرار نمی‌کنند پس چطور یک هاست usb 2 می‌تونه با یک دیوایس usb 3 ارتباط برقرار کنه؟ باز هم تشکر

  3. Avatar

    مهمان

    سعید

    سلام
    خدا قوت ممنون از مطالب مفیدتون
    بنده یک دستگاهی دارم که وقتی به کامپیوتر متصل می کنم یک سری اطلاعات به کامپیوتر میفرسته(از طریق USB) که با نرم افزاری مثل hterm می تونم اون رو بخونم.(دستگاه با عنوان USB Seerial Port(COM11 شناخته می شود.)

    حالا می خوام با میکرو stm32f103c8t6 این اطلاعات دستگاه رو دریافت کنم(در واقع میکرو جای کامپیوتر را می گیرد.) میکرو باید در چه حالتی تنظیم شود(در stmcube) ؟ CDC یا HID یا ….؟

    http://dmf313.ir/معرفی-تمام-نرم-افزارهای-پورت-سریال/

    • مهدی دمیرچیلو

      نویسنده این مطلب

      مهدی دمیرچیلو

      سلام – اگه به صورت کامل هستش و طوری که گفتید ( (USB Seerial Port(COM11 ) – شما باید از UART میکرو فوق استفاده کنید.
      کلاس CDC اگه اشتباه نکنم برا uart مجازی بود – کلاس hid برا کیبورد و موس – دسته بازی و اینجور چیزا.

  4. Avatar

    مهمان

    محمدرضا غلامزاده

    سلام و خدا قوت، ببخشید میشه در مورد DATA0 و DATA1 در data toggle بیشتر توضیح بدید، اینا مقدار هستند؟

  5. Avatar

    مهمان

    رضا

    سلام مهدی.
    USB.ORG هم هست.

  6. Avatar

    مهمان

    حسین

    خوندن دیتاشیت که از اوجب واجباته، در اون بحثی نیست. فقط میخواستم بدونم که برای شروع کار و سر در آوردن اولیه از USB، این کتاب خوبه یا نه که ظاهرا به قول دوستمون دونالد گزینه های روی میز محدوده laugh
    پس من همین کتابو سعی میکنم بگیرم؛ چاره ی دیگه ای که نداریم. ظاهرا اون جوری که میگی حسابی قراره تو گل گیر کنم crazy
    در کل ممنون از سایت خوب و پاسخ گویی ات. اگر سوالی بود بازم مزاحمت میشم good

    • مهدی دمیرچیلو

      نویسنده این مطلب

      مهدی دمیرچیلو

      البته این مطلبی که نوشتن و میبینی یجورایی خلاصه کل دیتاشیت usb2 هستش – نواقص زیادی داره فعلا ولی خب برا شروع بد نی. blush

      • Avatar

        مهمان

        حسین

        آره مطالب شما که جای خود دارد. حتما از اونا استفاده میکنم. قبلا هم چندباری از مطالب سایت شما استفاده اینجوری کرده ام. مثلا دنبال کتابخونه NRF برای ATMEL STUDIO بودم، ولی چون تقریبا چیز بدرد بخوری پیدا نکردم و حس کتابخونه نوشتن هم نبود، کتابخونه آردوینوی شما رو تبدیل کردم rofl

  7. Avatar

    مهمان

    حسین

    سلام
    آقا مهدی خودت این کتاب “اصول و راهنمای استفاده از پورت USB” رو داری؟ من برای یه کاری باید USB میکروکنترلر STM32 رو راه اندازی کنم و باهاش برای کامپیوتر دیتا بفرستم ولی تقریبا هیچ اطلاعاتی از USB و این که چجوری باید روی میکروکنترلر رو پیکر بندی کنم ندارم. متاسفانه آموزش های سایت شما هم بیشتر بر پایه LPC هستش و خیلی جاهاش به کار من نمیاد. cry
    میخواستم بدونم این کتاب چه مطالبی داره و کلیات USB رو خوب توضیح داده و ارزش خرید داره یا نه؟ سوال بعدی اینه خودت ورژن خاصی از این کتابو مد نظر داری که منم بخرم؟ اگر کتاب دیگه ای هم میشناسی که فکر میکنی مناسبه لطفا معرفی کن.
    ممنون میشم اگر راهنمایی کنی smile

    • مهدی دمیرچیلو

      نویسنده این مطلب

      مهدی دمیرچیلو

      سلام – تنها کتاب که ترجمه دیتاشیت usb2 هستش و تو بازار هستش فک کنم همینه – که اونم برا سال 93 هستش و کتاب جدیدی نیستش! – شما به دیتاشیت میکرو مدنظرت مراجعه کن – این مطلب که کلیات آموزش usb هستش و برا میکرو خاصی نی – مطلب آموزش usb در lpc ( که ترجمه فقط usb device میکرو lpc1768 هستش ) رو در سایت به صورت جداگونه گزاشتم – کلیت حرفم اینه که این کتاب اولین و آخرین گزینه شما برای مطالعه فارسی هستش laugh – غیر این کتاب شما باید دیتاشیت میکرو مدنظر رو قسمت usb شو بخونید.

      کتاب هم خوبه – بد نی – از هیچی بهتره – ولی خب تو شروع کار خیلی اذیت میشی – من که خیلی اذیت شدم – نه این که مطلب و اصطلاحات جدید بودن – یکم فهم کامل و درست برام سخت بود – الانش هم در حال مطالعه کلاس های usb هستم – خود usb یه بحثیه – کلاس هاش یه چیز دیگه crazy در کل وقت بزاری حله good