PUERTO USB (Universal Serial Bus) Generalidades El objetivo del desarrollo del puerto USB es reemplazar la tecnologa antigua,

como el puerto serie RS232 e IEEE 1284 (tambin denominados tipo Centronics) por una opcin con mayor compatibilidad con tecnologas y equipamientos actuales. Como premisas esenciales se considera la seguridad en la transferencia de la informacin y la velocidad de la misma. La comunicacin deber ser bidireccional para asegurar la transferencia tanto desde el host al perifrico y viceversa. Es importante que el perifrico pueda ser conectado y desconectado con la PC funcionando, que no necesite reiniciar el equipo para poder establecer la comunicacin. Otra premisa del diseo es que cada nueva versin del puerto USB deber ser compatible con todas las versiones anteriores. Con estos aspectos podemos tener la generalizacin de conexin a cualquier computadora. La norma asegura que el proceso de registracin puede llevarse a cabo sin necesidad de reiniciar el ordenador o exigir accin alguna por parte del usuario q no sea la sola instalacin del driver apropiado. El mecanismo de identificacin q usa el perifrico asegura q la aplicacin encuentre el perifrico q requiere sin la necesidad de configuracin alguna de parte del usuario final del programa. La velocidad del puerto USB supera la velocidad de transferencia del puerto paralelo y sobrepasa ampliamente la velocidad del puerto serie. Todo esto con el extra de q los cables usados para el USB son extremadamente ms simple de obtener y generalizados en el mercado que los de los puertos paralelos o serie. Es de especial importancia que en el protocolo USB permita la opcin de contemplar el chequeo de la informacin transferida para asegurar el envo, dependiendo del modo de trabajo. Esto garantiza la correcta transmisin de informacin en cada caso. Es adems un importante avance en comparacin con los puertos a reemplazar, que la norma contempla la posibilidad de alimentar con tensin continua a travs del mismo cable. En el caso del puerto serie esto poda ser logrado pero mediante el uso de pines de control. La mxima corriente que el puerto USB es capaz de proveer se limita a 500 miliamperios con una tensin de 5 voltios.

El logo USB compatible con la norma es el siguiente. Se refiere a mdulos bsicos con velocidades bajas:

Este logo se aplica a dispositivos que soportan altas velocidades:

Este logo representa a dispositivos que son compatibles con la caracterstica On The Go. En velocidad bsica o high speed. On The Go se refiere a dispositivos que pueden asumir el rol de perifrico o host, no se refiere a un hub USB sino a dispositivos especficos:

Logo identificador para equipos USB 3.0:

Logo identificador para equipos compatibles con USB wireless:

Este es el logo en dispositivos para identificar que el conector sealado es USB:

Podemos ver el siguiente cuadro comparativo para tener una referencia ms clara Bus Serie Bus Paralelo USB Modo de trabajo Serie Paralelo Serie Velocidad Baja Media Alta Complejidad del soft Baja Baja Alta Complejidad del hard Baja Alta Baja Largo del cable 15 metros 3 metros 5 metros Modos de trabajo 1 2 4 Futura compatibilidad NO NO SI Cant. de conexiones 2 28 127 Disponibilidad Abandonndose Abandonada Universal El modo de trabajo se refiere simplemente al modo de transmisin de cada bit de las palabras a transmitir. Tanto el Serie como el USB envan un bit a la vez mientras q el paralelo enva los 8 bits en un solo momento. La velocidad hace referencia al volumen de informacin que es capaz de transmitir el bus por unidad de tiempo. El caso del puerto serie est diseado para una velocidad de 20 kilobits/seg aunque, con ciertas consideraciones, esta ha sido superada. El paralelo ya tiene un diseo q considera lmites de velocidad que superan el megabyte por segundo. Pero ninguno se aproxima a la capacidad de transferencia que tiene el SUB que puede llegar a superar los 50 megabytes/seg.

La complejidad del soft representa la nica desventaja del USB respecto de los dems. Se refiere al soft extra, necesario para lograr que el puerto funcione de alguna forma en particular, por ejemplo, todo el intercambio de informacin al momento de la registracin. El desarrollador siempre va a utilizar libreras ya generadas. La complejidad del hard se refiere a las necesidades de circuitos integrados en la parte del equipo que necesita comunicarse con la PC. En este punto debemos sealar una gran variedad de opciones de circuitos integrados q sirven de interface USB con la inteligencia como para establecer la registracin y el intercambio de informacin con el Host, adems de simplificar toda la sealizacin elctrica del bus. En este punto es similar al puerto serie porque necesita de una interface entre el perifrico y el host. El caso del puerto paralelo tiene una complejidad extra, es el problema q representa la longitud del cable y lo complejo de su ensamblaje. La longitud del cable se refiere al largo mximo contemplado por la norma para una transmisin eficiente. El puerto paralelo est en especial desventaja por la ya mencionada complejidad y rigidez del cable de comunicaciones. El puerto serie tiene una ventaja aparente sobre los otros pero se trata de un cable no muy generalizado en el mercado. El USB puede extender su longitud aproximadamente a 30m usando hubs retransmisores. Este ltimo es vulnerable al ruido de forma similar al Serie. La generalizacin de la norma USB a prcticamente todos los dispositivos electrnicos de uso diario, hace q este tipo de cable sea de muy fcil obtencin con grados de calidad realmente bueno. La compatibilidad futura se refiere a la proyeccin de nuevas tecnologas y si las actuales van a pode funcionar con las mismas. Este aspecto es clave para la norma USB porque una de las premisas bsicas es la compatibilidad tanto hacia el pasado como al futuro de la norma. Se pudo notar q el surgimiento de la norma USB 2.0 no releg a la USB 1.0. Se proyecta que la norma USB 3.0 va a ser totalmente compatible con las primeras versiones de la misma. La cantidad de conexiones es otro factor que representa una ventaja importante para el USB; la cantidad de conexiones se refiere a cuntos equipos se pueden interconectar en un mismo bus. Es decir en el caso del puerto serie no se pueden conectar ms de 2 equipos, el host y el perifrico. Para el caso del paralelo conectando en modo Daisy Chain se puede llegar hasta 8 equipos interconectados. La norma USB puede llegar a conectar hasta 127 equipos en un solo bus. Esto permite una multitud de perifricos que se pueden conectar a un solo puerto USB del host. La disponibilidad se refiere a la presencia de las conexiones de cada norma en PCs actuales siempre considerando modelos estndar.

Principios bsicos del USB El USB es un mtodo de interconexin controlado por el Host. Es este quien elije con qu dispositivo conectarse en cada momento y el modo en que se van a comunicar. Topologa del USB

HUB PPAL

DISPOSITIVO

DISPOSITIVO

DISPOSITIVO

HUB

DISPOSITIVO

HUB

DISPOSITIVO

HUB

DISPOSITIVO

DISPOSITIVO

DISPOSITIVO

DISPOSITIVO

La topologa de conexin del bus es el de estrellas interconectadas. En el centro de la estrella se encuentra lo que se llama el hub, los dispositivos que se pueden conectar a estos varan entre 4 a 7 unidades. Del mismo modo otros hub pueden conectarse entre s formando una especie de conexin en niveles. La topologa de conexin slo describe el aspecto fsico de la misma, dado que desde el punto de vista del desarrollador slo se tiene en consideracin la informacin lgica de cada dispositivo. El Root hub solo tendr acceso a un dispositivo cada vez para maximizar el ancho de banda del canal. Se puede llegar a conectar hasta 5 hub en cascada para alcanzar un total de 127 dispositivos conectados al bus, incluyendo el Root hub. Esto por supuesto se trata de la situacin ms desfavorable para la comunicacin, es por esto que la PC normalmente tiene varios Root hub desde donde conectarse. Existen dispositivos que aparentan no tener un Hub. Hay equipos que permiten que otros se conecten directamente al mismo. Pero en realidad estos tiene incluido un hub para futuras conexiones.

Dentro de una red USB las tareas del host son las siguientes: Detectar los dispositivos conectados a la red: cuando un dispositivo se conecta a la red el host debe aprender las caractersticas de cada dispositivo conectado a la red. Manejar el flujo de datos: en el momento de la inicializacin, el dispositivo negocia un cierto ancho de banda para la comunicacin. A partir de ese momento es el host el encargado de que ese dispositivo reciba el derecho a uso del bus necesario para alcanzar el ancho de banda. Chequear errores: el host deber siempre verificar el control de errores de cada msj para la deteccin d errores. Dar energa a los dispositivos: la norma USB asegura que un bus debe ser capaz de dar una tensin continua de 5V y 500mA Envo y recepcin de datos con los dispositivos. Las tareas para los dispositivos son las siguientes: Detectar sus propias comunicaciones: cada dispositivo es responsable de identificar si cierto paquete de datos fue enviado a l, o a otro conectado en la misma red. Esto normalmente est resuelto a nivel del HW para simplificar el SW. Responder a pedidos estndar: hay ciertos msj q requieren respuestas especficas; esto es especial al momento de la inicializacin del dispositivo. Chequeo de errores: igual q en el host, cada dispositivo es responsable de hacer un chequeo de error de cada msj. Manejo de poder: contando con el host en el envo de energa es responsabilidad del dispositivo el manejo del poder, por ejemplo el caso del bus q entra en modo bajo consumo, el dispositivo debe entender esto como que el host est en pausa y ponerse a s mismo en modo bajo consumo. Envo y recepcin de datos con el host. Velocidad del Host y del Bus El bus 2.0 es capaz de emplear todas las velocidades posibles. El bus 1.x slo puede trabajar a Low Speed. Los Hub 1.x no hacen ningn proceso de conversin de velocidad, solo pasa los paquetes recibidos. Los Hub 2.0 tienen la capacidad de almacenar y retransmitir los paquetes, puede analizar los paquetes y convertirlos para pasar de un bus 2.0 a uno 1.x. Las velocidades son: Low Speed: 1Mbit/seg. Full Speed: 12 Mbits/seg. High Speed: 480 Mbits/seg. El bus USB 3.0 soporta velocidades de 4.8Gbits/seg.

En la figura podemos ver cmo se establecen las conexiones en un Bus mixto en tecnologas y velocidades

Elementos de una transferencia Cada transferencia est compuesta por una o ms transacciones (transactions) y cada una de estas est compuesta por uno o varios paquetes (packets) en donde va la informacin. Tanto la Transferencia como las Transactions son bidireccionales, es decir, en una misma hay msj desde y hacia el Host. Los packets dependiendo de su funcin son en una sola direccin, por ejemplo el Token packet siempre saldr del Host. Hay otros como el HandShake packet q depender de quien es el que est acusando el correcto recibo de la informacin; puede originarse en el Host o el Dispositivo. Por tratarse de un protocolo controlado por el Host, siempre por norma se refiere a msj OUT a paquetes que se originan en el host y estn destinados a un dispositivo y a msj IN como aquellos que se originan en el dispositivo. Esto no considera el trfico de informacin o el tipo de msj. Como se coment con anterioridad, tanto el Dispositivo como el Host pueden generar msjs de Handshake, pero la norma define q siempre q los paquetes tengan como destino el Host sern In y OUT cuando el mismo sea el origen

TRANSFER

CADA TRANSFERENCIA TIENE 1 O MS ACCIONES

TRANSACCION

TRANSACCION

TRANSACCION

CADA TRANSACCIN TIENE HASTA PAQUETES TOKEN, DATA Y HANDSHAKE

PAQUETE TOKEN

PAQUETE DATA

PAQUETE HANDSHAKE

CADA PAQUETE TIENE SU COMPOSICIN DEFINIDA

PID

DIRECCIN ENDPOINT

CRC

PID

DATA

CRC

PID

Cada transaccin tiene hasta 3 packets, que ocurren en secuencia. stas son token, data y handshake. Cada uno de estos packets tiene cierta informacin incluida dependiendo el uso o las caractersticas del mismo. A. Token: el Token siempre ser enviado por el Host. a. PID: el PID es la identificacin del Token. Este puede ser un comando de setup o la seal para que el dispositivo comience a transmitir o recibir informacin. Estos pueden ser OUT, IN SOF (start of frame), SETUP. b. ADDRESS: es el nmero de identificacin del dispositivo. c. ENDPOINT: es el nmero de endpoint del dispositivo detallado en ADDRESS. d. CRC: informacin usada para el chequeo de errores. B. Data: el paquete Data puede ser bidireccional. a. PID: es el identificador de la informacin que se est enviando. Puede ser DATA0, DATA1, DATA2 (usados para secuenciar paquetes) o MDATA (para transacciones divididas Split transactions). b. DATA: es la informacin en s. c. CRC: informacin usada para el chequeo de errores. 7

C. Handshake: a. PID: es el cdigo de retorno para el final de la transaccin. Puede ser: ACK, NACK, STALL (el dispositivo est en pausa) o NYET (an no se complet un Split transactions). Existen otros considerados Special Handshake con objetivos ms precisos para incrementar el rendimiento a altas velocidades. Esta secuencia de paquetes en general est encapsulada dentro del controlador USB de cada integrado. Es decir el desarrollador no necesita esperar un token para recin enviar el paquete de datos; de igual modo no necesita verificar el CRC de cada paquete para evitar prdida de informacin o paquetes ruidosos. Todas estas tareas estn automatizadas en el microchip controlador del dispositivo. Endpoints Todos los msj del bus viajan hacia o desde el endpoint de un dispositivo. Normalmente el endpoint es un bloque de memoria de datos o un registro en el controlador de chip. Los datos almacenados en un endpoint pueden ser datos recibidos o a la espera de datos a transmitir. El Host tambin tiene que prever buffers para los datos recibidos y los datos a la espera de transmitir, pero el Host no tiene parmetros. Por el contrario, el Host sirve como el inicio y fin para las comunicaciones con un dispositivo y sus endpoints. El endpoint es principal diferencia entre un dispositivo y un Hub. El Hub no tiene endpoints aunque necesite buffers para la recepcin y retransmisin de los paquetes. La direccin de un endpoint es un nmero que va desde 0 al 15 y cada uno tendr 2 buffers asociados, uno de IN y otro de OUT, siempre desde el punto de vista del Host, es decir desde el punto de vista del dispositivo. El endpoint 1 IN es un buffer de salida mientras que el endpoint 1 OUT es un buffer de entrada. Cada dispositivo deber tener siempre un endpoint 0 reservado en modo de control para todos los msj inherentes al bus como statos, reset, sleep, etc. Esto no significa que sea el nico endpoint destinado a este modo. Puede presentarse el caso del que hayan varios aunque rara vez se justifique esta modalidad. Cada paquete enviado por el bus tendr al principio el nmero de dispositivo y el de endpoint de destino. Adems estar un cdigo que identificar si el paquete es del tipo IN, OUT o SETUP. Son estos datos los que emplear cada dispositivo para identificar si el paquete es para l o no. Pipes Antes de q cualquier transferencia se lleve a cabo, se necesita establecer un Pipe. Un Pipe es la asociacin lgica entre un endpoint de un dispositivo de destino y el Host. El Pipe se establece en el momento de la enumeracin, adems de este momento el host tiene la posibilidad de eliminar los Pipes, ya sea que el dispositivo se desconect o no, o pedir que un Pipe se restablezca en cualquier momento. Todos estos comandos siempre se establecen por el Pipe de control por default conectado al endpoint cero del dispositivo. La informacin de cmo deber trabajar el Pipe se enva en la enumeracin encapsulada en lo que se llaman descriptores. Estos descriptores contienen toda la configuracin del Pipe que estn enumerando ya sea modo de conexin, velocidad de transferencia, si aplica intervalos de transferencia, etc. Por cada Pipe el dispositivo establezca con el Host hay un juego de descriptores a enviar.

Splits transactions Este modo de trabajo est pensado para el caso de conexiones mixtas, es decir cuando se conecta a un bus que est funcionando a 2.0 un dispositivo 1.x. La versin 2.0 de la norma es como mnimo 40 veces ms rpido que el 1.x. Por lo que cuando el host le est enviando informacin al dispositivo 1.x, el Hub realiza una Split Transaction. El Hub evitar que el host quede esperando al dispositivo, inutilizando todo el bus, mientras enva el paquete de informacin. Le reportar al Host que puede enviar a otro dispositivo informacin, hasta que termine de enviar el paquete al dispositivo ms lento. Esto nuevamente es una negociacin interna del bus y est encapsulada en el controlador del host y de los hub. Todo esto es totalmente transparente para el desarrollador. Comunicacin en el USB Las comunicaciones dentro del USB son bsicamente de 2 tipos. Pueden ser de enumeracin o de aplicacin. Comunicaciones de enumeracin: durante la comunicacin de enumeracin, el dispositivo intercambia cierta informacin estndar con el host. Esto se hace con msj de formato prefijado para la negociacin de cmo funcionar el bus en el modo aplicacin. Esta comunicacin se realiza siempre a Low Speed por el cao, o pipe, cero (pipe de control) Comunicacin de aplicacin: una vez terminada la comunicacin de enumeracin, el dispositivo inicia la comunicacin de la aplicacin. Esta etapa ya est supeditada al dispositivo en s, es decir cul es la funcin o cul es la informacin que este debe intercambiar con el host. Esta comunicacin ya se realiza del modo que se negoci en la enumeracin por el pipe previsto. Es decir ya en esta etapa se comunicara en modo Bulk, Sincrnico o interrupcin. El USB distribuye el uso del canal en paquetes llamados frames. Dentro de estos frames, el Host acomoda los distintos paquetes con informacin hacia o desde los dispositivos. En la figura se puede ver una representacin de varios frames y cmo el host podra distribuir los paquetes. En este diagrama se representa Bus trabajando a Full Speed debido a que la duracin de los frames es de 1mSeg.

DEVICE 5 . ENDPOINT 3

DEVICE 1 . ENDPOINT 1

DEVICE 2 . ENDPOINT 2

DEVICE 5 . ENDPOINT 3

DEVICE 5 . ENDPOINT 3

START OF FRAME

1 MILLISECOND FRAME

UNUSUED

START OF FRAME

START OF FRAME

DEVICE 1 . ENDPOINT 2 DEVICE 2 . ENDPOINT 0

DEVICE 1 . ENDPOINT 2 DEVICE 2 . ENDPOINT 0 DEVICE 5 . ENDPOINT 3

DEVICE 2 . ENDPOINT 0

1 MILLISECOND FRAME 1 MILLISECOND FRAME

UNUSUED

DEVICE 5 . ENDPOINT 3

UNUSUED

10

Modos de transferencias del USB El USB tiene 4 formas de trabajo (Bulk, Control, Interrupcin y Sincrnico). Estos 4 modos tienen algunas diferencias entre s, para potenciar el rendimiento del bus de acuerdo a la tarea que se planea realizar. Un mouse o un teclado no tienen las mismas necesidades de comunicacin que puede tener un disco rgido externo. Adems de los diferentes volmenes de informacin, podemos mencionar la velocidad de respuesta o cunto podra demorar en enviar un paquete en cada uno de los casos. Es importante mencionar que un bus USB siempre va a tener varios pipes con distintos modos de trabajo cada uno. Por ejemplo, en el caso de un dispositivo como un reproductor de audio que recibe la informacin va USB, tendr un pipe en modo sincrnico, pero adems tendr otro pipe habilitado en modo control para continuar intercambiando informacin inherente al bus mismo. Las principales diferencias estn en el modo en que se intercambia informacin entre el host y los dispositivos
Tipo transferencia Uso Tpico de

Control
Identificacin y configuracin

Bulk
Impresoras, Scanner, dispositivos de memoria NO NO 53248 (13 transacciones de 512 bytes/microframe)

Interrupcin
Mouse, teclado

Sincrnico
Dispositivos de reproduccin de audio o video NO NO 24576 (3 transacciones de 1024 bytes/microframe)

Requerido? Puede trabajar a Low Speed? Capacidad de transferencia. Bytes mxima por pipe. En bytes/mSeg. High Speed Capacidad de transferencia. Bytes mxima por pipe. En bytes/mSeg. Full Speed Capacidad de transferencia. Bytes mxima por pipe. En bytes/mSeg. Low Speed Direccin del flujo de datos Reserva de ancho de banda. En porcentaje del ancho de banda Deteccin de error MensajesoDatos Velocidad garantizada? Intervalo entre paquetes garantizado?

SI SI 15872 (31 transacciones de 64 bytes/microfra me) 832 (13 transacciones de 64 bytes/microfra me) 24 (3 transacciones de 8 bytes/frame)

NO SI 24576 (3 transacciones de 1024 bytes/microframe)

1216 (19 transacciones de 64 bytes/frame)

64 (1 transacciones de 64 bytes/frame)

1023 (1 transacciones de 1023 bytes/frame)

No es posible

0.8 (enva 8 bytes cada 10 mSeg.)

No es posible

Bidireccional

Bidireccional

10% a Low y Full Speed; 20% a High Speed SI Mensajes NO NO

NO

Bidireccional (USB Bidireccional 1.0 soporta solo de entrada) 90% a Low y Full Speed, 80% a High Speed (La combinacin de sincrnico con interrupcin dan el total)

SI Datos NO NO

Datos NO SI

Datos SI SI

11

Modos de transferencia Modo de transferencia de control Este modo est orientado para el proceso de enumeracin donde el host recibe los datos de configuracin del pipe. A pesar que es importante no se limita solo a la inicializacin del pipe; pueden implementarse msj especficos que no estn contemplados en la norma. a. Disponibilidad: cada dispositivo debe tener un endpoint en el modo control, el nmero cero siempre debe estar configurado de este modo. Puede tener otros pero realmente es difcil de justificar canales de control extra. No representa ninguna ventaja para el Host como para el protocolo de mltiples pipes de control. b. Estructura: cada transferencia de control tiene como mximo 3 etapas: Setup, Data (opcional) y Status. Data es una etapa de la transferencia que puede no estar, pero las otras 2 son imprescindibles. La transferencia en una transaccin de control puede ser tanto IN como OUT por lo que se emplean ambos buffers del endpoint. Una transaccin de control de escritura es equivalente a una OUT es decir es Data que sale del Host y tiene como destino un dispositivo. En caso de que la transaccin sea del tipo OUT y no tenga Data involucrada, tambin se la considera de escritura. En una transferencia de lectura, Data viaja del dispositivo al Host, es decir, estamos en una transferencia del tipo IN. En la etapa de enumeracin, el host enviar una transaccin del tipo Setup que incluir el paquete Token, con la identificacin del pedido como uno de control. El paquete Data conteniendo informacin sobre el pedido en s, incluyendo el nmero de pedido, si habr o no una etapa de datos, y de haberla, en qu direccin viajara esa informacin. Estas estructuras de msjs o la respuesta correcta a cada pedido del Host deben ser implementadas por el desarrollador. Por esto es una herramienta de gran importancia el uso de cdigo realizado por terceros, que incluyen toda la mensajera de acuerdo al estndar. Este cdigo es conocido como STACK USB. c. Tamao del paquete Data: Tamao del paquete en modo control Low Speed 8 bytes Full Speed 8, 16, 32 o 64 bytes High Speed 64 bytes Todos los paquetes menos el ltimo deben tener el tamao mximo definido por el endpoint. Este tamao se define en el momento de la enumeracin en el descriptor que enva el dispositivo. En caso de tener varios pipes de control, cada uno habr definido en su descriptor el tamao del paquete en uso. Si la cantidad de informacin supera el tamao de un paquete y adems es mltiplo par del tamao del mismo, es decir, el ltimo paquete esta completo y coincide con el final de la informacin a transmitir, el dispositivo deber enviar un paquete vaco en el siguiente pedido del Host para que ste entienda el final de la transferencia.

12

d. Velocidad: el host es responsable de reservar cierto porcentaje del bus para el o los canales de control que tenga el sistema. Para Low Speed se reserva un 10% y para velocidades ms altas, un 20%. Esta reserva no restringe al pipe de control a usar ms porcentaje del bus de ser necesario. Hay opiniones que intentan dar prioridad a los pedidos estndar del pipe de control. Estos opinan que el Host debe dar prioridad siempre a este tipo de msj y dejar en 2do lugar los dems. Otras opiniones indican que esto no debe hacerse porque la norma no indica que el pipe de control debe estar dedicado exclusivamente a pedidos estndar, es decir, el usuario puede crear msjs propios, para el pipe de control y estos no deberan tener una prioridad diferente a los estndar. El modo de control es uno de los modos ms ineficientes para la transferencia de datos. Esto se debe principalmente a la cantidad de informacin extra por cada paquete de datos. Por cada paquete de datos hay un total de 63 bytes en Low Speed, 45 bytes en Full Speed y 173 bytes en High Speed. Cada paquete de datos deber tener un token y otro de handshake por lo que otros modos son ms eficientes. En caso de haber varios dispositivos con sus pipes de control conectados, stos tendran que compartir el ancho de banda reservado. Esto hara que una transferencia pueda estar dividida en varios frames y la comunicacin sea aun ms lenta. Los dispositivos no tienen exigencia de responder de forma inmediata un llamado del modo de control; la norma especifica tiempo de respuesta vlidos. El dispositivo puede demorar hasta 500 mSeg antes de responder al Host. En caso de que el dispositivo no pueda responder en este tiempo, puede enviar un msj de NAK y el Host renovar el temporizador para 500 mSeg ms; esto se puede repetir por 5 seg. Cada paquete tiene un tiempo de espera de 50 mSeg, lo q significa q cada paquete puede extender el tiempo de espera. e. Deteccin y manejo de errores: si un dispositivo no retorna un valor vlido como Handshake, el Host repite 2 veces ms el msj antes de reportar el error. Esto no incluye la respuesta NACK desde el dispositivo. La transferencia de control emplea un valor en el empaquetado que identifica los paquetes con cierta alternancia (Data toggles); esto permite detectar si se est recibiendo los paquetes sin perder ninguno. Hay casos en que por ejemplo si el dispositivo est enviando datos al Host, el dispositivo completa la tarea y espera el ACK del Host y luego el Token OUT para iniciar el Status. El dispositivo puede no recibir el ACK y s el Token OUT. Esto debe ser interpretado por el dispositivo como q el msj fue recibido de forma correcta y deber continuar con el proceso.

13

Modo de transferencia BULK El modo de transferencia es un mtodo ideal para el transporte de grandes volmenes de datos, ya sea desde o hacia el Host, donde el tiempo no representa un parmetro esencial. a. Disponibilidad: solo dispositivos en Full o High Speed pueden trabajar en este modo. Hay dispositivos como el de almacenamiento masivo deben tener un pipe en modo Bulk. b. Estructura: la estructura de este modo es bastante simple. El Host enva un paquete Token ya sea In u OUT, luego se inicia una secuencia de paquetes de datos. Se puede hacer que la transferencia sea bidireccional pero esto requiere la configuracin de 2 pipes, uno en cada sentido. La transferencia de paquetes termina cuando la cantidad de informacin fue transferida o llega a un paquete Data con ningn dato. El tamao de la transferencia de datos no est determinado por algn mensaje de la norma; esto debe establecerse con anterioridad mediante algn tipo de protocolo desarrollado por el usuario. En la fig. podemos ver los casos tpicos de una transferencia Bulk en ambos sentidos
Paquete Token Paquete Data Paquete HandShake

HOST>DISPOSITIVO
IDLE

DISPOSITIVO>HOST

HOST>DISPOSITIVO

IN

DATA

ACK

IDLE

ERROR NAK
IDLE

STALL

IDLE

Paquete Token

Paquete Token

Paquete Token

HOST>DISPOSITIVO
IDLE

HOST>DISPOSITIVO

DISPOSITIVO>HOST

OUT

DATA

ACK

IDLE

NAK

IDLE

STALL

IDLE

IDLE

14

c. Tamao del paquete de datos: en Full Speed el modo BULK puede enviar, 8, 16, 32, 64 bytes por paquete. En High Speed este tamao puede llegar a 512 bytes. Durante la enumeracin es cuando el dispositivo reporta cul es el tamao del paquete que se va a emplear. Cuando la cantidad de informacin a transferir es mayor a la disponible en un paquete, el dispositivo puede generar varios paquetes Data. d. Velocidad: en modo Bulk, el Host no hace ninguna reserva de ancho de banda en el bus. Puede emplear el porcentaje que dejan los canales de control o sincrnico. Esto puede hacer que una transferencia en modo BULK se extienda en el tiempo. Pero teniendo esto en mente, cuando el bus est desocupado, el pipe en modo Bulk puede emplearlo completamente. Esto sumado a la baja sobrecarga de msjs de la norma, hace q este modo sea el ms rpido en comparacin con los otros. En un solo frame se pueden enviar 19 paquetes de 64 bytes lo que da una capacidad de transferencia de 1.217 MegaBytes/seg. De esta forma solo queda libre un 2% del bus. La velocidad real del modo de trabajo BULK puede variar dependiendo del software del driver y del protocolo propietario del Host. Adems existen otros factores como reintentos y velocidad de acceso a memoria que tambin inciden en la tasa de transferencia. e. Manejo de errores: el modo Bulk emplea la deteccin de errores tanto en el CRC como el handshake apropiado. El host har 2 reintentos luego de un handshake no esperado y esto no incluye los NACK. El Host tendr la opcin de contar la cantidad de NACK para, al llegar a un mximo, reportar el error. Adems, el modo BULK emplea el Data toggle para detectar la prdida de paquetes. Modo de transferencia Interrupcin Este modo est particularmente pensado para aquellos dispositivos q necesitan conectarse o enviar informacin en periodos de tiempo muy especficos. Por ejemplo, el usuario no debe percibir la espera entre la presin del botn, o el movimiento del mouse y el efecto esperado en la PC. En Low y Full Speed el canal reservado para este modo es bastante limitado, puesto que est pensado para un trnsito de informacin muy rpido y muy pequeo. En High Speed sin embargo, se puede llegar a transmitir hasta 400 veces ms informacin que en Full Speed. El nombre de modo de interrupcin puede sugerir que es el dispositivo quien inicia la transmisin, pero no es as. Este modo emplea exactamente el mismo mecanismo de msjs q el modo Bulk solo que los tiempos son mucho ms cortos. Todo esto con la intencin de reducir los tiempos de espera al mnimo posible. a. Disponibilidad: todas las velocidades soportan el modo de transferencia Interrupcin. Los dispositivos no necesitan tener un pipe en este modo, pero hay ciertas clases de dispositivos que s, por ej, los HID class (Human Iinterface Devices class). b. Estructura: la estructura del modo Interrupcin es igual a Bulk, solo que los tiempos de espera son distintos. Una transferencia de interrupcin solo puede ser en una sola direccin. Para que la comunicacin sea bidireccional es necesario usar 2 transferencias en distintos pipes. La transferencia termina de una de dos formas: por la recepcin de toda la informacin esperada o por la recepcin de un paquete Data vaco. En caso de q el Bus sea mixto, el modo de interrupcin emplear el modo de Split Transaction. 15

c. Tamao del paquete de datos: Tamao del paquete en modo interrupcin Low Speed 1 a 8 bytes Full Speed 1 a 64 bytes High Speed 1 a 1024 bytes Como en todos los casos, en caso de necesitar enviar ms informacin, proceder a hacer varias transacciones para completar la transferencia. d. Velocidad: en el modo Interrupcin se garantiza una latencia mxima. Esto significa que no hay garanta de tener una capacidad de transferencia. El Host intentar repetir la transferencia de acuerdo al intervalo programado. Velocidad Low Speed Full Speed High Speed Valores de latencia 10 a 255 mSeg 1 a 255 mSeg 125 microseg a 4 seg. En pasos de 125 microseg

En el cuadro se seala cules son los valores para programar la latencia del sistema. Esto no quita q el Host pueda enviar antes del tiempo programado una nueva transferencia. Por ejemplo, un pipe en modo Interrupcin que tiene una latencia de 10 mSeg garantiza que al Host le tomar como mximo 50 mSeg completar 5 transferencias, pero no inhibe al Host a completar las 5 transferencias en 5 mSeg, una cada frame. Se haba sealado q el modo Interrupcin no reserva un ancho de banda, pero hay una excepcin: en caso de programar un tiempo de latencia tan bajo que pueda alcanzar el ancho de banda de un pipe. Por ejemplo, tenemos el caso de un pipe 1.x trabajando a Full Speed con la latencia programada en 1 mSeg. Esto hara que en cada frame, el host est enviando una transaccin a este dispositivo. A Full Speed se pueden enviar 19 transacciones de 64 bytes en un frame. Si se programa el pipe como en el ejemplo anterior, cada transaccin tendra que ser para un dispositivo diferente. Esto sera imprctico debido a que en realidad el Host no va a tener la capacidad de manejar los 19 endpoints en un solo frame. Podr manejarlos pero el compromiso se paga con tiempo de transferencia. A High Speed el lmite es de 2 transferencias por microframe, cada transferencia de 1024 bytes. Estas limitaciones permiten que el Bus no se use completamente con transmisiones de interrupcin de muy baja velocidad. La cantidad extra de informacin a transferir en modo interrupcin por cada paquete de datos es de 19 bytes en baja velocidad, 13 bytes a Full Speed y 55 bytes a High Speed. En High Speed el modo de interrupcin combinado con el sincrnico pueden llegar a ocupar hasta un 80% del microframe. En Full Speed sincrnico y Full o Slow Speed, este modo puede llegar a ocupar el 90% de un frame. e. Manejo de errores: como en el caso del modo Bulk, el modo de Interrupcin usar los msjs de respuesta para verificar si la informacin fue apropiadamente recibida. La principal diferencia es que en modo interrupcin, prcticamente nunca se establece un lmite para los reintentos despus de un NACK. Esto se debe a que un dispositivo puede estar sin uso por plazos extendidos, pero al momento de usarse, deben actuar de forma inmediata.

16

Modo de transferencia sincrnico Este modo est pensado para dispositivos q necesitan recibir informacin de forma constante y con la posibilidad de tolerar cierto error en cada transferencia. Como ejemplos de estos modos, tenemos a dispositivos q reproducen o capturan audio o video. a. Disponibilidad: solo dispositivos q trabajan a Full o High Speed pueden emplear el modo Interrupcin. Hay algunas clases de dispositivos q necesitan usar este modo de transferencia. b. Estructura: en modo sincrnico se garantiza que una parte del frame o microframe estar reservada para la transferencia. Este es el nico modo q garantiza esto, salvo, por supuesto, el caso del modo Interrupcin con tiempos de latencia mnimos. A Full Speed, una transferencia asincrnica consiste en una transaccin IN u OUT por frame o cada cierta cantidad de frames. En High Speed es un poco ms flexible; pueden llegar a haber hasta 3 transacciones en un microframe, una cada 32768 microframes. En la fig. siguiente se puede ver la secuencia de transacciones involucradas en una transferencia asincrnica.

PAQUETE TOKEN

PAQUETE DATA

HOST>DISPOSITIVO
IDLE

DISPOSITIVO>HOST

IN

DATA

IDLE

PAQUETE TOKEN

PAQUETE DATA

HOST>DISPOSITIVO
IDLE

HOST>DISPOSITIVO

OUT

DATA

IDLE

El protocolo no establece un valor de transferencia que indique la cantidad de informacin a transferir, por lo q debe establecerse mediante un protocolo creado por el desarrollador. El Host es el encargado de reservar el ancho de banda del bus para establecer un pipe sincrnico. En Full Speed un pipe q reserve una transferencia de 1023 bytes por frame, est usando el 69% del pipe. Si un segundo dispositivo solicita la misma capacidad de transferencia, el Host lo rechazara debido a la no disponibilidad de ancho de banda. Toda la negociacin del ancho de banda se realiza por el pipe de control 0. Por lo q antes de establecerse el pipe, el dispositivo pudo negociar con el Host un ancho de banda menor o esperar a q se libere el bus para volver a pedir el ancho de banda requerido. Es importante sealar q aunque el modo sincrnico tenga una tasa constante de transferencia de informacin, no tiene una tasa constante de transferencia de bits. Es decir, el arribo de informacin no debe ser tomado como una referencia de tiempo. Hay varios factores q inciden en esto; est por ejemplo la informacin extra que el Host necesita enviar y sobre todo el hecho de q el paquete se enva a la mxima velocidad posible; de sobrar tiempo en el frame o microframe, el bus queda sin uso.

17

El modo sincrnico tiene un mecanismo para q un dispositivo use seales del bus para cierta sincronizacin. Se podra emplear por ejemplo, el principio de un frame (Start Of Frame) para hacer q varios dispositivos puedan sincronizarse entre s conectados al bus. c. Tamao del paquete de datos: a Full Speed, el tamao mximo de un paquete sincrnico puede ir de 0 a 1023 bytes. En caso de necesitar enviar ms informacin, el Host usara varias transacciones. Una vez establecido el tamao del paquete, no necesariamente pueden ser todos iguales. Por ejemplo, para una tasa de transferencia de 44.100 bytes/seg, peude haber 9 transacciones de 44 bytes, seguidas de una de 45 bytes. d. Velocidad: a Full Speed en modo sncrono, se puede llegar a enviar 1023 bytes por frame. Esto lleva a poder transmitir 1.023 MegaBytes/seg. Esto significa q queda un 31% del bus libre para otros usos. La necesidad de informacin extra para trabajar este modo es de 9 bytes por paquete de datos. Esto representa menos de un 1% de la informacin transferida. El ancho de banda mnimo que se puede reservar es de 1 byte por frame, lo que da una tasa de transferencia de 1 KB/seg. En High Speed en una transaccin se puede llegar a transmitir hasta 1024 bytes. Si el endpoint necesita ms de esta cantidad puede llegar hasta 3 transacciones en un microframe para llegar a una tasa de transferencia de 24.576 MegaBytes/seg. La cantidad de informacin extra para el envo en este modo es de 39 bytes por paquete de datos. En High Speed no necesita enviar una transaccin de datos en cada microframe. Esto hace q se puede enviar 1 byte cada 4.096 segundos. Desde ya, el endpoint puede enviar menos informacin de la que est reservada, o puede saltear el envo de algunos paquetes. En High Speed el modo de interrupcin combinado con el sincrnico pueden llegar a ocupar hasta un 80% del microframe. En Full Speed sincrnico y Full o Slow Speed Interrupcin, pueden llegar a ocupar el 90% de un frame. e. Manejo de errores: el precio que se paga por tener asegurado el ancho de banda, es el de que no haya correccin de errores. El modo de transferencia sincrnico est especialmente pensado para aquellos casos que un pequeo error es aceptable. El caso tpico es el de reproductor de audio; en caso de perder un segmento de informacin, el odo no detecta la prdida y puede pasarse por alto. En realidad el bus no debera tener problemas de error por ruido. En caso de establecer algn protocolo propietario para el control de errores, la reserva del ancho de banda hara q cualquier retransmisin atrase toda la transferencia.

18