3. Genealogía y alcance
Genealogía
Enero de 1996, versión 1.0.
Velocidad 1,5 Mbps.
Intel, Compaq, NEC, y Microsoft
Septiembre de 1998, versión 1.1.
Velocidades de 1,5 (Low Speed) ó 12Mbps (Full Speed)
Mejora en la asignación de ancho de banda a los dispositivos, a
través de la incorporación de nuevos tipos de transferencias.
Septiembre del 2000 versión 2.0
Velocidades de 1,5 (Low Speed), 12(Full Speed), o 480 Mbps (High
Speed)
Alcance:
Nuestro estudio se centrará en la versión 1.1, tratando de
introducir conceptos de 2.0.
Autor: Alejandro Furfaro 3
4. Principales metas propuestas
Expansión de periféricos sencilla
Detección automática de un nuevo dispositivo
Conexión y desconexión sin reiniciar el equipo
Soporte plug & play.
Velocidades de transferencia de hasta 480 Mbits/seg.
a bajo costo.
Soporte a aplicaciones multimedia real time.
Integración con dispositivos electrónicos (VCR, por
ejemplo), aumentando de esta manera las
capacidades de la PC.
Interfaz de software standard independiente del
dispositivo que se desee conectar.
Autor: Alejandro Furfaro 4
5. Arquitectura I
El Universal Serial Bus está organizado como
El Universal Serial Bus está organizado como
una estructura jerárquica, controlada por un
una estructura jerárquica, controlada por un
dispositivo denominado host controller que
dispositivo denominado host controller que
HOST HOST Tier 1
Hub root
reside en la PC.
reside en la PC.
Tier 2
Hub1 Func
Tier 3
Hub2
Func Se dispone además de
Se dispone además de
Func
Tier 4 un dispositivo
un dispositivo
denominado Hub ,, en el
denominado Hub en el
Func
USB 1.1 Hub3 Hub4 Func Tier 5 centro de cada estrella,
centro de cada estrella,
lográndose de esta forma
lográndose de esta forma
Tier 6
un anidamiento multinivel
un anidamiento multinivel
Func
Hub5 Func
que permite la expansión
que permite la expansión
del bus, conectándole
del bus, conectándole
Tier 7 diversos dispositivos.
diversos dispositivos.
Hub6 Hub7
USB 2.0
Func
Autor: Alejandro Furfaro 5
6. Arquitectura II
HOST
El Hub root es el elemento del
El Hub root es el elemento del
HOST Tier 1
Hub root
sistema que compone el vértice de la
sistema que compone el vértice de la
Tier 2 pirámide jerárquica. Por lo tanto solo
pirámide jerárquica. Por lo tanto solo
Hub1
hay un Hub Root en el sistema.
Func
hay un Hub Root en el sistema.
Func
Tier 3
También se lo conoce como Host
También se lo conoce como Host
Hub2 Func Controller ,, y se compone de
Controller y se compone de
Tier 4
hardware firmware y software, todo
hardware firmware y software, todo
instalado en la PC.
Func
Hub3 Hub4 Func Tier 5 instalado en la PC.
Func
Hub5 Func Tier 6
Tier 7
Hub6 Hub7
Func
Existen dos standards para implementar Host Controllers: Open Host
Existen dos standards para implementar Host Controllers: Open Host
Controller Interface (OHCI) desarrollado por Compaq, y Universal Host
Controller Interface (OHCI) desarrollado por Compaq, y Universal Host
Controller Interface (UHCI) de Intel.
Controller Interface (UHCI) de Intel.
Autor: Alejandro Furfaro 6
7. Dispositivos USB I
El Hub es un dispositivo USB especial, que
extiende la cantidad de ports para
conectar dispositivos, convirtiendo un
punto de conexión simple, en múltiples
puntos de conexión. Por punto de
conexión entendemos port.
Funciones
Son dispositivos conectados al bus capaces de recibir y transmitir
información desde / hacia el Host Controller. Se denomina función debido a
que no necesariamente la correspondencia función dispositivo es uno a uno.
Ejemplos de funciones en un Bus USB: Teclado, Mouse, lapiz óptico, una
impresora, un modem (analógico, o ISDN) etc.
Autor: Alejandro Furfaro 7
8. Dispositivos USB II
Es posible tener varias
funciones implementadas
dentro de un dispositivo
conectado por un único
cable a un port USB. Estos
son conocidos como
dispositivos compuestos, y
se presentan al Host
Controller como un Hub
con mas de un dispositivo
no removible.
Autor: Alejandro Furfaro 8
9. Consideraciones adicionales
Alimentación:Desde este punto de vista, los
dispositivos USB trabajan en dos modos:
self powered
Bus powered.
Velocidad:La especificación 1.1 soporta dos tipos de
dispositivos:
Dispositivos USB low speed, (1.5 Mbits/seg.)
Dispositivos USB full speed, (12Mbits/seg).
Además, garantiza la coexistencia de ambos tipos de
dispositivo en el bus de manera que no existan
desincronizaciones con los mismos.
Autor: Alejandro Furfaro 9
10. Flujo de datos: Modelo de
Implementación
Function Layer, es
Layer
quien provee la interfaz
entre el usuario y el
dispositivo.
USB Device Layer es la
visión que tiene el
software del sistema para
realizar las operaciones
previstas con el
dispositivo USB.
USB BUS Interface
Layer es la capa del
modelo que resuelve la
comunicación física, a
través de señalización de
hardware y transmisión
de paquetes de
información, entre el Host
Autor: Alejandro Furfaro
y el Dispositivo Físico. 10
12. Modelo del Dispositvo USB
A nivel de la USB Bus Interface,
tenemos fuertes cambios de un
dispositivo al otro ya que se ocupa de
la interacción con el Host Controller
remoto, a nivel de señalización y
transmisión física.
En el USB Logical Device, la interfaz
con el Host es básicamente la misma
independientemente del dispositivo.
Se trabaja a nivel lógico. Se dispone
de un juego de funciones de
interacción básicas, que son comunes
a los diferentes dispositivos USB a
conectar al bus. Analizando el
contenido de dichas funciones se
pueden recién advertir las posibles
diferencias en el tratamiento a los
diferentes dispositivos
La Función es la capa que realiza la
función esperada por el Client SW
Autor: Alejandro Furfaro instalado en el Host. 12
13. Conexiones
Cada conexión es punto a punto y se lleva a cabo mediante
un cable separado. Dicho cable está compuesto de cuatro
hilos.
Se pueden conectar hasta 127 nodos o dispositivos diferentes
al bus.
La señal se aplica en forma diferencial
La señal se aplica en forma diferencial
VBUS ,, por su parte transporta 5Vcc
VBUS por su parte transporta 5Vcc entre D+ y D-, de modo tal que se
entre D+ y D-, de modo tal que se
con respecto de la línea
con respecto de la línea establece una comunicación Half Duplex.
establece una comunicación Half Duplex.
GND que tiene la referencia eléctrica
GND que tiene la referencia eléctrica Es decir, se transmite en un único sentido
Es decir, se transmite en un único sentido
de tierra del sistema.
de tierra del sistema. en cada momento.
en cada momento.
Autor: Alejandro Furfaro 13
14. Características Eléctricas I
Entrada de un port de
Hub, y de un Dispositivo
USB Full-speed
Entrada de un port de
Hub, y de un Dispositivo
USB Low-speed
Significa que un port desconectado “ve” 15 KΩ. En el momento de conectar un
dispositivo uno de los conductores del Bus queda a 1,5 KΩ con respecto a una
fuente de entre 3V y 3,6V. La resistencia de Thevenin (que no incluye los 15 KΩ),
no debe ser menor de 900 Ω.
Estas condiciones eléctricas establecen la forma en que se detectan las conexiones
y desconexiones de dispositivos al bus.
Autor: Alejandro Furfaro 15
15. Características Eléctricas II
Señalización al desconectar
un dispositivo
Señalización al conectar
un dispositivo Full Speed
Autor: Alejandro Furfaro 16
16. Características Eléctricas III
Señalización al conectar un
dispositivo Low Speed
Señalización al resetear un
dispositivo
Autor: Alejandro Furfaro 17
17. Características Eléctricas IV
Niveles de Señalización
Estado del Bus En el conector de En el conector destino
origen
Requerido Aceptable
‘1’ Diferencial D+ > VOH(min) y D- (D+ ) – (D-) > (D+ ) – (D-) >
< VOL (max) 200 mV 200 mV
D+ > VIH (min)
‘0’ Diferencial D- > VOH(min) y D+ (D-) – (D+ ) > (D-) – (D+ ) >
< VOL (max) 200 mV 200 mV
D- > VIH (min)
Single Ended 0 D+ y D- < VOL D+ y D- < VIL D+ y D- < VIH
(SE0) (max) (max) (min)
Estado Dato “J”
Low Speed ‘0’ Diferencial ‘0’ Diferencial
Full Speed ‘1’ Diferencial ‘1’ Diferencial
Estado Dato
“K”
Low Speed ‘1’ Diferencial ‘1’ Diferencial
Full Speed ‘0’ Diferencial ‘0’ Diferencial
Start of Packet Las líneas de datos conmutan del estado Idle al estado
‘K’
Autor: Alejandro Furfaro 18
18. Características Eléctricas V
Niveles de Señalización
Estado del Bus En el conector de En el conector destino
origen
Requerido Aceptable
SE0 por el tiempo SE0 por ≥1 bit SE0 por ≥ 1 bit
End of Packet de dos bits seguido seguido por un seguido por un
(EOP) por un estado Dato estado Dato “J” estado Dato “J”
“J” por el tiempo de de un bit
un bit
Idle N.A. D- > VIHZ (min) y D- > VIHZ (min) y
Low Speed D+ < VIL (max) D+ < VIH (min)
Full Speed D+ > VIHZ (min) D+ > VIHZ (min)
y D- < VIL (max) y D- < VIH (min)
Resume Estado Dato “K” Estado Dato “K”
Desconectado N.A. SE0 por ≥2.5 µseg.
(a un port
upstream)
Conectado (a N.A. I dle ≥2 mseg. I dle ≥ 2.5 µseg.
un port
downstream)
Reset D+ y D- < VOL (max) D+ y D- < VIL D+ y D- < VIL
por ≥ 10 mseg. (max) por ≥ 10 (max) pr ≥ 2.5 µ
Autor: Alejandro Furfaro mseg. seg. 19
20. Características Eléctricas VII
USB emplea
codificación de
datos NRZI.
Consiste en
representar los ‘1’
mediante el no cambio de nivel y los ‘0’ mediante cambios de nivel. Llevado
a términos de estados, en NRZI pasa del estado J al K cada vez que aparece
un ‘0’ en el stream de bits a transmitir.
Problema: Las strings largas de ’1s’ no generan cambios de nivel y pueden
causar la pérdida de sincronismo entre los dos dispositivos.
Para evitarlo se utiliza una
técnica denominada “bit
Stuffing” (Relleno de bits),
que consiste en insertar un
‘0’ cada seis ‘1’ consecutivos.
Autor: Alejandro Furfaro 21
21. Flujo de Información en USB I
Se dispone de un flujo de comunicación dedicado entre cada aplicación y la
correspondiente Función en el dispositivo. Así, una Función de un dispositivo
puede tener diferentes flujos de comunicaciones con diferentes aplicaciones
que la requieran .
En el dispositivo USB, el flujo de
comunicación termina en un
Endpoint .Host Controller Driver:
Interfacea al USB Host Controller con
el USB System Software. Garantiza
que el USB System Software, pueda
interactuar con toda la variedad de
implementaciones de Hardware que
se pueda encontrar.
USB Driver (USBD): Interfacea al USB
System Software con la aplicación
cliente (Client SW) permitiéndoles a
éstas el manejo del dispositivo USB
Autor: Alejandro Furfaro 22
22. Flujo de Información en USB II
Un dispositivo USB se presenta al sistema como una colección
de Endpoints. Estos Endpoints a su vez se agrupan formando
Interfaces. Las Interfaces son “vistas” de las diferentes
Funciones del dispositivo.
La comunicación entre los extremos se realiza entre un buffer
del lado Host y un Endpoint del lado Dispositivo USB. El Canal
es un pipe.
Autor: Alejandro Furfaro 23
23. Endpoints I
Es la porción identificable de un dispositivo USB que
representa el extremo en un flujo de comunicación
entre el Host y dicho dispositivo.
Tiene un Número definido durante el diseño del
dispositivo que lo identifica unívocamente.
Transfiere información en una sola dirección.
Cada dispositivo USB tiene una cantidad de
Endpoints independientes entre sí, y una dirección
unívoca que lo identifica en el sistema, que obtiene
desde el Host en el momento de su conexión al bus.
Así es que, definidos la dirección del dispositivo USB,
el Número de Endpoint, y la Dirección del Flujo de
Datos, se determina el Endpoint del dispositivo con el
que se quiere establecer comunicación.
Autor: Alejandro Furfaro 24
24. Endpoints II
Características de un Endpoint que deben ser
conocidas por el Software Cliente a fin de interactuar
con él de manera correcta:
Número de identificación
Dirección de transferencia de datos
Tipo de transferencia que soporta.
Frecuencia o tiempo de demora en el acceso al bus.
Ancho de Banda requerido.
Comportamiento en el manejo de errores.
Tamaño máximo del paquete de datos que puede
transaccionar.
Autor: Alejandro Furfaro 25
25. El Endpoint 0
Todos los dispositivos USB deben tener implementado
un método de control default que utilice un par de
Endpoints (uno de entrada y otro de salida), para que
en el momento de su conexión al bus los pueda
inicializar el USB System Software en el Host.
Este método se conoce como Default control Pipe,
y el par de Endpoints que lo compone levan el
Número cero.
El Default Control Pipe soporta las transferencias
de Control.
El Endpoint cero está siempre accesible ni bien el
dispositivo se conecta al bus, o se conecta a la fuente
de alimentación, o es reseteado.
Autor: Alejandro Furfaro 26
26. Pipes I
Son entidades abstractas que relacionan un Endpoint del
dispositivo USB con el software del host. Son el canal de
comunicación virtual mediante el cual se pueden
transferir datos entre un buffer de memoria en el host y
el Endpoint del dispositivo USB.
Pueden tener uno de dos modos mutuamente
excluyentes:
Stream: Transmiten datos sin una estructura USB definida y en
modo First-In First-Out. Siempre son unidireccionales.
Message: Transmiten datos con alguna estructura USB definida.
Se envía un requerimiento al dispositivo USB desde el host, el
que es seguido por una transferencia de datos en la dirección
adecuada. Finalmente se pasa a una fase de Estado. Este tipo de
pipes permite comunicaciones bidireccionales.
Autor: Alejandro Furfaro 27
27. Pipes II
Para cursar una transferencia un pipe requiere que se
defina:
Demanda del bus USB y ancho de banda requerido.
Tipo de transferencia
Características del Endpoint asociado en el dispositivo: dirección
de transferencia, tamaño máximo del paquete de datos a
transmitir,etc.
El Cliente de Software que corre en el host envía
requerimientos al pipe a través de I/O Request Paquets
(IRPs). El formato de estos depende del Sistema
Operativo. El Cliente de Software se entera de la
finalización de un IRP, cuando recibe un aviso de
finalización exitosa, o con error.
Si no existen IRPs pendientes el pipe está en estado idle.
Esto significa que su Endpoint asociado en el extremo del
dispositivo USB no ve en el bus transacciones dirigidas a
él. Alejandro Furfaro
Autor: 28
28. Organización de las Transferencias
r azli t u n S
r a ili t u n S
i
i
E MARF F OT R A S
E MARF F OT R A S
T
T
3t n opdnE 1 ovti s opi D
2t n opdnE 6 ovti s opi D
3t n opdnE 1 ovti s opi D
3t n opdnE 1 ovti s opi D
1t n opdnE 2 ovti s opi D
1t n opdnE 4 ovti s opi D
2t n opdnE 3 ovti s opi D
2t n opdnE 2 ovti s opi D
2t n opdnE 2 ovti s opi D
i
z
s
s
s
s
s
s
s
s
s
Frame de 1mseg. Frame de 1mseg.
i
i
i
i
i
i
i
i
i
El Host Controller es el encargado de velar por que todas las transacciones se
lleven a cabo en el menor tiempo posible. Para ello divide el tráfico en frames
i
i
i
i
i
i
i
i
i
de 1 mseg. Luego arma cada frame con las transacciones correspondientes a
las diferentes transferencias que se le solicitan desde las aplicaciones que se
están ejecutando en el Host.
Autor: Alejandro Furfaro 29
29. Transacciones
Transferencia 1 Transferencia 2 Transferencia 3
Cada Transferencia
Transacción 1 Transacción 2 Transacción 3 comprende una o mas
transacciones
Cada Transacción contiene un
paquete Token, y puede contener
Token Datos Handshake
adicionalmente paquetes de
datos y Handshake
Cada paquete contiene un
PID Info. Adicional CRC PID y puede tener además
información adicional y un
CRC
Autor: Alejandro Furfaro 30
30. Paquetes I
Los paquetes se dividen en diversos campos. Algunos
son opcionales y otros obligatorios.
Campo SYNC: Todos los paquetes comienzan con un
campo SYNC. Genera la máxima frecuencia de transición
entre estados de las líneas diferenciales que componen el
Bus. Aparece como un tren de transiciones “JKJKJKJK” en
su codificación NRZI siguiente a un estado “Idle”. Sus
últimos dos bits se toman como el fin del campo SYNC y
por inferencia se asume que a continuación viene el campo
Token.
Los paquetes Token Data y Handshake se representarán en
formato no codificado. Sin embargo, no debe perderse de
vista que se trata de paquetes que se transmiten por el bus
con codificación NRZI, y Bit Stuffing.
Autor: Alejandro Furfaro 31
31. Paquetes II
Campo PID (Packet Identifier):
Se compone de cuatro bits que identifican el tipo de paquete
en cuestión, seguido de cuatro bits de chequeo de errores de
Tx.
PID Info. Adicional CRC
Tiene por función identificar que tipo de paquete se está
cursando por el bus.
En el siguiente cuadro se muestran los diferentes valores que
puede tomar para cada tipo de paquete que viaja por el Bus.
Los valores corresponden a los 4 LSBs.
Autor: Alejandro Furfaro 32
32. Paquetes III
PI D Type PID Name PI D[3: 0] * Descripción
Token OUT 0001B Transacción host-to-function. Lleva dirección +
número de endpoint
IN 1001B Transacción function-to-host. Lleva dirección +
número de endpoint
SOF 0101B Marca de Start-of-Frame y número de frame
SETUP 1101B Transacción host-to-function para SETUP en un
Control Pipe. Lleva Dirección + número de
endpoint
Data DATA0 0011B Paquete de datos para PI D para
DATA1 1011B Paquete de datos para PI D impar
Handshake ACK 0010B El receptor acepta un paquete de datos libre de
error
NAK 1010B El dispositivo Rx no puede aceptar datos o el
dispositivo Tx no puede enviar datos
STALL 1110B El Endpoint se halteó o no está soportado el
requerimiento a un control pipe.
Special PRE 1100B Preámbulo enviado por el Host. Habilita tráfico
downstream en el bus para dispositivos low-
speed.
Autor: Alejandro Furfaro 33
33. Paquetes IV
Formato de los Paquetes TOKEN
IN / OUT / SETUP:
START OF FRAME:
Autor: Alejandro Furfaro 34
34. Paquetes V
Formato de los Paquetes DATA
DATA0 / DATA1:
Formato de los paquetes HANDSHAKE:
ACK: Indica que el paquete STALL: Indica que existe una
fue recibido sin error, y que condición de error en la
puede enviar el siguiente. Función y el Endpoint está en
NACK: Indica que el paquete estado HALT. El Host no debe
fue recibido sin error, pero retransmitir el Paquete.
que por condición del Si el paquete tiene CRC
extremo receptor se debe Incorrecto o error de bit
retransmitir el paquete (Ej: stuffing no se retorna
Buffer Full). respuesta
Autor: Alejandro Furfaro 35
35. Paquetes VI
Campo de Información Adicional:
Cuando las transacciones llevan como PID los códigos IN, OUT, o
SETUP, es necesario especificar la dirección del port seleccionado así
como su número de Endpoint.
Tenemos 128 direcciones de port (Addr 0-6), y 16 Endpoints (Endp 0-
3), para transacciones IN y otros 16 para transacciones OUT.
PID Info. Adicional CRC
Cada frame que se transmite por el bus tiene un paquete SOF
en el que se incluye un número de frame de 11 bits, que se
genera secuencialmente.
En los paquetes cuyo PID es DATA0 y DATA1, se puede tener
hasta 1023 bytes de datos.
Autor: Alejandro Furfaro 36
36. Paquetes VII
PID Info. Adicional CRC
Chequeos de Redundancia Cíclica:
Controlan todos los campos no PID en los paquetes Token y Datos de
modo de asegurar su integridad.
El PID se autochequea al transmitir los bits en formato nativo y en
complemento a 1.
Se utiliza para los campos Token un algoritmo llamado CRC5 (ya que el
campo resultante es de 5 bits), que utiliza el siguiente polinomio:
G (X) = X5 + X2 + 1
Para los campos de datos se utiliza un algoritmo CRC16 (campo resultante
de 16 bits), que utiliza el siguiente polinomio:
G (X) = X16 + X15 + X2 + 1
Autor: Alejandro Furfaro 37
37. Tipos de Transferencias I
Cada tipo de transferencia determina características
importantes del flujo de información involucrado.
Entre otras contamos las siguientes:
Formato de datos impuesto por el USB.
Dirección del flujo de comunicaciones.
Restricciones en el tamaño del paquete de datos a
transmitir.
Restricciones en el acceso al bus.
Restricciones en el tiempo de recuperación de datos.
Secuencias de datos requeridas.
Manejo de errores.
Autor: Alejandro Furfaro 38
38. Tipos de Transferencias II
Transferencias de control:
Son comunicaciones por irrupción, no periódicas, iniciadas
por el host, que se utilizan en operaciones de comando o
status.
Transferencias Isócronas:
Se trata de un tipo de comunicación periódica y continua
entre el host y un dispositivo USB, utilizadas típicamente en
aplicaciones en donde el tiempo de recuperación de datos es
un factor relevante. No quiere decir que sea crítico el tiempo
de respuesta en cuanto a la velocidad de recuperación de los
datos sino más bien, en cuanto a la periodicidad de acceso a
éstos.
Autor: Alejandro Furfaro 39
39. Tipos de Transferencias III
Transferencias de Interrupción:
Son comunicaciones de baja frecuencia, para tamaños de
paquete de datos muy pequeños, y tiempo de recuperación
de datos limitado.
Transferencias de volumen (bulk):
Son comunicaciones de grandes paquetes de datos por
irrupción, no periódicas, utilizadas para transmitir datos que
pueden utilizar cualquier ancho de banda disponible y que
también pueden ser demorados hasta que el ancho de
banda requerido se encuentre disponible.
Autor: Alejandro Furfaro 40
40. Tipos de Transferencias IV
Tipo de Transferencia Control Bulk Interrupción Isócrona
Impresora,
Uso típico Configuración
scanner
Mouse, Teclado Audio
Obligatoria Si No No No
Soportada por dispositivos Low
Si No Si No
Speed
Corrección de errores Si Si Si No
Tipo de pipe Message Stream Stream Stream
Garantiza Velocidad de envío No No Si Si
Garantiza mínimo tiempo de
No No Si Si
acceso a la información
Tamaño de datos por Endpoint 8, 16, 32, ó 64 8, 16, 32, ó 64
1 a 64 bytes hasta 1023 bytes
(Full Speed) bytes bytes
Tamaño de datos por Endpoint
8 bytes No aplica 8 bytes No aplica
(Low Speed)
Ancho de banda reservado por
10% Ninguno 90 % (ambas combinadas)
frame
Autor: Alejandro Furfaro 41
48. Uso del Ancho de Banda I
Limites en las Transferencias de Control Full-speed
(9 SYNC bytes, 9 PID bytes, 6 Endpoint + CRC bytes,
Protocol Overhead
6CRC bytes, 8 Setup data bytes, and a 7-byte
(45 bytes)
interpacketdelay (EOP, etc.))
Frame
Max Bandwidth Max Bytes Bytes/Frame
DataPayload Bandwidth
(bytes/second) Transfers Remaining Useful Data
per Transfer
1 32000 3% 32 23 32
2 62000 3% 31 43 62
4 120000 3% 30 30 120
8 224000 4% 28 16 224
16 384000 4% 24 36 384
32 608000 5% 19 37 608
64 832000 7% 13 83 832
Max. 1500000 1500
Limites en las Transferencias de Control Low-speed
(PRE+ 9 SYNC bytes, 9 PID bytes, 6 Endpoint + CRC
Protocol Overhead
bytes, 6CRC bytes, 8 Setup data bytes, and a 7-byte
(46 bytes)
interpacketdelay (EOP, etc.))
Frame
Max Bandwidth Max Bytes Bytes/Frame
DataPayload Bandwidth
(bytes/second) Transfers Remaining Useful Data
per Transfer
1 3000 25% 3 46 3
2 6000 25% 3 43 6
4 12000 26% 3 37 12
8 24000 28% 3 25 24
Max. 187500 187
Autor: Alejandro Furfaro 49
49. Uso del Ancho de Banda II
Limites en las Transferencias Isócronas
Protocol Overhead (2 SYNC bytes, 2 PID bytes, 2 Endpoint + CRC bytes, 2
(9 bytes) CRC bytes, and a 1-byte interpacketdelay
Max Frame
Max Bytes Bytes/Frame
DataPayload Bandwidth Bandwidth
Transfers Remaining Useful Data
(bytes/second) per Transfer
1 150000 1% 150 0 150
2 272000 1% 136 4 272
4 460000 1% 115 30 460
8 704000 1% 88 5 704
16 960000 2% 60 40 960
32 1152000 3% 36 24 1152
64 1280000 5% 20 40 1280
128 1280000 9% 10 130 1280
256 1280000 18% 5 175 1280
512 1024000 35% 2 458 1024
1023 1023000 69% 1 468 1023
Max. 1500000 1500
Autor: Alejandro Furfaro 50
50. Uso del Ancho de Banda III
Limites en las Transferencias de Interrupción Full-speed
Protocol Overhead (3 SYNC bytes, 3 PID bytes, 2 Endpoint + CRC bytes, 2
(13 bytes) CRC bytes, and a 3-byte interpacket delay)
Max Frame
Max Bytes Bytes/Frame
DataPayload Bandwidth Bandwidth
Transfers Remaining Useful Data
(bytes/second) per Transfer
1 107000 1% 107 2 107
2 200000 1% 100 0 200
4 352000 1% 88 4 352
8 568000 1% 71 9 568
16 816000 2% 51 21 816
32 1056000 3% 33 15 1056
64 1216000 5% 19 37 1216
Max. 1500000 1500
Limites en las Transferencias de Interrupción Low-speed
Protocol Overhead (3 SYNC bytes, 3 PID bytes, 2 Endpoint + CRC bytes, 2
(13 bytes) CRC bytes, and a 3-byte interpacket delay)
Max Frame
Max Bytes Bytes/Frame
DataPayload Bandwidth Bandwidth
Transfers Remaining Useful Data
(bytes/second) per Transfer
1 13000 7% 13 5 13
2 24000 8% 12 7 24
4 44000 9% 11 0 44
8 64000 11% 8 19 64
Max. 187500 187
Autor: Alejandro Furfaro 51
51. Uso del Ancho de Banda IV
Limites en las Transferencias Bulk
Protocol Overhead (3 SYNC bytes, 3 PID bytes, 2 Endpoint + CRC bytes, 2
(13 bytes) CRC bytes, and a 3-byte interpacket delay)
Max Frame
Max Bytes Bytes/Frame
DataPayload Bandwidth Bandwidth
Transfers Remaining Useful Data
(bytes/second) per Transfer
1 107000 1% 107 2 107
2 200000 1% 100 0 200
4 352000 1% 88 4 352
8 568000 1% 71 9 568
16 816000 2% 51 21 816
32 1056000 3% 33 15 1056
64 1216000 5% 19 37 1216
Max. 1500000 1500
Autor: Alejandro Furfaro 52
52. Enumeración
Antesde comenzar a trabajar con un
dispositivo el Host debe averiguar sus
características (Tipos de transferencias,
cantidad de endpoints, etc.).
Una vez obtenida esta información le asigna al
dispositivo un número de port lógico en el
Bus.
Este proceso se denomina Enumeración.
Autor: Alejandro Furfaro 53
53. Estados durante la Enumeración Attached
Hub Reseteado
Hub O Desconfigurado
En la secuencia de Configurado
Actividad
Enumeración, el en el Bus
Powered Suspended
dispositivo puede Bus
Inactivo
tomar seis estados Corte de
Alimentación Reset
posibles: Actividad
en el Bus
Attached Default
Bus
Suspended
Suspended Dirección
Inactivo
Powered Reset
Asignada
Actividad
Default Addressed
en el Bus
Suspended
Addressed Bus
Inactivo
Dispositivo Dispositivo
Configured Des Configuraado
Configuraado Actividad
en el Bus
Configured
Suspended
Bus
Inactivo
Autor: Alejandro Furfaro 54
54. Pasos en la Enumeración I
El usuario conecta el dispositivo a un port de un Hub
(Hub root o cualquier hub externo).
El dispositivo toma su estado inicial:Attached.
Attached
Si el Hub está operativo y no está siendo reseteado,
alimenta al dispositivo automáticamente, si éste es Bus
Powered.
El dispositivo pasa al estado Powered.
Powered
Si el dispositivo es Self Powered al attacharse directamente
entra al estado Powered.
Powered
El Hub detecta al dispositivo.
Monitorea el estado eléctrico del port, y si detecta que la
impedancia de entrada cae de 15 KΩ a 1,5 KΩ, registra el
evento para informar al host.
El dispositivo sigue en estado Powered
El hub no transmite nada al bus.
Autor: Alejandro Furfaro 55
55. Pasos en la Enumeración II
El Host controller encuesta a los hubs para saber si
tienen eventos que reportar.
Cada Hub utiliza un pipe configurado para transferencias de
interrupción para reportar eventos al Host controller.
Por medio de este pipe el host controller encuesta a los
Hubs (uno a la vez) para saber si alguno tuvo un evento
desde la última consulta, y en tal caso en cual de sus ports
se produjo el evento.
El Host envía al Hub por el pipe de interrupción una
transferencia de Control que todos los hubs deben
entender: Get_Port_Status.
El Hub reponde este comando de acuerdo a lo establecido
en la especificación.
El Host Controller accede a la información completa acera
del evento.
Autor: Alejandro Furfaro 56
56. Pasos en la Enumeración III
El Hub resetea al dispositivo.
Leída la información del port attachado, el Host envía al
Hub el comando Set_Port_Feature.
En dicho comando utiliza la opción que le permite solicitar
al hub el reset del port.
El Hub envía las líneas D+ y D- del port a la condición de
Reset durante 10 mseg (atención: el reset durará los
próximos 10 frames).
El Hub detecta la velocidad del dispositvo.
Examina las tensiones en ambos terminales D+ y D- en el
estado Idle. Según cual tiene mayor tensión, el dispositivo
es High Speed o Low Speed.
Según su diseño el Hub puede efectuar esta comprobación
antes del Reset o inmediatamente después del mismo.
Autor: Alejandro Furfaro 57
57. Pasos en la Enumeración IV
El Host establece un path de señal entre el
dispositivo y el bus.
Envía al Hub el comando Get_Port_Status para verificar
que el dispositivo finalizó el reset.
Esta operación se repite frame tras frame hasta que el Hub
conteste que el dispositivo ha sido reseteado. (Recordar
que el reset dura 10 frames)
Cuando esto ocurre, el dispositivo está en estado Default:
Default
Los registros del controlador están en su estado default,
El controlador está listo para trabajar por el Endpoint 0,
Puede tomar no mas de 100 ma. del bus,
Contestará transacciones dirigidas a la dirección de port 0.
Autor: Alejandro Furfaro 58
58. Pasos en la Enumeración V
El Host averigua el tamaño máximo de paquete
soportado por el default control pipe.
Envía el requerimiento Get_Descriptor al Endpoint 0 de la
Dirección 0. Especificando en este comando que se refiere
al descriptor de dispositivo y que se requieren 8 bytes de
respuesta por parte del dispositivo.
El Host enumera solo un dispositivo a la vez, así que no hay
forma que otro dispositivo responda.
El tamaño máximo del paquete está en el byte 8 del
Descriptor de Dispositivo. Por eso el Host solo lee sus ocho
primeros bytes.
Autor: Alejandro Furfaro 59
59. Pasos en la Enumeración VI
El Host asigna una dirección.
Envía el requerimiento Set_Address, con la dirección que
le asigna al dispositivo.
El dispositivo lo lee, devuelve ACK, y almacena su
dirección.
Ahora está en el estado Addressed.
Addressed
La dirección asignada es válida hasta que el dispositivo se
desconecte, apague, o resetee.
Autor: Alejandro Furfaro 60
60. Pasos en la Enumeración VII
El Host lee las características del dispositivo.
Envía el requerimiento Get_Descriptor
Endpoint 0 del dispositivo.
Dirección de port: la que termina de asignar
Descriptor de dispositivo.
El dispositivo devuelve su Device Descriptor.
Contiene la cantidad de configuraciones, interfaces, y endpoints que el
dispositivo tiene definidos.
Los detalles de estos elementos se encuentran en los respectivos
descriptores almacenados en el dispositivo.
Por
cada configuración informada, el host controller envía un
Get_Descriptor al dispositivo
Port y Endpoint, ídem anterior
Descriptor de Configuración.
El dispositivo responde el requerimiento.
Descriptor de la configuración requerida
Descriptores de interfaz que dependen de esta configuración
Descriptores de endpoint que dependen de cada interfaz
Descriptores de string si los hubiera
Autor: Alejandro Furfaro 61
61. Pasos en la Enumeración VIII
El Host carga un Device Driver.
En base a la información de Vendor ID, Product ID, Release
number, e información de clase leídos del Device Descriptor
por el driver de Bus USB, el Sistema Operativo carga el
Device Driver mas apropiado para el dispositivo.
En el caso de entornos Windows, se usa además la
información de los archivos de Sistema .INF.
El Device Driver del dispositivo selecciona una
configuración.
Comando Set_Configuration.
El dispositivo está ahora en el estado Configured.
Configured
El dispositivo está listo para ser utilizado.
Autor: Alejandro Furfaro 62
62. Descriptor de Dispositivo
Offset Campo Tamaño Valor Descripción
0 bLength 1 Number Tamaño del Descriptor en Bytes
1 bDescriptorType 1 Constant Tipo de Descriptor DEVICE
2 bcdUSB 2 BCD Número de versión de la Especificación USB en Binario Codificado Decimal (ej., 1.10 es 110H).
Este campo identifica el release de la Especificación USB con la cual son compatibles el
dispositivo y sus descriptores.
4 bDeviceClass 1 Class Class c ode (asignado por el USB). Si este campo vale 00H, c ada interfaz dentro de
una c onfigurac ión espec ificará su propia informac ión de c lase y todas trabajarán
independientemente Si este campo tiene un valor entre 1 y FEH, significa que el
dispositivo soporta diferentes espec ific ac iones de c lase sobre diferentes interfac es
y éstas pueden no operar independientemente. Este valor identifica la definición de
clase usada por las interfac es
agregadas. (Por ejemplo, un CD-ROM c on interfac es de audio y datos digitales
que requieren c ontrol de transporte para ejectar el CD o c omenzar a hac erlos
girar).
Si este c ampo vale FFH, la c lase del dispositivo es vendor-specific
5 bDeviceSubClass 1 Subclass Subc lass c ode (asignado por el USB). Este c ódigo se evalúa de ac uerdo al valor
del c ampo bDeviceClass. Si el c ampo bDevic eClass es cero, este c ampo también
debe ser c ero. Si el c ampo bDevic eClass no vale FFH, todos los valores se
reservan para ser asignados por el USB.
6 bDeviceProtocol 1 Protocol Protocol code (asignado por el USB). Estos códigos se evalúan de acuerdo con el valor de los
campos bDeviceClass ybDeviceSubClass. Si un dispositivo soporta protocolos de clase
específicos sobre la base de dispositivo y no de interfaz, este código identifica el protocolo que
utiliza el dispositivo tal como se lo define en la especificación de clase de ese dispositivo. Si
este campo vale cero, el dispositivo no utiliza protocolos específicos de clase. Sin embargo
puede utilizar protocolos específicos de clase sobre la base de interfaces. Si este campo vale
FFH, el dispositivo usa un protocolo vendor-specific basado en el dispositivo.
7 bMaxPacketSize0 1 Number Tamaño máximo de paquete para endpoint 0 (valores válidos solo 8, 16, 32, o 64)
8 idVendor 2 ID Vendor ID (asignados por el USB)
10 idProduct 2 ID Product ID (asignados por el fabricante)
12 bcdDevice 2 BCD Número de versión del Dispositivo en Binario Codificado Decimal
14 iManufacturer 1 Index Indice de descriptor de string que describe al fabricante
15 iProduct 1 Index Indice de descriptor de string que describe al producto
16 iSerialNumber 1 Index Indice al descriptor de string que describe el número de serie del dispositivo
Autor: Alejandro Furfaro
17 bNumConfigurations 1 Number Número de configurationes posibles 63
63. Descriptor de Dispositivo
/*SINGLE HID INTERFACE*/
const byte DEV_DESC[]={DEV_LENGTH,/*length of this desc. */
DEVICE, /*DEVICE descriptor */
0x00,0x01, /*spec rev level (BCD) */
0x00, /*device class */
0x00, /*device subclass */
0x00, /*device protocol */
0x08, /*max packet size */
0x00,0x04, /*National's vendor ID */
0x5B,0xC3, /*National's product ID */
0x41,0x01, /*National's revision ID */
MFG_STR_OFS,/*index of manuf. string */
PID_STR_OFS,/*index of prod. string */
0, /*index of ser. # string */
0x01 /*number of configs. */
};
Autor: Alejandro Furfaro 64
64. Descriptor de Configuración
Offset Campo Tamaño Valor Descripción
0 bLength 1 Number Tamaño del Descriptor en Bytes
1 bDescriptorType 1 Constant Tipo de Descriptor CONFIGURATION
2 wTotalLength 2 Number Longitud total de los datos retornados para esta configuración. Incluye la longitud combinada de
todos los descriptores de configuración, interfaz, endpoint, y específicos de clase o fabricante
retornados para esta configuración.
4 bNumInterfaces 1 Number Númeo de interfac es soportadas por esta c onfigurac ión
5 bConfigurationValue 1 Number Valor a utilizar c omo argumento en el requerimiento SetConfiguration() para
selecc ionar esta c onfigurac ión
6 iConfiguration 1 Index Indice al descriptor de string que describe esta configuración
7 bmAttributes 1 Bitmap Características de la configuración :
D7: Reservado (debe estar en 1)
D6: Self-powered
D5: Remote Wakeup
D4...0: Reservados (deben estar en 0)
D7 está reservado y debe estar en 1 por razones históricas. Para indicar la cantidad de mA
requeridos, una configuración de dispositivo que utiliza alimentación del Bus y una fuente local,
reporta un valor distinto de cero en MaxPower y setea D6. La fuente de alimentación actual en
tiempo de ejecución se determina mediante el requerimiento GetStatus (DEVICE). Si una
configuración de dispositivo soporta remote wakeup, D5 se pone en 1.
8 MaxPower 1 mA Máximo consumo de alimentación desde el Bus para esta configuración específica, del dispositivo
USB cuando se encuentra completamente operacional. Se expresa en unidades de 2mA (p.ej., 50
= 100mA).
Nota: La configuración de un dispositivo indica si esa configuración es bus- powered o
selfpowered. El estado del dispositivo reporta si éste está actualmente self-powered. Si un
dispositivo se desconecta de su fuente de alimentación externa, actualiza su estado de dispositivo
para indicar que ya no está self-powered. Un dispositivo no puede incrementar su toma de
alimentación del bus, cuando pierde su alimentación externa, mas allá de la cantidad reportada
por esta configuración.
Si un dispositivo puede continuar operando cuando se desconecta de su fuente de alimentación
externa, continuará haciéndolo, caso contrario cesa su operación. El USB System Software puede
determinar la causa de la falla chequeando el estado y detectando la pérdida de alimentación del
dispositivo.
Autor: Alejandro Furfaro 65
65. Interface Descriptor
Offset Campo Tamaño Valor Descripción
0 bLength 1 Number Tamaño del Descriptor en Bytes
1 bDescriptorType 1 Constant Tipo de Descriptor INTERFACE
2 bInterfaceNumber 1 Number Número de interfaz. Valor base cero que identifica el ídice en un array de interfaces
concurrentes soportadas por esta configuración
3 bAlternateSetting 1 Number Valor utilizado para selec cionar ajustes alternativos para la interfaz
identificadas en el campo previo.
4 bNumEndpoints 1 Number Número de endpoints utilizado por esta interfaz (excluyendo el endpoint
c ero). Si este valor es c ero, esta interfaz solo utiliza el Default Control
Pipe.
5 bInterfaceClass 1 Class Código de clase (asignado por el USB).
El valor cero se reserva para futura estandarización.
Si este campo se pone en FFh, la clase de esta interfaz es "vendor-specific".
El resto de los valores está reservado para su asignación por el USB.
6 bInterfaceSubClass 1 SubClass El Código de Subclase (asignado por el USB). Estos códigos son clasificados por el
valor de campo bInterfaceClass.
Si el campo bInterfaceClass es 0, este campo también debe estar en 0.
Si el campo bInterfaceClassno es FFh, todos los valores se reservan para su
asignación por el USB.
7 bInterfaceProtocol 1 Protocol Código de Protocolo (asignado por el USB). Estos códigos se clasifican de acuerdo
con el valore de los campos bInterfaceClass y bInterfaceSubClass. Si una interfaz
soporta requerimientos "class-specific", este código identifica los protocolos que
usa el dispositivo de acuerdo con lo definido en la especificación de clase a la que
pertenece el dispositivo.
Si este campo se pone en 0, el dispositivo no utiliza un protocolo "class-specific" en
esta interfaz.
Si este campo se pone en FFh, el dispositivo utiliza un protocolo "vendor-specific"
para esta interfaz.
8 iInterface 1 Index Indice al descriptor de string que describe esta interfaz.
Autor: Alejandro Furfaro 66
66. Descriptor de Endpoint
Offset Campo Tamaño Valor Descripción
0 bLength 1 Number Tamaño del Descriptor en Bytes
1 bDescriptorType 1 Constant Tipo de Descriptor ENDPOINT
2 bEndpointAddress 1 Endpoint Dirección del endpoint en el dispositivo USB. Se codifica como sigue:
Bit 3...0: Número de endpoint
Bit 6...4: Reservados, se ponen en 0
Bit 7: Dirección de las transferencias( se ignora para endpoints de control )
0 = OUT endpoint
1 = IN endpoint
3 bmAttributes 1 Bitmap Este c ampo desc ribe los atributos del endpoint c uando lo configuró utilizando el valor
bConfigurationValue.
Bit 10: Tipo de transferenc ia:
00 = Control
01 = Isoc hronous
10 = Bulk
11 = Interrupt
El resto de los bits están reservados.
4 wMaxPacketSize 2 Number Es el máximo tamaño de paquete que este endpoint es c apaz de enviar o recibir
c uando se selec c iona esta c onfigurac ión.
Para endpoints isóc ronos, este valor se utiliza para reservar tiempo de bus en el
schedule, requerido para los payloads de datos de c ada frame. El pipe puede sobre
la marc ha, utilizar menos anc ho de banda que el reservado. Si es nec esario, el
dispositivo reporta el anc ho de banda ac tual en uso por medio de sus propios
mec anismos normales no definidos por USB.
Para endpoints de interrupc ión, bulk, y c ontrol, se pueden enviar payloads de datos
mas pequeños, pero esto terminará la transferenc ia y podrá o no requirirse
intervenc ión para rec omenzarla.
6 bInterval 1 Number Intervalo para polling al endpoint en espera de transferencias de datos. Expresado en
milisegundos. Este campo se ignora para endpoints bulk y control. Para endpoints isócronos este
campo debe estar en 1. Para endpoints de interrupción, este campo puede valer desde 1 a 255.
Autor: Alejandro Furfaro 67
67. Descriptores de Configuración,
Interfaz y Endpoint. Ejemplos
const byte CFG_DESC[] = {CFG_LENGTH, /*length of this desc. */
CONFIGURATION, /*CONFIGURATION descriptor*/
0x22,0x00, /*total length returned */
0x01, /*number of interfaces */
0x01, /*number of this config */
CFG_STR_OFS, /*index of config. string */
ATTRIBUTES, /*attr.: bus powered */
50, /*max power (100 mA) */
INT_LENGTH, /*length of this desc. */
INTERFACE, /*INTERFACE descriptor */
0x00, /*interface number */
0x00, /*alternate setting */
0x01, /*# of (non 0) endpoints */
HIDCLASS, /*interface class */
NOSUBCLASS, /*interface subclass */
0x00, /*interface protocol */
INT_STR_OFS, /*index of intf. string */
HID_LENGTH, /*length of this desc. */
HID, /*HID descriptor */
0x00,0x01, /*HID spec rev level (BCD)*/
0x00, /*target country */
1, /*# HID class desc follow.*/
HIDREPORT, /*report descr. type */
RPT_DESC_SIZE,0x00, /*report descr. length */
END_LENGTH, /*length of this desc. */
ENDPOINT, /*ENDPOINT descriptor */
0x85, /*address (IN) */
0x03, /*attributes (INTERRUPT) */
0x40,0x00, /*max packet size (64) */
0xFF}; /*interval (ms) */
Autor: Alejandro Furfaro 68
68. Descriptor de String
Offset Campo Tamaño Valor Descripción
0 bLength 1 N+2 Tamaño del Descriptor en Bytes
1 bDescriptorType 1 Constant Tipo de Descriptor STRING
2 wLANGID[0] 2 Constant Código de LANGID Cero
….. …… …… ……. ……….
N wLANGID[x] 2 Código de LANGID x
Autor: Alejandro Furfaro 69
70. Datos para un requerimiento SETUP
Offset Campo Tamaño Valor Descripción
0 bmRequestType 1 Bitmap Characteristics of request:
D7: Data transfer direction
Formato de wIndex cuando se especifica un Endpoint 0 = Host-to-device
D7 D6 D5 D4 D3 D2 D1 D0
1 = Device-to-host
Dirección Reservada (Reset a cero) Número de Endpoint Especifica las características del
D6...5: Type
D15 D14 D13 D12 D11 D10 D9 D8 requerimiento específico que se va
Reservada (Reset a cero) 0 = Standard
a enviar
1 = Class
Formato de wIndex cuando se especifica una Interfaz
2 = Vendor
D7 D6 D5 D4 D3 D2 D1 D0 Especifica al requerimiento específico
3 = Reserved
Nº de Interfaz que se va a enviar
D15 D14 D13 D12 D11 D10 D9 D8 D4...0: Recipient
(ver siguiente slide)
Reservada (Reset a cero) 0 = Device
1 = Interface
2 = Endpoint
3 = Other
4...31 = Reserved
1 bRequest 1 Value Specific request (Ver hoja "Standard Device Requests")
2 wValue 2 Value Word-sized field that varies according to request
4 wIndex 2 Index or Offset Word-sized field that varies according to request;
typically used to pass an index or offset
6 wLength 2 Count Number of bytes to transfer if there is a Data stage
Especifica la cantidad de bytes qué se
transmitirán en en la segunda fase de datos. La
dirección de la transacción la especifica el bit D7
Autor: Alejandro Furfaro de bmRequest 71
71. Requerimientos Standard
bmRequestType bRequest wValue wIndex wLength Data
00000000B CLEAR_FEATURE Feature Zero Zero None
00000001B Selector Interface
00000010B Endpoint
10000000B GET_CONFIGURATION Zero Zero One Configuration
Value
10000000B GET_DESCRIPTOR Descriptor Type Zero or Descript Descriptor
and Descriptor Language or
Index ID Length
10000001B GET_INTERFACE Zero Interface One Alternate Interface
10000000B GET_STATUS Zero Zero Two Device, Interface,
10000001B Interface or Endpoint Status
10000010B Endpoint
00000000B SET_ADDRESS Device Address Zero Zero None
00000000B SET_CONFIGURATION Configuration Zero Zero None
Value
00000000B SET_DESCRIPTOR Descriptor Type Zero or Descript Descriptor
and Descriptor Language or
Index ID Length
00000000B SET_FEATURE Feature Zero Zero None
00000001B Selector Interface
00000010B Endpoint
00000001B SET_INTERFACE Alternate Interface Zero None
Setting
10000010B SYNCH_FRAME Zero Endpoint Two Frame Number
Autor: Alejandro Furfaro 72
72. Códigos para Requerimientos y
Tipos Standard
bRequest Valor
GET_STATUS 0
CLEAR_FEATURE 1
Reservado para uso Futuro 2
SET_FEATURE 3
Reservado para uso Futuro 4
SET_ADDRESS 5
GET_DESCRIPTOR 6
SET_DESCRIPTOR 7 Tipo de Descriptor Valor
GET_CONFIGURATION 8 DEVICE 1
SET_CONFIGURATION 9 CONFIGURATION 2
GET_INTERFACE 10 STRING 3
SET_INTERFACE 11 INTERFACE 4
SYNCH_FRAME 12 ENDPOINT 5
Tipo de Descriptor Receptor Valor
DEVICE_REMOTE_WAKEUP Device 1
ENDPOINT_HALT Endpoint 0
Autor: Alejandro Furfaro 73
74. Start Of Frame
...se genera cada 1 mseg.
Setup stage
USB
Sync
Sync SOF
SOF Frame#
Frame# CRC5
CRC5 EOP
EOP
00000001
00000001 0xA5
0xA5
0xA5 0x0DD
0x0DD 0x15
0x15 001
001
Sync SETUP ADDR ENDP CRC5 EOP Device
00000001 0xB4 0x00 0x0 0x08 001
End of Packet (D+ and D- bajas)
End of Packet (D+ and D- bajas)
Sync DATA0 DATA CRC16 EOP
00000001 0xC3 80 06 00 01 00 00 40 00 5 bit Checksum sobre Frame#
0xBB29 001
5 bit Checksum sobre Frame#
Sync ACK EOP
Número de Frame (0 - 2047) cíclico
Número de Frame (0 - 2047) cíclico
00000001 0x4B 001
Start of Frame (uno por milisegundo)
Start of Frame (uno por milisegundo)
Packet start indica “llegando paquete” al transceiver
Packet start indica “llegando paquete” al transceiver
Autor: Alejandro Furfaro 75
75. Paquetes Setup
Se decodifican los Paquetes Setup completos y se
generan las interrupciones Setup stage
USB
Sync SOF Frame# CRC5 EOP
00000001 0xA5 0x0DD 0x15 001
Sync
Sync SETUP
SETUP ADDR
ADDR ENDP
ENDP CRC5
CRC5 EOP
EOP
00000001 0xB4
0xB4 0x00 0x0 0x08 001 Device
00000001 0xB4 0x00 0x0 0x08 001
Sync DATA0 DATA CRC16 EOP
00000001 0xC3 80 06 00 01 00 00 40 00 0xBB29 001
Endpoint 0 (usado para configuración)
Endpoint 0 (usado para configuración)
Sync ACK EOP
00000001 0x4B 001
Addr 0 (define direc.. para cada nuevo disp. attachado)
Addr 0 (define direc para cada nuevo disp. attachado)
Setup Packet (comienza transf. de control)
Setup Packet (comienza transf. de control)
Autor: Alejandro Furfaro 76
76. Paquete Data
El Paquete Data define que clase de transferencia
setup se inicia
Setup stage
Sync SETUP ADDR ENDP CRC5 EOP USB
00000001 0xB4 0x00 0x0 0x08 001
Sync
Sync DATA0
DATA0 DATA
DATA CRC16
CRC16 EOP
EOP
00000001
00000001 0xC3
0xC3
0xC3 80 06 00 01 00 00 40 00
80 06 00 01 00 00 40 00 0xBB29
0xBB29 001
001
Sync ACK EOP Device
00000001 0x4B 001 DATA
DATA
Get device descriptor
80 = dirección de transferencia, comando std. genera una interrupción
06 = get descriptor
00 = índice del descriptor
01 = device descriptor
Get device descriptor
00 00 = language ID
genera una interrupción
40 00 = cantidad de bytes requeridos
por el host (formato little endian;
Lowbyte, Highbyte)
Autor: Alejandro Furfaro 77
Notas del editor
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.
Inmediatamente con el hardware se encuentra una capa controladora de bajo nivel que actúa como Host Controller. Esta capa es parte del Sistema Operativo que soporta USB y se conoce como Host Controller Driver (HCD). Es el driver del controlador USB, que trabaja a bajo nivel controlando las transacciones que tienen lugar en el bus, de manera íntimamente relacionada al Hardware. Normalmente se diseñan de modo de soportar ambos standars de hardware (OHDI y UHDI). Encima de este driver, se encuentra un segundo Driver llamado USB Driver (USBD), cuya función es la de garantizar la interacción entre el HCD y los drivers lógicos. Esta Interacción está definida a través de estructuras de datos y funciones definidas en la Especificación Open USB Driver Interface. La tercer capa de Sistema es conocida como LDD (Logic Device Drivers), y consiste de una colección de drivers específicos para un determinado dispositivo, o bien para una clase de dispositivitos USB determinada. El Client Sw no es mas que el software que se ejecuta para acceder desde una aplicación de usuario final , al dispositivo USB en cuestión.