Puerto Usb

PUERTO USB (Universal Serial Bus) Generalidades

El objetivo del desarrollo del puerto USB es reemplazar la tecnología antigua, como el puerto serie RS232 e IEEE 1284 (también denominados tipo Centronics) por una opción con mayor compatibilidad con tecnologías y equipamientos actuales. Como premisas esenciales se considera la seguridad en la transferencia de la información y la velocidad de la misma. La comunicación deberá ser bidireccional para asegurar la transferencia tanto desde el host al periférico y viceversa. Es importante que el periférico pueda ser conectado y desconectado con la PC funcionando, que no necesite reiniciar el equipo para poder establecer la comunicación. Otra premisa del diseño es que cada nueva versión del puerto USB deberá ser compatible con todas las versiones anteriores. Con estos aspectos podemos tener la generalización de conexión a cualquier computadora. La norma asegura que el proceso de registración puede llevarse a cabo sin necesidad de reiniciar el ordenador o exigir acción alguna por parte del usuario q no sea la sola instalación del driver apropiado. El mecanismo de identificación q usa el periférico asegura q la aplicación encuentre el periférico q requiere sin la necesidad de configuración 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 más 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 opción de contemplar el chequeo de la información transferida para asegurar el envío, dependiendo del modo de trabajo. Esto garantiza la correcta transmisión de información en cada caso. Es además un importante avance en comparación con los puertos a reemplazar, que la norma contempla la posibilidad de alimentar con tensión continua a través del mismo cable. En el caso del puerto serie esto podía ser logrado pero mediante el uso de pines de control. La máxima corriente que el puerto USB es capaz de proveer se limita a 500 miliamperios con una tensión de 5 voltios.

1

El logo USB compatible con la norma es el siguiente. Se refiere a módulos básicos con velocidades bajas:

Este logo se aplica a dispositivos que soportan altas velocidades:

Este logo representa a dispositivos que son compatibles con la característica On The Go. En velocidad básica o high speed. On The Go se refiere a dispositivos que pueden asumir el rol de periférico o host, no se refiere a un hub USB sino a dispositivos específicos:

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 señalado es USB:

Podemos ver el siguiente cuadro comparativo para tener una referencia más clara Modo de trabajo Velocidad Complejidad del soft Complejidad del hard Largo del cable Modos de trabajo Futura compatibilidad Cant. de conexiones Disponibilidad

Bus Serie

Bus Paralelo

USB

Serie Baja Baja Baja 15 metros 1 NO 2 Abandonándose

Paralelo Media Baja Alta 3 metros 2 NO 2 –8 Abandonada

Serie Alta Alta Baja 5 metros 4 SI 127 Universal

El modo de trabajo se refiere simplemente al modo de transmisión de cada bit de las palabras a transmitir. Tanto el Serie como el USB envían un bit a la vez mientras q el paralelo envía los 8 bits en un solo momento. La velocidad hace referencia al volumen de información que es capaz de transmitir el bus por unidad de tiempo. El caso del puerto serie está diseñado para una velocidad de 20 kilobits/seg aunque, con ciertas consideraciones, esta ha sido superada. El paralelo ya tiene un diseño q considera límites 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.

2

La complejidad del soft representa la única desventaja del USB respecto de los demás. Se refiere al soft extra, necesario para lograr que el puerto funcione de alguna forma en particular, por ejemplo, todo el intercambio de información al momento de la registración. El desarrollador siempre va a utilizar librerías 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 señalar una gran variedad de opciones de circuitos integrados q sirven de interface USB con la inteligencia como para establecer la registración y el intercambio de información con el Host, además de simplificar toda la señalización eléctrica del bus. En este punto es similar al puerto serie porque necesita de una interface entre el periférico 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 máximo contemplado por la norma para una transmisión 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 generalización de la norma USB a prácticamente todos los dispositivos electrónicos de uso diario, hace q este tipo de cable sea de muy fácil obtención con grados de calidad realmente bueno. La compatibilidad futura se refiere a la proyección de nuevas tecnologías y si las actuales van a pode funcionar con las mismas. Este aspecto es clave para la norma USB porque una de las premisas básicas 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 cuántos equipos se pueden interconectar en un mismo bus. Es decir en el caso del puerto serie no se pueden conectar más de 2 equipos, el host y el periférico. 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 periféricos 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 estándar.

3

Principios básicos del USB

El USB es un método de interconexión controlado por el Host. Es este quien elije con qué dispositivo conectarse en cada momento y el modo en que se van a comunicar. Topología del USB

HUB PPAL

DISPOSITIVO

DISPOSITIVO

HUB

DISPOSITIVO

DISPOSITIVO

HUB

DISPOSITIVO

DISPOSITIVO

DISPOSITIVO

DISPOSITIVO

HUB

DISPOSITIVO

La topología de conexión 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 varían entre 4 a 7 unidades. Del mismo modo otros hub pueden conectarse entre sí formando una especie de conexión en niveles. La topología de conexión sólo describe el aspecto físico de la misma, dado que desde el punto de vista del desarrollador sólo se tiene en consideración la información lógica 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 situación más desfavorable para la comunicación, 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.

4

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 características de cada dispositivo conectado a la red.  Manejar el flujo de datos: en el momento de la inicialización, el dispositivo negocia un cierto ancho de banda para la comunicación. 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 detección d errores.  Dar energía a los dispositivos: la norma USB asegura que un bus debe ser capaz de dar una tensión continua de 5V y 500mA  Envío y recepción 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 estándar: hay ciertos msj q requieren respuestas específicas; esto es especial al momento de la inicialización 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 envío de energía 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”. 

Envío y recepción 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 sólo puede trabajar a Low Speed. Los Hub 1.x no hacen ningún proceso de conversión 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.

5

En la figura podemos ver cómo se establecen las conexiones en un Bus mixto en tecnologías y velocidades

6

Elementos de una transferencia

Cada transferencia está compuesta por una o más transacciones (transactions) y cada una de estas está compuesta por uno o varios paquetes (packets) en donde va la información. 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 función son en una sola dirección, 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 información; 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 están destinados a un dispositivo y a msj IN como aquellos que se originan en el dispositivo. Esto no considera el tráfico de información 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 serán In y OUT cuando el mismo sea el origen

TRANSFER

TRANSACCION

PAQUETE TOKEN

PID

DIRECCIÓN ENDPOINT

CADA TRANSFERENCIA TIENE 1 O MÁS ACCIONES

TRANSACCION

PAQUETE DATA

CRC

PID

TRANSACCION

CADA TRANSACCIÓN TIENE HASTA PAQUETES TOKEN, DATA Y HANDSHAKE

PAQUETE HANDSHAKE

DATA

CRC

CADA PAQUETE TIENE SU COMPOSICIÓN DEFINIDA

PID

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

C. Handshake: a. PID: es el código de retorno para el final de la transacción. Puede ser: ACK, NACK, STALL (el dispositivo está en pausa) o NYET (aún no se completó un Split transactions). Existen otros considerados Special Handshake con objetivos más 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 recién enviar el paquete de datos; de igual modo no necesita verificar el CRC de cada paquete para evitar pérdida de información o paquetes ruidosos. Todas estas tareas están 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 también tiene que prever buffers para los datos recibidos y los datos a la espera de transmitir, pero el Host no tiene parámetros. 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 recepción y retransmisión de los paquetes. La dirección de un endpoint es un número 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 número de dispositivo y el de endpoint de destino. Además estará un código 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 asociación lógica entre un endpoint de un dispositivo de destino y el Host. El Pipe se establece en el momento de la enumeración, además 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 información de cómo deberá trabajar el Pipe se envía en la enumeración encapsulada en lo que se llaman descriptores. Estos descriptores contienen toda la configuración del Pipe que están enumerando ya sea modo de conexión, 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.

8

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 versión 2.0 de la norma es como mínimo 40 veces más rápido que el 1.x. Por lo que cuando el host le está enviando información 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 envía el paquete de información. Le reportará al Host que puede enviar a otro dispositivo información, hasta que termine de enviar el paquete al dispositivo más lento. Esto nuevamente es una negociación interna del bus y está encapsulada en el controlador del host y de los hub. Todo esto es totalmente transparente para el desarrollador. Comunicación en el USB

Las comunicaciones dentro del USB son básicamente de 2 tipos. Pueden ser de enumeración o de aplicación. Comunicaciones de enumeración: durante la comunicación de enumeración, el dispositivo

intercambia cierta información estándar con el host. Esto se hace con msj de formato prefijado para la negociación de cómo funcionará el bus en el modo aplicación. Esta comunicación se realiza siempre a Low Speed por el caño, o pipe, cero (pipe de control) Comunicación de aplicación: una vez terminada la comunicación de enumeración, el

dispositivo inicia la comunicación de la aplicación. Esta etapa ya está supeditada al dispositivo en sí, es decir cuál es la función o cuál es la información que este debe intercambiar con el host. Esta comunicación ya se realiza del modo que se negoció en la enumeración por el pipe previsto. Es decir ya en esta etapa se comunicaría en modo Bulk, Sincrónico o interrupción. El USB distribuye el uso del canal en paquetes llamados frames. Dentro de estos frames, el Host acomoda los distintos paquetes con información hacia o desde los dispositivos. En la figura se puede ver una representación de varios frames y cómo el host podría distribuir los paquetes. En este diagrama se representa Bus trabajando a Full Speed debido a que la duración de los frames es de 1mSeg.

3 T N I O P D N E . 5 E C I V E D



D E U S U N U

1 MILLISECOND FRAME

9



D E U S U N U

1 MILLISECOND FRAME



D E U S U N U

1 MILLISECOND FRAME

10

Modos de transferencias del USB

El USB tiene 4 formas de trabajo (Bulk, Control, Interrupción y Sincrónico). 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 comunicación que puede tener un disco rígido externo. Además de los diferentes volúmenes de información, podemos mencionar la velocidad de respuesta o cuánto podría 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 información vía USB, tendrá un pipe en modo sincrónico, pero además tendrá otro pipe habilitado en modo control para continuar intercambiando información inherente al bus mismo. Las principales diferencias están en el modo en que se intercambia información entre el host y los dispositivos Tipo transferencia Uso Típico

de

Control

Bulk

Interrupción

Sincrónico

Identificación y configuración

Impresoras, Scanner, dispositivos de memoria NO NO

Mouse, teclado

Dispositivos de reproducción de audio o video

NO SI

NO NO

15872 (31 transacciones de 64 bytes/microfra me)

53248 (13 transacciones de 512 bytes/microframe)



832 (13 transacciones de 64 bytes/microfra me)

1216 (19 transacciones de 64 bytes/frame)




No es posible

0.8 (envía 8 bytes cada 10 mSeg.)

No es posible

Bidireccional (USB Bidireccional 1.0 soporta solo de entrada) 90% a Low y Full Speed, 80% a High Speed (La combinación de sincrónico con interrupción dan el total)

¿Requerido? ¿Puede trabajar a Low Speed? Capacidad de transferencia. Bytes máxima por pipe. En bytes/mSeg. High Speed Capacidad de transferencia. Bytes máxima por pipe. En bytes/mSeg. Full Speed Capacidad de transferencia. Bytes máxima por pipe. En bytes/mSeg. Low Speed Dirección del flujo de datos

SI SI

Bidireccional

Bidireccional

Reserva de ancho de banda. En porcentaje del ancho de banda Detección de error MensajesoDatos ¿Velocidad garantizada? ¿Intervalo entre paquetes garantizado?

10% a Low y Full Speed; 20% a High Speed

NO

SI Mensajes NO

SI Datos NO

Datos NO

Datos SI

NO

NO

SI

SI

11

Modos de transferencia Modo de transferencia de control

Este modo está orientado para el proceso de enumeración donde el host recibe los datos de configuración del pipe. A pesar que es importante no se limita solo a la inicialización del pipe; pueden implementarse msj específicos que no estén contemplados en la no rma. a. Disponibilidad: cada dispositivo debe tener un endpoint en el modo control, el número cero siempre debe estar configurado de este modo. Puede tener otros pero realmente es difícil de justificar canales de control extra. No representa ninguna ventaja para el Host como para el protocolo de múltiples pipes de control. b. Estructura: cada transferencia de control tiene como máximo 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 transacción de control puede ser tanto IN como OUT por lo que se emplean ambos buffers del endpoint. Una transacción 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 transacción sea del tipo OUT y no tenga Data involucrada, también 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 enumeración, el host enviará una transacción del tipo Setup que incluirá el paquete Token, con la identificación del pedido como uno de control. El paquete Data conteniendo información sobre el pedido en sí, incluyendo el número de pedido, si habrá o no una etapa de datos, y de haberla, en qué dirección viajaría esa información. 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 código realizado por terceros, que incluyen toda la mensajería de acuerdo al estándar. Este código es conocido como STACK USB. c. Tamaño del paquete Data: Tamaño 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 tamaño máximo definido por el endpoint. Este tamaño se define en el momento de la enumeración en el descriptor que envía el dispositivo. En caso de tener varios pipes de control, cada uno habrá definido en su descriptor el tamaño del paquete en uso. Si la cantidad de información supera el tamaño de un paquete y además es múltiplo par del tamaño del mismo, es decir, el último paquete esta completo y coincide con el final de la información a transmitir, el dispositivo deberá enviar un paquete vacío 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 más altas, un 20%. Esta reserva no restringe al pipe de control a usar más porcentaje del bus de ser necesario. Hay opiniones que intentan dar prioridad a los pedidos estándar del pipe de control. Estos opinan que el Host debe dar prioridad siempre a este tipo de msj y dejar en 2do lugar los demás. Otras opiniones indican que esto no debe hacerse porque la norma no indica que el pipe de control debe estar dedicado exclusivamente a pedidos estándar, es decir, el usuario puede crear msjs propios, para el pipe de control y estos no deberían tener una prioridad diferente a los estándar. El modo de control es uno de los modos más ineficientes para la transferencia de datos. Esto se debe principalmente a la cantidad de información 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 más eficientes. En caso de haber varios dispositivos con sus pipes de control conectados, éstos tendrían que compartir el ancho de banda reservado. Esto haría que una transferencia pueda estar dividida en varios frames y la comunicación sea aun más lenta. Los dispositivos no tienen exigencia de responder de forma inmediata un llamado del modo de control; la norma especifica tiempo de respuesta válidos. 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 más; 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. Detección y manejo de errores: si un dispositivo no retorna un valor válido como Handshake, el Host repite 2 veces más 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 método ideal para el transporte de grandes volúmenes de datos, ya sea desde o hacia el Host, donde el tiempo no representa un parámetro 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 envía 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 configuración de 2 pipes, uno en cada sentido. La transferencia de paquetes termina cuando la cantidad de información fue transferida o llega a un paquete Data con ningún dato. El tamaño de la transferencia de datos no está determinado por algún mensaje de la norma; esto debe establecerse con anterioridad mediante algún tipo de protocolo desarrollado por el usuario. En la fig. podemos ver los casos típicos de una transferencia Bulk en ambos sentidos Paquete Token

HOST>DISPOSITIVO IDLE

IN

Paquete Data

Paquete HandShake

DISPOSITIVO>HOST

HOST>DISPOSITIVO

DATA

ACK

IDLE

ERROR NAK

STALL

Paquete Token


OUT

IDLE

IDLE

Paquete Token

HOST>DISPOSITIVO

DATA

Paquete Token

DISPOSITIVO>HOST

ACK

NAK

STALL

IDLE

IDLE

IDLE

IDLE

14

c. Tamaño del paquete de datos: en Full Speed el modo BULK puede enviar, 8, 16, 32, 64 bytes por paquete. En High Speed este tamaño puede llegar a 512 bytes. Durante la enumeración es cuando el dispositivo reporta cuál es el tamaño del paquete que se va a emplear. Cuando la cantidad de información 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 sincrónico. 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 más rápido en comparación 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. Además existen otros factores como reintentos y velocidad de acceso a memoria que también inciden en la tasa de transferencia. e. Manejo de errores: el modo Bulk emplea la detección 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 opción de contar la cantidad de NACK para, al llegar a un máximo, reportar el error. Además, el modo BULK emplea el Data toggle para detectar la pérdida de paquetes. Modo de transferencia Interrupción

Este modo está particularmente pensado para aquellos dispositivos q necesitan conectarse o enviar información en periodos de tiempo muy específicos. Por ejemplo, el usuario no debe percibir la espera entre la presión del botón, 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 tránsito de información muy rápido y muy pequeño. En High Speed sin embargo, se puede llegar a transmitir hasta 400 veces más información que en Full Speed. El nombre de modo de interrupción puede sugerir que es el dispositivo quien inicia la transmisión, pero no es así. Este modo emplea exactamente el mismo mecanismo de msjs q el modo Bulk solo que los tiempos son mucho más cortos. Todo esto con la intención de reducir los tiempos de espera al mínimo posible. a. Disponibilidad: todas las velocidades soportan el modo de transferencia Interrupción. 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 Interrupción es igual a Bulk, solo que los tiempos de espera son distintos. Una transferencia de interrupción solo puede ser en una sola dirección. Para que la comunicación sea bidireccional es necesario usar 2 transferencias en distintos pipes. La transferencia termina de una de dos formas: por la recepción de toda la información esperada o por la recepción de un paquete Data vacío. En caso de q el Bus sea mixto, el modo de interrupción empleará el modo de Split Transaction. 15

c. Tamaño del paquete de datos: Tamaño del paquete en modo interrupción 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 más información, procederá a hacer varias transacciones para completar la transferencia. d. Velocidad: en el modo Interrupción se garantiza una latencia máxima. Esto significa que no hay garantía 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 señala cuáles 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 Interrupción que tiene una latencia de 10 mSeg garantiza que al Host le tomará como máximo 50 mSeg completar 5 transferencias, pero no inhibe al Host a completar las 5 transferencias en 5 mSeg, una cada frame. Se había señalado q el modo Interrupción no reserva un ancho de banda, pero hay una excepción: 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 haría que en cada frame, el host esté enviando una transacción 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 transacción tendría que ser para un dispositivo diferente. Esto sería impráctico 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 límite es de 2 transferencias por microframe, cada transferencia de 1024 bytes. Estas limitaciones permiten que el Bus no se use completamente con transmisiones de interrupción de muy baja velocidad. La cantidad extra de información a transferir en modo interrupción 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 interrupción combinado con el sincrónico pueden llegar a ocupar hasta un 80% del microframe. En Full Speed sincrónico 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 Interrupción usará los msjs de respuesta para verificar si la información fue apropiadamente recibida. La principal diferencia es que en modo interrupción, prácticamente nunca se establece un límite para los reintentos después 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 sincrónico

Este modo está pensado para dispositivos q necesitan recibir información 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 Interrupción. Hay algunas clases de dispositivos q necesitan usar este modo de transferencia. b. Estructura: en modo sincrónico 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 Interrupción con tiempos de latencia mínimos. A Full Speed, una transferencia asincrónica consiste en una transacción IN u OUT por frame o cada cierta cantidad de frames. En High Speed es un poco más flexible; pueden llegar a haber hasta 3 transacciones en un microframe, ó una cada 32768 mic roframes. En la fig. siguiente se puede ver la secuencia de transacciones involucradas en una transferencia asincrónica.

PAQUETE TOKEN

HOST>DISPOSITIVO

IN

IDLE

PAQUETE TOKEN


OUT

PAQUETE DATA

DISPOSITIVO>HOST

DATA

IDLE

PAQUETE DATA

HOST>DISPOSITIVO

DATA

IDLE

El protocolo no establece un valor de transferencia que indique la cantidad de información 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 sincrónico. 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 rechazaría debido a la no disponibilidad de ancho de banda. Toda la negociación 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 señalar q aunque el modo sincrónico tenga una tasa constante de transferencia de información, no tiene una tasa constante de transferencia de bits. Es decir, el arribo de información no debe ser tomado como una referencia de tiempo. Hay varios factores q inciden en esto; está por ejemplo la información extra que el Host necesita enviar y sobre todo el hecho de q el paquete se envía a la máxima velocidad posible; de sobrar tiempo en el frame o microframe, el bus queda sin uso.

17

El modo sincrónico tiene un mecanismo para q un dispositivo use señales del bus para cierta sincronización. Se podría emplear por ejemplo, el principio de un frame (Start Of Frame) para hacer q varios dispositivos puedan sincronizarse entre sí conectados al bus. c. Tamaño del paquete de datos: a Full Speed, el tamaño máximo de un paquete sincrónico puede ir de 0 a 1023 bytes. En caso de necesitar enviar más información, el Host usaría varias transacciones. Una vez establecido el tamaño 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 síncrono, 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 información extra para trabajar este modo es de 9 bytes por paquete de datos. Esto representa menos de un 1% de la información transferida. El ancho de banda mínimo 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 transacción se puede llegar a transmitir hasta 1024 bytes. Si el endpoint necesita más 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 información extra para el envío en este modo es de 39 bytes por paquete de datos. En High Speed no necesita enviar una transacción de datos en cada microframe. Esto hace q se puede enviar 1 byte cada 4.096 segundos. Desde ya, el endpoint puede enviar menos información de la que está reservada, o puede saltear el envío de algunos paquetes. En High Speed el modo de interrupción combinado con el sincrónico pueden llegar a ocupar hasta un 80% del microframe. En Full Speed sincrónico y Full o Slow Speed Interrupción, 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 corrección de errores. El modo de transferencia sincrónico está especialmente pensado para aquellos casos que un pequeño error es aceptable. El caso típico es el de reproductor de audio; en caso de perder un segmento de información, el oído no detecta la pérdida y puede pasarse por alto. En realidad el bus no debería tener problemas de error por ruido. En caso de establecer algún protocolo propietario para el control de errores, la reserva del ancho de banda haría q cualquier retransmisión atrase toda la transferencia.

18

Puerto Usb

Recommend Documents