LABORATOR 5

USB
USB a fost inventat si standardizat de ctre un grup de productori de calculatoare si echipamente periferice in 1995. Idea era sa se aduc ntreaga gama de porturi seriale si de magistrale seriale la nivelul tehnologiei secolului 21. USB 2.0 a aprut in 2000 si revizuiete anumite caracteristici ale standardului pentru a mari viteza de transmisie a datelor si a-l adapta la cerinele sistemelor multimedia moderne. Este adevrat ca la momentul apariiei USB-ului existau mai multe standarde de comunicare intre computerul gazda si echipamentele periferice, dar inta era crearea unei tehnologii care sa combine activitatile magistalelor de viteza redusa si de viteza mare. Tehnologia permite accesul la ambele viteze, o tehnologie care asigura protocol sigur, solid, configurarea automata a dispozitivelor si o magistrala seriala care este mult simplificat si uor de conectat. Toate aceste cerine au fost ndeplinite de ctre USB. USB a devenit foarte popular in ceea ce privete extinderea ctre PC-uri. Este important sa amintim ca USB nu este un port serial, ci o magistrala seriala, un lucru care permite unui singur port pe computer sa fie o legtura pentru o multitudine de mecanisme si dispozitive (pana la 127 de dispozitive in sistemul USB).Putem lega uor un dispozitiv de altul si sa folosim un singur port ca un punct de legtura pentru multe dispozitive prin simpla folosire a unui hub. Toate acestea ne permit sa privim sistemul USB ca pe o mica reea de dispozitive. Capacitatea plug-and-play a USB-ului este unul din marile avantaje fata de alte magistrale seriale. Aceasta capacitate permite detectarea automata a unui nou dispozitiv care este introdus in sistem, o configurare automata a sa de ctre gazda si o detectare automata a decuplrii de la sistem. Cuplarea si decuplarea uoara a dispozitivelor la si din sistem permit mobilitatea pe magistrala si asigurarea sistemului la noile dispozitive fara a fi nevoie sa repornim ntregul sistem de fiecare data cnd un nou dispozitiv este detectat. O alta caracteristica importanta a USB-ului este flexibilitatea la viteze medii si mari. Aceste aspect se refera la posibilitatea USB-ului de a suporta simultan dispozitive de viteza medie (care lucreaz in 1.5 Mbps) si dispozitive de viteza mare(12 Mbps si 400Mbps). Capacitatea dispozitivelor USB de funciona in paralel isi gaseste utilizarea in susinerea att a metodelor de alocare de banda isocron si asincron. Isocron nseamn dependent de timp (data este transferata intre anumite constrngeri temporale spre deosebire de transmisiile sincrone in care constrngerile de timp sunt mult mai stricte), adic limea necesar de band este garantat, oricnd o cere dispozitivul fiind disponibila. Pe de alt parte, asincron nseamn ca nu exista nici o garanie a momentului transmisiei - datele vor fi transmise in momentul in care este posibil sa fie transmise. Dispozitivele multimedia video si audio care folosesc transferul in flux de date, vor folosi metoda isocron in timp ce genereaz transfer de tip bulk(la grmad), aa cum e cazul imprimantelor si scanerelor. USB este o magistrala sigur: in orice nivel al protocolului exista un mecanism de detectare si corecie a erorilor ceea ce permite o rat sczut a acestora. USB permite depistarea dispozitivelor defecte si realizeaz mecanismul de control al fluxului chiar prin modul in care este construit protocolul.

SISTEM TIPIC USB Alte tehnologii au nceput sa apar pe piaa, de exemplu Wireless USB, care promit performante foarte bune, insa ele sunt doar la nivel de standard, implementrile urmnd sa apar in viitorul apropiat. USB este cea mai folosita interfaa din istoria calculatoarelor, avnd in momentul de fata o baza instalata de zeci de milioane de calculatoare si se bucura de un sprijin puternic din partea diferitelor segmente ale pieei. Wireless USB se bazeaz pe succesul USB-ului prin fir si se focalizeaz asupra transmisiilor de mare viteza pe distante scurte, oferind viteza de pana la 480Mbps. In acest sens este considerat un viitor nlocuitor al tehnologiei Bluetooth. UN SISTEM TIPIC USB CONSTA IN : O gazda (host) - nu exista dect o singura gazda in sistemul USB, care este responsabila cu ntregul protocol complex (astfel se simplifica proiectarea perifericelor USB). Gazda controleaz accesul la mediul de transmisie - nimeni nu poate accesa magistrala de date daca nu a primit aprobarea de la host. Hub-ul, are rol asemntor hub-urilor folosite in reelele de calculatoare. Hub-ul asigura un punct de interconectare care permite mai multor dispozitive sa fie conectate la un singur port USB. Topologia logica a USB-ului are o structura stelara iar toate dispozitivele sunt conectate (logic) direct la gazd. Concatenarea de hub-uri este transparent pentru dispozitiv (numrul de hub-uri prin care trebuie sa treac datele). Hub-ul este conectat intre gazda si dispozitivul USB (datele curg in jos de la gazda la dispozitiv). Responsabilitatea principala a hub-urilor este aceea de a detecta conectarea sau o deconectarea dispozitivelor, avnd grija de managementul energiei pentru dispozitivele care sunt alimentate de la magistrala (obin energie de la bus) si rspund la erorile magistralei pe care le si corecteaz. Un alt rol important al hub-ului este acela de a coordona att dispozitivele de viteza mica sau la viteza maxima. Cnd un dispozitiv este conectat la sistem, hub-ul determin viteza la care opereaz acesta si pe toata durata comunicrii prin magistrala previne trecerea de la viteza mare la viteza mica si vice-versa. Dispozitivul - orice mecanism in sistemul USB care este o gazda este un dispozitiv(inclusiv hub-urile). Un dispozitiv asigura una sau mai multe funcii ale USB. Majoritatea dispozitivelor asigura doar o funcie, dar pot fi unele care asigura mai multe

funcii si care se numesc dispozitive complexe(compuse). Exist dou tipuri de dispozitive cele care au alimentare proprie sau cele care sunt alimentate de magistrala USB. Un dispozitiv care isi ia energie de la magistrala USB se numeste bus powered iar un dispozitiv care isi asigura singur energia este self powered. Aa cum am mai precizat, avem de-a face cu trei tipuri de dispozitive : - cele care opereaz la 400Mbps(Hi-speed) USB 2.0 - cele care opereaz la 12Mbps(Full-speed) USB 1.1 - cele care opereaz la 1.5Mbps(Low-speed) USB 1.0 USB folosete mai multe tipuri de conectori:

(a) (b) Conector de tip A (conectat la calculator) si conector de tip B (conectat la dispozitivul periferic). Un periferic USB precum mouse-ul sau tastatura are nevoie de numai 1.5Mbps pentru a funciona. Vitezele mai mari sunt necesare pentru transferul de informaii cu unitile de stocare a datelor: HDD, memory card, camere video USB, etc. NIVELURILE DE COMUNICARE USB Modelul nivelurilor de comunicare USB este conform urmtoarelor specificaii:

FLUXUL DE COMUNICARE USB Comunicarea logic intre softul client pe gazda si funcia dispozitivului se face prin conducte (pipe). Un pipe este o asociere intre un anumit endpoint al dispozitivului si softul adecvat de pe gazda. Endpoint-ul este sursa sau destinaia datelor transmise prin canalul USB. O interfaa este compusa din endpoint-uri grupate intr-un set bine determinat. Softul client dorete sa transmit datele intre buffer-ii din gazda si endpoint-urile din dispozitive si astfel se realizeaz respectiva interfaa (care este asociata anumitor endpoint-uri). Fluxul informaional pe magistrala poate fi realizat in doua direcii : - OUT (afara) - datele sunt transferate dinspre gazda spre dispozitiv - IN (nuntru) - datele sunt transferate de la dispozitiv ctre gazda

I. NIVELUL FIZIC
Semnalizarea pe magistrala Nivelul fizic este o interfaa fizic pentru cablul USB. Principala sarcina a nivelului fizic este aceea de a transmite si recepiona 0 si 1 logic drept nivele de tensiune corespunztoare. Cablul USB este format din 4 fire, iar semnalizarea pe bus este pe doua fire (pereche diferenial). Exista un fir D+ si un fir D-, astfel nct daca vrem sa transmitem 0 de pe bus vom menine D+ jos si D- sus si invers daca vrem sa transmitem 1.

Celelalte doua cabluri sunt Vbus(+5V) si GND(-5V) care asigur curent dispozitivului. Biii sunt transmii pe magistrala ncepnd cu LSB. Exista cteva tipuri unice de semnalizare pe magistrala: Reset signaling : gazda poate reseta dispozitivul. Acest lucru este posibil prin trimiterea SE0 (single ended zero - adic liniile D+ si D sunt tinute in starea low) mai mult de 2.5sec. Cnd dispozitivul recunoate asemenea semntura pe portul superior al magistralei, l trateaz ca pe un semnal RESET. Suspend signaling : gazda poate introduce dispozitivul intr-un modul de suspendare, astfel nct dispozitivul nu va rspunde la traficul USB. Un dispozitiv va ncepe tranziia ctre modul suspend oricnd va sesiza o stare de inactivitate pe magistrala mai mare de 3ms, dispozitivul va fi suspendat, dar nu pentru mai mult de 10ms de inactivitate pe magistral. Recunoaterea semnalului pe porturile superioare va scoate dispozitivul din starea de suspendare. Resume signaling : un dispozitiv care in modul suspendat isi va relua operaiunile oricnd va recunoate un semnal K pe magistral (0 diferenial pentru dispozitivele de mare viteza si 1 pentru dispozitivele de mic vitez). De fiecare data cnd gazda vrea sa trezeasc dispozitivul trimite semnalul RESUME pentru cel puin 20ms. Un dispozitiv poate sa se trezeasc singur - numim aceasta caracteristic remote wakeup capability. Aceasta permite dispozitivului aflat in modul suspended sa nceap transmiterea semnalului K pe magistrala si sa-si reia activitatea proprie. Semnalizarea EOP : EOP este transmis ca SE0 pe durata a 2 biti (definit diferit pentru dispozitivele de joasa si de mare viteza). Semnalul e urmat de semnalizarea J (1 diferenial pentru dispozitive de viteza maxima si 0 pentru viteze mici)un bit o data. Codarea si decodarea se realizeaz prin metoda NRZI. In codarea NRZI (Non-Return-to-Zero-Inverted Encoding) dac vrem sa transmitem 1 nu schimbam nivelul semnalului (daca perechea difereniala reprezentarea 1 logic, acesta va rmne astfel si pentru ceasul urmtor). Pe de alta parte, dac dorim s transmitem 0 vom inversa valoarea perechii difereniale (va exista o inversare de nivel astfel nct daca valoarea curent este 1 urmtoarea valoare va fi 0). Unul din efectele codrii descrise mai sus este transmiterea unui ir de 1 ce va genera un mod continuu de transmitere (linia transmiterii va fi statica - nu se va schimba in acea perioad). Pentru a preveni o asemenea stare continu, se face o dopare a biilor nainte de decodarea NRZI. Acest lucru se realizeaz prin inserarea unui 0 dup un ir de sase de 1. Decodorul ignora zeroul pe care-l recunoate ca parte a doprii biilor. SIE - Serial Interface Engine SIE este parte att a nivelului fizic al gazdei, cat si al dispozitivului. Datele sunt transmise pe magistral ca un ir de bii in serial. SIE este responsabil pentru serializarea si deserializarea (convertirea fluxului de date intr-unul paralel) a transmisiilor USB. SIE este responsabil si de operaiile de codare si decodare a fluxului de date care intra in sistem este NRZI si decodat de bitii de dopare fluxul catre exterior este NRZI si codat cu bitii de dopare. SIE este responsabil si de generare CRC pentru datele de iesire si verifica CRC pentru datele de intrare. SIE detecteaz de asemenea PID-ul (ID-ul pachetului ), precum si semnalizrile SOP, EOP, RESET si RESUME de pe magistrala. HC Host Controller (Control gazd)

Gazda este cel mai detept element al sistemului USB i joac un rol unic n sistem. Gazda iniiaz toate operaiunile, controleaz accesul media i este motorul principal al fluxului protocolului, aa cum vom vedea mai trziu. Iat de ce controlerul gazd, un element n plus hardware, este necesar pentru a se asigura c tot ce este transmis pe magistrala este corect i corespunde specificaiilor. Controlerul gazd deservete att gazd, ct i USB-ul i are aceeai funcionalitate n fiecare sistem USB. Iat cteva din funciile controlerului gazd: FRAME GENERATION (Generarea cadrelor) Controlerul este responsabil cu partiionarea timpului USB-ului n uniti de timp astfel nct numim frame (cadru) fiecare msur de timp egal cu 1 ms (dup transmiterea SOF-ului, controlerul gazd poate lucra cu oricare alt tranzacie din restul cadrului). SOF conine numrul curent al cadrului (sau frame-ului) care este meninut de ctre HC. DATA PROCESSING (Procesare date) controlerul gazd rspunde cererilor de date ctre i dinspre gazd. PROTOCOL ENGINE (Motor de protocol) Se ocup de interfaa nivelurilor de protocol ale USB-ului. ERROR HANDING (Situaii de eroare) controlerul gazd se ocup de erori cum ar fi: Timeout funcia dispozitivului nu rspunde comenzilor; CRC error (eroare CRC); O neateptat suprancrcare a datelor. REMOTE WAKEUP controlerul gazd este capabil s induc USB-ului o stare de suspendare i s detecteze un semnal de reactivare pe bus.

II. Nivelul Protocol Engine Layer

Nivelul mijlociu al modelului nivelurilor de comunicare are un rol important. Acest nivel este cel care transform datele ntre nivelul de aplicaie (software client pe gazd i funcie dispozitiv) i protocolul de operaiuni al USB-ului. Nivelul codeaz/decodeaz datele n funcie de protocol. Acest nivel este denumit diferit in dispozitivul USB gazda (numit nivel de software de sistem pentru USB), si n cazul dispozitivului periferic (numit nivel logic al dispozitivului USB). Acest lucru este permis datorit rolurilor diferite pe care cele dou componente le joac n sistem. SISTEMUL USB SW n afar de operaiunile descrise mai sus, sistemul USB aloc lungimile de band i controleaz alimentarea cu energie a bus-ului, permind astfel accesul dispozitivului la magistral. Sistemul USB SW este compus din software gazd i dou interfee de soft adiionale: Driver al controlerului gazd (Host Controller Driver - HCD) este o interfata la controlerul gazd. Scopul acesteia este de a face transparent pentru software-ul de pe host la care controller este dispozitivul conectat. DRIVERE USB (USBD): softul client (adic nivelul superior al nivelului de comunicare) solicit date de la USBD sub forma IRPs (I/O Request packets) care presupune solicitarea de transmitere/primire a datelor printr-un anumit pipe. USBD-ul are

rolul de a tratsa aceste solicitri. Un alt rol important al USBD-ului este acela de a oferi softului client o descriere general a dispozitivului cu care softului este pe cale s interacioneze. USBD-ul trebuie s aib grij de procesul de enumerare (un proces care este activat n momentul n care dispozitivul este ataat magistralei, iar la sfarsitul acestuia dispozitivul este configurat complet, dispozitivul este parte integrant a sistemului USB i poate rspunde fluxului de pe magistral), analizeaz diversele configuraii ale dispozitivului i ofer aceste cunotine softului client. Drept parte a acestei sarcini, USBD-ul include pipe-ul implicit (cel corespunztor endpoint-ului 0) deoarece atunci cnd un dispozitiv este introdus in sistem, acesta reprezint singurul mod de a comunica cu dispozitivul.

Dispozitivul logic USB Dispozitivul USB logic este compus dintr-o colecie de endpoint-uri independente. Fiecare punct are o adres unic (numr) pe un timp stabilit iar dispozitivul logic USB este adresat n mod unic la finalul procesului de enumerare. Un endpoint este unidirecional (cu excepia endpoint-ului zero). Poate fi de tip IN sau de tip OUT (susine transferul datelor de la gazd la dispozitiv). Asta nseamn c pentru fluxuri bidirecionale avem nevoie de dou endpoint-uri pentru fiecare direcie n parte. Combinaia dintre adresa dispozitivului USB, numrul endpoint-ului i direcia acestuia definete n mod unic un endpoint. Acesta este caracterizat de un anumit tip de transfer. Aa cum vom vedea mai trziu, exist 4 tipuri de transfer pe USB, fiecare endpoint fiind asociat doar cu un tip de transfer, fiind astfel caracterizat de cererea de alocare a lungimii sale de band. Toate dispozitivele USB trebuie s susin comunicarea prin pipe-ul implicit. Aceasta joac un rol important n procesul de enumerare i este singurul canal de comunicare cu dispozitivul la momentul atarii. Este asociat acestui pipe endpoint-ul zero (iat de ce numrul zero ca endpoint trebuie s fie inclus n dispozitiv i s fie de tip control). Endpoint-ul zero este de fapt format din dou endpoint-uri (unul IN i altul OUT) care mpart insa acelai numr i referirea la ele se face ca la unul singur. Dispozitivele cu vitez mic pot susine dou endpoint-uri adiionale (n afara celui cu numr zero) care pot fi de tip control sau de tip ntrerupere. Dispozitivele cu vitez mare, pe de alt parte, pot susine pn la maxim 15 puncte finale de tip IN i 15 de tip OUT. Punctele adiionale pot fi folosite doar dup configurarea complet a dispozitivului. III NIVELUL DE APLICAIE Acesta apare ca soft client n gazd i ca funcie n dispozitiv. Funcia din dispozitiv este compus din mai multe interfee i controleaz funcionarea dispozitivului. Softul client orienteaz interfaa nimerit prin transferul de date din bufferii proprii ctre endpoint-urile asociate interfeei corespunztoare. Softul client lucreaz cu o funcie specific a dispozitivului independent de alte funcii ale dispozitivului din sistem. PROTOCOLUL USB Gazda USB controleaz majoritatea complexitii protocolului USB, ceea ce duce la costuri reduse i o structura simpla pentru echipamentele periferice. Fluxul de date poate

fi direcionat de la gazd la dispozitiv i invers. Transferurile USB se fac prin pachete. Fiecare tranzacie este compus, de obicei, din 3 faze: Token Phase gazda iniializeaz simbolurile indicnd tipul viitoarei tranzacii. Data phase: datele sunt transmise n pachete. Direcia datelor coincide cu direcia indicat de simbolul transmis anterior. Handshake phase: (opional) pachetul handshake este transmis, indicnd succesul sau eecul tranzaciei. USB-ul folosete un protocol de tip interogare polling. De fiecare dat cnd gazda vrea s primeasc date de la dispozitiv emite un simbol (un tip de pachet informaional pe care l vom explica mai trziu) semnal adresat unui dispozitiv anume. Dac sunt date de transmis, se transmit dup primirea semnalului iar gazda nu rspunde cu pachetul handshake (dac faza de handshake este inclus n transfer). Dac dispozitivul nu are nimic de transmis, gazda emite semnalul ctre dispozitivul urmtor. Dac, pe de alt parte, gazda dorete s trimit data ctre dispozitiv, va transmite semnalul potrivit i datele care-i urmeaz. Dispozitivul va rspunde printr-un pachet handshake (dac faza handshake este inclus). Din momentul n care gazda termin de transmis datele ctre dispozitiv va emite un nou semnal ctre urmtorul dispozitiv. Cnd vorbim despre protocolul USB nu-i putem trece cu vederea robusteea. Protocolul include mecanismul de tip handshake, regulile time-out (pentru prevenirea blocrii sistemului), mecanisme de control i o rat a erorilor foarte joas (<10 10). Fiecare pachet transmis pe bus include bii de control i protecie CRC. Exist 4 tipuri de transfer USB: Transfer BULK (la grmad): transferul BULK este o cantitate mare de date i este folosit de dispozitive precum imprimante, scanere, etc. Limea de band alocat n fiecare tranzacie a transferului variaz n funcie de resursele bus-ului la momentul respectiv. Transferurile BULK sunt sigure atenia la apariia erorilor e foarte mare. Transfer ISOCHRONOUS (sincron): acest transfer (de care am mai vorbit) este folosit pentru dispozitive multimedia (audio, video). O caracteristic important a transferului este c limea de band este garantat banda necesar este rezervat pentru dispozitivele care folosesc acest tip de transfer. Aici se pune mai puin accent pe succesul transferului (dac toate datele ajung sau nu la timp), de vreme ce exist o toleran ridicat fa de erori. Transfer INTERRUPT: acest tip de transfer este cu laten limitat i e folosit pentru dispozitive precum mouse-ul, joystick-ul care trebuie s rspund la notificri, caracteristici i coordonate aprute din scurt. Un dispozitiv care lucreaz cu acest tip de transfer definete intervalul de timp de care are nevoie pentru a trimite sau primi informaia (element caracteristic configuraiei sale). Transfer CONTROL: este folosit pentru configurarea unui dispozitiv. Configurarea se realizeaz n timpul procesului de enumerare dar poate fi fcut, de asemenea, n orice moment al procesului de comunicare. Cnd un dispozitiv nou este ataat la sistem gazda are nevoie de date pentru a-l configura totul prin transferul de tip CONTROL. Pot fi incluse i mesaje speciale realizate de ctre vnztor.

Dispozitivele de vitez mic suport transferul de tip CONTROL i INTERRUPT, n timp ce dispozitivele de mare vitez suport toate cele 4 tipuri de transfer descrise mai sus. nainte de a nva diferitele tipuri de pachete folosite de protocolul USB, s vedem care sunt cmpurile din pachete: Cmpul SYNC: apare la nceputul fiecrui pachet. Apare pe bus n ateptare urmat de KJKJKJKK (codare n NRZI). Cmpul SYNC (sincronizare) permite echipamentelor periferice s-i sincronizeze ceasul intern la datele de intrare. Urmtoarea descriere a pachetelor va ignora acest cmp (pentru simplificare), dar nu trebuie s uitm de existena sa. PID: cmpul de identificarea pachetului conine datele de identitate ale pachetului. Deoarece sunt multe tipuri de pachete trebuie s indicm nceputul pachetului. Cmpul PID este compus din 8 bii dup cum se va demonstra n diagrama urmtoare. >>>>>>>>>>>> figura campul PID <<<<<<<<<<<<<<<<<<< Primii 4 bii se folosesc pentru a notifica identitatea pachetului, iar ceilali 4 pentru control (complementari primilor 4 bii) i depistarea erorilor. Tipurile PID sunt mprite n patru mari grupe: SIMBOLURI (semnale) care pot fi OUT, IN, SOF i SETUP: o OUT indic faptul c datele urmtoare vor fi transmise de la gazd la dispozitive; o IN datele vor fi transmise de la dispozitiv la gazd; o SOF nceput frame (secven) o SETUP pachetul va fi transmis de la gazd la dispozitiv i va conine comenzi de setare (folosite la configurare) DATE: PID-ul data apare n pachetele de date. Poate aprea fie sub forma DATA 0, fie DATA 1, PID diferit fiind folosit pentru ghidarea sincronizrii. HANDSHAKE acest PID e folosit n pachetele handshake pentru a semnala succesul sau eecul transferului. Poate fi fie ACK, fie NAK sau STALL. o ACK receptorul primete pachetul fr erori o NAK receptorul nu poate primi datele (de exemplu, din cauza unei probleme de suprasarcin) sau transmitorul nu poate trimite datele (probleme de flux) o STALL endpoint specific care este izolat sau comanda specific SETUP nu poate fi meninut. ADDRESS FIELD (cmpul adres) Este mprit n dou cmpuri:

Cmpul ADDRESS (ADDR): acesta conine adresa funciei (de obicei a dispozitivului) atribuit la procesul de enumerare. Fiecare funcie din sistem are o adres unic i pot exista ntr-un sistem pn la 127 adrese diferite (adresa zero este rezervat i folosit ca adres iniial a unei funcii, de aceea nu este permis folosirea adresei zero ca adres permanent).

Cmpul ENDPOINT (ENDP): cmpul respectiv conine numrul referinelor la punctele de final. Fiecare punct ntr-o funcie specific este unic i se identific printr-un numr. La dispozitivele cu vitez redus pot fi dou puncte adiionale (n afar de zero). Cmpul este folosit n simbolurile OUT, IN, SETUP.

FRAME NUMBER FIELD numrul segmentelor ce constituie cmpul sunt compuse din 11 bii care indic secvena curent. Cmpul este coninut doar de simbolul SOF care indic nceputul unei secvene. DATA FIELD - cmpul datelor conine date transmise n operaiuni. Acest cmp poate conine pn la 10223 bytes. CRC FIELD CRC (verificare ciclic redundant) este folosit pentru protejarea tuturor cmpurilor dintr-un pachet token (cu excepia cmpului PID) i protejeaz datele din pachetele de date. Cmpul CRC ntr-un pachet token este compus din 5 bii, n timp ce un cmp de date este compus din 16 bii. S vedem acum care sunt tipurile de pachete: PACHET TOKEN fiecare tranzacie (operaie) ncepe prin emiterea unui semnal de ctre gazd. Cmpurile ADDR i ENDP definesc n mod unic endpoint-ul care va primi datele n operaiunile SETUP sau AUT i specific i endpoint-ul care este pe cale s transmit datele n operaiunile de tip IN.

START OF FRAME PACKET gazda emite un pachet SOF la fiecare milisecund, plus sau minus 0,0005 ms. Pachetul conine cmpul secvenelor sincronic de tip OUT.

DATA PACKET sunt compuse din PID (ceea ce indic faptul c pachetul este un pachet de date), cmpul de date care conine datele ce trebuie transmise i CRC 16 pentru protejarea cmpului de date. HANDSHAKE PACKETS sunt compuse doar din PID care indic rezultatele etapei anterioare. ACK care arat c pachetul a fost trimis fr CRC sau erori, poate fi folosit n faza handshake a transferurilor de tip SETUP sau OUT (trimise de dispozitiv) sau n transferuri de tip IN (trimise de ctre gazd). NAK folosit n controlul fluxului informaional poate fi transmis n faza handshake pentru transferul de tip OUT i IN. STALL care indic unele probleme de transfer (scurt circuit ntre puncte sau nemeninerea comenzii de control) nu este permis a fi folosit de ctre gazde.

Tipuri de transfer USB CONTROL TRANSFER un transfer de control este compus din 3 sau 2 faze: SETUP, DATA (opional), STATUS, fiecare din acestea fiind compus la rndul su din 3 faze (TOKEN, DATA, HANDSHAKE). Rolul etapei SETUP este s indice dispozitivul care va seta comenzile pe care gazda le va transmite. Exist mai multe feluri de comenzi SETUP cum ar fi: o SET_ADDRESS; stabilete o adres permanent pentru o funcie; o GET_DEVICE_DESCRIPTOR: gazda dorete s primeasc decodorul dispozitivului care conine detalii legate de acesta: cte configuraii, interfee, dac este cu auto-alimentare, de pe bus etc. o GET_CONFIGURATION_DESCRIPTOR: gazda vrea s afle o configurare specific a unui dispozitiv; o GET_CONFIGURATION: gazda detecteaz care configuraie este activ la un moment dat ntr-un dispozitiv; o SET_CONFIGURATION: gazda seteaz o configuraie specific unui dispozitiv. La nceputul etapei de setare gazda emite un semnal SETUP urmat de un pachet de comenzi SETUP la care dispozitivul trebuie s rspund cu un pachet ACK. Etapa DATA (dac este inclus) conine fluxul de date , direcia n cadrul etapei de setare (de la gazd la dispozitiv sau invers). Aceast etap este compus din una sau mai multe operaiuni IN sau AUT (toate operaiunile din aceast etap trebuie s fie n aceeai direcie toate IN sau toate OUT). Fiecare operaiune n aceast etap ncepe cu semnalul IN sau AUT emis de gazd dup care datele sunt transmise (n direcia potrivit) si operaiunea se ncheie cu un pachet HANDSHAKE. Etapa status raporteaz gazdei rezultatele etapelor anterioare: SETUP i DATA. Raportul este ntotdeauna de la dispozitiv la gazd. O caracteristic important a acestei etape este c direcia fluxului de date n cadrul acesteia este invers celei din etapa DATA (dac nu a existat o etap DATA direcia va fi IN). Dac direcia etapei status este

IN, atunci raportul este realizat n faza DATA a operaiunii, iar dac e OUT raportul e realizat n faza HANDSHAKE. Exemplu:

BULK TRANSFER: acest tip de transfer se compune din una sau mai multe operaiuni. Fiecare operaiune ncepe cu un semnal transmis de gazd i care indic direcia transferului de date n faza urmtoare. Aici, datele sunt transmise n funcie de direcia indicat de semnal. Dac nu au fost depistate erori n timpul recepionrii datelor, ultima faz este handshake, n care un raport legat de succesul operaiunii este transmis. Dac au fost depistate erori, nu este trimis nici un pachet de tip handshake. Exist dou tipuri de transferuri BULK: - Transfer IN: - n care gazda solicit date de la dispozitiv direcia fluxului informaional este de la dispozitiv ctre gazd. - Transfer OUT: - n care gazda vrea s primeasc date de la dispozitiv, trimite un semnal IN ctre dispozitiv. Cnd acesta primete semnalul trimite datele ca rspuns la semnal dat gazda rspunde cu un pachet ACK dac nu au fost erori i nu trimite nici un handshake n cazul depistrii unei erori. n cazul n care dispozitivul nu poate trimite datele solicitate (subdimensionare FIFO este gol sau orice alt problem), dispozitivul nu va rspunde cu pachetul de date i cu NAK sau STALL care indic indispoziia sa de a rspunde cerinelor gazdei. Situaia duce la o tranzacie n dou faze. Dac, pe de alt parte, gazda vrea s trimit date ctre dispozitiv, iniiaz i transmite un semnal OUT, iar n etapa urmtoare trimite datele pe care vrea s le transmit. Dup primirea datelor, dispozitivul rspunde cu un pachet handshake.

Sunt trei tipuri de rspunsuri handshake ale dispozitivului: ACK indic faptul c datele au fost trimise fr erori i au fost acceptate de ctre dispozitiv. NAK care relev c datele au fost primite fr erori dar nu au putut fi acceptate de ctre dispozitiv din cauza unor probleme de ordin temporar (overflow, underflow) iar gazda ar trebui s reia transmisia. STALL, dispozitivul nu poate accepta datele din cauza condiiilor eronate de funcionare, iar gazda nu ar mai trebui s reia transmisia. Transferurile BULK sunt viabile datorit mecanismelor de handshake i timeout (care au fost menionate anterior). Dac e vreo problem cu sistemul USB gazda o va detecta i va preveni blocarea sistemului. INTERRUPT TRANSFER asemntor transferului BULK. Ca i n transferurile BULK, datele pot fi trimise de la dispozitiv la gazd i invers. Dac gazda vrea s tie ce ntrerupere este n ateptare n dispozitiv, iniiaz un semnal IN ctre endpoint-ul adecvat. Dac este gsit, funcia va trimite detalii legate de ntrerupere cum ar fi un pachet de date n etapa urmtoare. Dac gazda a primit informaiile fr erori, va lansa un pachet ACK n faza handshake. Dac este depistat o eroare, nici un handshake nu va fi transmis. Dac, totui, gazda lanseaz un pachet IN dar nu exist ntreruperi i endpoint-ul n-are informaii de transmis, funcia va returna un pachet NAK. n condiii de eroare n funcie va fi transmis un pachet STALL. Gazda va emite un semnal OUT dac dorete s transmit date dispozitivului, urmnd semnalului ce va fi transmis cu privire la pachetul de date. Dispozitivul, din momentul primirii datelor, detecteaz erorile iar dac acestea nu exist va rspunde cu ACK, NAK sau STALL (ca n cazul transferurilor BULK). Dac datele sunt corupte nu va fi transmis nici un semnal de handshake. Exemplu:

ISOCHRONOUS TRANSFER - compus din una sau dou faze operaionale. Aa cum am menionat anterior, nu exist faza handshake n transferurile sincron. Gazda

lanseaz fie un semnal IN pentru a primi date de la dispozitiv, fie OUT pentru a transmite date. n faza urmtoare datele sunt transmise n sensul cerut de semnalul gazdei emis mai nainte. Exemplu:

Wireless USB
Tehnologia Wireless USB permite viteze de 480Mbps la distante de pana la 10m, si promite ca reprezint o arhitectura scalabila care sa suporte in scurt timp viteze de 1Gbps si mai mari in continuare. Motivaia tehnologiei USB a pornit de la urmtoarele consideraii: uurina de folosire: lipsa flexibilitii in reconfigurarea PC-urilor a fost considerata punctul slab al acestora. Dei s-au fcut eforturi pentru uurarea configurrii, dispozitivelor, porturile serial/paralel nu aveau caracteristica de plug-and-play extinderea porturilor: adugarea de noi dispozitive periferice a fost pana nu de mult problematica, datorita lipsei fizice a porturilor. In acelai timp porturile erau optimizate pentru cteva tipuri de periferice, iar pentru noi dispozitive nu exista o interfaa alternativa bidirecional, cu un cost sczut, si viteza acceptabila. Succesul introducerii USB-ului a fost rapid, astfel in 2005 analitii au estimat ca exista peste 500 de milioane de produse folosind interfata USB. In prezent, pe msura ce tehnologia avanseaz si dispozitivele wireless devin mai importante, este esenial sa se dezvolte o soluie de viteza mare si eficienta ca implementare. Tehnologia radio UWB (Ultra-WideBand) are caracteristici similare modelului USB clasic, de aceea ea a stat la baza implementrii WUSB. Conexiunile WUSB se bazeaz pe modelul hub and spoke: host-ul USB este un hub in centrul reelei, iar dispozitivele (in numr de maxim 127). Topologia este ilustrata mai jos:

Dispozitiv Wireless USB Dispozitiv Wireless USB Wireless USB Host Dispozitiv Wireless USB

Dispozitiv Wireless USB

Dispozitiv Wireless USB Dispozitiv Wireless USB

In orice sistem USB exista un singur host. Wireless USB nu are porturi fizice definite, deoarece dispozitivul hub asigura extinderea porturilor. Nivelul fizic al WUSB este descris de Multiband OFDM Alliance (MBOA), specificaia UWB PHY. Pentru dispozitivele WUSB, este obligatoriu suportul pentru transmisia si recepia datelor la viteze de 53.3, 106.7, si 200 Mb/s este obligatoriu. Suportul pentru restul vitezelor, of 80, 160, 320, 400 si 480 Mb/s este opional. Toate implementrile WUSB trebuie sa suporte canalele de transmisie PHY pe canalele 9 15 (grupul 1).

WUSB folosete UWB pentru transmisia datelor Protocolul WUSB este bazat pe TDMA, in mod similar cu protocolul USB clasic. Hostul este cel care iniiaza transferurile de date. Ca si in USB, fiecare transfer consta in trei pachete: token, data si handshake. Totui, pentru a creste eficienta nivelului fizic prin eliminarea tranziiilor costisitoare intre transmisie si recepie, hostul combina informaia din tokenuri multiple intr-un singur pachet. In acesta hostul indica momentul de timp in care dispozitivul trebuie sa asculte pentru u n pachet de date OUT sau sa transmit pachetul de date IN (de tip date sau handshake) ca in figura de mai jos:

Comparatie intre WUSB si USB WUSB este un protocol dine definit si performant, lucru datorat ctorva factori: nivelul fizic este proiectat sa fie fiabil cu mecanisme de detecie si corecie a erorilor sistemul de detecie, deconectare si ataare a dispozitivelor precum si autoconfigurarea resurselor de sistem

protocolul de recepie a datelor folosind pauze pentru pachetele pierdute si eronate. Controlul traficului de date asigura folosirea bufferilor hardware in mod eficient

Securitatea este suportata de toate dispozitivele WUSB. Mecanismul implementat este bazat pe criptarea AES-128/CCM care asigura atat testarea integritatii datelor cat si criptarea acestora. Comunicarea folosete chei autentificate doar de host si de dispozitiv. In concluzie WUSB este un standard performant, bazat pe arhitectura de succes USB care urmeaz a se impune in viitor datorita caracteristicilor sale si a suportului oferit de productori, fcnd concurenta soluiilor Bluetooth si chiar celor 802.11x pe distante scurte

Exemplu: Caracteristicile returate de utilitarul USBView:

Iat informaiile schimbate intre host si periferic la conectarea unui mouse USB la calculator returnare de Snoopy Pro:

nr 1 1 2 2 3 3 4 4 5 5 6 6 7 8 7 9 8 10

dir in down in up in down in up in down in up ??? down ??? up out down out up in down in up ??? down ??? down ??? up ??? down ??? up ??? down

time 0.142 0.148 0.148 0.153 0.153 0.161 0.161 0.175 0.175 0.177 0.177 0.189 0.191 0.191 0.193 0.193 0.769 0.769

function GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER SELECT_CONFIGURATION SELECT_CONFIGURATION CLASS_INTERFACE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_INTERFACE CONTROL_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER

data 12 01 00 01 00 00 00 08 09 02 22 00 01 01 00 a0 09 02 22 00 01 01 00 a0

result

0x00000000

0x00000000

0x00000000 0x00000000

05 01 09 02 a1 01 09 01 00 00 00 00 00 00 00 00 -

0x00000000

0x00000000

0x00000000 0x00000000

Informaii obinute la conectarea unei tastaturi USB pe acelai port sunt prezentate in continuare:

Raport Snoopy pro simplu:

nr 1 1 2 2 3 3 4 4 6 6 7 7 8 8 9 9 10 11 12 13 dir in down in up in down in up in down in up ??? down ??? up out down out up in down in up out down out up in down in up ??? down ??? down ??? down ??? down time 0.143 0.149 0.149 0.154 0.154 0.165 0.165 0.19 0.248 0.251 0.251 0.264 0.267 0.269 0.269 0.291 0.293 0.293 0.294 0.294 function GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_DEVICE CONTROL_TRANSFER SELECT_CONFIGURATION SELECT_CONFIGURATION CLASS_INTERFACE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_INTERFACE CONTROL_TRANSFER CLASS_INTERFACE CONTROL_TRANSFER GET_DESCRIPTOR_FROM_INTERFACE CONTROL_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER BULK_OR_INTERRUPT_TRANSFER data 12 01 10 01 00 00 00 08 09 02 3b 00 02 01 00 a0 09 02 3b 00 02 01 00 a0 Result

0x00000000

0x00000000

0x00000000 0x00000000

05 01 09 06 a1 01 05 07 05 01 09 80 a1 01 85 01 -

0x00000000

0x00000000 0x00000000

0x00000000

Extragei similaritaile si deosebirile intre cele doua dispozitive(mouse si tastatura)

Anexa A In detaliu informaiile schimbate intre host si periferic la conectarea unui mouse USB la calculator returnate de Snoopy Pro:
nr dir endpoint time function 1 in down n/a 0.142 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 1 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 1 in up n/a 0.148 URB Header (length: 80) SequenceNumber: 1 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82162898 SetupPacket: 0000: 80 06 00 01 00 00 12 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0001 DEVICE CONTROL_TRANSFER data

12 01 00 01 00 00 00 08

TransferBuffer: 0x00000012 (18) length 0000: 12 01 00 01 00 00 00 08 b0 0a 01 00 10 00 01 02 0010: 00 01 bLength : 0x12 (18) bDescriptorType : 0x01 (1) bcdUSB : 0x0100 (256) bDeviceClass : 0x00 (0) bDeviceSubClass : 0x00 (0) bDeviceProtocol : 0x00 (0) bMaxPacketSize0 : 0x08 (8) idVendor : 0x0ab0 (2736) idProduct : 0x0001 (1) bcdDevice : 0x0010 (16) iManufacturer : 0x01 (1) iProduct : 0x02 (2) iSerialNumber : 0x00 (0) bNumConfigurations : 0x01 (1) 2 in down n/a 0.148 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 2 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 2 in up n/a 0.153 URB Header (length: 80) SequenceNumber: 2 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82162898 CONTROL_TRANSFER 09 02 22 00 01 01 00 a0

SetupPacket: 0000: 80 06 00 02 00 00 09 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0002 CONFIGURATION

TransferBuffer: 0x00000009 (9) length 0000: 09 02 22 00 01 01 00 a0 14 bLength : 0x09 (9) bDescriptorType : 0x02 (2) wTotalLength : 0x0022 (34) bNumInterfaces : 0x01 (1) bConfigurationValue: 0x01 (1) iConfiguration : 0x00 (0) bmAttributes : 0xa0 (160) MaxPower : 0x14 (20) 3 in down n/a 0.153 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 3 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 3 in up n/a 0.161 URB Header (length: 80) SequenceNumber: 3 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82162898 SetupPacket: 0000: 80 06 00 02 00 00 22 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0002 CONFIGURATION CONTROL_TRANSFER 09 02 22 00 01 01 00 a0

TransferBuffer: 0x00000022 (34) length 0000: 09 02 22 00 01 01 00 a0 14 09 04 00 00 01 03 01 0010: 02 00 09 21 00 01 00 01 22 3e 00 07 05 81 03 04 0020: 00 0a bLength : 0x09 (9) bDescriptorType : 0x02 (2) wTotalLength : 0x0022 (34) bNumInterfaces : 0x01 (1) bConfigurationValue: 0x01 (1) iConfiguration : 0x00 (0) bmAttributes : 0xa0 (160) MaxPower : 0x14 (20)

4 ??? down n/a 0.161 SELECT_CONFIGURATION URB Header (length: 60) SequenceNumber: 4 Function: 0000 (SELECT_CONFIGURATION) Configuration Descriptor: bLength: 9 (0x09) bDescriptorType: 2 (0x02) wTotalLength: 34 (0x0022) bNumInterfaces: 1 (0x01) bConfigurationValue: 1 (0x01) iConfiguration: 0 (0x00) bmAttributes: 160 (0xa0) 0x80: Bus Powered 0x20: Remote Wakeup MaxPower: 20 (0x14) (in 2 mA units, therefore 40 mA power consumption) Number of interfaces: 1 Interface[0]: Length: 0x0024 InterfaceNumber: 0x00 AlternateSetting: 0x00 Class = 0x00 SubClass = 0x00 Protocol = 0x00 InterfaceHandle = 0x00000000 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0000 EndpointAddress = 0x00 Interval = 0x00 PipeType = 0x00 UsbdPipeTypeControl PipeHandle = 0x00000000 MaxTransferSize = 0x00001000 PipeFlags = 0x00 4 ??? up n/a 0.175 SELECT_CONFIGURATION URB Header (length: 60) SequenceNumber: 4 Function: 0000 (SELECT_CONFIGURATION) Configuration Descriptor: bLength: 9 (0x09) bDescriptorType: 2 (0x02) wTotalLength: 34 (0x0022) bNumInterfaces: 1 (0x01) bConfigurationValue: 1 (0x01) iConfiguration: 0 (0x00) bmAttributes: 160 (0xa0) 0x80: Bus Powered 0x20: Remote Wakeup MaxPower: 20 (0x14) (in 2 mA units, therefore 40 mA power consumption) Number of interfaces: 1 Interface[0]: Length: 0x0024 InterfaceNumber: 0x00

AlternateSetting: 0x00 Class = 0x03 SubClass = 0x01 Protocol = 0x02 InterfaceHandle = 0xff2e2578 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0004 EndpointAddress = 0x81 Interval = 0x0a PipeType = 0x03 UsbdPipeTypeInterrupt PipeHandle = 0xff2e2594 MaxTransferSize = 0x00001000 PipeFlags = 0x00 5 out down n/a URB Header (length: 80) SequenceNumber: 5 Function: 001b (CLASS_INTERFACE) PipeHandle: 00000000 SetupPacket: 0000: 22 0a 00 00 00 00 00 00 bmRequestType: 22 DIR: Host-To-Device TYPE: Class RECIPIENT: Endpoint bRequest: 0a No TransferBuffer

0.175

CLASS_INTERFACE

5 out up n/a 0.177 URB Header (length: 80) SequenceNumber: 5 Function: 0008 (CONTROL_TRANSFER) PipeHandle: 82162898 SetupPacket: 0000: 21 0a 00 00 00 00 00 00 bmRequestType: 21 DIR: Host-To-Device TYPE: Class RECIPIENT: Interface bRequest: 0a No TransferBuffer

CONTROL_TRANSFER

6 in down n/a 0.177 GET_DESCRIPTOR_FROM_INTERFACE URB Header (length: 80) SequenceNumber: 6 Function: 0028 (GET_DESCRIPTOR_FROM_INTERFACE) 6 in up URB Header (length: 80) SequenceNumber: 6 Function: 0008 (CONTROL_TRANSFER) n/a 0.189 CONTROL_TRANSFER 05 01 09 02 a1 01 09 01

PipeHandle: 82162898 SetupPacket: 0000: 81 06 00 22 00 00 7e 00 bmRequestType: 81 DIR: Device-To-Host TYPE: Standard RECIPIENT: Interface bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0022 unknown

TransferBuffer: 0x0000003e (62) length 0000: 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 05 0010: 15 00 25 01 75 01 95 05 81 02 75 03 95 01 81 01 0020: 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 0030: 09 38 15 81 25 7f 75 08 95 01 81 06 c0 c0 7 ??? down n/a 0.191 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 7 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer 8 ??? down n/a 0.191 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 8 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer 7 ??? up n/a 0.193 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 7 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 TransferBuffer: 0x00000004 (4) length 0000: 00 00 00 00 9 ??? down n/a 0.193 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 9 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer 8 ??? up n/a 0.769 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 8 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003

00 00 00 00

00 00 00 00

TransferBuffer: 0x00000004 (4) length 0000: 00 00 00 00 10 ??? down n/a 0.769 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 10 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer

Raport Snoopy Pro complet al transferului de informaie intre PC si tastatura USB:

1 in down n/a 0.143 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 1 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 1 in up n/a 0.149 CONTROL_TRANSFER URB Header (length: 80) SequenceNumber: 1 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 80 06 00 01 00 00 12 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0001 DEVICE TransferBuffer: 0x00000012 (18) length 0000: 12 01 10 01 00 00 00 08 62 0d 1c 00 02 02 01 02 0010: 00 01 bLength : 0x12 (18) bDescriptorType : 0x01 (1) bcdUSB : 0x0110 (272) bDeviceClass : 0x00 (0) bDeviceSubClass : 0x00 (0) bDeviceProtocol : 0x00 (0) bMaxPacketSize0 : 0x08 (8) idVendor : 0x0d62 (3426) idProduct : 0x001c (28) bcdDevice : 0x0202 (514) iManufacturer : 0x01 (1) iProduct : 0x02 (2) iSerialNumber : 0x00 (0) bNumConfigurations : 0x01 (1)

12 01 10 01 00 00 00 08

2 in down n/a 0.149 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 2 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 2 in up n/a 0.154 CONTROL_TRANSFER URB Header (length: 80) SequenceNumber: 2 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 80 06 00 02 00 00 09 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0002 CONFIGURATION

09 02 3b 00 02 01 00 a0

TransferBuffer: 0x00000009 (9) length 0000: 09 02 3b 00 02 01 00 a0 32 bLength : 0x09 (9) bDescriptorType : 0x02 (2) wTotalLength : 0x003b (59) bNumInterfaces : 0x02 (2) bConfigurationValue: 0x01 (1) iConfiguration : 0x00 (0) bmAttributes : 0xa0 (160) MaxPower : 0x32 (50) 3 in down n/a 0.154 GET_DESCRIPTOR_FROM_DEVICE URB Header (length: 80) SequenceNumber: 3 Function: 000b (GET_DESCRIPTOR_FROM_DEVICE) 3 in up n/a 0.165 CONTROL_TRANSFER URB Header (length: 80) SequenceNumber: 3 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 80 06 00 02 00 00 3b 00 bmRequestType: 80 DIR: Device-To-Host TYPE: Standard RECIPIENT: Device bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0002

09 02 3b 00 02 01 00 a0

CONFIGURATION

TransferBuffer: 0x0000003b (59) length 0000: 09 02 3b 00 02 01 00 a0 32 09 04 00 00 01 03 01 0010: 01 00 09 21 00 01 00 01 22 41 00 07 05 81 03 08 0020: 00 18 09 04 01 00 01 03 00 00 00 09 21 00 01 00 0030: 01 22 8b 00 07 05 82 03 08 00 30 bLength : 0x09 (9) bDescriptorType : 0x02 (2) wTotalLength : 0x003b (59) bNumInterfaces : 0x02 (2) bConfigurationValue: 0x01 (1) iConfiguration : 0x00 (0) bmAttributes : 0xa0 (160) MaxPower : 0x32 (50) 4 ??? down n/a 0.165 SELECT_CONFIGURATION URB Header (length: 96) SequenceNumber: 4 Function: 0000 (SELECT_CONFIGURATION) Configuration Descriptor: bLength: 9 (0x09) bDescriptorType: 2 (0x02) wTotalLength: 59 (0x003b) bNumInterfaces: 2 (0x02) bConfigurationValue: 1 (0x01) iConfiguration: 0 (0x00) bmAttributes: 160 (0xa0) 0x80: Bus Powered 0x20: Remote Wakeup MaxPower: 50 (0x32) (in 2 mA units, therefore 100 mA power consumption) Number of interfaces: 2 Interface[0]: Length: 0x0024 InterfaceNumber: 0x00 AlternateSetting: 0x00 Class = 0x00 SubClass = 0x00 Protocol = 0x00 InterfaceHandle = 0x00000000 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0000 EndpointAddress = 0x00 Interval = 0x00 PipeType = 0x00 UsbdPipeTypeControl PipeHandle = 0x00000000 MaxTransferSize = 0x00001000

PipeFlags = 0x00 Interface[1]: Length: 0x0024 InterfaceNumber: 0x01 AlternateSetting: 0x00 Class = 0x00 SubClass = 0x00 Protocol = 0x00 InterfaceHandle = 0x00000000 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0000 EndpointAddress = 0x00 Interval = 0x00 PipeType = 0x00 UsbdPipeTypeControl PipeHandle = 0x00000000 MaxTransferSize = 0x00001000 PipeFlags = 0x00 4 ??? up n/a 0.19 SELECT_CONFIGURATION URB Header (length: 96) SequenceNumber: 4 Function: 0000 (SELECT_CONFIGURATION) Configuration Descriptor: bLength: 9 (0x09) bDescriptorType: 2 (0x02) wTotalLength: 59 (0x003b) bNumInterfaces: 2 (0x02) bConfigurationValue: 1 (0x01) iConfiguration: 0 (0x00) bmAttributes: 160 (0xa0) 0x80: Bus Powered 0x20: Remote Wakeup MaxPower: 50 (0x32) (in 2 mA units, therefore 100 mA power consumption) Number of interfaces: 2 Interface[0]: Length: 0x0024 InterfaceNumber: 0x00 AlternateSetting: 0x00 Class = 0x03 SubClass = 0x01 Protocol = 0x01 InterfaceHandle = 0x821dc138 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0008 EndpointAddress = 0x81 Interval = 0x18 PipeType = 0x03

UsbdPipeTypeInterrupt PipeHandle = 0x821dc154 MaxTransferSize = 0x00001000 PipeFlags = 0x00 Interface[1]: Length: 0x0024 InterfaceNumber: 0x01 AlternateSetting: 0x00 Class = 0x03 SubClass = 0x00 Protocol = 0x00 InterfaceHandle = 0x81f6d108 NumberOfPipes = 0x00000001 Pipe[0]: MaximumPacketSize = 0x0008 EndpointAddress = 0x82 Interval = 0x30 PipeType = 0x03 UsbdPipeTypeInterrupt PipeHandle = 0x81f6d124 MaxTransferSize = 0x00001000 PipeFlags = 0x00 6 out down n/a 0.248 CLASS_INTERFACE URB Header (length: 80) SequenceNumber: 6 Function: 001b (CLASS_INTERFACE) PipeHandle: 00000000 SetupPacket: 0000: 22 0a 00 00 00 00 00 00 bmRequestType: 22 DIR: Host-To-Device TYPE: Class RECIPIENT: Endpoint bRequest: 0a No TransferBuffer 6 out up n/a 0.251 CONTROL_TRANSFER URB Header (length: 80) SequenceNumber: 6 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 21 0a 00 00 00 00 00 00 bmRequestType: 21 DIR: Host-To-Device TYPE: Class RECIPIENT: Interface bRequest: 0a

No TransferBuffer 7 in down n/a 0.251 GET_DESCRIPTOR_FROM_INTERFACE URB Header (length: 80) SequenceNumber: 7 Function: 0028 (GET_DESCRIPTOR_FROM_INTERFACE) 7 in up n/a 0.264 CONTROL_TRANSFER 05 01 09 06 a1 01 05 07 URB Header (length: 80) SequenceNumber: 7 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 81 06 00 22 00 00 81 00 bmRequestType: 81 DIR: Device-To-Host TYPE: Standard RECIPIENT: Interface bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0022 unknown

TransferBuffer: 0x00000041 (65) length 0000: 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 0010: 95 08 75 01 81 02 95 08 75 01 81 01 05 08 19 01 0020: 29 03 95 03 75 01 91 02 95 01 75 05 91 01 05 07 0030: 19 00 2a ff 00 15 00 26 ff 00 95 06 75 08 81 00 0040: c0 8 out down n/a 0.267 CLASS_INTERFACE URB Header (length: 80) SequenceNumber: 8 Function: 001b (CLASS_INTERFACE) PipeHandle: 00000000 SetupPacket: 0000: 22 0a 00 00 01 00 00 00 bmRequestType: 22 DIR: Host-To-Device TYPE: Class RECIPIENT: Endpoint bRequest: 0a No TransferBuffer 8 out up n/a URB Header (length: 80) SequenceNumber: 8 0.269 CONTROL_TRANSFER

Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 21 0a 00 00 01 00 00 00 bmRequestType: 21 DIR: Host-To-Device TYPE: Class RECIPIENT: Interface bRequest: 0a No TransferBuffer 9 in down n/a 0.269 GET_DESCRIPTOR_FROM_INTERFACE URB Header (length: 80) SequenceNumber: 9 Function: 0028 (GET_DESCRIPTOR_FROM_INTERFACE) 9 in up n/a 0.291 CONTROL_TRANSFER 05 01 09 80 a1 01 85 01 URB Header (length: 80) SequenceNumber: 9 Function: 0008 (CONTROL_TRANSFER) PipeHandle: ff5b0900 SetupPacket: 0000: 81 06 00 22 01 00 cb 00 bmRequestType: 81 DIR: Device-To-Host TYPE: Standard RECIPIENT: Interface bRequest: 06 GET_DESCRIPTOR Descriptor Type: 0x0022 unknown

TransferBuffer: 0x0000008b (139) length 0000: 05 01 09 80 a1 01 85 01 19 81 29 83 15 00 25 01 0010: 75 01 95 03 81 02 75 05 95 01 81 01 c0 05 0c 09 0020: 01 a1 01 85 02 25 01 15 00 75 01 0a 25 02 0a 24 0030: 02 0a 27 02 0a 26 02 0a 21 02 0a 2a 02 0a 23 02 0040: 0a 8a 01 95 08 81 02 0a e2 00 0a ea 00 0a e9 00 0050: 0a cd 00 0a b7 00 0a b6 00 0a b5 00 0a 94 01 95 0060: 08 81 02 0a 92 01 95 01 81 02 95 07 81 01 c0 06 0070: 00 ff 09 01 a1 01 85 03 25 01 15 00 75 01 19 01 0080: 29 09 95 09 81 02 95 07 81 01 c0 10 ??? down n/a 0.293 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 10 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003

No TransferBuffer 11 ??? down n/a 0.293 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 11 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer 12 ??? down n/a 0.294 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 12 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer 13 ??? down n/a 0.294 BULK_OR_INTERRUPT_TRANSFER URB Header (length: 72) SequenceNumber: 13 Function: 0009 (BULK_OR_INTERRUPT_TRANSFER) TransferFlags: 0x00000003 No TransferBuffer -