Portul USB

LABORATOR 5
USB
USB a fost inventat si standardizat de către un grup de producători 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 apărut in 2000 si
revizuieşte anumite caracteristici ale standardului pentru a mari viteza de transmisie a
datelor si a-l adapta la cerinţele sistemelor multimedia moderne.
Este adevărat ca la momentul apariţiei 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 uşor de conectat. Toate aceste cerinţe au fost îndeplinite de către USB.
USB a devenit foarte popular in ceea ce priveşte extinderea către 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 legătura pentru o multitudine de mecanisme
si dispozitive (pana la 127 de dispozitive in sistemul USB).Putem lega uşor un dispozitiv
de altul si sa folosim un singur port ca un punct de legătura pentru multe dispozitive prin
simpla folosire a unui hub. Toate acestea ne permit sa privim sistemul USB ca pe o mica
reţea 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 către gazda si o detectare
automata a decuplării de la sistem. Cuplarea si decuplarea uşoara 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 când 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 funcţiona in paralel isi gaseste utilizarea in
susţinerea atât a metodelor de alocare de banda isocronă si asincronă. Isocron înseamnă
dependent de timp (data este transferata intre anumite constrângeri temporale – spre
deosebire de transmisiile sincrone in care constrângerile de timp sunt mult mai stricte),
adică lăţimea necesară de bandă este garantată, oricând o cere dispozitivul fiind
disponibila. Pe de altă parte, asincron înseamnă ca nu exista nici o garanţie 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 grămadă), aşa cum e cazul
imprimantelor si scanerelor.
USB este o magistrala sigură: in orice nivel al protocolului exista un mecanism de
detectare si corecţie a erorilor ceea ce permite o rată scăzută 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 piaţa, de exemplu Wireless USB, care promit
performante foarte bune, insa ele sunt doar la nivel de standard, implementările urmând
sa apară in viitorul apropiat. USB este cea mai folosita interfaţa din istoria
calculatoarelor, având 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 pieţei.
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 decât 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 asemănător ‘hub’-urilor folosite in reţelele 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 (numărul 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, având grija de managementul energiei pentru
dispozitivele care sunt alimentate de la magistrala (obţin energie de la bus) si răspund la
erorile magistralei pe care le si corectează. Un alt rol important al ‘hub’-ului este acela de
a coordona atât dispozitivele de viteza mica sau la viteza maxima. Când un dispozitiv
este conectat la sistem, ‘hub’-ul determină viteza la care operează acesta si pe toata
durata comunicării 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 funcţii ale USB.
Majoritatea dispozitivelor asigura doar o funcţie, dar pot fi unele care asigura mai multe
funcţii 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’. Aşa 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 foloseşte 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 funcţiona. Vitezele mai mari sunt necesare pentru transferul de informaţii cu
unităţile de stocare a datelor: HDD, memory card, camere video USB, etc.
NIVELURILE DE COMUNICARE USB

Modelul nivelurilor de comunicare USB este conform următoarelor specificaţii:
FLUXUL DE COMUNICARE USB
Comunicarea logică intre softul client pe gazda si funcţia 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 destinaţia datelor transmise prin canalul USB. O interfaţa
este compusa din endpoint-uri grupate intr-un set bine determinat. Softul client doreşte sa
transmită datele intre buffer-ii din gazda si endpoint-urile din dispozitive si astfel se
realizează respectiva interfaţa (care este asociata anumitor endpoint-uri).
Fluxul informaţional pe magistrala poate fi realizat in doua direcţii :
- OUT (afara) - datele sunt transferate dinspre gazda spre dispozitiv
- IN (înăuntru) - datele sunt transferate de la dispozitiv către gazda
I. NIVELUL FIZIC
Semnalizarea pe magistrala
Nivelul fizic este o interfaţa fizică pentru cablul USB. Principala sarcina a nivelului
fizic este aceea de a transmite si recepţiona 0 si 1 logic drept nivele de tensiune
corespunzătoare.
Cablul USB este format din 4 fire, iar semnalizarea pe bus este pe doua fire
(pereche diferenţială). Exista un fir D+ si un fir D-, astfel încât daca vrem sa transmitem
‘0’ de pe bus vom menţine 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.
Biţii sunt transmişi pe magistrala începând cu LSB.
Exista câteva 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.5µsec. Când dispozitivul recunoaşte asemenea semnătura pe portul superior al
magistralei, îl tratează ca pe un semnal RESET.
Suspend signaling : gazda poate introduce dispozitivul intr-un modul de
suspendare, astfel încât dispozitivul nu va răspunde la traficul USB. Un dispozitiv va
începe tranziţia către modul ‘suspend’ oricând 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ă. Recunoaşterea semnalului pe porturile superioare va
scoate dispozitivul din starea de suspendare.
Resume signaling : un dispozitiv care in modul ‘suspendat’ isi va relua
operaţiunile oricând va recunoaşte un semnal K pe magistrală (‘0’ diferenţial pentru
dispozitivele de mare viteza si ‘1’ pentru dispozitivele de mică viteză). De fiecare data
când gazda vrea sa ‘trezească’ dispozitivul trimite semnalul RESUME pentru cel puţin
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’
diferenţial 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 diferenţiala reprezentarea
‘1’ logic, acesta va rămâne astfel si pentru ceasul următor). Pe de alta parte, dacă dorim
să transmitem ‘0’ vom inversa valoarea perechii diferenţiale (va exista o inversare de
nivel astfel încât daca valoarea curentă este ‘1’ următoarea valoare va fi ‘0’).
Unul din efectele codării 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 biţilor
î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 recunoaşte ca parte a dopării biţilor.
SIE - Serial Interface Engine

SIE este parte atât a nivelului fizic al gazdei, cat si al dispozitivului. Datele sunt
transmise pe magistrală ca un şir de biţi in serial. SIE este responsabil pentru serializarea
si deserializarea (convertirea fluxului de date intr-unul paralel) a transmisiilor USB. SIE
este responsabil si de operaţiile 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 semnalizările SOP, EOP, RESET si RESUME de pe magistrala.
HC – Host Controller (Control gazdă)

Gazda este cel mai „deştept” element al sistemului USB şi joacă un rol unic în
sistem. Gazda iniţiază toate operaţiunile, controlează accesul media şi este motorul
principal al fluxului protocolului, aşa cum vom vedea mai târziu. 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 specificaţiilor.
Controlerul gazdă deserveşte atât gazdă, cât şi USB-ul şi are aceeaşi funcţionalitate
în fiecare sistem USB. Iată câteva din funcţiile controlerului gazdă:
FRAME GENERATION (Generarea cadrelor) – Controlerul este responsabil cu

partiţionarea timpului USB-ului în unităţi de timp astfel încât numim „frame” (cadru)
fiecare măsură de timp egală cu 1 ms (după transmiterea SOF-ului, controlerul gazdă
poate lucra cu oricare altă tranzacţie din restul cadrului). SOF conţine numărul curent al
cadrului (sau „frame”-ului) care este menţinut de către HC.
DATA PROCESSING (Procesare date) – controlerul gazdă răspunde cererilor de
date către şi dinspre gazdă.
PROTOCOL ENGINE (Motor de protocol) – Se ocupă de interfaţa nivelurilor de
protocol ale USB-ului.
ERROR HANDING (Situaţii de eroare) – controlerul gazdă se ocupă de erori cum
ar fi:
- Timeout – funcţia dispozitivului nu răspunde comenzilor;
- CRC error (eroare CRC);
- O neaşteptată supraîncărcare 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 aplicaţie (software client pe gazdă şi
funcţie dispozitiv) şi protocolul de operaţiuni al USB-ului. Nivelul codează/decodează
datele în funcţie 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 operaţiunile descrise mai sus, sistemul USB alocă lungimile de bandă şi
controlează alimentarea cu energie a „bus”-ului, permiţând astfel accesul dispozitivului la
magistrală. Sistemul USB SW este compus din software gazdă şi două interfeţe de soft
adiţionale:
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 solicitări. 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ă
interacţioneze. USBD-ul trebuie să aibă grijă de procesul de enumerare (un proces care
este activat în momentul în care dispozitivul este ataşat magistralei, iar la sfarsitul
acestuia dispozitivul este configurat complet, dispozitivul este parte integrantă a
sistemului USB şi poate răspunde fluxului de pe magistrală), analizează diversele
configuraţii ale dispozitivului şi oferă aceste „cunoştinţe” softului client. Drept parte a
acestei sarcini, USBD-ul include pipe-ul implicit (cel corespunzător endpoint-ului 0) –
deoarece atunci când 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 colecţie de endpoint-uri independente.
Fiecare punct are o adresă unică (număr) pe un timp stabilit iar dispozitivul logic USB
este adresat în mod unic la finalul procesului de enumerare. Un endpoint este
unidirecţional (cu excepţia endpoint-ului zero). Poate fi de tip IN sau de tip OUT (susţine
transferul datelor de la gazdă la dispozitiv). Asta înseamnă că pentru fluxuri
bidirecţionale avem nevoie de două endpoint-uri pentru fiecare direcţie în parte.
Combinaţia dintre adresa dispozitivului USB, numărul endpoint-ului şi direcţia acestuia
defineşte în mod unic un endpoint. Acesta este caracterizat de un anumit tip de transfer.
Aşa cum vom vedea mai târziu, 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ă susţină comunicarea prin pipe-ul implicit.
Aceasta joacă un rol important în procesul de enumerare şi este singurul canal de
comunicare cu dispozitivul la momentul ataşării. Este asociat acestui pipe endpoint-ul
zero (iată de ce numărul 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 acelaşi număr şi referirea la ele se face ca la unul singur.
Dispozitivele cu viteză mică pot susţine două endpoint-uri adiţionale (în afara celui
cu număr zero) care pot fi de tip control sau de tip întrerupere. Dispozitivele cu viteză
mare, pe de altă parte, pot susţine până la maxim 15 „puncte finale” de tip IN şi 15 de tip
OUT. Punctele adiţionale pot fi folosite doar după configurarea completă a dispozitivului.
III NIVELUL DE APLICAŢIE
Acesta apare ca soft client în gazdă şi ca funcţie în dispozitiv. Funcţia din dispozitiv
este compusă din mai multe interfeţe şi controlează funcţionarea dispozitivului. Softul
client orientează interfaţa nimerită prin transferul de date din bufferii proprii către
endpoint-urile asociate interfeţei corespunzătoare. Softul client lucrează cu o funcţie
specifică a dispozitivului independent de alte funcţii ale dispozitivului din sistem.
PROTOCOLUL USB
Gazda USB controlează majoritatea complexităţii protocolului USB, ceea ce duce la
costuri reduse şi o structura simpla pentru echipamentele periferice. Fluxul de date poate
fi direcţionat de la gazdă la dispozitiv şi invers. Transferurile USB se fac prin pachete.
Fiecare tranzacţie este compusă, de obicei, din 3 faze:
Token Phase – gazda iniţializează simbolurile indicând tipul viitoarei tranzacţii.

Data phase: datele sunt transmise în pachete. Direcţia datelor coincide cu direcţia
indicată de simbolul transmis anterior.
Handshake phase: (opţional) – pachetul „handshake” este transmis, indicând succesul
sau eşecul tranzacţiei.
USB-ul foloseşte un protocol de tip interogare – „polling”. De fiecare dată când

gazda vrea să primească date de la dispozitiv emite un simbol (un tip de pachet
informaţional pe care îl vom explica mai târziu) – semnal adresat unui dispozitiv anume.
Dacă sunt date de transmis, se transmit după primirea semnalului iar gazda nu răspunde
cu pachetul „handshake” (dacă faza de handshake este inclusă în transfer). Dacă
dispozitivul nu are nimic de transmis, gazda emite semnalul către dispozitivul următor.
Dacă, pe de altă parte, gazda doreşte să trimită data către dispozitiv, va transmite
semnalul potrivit şi datele care-i urmează.
Dispozitivul va răspunde printr-un pachet „handshake” (dacă faza handshake este
inclusă). Din momentul în care gazda termină de transmis datele către dispozitiv va emite
un nou semnal către următorul dispozitiv. Când vorbim despre protocolul USB nu-i
putem trece cu vederea robusteţea. Protocolul include mecanismul de tip handshake,
regulile „time-out” (pentru prevenirea blocării sistemului), mecanisme de control şi o rată
a erorilor foarte joasă (<10 – 10). Fiecare pachet transmis pe „bus” include biţi de control
şi protecţie CRC.
Există 4 tipuri de transfer USB:

- Transfer BULK (la grămadă): transferul BULK este o cantitate mare de
date şi este folosit de dispozitive precum imprimante, scanere, etc. Lăţimea de bandă
alocată în fiecare tranzacţie a transferului variază în funcţie de resursele „bus”-ului la
momentul respectiv. Transferurile BULK sunt sigure – atenţia la apariţia 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ă lăţimea de bandă este garantată – banda necesară
este rezervată pentru dispozitivele care folosesc acest tip de transfer. Aici se pune
mai puţin 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ă răspundă la
notificări, caracteristici şi coordonate apărute „din scurt”. Un dispozitiv care lucrează
cu acest tip de transfer defineşte intervalul de timp de care are nevoie pentru a trimite
sau primi informaţia (element caracteristic configuraţiei sale).
- Transfer CONTROL: este folosit pentru configurarea unui dispozitiv.
Configurarea se realizează în timpul procesului de enumerare dar poate fi făcută, de
asemenea, în orice moment al procesului de comunicare. Când un dispozitiv nou este
ataşat 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 către vânzător.
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 învăţa diferitele tipuri de pachete folosite de protocolul USB, să vedem

care sunt câmpurile din pachete:
- Câmpul SYNC: apare la începutul fiecărui pachet. Apare pe „bus” în
aşteptare urmat de „KJKJKJKK” (codare în NRZI). Câmpul SYNC (sincronizare)
permite echipamentelor periferice să-şi sincronizeze ceasul intern la datele de intrare.
Următoarea descriere a pachetelor va ignora acest câmp (pentru simplificare), dar nu
trebuie să uităm de existenţa sa.
- PID: câmpul de identificarea pachetului – conţine datele de identitate ale

pachetului. Deoarece sunt multe tipuri de pachete trebuie să indicăm începutul
pachetului.
Câmpul PID este compus din 8 biţi după cum se va demonstra în diagrama
următoare.
>>>>>>>>>>>> figura campul PID <<<<<<<<<<<<<<<<<<<
Primii 4 biţi se folosesc pentru a notifica identitatea pachetului, iar ceilalţi 4 pentru
control (complementari primilor 4 biţi) şi depistarea erorilor.
Tipurile PID sunt împărţite în patru mari grupe:
- SIMBOLURI (semnale) – care pot fi OUT, IN, SOF şi SETUP:
o OUT – indică faptul că datele următoare 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
conţine comenzi de setare (folosite la configurare)
- DATE: PID-ul „data” apare în pachetele de date. Poate apărea fie sub
forma DATA 0, fie DATA 1, PID diferit fiind folosit pentru ghidarea sincronizării.
- HANDSHAKE – acest PID e folosit în pachetele handshake pentru a
semnala succesul sau eşecul transferului. Poate fi fie ACK, fie NAK sau STALL.
o ACK – receptorul primeşte pachetul fără erori
o NAK – receptorul nu poate primi datele (de exemplu, din cauza
unei probleme de suprasarcină) sau transmiţătorul nu poate trimite datele
(probleme de flux)
o STALL – endpoint specific care este izolat sau comanda specifică
SETUP nu poate fi menţinută.
ADDRESS FIELD (câmpul adresă)

Este împărţit în două câmpuri:
Câmpul ADDRESS (ADDR): acesta conţine adresa funcţiei (de obicei a
dispozitivului) atribuită la procesul de enumerare. Fiecare funcţie din sistem are o adresă
unică şi pot exista într-un sistem până la 127 adrese diferite (adresa zero este rezervată şi
folosită ca adresă iniţială a unei funcţii, de aceea nu este permisă folosirea adresei zero
ca adresă permanentă).
Câmpul ENDPOINT (ENDP): câmpul respectiv conţine numărul referinţelor la

punctele de final. Fiecare punct într-o funcţie specifică este unic şi se identifică printr-un
număr. La dispozitivele cu viteză redusă pot fi două puncte adiţionale (în afară de zero).
Câmpul este folosit în simbolurile OUT, IN, SETUP.
FRAME NUMBER FIELD – numărul segmentelor ce constituie câmpul sunt

compuse din 11 biţi care indică secvenţa curentă. Câmpul este conţinut doar de simbolul
SOF care indică începutul unei secvenţe.
DATA FIELD - câmpul datelor conţine date transmise în operaţiuni. Acest câmp
poate conţine până la 10223 bytes.
CRC FIELD – CRC (verificare ciclică redundantă) este folosit pentru protejarea
tuturor câmpurilor dintr-un pachet „token” (cu excepţia câmpului PID) şi protejează
datele din pachetele de date. Câmpul CRC într-un pachet „token” este compus din 5 biţi,
în timp ce un câmp de date este compus din 16 biţi.
Să vedem acum care sunt tipurile de pachete:
- PACHET „TOKEN” – fiecare tranzacţie (operaţie) începe prin emiterea unui

semnal de către gazdă. Câmpurile ADDR şi ENDP definesc în mod unic
endpoint-ul care va primi datele în operaţiunile SETUP sau AUT şi specifică şi
endpoint-ul care este pe cale să transmită datele în operaţiunile de tip IN.
- START OF FRAME PACKET – gazda emite un pachet SOF la fiecare

milisecundă, plus sau minus 0,0005 ms. Pachetul conţine câmpul secvenţelor
sincronic de tip OUT.
- DATA PACKET – sunt compuse din PID (ceea ce indică faptul că pachetul este
un pachet de date), câmpul de date care conţine datele ce trebuie transmise şi
CRC 16 pentru protejarea câmpului de date.
- HANDSHAKE PACKETS – sunt compuse doar din PID care indică rezultatele
etapei anterioare. ACK care arată că pachetul a fost trimis fără 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 către gazdă).
- NAK – folosit în controlul fluxului informaţional 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
nemenţinerea comenzii de control) – nu este permisă a fi folosită de către gazde.
Tipuri de transfer USB

CONTROL TRANSFER – un transfer de control este compus din 3 sau 2 faze:
SETUP, DATA (opţional), STATUS, fiecare din acestea fiind compusă la rândul său 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; stabileşte o adresă permanentă pentru o funcţie;
o GET_DEVICE_DESCRIPTOR: gazda doreşte să primească decodorul
dispozitivului care conţine detalii legate de acesta: câte configuraţii,
interfeţe, 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 configuraţie este activă
la un moment dat într-un dispozitiv;
o SET_CONFIGURATION: gazda setează o configuraţie 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ă răspundă cu un pachet ACK.
Etapa DATA (dacă este inclusă) conţine fluxul de date , direcţia în cadrul etapei de setare
(de la gazdă la dispozitiv sau invers). Această etapă este compusă din una sau mai multe
operaţiuni IN sau AUT (toate operaţiunile din această etapă trebuie să fie în aceeaşi
direcţie – toate IN sau toate OUT).
Fiecare operaţiune în această etapă începe cu semnalul IN sau AUT emis de gazdă
după care datele sunt transmise (în direcţia potrivită) si operaţiunea 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ă direcţia fluxului de date în cadrul acesteia este inversă celei din etapa
DATA (dacă nu a existat o etapă DATA direcţia va fi IN). Dacă direcţia etapei status este
IN, atunci raportul este realizat în faza DATA a operaţiunii, iar dacă e OUT raportul e
realizat în faza HANDSHAKE.
Exemplu:
BULK TRANSFER: acest tip de transfer se compune din una sau mai multe
operaţiuni. Fiecare operaţiune începe cu un semnal transmis de gazdă şi care indică
direcţia transferului de date în faza următoare. Aici, datele sunt transmise în funcţie de
direcţia indicată de semnal. Dacă nu au fost depistate erori în timpul recepţionării datelor,
ultima fază este „handshake”, în care un raport legat de succesul operaţiunii 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 – direcţia fluxului
informaţional este de la dispozitiv către gazdă.
- Transfer OUT: - în care gazda „vrea” să primească date de la dispozitiv, trimite
un semnal IN către dispozitiv. Când acesta primeşte semnalul trimite datele ca
răspuns la semnal dat gazda răspunde cu un pachet ACK dacă nu au fost erori şi
nu trimite nici un „handshake” în cazul depistării unei erori.
În cazul în care dispozitivul nu poate trimite datele solicitate (subdimensionare –
FIFO este gol sau orice altă problemă), dispozitivul nu va răspunde cu pachetul de
date şi cu NAK sau STALL care indică „indispoziţia” sa de a răspunde cerinţelor
gazdei. Situaţia duce la o tranzacţie în două faze.
Dacă, pe de altă parte, gazda „vrea” să trimită date către dispozitiv, iniţiază şi
transmite un semnal OUT, iar în etapa următoare trimite datele pe care vrea să le
transmită. După primirea datelor, dispozitivul răspunde cu un pachet „handshake”.
Sunt trei tipuri de răspunsuri „handshake” ale dispozitivului: ACK indică faptul că
datele au fost trimise fără erori şi au fost acceptate de către dispozitiv. NAK care
relevă că datele au fost primite fără erori dar nu au putut fi acceptate de către
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 condiţiilor eronate de funcţionare, iar gazda nu ar mai trebui să reia transmisia.
Transferurile BULK sunt viabile datorită mecanismelor de handshake şi timeout (care
au fost menţionate anterior). Dacă e vreo problemă cu sistemul USB gazda o va
detecta şi va preveni blocarea sistemului.
INTERRUPT TRANSFER – asemănător 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 aşteptare în dispozitiv, iniţiază un semnal
IN către endpoint-ul adecvat. Dacă este găsit, funcţia va trimite detalii legate de
întrerupere cum ar fi un pachet de date în etapa următoare. Dacă gazda a primit
informaţiile fără erori, va lansa un pachet ACK în faza handshake. Dacă este depistată o
eroare, nici un handshake nu va fi transmis.
Dacă, totuşi, gazda lansează un pachet IN dar nu există întreruperi şi endpoint-ul
n-are informaţii de transmis, funcţia va returna un pachet NAK. În condiţii de eroare în
funcţie va fi transmis un pachet STALL.
Gazda va emite un semnal OUT dacă doreşte să transmită date dispozitivului, urmând
semnalului ce va fi transmis cu privire la pachetul de date. Dispozitivul, din momentul
primirii datelor, detectează erorile iar dacă acestea nu există va răspunde 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 operaţionale. Aşa
cum am menţionat 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 următoare 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.
Motivaţia tehnologiei USB a pornit de la următoarele consideraţii:
- uşurinţa de folosire: lipsa flexibilităţii in reconfigurarea PC-urilor a fost
considerata punctul slab al acestora. Deşi s-au făcut eforturi pentru uşurarea
configurării, dispozitivelor, porturile serial/paralel nu aveau caracteristica de
plug-and-play
- extinderea porturilor: adăugarea de noi dispozitive periferice a fost pana nu de
mult problematica, datorita lipsei fizice a porturilor. In acelaşi timp porturile
erau optimizate pentru câteva tipuri de periferice, iar pentru noi dispozitive nu
exista o interfaţa alternativa bidirecţională, cu un cost scăzut, si viteza
acceptabila.
Succesul introducerii USB-ului a fost rapid, astfel in 2005 analiştii au estimat ca
exista peste 500 de milioane de produse folosind interfata USB.
In prezent, pe măsura ce tehnologia avansează si dispozitivele wireless devin mai
importante, este esenţial sa se dezvolte o soluţie 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 implementării WUSB.
Conexiunile WUSB se bazează pe modelul ‘hub and spoke’: host-ul USB este un
hub in centrul reţelei, iar dispozitivele (in număr de maxim 127). Topologia este
ilustrata mai jos:
Dispozitiv
Wireless USB
Dispozitiv
Wireless USB Dispozitiv
Wireless USB
Wireless
USB
Dispozitiv Host
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),
specificaţia UWB PHY. Pentru dispozitivele WUSB, este obligatoriu suportul pentru
transmisia si recepţia 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 opţional. Toate
implementările WUSB trebuie sa suporte canalele de transmisie PHY pe canalele 9 – 15
(grupul 1).
WUSB foloseşte UWB pentru transmisia datelor
Protocolul WUSB este bazat pe TDMA, in mod similar cu protocolul USB clasic.
Hostul este cel care iniţiaza transferurile de date. Ca si in USB, fiecare transfer consta in
trei pachete: token, data si handshake. Totuşi, pentru a creste eficienta nivelului fizic prin
eliminarea tranziţiilor costisitoare intre transmisie si recepţie, hostul combina informaţia
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 câtorva factori:
- nivelul fizic este proiectat sa fie fiabil cu mecanisme de detecţie si corecţie a
erorilor
- sistemul de detecţie, deconectare si ataşare a dispozitivelor precum si
autoconfigurarea resurselor de sistem
- protocolul de recepţie 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 foloseşte 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 producători, făcând concurenta soluţiilor Bluetooth si chiar celor 802.11x pe distante
scurte
Exemplu:
Caracteristicile returate de utilitarul USBView:
Iată informaţiile schimbate intre host si periferic la conectarea unui mouse USB la
calculator returnare de Snoopy Pro:
nr dir time function data result
1 in down 0.142 GET_DESCRIPTOR_FROM_DEVICE
12 01 00 01
1 in up 0.148 CONTROL_TRANSFER 00 00 00 08 0x00000000
09 02 22 00
2 in up 0.153 CONTROL_TRANSFER 01 01 00 a0 0x00000000
09 02 22 00
4 ??? down 0.161 SELECT_CONFIGURATION
4 ??? up 0.175 SELECT_CONFIGURATION 0x00000000
5 out down 0.175 CLASS_INTERFACE -
5 out up 0.177 CONTROL_TRANSFER - 0x00000000
6 in down 0.177 GET_DESCRIPTOR_FROM_INTERFACE
05 01 09 02
6 in up 0.189 CONTROL_TRANSFER a1 01 09 01 0x00000000
7 ??? down 0.191 BULK_OR_INTERRUPT_TRANSFER -
7 ??? up 0.193 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00 0x00000000
8 ??? up 0.769 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00 0x00000000
Informaţii obţinute la conectarea unei tastaturi USB pe acelaşi port sunt prezentate in continuare:
Raport Snoopy pro simplu:
nr dir time function data Result

12 01 10 01
1 in up 0.149 CONTROL_TRANSFER 00 00 00 08 0x00000000
09 02 3b 00
09 02 3b 00
4 ??? down 0.165 SELECT_CONFIGURATION
4 ??? up 0.19 SELECT_CONFIGURATION 0x00000000
05 01 09 06
05 01 09 80
Extrageţi similaritaţile si deosebirile intre cele doua dispozitive(mouse si tastatura)

Anexa A
In detaliu informaţiile schimbate intre host si periferic la conectarea unui mouse USB la calculator
returnate de Snoopy Pro:
nr dir endpoint time function data
1 in down n/a 0.142 GET_DESCRIPTOR_FROM_DEVICE
URB Header (length: 80)
SequenceNumber: 1
Function: 000b (GET_DESCRIPTOR_FROM_DEVICE)
12 01 00 01
1 in up n/a 0.148 CONTROL_TRANSFER 00 00 00 08
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
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)
SequenceNumber: 2
09 02 22 00
2 in up n/a 0.153 CONTROL_TRANSFER 01 01 00 a0
SequenceNumber: 2
SetupPacket:
0000: 80 06 00 02 00 00 09 00
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
CONFIGURATION

0000: 09 02 22 00 01 01 00 a0 14
bLength : 0x09 (9)
wTotalLength : 0x0022 (34)
bNumInterfaces : 0x01 (1)
bConfigurationValue: 0x01 (1)
iConfiguration : 0x00 (0)
bmAttributes : 0xa0 (160)
MaxPower : 0x14 (20)
SequenceNumber: 3
09 02 22 00
3 in up n/a 0.161 CONTROL_TRANSFER 01 01 00 a0
SequenceNumber: 3
SetupPacket:
0000: 80 06 00 02 00 00 22 00
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
CONFIGURATION

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)
wTotalLength : 0x0022 (34)
4 ??? down n/a 0.161 SELECT_CONFIGURATION
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
SequenceNumber: 4
bLength: 9 (0x09)
wTotalLength: 34 (0x0022)
0x80: Bus Powered
0x20: Remote Wakeup
MaxPower: 20 (0x14)
Interface[0]:
Length: 0x0024
Class = 0x03
SubClass = 0x01
Protocol = 0x02
InterfaceHandle = 0xff2e2578
Pipe[0]:
Interval = 0x0a
PipeType = 0x03
UsbdPipeTypeInterrupt
PipeHandle = 0xff2e2594
PipeFlags = 0x00
5 out down n/a 0.175 CLASS_INTERFACE -
SequenceNumber: 5
Function: 001b (CLASS_INTERFACE)
SetupPacket:
0000: 22 0a 00 00 00 00 00 00
bmRequestType: 22
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Endpoint
bRequest: 0a
No TransferBuffer
5 out up n/a 0.177 CONTROL_TRANSFER -

SequenceNumber: 5
SetupPacket:
0000: 21 0a 00 00 00 00 00 00
bmRequestType: 21
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Interface
bRequest: 0a
No TransferBuffer
6 in down n/a 0.177 GET_DESCRIPTOR_FROM_INTERFACE

SequenceNumber: 6
Function: 0028 (GET_DESCRIPTOR_FROM_INTERFACE)
05 01 09 02
6 in up n/a 0.189 CONTROL_TRANSFER a1 01 09 01
SequenceNumber: 6
Function: 0008
(CONTROL_TRANSFER)
SetupPacket:
0000: 81 06 00 22 00 00 7e 00
bmRequestType: 81
DIR: Device-To-Host
TYPE: Standard
bRequest: 06
GET_DESCRIPTOR
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 -
SequenceNumber: 7
Function: 0009 (BULK_OR_INTERRUPT_TRANSFER)
TransferFlags: 0x00000003
No TransferBuffer

SequenceNumber: 8
No TransferBuffer
7 ??? up n/a 0.193 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00

SequenceNumber: 7

0000: 00 00 00 00
SequenceNumber: 9
No TransferBuffer
8 ??? up n/a 0.769 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00

SequenceNumber: 8
0000: 00 00 00 00
SequenceNumber: 10
No TransferBuffer
Raport Snoopy Pro complet al transferului de informaţie intre PC si tastatura USB:

SequenceNumber: 1
1 in up n/a 0.149 CONTROL_TRANSFER 12 01 10 01 00 00 00 08
SequenceNumber: 1
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
DEVICE

0000: 12 01 10 01 00 00 00 08 62 0d 1c 00 02 02 01 02
0010: 00 01
bLength : 0x12 (18)
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)
SequenceNumber: 2
2 in up n/a 0.154 CONTROL_TRANSFER 09 02 3b 00 02 01 00 a0
SequenceNumber: 2
SetupPacket:
0000: 80 06 00 02 00 00 09 00
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
CONFIGURATION

0000: 09 02 3b 00 02 01 00 a0 32
bLength : 0x09 (9)
wTotalLength : 0x003b (59)
SequenceNumber: 3
3 in up n/a 0.165 CONTROL_TRANSFER 09 02 3b 00 02 01 00 a0
SequenceNumber: 3
SetupPacket:
0000: 80 06 00 02 00 00 3b 00
bmRequestType: 80
DIR: Device-To-Host
TYPE: Standard
RECIPIENT: Device
bRequest: 06
GET_DESCRIPTOR
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)
wTotalLength : 0x003b (59)
4 ??? down n/a 0.165 SELECT_CONFIGURATION
SequenceNumber: 4
bLength: 9 (0x09)
wTotalLength: 59 (0x003b)
0x80: Bus Powered
0x20: Remote Wakeup
MaxPower: 50 (0x32)
Interface[0]:
Length: 0x0024
Class = 0x00
SubClass = 0x00
Protocol = 0x00
Pipe[0]:
Interval = 0x00
PipeType = 0x00
UsbdPipeTypeControl
PipeFlags = 0x00
Interface[1]:
Length: 0x0024
Class = 0x00
SubClass = 0x00
Protocol = 0x00
Pipe[0]:
Interval = 0x00
PipeType = 0x00
UsbdPipeTypeControl
PipeFlags = 0x00
4 ??? up n/a 0.19 SELECT_CONFIGURATION
SequenceNumber: 4
bLength: 9 (0x09)
wTotalLength: 59 (0x003b)
0x80: Bus Powered
0x20: Remote Wakeup
MaxPower: 50 (0x32)
Interface[0]:
Length: 0x0024
Class = 0x03
SubClass = 0x01
Protocol = 0x01
InterfaceHandle = 0x821dc138
Pipe[0]:
Interval = 0x18
PipeType = 0x03
PipeHandle = 0x821dc154
PipeFlags = 0x00
Interface[1]:
Length: 0x0024
Class = 0x03
SubClass = 0x00
Protocol = 0x00
InterfaceHandle = 0x81f6d108
Pipe[0]:
Interval = 0x30
PipeType = 0x03
PipeHandle = 0x81f6d124
PipeFlags = 0x00
SequenceNumber: 6
SetupPacket:
0000: 22 0a 00 00 00 00 00 00
bmRequestType: 22
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Endpoint
bRequest: 0a
No TransferBuffer

SequenceNumber: 6
SetupPacket:
0000: 21 0a 00 00 00 00 00 00
bmRequestType: 21
DIR: Host-To-Device
TYPE: Class
bRequest: 0a
No TransferBuffer

SequenceNumber: 7
7 in up n/a 0.264 CONTROL_TRANSFER 05 01 09 06 a1 01 05 07
SequenceNumber: 7
SetupPacket:
0000: 81 06 00 22 00 00 81 00
bmRequestType: 81
DIR: Device-To-Host
TYPE: Standard
bRequest: 06
GET_DESCRIPTOR
unknown

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
SequenceNumber: 8
SetupPacket:
0000: 22 0a 00 00 01 00 00 00
bmRequestType: 22
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Endpoint
bRequest: 0a
No TransferBuffer

SequenceNumber: 8
SetupPacket:
0000: 21 0a 00 00 01 00 00 00
bmRequestType: 21
DIR: Host-To-Device
TYPE: Class
bRequest: 0a
No TransferBuffer

SequenceNumber: 9
9 in up n/a 0.291 CONTROL_TRANSFER 05 01 09 80 a1 01 85 01
SequenceNumber: 9
SetupPacket:
0000: 81 06 00 22 01 00 cb 00
bmRequestType: 81
DIR: Device-To-Host
TYPE: Standard
bRequest: 06
GET_DESCRIPTOR
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
SequenceNumber: 10
No TransferBuffer

SequenceNumber: 11
No TransferBuffer

SequenceNumber: 12
No TransferBuffer

SequenceNumber: 13
No TransferBuffer

Portul USB

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Portul USB

Încărcat de

Drepturi de autor:

Formate disponibile

LABORATOR 5

UN SISTEM TIPIC USB CONSTA IN :

NIVELURILE DE COMUNICARE USB

SIE - Serial Interface Engine

HC – Host Controller (Control gazdă)

FRAME GENERATION (Generarea cadrelor) – Controlerul este responsabil cu

II. Nivelul Protocol Engine Layer

Dispozitivul logic USB

III NIVELUL DE APLICAŢIE

Token Phase – gazda iniţializează simbolurile indicând tipul viitoarei tranzacţii.

USB-ul foloseşte un protocol de tip interogare – „polling”. De fiecare dată când

Există 4 tipuri de transfer USB:

Înainte de a învăţa diferitele tipuri de pachete folosite de protocolul USB, să vedem

- PID: câmpul de identificarea pachetului – conţine datele de identitate ale

>>>>>>>>>>>> figura campul PID <<<<<<<<<<<<<<<<<<<

ADDRESS FIELD (câmpul adresă)

Câmpul ENDPOINT (ENDP): câmpul respectiv conţine numărul referinţelor la

FRAME NUMBER FIELD – numărul segmentelor ce constituie câmpul sunt

Să vedem acum care sunt tipurile de pachete:

- PACHET „TOKEN” – fiecare tranzacţie (operaţie) începe prin emiterea unui

- START OF FRAME PACKET – gazda emite un pachet SOF la fiecare

Tipuri de transfer USB

Etapa status raportează gazdei rezultatele etapelor anterioare: SETUP şi DATA.

Există două tipuri de transferuri BULK:

INTERRUPT TRANSFER – asemănător transferului BULK. Ca şi în

Comparatie intre WUSB si USB

Securitatea este suportata de toate dispozitivele WUSB. Mecanismul implementat

nr dir time function data Result

Extrageţi similaritaţile si deosebirile intre cele doua dispozitive(mouse si tastatura)

TransferBuffer: 0x00000012 (18) length

TransferBuffer: 0x00000009 (9) length

TransferBuffer: 0x00000022 (34) length

5 out up n/a 0.177 CONTROL_TRANSFER -

6 in down n/a 0.177 GET_DESCRIPTOR_FROM_INTERFACE

TransferBuffer: 0x0000003e (62) length

8 ??? down n/a 0.191 BULK_OR_INTERRUPT_TRANSFER -

7 ??? up n/a 0.193 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00

TransferBuffer: 0x00000004 (4) length

8 ??? up n/a 0.769 BULK_OR_INTERRUPT_TRANSFER 00 00 00 00

Raport Snoopy Pro complet al transferului de informaţie intre PC si tastatura USB:

1 in down n/a 0.143 GET_DESCRIPTOR_FROM_DEVICE

TransferBuffer: 0x00000012 (18) length

TransferBuffer: 0x00000009 (9) length

TransferBuffer: 0x0000003b (59) length

6 out up n/a 0.251 CONTROL_TRANSFER -

7 in down n/a 0.251 GET_DESCRIPTOR_FROM_INTERFACE

TransferBuffer: 0x00000041 (65) length

8 out up n/a 0.269 CONTROL_TRANSFER -

9 in down n/a 0.269 GET_DESCRIPTOR_FROM_INTERFACE

TransferBuffer: 0x0000008b (139) length

11 ??? down n/a 0.293 BULK_OR_INTERRUPT_TRANSFER -

12 ??? down n/a 0.294 BULK_OR_INTERRUPT_TRANSFER -

13 ??? down n/a 0.294 BULK_OR_INTERRUPT_TRANSFER -

S-ar putea să vă placă și