RESUMEN USB

INTRODUCCION AL USB La versin USB 1.1 soporto dos velocidades, un modo de velocidad completa de 12Mbits / s y un modo de baja velocidad de 1.5Mbits / s. El modo de 1.5Mbits / s es el ms lento y menos susceptible a EMI, reduciendo as el costo de cuentas de ferrita y los componentes de calidad. Por ejemplo, los cristales pueden ser sustituidos por otros osciladores ms baratos. El USB 2.0 trabaja a una velocidad de 480 Mbits / s. El modo de 480 Mbits / s se conoce como Modo de alta velocidad y era una tctica para competir con el bus FireWire de serie. Velocidades USB: Alta velocidad-480Mbits/s Velocidad completa-12Mbits/s Baja velocidad-1.5Mbits/s

ARQUITECTURA El Universal Serial Bus conecta los dispositivos USB con el host USB. La interconexin fsica USB es una topologa de estrellas apiladas donde un hub es el centro de cada estrella. Cada segmento de cable es una conexin puntoa-punto entre el host y los hubs o funcin, o un hub conectado a otro hub o funcin. El nmero mximo de dispositivos que puede conectar USB es de 127, pero debido a las constantes de tiempo permitidas para los tiempos de propagacin del hub y el cable, el nmero mximo de capas permitido es de siete (incluida la capa raz) con un mximo de longitud de cable entre el hub y el dispositivo de 5 metros. Cabe destacar que en siete capas, slo se soportan cinco hubs que no sean raz en una ruta de comunicacin entre el host y cualquier dispositivo. Un dispositivo compuesto ocupa dos capas, por eso, no puede ser activado si est acoplado en la ltima capa de nivel siete. Slo las funciones pueden ponerse en este nivel.

El host USB El host es el sistema de computacin completo, incluyendo el software y el hardware, sobre el cual se sostiene el USB. El host tiene la habilidad de procesar y gestionar los cambios de configuracin que puedan ocurrir en el bus durante su funcionamiento. El host gestiona el sistema y los recursos del bus como el uso de la memoria del sistema, la asignacin del ancho de banda del bus y la alimentacin del bus. El host tambin ayuda al usuario con la configuracin automtica de los dispositivos conectados y reaccionando cuando son desconectados. Un host puede soportar uno o mas buses USB. El host gestiona cada bus independientemente de los dems. Los recursos especficos del bus como el ancho de banda asignado son nicos a cada bus. Cada bus est conectado al host a travs de un controlador del host. Slo hay un host en cualquier sistema USB. Desde el interfaz USB hasta el sistema de host del ordenador es lo que se le llama controlador de host y puede estar implementado como combinacin de hardware, firmware o software. Integrado dentro del sistema de host hay un hub raz que provee de un mayor nmero de puntos de acople al sistema. Siempre que es posible, el software del USB usa el interfaz existente del sistema de host para gestionar las interacciones superiores. Por ejemplo, si un sistema de host usa la Gestin de Energa Avanzada (APM), el software del USB conecta al APM para interceptar, suspender las notificaciones. El controlador del host El controlador de host est formado por el hardware y el software que permite a los dispositivos USB ser conectados al host. Este controlador es el agente iniciador del bus, es decir es el que comienza las transferencias en el bus. El controlador de bus es el maestro en un bus USB. Otros buses como PCI, permiten la presencia de mltiples maestros donde cada uno arbitra sus accesos al bus. El la arquitectura USB slo hay un controlador de host por cada bus USB y por eso no hay arbitracin para el acceso al bus. Como las transferencias de datos de los dispositivos pueden ser basadas en datos o en la disponibilidad espacial del dispositivo, la mayora de los controladores de host estn implementados como dispositivos maestros de bus PCI. Esto permite al controlador de host iniciar una transferencia de datos en el bus del sistema cuando le sea necesario, sin requerir la intervencin del host de la CPU para cada transferencia. El controlador se comporta como un bus maestro PCI multicanal programable para dar soporte a las necesidades de transferencia de datos de mltiples dispositivos conectados al bus USB.

Esta figura muestra una vista conceptual del controlador de bus USB. La parte software consiste en el driver del controlador de host (HCD). Este software interacta con el hardware del controlador de host a travs del interfaz hardware/software. La parte hardware del controlador de host consiste en un hub raz que proporciona los puertos USB y los buffers de datos (colas) donde son almacenadas cuando son movidas a/desde memoria. El host USB interacta con los dispositivos USB a travs del controlador. Las funciones bsicas del controlador de host son: Detectar la insercin o desconexin de dispositivos USB. Gestionar el flujo de control entre el host y los dispositivos. Gestionar el flujo de datos entre el host y los dispositivos. Coleccionar estadsticas de actividad y estado. Proveer una cantidad limitada de energa a los dispositivos conectados Hay dos implementaciones estandarizadas de la parte hardware de los controladores de host USB. Ambas proporcionan la misma funcionalidad y rendimiento para la interconexin. Estas implementaciones son:

El Universal Host Controller Inteface (UHCI) definido por Intel Open Host Controller Interface (OpenHCI o OHCI) definido por Microsoft

UHCI esta definido como que la parte software tiene una gran responsabilidad para mantener el hardware en funcionamiento. Esto permite a esta implementacin ser relativamente simple y realizarse con un bajo nmero de puertas. OHCI esta definida como que la parte hardware tiene ms responsabilidad por el mantenimiento del flujo de datos, para que la parte software tenga menos trabajo que hacer. Esta otra implementacin tiende a ser ms compleja y tiene una cantidad mayor de puertas que la UHCI. Con el USB 2.0 se introdujo otra especificacin llamada EHCI(Enhanced Host Controller Interface).

Dispositivos USB: El Hub es un dispositivo USB especial, que extiende la cantidad de ports para conectar dispositivos, convirtiendo un punto de conexin simple, en mltiples puntos de conexin. Por punto de conexin entendemos port. Las principales funciones de un hub son 2: el Incremento de los puntos de conexin a travs de puertos adicionales y proporcionar energa a los dispositivos al expandir el bus. Posee un puerto de subida (upstream) y varios puertos de bajada (downstream). Las Funciones son dispositivos conectados al bus capaces de recibir y transmitir informacin desde / hacia el Host Controller. Se denomina funcin debido a que no necesariamente la correspondencia funcin-dispositivo es uno a uno. Ejemplos de funciones en un Bus USB: Teclado, Mouse, lapiz ptico, una impresora, un modem(analgico, o ISDN) etc. 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. Cada dispositivo lleva consigo informacin que puede ser til para identificar sus caractersticas. La informacin que describe al dispositivo se encuentra asociada con el canal de control. Esta informacin se divide en tres categoras: Estndar: Esta es la informacin cuya definicin es comn a todos los dispositivos USB e incluye elementos como la identificacin del fabricante, la clase, la gestin de energia.... Clase: La definicin de esta informacin vara dependiendo del aparato. Es una clasificacin de los dispositivos en cuanto a sus prestaciones. USB Vendor: El fabricante del perifrico puede poner aqu cualquier informacin deseada. (PID/VID)=(Product ID/Vendor ID) El software del host es capaz de determinar el tipo de dispositivo conectado haciendo uso de esta informacin y de un direccionamiento individual. Todos los dispositivos USB son accedidos por una direccin USB que es asignada dinmicamente cuando se conecta, asignndole tambin un nmero. Cada aparato soporta adems uno o ms canales a travs de los cuales el host puede comunicarse con el dispositivo. Una vez que ha sido reconocido e identificado el dispositivo, el software del host puede hacer que los drivers del dispositivo apropiados obtengan el control del nuevo dispositivo conectado. Cuando desconectamos el dispositivo, la direccin puede ser reutilizada para el prximo dispositivo conectado.

La topologa del bus USB se puede dividir en tres partes:

La capa fsica: Como estn conectados los elementos fsicamente.(host, host controller, hubs, dispositivos) La capa lgica: Los roles y las responsabilidades de los elementos USB. Fsicamente el USB tiene slo un cable simple de bus que es compartido por todos los dispositivos del bus. Sin embargo, desde el punto de vista lgico cada dispositivo tiene su propia conexin punto a punto al host.

Si lo miramos desde el punto de vista lgico, los hubs son tambin dispositivos pero no se muestran en la figura para la simplificacin del esquema. Aunque la mayora de las actividades de los hosts o de los dispositivos lgicos usan esta perspectiva lgica, el host mantiene el conocimiento de la topologa fsica para dar soporte al proceso de desconexin de los hubs. Cuando se quita un hub, todos los dispositivos conectados a l son quitados tambin de la vista lgica de la topologa.

La relacin software del cliente-funcin: Como se ven mutuamente el software del cliente y los interfaces de las funciones relacionadas.

El software cliente se ejecuta en el host y corresponde a un dispositivo USB. Se suministra con el sistema operativo o con el dispositivo USB. El software del sistema USB, es el que soporta USB en un determinado sistema operativo. Se suministra con el sistema operativo independientemente de los dispositivos USB o del software cliente. El controlador del host USB est constituido por el hardware y el software que permite a los dispositivos USB ser conectados al host. Como se muestra en la figura, la conexin entre un host y un dispositivo requiere de la interaccin entre las capas. La capa de interfaz del bus USB proporciona la conexin fsica entre el host y el dispositivo. La capa de dispositivo USB es la que permite que el software del sistema USB realice operaciones genricas USB con el dispositivo. La capa de funcin proporciona capacidades adicionales al host va una adecuada capa de software cliente, proporciona la interfaz entre el usuario y el dispositivo. Las capas de funcin y dispositivos USB tienen cada una de ellas una visin de la comunicacin lgica dentro de su nivel, aunque la comunicacin entre ellas se hace realmente por la capa de interfaz de bus USB. A nivel de la USB Bus Interface, tenemos fuertes cambios de un dispositivo al otro ya que se ocupa de la interaccin con el Host Controller remoto, a nivel de sealizacin y transmisin fsica. En el USB Logical Device, la interfaz con el Host es bsicamente la misma independientemente del dispositivo. Se trabaja a nivel lgico. Se dispone de un juego de funciones de interaccin bsicas, que son comunes a los diferentes dispositivos USB a conectar al bus. Analizando el contenido de dichas funciones se pueden recin advertir las posibles diferencias en el tratamiento a los diferentes dispositivos La funcin es la capa que interacciona a nivel logico con el software de cliente. Flujo de informacin Se dispone de un flujo de comunicacin dedicado entre cada aplicacin y la correspondiente Funcin en el dispositivo. As,una Funcin de un dispositivo puede tener diferentes flujos de comunicaciones con diferentes aplicaciones que la requieran .En el dispositivo USB, el flujo de comunicacin termina en un Endpoint. Un dispositivo USB desde un punto de vista lgico hay que entenderlo como una serie de endpoints, a su vez los endpoints se agrupan en conjuntos que dan lugar a interfaces, las cuales permiten controlar la funcin del dispositivo. Como ya se ha visto la comunicacin entre el host y un dispositivo fsico USB se puede dividir en tres niveles o capas. En el nivel mas bajo el controlador de host USB se comunica con la interfaz del bus utilizando el cable USB, mientras que en un nivel superior el software USB del sistema se comunica con el dispositivo lgico utilizando la tubera de control por defecto ("Default Control Pipe"). En lo que al nivel de funcin se refiere, el software cliente establece la comunicacin con las interfaces de la funcin a travs de tuberas asociadas a endpoints.

La comunicacin entre los extremos se realiza entre un buffer del lado Host y un Endpoint del lado Dispositivo USB. El Canal es un pipe.

Endpoints y direcciones de dispositivo Es la porcin identificable de un dispositivo USB que representa el extremo en un flujo de comunicacin entre el Host y dicho dispositivo. Tiene un Nmero definido durante el diseo del dispositivo que lo identifica unvocamente. Transfiere informacin en una sola direccin. Cada dispositivo USB tiene una cantidad de Endpoints independientes entre s, y una direccin unvoca que lo identifica en el sistema, que obtiene desde el Host en el momento de su conexin al bus. As es que, definidos la direccin del dispositivo USB, el Nmero de Endpoint, y la Direccin del Flujo de Datos, se determina el Endpoint del dispositivo con el que se quiere establecer comunicacin. Cada dispositivo USB est compuesto por una coleccin de endpoints independientes, y una direccin nica asignada por el sistema en tiempo de conexin de forma dinmica. A su vez cada endpoint dispone de un identificador nico dentro del dispositivo al que pertenece, a este identificador se le conoce como nmero de endpoint y viene asignado de fbrica. Cada endpoint tiene una determinada orientacin de flujo de datos. La combinacin de direccin, nmero de endpoint y orientacin, permite referenciar cada endpoint de forma inequvoca. Cada endpoint es por si solo una conexin simple que soporta un flujo de datos en una nica direccin, bien de entrada o bien de salida. Cada endpoint se caracteriza por: Frecuencia de acceso al bus requerida Ancho de banda requerido Nmero de endpoint Tratamiento de errores requerido Mximo tamao de paquete que el endpoint puede enviar o recibir Tipo de transferencia que soporta La direccin en la que se transmiten los datos Existen dos endpoints especiales que todos los dispositivos deben tener, los endpoints con nmero 0 de entrada y de salida, que deben de implementar un

mtodo de control por defecto al que se le asocia la tubera de control por defecto. Estos endpoints estn siempre accesibles mientras que el resto no lo estarn hasta que no hayan sido configurados por el host.

PIPES Un PIPE USB es una asociacin entre uno o dos endpoints en un dispositivo, y el software en el host. Son el canal de comunicacin virtual mediante el cual se pueden transfrerirLas tuberas permiten mover datos entre el host, a travs de un buffer, y un endpoint en un dispositivo. Hay dos tipos de PIPES:

Stream: Los datos se mueven a travs de la tubera sin una estructura definida, y en modo first in first out (FIFO). Mensaje: Los datos se mueven a travs de los PIPES utilizando una estructura USB definida. Se envia un requerimiento al dispositivo USB desde el host, el que es seguido por una transferencia de datos en la direccin adecuada. Finalmente se pasa a una fase de estado. Este tipo de pipes permite comunicaciones bidireccionales.

Adems los pipes se caracterizan por:

Demanda de acceso al bus y uso del ancho de banda Un tipo de transferencia Las caractersticas asociadas a los endpoints

Como ya se ha comentado, la tubera que esta formada por dos endpoints con nmero cero se denomina tubera de control por defecto. Esta tubera est siempre disponible una vez se ha conectado el dispositivo y ha recibido un reseteo del bus. El resto de tuberas aparecen despus que se configure el dispositivo. La tubera de control por defecto es utilizada por el software USB del sistema para obtener la identificacin y requisitos de configuracin del dispositivo, y para configurar al dispositivo. El software cliente normalmente realiza peticiones para transmitir datos a una tubera va IRPs y entonces, o bien espera, o bien es notificado de que se ha completado la peticin. El software cliente puede causar que una tubera devuelva todas las IRPs pendientes. El cliente es notificado de que una IRP se ha completado cuando todas las transacciones del bus que tiene asociadas se han completado correctamente, o bien porque se han producido errores. Una IRP puede necesitar de varias tandas para mover los datos del cliente al bus. La cantidad de datos en cada tanda ser el tamao mximo de un paquete excepto el ltimo paquete de datos que contendr los datos que faltan. De modo que un paquete recibido por el cliente que no consiga llenar el buffer de datos de la IRP puede interpretarse de diferentes modos en funcin de las expectativas del cliente, si esperaba recibir una cantidad variable de datos considerar que se trata del ltimo paquete de datos, sirviendo pues como delimitador de final de datos, mientras que si esperaba una cantidad especfica de datos lo tomar como un error.

Streams: No necesita que los datos se transmitan con una cierta estructura. Las tuberas stream son siempre unidireccionales y los datos se transmiten de forma secuencial: "first in, first out". Estn pensadas para interactuar con un nico cliente, por lo que no se mantiene ninguna poltica de sincronizacin entre mltiples clientes en caso de que as sea. Un stream siempre se asocia a un nico endpoint en una determinada orientacin. Mensajes: A diferencia de lo que ocurre con los streams, en los mensajes la interaccin de la tubera con el endpoint consta de tres fases. Primero se realiza una peticin desde el host al dispositivo, despus se transmiten los datos en la direccin apropiada, finalmente un tiempo despus se pasa a la fase estado. Para poder llevar a acabo este paradigma es necesario que los datos se transmitan siguiendo una determinada estructura. Las tuberas de mensajes permiten la comunicacin en ambos sentidos, de hecho la tubera de control por defecto es una tubera de mensajes. El software USB del sistema se encarga de que mltiples peticiones no se enven a la tuberia de mensajes concurrentemente. Un dispositivo ha de dar nicamente servicio a una peticin de mensaje en cada instante por cada tubera de mensajes. Una tubera de mensajes se asocia a un par de endpoints de orientaciones opuestas con el mismo nmero de endpoint. 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.

Organizacin de las Transferencias

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 trfico en frames de 1 mseg. Luego arma cada frame con las transacciones correspondientes a las diferentes transferencias que se le solicitan desde las aplicaciones que se estn ejecutando en el Host.

USB establece una unidad de tiempo base equivalente a 1 milisegundo denominada frame y aplicable a buses de velocidad media o baja, en alta velocidad se trabaja con microframes, que equivalen a 125 microsegundos. Los (micro)frames no son mas que un mecanismo del bus USB para controlar el acceso a este, en funcin del tipo de transferencia que se realice. En un (micro)frame se pueden realizar diversas transacciones de datos. USB divide el tiempo en espacios de 1 ms denominados Tramas, durantes las cuales se llevan a cabo las comunicaciones a travs de Transacciones, las cuales se componen a su vez de Paquetes. Las Transacciones se componen de 3 fases: Token, Dato y Validacin (Handshake):

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 mxima frecuencia de transicin entre estados de las lneas diferenciales que componen el Bus. Aparece como un tren de transiciones JKJKJKJK en su codificacin 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 continuacin viene el campo Token. Los paquetes TokenData y Handshake se representarn en formato no codificado. Sin embargo, no debe perderse de vista que se trata de paquetes que se transmiten por el bus con codificacin NRZI, y Bit Stuffing. En la transmisin se envan y reciben paquetes de datos, cada paquete de datos viene precedido por un campo sync y acaba con el delimitador EOP, todo esto se enva codificado adems de los bits de relleno insertados. En este punto cuando se habla de datos se refiere a los paquetes sin el campo Sync ni el delimitador EOP, y sin codificacin ni bits de relleno.

Campo identificador de paquete (PID)

Es el primer campo que aparece en todo paquete. El PID indica el tipo de paquete, y por tanto el formato del paquete y el tipo de deteccin de error aplicado a este. Se utilizan cuatro bits para la codificacin del PID, sin embargo el campo PID son ocho bits, que son los cuatro del PID seguidos del complemento a 1 de esos cuatro bits. Estos ltimos cuatro bits sirven de confirmacin del PID. Si se recibe un paquete en el que los cuatro ltimos bits no son el complemento a 1 del PID, o el PID es desconocido, se considera que el paquete est corrupto y es ignorado por el receptor.

Campos de informacin adicional

Campo direccin Este campo indica la funcin, a travs de la direccin, que enva o es receptora del paquete de datos. Se utilizan siete bits, de lo cual se deduce que hay un mximo de 128 direcciones.

Campo Endpoint Se compone de cuatro bits e indica el nmero de "enpoint" al que se quiere acceder dentro de una funcin, como es lgico este campo siempre sigue al campo direccin.

Campo nmero de frame Es un campo de 11 bits que es incrementado por el host cada (micro)frame en una unidad. El mximo valor que puede alcanzar es el 7FFH, si se vuelve a incrementar pasa a cero. Campo de datos Los campos de datos pueden variar de 0 a 1024 bytes. En el dibujo se muestra el formato para mltiples bytes.

Campo de chequeo de redundancia ciclica (CRC)

El CRC se usa para proteger todos los campos no PID de los paquetes de tipo token y de datos. El CRC siempre es el ltimo campo y se genera a partir del resto de campos del paquete, a excepcin del campo PID. El receptor al recibir el paquete comprueba si se ha generado de acuerdo a los campos del paquete, si no es as, se considera que alguno o mas de un campo estn corruptos, en ese caso se ignora el paquete. El CRC utilizado detecta todos lo errores de un bit o de dos bits. El campo de CRC es de cinco bits para los paquetes de tipo IN, SETUP, OUT, PING y SPLIT. El polinomio generador es el siguiente: En el caso de los paquetes de datos se utiliza un campo CRC de 16 bits, el polinomio generador es el siguiente:

Formato de los paquetes

Paquetes de tipo token Un token est compuesto por un PID que indica si es de tipo IN, OUT o SETUP. El paquete especial de tipo PING tambin tiene la misma estructura que token. Despus del campo PID viene seguido de un campo direccin y un campo endpoint, por ltimo hay un campo CRC de 5 bits.

En los paquetes OUT y SETUP esos campos identifican al endpoint que va a recibir el paquete datos que va a continuacin. En los paquetes IN indican el endpoint que debe transmitir un paquete de datos. En el caso de los paquetes PING hacen referencia al endpoint que debe responder con un paquete "handshake". Paquete inicio de frame (SOF) Estos paquetes son generados por el host cada un milisegundo en buses de velocidad media y cada 125 microsegundos para velocidad alta. Este paquete est compuesto por un campo nmero de frame y un campo de CRC de 5 bits.

Paquete de datos Este paquete est compuesto por cero o ms bytes de datos seguido de un campo de CRC de 16 bits. Existen cuatro tipos de paquetes de datos: DATA0, DATA1, DATA2 y MDATA. El nmero mximo de bytes de datos en velocidad baja es de ocho bytes, en media de 1023 bytes y en alta de 1024 bytes. El nmero de bytes de datos ha de ser entero.

Paquetes "Handshake" Los paquetes "handshake", en castellano apretn de manos, se utilizan para saber el estado de una transferencia de datos, indicar la correcta recepcin de datos, aceptar o rechazar comandos, control de flujo, y condiciones de parada. El nico campo que contiene un paquete de este tipo es el campo PID.

Existen cuatro paquetes de tipo "handshake" adems de uno especial: 1) ACK: Indica que el paquete de datos ha sido recibido y decodificado correctamente. ACK slo es devuelto por el host en las transferencias IN y por una funcin en las transferencias OUT, SETUP o PING. 2) NAK: Indica que una funcin no puede aceptar datos del host (OUT) o que no puede transmitir datos al host (IN). Tambin puede enviarlo una funcin durante algunas fases de transferencias IN, OUT o PING. Por ltimo se puede utilizar en el control de flujo indicando disponibilidad. EL host nunca puede enviar este paquete.

3) STALL: Puede ser devuelto por una funcin en transacciones que intervienen paquetes de tipo IN, OUT o PING. Indica que una funcin es incapaz de transmitir o enviar datos, o que una peticin a una tubera control no est soportada. El host no puede enviar bajo ninguna condicin paquetes STALL. 4) NYET: Slo disponible en alta velocidad es devuelto como respuesta bajo dos circunstancias. Como parte del protocolo PING, o como respuesta de un hub a una transaccin SPLIT indicando que la transaccin de velocidad media o baja an no ha terminado, o que el hub no est an habilitado para realizar la transaccin. 5) ERR: De nuevo slo disponible en alta velocidad y de nuevo formando parte del protocolo PING, permite a un hub de alta velocidad indicar que se ha producido un error en un bus de media o baja velocidad. TIPOS DE TRANSFERENCIA Cada tipo de transferencia determina caractersticas importantes del flujo de informacin involucrado. Entre otras contamos las siguientes: Formato de datos impuesto por el USB. Direccin del flujo de comunicaciones. Restricciones en el tamao del paquete de datos a transmitir. Restricciones en el acceso al bus. Restricciones en el tiempo de recuperacin de datos. Secuencias de datos requeridas. Manejo de errores. Transferencias de control Es el nico tipo de transferencia que utiliza tuberas de mensajes, soporta por lo tanto comunicaciones de tipo configuracin/comando/estado entre el software cliente y su funcin. Una transferencia de tipo control se compone de una transaccin de setup del host a la funcin, cero o mas transacciones de datos en la direccin indicada en la fase de setup, y por ltimo una transaccin de estado de la funcin al host. Por lo tanto este tipo de transferencia esta pensado para configurar, obtener informacin, y en general para manipular el estado de los dispositivos. El tamao mximo de datos que se transmiten por el bus viene determinado por el endpoint. En dispositivos de velocidad media los posibles tamaos mximos son de 8, 16, 32 o 64 bytes, en velocidad baja el tamao es de 8 bytes y en velocidad alta 64 bytes. Estas son comnmente, por irrupcin, no periodicas iniciadas por el host, que se utilizan en operciones de comando o status.r El uso tpico es para configuracin. Transferencias iscronas Hacen uso de tuberas stream. Garantiza un acceso al bus USB con una latencia limitada, asegura una transmisin constante de los datos a travs de la tubera siempre y cuando se suministren datos, adems en caso de que la entrega falle debido a errores no se intenta reenviar los datos. USB limita el mximo tamao de datos para los endpoints con tipo de transferencia iscrona a 1023 bytes para los endpoints de velocidad media y

1024 bytes para velocidad alta. De hecho las transferencias iscronas solo se pueden usar en dispositivos de velocidad alta o media. Se trata de un tipo de comunicacin peridica y continua entre el host y un dispositivo USB, utilizadas tpicamente en aplicaciones en donde el tiempo de recuperacin de datos es un factor relevante. No quiere decir que sea crtico el tiempo de respuesta en cuanto a la velocidad de recuperacin de los datos sino ms bien, en cuanto a la periodicidad de acceso a stos. Se utiliza para transmisin de audio.

Tranferencias de interrupcin Utiliza tuberas stream. Este tipo de transferencia est diseado para servicios que envan o reciben datos de forma infrecuente. Esta trasferencia garantiza el mximo servicio para la tubera durante el periodo en el que enva. En caso de error al enviar los datos se reenvan en el prximo periodo de envo de datos. El tamao de paquete de datos mximo es de 1024 bytes para alta velocidad, 64 bytes para velocidad media y 8 bytes para baja velocidad. En ningn caso se precisa que los paquetes sean de tamao mximo, es decir, no es necesario rellenar los paquetes que no alcancen el mximo. Cuando en una transferencia de interrupcin se necesite transmitir mas datos de los que permite el paquete mximo, todos los paquetes a excepcin del ltimo paquete deben de tener el tamao mximo. De modo que la transmisin de un paquete se ha llevado a cabo cuando se ha recibido la cantidad exacta esperada o bien, se ha recibido un paquete que no alcanza el tamao mximo. Tipicamente se usa con mouse, teclado, etc. Transferencias de volumen ("Bulk") Hace uso de tuberas stream. Esta diseado para dispositivos que necesitan transmitir grandes cantidades datos en un momento determinado sin importar mucho el ancho de banda disponible en ese momento. Esta transferencia garantiza el acceso al USB con el ancho de banda disponible, adems en caso de error se garantiza el reenvo de los datos. Por lo tanto este tipo de transferencia garantiza la entrega de los datos pero no un determinado ancho de banda o latencia (pueden ser demorados hasta que el ancho de banda requerido se encuentre disponible). El tamao mximo de paquete de datos para velocidad media es de 8, 16, 32 o 64 bytes, mientras que en velocidad alta es de 512 bytes. Los dispositivos de velocidad baja no disponen de endpoints con este tipo de transferencia. Se usa en impresoras, escner, etc. CONEXIN ELECTRICA Cada conexin 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.

Identificacin de la velocidad del dispositivo Para poder iniciar cualquier tipo de transaccin cuando se conecta el dispositivo al host, es necesario que este conozca la velocidad a la que trabaja. Con esa finalidad existe un mecanismo a nivel elctrico. La diferencia entre los dispositivos de velocidad media y los de velocidad baja, es que en velocidad media tiene una resistencia conectada al D+, en velocidad baja la misma resistencia se encuentra en D- y no en D+ como se puede observar en los dibujos.

De forma que despus del reset el estado de reposo de la lnea es diferente si se trata de baja o media velocidad. En el caso de dispositivos de alta velocidad lo que se hace es que en un principio se conecta como un dispositivos de velocidad media y mas tarde a travs de un protocolo se pasa a velocidad alta. Codificacin de datos El USB utiliza la codificacin NRZI para la transmisin de paquetes. En esta codificacin los "0" se representan con un cambio en el nivel, y por el contrario los "1" se representan con un no cambio en el nivel. De modo que las cadenas de cero producen transiciones consecutivas en la seal, mientras que cadenas de unos produce largos periodos sin cambios en la seal. A continuacin un ejemplo:

Relleno de bits Debido a que cadenas de unos pueden producir largos periodos en los que la seal no cambia dando lugar a problemas de sincronizacin, se introducen los bits de relleno. Cada 6 bits consecutivos a "1" se inserta un bit a "0" para forzar un cambio, de esta forma el receptor puede volverse a sincronizar. El relleno bits empieza con el patrn de seal Sync El "1" que finaliza el patrn de seal Sync es el primer uno en la posible primera secuencia de seis unos.

En las seales a velocidad media o baja, el relleno de bits se utiliza a lo largo de todo el paquete sin excepcin. De modo que un paquete con siete unos consecutivos ser considerado un error y por lo tanto ignorado. En el caso de la velocidad alta se aplica el relleno de bits a lo largo del paquete, con la excepcin de los bits intencionados de error usados en EOP a velocidad alta. Sync Teniendo en cuenta que K y J representan respectivamente nivel bajo y nivel alto, el patrn de seal Sync emitido, con los datos codificados, es de 3 pares KJ seguidos de 2 K para el caso de velocidad media y baja. Para velocidad alta es una secuencia de 15 pares KJ seguidos de 2 K. A continuacin el caso de velocidad media y baja:

El patrn de seal Sync siempre precede al envo de cualquier paquete, teniendo como objetivo que el emisor y el receptor se sincronicen y se preparen para emitir y recibir datos respectivamente. Si partimos de que el estado de reposo de la seal es J, podemos interpretar Sync como una secuencia impar de "0's" y un "1" que se inserta antes de los datos. EOP ("End Of Packet") A todo paquete le sigue EOP, cuya finalidad es indicar el final del paquete. En el caso de velocidad media y baja el EOP consiste en que, despus del ltimo bit de datos en el cual la seal estar o bien en estado J, o bien en estado K, se pasa al estado SE0 durante el periodo que se corresponde con el ocupado por dos bits, finalmente se transita al estado J que se mantiene durante 1 bit. Esta ltima transicin indica el final del paquete. En el caso de la velocidad alta se utilizan bits de relleno errneos, que no estn en el lugar correcto, para indicar el EOP. Concretamente, el EOP sin aplicar codificacin consisitira en aadir al final de los datos la secuencia.

Enumeracin Antes de comenzar a trabajar con un dispositivo el Host debe averiguar sus caractersticas (Tipos de transferencias, cantidad de endpoints, etc.). Una vez obtenida esta informacin le asigna al dispositivo un nmero de port lgico en el Bus. Este proceso se denomina Enumeracin.