DISEÑO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTO MASIVO USB

Tamaño: px
Comenzar la demostración a partir de la página:

Download "DISEÑO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTO MASIVO USB"

Transcripción

1 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA DISEÑO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTO MASIVO USB Alexander Illich Volantines Rivera Ingeniería Civil Electrónica Diciembre del 2006

2 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA DISEÑO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTO MASIVO USB Memoria presentada por Alexander Illich Volantines Rivera Como requisito parcial para la obtención del título de Ingeniero Civil Electrónico Profesor Guía: Sr. Leopoldo Silva Bijit Valparaíso Diciembre del 2006

3 título de la memoria DISEÑO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTO MASIVO USB AUTOR Alexander Illich Volantines Rivera TRABAJO DE MEMORIA, presentado en cumplimiento parcial de los requisitos para el Título de Ingeniero Civil Electrónico de la Universidad Técnica Federico Santa María. Sr. Leopoldo Silva B Sr. Wolfgang Freund G Valparaíso, Diciembre del 2006

4 Gracias a mis padres Arturo e Irma por educarme A mi hermana Violeta por su compañía y consejos A Don Leopoldo Silva por su apoyo A Daniela por su cariño A mi amiga ACB (Q.E.P.D)

5 Diseño de un driver para dispositivos de almacenamiento masivo USB Alexander Illich Volantines Rivera Requisito parcial para la obtención del Título de Ingeniero Civil Electrónico. Profesor Guía: Leopoldo Silva B. Diciembre 2006 Resumen Hoy en día el protocolo USB ha tenido un éxito inesperado. Los factores claves de la gran aceptación entre los usuarios de computadores son sin duda: los costos para el fabricante y para el usuario; la sencillez de la conexión y la velocidad de sus productos. Universal Serial Bus fue diseñado para ser una interfaz capaz de comunicar diferentes tipos de dispositivos. Cada nuevo PC o Macintosh que sale al mercado incluyen puertos USB que pueden conectar automáticamente a los dispositivos estándar tales como: teclados, mouses, scanners, impresoras, etc., o también dispositivos con hardware personalizado con cualquier tipo de propósito. En una etapa inicial de este trabajo, se realiza una visión general de los aspectos más importantes del protocolo USB. De esta manera lleva al lector a comprender y a relacionarse tanto con los términos más comunes en el ambiente USB, como en el protocolo propiamente tal. Un host controlador es el encargado de manejar, controlar y dirigir todas las comunicaciones con los dispositivos USB. En el segundo capítulo se describe el funcionamiento y las operaciones del host controlador SL811HS de la compañía Cypress Semiconductor Corporation. El tercer capítulo se desarrolla la implementación de las herramientas que entrega el protocolo USB. Las herramientas llamadas Peticiones (Request) sirven para realizar la configuración e interrogación de los dispositivos USB. En el cuarto capítulo se describe el funcionamiento de los dispositivos que pertenecen a la clase de interfaz humana, que abarca a los dispositivos como teclados y mouses. Por último, en el quinto capítulo, se explica el funcionamiento de los dispositivos de la clase de almacenamiento masivo, en donde se desarrolla un programa para la lectura y escritura de archivos para los Pendrives. Palabras Claves Universal Serial Bus (USB), Endpoint, Bulk-Only, Class, Bus Enumeration, Standard Request (peticiones), SCSI, HID, MSD, Pendrives.

6 Índice general 1. Protocolo USB Características Generales USB-IF Versiones USB USB USB OTG USB Wireless USB Vs. FireWire Nivel Físico Transmisión Identificación de velocidades Topología Controlador Hubs Funciones Transacciones Pipes y endpoint Paquetes y fases de las transacciones Token Packet Data Packet Handshake Packet Transferencias Interrupt Bulk Isochronous CONTROL Controlador SL811HS Aspectos generales Módulo de trabajo Modos host/slave Registro y memoria Registros generales de configuración

7 Registros en modo host Señales de control Funciones básicas Escritura en registros Lectura de registros Inicialización del SL811HS Detección low/full speed Visualización de los registros Visualización de los registros a través del display Visualización de los registros a través de la ventana Watch Peticiones, descriptores y configuración general Peticiones Tipos de peticiones Principales peticiones set adress set configuration get configuration Descriptores Descriptores Standard Device Descriptor Configuration Descriptor Interface Descriptor Endpoint Descriptor String Descriptor Construcción de las peticiones Configuración de un dispositivo cualquiera Programas para los descriptores USBview USBCommandVerifer Hardware Dispositivos de interfaz humana HID Tipos de dispositivos Pipes de la Clase HID Identificación Clases Subclases Protocolos Descriptores de clase HID Descriptor Report Descriptor Physical Descriptor Recibimientos de los datos en un dispositivo HID

8 4.7. Configuración de un Mouse Dispositivos de almacenamiento masivo Mass Store Device Reconocimiento de un dispositivo MSD Clase Subclase Protocolo Peticiones de clase Bulk-Only Mass Storage Reset Get Max LUN Protocolo de transporte Bulk-Only Transferencias Bloque CBW Bloque CSW Bloques de comandos SCSI Inquiry Read(10) Write(10) Organización De La Memoria Física FAT Master Boot Record - MBR Particiones Función para encontrar particiones Distribución de los archivos en memoria Archivos y directorios Desarrollo de una función base de búsqueda Búsqueda de archivos y directorios en la raíz Búsqueda de archivos y directorios en directorios Lectura de archivos Escritura en archivos Conclusiones 110 A. Detalles del protocolo USB 111 A.1. Paquetes que se encuentran en las transacciones A.1.1. SYNC A.1.2. PID A.1.3. Address A.1.4. ENDP A.1.5. CRC A.2. Estados en la línea de transmisión A.2.1. Diferencial0 y Diferencial A.2.2. Single-Ended Zero A.2.3. J y K

9 A.2.4. Bus Idle A.3. Special Packet para el protocolo USB A.4. Resumen de los paquetes en las transacciones A.5. Resumen de las transferencias USB B. Diagrama de conexiones 117 C. Registros del controlador SL811HS en modo Host 118 D. Construcción de las peticiones 125 D.1. Setup Packet D.2. Función Request() D.2.1. Ejemplo de la construcción de la petición Set Adress E. Construcción de los comandos SCSI 130 E.0.2. INQUIRY E.0.3. READ(10) E.0.4. WRITE(10) E.0.5. Función de lectura de sectores, Leer Sector() E.0.6. Función de escritura de sectores, Escribir Sector() E.0.7. Función INQUIRY F. Estructura de información FAT F.0.8. Master Boot Record F.0.9. Partition Boot Record F.1. Formatos DOS 8.3 y LFN (Long File Name) G. Glosario. 144

10 Índice de figuras 1.1. Logo USB Logo USB Logo USB On-The-Go Logo USB Wireless Modelo Hub and Spoke Cable de cuatro hilos USB Transmisión de los datos en el cable USB Reconocimiento de full-speed Topología del bus USB Modelo hub de 7 puertos Distribución de diferentes transacciones en un frame Pipes y endpoint Fases de una transacción Fases de una transacción Interrupt Fases de una transacción Bulk Fases de una transacción Isochronous Fases de una transacción de Control SL811HS pin layout Módulo de trabajo para el SL811HS Conectores Serie-A y Serie-B Distribución de la memoria y registros Señales de acceso para el SL811HS Formas de ondas cuando se escribe en un registro del SL811HS Visualización de los registros a través del display Visualización de los registros con la herramienta watch Descriptores Standard Estructura de los descriptores para la herramienta watch Device Descriptor al conectar un teclado USB Configuration Descriptor de un mouse Mensaje de Windows para un dispositivo USB Interface Descriptor para un mouse Endpoint Descriptor para una impresora Mensaje de Windows XP para el nombre del producto

11 3.9. Nombre del producto de un dispositivo usando el SL811HS Visualización de la pantalla después de usar Bus Enumeración USBview mostrando los dispositivos conectados USBview mostrando los descriptores USBcommandVerifer Conexión de un sniffer para la captura de datos Pipes de la clase HID Descriptores de la clase HID HID Descriptor Tabla de reportes Software HID Descriptor Tool Estructura interna de los pendrives Flujo de datos Command Block Wrapper Command Status Wrapper Resultado del comando Inquiry Organización de la memoria Master Boot Record del pendrive Packerbell 256MB Estructura de las particiones Ejemplo de la Partition Boot Record Valores obtenidos al ejecutar la función buscaparticion() Ejemplo de la distribución de un archivo en memoria Ejemplos de nombres y carpetas en la tabla de directorios Estructura de la función save() Relleno de sectores y cluster en la escritura de datos A.1. Resumen de la estructura de los paquetes del protocolo USB A.2. Resumen de las transferencias del protocolo USB B.1. SL811HS USB Host/Slave Controlador, Pin Layout

12 Índice de cuadros 1.1. Ejemplos de aplicaciones OTG Tipos de protocolos y sus usos Token Packet Data Packet Handshake Packet Resumen de las transferencias y sus usos Registros de configuración del SL811HS Registros y definiciones para modo host Peticiones Standard Estructura del Device Descriptor Configuration Descriptor Interface Descriptor Clases USB Endpoint Descriptor Campos del Setup Packet Resumen de la comunicación HID Códigos de Subclases Códigos de protocolos Estructura del HID Descriptor Descriptores especiales para la clase HID Valores para los botones del mouse Valores para el movimiento del mouse Código de subclase para Mass Store Device Código de protocolo para Mass Store Device Interface Descriptor para distintos pendrives Típicos comandos SCSI Cluster por tamaño Master Boot Record Códigos para el cluster A.1. Paquetes del protocolo USB A.2. Bits del paquete PID

13 A.3. Bits del paquete Adress A.4. Bits del paquete ENDP A.5. Estados J y K C.1. Registros en modo host C.2. Registro 0x C.3. Registro 0x03, resultados de la última transacción C.4. Registro 0x03, valores para el paquete PID C.5. Registro 0x C.6. Estados de operación de las líneas D+ y D C.7. Registro 0x C.8. Registro 0x0D C.9. Registro 0x0E, hardware revisión C.10.Registro 0x0F D.1. Campos del Setup Packet D.2. Peticiones Standard D.3. Tipos de descriptores E.1. Campo de envío del comando INQUIRY E.2. Campos de retorno del comando INQUIRY E.3. Formato del comando READ(10) E.4. Campo de envío del comando INQUIRY F.1. Master Boot Record F.2. Información de los 16 bytes para cada partición F.3. Tipos de particiones F.4. Campos del sector Partition Boot Record F.5. Formato de nombres cortos para DOS F.6. Formato de nombres cortos para LFN F.7. Formato de nombres largos para LFN

14 Capítulo 1 Protocolo USB Este capítulo describe el protocolo USB incluyendo sus ventajas y sus límites, la historia acerca de la interfaz y sus últimos avances. El conocimiento general del protocolo USB y sus principales características es una referencia en el cual debe estar involucrado cualquier diseñador y programador de un dispositivo USB Características Generales El protocolo USB (Universal Serial Bus) ha sido una verdadera revolución en el mundo de la computación, características como sencillez en la conexión y velocidad de transmisión han hecho masivo el uso de esta tecnología, dejando atrás antiguas formas de conectar periféricos por los puertos paralelos o el serial RS-232. USB tiene la gran ventaja que es un estándar abierto, lo cual permite ir mejorando el protocolo según las nuevas necesidades que vayan saliendo en el mercado, además ya ha sido adoptado por cientos de fabricantes de periféricos y ha recibido una gran aceptación entre los fabricantes de computadores personales. En un principio el estándar USB fue sólo una especificación de las empresas Compaq, Intel, Microsoft y NEC, pero con el paso del tiempo se incorporaron grandes empresas como Hewlett-Packard, Lucent y Philips y ahora ha sido formalmente adoptado por los sistemas operativos de Apple y Linux, que en conjunto con Microsoft Windows representan a casi el total del sector de la informática personal. USB fue diseñado expresamente para proporcionar las características más requeridas por los usuarios, las principales son: Una interfaz para muchos dispositivos: USB es lo suficientemente versátil para ser utilizable con una variedad de periféricos. En lugar de tener un tipo de conector diferente para cada dispositivo y tener un soporte para cada hardware, en USB una interfaz sirve para todos. 14

15 CAPÍTULO 1. PROTOCOLO USB Configuración automática para clases conocidas: Cuando un usuario conecta un dispositivo USB, el sistema operativo detecta el periférico y carga el software apropiado. Si una clase desconocida se conecta, los sistemas operativos como Windows advierten al usuario para insertar un disco con los drivers, pero aparte de eso, la instalación es automática. Fácil de manejar: La implementación del USB elimina el uso de IRQ s y canales de DMA. Así como la necesidad de abrir los gabinetes para instalar o quitar dispositivos. El usuario no tienen la necesidad de preocuparse sobre la correcta selección del puerto serial, la instalación de tarjetas de expansión o configurar los jumpers de la placa madre. Un PC típicamente tiene cuatro o más puertos USB los cuales son ampliables a través de hubs. Simple conexión: Los conectores del cable USB son como una llave, así que no es posible poder conectar incorrectamente el dispositivo. El largo puede llegar hasta los 5 metros. Con hubs, un dispositivo puede llegar hasta los 30 metros de distancia desde el host base. Los conectores USB son pequeños y compactos en contraste a los típicos RS-232 y conectores paralelos. En resumen USB usa únicamente un solo tipo de conector para cualquier tipo de dispositivo, más allá de la función que cumplan. Para asegurar la buena operación, la especificación USB incluye requisitos eléctricos que todos los cables y los conectores deben incorporar. Conexión en caliente: USB permite conectar y desconectar un dispositivo cuando se requiera, no importando si los sistemas están energizados. No requiere alimentación externa: La interfaz USB incluye suministro de energía a través de la línea de tierra y los +5V nominal entregado por el computador o el hub. Un dispositivo puede tomar hasta máximo 500 ma a través del bus. Por lo contrario, los dispositivos que usan interfaces en el cual requieran más corriente, pueden incluir un suministro de energía dentro del dispositivo o usar un suministro externo. Conectividad: Hasta 127 dispositivos diferentes pueden estar conectados simultáneamente y operando con el mismo computador. Bajos costos de diseño: Para casi la mayoría de las aplicaciones que son estándar y no tienen una configuración propia, los costos de diseño son comparativamente menores que otras tecnologías. 15

16 CAPÍTULO 1. PROTOCOLO USB 1.2. USB-IF Para los diseñadores de dispositivos USB se dispone de una gran cantidad de ayuda por: USB Implementers Forum S.A. (USB-IF) y su sitio Web USB-IF es una corporación sin fines de lucro fundada por las compañías que están desarrollando continuamente especificaciones y productos USB. La misión de USB-IF es dar soporte al avance y la utilización de la tecnología USB. Para ese fin, USB-IF ofrece información, herramientas y test de pruebas. La información incluye los documentos de especificación, artículos, FAQs y foros en la Web, donde los desarrolladores pueden discutir temas relacionados a USB. Las herramientas previstas por el USB-IF incluyen software y hardware para ayudar a desarrollar y probar productos. El soporte para experimentar incluye tests para verificar que las operaciones realizadas por los dispositivos USB sean las correctas. Cualquiera puede desarrollar drivers, programas y dispositivos USB sin pagar alguna tarifa de licencias, sin embargo cualquiera que distribuye un dispositivo con una interfaz USB debe obtener los derechos para usar un Vendor ID 1. Al momento de escribir la presente memoria, el cargo administrativo para obtener un Vendor ID es de US$1500. Para ser partícipe de USB-IF la cuota anual es de US$2500, con lo cual junto con el Vendor ID se puede participar en talleres y foros para el mejoramiento de la tecnología USB. Estas cuotas no son problemas para desarrolladores de productos con volúmenes altos de dispositivos, sino más bien puede ser un impedimento para los desarrolladores que planean realizar cantidades pequeñas de dispositivos y a bajos costos Versiones En la actualidad existen cuatro tipos de diferentes versiones USB. Éstos han aparecido principalmente por la necesidad de ir mejorando la velocidad de la transmisión serial y además por las nuevas formas a la hora de interconectar dispositivos USB 1.1 Esta especificación fue realizada por las empresas Compaq, Intel, Microsoft y NEC, en septiembre de 1998 y marcaba la primera versión final de una serie de antiguas versiones. La versión USB 1.1 define y caracteriza casi por completo lo que es hoy en día el protocolo USB, pues en ella se especifica un canal serial para soportar a una gran gama de periféricos de media y baja velocidad, con soporte integral para transferencias en tiempo real como voz, audio y vídeo. 1 El Vendor ID es asignado por USB-IF y se incorpora en cada dispositivo para su identificación. 16

17 CAPÍTULO 1. PROTOCOLO USB Las principales características de USB 1.1 son: Dos velocidades de transmisión: 12 Mbps llamada full-speed, con propósito de diseño para dispositivos que requieren grandes velocidades de transmisión. Y low-speed de 1,5 Mbps para dispositivos más lentos como son los mouse, teclados y joysticks. Manejar hasta 127 dispositivos simultáneamente que se pueden conectar y desconectar en caliente, sin tener que reiniciar el sistema. Una configuración automática de dispositivos que elimina la necesidad de realizar configuraciones. Un acceso al bus gestionado directamente por el controlador USB para permitir transferencias isócronas y eliminar los tiempos de arbitración. La coexistencia de dispositivos isócronos y asíncronos. Los dispositivos isócronos se atienden en función del ancho de banda y tiempo requerido, y los asíncronos se atienden durante el tiempo restante no consumido por los dispositivos isócronos. Una distribución de alimentación desde el controlador USB, que permite la conexión de los dispositivos sin alimentación externa. Una arquitectura fácilmente escalable para permitir la existencia de varios controladores USB en un sistema. Para el reconocimiento del protocolo USB 1.1 se dispone del logo mostrado en la figura 1.1. Figura 1.1: Logo USB USB 2.0 USB 1.1 ganó gran popularidad entre los usuarios y diseñadores de productos. En abril del año 2000, en conjunto con nuevas empresas para el mejoramiento del protocolo como: Hewlett-Packard, Lucent y Philips se publica finalmente USB 2.0, cuyo logo de reconocimiento se muestra en la figura 1.2. Esto demostraba el gran interés por desarrollar e integrar nuevos dispositivos más rápidos y que demandaran gran 17

18 CAPÍTULO 1. PROTOCOLO USB cantidad de datos de transferencias. La nueva velocidad que se incorpora se llama high-speed y es de 480 Mbps, lo que es cuarenta veces más rápido que la antigua fullspeed. La incorporación de high-speed hizo que USB sea mucho más atractivo para el diseño de dispositivos como: impresoras, scanners, cámaras fotográficas y pendrives. Figura 1.2: Logo USB 2.0. Las características del protocolo USB 1.1 se suman a USB 2.0 y se agregan nuevos tipos de paquetes. Los dispositivos high-speed también soportan una funcionalidad en modo full-speed, de forma que cuando se conectan a un puerto que está trabajando en modo full-speed pueden al menos: Detectar y procesar el reset. Aceptar, procesar y responder adecuadamente a las funciones estándar de asignación de dirección y de configuración, así como la lectura de la información descriptiva del dispositivo y de sus posibles configuraciones (peticiones y descriptores). Los dispositivos high-speed pueden o no soportar su total funcionalidad cuando trabajan en modo full-speed, pero la mayoría lo hacen para que sean compatibles. USB pone a disposición herramientas como USB command Verifier Tool 1 para comprobar si cumplen con los requisitos para su funcionamiento en ambas velocidades USB OTG Los desarrolladores de periféricos comenzaron a solicitar una nueva forma para poder conectar los dispositivos USB. Por ejemplo, un usuario podría querer usar una impresora directamente con una cámara fotográfica. El protocolo On-The-Go, cuyo logo se muestra en la figura 1.3, fue el que pudo hacer posible la conexión pedida por los fabricantes. Se publicó en diciembre del 2001 y corresponde a una variación de USB 2.0. Con este nuevo protocolo el host tiene una capacidad limitada, pero posibilita la comunicación entre periféricos y elimina la indispensabilidad de tener un PC para establecer la comunicación. Igualmente USB OTG permite a un dispositivo actuar como servidor o como cliente dependiendo como originalmente se conectó el cableado. Incluso después de que las unidades se están comunicando, los 1 El programa se encuentra en o en el CD adjunto a la memoria Programas/USB command Verifier Tool/USBCV121.msi y requiere de un ROOT USB

19 CAPÍTULO 1. PROTOCOLO USB dos dispositivos pueden cambiar el rol bajo el control de un programa. Esta facilidad está específicamente diseñada para dispositivos como PDA, cámaras e impresoras. Las principales características son: Habilidad Dual-Rol, con la cual se puede intercambiar papeles entre host y slave bajo el protocolo de negociación de host (HPN). Nuevos conectores más pequeños (mini-a y mini-b) con un cableado diferente. Ahorro de consumo de energía para facilitar durabilidad de la batería en los dispositivos. Figura 1.3: Logo USB On-The-Go 2.0. En el cuadro 1.1 muestra algunos ejemplos de conexión directa entre periféricos con las respectivas aplicaciones. Host Periférico Aplicación PDA -PDA -Intercambiar información -Impresora -Imprimir documentos -Teléfonos -Subir/bajar archivos -Scanner -Digitalizar fotos -Pendrive -Subir/bajar archivos -GPS -Obtener mapas, direcciones -Cámaras -Subir/bajar fotos Impresora -Cámaras -Imprimir archivos -Teléfonos -Pendrive - PDA Cuadro 1.1: Ejemplos de aplicaciones OTG USB Wireless USB inalámbrico (WUSB) es la tecnología desarrollada más reciente por USB-IF. La versión 1.0 de WUSB fue publicada en mayo del 2005 y entrega más facilidades y movilidad a los dispositivos que se conectan a los PC. Esta especificación mantiene el mismo uso y arquitectura que el USB con cables, con una conexión high-speed 19

20 CAPÍTULO 1. PROTOCOLO USB desde el host al dispositivo. Aunque el despliegue masivo de dispositivos compatibles con esta tecnología no se producirá hasta La utilización de WUSB no ha sido aprobado aún por una buena cantidad de organismos regulatorios europeos y asiáticos, debido a potenciales conflictos con otras tecnologías inalámbricas. Esto podría oscurecer las perspectivas de Wireless USB de alcanzar economías de escala que puedan reducir costos y competir de igual con Bluetooth, que ha alcanzado un importante crecimiento en el campo de la tecnología inalámbrica durante los últimos años. Figura 1.4: Logo USB Wireless. Figura 1.5: Modelo Hub and Spoke. Wireless USB conecta a los dispositivos USB con un modelo llamado Hub and Spoke. El host WUSB es el hub que está representado en la parte central de la figura 1.5 y cada dispositivo que se conecta se llama spoke. Un spoke es una conexión pointto-point entre el host y el dispositivo. El host puede soportar 127 dispositivos y como no tiene puertos físicos no hay necesidad de definir nuevos hubs para la expansión de los puertos. Las principales características son: Transferencia de 480 Mbps a 3 metros y 110 Mbps a 10 metros de distancia. 20

21 CAPÍTULO 1. PROTOCOLO USB Tecnología CMOS, con ahorro de energía (Sleep/Listen/Wake) y bajos costos de diseños. Conexión máxima de 127 dispositivos WUSB. Seguridad y asociación de dispositivos con mecanismo de cifrado AES-128/CCM a nivel de las aplicaciones. Usa el espectro UWB (Ultra-Wideband), Ghz. Dispositivos WUSB con protocolo OTG para funciones Dual-Rol. Arquitectura y protocolo escalable a 1 Gbps. Interface Formato Dispos. Máx. Veloc. Máx. Uso típico USB asynchronous serial M, 12M, 480M. teclados, mouse, impresoras, scanner, pendrives, cámaras fotográficas, etc. Ethernet serial G general network IEEE-1394a (FireWire) IEEE-1394b (FireWire) IEEE-488 (GPIB) IrDA I 2 C Microwire serial M video y audio serial G video y audio paralelo 15 8M instrumentación infrarrojo serial asynchronous serial asynchronous serial 2 16M manos libres, impresoras M microcontroladores 8 2M microcontroladores Puerto Paralelo paralelo 2 8M impresoras, scanner RS-232 RS-485 SPI asynchronous serial asynchronous serial asynchronous serial 2 20k modem, mouse, instrumentación 32 10M adquisición de datos y sistemas de control 8 2.1M microcontroladores Cuadro 1.2: Tipos de protocolos y sus usos USB Vs. FireWire Otra popular elección de interfaz para dispositivos periféricos es el protocolo IEEE-1394, también conocido como FireWire. La implementación de la interfaz 1394 fue desarrollado por Apple Computer. Ambas tecnologías persiguen un mismo método de conectar múltiples periféricos a un computador con la capacidad de permitir 21

22 CAPÍTULO 1. PROTOCOLO USB que los periféricos sean añadidos o desconectados sin la necesidad de reiniciar. Pero la diferencia radica en que generalmente IEEE-1394 puede ser más rápido y flexible que USB, pero los costos de implementación suelen ser mayores. Con USB un solo host es el que controla todas las comunicaciones de los dispositivos, el host manipula la mayoría de la complejidad, así es que la electrónica de los dispositivos puede ser relativamente simple y menos costosa. Como se muestra el cuadro comparativo 1.2, la velocidad y capacidad de transferencia marca la principal distinción entre estas dos tecnologías. Hoy USB high-speed lo hace competitivo con el IEEE-1394A con velocidad de 480 Megabits/sec, pero IEEE-1394B es superior con 3.2 Gigabits/sec Nivel Físico La interfaz USB se conecta con el equipo del usuario a través de un cable de cuatro hilos. Dos son dedicados a la alimentación y los dos restantes a la señal de datos (D+ y D-), estos últimos están como par trenzado. Los conductores de alimentación (figura 1.6) VBus y GND entregan una tensión continua de 5V y 500mA máximo. En función de las necesidades de alimentación eléctrica de los dispositivos, éstos pueden tomar la alimentación de estas líneas, o bien tener una fuente de alimentación alternativa. Todos los aspectos técnicos relativos al cable y conector USB se encuentran en la especificación USB entregada por USB-IF. Figura 1.6: Cable de cuatro hilos USB Transmisión El bus USB es síncrono y los paquetes de datos están codificados usando NRZI 1 agregando la inserción de bits llamado Bit Stuffing. La inserción de bits es requerido por el dispositivo receptor porque éste funciona sincrónicamente con las transiciones. Si los datos son todos 0, entonces existen bastantes transiciones, pero si los datos contienen demasiados 1, entonces la falta de transiciones podría causar que el aparato receptor pueda salir del sincronismo (SYNC). Si los datos tienen seis 1 consecutivos el transmisor inserta un 0 (representado por una transición). Esto 1 Non Return to Zero Inverted, la línea cambia de nivel si se transmite un 0 y no cambia si transmite un 1. 22

23 CAPÍTULO 1. PROTOCOLO USB asegura al menos una transición para cada siete bits transmitidos. El aparato receptor detecta y descarta cualquier bit que tenga seis 1s consecutivos. La inserción de bits puede aumentar el número de bits transmitidos que en teoría puede llegar hasta un 17 %, pero en la práctica el promedio es mucho menos. El overhead por bit stuffing para datos aleatorios es aproximadamente un 0.8 %, lo cual significa 1 bit de relleno por cada 125 bits de datos. Después, los datos codificados son conducidos en el cable USB por el conductor diferencial. El dispositivo receptor amplifica los datos diferenciales entrantes (ver figura 1.7) y entrega los datos para ser decodificados. La codificación y la señalización diferencial se usan para ayudar a asegurar la integridad de los datos y eliminar problemas de ruido. Figura 1.7: Transmisión de los datos en el cable USB Identificación de velocidades Para que el host detecte la velocidad de un dispositivo (low-speed y full-speed) se coloca una resistencia Pull-Up de 15KΩ al final del cable para que la detección se realice en forma eléctrica a través de un voltaje diferencial (2.7V a 3.3V para ambas velocidades). Para los dispositivos full-speed la resistencia Pull-up es conectada en la línea D+ (figura 1.8) y para los dispositivos low-speed la resistencia Pull-up es conectada en la línea D-. La ausencia de un dispositivo se detecta con las señales D+ y D- estando en 0. Figura 1.8: Reconocimiento de full-speed. En un principio USB fue pensado con un diseño de dos tipos de velocidades, es por eso que los dispositivos high-speed se tienen que identificar eléctricamente como dispositivos full-speed. Luego se ejecutan unas secuencias de señales eléctricas que 23

24 CAPÍTULO 1. PROTOCOLO USB determinan finalmente si el dispositivo corresponde a full-speed o high-speed Topología La conexión en el bus USB se denomina Estrella en Niveles de 7 capas. En el centro de cada estrella hay un hub y en cada punta puede ser un dispositivo o otro hub (figura 1.9). Debido a los retardos producidos por la propagación de la señal en el largo del cable, se fija un máximo de 7 niveles para el control de todo el tráfico de información en el bus. El número de puertos de cada hub puede variar de dos, cuatro o siete, dependiendo del hub conectado. Un dispositivo compuesto ocupa dos filas, por consiguiente, no puede ser colocado al final del nivel 7, sólo los dispositivos simples pueden ser colocados en ese nivel. Considerando el hub raíz y el último nivel, la máxima cantidad de hub conectados en cascada es de 5. Figura 1.9: Topología del bus USB. En la figura 1.9 se puede observar que en la topología USB hay tres agentes participativos: el controlador host, los hubs y las funciones Controlador Es el responsable de las comunicaciones entre los periféricos USB y el microcontrolador. Para cada periférico añadido, el controlador determina su clase y le asigna una 24

25 CAPÍTULO 1. PROTOCOLO USB dirección lógica para utilizarla en las comunicaciones. El host controlador puede ser implementado usando una combinación entre hardware, firmware o software, donde las principales funciones que lleva a cabo son: Detectar si un dispositivo se ha conectado o ha sido removido de alguno de los puertos. Manejar el flujo de control y flujo de datos entre el microcontrolador y los dispositivos. Proveer la alimentación a los dispositivos USB conectados. Comunicar al microcontrolador o CPU los errores durante la comunicación Hubs El hub es un dispositivo más de la gran lista de aparatos USB que se pueden conectar. Estos dispositivos simplifican de gran manera la sencillez de la interconexión, dando la posibilidad de extender la cantidad de dispositivos que se puedan conectar (127 dispositivos). El hub USB está hecho para detectar si un periférico ha sido conectado o si un dispositivo ha sido removido de sus puertos a través de un estado interno dentro del hub: el controlador debe estar constantemente revisando 1 los estados de los hub para procesar el equipo nuevo o para remover los programas de administración (drivers) del dispositivo retirado. Otra de las funciones importantes de los hubs es aislar los puertos de baja velocidad, de las transferencias de alta velocidad, proceso sin el cual, todos los dispositivos de baja velocidad conectados al bus entrarían en colapso. La protección de los dispositivos low-speed de los full-speed ha sido siempre un serio problema dentro de las redes mixtas, disminuyendo el rendimiento como es el caso de los hub 1.1. Figura 1.10: Modelo hub de 7 puertos. Un hub 2.0 maneja lo mismo que el hub 1.1 pero éste da soporte a velocidades high-speed (480Mbs), con la gran diferencia que realiza todas las transacciones de datos a la velocidad high-speed, convirtiendo la velocidad que necesita el dispositivo en la última parte de la conexión. De esta forma la entrega de datos es mucho más 1 Las revisiones de los estados se realizan a través de las peticiones. Para mayor detalle ver Capítulo 3. 25

26 CAPÍTULO 1. PROTOCOLO USB eficiente comparado con los hubs 1.1 (full-speed). Internamente el hub 1.1 está compuesto por el controlador hub y el repetidor hub, sin embargo el hub 2.0 posee un nuevo elemento llamado Traductor de Transacciones (TT) Funciones Una función es un dispositivo USB no compuesto, que está diseñado para transmitir y recibir datos. Se puede decir que es un periférico, sin embargo un dispositivo común y corriente físicamente puede incorporar múltiples funciones e incluso llevar dentro un hub, en cuyo caso se conoce como un dispositivo compuesto, donde cada función no puede ser desconectada o conectada de modo individual Transacciones El host es el que maneja todo el flujo de datos en el BUS, para ello USB 1.1 divide el tiempo en segmentos equivalente a 1 milisegundo denominado Frame o Trama y aplicable a los buses low-speed y full-speed. En high-speed que pertenece al protocolo USB 2.0, se trabaja con frame y microframes donde cada microframe equivalen a 125 microsegundos. Los frames no es más que un mecanismo del bus USB para controlar el acceso a éste, en función del tipo de transferencia que se realice reservando ciertos porcentajes del tiempo de la trama. En cada transacción incluye un número determinado de paquetes y cada frame incluye un número determinado de transacciones. La figura 1.11 muestra como las diferentes transacciones que producen los dispositivos se van agrupando en el frame. En cada frame puede suceder que no se haga uso completo del tiempo, ya que a veces no existen más transacciones en el bus o simplemente porque el tiempo sobrante no es suficiente para asegurar que la transacción se realice. Las transacciones se agrupan formando transferencias. Cada transferencia obedece a un tipo predeterminado como lo son: Interrupt, Control, Bulk e Isochronous. Una transferencia puede estar distribuida entre distintos frames o incluida completamente en una sola (dependiendo del tamaño de la información). Las transferencias que necesitan una tasa específica de velocidad, se garantizan reservando la cantidad de tiempo que necesitan en cada frame. Si el ancho de banda no está disponible, entonces el host no establece la comunicación dando al driver la posibilidad de poder pedir una porción más pequeña del ancho de banda o esperar hasta que el ancho de banda demandado esté disponible. La máxima cantidad de información útil que se puede transferir en un paquete de datos depende de la velocidad del dispositivo y del tipo de Endpoint. 26

27 CAPÍTULO 1. PROTOCOLO USB Figura 1.11: Distribución de diferentes transacciones en un frame Pipes y endpoint El flujo de datos del bus USB desde un punto de vista virtual se realiza por caminos denominados pipes (figura 1.12). Figura 1.12: Pipes y endpoint. Cada pipe tiene asociado un endpoint que son los respectivos terminales de cada pipe. Cada endpoint tiene una dirección que puede ser IN, OUT o bi-direccional. El controlador puede acceder a cada endpoint para establecer la comunicación, pues cada dispositivo USB define un grupo de endpoint que forman la interfaz final. A su vez, cada endpoint define el tamaño máximo de transferencia. En USB 1.1 los valores 27

28 CAPÍTULO 1. PROTOCOLO USB son de 8, 16, 32 o 64 bytes. Para USB 2.0 se suma un nuevo tamaño de 512 bytes. En los dispositivos low-speed sólo es posible tener endpoint de 8 bytes Paquetes y fases de las transacciones El protocolo de comunicaciones del bus USB entre el host y el dispositivo físico se realiza a través de Tokens (testigos). De forma general toda función (dispositivo) en principio, está esperando a que el host le envíe un paquete. Si un paquete tiene la misma dirección (device adress) que el dispositivo, entonces éste cambia de estado para proceder aceptar la transacción. Figura 1.13: Fases de una transacción. Como se muestra en la figura 1.13 una transacción típicamente puede estar compuesta por una, dos o tres fases. Las tres posibles fases son Token, Data y Handshake, las cuales de existir lo harán de forma secuencial: una fase Token es siempre seguida de una fase Data y ésta a su vez será seguida de una fase Handshake. Las fases Data y Handshake son opcionales de acuerdo al tipo de transmisión que se solicite. A su vez, cada fase está compuesta por una serie de paquetes 1 como: SYNC, PID, ENDPOINT, DEVICE ADDRESS, DATA y CRC. 1 El detalle de los paquetes del protocolo se pueden encontrar en el Apéndice A. 28

29 CAPÍTULO 1. PROTOCOLO USB Token Packet Se compone de un paquete enviado por el controlador USB y siempre está presente en toda transacción. En ésta fase se envía: el tipo del paquete, la dirección del dispositivo y la dirección del endpoint. El paquete finaliza con un control de error CRC5. Los paquetes que componen un Token Packet (cuadro 1.3) son: PID ADDR ENDP CRC5 8 bits 7 bits 4 bits 5 bits Cuadro 1.3: Token Packet. PID: Identifica el tipo de paquete, los posibles tipos de paquetes soportables para el PID tipo Token son: IN, OUT, SETUP y SOF. Todos los PIDs van auto-protegidos con bits redundantes. ADDR: Dirección del dispositivo a comunicar, con un total de 127 direcciones posibles. ENDP: Número del endpoint para establecer la transferencia. Son soportables sólo 16 endpoints como máximo. CRC5: El último campo en todos los paquetes Tokens consta de 5 bits y corresponde al código de redundancia cíclica. Éste no abarca los campos SYNC y PID Data Packet Data Packet (cuadro 1.4) consiste en un paquete PID, luego cero o más bytes de los datos útiles asociado con la transferencia (DATA) y finaliza con un paquete de corrección de 16 bits. Hay dos tipos de Data Packet identificados por diferentes PIDs 1 : DATA0 y DATA1. Estos dos paquetes están definidos para usarlos en forma de toggle para la disminución de errores y confusiones por parte del host. En USB 1.1 un paquete de datos puede transmitir una carga máxima de 1023 bytes de datos (en transacciones isócronas) durante una sola transacción, mientras en los otros tipos de transferencia tienen cargas máximas de 64 bytes (Bulk). 1 El protocolo USB 2.0 agrega nuevos tipos de paquetes para la fase Data Packet: DATA2 y MDATA. 29

30 CAPÍTULO 1. PROTOCOLO USB 0 PID DATA CRC16 8 bits bytes 16 bits Handshake Packet Cuadro 1.4: Data Packet. Todas las transferencias USB (excepto isócronas) son implementadas para garantizar la entrega de datos. Para ello se incluye la fase Handshake que permite verificar si la transferencia ha sido exitosamente realizada. Si un error ocurre en la transacción, el Data Packet no es entregado y el host puede intentar entregarlo nuevamente. 0 7 PID Cuadro 1.5: Handshake Packet. Los posibles PID que soporta el paquete Handshake son: ACK Significa Acknowledged o reconocimiento y es transmitido cuando el host o el dispositivo ha recibido satisfactoriamente los datos sin errores. El dispositivo retorna un ACK en el Handshake para transacciones OUT o SETUP y el host retorna un ACK sólo para transacciones tipo IN. NAK Not Acknowledged o Reconocimiento Negativo: éste paquete es transmitido cada vez que el dispositivo no está listo para una operación, tanto de transmisión como de recepción de paquetes. Por definición el host siempre puede transmitir o recibir un paquete de datos, de lo contrario nunca habría transmitido el paquete Token (OUT o IN). Consecuentemente el paquete handshake NAK sólo puede ser transmitido hacia arriba (Upstream) por el dispositivo y sólo puede ser recibido por el host. Luego de que el controlador host transmita un paquete de datos asociado a un paquete Token de salida (OUT Token), el dispositivo transmite un paquete handshake NAK si no está listo para recibir los datos. Esto se da también en el caso de que el host transmita un paquete Token de entrada (IN Token) y que el dispositivo no esté listo para transmitir. Las transferencias del tipo isócronas no retornan NAK porque ese tipo de transferencias no usan Handshake. 30

31 CAPÍTULO 1. PROTOCOLO USB STALL El Handshake STALL puede significar: que no soporta una petición de control, la petición de control ha fallado o el endpoint no existe. En el caso que el endpoint falle, el dispositivo es incapaz de recibir o trasmitir los datos. El comando STALL es transmitido sólo por los dispositivos (upstream), y pueden ser recibidos únicamente por el controlador, el cual debe intervenir para solucionar el problema antes de que la comunicación puede ser reanudada Transferencias USB fue diseñado para manipular diferentes periféricos con diversos requisitos como: velocidad de transferencia, tiempo de respuesta, tamaño de datos enviados y corrección de errores. Los cuatro tipos de transferencias que existen en USB cumplen con las necesidades que se nombraron. Las transferencias son: Control, Interrupt, Bulk y Isochronous y un dispositivo puede integrar a los tipos de transferencias que más les convengan y satisfagan, según sean sus propósito, siendo el del tipo Control el único de uso obligatorio para los dispositivos USB. Tipo Control Bulk Interrupt Isochronous Uso típico Identificación configuración Impresoras, Mouse, teclados, Streaming audio y scanner, pendrives joysticks video. Requerido Si No No No Permite lowspeed Si No Si No Corrección de Si Si Si No errores? Reserva ancho 10 % para low y No 90 % para low y 90 % para low y de banda full-speed, 20 % full-speed, 80 % full-speed, 80 % para high-speed para high-speed para high-speed Máxima tasa 832 bytes/frame 1216 bytes/frame 64 bytes/frame 1023 bytes/frame full-speed Máxima tasa 24 bytes/frame No permitido 0.8 bytes/frame No permitido low-speed Tasa garantizada No No No Si de entre- ga? Cuadro 1.6: Resumen de las transferencias y sus usos. El cuadro 1.6 muestra los tipos de transmisión con un resumen de las cualidades y sus típicos usos. Para cada transferencia se considera el máximo tamaño del paquete permitido. 31

32 CAPÍTULO 1. PROTOCOLO USB Interrupt Éste tipo de comunicación incorpora detección de errores y retransmisión de datos. Es utilizado por aquellos dispositivos que desean transferir muy poca información y además poco frecuente, asegurando la lectura de los datos dentro de un período máximo de tiempo. Los dispositivos full-speed pueden solicitar entre 1 y 255 ms, mientras que los dispositivos low-speed pueden solicitar un período máximo de servicio entre 10 y 255 ms. Interrupt tiene la particularidad de ser unidireccional por cada endpoint que se defina (desde el host al dispositivo o desde el dispositivo al host). Además junto con las transferencias de Control, las transferencias del tipo Interrupt son las únicas formas en que los dispositivos low-speed pueden transferir datos. Los teclados y los mouse usan este tipo de transferencias para enviar información de teclas, botones y datos de los movimientos. Las transferencias de interrupción pueden usar cualquier velocidad ya sea low, full o high speed, pero los dispositivos no están obligados a soportar las transferencias de interrupción. Una clase específica de dispositivo las podría precisar si la requiere. Figura 1.14: Fases de una transacción Interrupt. Durante cada frame la máxima carga útil de datos permitidos por las transferencias de interrupción es de 8 bytes para low-speed y de 8, 16, 32 ó 64 bytes para dispositivos full-speed. Para USB 2.0 en modo high-speed el tamaño máximo del paquete para las transferencias de interrupción es aumentado a 1024 bytes. La reserva de tiempo para acomodar transferencias de interrupción es como máximo el 90 % del tiempo del frame y 80 % para microframe, esto porque las transferencias de Control tienen reservado el otro 10 % restante. El sistema USB puede ir estableciendo pipes 32

33 CAPÍTULO 1. PROTOCOLO USB de interrupción con distintos dispositivos hasta agotar dicha reserva, en caso que estén agotadas las reservas y se incorporen nuevos dispositivos con transferencias del tipo Interrupt, el dispositivo responderá como no configurado. Las transacciones del tipo Interrupt pueden ser transferencias IN o OUT 1. La transacción se compone de tres fases: Token, Data y Handshake, tal como se muestra en la figura Bulk La transferencia Bulk es una comunicación no periódica, típicamente empleada por transferencias que requieren usar todo el ancho de banda disponible o esperar hasta que el ancho de banda esté disponible. Esto implica particularmente movimientos de imágenes, archivos o video, donde se requiere de gran potencial de transferencia en poco tiempo. Para estas aplicaciones, las transferencias pueden ser muy rápidas pero los datos pueden esperar si es necesario. Si el bus USB está muy ocupado, entonces las transferencias Bulk son lentas, pero si el bus de lo contrario está desocupado, entonces las transferencias Bulk son muy rápidas. Figura 1.15: Fases de una transacción Bulk. Los dispositivos full-speed y high-speed pueden hacer transferencias Bulk. Los dispositivos low-speed no pueden soportar las transferencias Bulk. Para dispositivos full-speed el máximo tamaño del paquete puede ser 8, 16, 32 ó 64 bytes y para dispositivos high-speed es de 512 bytes. Los dispositivos no están obligados a tener una pipe tipo Bulk, pero una clase específica del dispositivo las podría precisar. Otra de las características de la transferencia Bulk es la habilidad de garantizar la entrega de 1 USB 1.0 sólo admite transferencias del tipo IN, USB 1.1 soporta ambas. 33

34 CAPÍTULO 1. PROTOCOLO USB datos libres de errores entre el host y el dispositivo. Bulk usa 3 fases: Token, Data y Handshake (figura 1.15). Bajo ciertas condiciones del endpoint en el cual su estado está en modo suspendido, la fase Data es reemplazada por el Handshake resultando sólo 2 fases de transmisión. Los campos PING y NYET sólo son usados por dispositivos high-speed Isochronous La transmisión isócrona ha sido desarrollada especialmente para satisfacer las demandas de la transmisión en tiempo real para voz, video e imágenes, donde los errores pueden ser tolerados (los posibles errores no se recuperan, la información que no llega a su tiempo se descarta). La transferencia isócrona provee comunicación continua y periódica entre el host y el dispositivo, con el fin de mover información relevante a un cierto momento, donde la información útil por paquete puede oscilar entre 1 y 1,023 bytes. Sólo los dispositivos full y high-speed pueden hacer transferencias isócronas y para el caso de full-speed se puede reservar un ancho de banda de hasta un 90 %. En el caso que el sistema no puede garantizar el tiempo suficiente como para manejar una nueva conexión isócrona (transmitir un nuevo paquete dentro del período máximo requerido), simplemente no se establece la conexión. Figura 1.16: Fases de una transacción Isochronous. La figura 1.16 resume las fases permitidas dentro de una transferencia isócrona. Existen dos fases: Token y Data, no existe ninguna fase Handshake en las transferencias isócronas CONTROL Las transferencias de control están definida para un solo uso: transportar las peticiones (request) standard y especificas definidas por la especificación USB. El objetivo 34

35 CAPÍTULO 1. PROTOCOLO USB es facultar al host para que éste interrogue y configure a los dispositivos conectados en los puertos. Por esta razón, la intervención de este tipo de comunicación es obligatoria y sólo aparece al principio de la conexión de un dispositivo, para luego dar paso a las otras tres transferencias posibles. La transferencia de Control se hace a través del endpoint-0 bidireccional. Un fabricante puede colocar otros endpoint de Control a disposición, pero no trae ninguna ventaja comparativa. En la figura 1.17 se resumen las fases de una transacción de Control. Figura 1.17: Fases de una transacción de Control. 35

36 Capítulo 2 Controlador SL811HS Este capítulo explica el funcionamiento general del host controlador SL811HS, detallando las principales señales que posee. A su vez, se nombran las funciones básicas que permiten acceder a la lectura y escritura de los registros de configuración del SL811HS, para luego nombrar y explicar cuales son los registros principales para el funcionamiento en modo host Aspectos generales El controlador USB SL811HS cuyo diagrama se muestra en la figura 2.1, es un chip de la compañía Cypress Semiconductor Corporation, capaz de comunicarse con dispositivos USB tanto como para la velocidad low-speed, como para la velocidad full-speed. El controlador SL811HS sólo soporta la norma del protocolo USB Figura 2.1: SL811HS pin layout. 1 USB 1.1 no soporta high-speed. 36

37 CAPÍTULO 2. CONTROLADOR SL811HS A diferencia de otros controladores USB, el SL811HS puede ser controlado por diversos dispositivos tales como: microprocesadores, microcontroladores, DSPs, y variedades de buses como: ISA, PCMCIA y otros. De esta manera, el controlador SL811HS sirve para una variedad de sistemas embebidos en donde requieren de una configuración independiente del dispositivo que lo controle, ya sea para un modo host (controlador) o un modo slave (dispositivo USB) Módulo de trabajo La compañía Cypress a lo largo del tiempo ha sacado diferentes modelos de este chip, como por ejemplo: SL811, SL811S y SL811HS. A su vez, se ha revisado el firmware del SL811HS agregando en varias ocasiones modificaciones, como por ejemplo la generación automática de CRC. En la presente memoria se trabajó con el chip SL811HS versión 1.5, ensamblado en un módulo de trabajo que es mostrado en la figura 2.2. Este módulo fue realizado por el Departamento de Electrónica como parte del trabajo de título de Michael Kusch. Figura 2.2: Módulo de trabajo para el SL811HS. En la presente memoria el módulo fue controlado a través del microcontrolador MSP430F1612. El detalle de la conexión entre el microcontrolador, el controlador SL811HS y el display de 4 líneas, se puede consultar en el Apéndice B. 37

38 CAPÍTULO 2. CONTROLADOR SL811HS Modos host/slave El SL811HS soporta dos modos de trabajo. El primer modo es USB Host que sirve para manejar y controlar diversos dispositivos USB. La segunda opción es elegir el modo de trabajo USB Slave, que se utiliza para diseñar dispositivos USB con la capacidad de manejar diversos endpoints según la necesidad del diseñador. Estos dos modos se pueden elegir a través de un solo pin: se fija a tierra en caso que se trabaje en modo host o se conecta a Vcc para trabajar modo slave. Junto con la elección del pin master o slave, se debe construir un circuito propuesto por el fabricante para cada caso, pero que tienen una gran similitud de construcción. La similitud de los circuitos fue aprovechado por Michael Kusch para ensamblar ambos modos en una sola placa, dando la opción de elegir entre host y slave a través de tres jumper tal como lo muestra la figura Figura 2.3: Conectores Serie-A y Serie-B. La elección del modo de trabajo host o slave, lleva consigo a la utilización de conectores únicos para cada caso. Para trabajar en modo host los conectores y cables se denominan Serie-A, en cambio los conectores en modo slave son llamados Serie-B (figura 2.3). Nunca se debe usar un modo de operación y conectar ambas series, puesto que el SL811HS no trabaja en ambos modos al mismo tiempo Registro y memoria El SL811HS usa un mapa de memoria de 256 bytes, los cuales se direccionan a través de un bus de datos de 8 bits. Las primeras 16 direcciones (00h-0Fh) corresponden a los 16 registros que se disponen para el control del chip tanto para el modo host 1 En la figura 2.2, los tres jumper tienen el color azul. 38

39 CAPÍTULO 2. CONTROLADOR SL811HS y slave. Las direcciones restantes (10h-FFh) están disponible para la implementación del buffer que envía y recibe los datos a los dispositivos USB. El mapa de la memoria del SL811HS se muestra gráficamente en la figura 2.4. Figura 2.4: Distribución de la memoria y registros Registros generales de configuración ADDR. Función Escritura Función Lectura 0x00 USB-A Control USB-A Control 0x01 USB-A Address USB-A Address 0x02 USB-A Length USB-A Length 0x03 USB-A PID/EP USB-A Status 0x04 USB-A Address USB-A Count 0x05 Ctrl1 Ctrl1 0x06 Int. Enable Int. Enable 0x07 Reservado Reservado 0x08 USB-B Control USB-B Control 0x09 USB-B Address USB-B Address 0x0A USB-B Length USB-B Length 0x0B USB-B PID/EP USB-B Status 0x0C USB-B Address USB-B Count 0x0D Int. Status Int. Status 0x0E SOF Low HW Revision 0x0F SOF High/Ctrl2 SOF High/Ctrl2 Cuadro 2.1: Registros de configuración del SL811HS. Los 16 registros mostrado en el cuadro 2.1 se pueden separar en 3 bloques: registros para la utilización en modo host (USB-A), registros para la utilización en modo slave (USB-B) y registros comunes de control para ambos modos. 39

40 CAPÍTULO 2. CONTROLADOR SL811HS Los registros de configuración tienen la característica que después de escribir en ellos se puedan leer para verificar los valores, sin embargo algunos registros funcionan de diferente manera para la lectura y escritura, adquiriendo una doble función: configurar los registros para el control e informar datos revelantes respecto a la comunicación USB. La comprobación de un registro sólo tendrá sentido para aquellos registros que cumplan con la misma función (deben tener el mismo nombre para lectura y escritura en el cuadro 2.1) Registros en modo host Son 10 registros que se ocupan en modo host (12 funciones diferentes), los cuales se resumen en el cuadro 2.2. En el cuadro mencionado se muestra: el nombre de cada registro (columna 1), la definición que ocupa en el código del programa (columna 2), la dirección del registro en el SL811HS (columna 3) y un resumen de las principales características (columna 4). La mayoría de los registros son configuraciones bit a bit. Para mayor detalles de los registros y su configuración se puede consultar el Apéndice C de este trabajo, donde además se incluyen ejemplos con los registros en modo host, o bien consultar el documento 1 oficial. Registro. Definición Direcc. Características USB-A Control CTL 0x00 provee el control básico de las transacciones realizada por el host USB-A Address BUFADR 0x01 fija en que parte de la memoria van a llegar o enviar los datos USB-A Length BUFLEN 0x02 fija el largo máximo de la transacción USB-A PID/EP PID EP 0x03 establece que tipo de paquete se va enviar y en que endpoint USB-A Status PKTSTAT 0x03 indica el resultado de la última transacción USB-A Address FNADDR 0x04 fija la dirección del dispositivo USB (0-127) Ctrl1 CTL1 0x05 genera reset, control de low/full, suspensión/habilitación del USB y generación automática de SOF Int. Enable IE 0x06 habilita las interrupciones Int. Status INTSTATUS 0x0D muestra el estado de las interrupciones SOF Low SOFCT L 0x0E contador low, para generar frame de 1 ms HW Revision HWR 0x0E indica la versión del hardware SOF High/Ctrl2 SOFCT H 0x0F contador high, para generar frame de 1ms Cuadro 2.2: Registros y definiciones para modo host Señales de control El microcontrolador accede al SL811HS por medio de una serie de pines de entrada y de salida. Estas señales permiten realizar las funciones básicas para realizar 1 El documento se puede encontrar en la página o en el CD-ROM adjunto a la memoria, Documentos/Sl811hs/SL811HS - Datasheet.pdf. 40

41 CAPÍTULO 2. CONTROLADOR SL811HS las operaciones dentro del chip y así poder establecer una comunicación USB. Si bien es importante saber el funcionamiento de estas señales para poder construir las primeras operaciones básicas dentro del chip, en un momento dado, luego de las construcciones de las funciones básicas (lectura y escritura), estas señales pasarán a un segundo plano, ya que difícilmente serán manipuladas en una forma directa por el programador. Las señales básicas se muestran en la figura 2.5. Figura 2.5: Señales de acceso para el SL811HS. A continuación se explican las señales del SL811HS y se muestran las definiciones del código para el uso del microcontrolador. CHIP SELECT (ncs): Esta señal se usa para habilitar la lectura o escritura tanto de los registros de configuración como del buffer para almacenamiento de datos, de esta manera se protege el uso del chip cuando se compartan las mismas señales en el microcontrolador. #define USB_EN_ON P1OUT=BIT2 #define USB_EN_OFF P1OUT&=~BIT2 #define USB_EN_init P1DIR=BIT2;P1SEL&=~BIT2; // OUT; DigitalIO; READ (nrd): Con una señal baja, el microcontrolador puede acceder a la lectura de los registros y memoria del SL811HS, sin embargo antes de que una lectura pueda llevarse a cabo, la dirección del registro o memoria que se desea leer debe estar escrita en el puntero del SL811HS. Previamente la señal ncs debe habilitar la lectura del chip para que se pueda reconocer la señal nrd. #define USB_RD_ON P1OUT=BIT4 #define USB_RD_OFF P1OUT&=~BIT4 #define USB_RD_ini P1SEL&=~BIT4; // DigitalIO; #define USB_RD_OUT P1DIR=BIT4; #define USB_RD_IN P1DIR&=~BIT4; 41

42 CAPÍTULO 2. CONTROLADOR SL811HS WRITE (nwr): Esta señal se activa con un bit bajo para que el microcontrolador pueda escribir en el puntero, registro o memoria del chip. Al igual que la señal de lectura nrd se debe activar ncs para su uso. #define USB_WR_ON P1OUT=BIT3 #define USB_WR_OFF P1OUT&=~BIT3 #define USB_WR_init P1SEL&=~BIT3; #define USB_WR_OUT P1DIR=BIT3; #define USB_WR_IN P1DIR&=~BIT3; // DigitalIO; ADDRESS (A0): La señal A0 es manejada para que en conjunto con la señal nwr se pueda definir si la escritura es hacia el puntero o hacia los registros. #define USB_A0_ON P1OUT=BIT5 #define USB_A0_OFF P1OUT&=~BIT5 #define USB_A0_init P1SEL&=~BIT5; #define USB_A0_OUT P1DIR=BIT5; #define USB_A0_IN P1DIR&=~BIT5; //OUT; DigitalIO; Las formas de ondas que se producen dentro del SL811HS cuando se produce una escritura en un registro son mostradas en la figura 2.6. Figura 2.6: Formas de ondas cuando se escribe en un registro del SL811HS. INTERRUPT (INTRQ): La señal INTRQ entrega un valor alto al microcontrolador, cuando ocurre una de las posibles interrupciones programadas dentro del SL811HS, como por ejemplo la conexión de un nuevo dispositivo. INTRQ vuelve a cero sólo cuando el registro de interrupción es borrado a través de software. 42

43 CAPÍTULO 2. CONTROLADOR SL811HS #define USB_INT P1IN&BIT0 //Active High #define USB_INT_B BIT0 //Active High #define USB_INT_init P1DIR&=~BIT0;P1SEL&=~BIT0; // IN; DigitalIO; #define USB_INT_EN P1IE=BIT0;P1IES&=~BIT0; DATA BUS (D[7:0]): El SL811HS usa este bus bi-direccional para transferir datos de entrada y salida de los registros y memoria. #define USB_IN P4IN #define USB_OUT P4OUT #define USB_SEL P4SEL #define USB_DIR P4DIR RESET (NRST): La señal NRST se realiza a través de un nivel bajo de entrada para generar un reset. El reset es válido cuando se cumplen 16 ciclos de reloj del SL811HS. #define USB_RST_ON P1OUT=BIT1 #define USB_RST_OFF P1OUT&=~BIT1 #define USB_RST_init P1DIR=BIT1;P1SEL&=~BIT1; // OUT; DigitalIO; 2.4. Funciones básicas El objetivo es poder realizar cuatro funciones que permitirán configurar y establecer la comunicación USB: iniciar el SL811HS, leer registros/memoria, escribir en los registros/memoria del SL811HS y detectar la velocidad de un dispositivo Escritura en registros La función wr811(), cuyo código es mostrado más abajo, realiza la función de escribir en la dirección del registro/memoria a del SL811HS, el valor del byte d. Para ello utiliza la habilitación de las señales discutidas anteriormente void wr811(byte a, BYTE d) { USB_SELECT; //Make SL811 ready to communicate with. USB_DIR=0xFF; //Data port to outputs USB_OUT=a; USB_A0_OFF; //Write address to pointer USB_WR_OFF; USB_WR_ON; USB_OUT=d; USB_A0_ON; //Write data to register USB_WR_OFF; USB_WR_ON; 43

44 CAPÍTULO 2. CONTROLADOR SL811HS USB_DIR=0x00; USB_DESELECT; } //Data port to inputs (for multiplexing) //Liberate used signals Se construyó una función más útil para copiar datos en bloques desde memoria del microcontrolador al buffer del SL811HS: char *BuffWr811(BYTE addr, BYTE c, char *ptr) { if(c<=0) return ptr; while (c--) wr811(addr++,*ptr++); return ptr; } La función BuffWr811() es una variación que permite escribir un bloque de datos de largo específico c desde un puntero ptr a la dirección addr del SL811HS. Como precaución se debe usar siempre a partir de la dirección 0x10h (addr), puesto que antes se encuentran los registros de configuración. En caso de querer modificar los registros de configuración, siempre será mejor hacerlo a través de la función wr811() que permite operaciones paso a paso, y de esta manera evitar posibles errores. Otra operación de escritura en el SL811HS es la función BuffClear811(). La función fue construida para borrar bloques de memoria del SL811HS. De esta manera se podrá borrar basura o limpiar los registros para realizar análisis de los datos recibidos y así no mezclar los antiguos datos del SL811HS. El código para esta función es mostrado a continuación: void BuffClear811(BYTE addr, BYTE c) { if(c<=0) return; while (c--) wr811(addr++,0x00); } Lectura de registros La función que permite la lectura de los registros o buffer del SL811HS es la función rd811() donde el código es muy parecido a la función de escritura. El código 44

45 CAPÍTULO 2. CONTROLADOR SL811HS para esta función es mostrado a continuación: BYTE rd811(byte a) { unsigned char d; USB_SELECT; //Make SL811 ready to communicate with. USB_DIR=0xFF; //Data port to outputs USB_OUT=a; USB_A0_OFF; //Write address to pointer USB_WR_OFF; USB_WR_ON; USB_DIR=0x00; //Data port to inputs USB_A0_ON; //Read data from register USB_RD_OFF; d=usb_in; //Read DATA USB_RD_ON; USB_DESELECT; //Liberate used signals return d; } Al igual que en la sección de la escritura, esta vez se diseño la función contraria. La función BuffRead811() permite leer y copiar datos en bloques desde el SL811HS al microcontrolador. El código de esta función es mostrado a continuación. void BuffRead811(BYTE addr, BYTE c, char *s) { if(c<=0) return; while (c--) *s++=rd811(addr+); } Inicialización del SL811HS La inicialización del SL811HS consiste en primer lugar en aplicar por medio de señales un reset 1 al SL811HS. En segundo lugar se habilitan los puertos del microcontrolador que van controlar las señales del SL811HS. Todo este proceso se encuentra disponible en la función USB init(). El código de la función se muestra a continuación: unsigned char USB_init(void) { unsigned char rev; 1 También es posible aplicar un reset a través de los registro de configuración, pero para ello tiene que estar inicializado el SL811HS. 45

46 CAPÍTULO 2. CONTROLADOR SL811HS USB_RST_OFF; //Reset activado USB_RST_init; //inicialización de las se~nales USB_EN_ON; USB_EN_init; USB_PWR_OFF; USB_PWR_init; USB_WR_init; USB_RD_init; USB_INT_init; USB_PWR_FLG_init; Delayx100us(250); USB_RST_ON; //Reset desactivado. USB_SEL=0x00; //DigitalIO USB_PWR_ON; //obetencion de la versión del Hardware. rev=( (rd811(hwr)&0xf0) >>4 ); return rev; } Antes que se desactive el reset con una señal alta (línea 15 del código) se espera un tiempo suficiente para asegurar que se cumplan los 16 ciclos de reloj y así el reset tenga efecto. Esta función retorna la versión del hardware, leyendo el registro HWR 1 del SL811HS. El número obtenido tiene que desplazarse puesto que la información está en los últimos 4 bits del registro. El valor de la actual versión del chip es 02h (versión 1.5) Detección low/full speed Las cuatro interrupciones que se generan dentro del SL811HS activan una sola señal en el microcontrolador. Las interrupciones se habilitan o deshabilitan con el registro IE (0x06) del SL811HS, dando las posibilidades de configurar las interrupciones para: la detección del puerto USB-A o USB-B, interrupciones de desconexión o conexión de un dispositivo esclavo, interrupción por resumen/suspensión de un dispositivo y finalmente interrupción cuando se produce un SOF (Start Of Frame). Como se puede analizar, las interrupciones (excluyendo la interrupción por SOF) sólo tienen que ver con el dispositivo físico. El registro que se encarga de informar cual es la interrupción que se activa corresponde al registro INTSTATUS (0x0D), que junto con decir la presencia o ausencia de un dispositivo, entrega información (en el bit7) si la línea conectada es D+ o D-, determinando de esta manera si el dispositivo es low-speed o full-speed. Se puede decir que cuando se usa el SL811HS con un solo puerto de entrada (sin hub), las interrupciones que tienen que ver con el dispositivo físico pueden llegar a ser de uso ocasional. Por lo contrario, la interrupción por SOF es una interrupción de uso frecuente: cuando se envían paquetes de control o datos a un dispositivo, éstos 1 El registro HWR está definido como el registro de lectura 0x0E. 46

47 CAPÍTULO 2. CONTROLADOR SL811HS se hacen normalmente después de generarse un SOF 1 (inicio de un frame) y para ello se usa las interrupción por SOF usando la función waitframes(byte n). La función mencionada retorna cuando pasa la cantidad de n-frame y justo después de haberse generado el SOF. Función detección de velocidad Internamente la función detectar velocidad() consiste en cuatro partes: desactivación de las transferencias USB; comprobación de la presencia o ausencia de un dispositivo a través de las interrupciones; determinar si el dispositivo es full o low speed y finalmente la configuración para cada caso de velocidad. El código de la función detectar velocidad() es mostrado a continuación: int detectar_velocidad(void) { wr811(sofct_h, 0x2E 0x80); // 1 msec SOF rate, b7=host, b6= no change wr811(ctl1,usb_reset); // Reset USB. Delayx100us(250); //estabiliza. wr811(ctl1,0x00); // Set normal operación. wr811(ie,(usb_ie_ins USB_IE_A USB_IE_RESUME)); // USB-A, Insert/Remove, USB_Resume. wr811(intstatus,usb_int_clear); // Limpia las interrupciones. Delayx100us(250); //estabiliza. if (rd811(intstatus)&usb_if_detect) //Si no hay dispositivo. { wr811(intstatus,usb_int_clear); printf("no hay dispositivo."); return 0; } else { // Limpia las interrupciones. if (rd811(intstatus)&usb_if_d) //bit7 de registro 1=full,0=low. { wr811(intstatus,usb_int_clear); // Limpia las interrupciones. printf("full speed."); //activa para usar en full. wr811(sofct_l, 0xE0); } else wr811(sofct_h, 0x2E wr811(ctl1,0x01); return 2; } 0x80); { wr811(intstatus,usb_int_clear); // Limpia las interrupciones. printf("low speed."); //activar low. wr811(sofct_l, 0xE0); wr811(sofct_h, 0x2E 0xC0); wr811(ctl1,0x21); return 1; } 1 La entrega de los paquetes se puede hacer de forma automática después de un SOF usando los registros de configuración, pero el SL811HS contiene un error que no permite el uso normal de esta configuración. 47

48 CAPÍTULO 2. CONTROLADOR SL811HS } //end detectar_velocidad. Hay que mencionar que la función detectar velocidad() retorna valores según sea el caso: el valor 0 cuando no hay dispositivo, el valor 1 para dispositivos low-speed y el valor 2 para los dispositivos que sean full-speed. De esta manera la función detectar velocidad() es el primer paso para la enumeración del bus. 1 Existen dos escenarios distintos para la detección de un dispositivo: primer caso cuando el dispositivo está conectado desde un principio al controlador, y segundo caso cuando ya se ha iniciado el funcionamiento del controlador y el usuario conecta un tiempo después el dispositivo USB. Para ambos casos la función detectar velocidad() cumple con el reconocimiento y configuración del dispositivo. En el primer caso, en donde un dispositivo se encuentra inicialmente conectado al SL811HS, simplemente basta con colocar en el programa principal las siguientes funciones ya comentadas: int main(void) {.. USB_init(); detectar_velocidad();.. } Usando los valores de retorno de la función se puede condicionar el paso al resto del código con una sentencia while() hasta que se cumpla una condición verdadera, es decir, hasta que se conecte un dispositivo. Sin embargo, cuando se ocupa el microcontrolador para realizar otras tareas y no tiene dedicación exclusiva para el controlador SL811HS, se debe usar la función detectar velocidad() en una rutina de interrupción del microcontrolador, tal como se muestra el siguiente código: #pragma vector = PORT1_VECTOR interrupt void port1_int(void) { if(usb_int_b&p1ifg) { detectar_velocidad(); P1IFG &= ~BIT0; } } Se puede decir que las dos formas de utilización, ya sea en forma indirecta o directa, son convenientes dependiendo de las circunstancias. Por ejemplo, cuando se está diseñando dispositivos USB es preferible usar la función en forma directa para la mayor comprensión y descartar posibles errores. 1 Posteriormente la función detectar velocidad() va a ser incluida en otra función más completa llamada Bus Enumeracion(). 48

49 CAPI TULO 2. CONTROLADOR SL811HS 2.5. Visualizacio n de los registros Para la construccio n de los primeros co digos de programas, la visualizacio n de los registros de configuracio n fue un factor muy importante; cuando se producen errores de comunicacio n es necesario consultar los registros de configuracio n y ası poder aislar el error verificando cada registro del SL811HS. Tambie n es u til consultar por los datos que se esta n enviando o recibiendo, ubicados en el buffer de SL811HS. Para ambos casos hay dos posibles soluciones: a trave s del display de 4 lı neas o a trave s de la herramienta watch del IAR Embedded Workbench Visualizacio n de los registros a trave s del display El display de 4 lı neas permite mostrar so lo hasta 16 nu meros en formato hexadecimal (4 registros por lı nea), lo cual es precisamente la cantidad de registros que tiene el SL811HS. Para ello se construyo la funcio n Registros(BYTE a). El para metro a indica de donde empezar a mostrar los registros. Figura 2.7: Visualizacio n de los registros a trave s del display. Por lo tanto, con so lo poner Registros(0x00) en cualquier parte del co digo del programa, se podra obtener los primeros 16 registros de del SL811HS. En la figura 2.7 se muestra un ejemplo real. Utilizando el ejemplo de la figura 2.7 se debe aclarar dos cosas: no todos los registros mostrados en el display son para el modo host y segundo, no todos los registros tienen la misma funcio n de lectura y escritura Visualizacio n de los registros a trave s de la ventana Watch Utilizando la herramienta watch del IAR embedded se pueden visualizar variables, estructuras, arreglos, etc. La manera de cargar los registros a la memoria del microcontrolador es por medio de la funcio n BuffRead811() mencionada en secciones anteriores de este capı tulo y que permite leer bloques de memoria del SL811HS. El procedimiento para cargar los 16 registros es muy sencillo: 1 Software que se utilizo para programar el microcontrolador MSP430f

50 CAPÍTULO 2. CONTROLADOR SL811HS char temp[16] ; BuffRead811(0, 16,temp); La ventana watch se obtiene desde menu/view/watch y luego se escribe el nombre de arreglo que se desea ver. La figura 2.8 muestra el resultado obtenido de los registros de configuración en la misma situación que en el ejemplo anterior. Se puede observar que los resultados son los mismos exceptuando por el último registro. Esto se debe a que el último registro es un indicador de velocidad de transmisión y siempre va a estar en constante cambio. Figura 2.8: Visualización de los registros con la herramienta watch. 50

51 Capítulo 3 Peticiones, descriptores y configuración general Este capítulo describe como el host tiene a disposición un set de herramientas denominadas peticiones (Request). Se detalla el funcionamiento y nombre de las principales peticiones que fueron creadas para que el host pueda utilizarlas en la interrogación y configuración de los dispositivos, mostrando en cada caso la estructura interna de cada petición. Además, se explican cuales son los pasos necesarios para la configuración básica de un dispositivo USB y así luego lograr establecer una comunicación de transferencia en forma exitosa. Finalmente se nombran algunos programas que manejan diferentes aspectos de los dispositivos y protocolos, y de esta manera descartar posibles errores en la construcción de códigos Peticiones Las peticiones o Request son una serie de instrucciones definidas por USB-IF que permiten a los controladores USB la interrogación y configuración de los dispositivos. La interrogación permite obtener información clave para la asignación de un driver adecuado. En total son 11 las peticiones standard que el host puede utilizar en diferentes tareas: desde asignar una dirección al dispositivo, hasta desactivar un endpoint para no recibir más datos. No todas las peticiones tienen un uso fijo, un grupo reducido se dividen internamente para generar nuevas sub-peticiones. Algunas peticiones participan sólo después de que el dispositivo está configurado, para así monitorear multiples sucesos. Un grupo importante de las peticiones se ejecutan sólo al principio de cada configuración, generando un proceso que se denomina Bus Enumeración Tipos de peticiones Las 11 peticiones que se muestran en el cuadro 3.1 son llamadas peticiones del tipo standard (Standard Request), definidas en el capítulo 9 del protocolo USB y válidas para USB 1.1 y 2.0. Las peticiones standard son de carácter de obligatoriedad de 51

52 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL implementar por los diseñadores de dispositivos USB, de esta manera siempre se va a tener la seguridad que las peticiones responderán cuando el host las ocupa. Sin embargo, no es así para las peticiones de clase donde grupos de dispositivos de similares características se asocian. Por ejemplo la clase de dispositivos de almacenamiento masivos, en donde se agrupan dispositivos tales como pendrives, CD-ROM, DVD, discos duros, etc. Las clases disponen de nuevas peticiones que son definidas en sus respectivos document class. Las peticiones de clases pueden entregar algún tipo de información adicional, o bien realizar alguna función específica dentro del dispositivo. Nombre Valor Nombre Valor (brequest) (brequest) get status 0 set descriptor 7 clear feature 1 get configuration 8 reservado 2 set configuration 9 set feature 3 get interface 10 reservado 4 set interface 11 set adress 5 synch frame 12 get descriptor 6 Cuadro 3.1: Peticiones Standard. El nombre de cada petición tiene asociado un valor único para la identificación. El valor de cada petición es pasado como parámetro en conjunto con otros valores que finalmente definen a la petición. El detalle de las construcciones de las peticiones se verá posteriormente Principales peticiones Las principales peticiones son las que pertenecen al llamado Bus Enumeración. Estas son: set adress, set configuration, get configuration y get descriptor (descriptores generales) set adress Todos los dispositivos al conectarse por primera vez están en la dirección cero del host, lo que lleva a que siempre se deba estar liberando la dirección para la configuración de los nuevos dispositivos. Mientras un dispositivo permanezca en la dirección cero, el host no podrá reconocer otro dispositivo. La petición set adress realiza la asignación de una entre las 127 direcciones que están disponibles. En los controladores USB la asignación es única para el dispositivo, por lo tanto sólo una vez se puede asignar una dirección a un dispositivo. La función creada para que el host pueda obtener el acceso a esta petición se muestra a continuación: 52

53 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Función: set_adress(byte adress); La petición no retorna ningún valor hacia el host. El parámetro adress determina la nueva dirección del dispositivo. Por ejemplo set adress(0x01) significará que el nuevo dispositivo estará en la dirección número 1. La dirección no tiene que ser necesariamente una dirección correlativa, puede tomar cualquier valor menos el valor de 0. Sin embargo, en caso de que el SL811HS tenga configurado un HUB, es recomendable usar direcciones ordenadas set configuration La petición set configuration es para declarar que el dispositivo está completamente configurado. De esta manera, el dispositivo ya puede comenzar a usarse sin problemas. Los dispositivos que no están declarados como configurados no suelen responder a las transferencias de datos. La función creada para tener acceso a esta petición se muestra a continuación: Función: set_configuration (BYTE adress, BYTE value); El parámetro adress indica la dirección del dispositivo en donde se aplicará esta petición. El parámetro value indica la configuración que se ha elegido para el dispositivo. El valor lo determina otra petición llamada Configuration Descriptor en su campo de retorno llamado bconfigurationvalue. Por lo general los dispositivos traen una sola configuración y el valor del parámetro value es siempre de 0x get configuration Una manera de saber si realmente un dispositivo está configurado es a través de la petición get configuration. La petición retorna al host el valor de la actual configuración del dispositivo. En caso que el dispositivo no está configurado, la petición get configuration retorna el valor 0. Por lo general la petición get configuration no es un requisito obligatorio dentro del Bus Enumeración. La función creada para tener acceso a esta petición se muestra a continuación: 53

54 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Función: int set_configuration (BYTE adress); 3.2. Descriptores Sin duda una de las peticiones que caracteriza el funcionamiento USB, donde necesariamente es un punto de discusión con más detalle para cualquier tipo de diseño, son las peticiones que se obtienen por medio de get descriptor, comúnmente nombrado como descriptores. La importancia de esta petición standard radica en el hecho de que cada dispositivo USB tiene grabado en una ROM las descripciones e interfaces hechas por el fabricante del producto. Saber el detalle de las descripciones es completamente necesario para que el host pueda determinar el driver apropiado. Entre los muchos datos que se pueden obtener están por ejemplo: tipo de transferencia (Control, Isochronous, Bulk, Interrupt), clase de dispositivo, transferencia máxima, números de endpoints disponibles, etc., en fin, una cantidad de información útil. Sin embargo, también se puede consultar por detalles que no son necesarios para el funcionamiento del dispositivo pero puede servir de información general, por ejemplo los descriptores del tipo string donde entregan datos como: nombre del fabricante, modelo del aparato, número de serie, etc Descriptores Standard Figura 3.1: Descriptores Standard. 54

55 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Son cuatro los Descriptores Standard que se pueden solicitar. La figura 3.1 muestra como se dividen jerárquicamente ya que cada descriptor depende del anterior. Se puede observar que cada dispositivo tiene un Device Descriptor que contiene información general acerca del dispositivo: número de la versión del USB, máximo tamaño para el endpoint-0, identificadores de fábrica y producto, etc. A su vez, un dispositivo USB puede tener diferentes configuraciones para que el host puede elegir cual más le convenga, como por ejemplo ahorrar energía. Normalmente no existen productos USB con alternativas de configuraciones. Configuration Descriptor contiene información como: configuraciones posibles, energía requerida para funcionar, indicar si la energía es proveniente del propio Bus USB o de alimentación externa. Cada Configuration Descriptor tiene varios Interface Descriptor que detallan: endpoint disponibles y tipo de clase al cual pertenece el dispositivo. Finalmente, el último descriptor corresponde al Endpoint Descriptor que contiene el detalle sobre cada endpoint, indicando: tamaño, tipo de transferencia y dirección (IN-OUT). Cada descriptor entrega los valores a través de campos que están identificados con sus respectivos nombres. Además, cada descriptor puede tener hasta 18 campos de 1 a 2 bytes. Los primeros dos campos de los descriptores comienzan siempre de la misma manera: el primer campo muestra el largo del descriptor (blength) y el segundo campo identifica el descriptor que se solicitó (bdescriptortype). Los nombres de los campos empieza con una letra que identifica el tipo o la forma como debe ser leído: la letra b indica que es del tipo byte, bcd indica código decimal binario, id indica que es identificación y por último la letra i indica que es del tipo string. A continuación se describen los campos de cada descriptor, destacándose los campos más importante para el desarrollo de aplicaciones con dispositivos USB. En cada descriptor se muestra la respectiva función que permite el acceso a ellas, en donde se incluye un ejemplo real obtenido con las funciones para los descriptores. El detalle específico de cada campo se puede encontrar en el capítulo 9 del protocolo USB Device Descriptor El formato del Device Descriptor corresponde al mostrado en el cuadro 3.2. El campo bcdusb describe la versión del protocolo USB para el dispositivo interrogado. USB 2.0 es interpretado por el número 0x0200, USB 1.1 por 0x0110 y USB 1.0 por 0x0100. Para el caso del controlador SL811HS la versión será 1.1 indistintamente si el dispositivo es para la versión 2.0. Los campos bdeviceclass, bdevicesubclass, bdeviceprotocol identifican a que grupo (clase) de dispositivo corresponde y a que dispositivo específicamente corresponde de ese grupo. Normalmente los valores de estos campos son siempre cero, exceptuando por los hub y algunos dispositivos especiales. Cuando 55

56 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Campo Tamaño Descripción Ejemplo (bytes) blength 1 tamaño del descriptor en bytes 0x12 bdescriptortype 1 constante DEVICE(01h) 0x01 bcdusb 2 num. de especificación USB 0x0110 bdeviceclass 1 código de clase 0x00 bdevicesubclass 1 código de subclase 0x00 bdeviceprotocol 1 código de protocolo 0x00 bmaxpacketsize0 1 tamaño máximo para el paquete del endpoint0 0x40 idvendor 2 vendedor ID 0x3540 idproduct 2 producto ID 0x0215 bcddevice 2 num. de versión del producto. 0x0110 imanufacturer 1 index del String Descriptor para la fábrica 0x01 iproduct 1 index del String Descriptor para el producto 0x01 iserialnumber 1 index del String Descriptor para la serie 0x00 bnumconfigurations 1 número de posibles configuraciones 0x01 Cuadro 3.2: Estructura del Device Descriptor. los valores tienen el valor cero, los valores reales de estos campos son definidos en el Interface Descriptor a través de los campos binterfaceclass, binterface- SubClass, binterfaceprotocol. El detalle de las clases y subclases se discutirán posteriormente. Los campos imanufacturer, iproduct, iserialnumber entregan un valor llamado index el cual es ingresado como parámetro dentro del descriptor opcional llamado String Descriptor. El valor cero indica que no hay información consultable, como es el caso de números de series para dispositivos como teclados y mouse. La función construida con la cual se puede acceder a este descriptor es: Get_DescriptorDevice(BYTE adress); El parámetro adress indica la dirección del dispositivo. Esta función tiene la ventaja de mostrar los descriptores no sólo para aquellos dispositivos que se están conectando por primera, sino también, para los dispositivos que ya han sido configurados. La función Get DescriptorDevice(), al igual que las otras funciones que se construyeron para solicitar a los descriptores, retornan los valores en estructuras de datos con los mismos nombres del descriptor original. Por ejemplo la función Get DescriptorDevice() retorna los valores en la siguiente 56

57 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL estructura 1 : struct Device_Struct { unsigned char blength; unsigned char bdescriptortype; unsigned int bcdusb; unsigned char bdeviceclass; unsigned char bdevicesubclass; unsigned char bdeviceprotocol; unsigned char bmaxpacketsize0; unsigned int idvendor; unsigned int idproduct; unsigned int bcddevice; unsigned char imanufacturer; unsigned char iproduct; unsigned char iserialnumber; unsigned char bnumconfigurations; } Device_Descriptor; Por medio de la herramienta watch del programa IAR embedded se pueden visualizar las estructuras. Las estructuras definidas para los cuatro descriptores son: Device Descriptor, Config Descriptor, Interface Descriptor y Endpoint Descriptor. La figura 3.2 muestra las estructuras ingresadas en la herramienta watch. Figura 3.2: Estructura de los descriptores para la herramienta watch. La figura 3.3 muestra los datos obtenidos al solicitar la función Get DescriptorDevice() cuando se conecta un teclado USB al controlador SL811HS. 1 El resto de las funciones para los descriptores retornan en estructuras similares cambiando los nombres de los campos y el nombre de la estructura. 57

58 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Figura 3.3: Device Descriptor al conectar un teclado USB Configuration Descriptor El formato del Configuration Descriptor corresponde al mostrado en cuadro 3.3. Campo Tamaño Descripción Ejemplo blength 1 largo de este descriptor en bytes 0x09 bdescriptortype 1 constante CONFIGURATION(02h) 0x02 wtotallength 2 largo real 0x0022 bnuminterfaces 1 número de interfaces 0x01 bconfigurationvalue 1 identificador de la configuración 0x01 iconfiguration 1 índice del string configuración 0x00 bmattributes 1 alimentación propia o remota 0xA0 MaxPower 1 corriente requerida 0x32 Cuadro 3.3: Configuration Descriptor. El campo wtotallength (tercer campo) indica el largo total del actual descriptor, agregando además, la suma de todo el resto de los descriptores que quedan por consultar: cuando se accede a este descriptor, uno de los parámetros que se fijan es indicar el largo del Descriptor (corresponde al valor 0x09, primer campo). Sin embargo, la manera de acceder a los demás descriptores que quedan por consultar es a través del mismo formato del descriptor (código original de la función), pero cambiando el parámetro que indica el largo de retorno de los datos. De esta manera el dispositivo devuelve al host todo el resto de los descriptores, incluyendo algunos descriptores de clase. El máximo retorno de datos es de 255 bytes. Poner un valor diferente al establecido al wtotallength hace que el dispositivo no reconozca el comando y retorne un Stall. bmattributes y MaxPower son campos que describen las necesidades de energía del dispositivo. Si el bit6 del campo bmattributes es 1, este indicará que el dispositivo 58

59 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL es auto-alimentado, de lo contrario, un valor 0 indicará que es el Bus quien alimenta al dispositivo. Por su parte el campo MaxPower indica la corriente necesaria para el dispositivo, para ello se multiplica el valor del campo por 2 y el resultado será en miliamperes. La función construida con la cual se puede acceder a este descriptor es mostrado a continuación: Get_DescriptorConfig(BYTE adress); La figura 3.4 muestra los datos obtenidos por medio de la herramienta watch para el Configuration Descriptor. En este caso los datos obtenidos corresponden a un mouse. Figura 3.4: Configuration Descriptor de un mouse Interface Descriptor El formato del Interface Descriptor corresponde al mostrado en el cuadro 3.4. El campo binterfaceclass define la clase y corresponde al dato más importante de todos los descriptores. Una clase se emplea para especificar la manera en que una interfaz se comunica con el host, tanto a nivel de datos como a nivel de control, entregando información sobre la funcionalidad del interfaz. Las distintas clases estandarizadas por USB-IF hacen que la gran mayoría de los fabricantes de dispositivos USB trabajen con ellas, pues de lo contrario deberán desarrollar sus propios drivers. Otra ventaja de las clases es que se asegura que el host reconocerá y manejará sin ningún tipo de problemas al dispositivo. También existen los dispositivos compuestos 59

60 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL que usan múltiples clases, por ejemplo un teléfono tiene la clase HID (human interface device), la clase audio y clase de telefonía. Los valores para binterfaceclass y sus respectivas clases están en el cuadro 3.5. Campo Tamaño Descripción Ejemplo blength 1 tamaño del descriptor en bytes 0x09 bdescriptortype 1 constante INTERFACE(04h) 0x04 binterfacenumber 1 valor para fijar la interface 0x00 balternatesetting 1 valor para consultar sentencias alternativas 0x00 bnumendpoints 1 números de endpoints para la interfaz 0x02 binterfaceclass 1 código de la clase 0x03 binterfacesubclass 1 código de la subclase 0x00 binterfaceprotocol 1 código del protocolo 0x00 iinterface 1 index del string de la interface 0x00 Cuadro 3.4: Interface Descriptor. Class Device Audio CDC-Control Human Interface Physical Image Printer Mass-Storage HUB CDC-Data Chip/Smart Card Content-Security Video Diagnostic Device Wireless Controller Application-Specific Vendor-Specific binterfaceclass 0x01 0x02 0x03 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0D 0x0E 0xDC 0xE0 0xFE 0xFF Cuadro 3.5: Clases USB. El sistema operativo Windows utiliza las clases para mostrar en la barra de inicio el grupo de dispositivo que se ha conectado. En la figura 3.5 se puede observar que Windows está reconociendo y configurando la clase llamada Human Interface Device (dispositivo de interfaz humana), que corresponde a los dispositivos como teclados y mouse. En la presente memoria se trabajaron con las clases de interfaz humana (0x03) y de almacenamiento masivo (0x08). 60

61 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Figura 3.5: Mensaje de Windows para un dispositivo USB. Los valores de lo campos para binterfacesubclass y binterfaceprotocol dependen de cada clase. Por ejemplo en la clase de interfaz humana especifica si el dispositivo es un mouse o teclado. La función construida con la cual se puede acceder a este descriptor es la siguiente: Get_DescriptorInterf(BYTE adress); La figura 3.6 muestra los datos obtenidos por medio de la herramienta watch del IAR embedded. En este caso corresponde a un mouse conectado al puerto USB del SL811HS. Figura 3.6: Interface Descriptor para un mouse. 61

62 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Endpoint Descriptor El formato del Endpoint Configuration corresponde al mostrado en el cuadro 3.6. Campo Tamaño Descripción Ejemplo blength 1 tamaño del descriptor en bytes 0x07 bdescriptortype 1 constante ENDPOINT(05h) 0x05 bendpointaddress 1 dirección de la transferencia 0x82 bmattributes 1 tipo de transferencia 0x03 wmaxpacketsize 2 máximo tamaño de paquete 0x0040 binterval 1 tiempo de consulta para la transferencia 0x03 Cuadro 3.6: Endpoint Descriptor. El campo bmattributes indica el tipo de transferencia en los bit 1..0, el resto de los bit son reservados. Si el valor es 00 indica que es del tipo Control, 01 Isochronous, 10 Bulk y 11 del tipo Interrupt. El campo bendpointaddress indica la dirección del endpoint. El último bit indica el sentido que tiene el endpoint (IN o OUT). Por ejemplo el endpoint 0x02 equivaldría a un endpoint con la dirección 0x02 tipo OUT y 0x82 equivaldría a un endpoint con la dirección 0x02 pero tipo IN. binterval es el tiempo medido en frames que indica el período máximo en que se debe consultar por las interrupciones. Es obligación del host consultar por las interrupciones. La función construida con la cual se puede acceder a este descriptor es mostrado a continuación: Get_DescriptorEndpoint(BYTE adress); La figura 3.7 muestra los datos obtenidos (dos endpoint) para Get DescriptorEndpoint al conectar una impresora 1 EPSON C60 al puerto USB del host SL811HS. 1 Los datos de una impresora a otra son variables, pero siempre son los mismos para un mismo dispositivo. 62

63 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Figura 3.7: Endpoint Descriptor para una impresora String Descriptor Un String Descriptor es una petición opcional de implementar por los fabricantes. Lo que entrega esta petición es un texto UNICODE 1 sobre configuraciones, fábrica, producto, número de serie, interfaces, etc. Muchas veces se pueden encontrar textos vacíos a la hora de consultar por estas descripciones, como los casos de los mouse y teclados, ya que por la gran cantidad de productos emitidos no se declaran por ejemplo números de series. Sin embargo, tiene más sentido declarar números de series en dispositivos de mayores costos como los pendrives o modems. Un número de serie puede a veces resolver problemas de conflictos con equipos o simplemente cargar más rápido un driver, ya que las series de una fábrica son únicas. La figura 3.8 muestra un mensaje que emite el sistema operativo WindowsXP cuando se conecta un mouse de marca Genius modelo NetScroll. Este mensaje no se vuelve a mostrar si el mouse es colocado en el mismo puerto del computador, pero sí se muestra un mensaje sobre la clase de dispositivo que se encontró (figura 3.5). Figura 3.8: Mensaje de Windows XP para el nombre del producto. El mensaje mostrado por Windows de la figura 3.8 se realiza consultando con el String Descriptor. Para ello se ingresa como parámetro de entrada el valor del campo del iproduct que entrega el Device Descriptor. Todos los campos que son del 1 El texto por defecto es UNICODE pero es configurable a otros tipos de textos. 63

64 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL tipo index son los campos que comienzan con la letra i 1. Si el valor del index es distinto de cero significa que trae información consultable a través del String Descriptor. Para consultar el String Descriptor en el controlador SL811HS, se realiza con la siguiente función: Get_DescriptorString(BYTE adress, BYTE index, char *ptr); El parámetro adress indica la dirección del dispositivo, por su parte index especifica lo que se va a consultar. A diferencia de los demás descriptores, este descriptor no tiene una estructura fija, es decir, no tiene un tamaño único pues los datos que entregan los dispositivos es variable desde 0 a 255 bytes. Código de ejemplo: char temp[255]; Get_DescriptorString(0x01,Device_Descriptor.iProduct, temp); En el código de ejemplo se puede observar que se está consultando por el nombre del producto del dispositivo. El dispositivo está conectado en la dirección 1 del controlador. El resultado obtenido es puesto en temp y es mostrado en la figura 3.9. Figura 3.9: Nombre del producto de un dispositivo usando el SL811HS. El resultado obtenido corresponde al mismo que muestra Windows en su barra de inicio (Netscroll) Construcción de las peticiones Las peticiones van en un paquete de 8 bytes denominado Setup Packet. Es el host el encargado de entregar este paquete al dispositivo. El Setup Packet a su vez se 1 Los campos tipo id no son válidos. 64

65 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL compone de 5 campos tal como se muestra en el cuadro 3.7. Cada uno de los campos es de tamaño de 1 ó 2 bytes, donde algunos son configuraciones bit a bit. Los valores de los campos del Setup Packet son siempre fijos para cada una de las peticiones estándar establecido por USB-IF en el capítulo 9 del protocolo USB. Posición Nombre Bytes Descripción 0 bmrequesttype 1 fija la dirección de la transferencia 1 brequest 1 valores de 0 a 12, según se la petición. 2 wvalue 2 varía según la petición 4 windex 2 varía según la petición 6 wlength 2 cantidad de bytes a transferir Cuadro 3.7: Campos del Setup Packet. Se construyó una función que enviará el Setup Packet y retornará los resultados en un puntero. La función construida se muestra a continuación: int Request(BYTE bmrequesttype, BYTE brequest, WORD wvalue, WORD windex, WORD wlength, BYTE adress, char *ptr ) La función Request() es la base de la construcción de las peticiones que se han expuesto en este capítulo. En ella se le ingresan los cinco campos del Setup Packet en conjunto con la dirección del dispositivo. La función retorna el valor 1 cuando la petición que se solicitó existe, de lo contrario, retorna el valor 0. La función Request() permite experimentar con los valores cuando los documentos oficiales proporcionado por USB-IF no son claros para el relleno del Setup Packet. Los documentos de clases entregan los valores de los campos de una forma más precisa para las peticiones de clases. En el Apéndice D se encuentran los detalles de la construcción de la función Request(), para así construir nuevas peticiones Configuración de un dispositivo cualquiera Como se dijo al principio de este capítulo, la configuración de cualquier dispositivo USB es por medio de una serie de pasos llamado Bus enumeración. Los pasos para el SL811HS son los siguientes: 65

66 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Detección de Velocidad Get Descriptor (Device) Get Descriptor (Configuración) Get Descriptor (Interface) Get Descriptor (Endpoint) Set Adress Set Configuration Get Configuration El primer paso corresponde a la detección de la velocidad del dispositivo, y es realizado por el host (SL811HS) sin hacer ningún tipo de comunicación directa con el dispositivo, pues es un juego de las señales en conjunto con el manejo de los registros de configuración. El resto de los pasos son descriptores y peticiones que necesitan una comunicación del tipo Control y fueron analizados anteriormente. Entre cada paso que se realiza en el Bus Enumeración, hay tomas de decisiones entre los descriptores a través de las estructuras de los campos, esto lleva a la dependencia de los resultados. Es por eso que esta serie de pasos tienen un orden que hay que respetar. No es sólo para el caso del host controlador SL811HS, sino también, para todos los sistemas operativos que manejan USB. El sistema operativo Windows al realizar la Bus Enumeración agrega la petición del tipo string para utilizar el nombre del equipo y así mostrar al usuario lo que se está configurando en ese momento. Se desarrolló una función estricta y segura para la realización de la Bus Enumeración. La función que reúne a todos los pasos y carga los descriptores es la función Bus Enumeracion(). El código es mostrado a continuación: int Bus_Enumeracion(BYTE direccion) { if( detectar_velocidad() ==0) //si no hay dispositivo conectado retorna return 0; else { //sólo si hay algún dispositivo conectado. Get_DescriptorDevice(0x00); Get_DescriptorConfig(0x00); Get_DescriptorInterf(0x00); Get_DescriptorEndpoint(0x0); Set_Adress(direccion); Set_Configuration(direccion,Config_Descriptor.bConfigurationValue); //comprobación del dispositivo configurado if (Get_Configuration(direccion) == Config_Descriptor.bConfigurationValue) { SEND_CMD(LINE2); 66

67 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL printf("disp. Configurado"); return 1; // éxito } else { SEND_CMD(LINE2); printf("disp. No Configurado"); return 0; } } } En caso de no detectar un dispositivo o no comprobar el estado de la configuración, la función Bus Enumeracion() retorna un 0 y en caso de éxito la función retorna el valor 1. Con la presencia de un hub, los pasos nombrados anteriormente también cumplen con el objetivo de asignarle una dirección, ya que el hub es un dispositivo USB como otro más. La diferencia radica en que una vez que el hub termina de ser configurado, se deben construir nuevas peticiones definidas especialmente para el hub, las cuales se pueden construir con la función Request(). Estas nuevas peticiones sirven para el control y monitoreo de los puertos. Con la construcción de las peticiones y la función Bus Enumeracion(), la parte principal del programa solamente tendría unos pocos pasos para la configuración inicial de un dispositivo. El código siguiente muestra como sería la configuración de un equipo USB #include <stdio.h> /* For printf(). */ #include <msp430x16x.h> #include "LCD_4.inc" #include "minhost.c" #include "peticiones.c" /* */ int main(void) { Init_Osc_X2(); Init_LCD(); Delayx100us(5000); USB_init(); //inicialización del SL811HS Delayx100us(5000); Bus_Enumeracion(0x01); //bus enumeración dirección 1. } Se debe subrayar que algunos dispositivos como los de almacenamiento masivo que traen incorporado reproductores de mp3 y otras funciones (display y radio), pueden afectar de tal manera que no se configure el dispositivo. Esto porque algunos de ellos se encienden de forma más lenta que otros, causando que las peticiones no respondan. Las peticiones son válidas en un cierto tiempo que el host tolera. Sobrepasar ese tiempo involucra que las peticiones se pierdan y el host responda con un timeout. La colocación de tiempos grandes antes de hacer las peticiones evita problemas de esa indole. La figura 3.10 muestra como 67

68 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL se verá la pantalla luego de realizar un bus enumeración en el SL811HS de forma exitosa 1. Figura 3.10: Visualización de la pantalla después de usar Bus Enumeración Programas para los descriptores Unas de la maneras de comprobar los descriptores es por medio de programas especializados. Los programas para diseño USB pueden ser herramientas muy útiles en el principio del diseño de drivers, pues se debe estar seguro que los descriptores obtenidos son los correctos y así descartar algún tipo de error en la construcción de ellos. Poner datos erróneos en los drivers, ya sea como el asignar una dirección de un endpoint no válido, lleva a que los dispositivos nunca realicen sus funciones USBview Hay muchos programas que muestran de manera didáctica los descriptores, pero en su mayoría son limitados hasta que no se pague por el precio del programa. Sin embargo, el programa más simple, liviano y gratis es el que en un principio dispuso USB-IF en su página oficial llamado USBview (figura 3.11). Sin embargo, actualmente el programa se encuentra no disponible en su web. En la presente memoria se incluye USBview para su utilización. En un principio, el programa USBview muestra todos los Root Hub que se encuentra en el computador. Para un óptimo resultado se debe tener marcada las opciones mostradas en la figura De esta manera el detalle de los descriptores será mejor. La figura 3.14 muestra el listado de los descriptores utilizando USBview. 1 La implementación de la pantalla no es requisito para utilizar las peticiones, sólo bastara con desactivar las funciones printf(). 68

69 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Figura 3.11: USBview mostrando los dispositivos conectados. Figura 3.12: USBview mostrando los descriptores USBCommandVerifer Otro programa de uso libre que dispone USB-IF es USBCommandVerifer (figura 3.13). El programa tiene varias herramientas donde la más importante es verificar que las peticiones que están estipuladas en el capítulo 9 del protocolo USB están bien establecidas en el dispositivo y pueden ser solicitadas. También tiene otras funciones como por ejemplo: verificar si un dispositivo USB 2.0 puede funcionar en un host USB 1.1, test para dispositivos de interfaz humana y test para Hub. 69

70 CAPÍTULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACIÓN GENERAL Figura 3.13: USBcommandVerifer Hardware Existe Hardware especializado de gran costo que sirve para monitorear el tráfico USB (sniffer). La ventaja de estos instrumentos es que pueden capturar todo el tráfico incluyendo cuando se produce la enumeración del bus, cosa que los programas en su mayoría no pueden hacer. La captura de datos puede facilitar la construcción de funciones y drivers especializados como también facilitar el aprendizaje del protocolo USB. Uno de los hardware más usado por su menor costo es Usbviewer 1 cuyo valor es cercano a los US$1000. Figura 3.14: Conexión de un sniffer para la captura de datos. 1 El producto se puede ubicar en la página Web: 70

71 Capítulo 4 Dispositivos de interfaz humana Este capítulo describe al grupo de dispositivos que pertenece a la clase de interfaz humana, detallando la comunicación y su forma de entregar los datos al host. Se explican los descriptores standard y especiales para esta clase, mostrando ejemplos reales de dispositivos encuestados. Se establece cómo se debe reconocer los dispositivos de esta clase y cuáles son los pasos a seguir para su eventual configuración. Finalmente se muestra una aplicación con los dispositivos HID HID Human Interface Device (HID) es la clase de dispositivo más popular entre los usuarios de computadores. La razón radica en que esta clase define y clasifica principalmente a dispositivos que son utilizados en una forma directa por las personas, con el objetivo de interactuar y dar órdenes al computador. También otro factor que ha influido en la masificación de los productos, es su bajo costo de elaboración. Por su parte, el sistema operativo Windows fue el pionero (1995) en incorporar los drivers para el soporte USB-HID, a través de su sistema operativo Windows95b Tipos de dispositivos Estos dispositivos en su mayoría funcionan al tacto, movimientos, presiones y fuerzas, lo que hace que casi siempre depende de las órdenes del usuario, sin embargo esta clase incorpora en una gran mayoría a los dispositivos de baja velocidad de transmisión (lowspeed), donde es común encontrar dispositivos que no necesariamente interactúan de una forma directa con las personas como se dijo inicialmente, sino más bien, son dispositivos que cuya misión es informar como es el caso de los lectores de código de barra. Los dispositivos de interfaz humana que necesitan estar en tiempo real, donde tienen requisitos como estar en una constante retroalimentación de datos con el host, son clasificados en otra clase llamada PID (Physical Interface Device) como es el caso de algunos 71

72 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA controles de juego avanzados que no pertenecen a la clase HID. También es el caso de dispositivos como cámaras Webs o cámaras fotográficas que suelen confundirse con dispositivos de clase HID, ellos pertenecen a la clase llamada imagen class. Los ejemplos más típicos de la clase HID son: Teclados, apuntadores, mouses, joysticks y trackballs. Paneles de controles tales como: tabletas gráficas, sliders, botones, controles remotos, pedales. Algunos dispositivos de audio como: teléfonos, micrófonos o altavoces digitales, etc. Dispositivos que no requieren de una intervención humana pero comparten la misma clase como por ejemplo: lectores de códigos de barras, voltímetros, termómetros, linternas, ventiladores, etc. En la clase HID es considerable destacar que dada su versatilidad, un dispositivo compuesto puede llevar incluido en su composición física un dispositivo de clase HID. Es el caso de los teléfonos que perteneciendo a la clase de audio, tienen incorporado parte de una interfaz humana en los botones u otras funcionalidades añadidas al teléfono Pipes de la Clase HID La clase HID sólo se puede comunicar a través dos pipes, tal como lo muestra la figura 4.1. Figura 4.1: Pipes de la clase HID. La primera comunicación por defecto y además de carácter obligatorio de tener por parte de los dispositivos de clase HID, es la pipe de Control. Esta pipe, como se discutió en el primer capítulo, es bi-direccional y corresponde al endpoint-0. Se utiliza básicamente para recibir y responder las peticiones de configuración del dispositivo USB-HID. De esta manera, se intercambian en una etapa inicial los datos necesarios para el reconocimiento del dispositivo, usando los Descriptores y Peticiones Standard. 72

73 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA El otro tipo de comunicación que se encuentra, corresponde a la pipe del tipo Interrupt. Ésta atiende, por medio de su endpoint, la recepción y envío asíncrona de los datos. En el caso de la comunicación de la clase HID se tiene la particularidad que en la mayoría de los dispositivos el flujo de datos se hace en una sola dirección (IN), donde prácticamente es muy difícil encontrar dispositivos que tengan incorporado un endpoint Interrupt del tipo OUT. Esto es porque en la clase HID el endpoint OUT es totalmente opcional. El cuadro 4.1 muestra un resumen de la comunicación en la clase HID. Pipe Descripción Requerido Control USB control, peticiones, descriptores si Interrupt In datos de entrada, esto es desde el device al host si Interrupt Out datos de salida, esto es desde el host al device opcional Cuadro 4.1: Resumen de la comunicación HID Identificación Para la identificación de la clase HID y especificar el dispositivo que se encuentra conectado al controlador, se realiza la comprobación de los siguiente tres campos: binterfaceclass, binterfacesubclass, binterfaceprotocol. Estos campos definen la clase, subclase y protocolo respectivamente. Los tres campos pertenecen a la petición Interface Descriptor Clases La especificación USB define a la clase HID con el valor 0x03 para el campo binterfaceclass, de esta manera todos los dispositivos que cumplan con las características y configuraciones de la clase HID deberán tener el valor mencionado para el campo Subclases El cuadro 4.2 muestra los valores posibles para el campo binterfacesubclass. El valor 1 para la subclase define la capacidad de los dispositivos para funcionar en el arranque y Bios, de lo contrario el valor para el campo binterfacesubclass es de 0. Hoy en día la mayoría de los teclados USB tienen soporte para BIOS, pero no es así para los dispositivos como mouse y joystick. 73

74 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA binterfacesubclass Descripción 0 sin subclase 1 boot interface reservado Cuadro 4.2: Códigos de Subclases Protocolos El valor del campo (binterfaceprotocol) pueden llevar tres valores y es mostrado en el cuadro 4.3. Los valores definen finalmente si el dispositivo es un mouse o teclado. Es importante resaltar que USB-IF no define valores de protocolos para otros productos populares como es el joystick. La razón de ello radica en que cada fabricante de productos HID, en donde no tienen un comportamiento standard (como el joystick), definen a través de una tabla llamada Report las características del dispositivo como por ejemplo: números de botones, movimientos, fuerzas ejercidas, etc. No es el caso de los teclados y mouses que poseen un funcionamiento con un número de botones fijos. binterfaceprotocol Descripción 0 específico 1 teclado 2 mouse reservado Cuadro 4.3: Códigos de protocolos. En resumen, para la identificación de un dispositivo HID se debe consultar por la función Get DescriptorInterf() que llama a la petición solicitando los los descriptores del tipo Interface. Cuando se solicita la función Bus Enumeracion() se cargarán automáticamente todos los descriptores y no será necesario ejecutar la función Get DescriptorInterf(). La estructura donde se guardan los datos de la Interface es Interface Descriptor Descriptores de clase Como se muestra en la figura 4.2, en los dispositivos de clase HID se encuentran los descriptores Standard y descriptores del tipo String discutido ampliamente en el capítulo 3. También se encuentran los descriptores de clase HID que son únicamente de esta clase. Los descriptores de clase son: HID Descriptor, Report Descriptor y Physical Descriptor, los cuales están dentro del descriptor Interface. Si bien es importante saber el detalle y funcionamiento de cada descriptor de la clase HID, la información que entrega cada uno de los descriptores de clase, no influye en la 1 Para mayor detalles se puede consultar en la presente memoria por el capítulo 3, sección de descriptores. 74

75 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA Figura 4.2: Descriptores de la clase HID. configuración general de un dispositivo de clase HID tales como teclados y mouse. Sin embargo, para dispositivos desconocidos para el host (dispositivo especial) y que forman parte de esta clase (HID), la información entregada por los descriptores es de gran importancia para el fruncimiento HID Descriptor La estructura de HID Descriptor se muestra en el cuadro 4.4: Campo Tamaño Descripción Ejemplo blength 1 tamaño del descriptor en bytes 0x0B ó 0x09 bdescriptortype 1 constante HID 0x21 bcdhid 2 especificación de la clase 0x0110 bcountrycode 1 número que especifica el país 0x00 bnumdescriptors 1 número de descriptores de la clase 0x02 bdescriptortype2 1 código del primer descriptor 0x22 witemlength2 2 largo del descriptor 0x0040 bdescriptortype3 1 código del tercer descriptor 0x00 witemlength3 2 largo del tercer descriptor 0x0000 Cuadro 4.4: Estructura del HID Descriptor. HID Descriptor es una estructura fija que puede ser de 9 ó 11 campos, donde su código de identificación es 0x21 (bdescriptortype). HID Descriptor es la cabecera de los demás 75

76 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA descriptores de la clase, donde la función principal es informar la existencia o no de los otros dos descriptores de la clase. Como se dijo en el capítulo anterior, cuando se solicita una petición y no concuerda el largo exacto del descriptor que se está solicitando, se produce un error de comando. Es por eso que el HID Descriptor junto con entregar la existencia o no de los descriptores, entrega además, el largo exacto de los otros dos descriptores, pues como se verá más adelante, los otros dos descriptores de la clase son estructuras no fijas y varían de un dispositivo a otro. El tercer descriptor (bdescriptortype3 ) puede tener el valor cero, indicando que no existe el descriptor. Los códigos para identificar los descriptores se muestra en el cuadro 4.5. bdescriptortype 0x21 0x22 0x23 0x24 Clase Descriptor HID Report Physical Descriptor Reservado Cuadro 4.5: Descriptores especiales para la clase HID. Para solicitar el HID Descriptor se construyó la función Get DescriptorHID() utilizando la función base Request() que permite enviar el Setup Packet. Un resultado obtenido al ejecutar la función Get DescriptorHID() conectando un mouse genérico al puerto SL811HS se muestra en la figura 4.3: Figura 4.3: HID Descriptor. Se observa en la figura 4.3 que sólo existe un descriptor adicional (0x22), el cual corresponde al descriptor llamado Report Descriptor. Por otro lado, el valor del campo bcdhid indica la versión de la clase USB del dispositivo. El valor corresponde justamente a la última versión que es HID

77 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA Report Descriptor Report Descriptor entrega una tabla que describe cada pieza del dispositivo que genera datos. Por ejemplo un Report Descriptor define items en un mouse como la posición y botones, a su vez determina cuanto esfuerzo hay que aplicar para que el dispositivo genere los datos mínimos y máximos. Debido a esto, la estructura del Report Descriptor es variable y lleva a realizar una función en donde la captura de los reportes sea en un arreglo temporal. La función que solicita el Report Descriptor es la siguiente: int Get_DescriptorReport(BYTE adress, char *ptr) La petición se realiza en forma directa a través de la función Request(), pero previamente se solicita el HID Descriptor de manera de asegurar que los campos del HID Descriptor se carguen y así funcione correctamente el Report Descriptor. La figura 4.4 muestra los datos obtenidos de un mouse genérico. La interpretación se debe realizar leyendo cada 1, 2 ó 3 bytes, donde existe un significado para cada caso. Por ejemplo el primer par de bytes mostrando en la figura 4.4 es 0501 y su significado es indicar que el dispositivo es de un formato conocido (genérico). Para el segundo par (0902) su significado es indicar que el dispositivo genérico es un mouse. La interpretación de cada valor es bastante extensa, pero para los dispositivos conocidos mayormente no influye. Para los valores de los reportes se puede consultar los documentos oficiales Device Class Definition for Human Interface Devices (HID 1.1) y HID Usage Tables 1.12, descargables de la página En los documentos se pueden encontrar tablas genéricas para los dispositivos más usados de la clase HID. Figura 4.4: Tabla de reportes. 77

78 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA Los reportes resultan algo engorroso de utilizar para los que realizan dispositivos específicos de la clase HID. Sin embargo, se disponen de herramientas que facilitan la construcción de las tablas de reportes. Una herramienta muy utilizada es HID descriptor Tool, donde de una manera más fácil se van agregando botones, movimientos, rangos, etc., y de esta manera se va llenando automáticamente la tabla de reportes. La figura 4.5 muestra la herramienta nombrada anteriormente, en donde se configura la tabla de reportes para un mouse. Figura 4.5: Software HID Descriptor Tool Physical Descriptor Es un descriptor opcional el cual provee información sobre que parte del cuerpo humano es usado para activar los controles. Al igual que en el caso anterior se pueden consultar por las tablas entregadas por USB-IF en los mismos documentos, pero su implementación no es vital para el funcionamiento de dispositivos standard o desconocidos. La función para acceder al Physical Descriptor se muestra a continuación: int Get_DescriptorPhysical(unsigned int adress, char *ptr) En los diferentes dispositivos de clase HID que se conectaron al controlador SL811HS, no se encontraron registro alguno del Physical Descriptor. Saber que parte del cuerpo humano 78

79 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA es la que controla al dispositivo, no influye en el funcionamiento general del dispositivo Recibimientos de los datos en un dispositivo HID Los datos entregados por los dispositivos HID, como al apretar un botón o una tecla, son enviados a través de los endpoint que especifica el fabricante del dispositivo. Generalmente los dispositivos HID traen un sólo endpoint del tipo Interrupt. La cantidad máxima de datos que pueden enviar los dispositivos low-speed es de 8 bytes. Los teclados ocupan los 8 bytes para transmitir los datos al host, en cambio el mouse sólo ocupa 4 bytes. Por otra parte, es deber del host preguntar por las interrupciones generadas por los dispositivos, en el tiempo que lo estipula en campo binterval del Endpoint Descriptor. Pasado ese tiempo, implicaría que se perdieran los datos de las interrupciones siempre y cuando el usuario produzca una nueva interrupción. La función RecibirInt() permite preguntar si hay datos que el dispositivo desea enviar (interrupción de un dispositivo) y posteriormente recibir los datos del dispositivo. RecibirInt() funciona indistintamente de la cantidad de bytes que el dispositivo desea enviar, pues se usa un buffer de recepción de 8 bytes (línea 5 del código). La función RecibirInt() tiene 3 parámetros de entradas: adress indica la dirección del dispositivo, endpointhid corresponde al endpoint que va a trasmitir los datos y ptr el puntero que indicará la dirección de memoria para guardar los datos. Si no hay datos en el endpoint, la función RecibirInt() retorna el valor 0, por el contrario en caso de recibir datos la función retorna el valor 1. El código de la función RecibirInt() se muestra a continuación: int RecibirInt(BYTE adress, char endpointhid, char *ptr) { BuffClear811(0x10,8); //borra basura del buffer wr811(fnaddr,adress); //direccion del dispositivo wr811(bufadr,0x10) ; // inicio de los datos de llegada. wr811(buflen,0x08) ; //en low mode, los paquetes son de 8 bytes wr811(pid_ep,in_pid endpointhid); // paquetes tipo IN result=go(0x03); // enviar comando, DIREC=0(in), ENAB=1, ARM=1 if (result & 0x01) // ACK si se reciben datos { BuffRead811(0x10, ptr, 8); // copia los datos llegados. return 1; //retorna indicado datos positivo } else return 0; //no hay datos } En el main() principal del programa, mostrado a continuación de este párrafo, se muestra una rutina para configurar y preguntar por las interrupciones de los dispositivos de clase HID. Desde la línea 1 a 12 del código, es la parte en donde se inicializa el controlador y se asigna una dirección al dispositivo USB (dirección número 5). Las líneas 14, 15 y 16 rescatan en variables más didácticas, los valores esenciales para el funcionamiento del dispositivo, que corresponden a la clase, protocolo y endpoint del dispositivo. A continuación, se verifica que la clase obtenida pertenece a clase HID (valor 0x03) y luego se ejecuta la 79

80 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA función RecibirInt(). En caso de haber datos, la rutina despliega un mensaje en la pantalla LCD, dependiendo si que el dispositivo que realizó la interrupción fue un mouse o un teclado int main(void) { char temp[8]; //temporal para recibir los datos, debe ser 8. BYTE clase, protocol, endinter, direccion; Init_Osc_X2(); Init_LCD(); Delayx100us(5000); USB_init(); Delayx100us(5000); direccion=0x05; // dirección a asignar al dispositivo. Bus_Enumeracion(direccion); //bus enumeración clase =Interface_Descriptor[0].bInterfaceClass ; protocol =Interface_Descriptor[0].bInterfaceProtocol; endinter =Endpoint_Descriptor[0].bEndpointAddress ; if (clase==0x03) //si es de clase HID. { while(1) { if ( RecibirInt(direccion,endInter,temp) ) //si hay datos 1. { if(protocol==1) // si es teclado. printf("teclado interrupcion"); //función del usuario if(protocol==2) //si es mouse. printf("mouse interrupcion"); //función del usuario } } } } 4.7. Configuración de un Mouse Son 4 bytes para representar los movimientos y botones de un mouse. El primer byte (byte0) sirve para representar a todos los botones del mouse, generando un valor único para cada botón, tal como se muestra en el cuadro 4.6. Para los casos en que se presionan botones al mismo tiempo, el valor generado para el byte0 es la respectiva suma de los valores de cada botón que se presionó. Por ejemplo al presionar al mismo tiempo el botón izquierdo (0x01) con el botón derecho (0x02), el valor para el byte0 es de 0x03. Cuando se realiza un click en un botón, este genera dos interrupciones: la primera es producida cuando el botón se presiona y es mantenido en la posición, entregando el valor correspondiente al botón; la segunda interrupción es producida al momento de soltar el botón, generando el valor 0x00 para el byte0. 80

81 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA Botón (Byte 0) Izquierdo Derecho Medio Valor 0x01 0x02 0x04 Cuadro 4.6: Valores para los botones del mouse. Para el movimiento del cursor, se usa un byte para cada eje de coordenadas: el byte1 es para el eje-x, el byte2 para el eje-y y el byte3 representa al movimiento del roller que es utilizado para avanzar y retroceder páginas. Para diferenciar movimientos positivos y negativos se divide cada byte en dos partes iguales (cuadro 4.7). Movimiento x + x- y+ y- roller+ roller- Byte Valor 1 a a a a a a 129 Cuadro 4.7: Valores para el movimiento del mouse. La velocidad del cursor es proporcional al valor que se reciba como dato en el byte, por ejemplo movimientos muy lentos en el eje x+ significarán valores entre 1 a 10 en el byte1, de igual manera movimientos muy lentos en el eje x- significarán valores desde 255 a 240. Sin embargo, el movimiento del mouse puede pasar por todos los valores, ya que la acción completa para acceder a un objeto en la pantalla, pasa desde un movimiento inicial del tipo brusco, finalizando en un movimiento lento. Caso especial es el movimiento del roller, en donde en su mayoría son movimientos del tipo lento, principalmente porque se requieren que los movimientos sean de esa manera y además porque el desplazamiento se realiza a través de los dedos. Se puede emular el movimiento del eje-x de un mouse utilizando una pantalla LCD de 4 líneas. Para ello se realizó una sencilla función llamada MouseX(): Código: void MouseX(BYTE val) { if(val>=5 && val<=105) { SEND_CMD(Display_and_Cursor+Display_On+Cursor_On+Blink_On); SEND_CMD(Set_Shift+Shift_Cursor+Right); Delayx100us(2000); } if (val<=250 && val>=150 ) { SEND_CMD(Display_and_Cursor+Display_On+Cursor_On+Blink_On); SEND_CMD(Set_Shift+Shift_Cursor+Left); Delayx100us(2000); } Delayx100us(1000); } 81

82 CAPÍTULO 4. DISPOSITIVOS DE INTERFAZ HUMANA En la rutina MouseX(), primero se fija los rangos en el cual se aceptan movimientos válidos para x- y x+, descartando valores pequeños y valores grandes. Cada vez que se entre en el rango establecido se activa el cursor y el parpadeo (Cursor On+Blink On) de manera de visualizar el movimiento en la pantalla. Luego se procede a realizar el corrimiento del cursor según sea el caso (Right o Left). Un movimiento simple y corto del mouse puede provocar decenas de interrupciones dependiendo del tiempo que destine el host para preguntar por las interrupciones, pero por lo general puede provocar que el cursor se pierda en la pantalla LCD y no se logre seguir el cursor con la vista, principalmente porque la pantalla tiene 30 caracteres por línea, que equivaldrían a 30 movimiento de cursor por línea. El problema anterior se solucionó introduciendo retardos de manera de perder algunas interrupciones por tiempo y así demorar el movimiento en la pantalla. En el main() principal del programa, se debe pasar el valor que representa al movimiento en el eje-x (byte1 o temp[1]) a la función mousex(). El siguiente código ilustra la función completa int main(void) { char temp[8]; //temporal para recibir los datos, debe ser 8. BYTE clase, protocol, endinter, direccion; Init_Osc_X2(); Init_LCD(); Delayx100us(5000); USB_init(); Delayx100us(5000); direccion=0x05; // dirección a asignar al dispositivo. Bus_Enumeracion(direccion); //bus enumeración clase =Interface_Descriptor[0].bInterfaceClass ; protocol =Interface_Descriptor[0].bInterfaceProtocol; endinter =Endpoint_Descriptor[0].bEndpointAddress ; if (clase==0x03) //si es de clase HID. { while(1) { if ( RecibirInt(direccion,endInter,temp) ) //si hay datos 1. { if(protocol==1) // si es teclado. printf("teclado interrupcion"); if(protocol==2) //si es un mouse. MouseX(temp[1]); //temp[1]=eje x. } } } } 82

83 Capítulo 5 Dispositivos de almacenamiento masivo Este capítulo describe la clase Mass Store Device, donde el principal objetivo de análisis son los dispositivos llamados pendrives. Además, se estudia y desarrolla el protocolo de comandos Bulk-Only que permite encapsular los comandos SCSI para así realizar la lectura y escritura de archivos. También se explica el sistema de estructura FAT16 que distribuye las particiones y los archivos en memoria Mass Store Device La clase Mass Store Device (MSD) corresponde a los dispositivos que tienen la capacidad de almacenar y transportar datos. Los dispositivos típicos que se pueden encontrar en esta clase son: diskette, discos duros, CD-ROM, DVD y pendrives. Sin embargo, el dispositivo que más comúnmente es usado por el usuario es el pendrive. En un principio los pendrives sólo fueron diseñados para que cumplieran la función de almacenar y transportar datos, teniendo la gran ventaja con respecto a los diskette: la velocidad y capacidad de almacenamiento. Actualmente el mercado ofrece pendrives con incorporación de radio, mp3, teléfono y video, lo que ha hecho que la utilización de los pendrives reemplace en gran medida a los diskettes. Hoy en día, los nuevos computadores que salen al mercado están suprimiendo el uso de las disketeras 1, incorporando ranuras para conectar directamente memorias flash y pendrives. Un pendrive básico, tal como se muestra en la figura 5.1, internamente se compone de: varios chip de memoria flash, un controlador de memoria y un interfaz USB. Con estos tres componentes los dispositivos emulan el comportamiento de un disco magnético. Por su parte, la memoria de datos de los pendrives se asocia a sectores de 512 bytes (bloques), leyendo y escribiendo datos únicamente de esta manera. 1 Las nuevas placas madres, soportan que los pendrives tengan la capacidad de ser booteable o cargar un sistema operativo. 83

84 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.1: Estructura interna de los pendrives Reconocimiento de un dispositivo MSD Los dispositivos de la clase MSD se identifican al igual que otros dispositivos USB, esto es a través de los campos binterfaceclass, binterfacesubclass y binterfaceprotocol. Los tres campos mencionados pertenecen al Interface Descriptor Clase El campo binterfaceclass devuelve el valor 0x08, lo cual aclara que el dispositivo es de la clase Mass Store Device Subclase Código Juego de comandos Comentarios 01h Reduced Block Commands (RBC). T10 Project 1240-D normalmente utilizado por memorias Flash aunque cualquier dispositivo de almacenamiento masivo puede utilizarlo 02h SFF-8020i, MMC-2 normalmente utilizado por CD y DVD 03h QIC-157 normalmente utilizado por unidades de cinta 04h UFI normalmente usado por unidades de diskette 05h SFF-8070i normalmente utilizado por disquete, aunque también puede utilizar otra subclase (como RBC) 06h SCSI-2 cualquier dispositivo de almacenamiento masivo puede utilizar esta subclase 07h-FFh reservados para uso futuro Cuadro 5.1: Código de subclase para Mass Store Device. El campo binterfacesubclass entrega distintos valores para los dispositivos de la clase MSD (cuadro 5.1). Los distintos valores sirven para identificar el tipo de juego de comandos que soporta la interfaz. El cuadro 5.1 muestra los códigos y utilización para el campo 1 Para mayor información sobre los descriptores, dirigirse al capítulo 3. 84

85 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO subclase. Los pendrives utilizan los juegos de comandos SCSI-2 que corresponde al valor 06h del campo binterfacesubclass. Actualmente USB-IF está intentando unificar todos los dispositivos con los comandos UFI (Floppy Disk Unit), publicado en el documento oficial Universal Serial Bus Mass Storage Class - UFI Command Specification 1. El documento sirve para consultar por los comandos SCSI-2 ya que UFI tienen como base a los comandos SCSI-2 y SFF-8070i Protocolo El campo binterfaceprotocol devuelve un valor para indicar la manera como se transporta el juego de comandos. Esto se refiere a como se emplean las transferencias en el protocolo USB (Control, Bulk, Interrupt, Isochronous). Los valores son mostrados en la cuadro 5.2. Código 00h 01h 50h 02-4Fh 51h-FFh Protocolo de Transporte de comandos CBI con interrupción de fin de comando CBI sin interrupción de fin de comando Bulk-Only reservado reservado Cuadro 5.2: Código de protocolo para Mass Store Device. El protocolo de transporte de comandos CBI (Control, Bulk, Interrupt) fue el que en un principio se utilizó en los pendrives con capacidad de memoria no superior a 64MB. CBI utiliza tres endpoint para las transferencias de los comandos y datos, produciendo ineficiencias en los dispositivos de gran tamaño y capaces de soportar high-speed. El uso de CBI para cualquier diseño de pendrives fue descartado y puesto por USB-IF en calidad de obsoleto. Hoy en día se utiliza el protocolo de transporte Bulk-Only que es más simple para la comunicación, pues sólo utiliza los endpoint del tipo Bulk. En el cuadro 5.3 se muestra el Interface Descriptor de cuatro diferentes pendrives. Las diferencias entre los dispositivos son tanto en tamaño, velocidad y modelo de fábrica. Los datos fueron obtenidos por medio de la función Bus Enumeracion() 2 conectando los dispositivos al puerto USB del SL811HS. Como se observa en el cuadro 5.3 los valores de los campos no varían de un modelo a otro. Además se observa que la cantidad de endpoint de cada dispositivo es 2, ya que necesita un endpoint para datos de entrada y un endpoint para datos de salida. 1 El documento se encuentra en el CD-ROM adjunto al trabajo, Documentos/usborg/usbmass-ufi10.pdf o en 2 La función Bus Enumeracion() carga todos los descriptores en sus respectivas estructuras, tal como lo señala el capítulo 3 de la presente memoria. 85

86 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Campos Creative 1GB PackerBell 256MB Kingston 256MB I-storage 128MB números de 0x00 0x00 0x00 0x00 interfaces alternativas 0x00 0x00 0x00 0x00 sentencias números de 0x02 0x02 0x02 0x02 endpoint clase 0x08 0x08 0x08 0x08 subclase 0x06 0x06 0x06 0x06 protocolo 0x50 0x50 0x50 0x50 interface 0x00 0x00 0x00 0x00 Cuadro 5.3: Interface Descriptor para distintos pendrives Peticiones de clase El protocolo de transporte Bulk-Only define dos peticiones específicas que deben soportar los dispositivos de la clase MSD, éstas son: Bulk-Only Mass Storage Reset y Get Max LUN Bulk-Only Mass Storage Reset El objetivo de la petición es aplicar un reset al dispositivo MSD. Así el dispositivo se prepara para recibir el juego de comandos que tiene especificado (SCSI-2 para los pendrives). La petición no retorna ningún dato. La función para acceder a esta petición es la siguiente: MassStorageReset(BYTE adress, BYTE interface) El parámetro adress indica la dirección del dispositivo y el parámetro interface corresponde al valor que entrega el campo bnuminterfaces (interface que se escogió para el dispositivo) Get Max LUN La petición especial Get Max LUN se usa para determinar el número de unidades lógicas soportadas por el dispositivo. Es posible que un dispositivo pueda tener varias unidades lógicas. Las unidades lógicas del dispositivo son enumeradas contiguamente a partir de LUN 0 hasta LUN 15 (Fh). Como se verá posteriormente, el host usa el comando encapsulado 86

87 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO bcbwlun (Command Block Wrapper) para elegir a que unidad lógica será enviado el paquete. Por lo general los pendrives sólo tienen una unidad lógica disponible. Solicitando la petición Get Max LUN el dispositivo devolverá un byte de datos con el máximo LUN (unidades lógicas) soportado. Por ejemplo, si el dispositivo soporta cuatro LUNs entonces el valor de retorno sería 3. Si ningún LUN es asociado con el dispositivo, entonces el valor retornado será 0 (1 partición). En caso que se envíe un paquete a una unidad lógica que no exista, el dispositivo responderá con un STALL. La función construida para acceder a la petición Get Max LUN es la siguiente: GetMaxLUN(BYTE adress, BYTE interface) 5.4. Protocolo de transporte Bulk-Only El protocolo Bulk-Only 1 es el encargado de transportar los datos y estados de un dispositivo de almacenamiento masivo cualquiera. Esto se hace exclusivamente a través de las transferencias tipo Bulk Transferencias La figura 5.2 muestra el flujo de las transferencias de datos en el protocolo Bulk-Only. Las transferencias se realizan a través de tres bloques: Command, Data y Status Protocol. El primer bloque es llamado CBW (Command Block Wrapper), corresponde a un bloque de comando que indica la inicialización de la transferencia, especificando el tipo de operación a realizar con el dispositivo. El segundo bloque (Data) puede ser del tipo Data-IN o Data- OUT, dependiendo si la transferencia es hacia al host o hacia el dispositivo. El bloque Data corresponde a los datos reales de la transferencia. La transferencia termina con el bloque CSW (Command Status Wrapper) que contiene la información del estado de la transferencia. CSW tiene un estructura similar a CBW y ambos están encapsulado en un paquete tipo DATA, sin embargo la estructura especial y fija de los paquetes CBW y CSW permiten al controlador y al dispositivo diferenciarlos de los paquetes tipo DATA normales. Las transferencias y el uso de los comandos especiales de control (CBW) no solamente sirven para realizar una lectura o escritura en la memoria de los dispositivos, sino también, se utilizan para realizar distintas operaciones extras con los dispositivos. En general se puede decir que el uso de los comandos es para realizar la lectura, escritura y pedir información al dispositivo. 1 El documento que especifica USB-IF para el transporte Bulk-Only, se denomina Bulk-Only Transport 1.0, el cual se puede encontrar en el CD adjunto a la memoria, con el nombre usbmassbulk 10.pdf. 87

88 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.2: Flujo de datos. Por otra parte, el protocolo Bulk-Only no permite el encolado de comandos, por lo que el controlador USB no envía ningún nuevo CBW hasta no haber recibido el CSW correspondiente al último comando enviado. Tampoco se permiten transferencias bi-direccionales, por lo cual, todas las transferencias de datos entre el CBW y el CSW serán en la misma dirección, es decir todas en su momento OUT o IN Bloque CBW La estructura del CBW comienza exactamente al principio de un paquete de datos y tiene un largo de 31 bytes. Internamente CBW (figura 5.3) se compone de 7 campos, donde algunos son fijos y otros variables. Los campos del CBW se llenan previamente en el buffer (31 bytes) del SL811HS de tal manera que el comando que se desea enviar sea el correcto para establecer la comunicación con el dispositivo. Cualquier tipo de error en el llenado de los campos lleva a que la comunicación no se establezca con los dispositivos. Para la construcción de las funciones básicas con los dispositivos de almacenamiento masivo, es de vital importancia saber el detalle de los campos del bloque CBW. A continuación se detalla cada campo del bloque CBW. CBWSignature: Se trata de una firma de 4 bytes. El contenido de la firma son los caracteres ASCII 0x43-0x42-0x53-0x55 que significa USBC (USB Command, en formato little-endian). De esta manera el dispositivo identifica que el paquete que está recibiendo es el comando encapsulado CBW, para luego en un segundo paso verificar que el largo del paquete sea de longitud de 31 bytes. CBWTag: Se trata de un número asignado por el host. El dispositivo devuelve este mismo número en el paquete CSW para identificar claramente a que CBW pertenece el CSW. Debido a que sólo hay un puerto en el SL811HS, se procedió a utilizar los valores: 0x71-0x72-0x73-0x74h. 88

89 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.3: Command Block Wrapper. CBWDataTransferLength: Aquí se indica el número de datos en bytes que el controlador espera que se transfieran durante la fase de datos. Si este campo se rellena con un cero, ni el controlador ni el dispositivo envían paquetes de datos entre el CBW y el CSW. CBWFlags: En este campo se indica el sentido de las transferencias de datos (Data-Out desde controlador a dispositivo o Data-In desde dispositivo a controlador). Un valor de 0x00 indica que la transferencia es desde el dispositivo al host. Para el sentido contrario el valor del campo es de 0x80. CBWLUN: Aquí se indica a que unidad lógica va dirigido el comando. Típicamente el valor es de 0x00, pues los dispositivos como pendrives suelen tener una sola unidad lógica disponible. CBWCBLength: Aquí se indica la longitud (en bytes) del juego de comandos. En este caso correspondería a los comandos SCSI-2 (campo CBWCB). Los valores pueden variar de comando a comando, por ejemplo para un comando de lectura correspondería el valor de 0x0A bytes. CBWCB: En este campo se sitúa el comando que debe ejecutar el dispositivo. El juego de comandos soportado es indicado por el valor del campo de la subclase (Interface Descriptor). CBWCB tiene una longitud de 16 bytes, aunque el juego de comandos utilizado puede usar una menor longitud. La longitud del bloque viene especificada en el campo anterior y el dispositivo ignora los bytes sobrantes Bloque CSW La estructura del bloque CSW tiene un largo de 13 bytes (figura 5.4). 89

90 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.4: Command Status Wrapper. Cada campo tiene las siguientes características. CSWSignature: Se trata de una firma para identificar el paquete de datos como un CSW. El contenido de la firma son los caracteres ASCII 0x53-0x42-0x53-0x55 (USBS = USB Status, en formato little-endian). El controlador USB identifica que el paquete es un CSW por esta firma y porque el paquete tiene una longitud de 13 bytes. CSWTag: El dispositivo devuelve en este campo el mismo valor del campo CBWTag del CBW correspondiente. CSWDataResidue: Para transferencias de datos, el dispositivo indica aquí la diferencia entre los datos que esperaba recibir y los que realmente se han recibido o viceversa. CSWStatus: En este campo se indica si el comando se ha ejecutado correctamente o si se ha producido algún error. El host puede confirmar la causa concreta mediante los mecanismos proporcionados por el juego de comandos que se esté utilizando. Por ejemplo, si se está utilizando SCSI o ATAPI, tras un error en la ejecución de un comando el controlador puede enviar el comando Request Sense para que el dispositivo envíe el tipo de error concreto Bloques de comandos SCSI-2 En general los comandos SCSI 1 o SCSI Block Command (SBC) son una serie de instrucciones estandarizadas que permiten la interacción con los dispositivos que manejan datos. Los comandos SCSI-2 (SBC-2) son comandos reducidos, que están únicamente orientados a realizar acciones en los discos rígidos, en este caso aplicables a los pendrives. Sin embargo, existen otros comandos SCSI muy parecidos en funciones entre sí, pero orientados 1 Small Computer Systems Interface. 90

91 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO a otros dispositivos como son los comandos SBC-3 para CD-ROM y lectores de DVD. Los comandos SCSI se encuentran regulados por el comité INCITS (International Committee for Information Technology Standards) que dispone de los documentos oficiales en la página web Los bloques de comandos SCSI tienen una serie de campos que varían de comando a comando, donde deben ser llenados de acuerdo a las especificaciones. Cada comando empieza con un número llamado código de identificación, el cual permite diferenciar los comandos entre sí. También, cada comando SCSI tiene establecido una serie de campos que retornan al host. Código 0x00 0x03 0x12 0x1A 0x1E 0x25 0x28 0x2A 0x2F 0x5A Comando Test Unit Ready Request Sense Inquiry Mode Sense Prevent Allow Media Removal Read Capacity Read(10) Write(10) Verify Mode Sense Cuadro 5.4: Típicos comandos SCSI. Algunos de los típicos comandos que se pueden solicitar se muestran en el cuadro 5.4, de los cuales no todos están implementados por los fabricantes de pendrives. Esto se debe porque algunos comandos SCSI son reemplazables por las peticiones propias del protocolo USB. Otro motivo del no soporte a todos los comandos SBC-2, es porque algunos se pueden obtener por otros comandos SCSI. Es el caso del comando Read Capacity que entrega la capacidad total de memoria del pendrive, sin embargo la información también se encuentra disponible en la partición lógica de la unidad, que entrega una información más precisa con respecto al que entrega el comando Read Capacity, accesible por medio de el comando Read(10) que permite la lectura de sectores de bloques de memoria. De todas las pruebas realizadas en diferentes pendrives, se pudo constatar que todos los dispositivos soportan al menos tres comandos básicos que permiten la lectura y escritura de datos, estos son: Inquiry, Read(10) y Write(10). Estos tres comandos fueron construidos según las especificaciones, llenado los 31 bytes del bloque de comando CBW que envía la petición de comando SCSI Inquiry El comando Inquiry entrega información más precisa sobre el dispositivo, como por ejemplo: fábrica del producto, nombre del producto, versión del producto, etc. Inquiry es 91

92 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO muy parecido a las peticiones USB del tipo String, la diferencia radica en que este comando se envía típicamente después de aplicar un reset al dispositivo, de manera de comprobar que el dispositivo soporta los comandos SCSI y así indicar al dispositivo que está listo para recibir otros comandos SCSI. Para acceder al llenado y envío del comando Inquiry se puede consultar en el Apéndice E. También se incluyen el resto de los comandos construidos. A continuación se muestra la función construida para ejecutar el comando SCSI Inquiry. INQUIRY(char *ptr) Figura 5.5: Resultado del comando Inquiry. El siguiente código muestra la forma de realizar el comando Inquiry. int main(void) {... char temp[36] Bus_Enumeracion(0x02); //bus enumeración en 0x02 Buscar_EndpointBulk(); //busca y ordena los endpoint tipo bulk en los descriptores NUM_DISP=0x02; //var. general, fija la dirección para las funciones SCSI INQUIRY(temp); // comando SCSI La figura 5.5 muestra el resultado obtenido al ejecutar el comando SCSI INQUIRY() a un pendrive Packard Bell. En la figura se observa que el dispositivo devuelve la marca, producto y versión del dispositivo, demostrando de esta manera que está listo para seguir recibiendo comandos SCSI. Sin duda, este comando es muy parecido a las peticiones del tipo string. 92

93 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Read(10) El comando SCSI Read(10 ) permite leer un sector de memoria de 512 bytes (bloque), con la posibilidad de fijar cuantos sectores consecutivos se van a leer. Es decir, la cantidad de bloques que se leen puede ir variando dependiendo de las necesidades del programador. Lo ideal y óptimo para la lectura de datos es leer por cluster 1. Sin embargo, al usar un microcontrolador se reduce la posibilidad de leer en forma óptima los dispositivos con mayor memoria y que a su vez tengan un cluster de mayor tamaño. La memoria RAM que posee el microcontrolador MSP430f1612 es de 5KB (aproximadamente 10 bloques de 512 bytes). Teniendo en cuenta que se debe dejar memoria libre para la escritura de datos, variables, funciones y otras operaciones paralelas que realizará el microcontrolador, la lectura no debe sobrepasar más allá de los 2048 bytes, es decir 4 bloques consecutivos de memoria. La siguiente función permite ejecutar el comando SCSI de lectura de sectores: Leer_Sector(DWORD sect_leer, BYTE veces, char *ptr) EL parametro sect leer indica el sector que se va a leer. El parámetro veces indica la cantidad de bloques de sectores de memoria (512 bytes). El resultado de la lectura empieza en el puntero ptr. En el siguiente ejemplo ilustra como leer el sector de memoria 0x40 y 0x41 utilizando las propiedades. int main(void) {... char temp[1024]; Leer_Sector(0x000040, 2, temp); En el ejemplo anterior también es posible leer los dos sectores de memoria por separado, pero usando las propiedades de la función SCSI se pueden reducir notablemente los tiempos de acceso a memoria en los pendrives. Sin duda, la función de lectura es la clave del posterior proceso de búsqueda y escritura de archivos. Pero en si, la lectura de sectores no tiene mucho sentido sino se tiene claro que representa cada sector de memoria. En secciones más adelante se discutirá la organización de la memoria en los dispositivos. 1 Un cluster es una agrupación de sectores de 512 bytes que dependen de cada dispositivo. 93

94 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Write(10) La función SCSI Write(10) permite escribir en un sector de memoria de los dispositivos. Esta función tiene las mismas características y consideraciones que la función anterior Read(10). Sin embargo, la construcción interna es bastante diferente, pues los llenados de los bloques de comandos CBW son distintos y la comunicación entre el host y el dispositivo es del tipo DATA-OUT. La siguiente función fue creada para ejecutar el comando SCSI de escritura. Escribir_Sector(DWORD sect_escr, BYTE veces, char *ptr) El siguiente ejemplo ilustra como escribir los caracteres e, l, o, en el sector de memoria 0x40 de un dispositivo MSD. int main(void){.. char temp[512]; temp[0]= e ; temp[1]= l ; temp[2]= o ; Escribir_Sector(0x000040, 1, temp); Se debe tener cuidado cuando se intenta escribir en sectores en el cual puede afectar el funcionamiento de los dispositivos. Por ejemplo escribir datos incorrectos en el sector 0x00 puede causar que el dispositivo no sea reconocido en los S.O, o escribir en un sector que no esté libre puede causar que se dañen los archivos y posteriormente no puedan ser recuperados. Con la ayuda de la función de escritura se creó una nueva función capaz de escribir a partir desde una posición del sector (1-512). La función es EscrSectorPosic(), donde se utilizó para rellenar sectores cuando se desea escribir al final de un archivo Organización De La Memoria Física Actualmente los pendrives tienen una capacidad de almacenamiento desde 16MB a 2GB, lo cual es relativamente pequeño comparado con los actuales discos duros que superan los 500GB. La estructura de memoria para discos con capacidades menores a 2GB corresponde a FAT16. De esta manera los actuales pendrives vienen por defecto con el formato (FAT16). Sin embargo, los pendrives se pueden formatear bajo Windows a FAT32, pero puede causar algunos problemas o daños como: reducción del tamaño original, pérdida de la Master Boot 94

95 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Record o simplemente la pérdida del firmware en los Mp3 Player. Sin duda, con el aumento gradual de las capacidades de memorias de los pendrives, éstos tendrán que funcionar normalmente en otros formatos, lo que está en plena discusión por USB-IF FAT16 La figura 5.6 muestra la estructura para FAT16. En los primeros 512 bytes de memoria se encuentra el sector llamado Master Boot Record (MBR). A continuación se encuentran cuatro posibles unidades lógicas (logical disk). Cada unidad lógica contiene: una Partition Boot Record (PBR), dos FAT idénticas (FAT1 y FAT2) y una tabla de directorios raíz. En el caso del protocolo USB, el acceso es sólo a través de sectores de 512 bytes y no por medio de CHS (Cylinder, Head, Sector). Figura 5.6: Organización de la memoria. Además de agrupar la memoria por sectores de 512 bytes, también se agrupan sectores consecutivos los cuales se llaman cluster. Estos dependen del tamaño de la memoria de cada dispositivo. El cuadro 5.5 se muestran los cluster por la capacidad de cada dispositivo, en donde más grande la memoria implicará más sectores por cluster. El total de cluster que debe haber en FAT16 es de cluster (0xFFFF) por área de datos. Tamaño 32MB 64MB 128MB 256MB 512MB 1GB número de cluster Cuadro 5.5: Cluster por tamaño. 95

96 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Master Boot Record - MBR El sector Master Boot Record (primer sector de memoria) lleva el control de las diversas particiones (unidades lógicas) que existen en el dispositivo, entregando detalles importantes como el sector donde comienza dicha partición. Posición Descripción Largo 000h Código ejecutable (booteable) 446 bytes 1BEh 1 o Partición 16 bytes 1CEh 2 o Partición 16 bytes 1DEh 3 o Partición 16 bytes 1EEh 4 o Partición 16 bytes 1FEh Identificador (55h AAh) 2 bytes Cuadro 5.6: Master Boot Record. La Master Boot Record se encuentra dividida en 6 campos (cuadro F.1). La posición 0x1BE de la MBR entrega la información necesaria para determinar donde se inicia la primera partición del disco. Toda esta información parcial sobre la primera partición se encuentra en 16 bytes (el detalle de los 16 bytes se encuentra en el Apéndice F). Figura 5.7: Master Boot Record del pendrive Packerbell 256MB. En la figura 5.7 se muestra la MBR de un pendrive Mp3 Player PackardBell. Se observa 96

97 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO que los primeros 446 bytes de código ejecutable (color verde) no se encuentra en el dispositivo, sin embargo en otros modelos se pudo constatar la presencia del código ejecutable. Luego en la figura, se muestran las cuatro unidades lógicas disponibles con un largo de 16 bytes de información. Se puede observar que sólo la primera partición está activa. Por último la MBR finaliza con los valores fijos 55h AAh (firma). No siempre se puede encontrar la MBR en el primer sector. Cuando ocurre esto, el primer sector de memoria pasa a ser la PBR (Partition Boot Record) de la primera unidad lógica. Esto sucede cuando los dispositivos cuentan con una sola partición (muy común) y se formatean bajo Windows, pero en caso contrario, la MBR deberá estar presente para indicar las distintas particiones Particiones Cada partición tiene 6 secciones definidas (figura 5.8). Toda partición comienza con la Partition Boot Record (PBR) de un un tamaño fijo de 512 bytes. Seguido se encuentran de tamaño variable: los sectores reservados, dos tablas FAT, tabla de directorios y termina con el área de datos. Toda la información respecto del tamaño y direcciones de las secciones nombradas anteriormente la proporciona la PBR, que además entrega la cantidad de sectores por cluster que tiene la partición 1. Figura 5.8: Estructura de las particiones. 1 EL detalle referente a toda la PBR se puede consultar en el Apéndice F. 97

98 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO La figura 5.9 muestra la PBR de un pendrive conectado al SL811HS. Figura 5.9: Ejemplo de la Partition Boot Record Función para encontrar particiones Se construyó una función que buscará y calculará los datos útiles para la posterior búsqueda de archivos (direcciones de cada sección de la estructura de la partición). También que diferenciara entre la MBR y la PBR ya que ambas pueden aparecer en el sector 0x00 con un tamaño de 512 bytes. El código interno de la función se basa en lo que anteriormente se discutió sobre las particiones, en conjunto con los detalles que se encuentran en el Apéndice F sobre las particiones. La función construida es la siguiente: buscaparticion(byte adress) La figura 5.10 muestra los resultados obtenidos al utilizar la función buscaparticion() al mismo pendrive del ejemplo de la figura

99 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.10: Valores obtenidos al ejecutar la función buscaparticion(). Como se puede observar de la figura 5.10, los valores obtenidos y calculados se guardan en la siguiente estructura: struct Particion_struct { //MBR DWORD Start; //inicio de la partición. //PBR WORD BytesPorSec; BYTE SecPorCluster; WORD BytesporCluster; WORD ReservedSectors; WORD MaxRootDir; WORD SecPorFAT; //bytes por sector. //sectores por cluster. //bytes por cluster. //sectores reservados. //máximo root directorio. //sectores por FAT. //datos calculados a partir de los datos obtenidos DWORD RootDir; DWORD DataArea; DWORD FAT1; DWORD FAT2; //directorio raíz. //área de datos. //tabla FAT1. //tabla FAT2. //datos útiles DWORD TamanoCluster; DWORD NumberSecPart; DWORD NumberSecData; DWORD EspTotalBytes; } Particion; //tama~no del cluster en bytes. //números de sectores en la partición. //números de sectores de datos. //espacio total del dispositivo. 99

100 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Distribución de los archivos en memoria Como se mencionó en este capítulo, grupos de sectores de 512 bytes se agrupan en cluster 1. La numeración de los cluster sucede a partir del área de datos de la partición, para lo cual, se establece que el área de datos comienza exactamente en el cluster 0x02. Figura 5.11: Ejemplo de la distribución de un archivo en memoria. Cuando se busca un archivo, uno de los datos que se obtienen de aquella búsqueda es el cluster que da el comienzo al archivo, llamado cluster de inicio. El cluster de inicio se relaciona directamente con los datos obtenidos de la partición para establecer la dirección precisa del sector que se debe leer. Además, la utilización de cluster produce que un archivo siempre ocupe como mínimo la cantidad de 1 cluster de memoria, excepto por los archivos de tamaño cero que no tienen un cluster asignado. Por otra parte, los archivos superiores a un cluster se ubican en varios cluster (dependiendo del tamaño del archivo), donde no necesariamente pueden ser consecutivos. De esta manera, la distribución total del archivo es repartida a lo largo de la memoria del dispositivo. En la figura 5.11 se muestra un ejemplo gráfico de un archivo repartido a través de dos cluster. Como se observa en la figura 5.11, la información sobre la continuidad del archivo es proporcionado por la tabla FAT 2, indicando a través de un número de 2 bytes el próximo cluster a leer. El archivo sólo termina cuando la tabla FAT entrega el valor 0xFFFF. Sin embargo, la tabla FAT entrega otros valores, como indicar si un cluster está vació o dañado. 1 Mirar el cuadro FAT1 y FAT2 son tablas idénticas. 100

101 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Los valores que se pueden obtener de la tabla FAT y su interpretación se muestran en el cuadro 5.7. Valor 0x0000 0x0002-0xFFEF 0xFFF0-0xFFF6 0xFFF7 0xFFF8-0xFFFF Descripción cluster vació usado, próximo cluster cluster reservado cluster dañado usado, último cluster en el archivo Cuadro 5.7: Códigos para el cluster Archivos y directorios La asignación de nombre para los archivos y directorios establece dos tipos de formatos: 8.3 y LFN. El primer formato (8.3) se utilizó en el sistema operativo DOS para asignar como máximo 8 caracteres para el nombre y 3 caracteres para la extensión, normalmente conocido como nombres cortos. El formato 8.3 tiene la ventaja que por cada nombre que se guarde sólo ocupará el espacio de 32 bytes, pero con la desventaja que recorta los nombres que se salgan del formato 8.3. Por su parte, el formato Long File Name, por problemas de compatibilidad conserva el formato 8.3, y además agrega espacio para los nombres que contengan más caracteres de lo que permite el formato 8.3, incluyendo casos como los caracteres especiales que no soporta 8.3. El formato LFN se empezó a utilizar a partir de Windows95, en donde se establece una asignación de espacio múltiplo de 32 bytes 1. Cada formato tiene sus propias características de como se distribuye los caracteres a lo largo del espacio que tienen asignado para el nombre. Además cada archivo o directorio trae consigo la información necesaria para la ubicación posterior de los datos. La información que tiene cada archivo o directorio es en general: nombre, extensión, atributos (archivo, directorio, oculto, sistema), fecha de creación, último día de acceso, primer cluster de acceso y tamaño del archivo. Hay que rescatar que el significado del primer cluster de acceso para un archivo, es indicar en que sector de memoria hay que leer el archivo (primeros bytes del archivo), sin embargo, para un directorio el significado es indicar en que sector de memoria están los nombres de archivos y sub-directorios que pertenecen a ese directorio. Para mayor detalle, en el Apéndice F se encuentra la distribución de los caracteres para el formato 8.3 y LFN en conjunto con toda la información que se puede obtener de los archivos y directorios. En la figura 5.12 muestra cuatro ejemplos de diferentes nombres de archivos obtenido de la tabla de directorios de un pendrive. En el primer caso se tiene el nombre informe.txt, el cual corresponde al formato de nombres cortos. Se puede observar del caso 1 que el nombre va en mayúscula (no se conserva el nombre original) y además, el punto que divide el nombre de la extensión es considerado como un caracter de espacio (0x20). En segundo 1 El mínimo de espacio que ocupa el formato LFN es de 32 bytes para archivos y directorios cortos. 101

102 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.12: Ejemplos de nombres y carpetas en la tabla de directorios. caso, corresponde al archivo mis documentos.zip, en donde se utiliza el formato LFN. Se observa del caso 2 que se ocupan 32 bytes para la asignación del nombre corto y se agregan 64 bytes para el nombre largo. Cada nombre largo tiene detalles como por ejemplo: la cadena siempre empieza con el valor 0x01; la continuación de cada nombre es hacia atrás; la información correspondiente al archivo se guarda donde está el nombre corto; el punto de división entre el nombre y la extensión es considerando como un caracter de punto (0x2e); los espacios vacíos se rellena con 0xff, etc. El tercer caso 3 corresponde al archivo todas mis fotografias 1 del paseo.rar, en donde corresponde al formato LFN y ocupa un total 128 bytes. En el caso 4 (último ejemplo) corresponde al archivo borrado notas.doc. Se puede observar que la primera letra del nombre se reemplazó por el valor 0xe5, de esta manera se indica que el archivo ya no existe. En general, como se vieron en los ejemplos, la búsqueda de un nombre no resulta ser una acción sencilla, ya que por la gran cantidad de detalles no se soluciona con una simple comparación de cadenas Desarrollo de una función base de búsqueda Se desarrolló una función que sirviera de base para la posterior búsqueda de nombres de archivos. La función permite buscar nombre entre un rango de sectores que determine el programador. La función se muestra a continuación: busqueda_archivo(char *name, char atr, DWORD sect_inic, DWORD sect_final) 1 El archivo original no lleva acento. 102

103 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO La función permite la búsqueda de un nombre name, entre las dirección inicial sect inic y la dirección final sect final, diferenciando con el parámetro atr para establecer si se trata de un archivo o directorio ( D =directorio y A =archivo). La función retorna el valor 1 si la búsqueda es exitosa o el valor 0 en caso contrario. Además, permite buscar nombres ya sea de cualquier formato (8.3 y LFN), ya que la función reconoce y transforma los nombres según sea el caso. Internamente la función se ayuda de otras funciones creadas que facilitan la búsqueda, como son: la reubicación de los caracteres, comparaciones de atributos, comparación de cadenas, descartar nombres borrados, información de cluster, etc. Una vez encontrado el archivo, la función guarda en una estructura los datos necesarios para la posterior lectura y escritura del archivo. Los datos más necesarios que se obtienen al encontrar un archivo son: tamaño del archivo y dirección de inicio del sector de datos. A su vez, cuando se encuentra un archivo se guarda la información del sector y posición exacta en donde está ubicado el nombre del archivo, para que posteriormente se pueda modificar los bytes que indica el tamaño del archivo Búsqueda de archivos y directorios en la raíz Los archivos y directorios que se encuentran en la raíz, son todos aquellos que no están dentro de un directorio. Para encontrar estos archivos se procedió a realizar una función que buscará en todo el sector designado para la tabla de directorios. Es decir, desde el inicio de la tabla de directorios, hasta un sector antes del área de datos 1. Este espacio de búsqueda, es siempre un rango limitado 2 y conocido (dependiendo de la memoria física de cada dispositivo), lo cual origina que cuando el espacio para la tabla de directorios se llena, no se pueda guardar un nuevo archivo en la raíz, sin embargo se puede seguir escribiendo en los archivos. Finalmente para la búsqueda de nombres en la raíz se desarrolló la función root(), para lo cual se fijaron los parámetros de búsqueda de la función base busqueda archivo(). El código de construcción se muestra a continuación: int root(char *name, char atr) { int res; res=busqueda_archivo(name,atr,particion.rootdir,particion.dataarea-1); SEND_CMD(Display_Clear); if (res==1) printf("arch o Dir encontrado"); else { printf("arch o Dir No encontrado"); borrartemp(); } return res; } 1 Mirar la figura 5.8, sector Root Directory. 2 La tabla de directorios pueden ser varios cluster de memoria. 103

104 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO La función root() retorna un valor y un mensaje dependiendo del resultado de la búsqueda Búsqueda de archivos y directorios en directorios Los archivos y directorios que se encuentran dentro de otro directorio (no-root), se diferencian de los archivos que se encuentran en la raíz, en tener un espacio limitado sólo por la memoria disponible que tenga en el disco (pendrive). Esto se debe porque los nombres de archivos y carpetas se guardan como datos de archivos, utilizando para ello el método del seguimiento por cluster (FAT). La función que se construyó para la búsqueda en directorio es la función noroot(), cuyo código se muestra a continuación: int noroot(char *name, char atr) { int res; DWORD ultimo_sectorleido, proximo, final; SEND_CMD(Display_Clear); proximo=directemp.direccarchiv; final=proximo+particion.secporcluster; //fija el limite inicial //fija el limite final del cluster if(directemp.direccarchiv==0) //verifica si hay un directorio anterior buscado { printf("error, no existe directorio anterior"); return 0; } //se realiza la búsqueda hasta que se encuentre el archivo, //o hasta que se terminen los cluster de datos. do { res=busqueda_archivo(name,atr,proximo,final); ultimo_sectorleido=proximo; proximo=infocluster(proximo); final=proximo+particion.secporcluster; } while((res==0) && (ultimo_sectorleido!= Directemp.UltimoSector)); if (res==1) //respuesta positiva printf("arch o Dir encontrado"); else //respuesta negativa { borrartemp(); printf("arch o Dir No encontrado"); } return res; } 104

105 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Inicialmente la función busca en todo el cluster inicial de datos, que es entregado por la función anterior root(). Si la búsqueda es negativa, consulta si hay más cluster por leer y se fijan los nuevos límites de búsqueda. La búsqueda se realiza hasta que se encuentre el archivo o hasta que la información del cluster diga que no hay más saltos de memoria (no hay más archivos en ese directorio). por ejemplo para buscar dos archivos diferentes se procede de la siguiente manera: int main(void){... //busca el archivo 1 root("archivos", D ); //directorio "archivo". noroot("textos generales", D ); //directorio "textos generales". noroot("teclado.txt", A ); //archivo "teclado.txt". save(0); //graba dirección en posición 0. //busca el archivo 2 root("strupr.c", A ); //archivo "strupr.c" save(1); //graba dirección en posición 1. En la primera parte del ejemplo, se busca un archivo en la ruta archivos/textos generales/teclado.txt, el resultado se guarda en la posición 0. Para el segundo caso se busca en la raíz el archivo strupr.c y se guarda en la posición 1. La función save(), que se muestra en el código, se diseño para permitir operar con varios archivos: se guarda en una posición del 0 al 9 todos los datos respecto del último archivo buscado, de manera que posteriormente se pueda elegir la lectura y escritura de 10 archivos distintos. Por otro lado, cuando un nombre no se encuentra o no existe, la búsqueda (noroot()) y el grabado de datos (save()) no se realizan. Esto porque las distintas funciones verifican si existe un resultado anterior positivo. Además, en cada caso se muestra a través de la pantalla LCD el resultado de la operación. El resultado final de la función save() queda en la estructura Archiv Open. La figura 5.13 muestra el resultado de los dos archivos encontrados en el ejemplo anterior. Se puede observar en la figura 5.13 que los tamaños de los dos archivos son 4096 y 709 bytes respectivamente (TamArchiv). El valor del tamaño del archivo es el único dato que puede llegar a ser útil para el usuario, como por ejemplo mostrarlo el tamaño en pantalla. Además, es útil para abrir el final de un archivo y posteriormente escribir a continuación. El resto de los datos que se guardan con la función save() y que se muestran en la figura (dirección de inicio del archivo, último cluster, index, etc) son para que posteriormente las funciones de lectura y escritura de archivos se guíen para cumplir con la tarea. En un futuro se podría integrar estas tres funciones (root(), noroot() y save()) de manera de realizar una búsqueda general tipo D.O.S, MATLAB, Linux, etc. 105

106 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO Figura 5.13: Estructura de la función save() Lectura de archivos Se construyó una única función capaz de realizar una lectura de archivos, de tal manera que satisficieran las mayorías de las necesidades de lectura de archivos. La función de lectura es: readfile(dword numr,dword ini, WORD cuant, char *ptr) La función permite leer un archivo de los que ya se han guardado con la función save(). Para ello se le ingresa en el parámetro numr para indicar el número del archivo que se desea leer. También se le ingresan los parámetros ini y cuant, que permite decirle a la función en que byte del archivo empezar a leer y que cantidad de bytes leer respectivamente. Los datos se guardaran en la dirección de memoria ptr. La función retorna los bytes que se leyeron, pues se le pueden indicar leer una cantidad que sobrepase el tamaño del archivo. En caso que no se pueda leer el archivo, la función retorna el valor 0. La función tiene varias restricciones, una de ellas es que no se pueden leer más de 2048 bytes de cualquier parte del archivo, pues por problema de memoria en el microcontrolador, puede afectar a la escritura de datos o a otras funciones paralelas que se quieran realizar con el. De esta manera la función retorna el valor 0 cuando se ingresan parámetros 106

107 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO de lectura más grande que 2048 bytes (cuant). Otra restricción que se realizó fue que el valor ini sólo sea válido desde el valor 1, pues el valor indica el primer byte del archivo. También, la función retorna el valor 0 cuando se pone un valor ini más grande de lo que es el tamaño del archivo, de manera de proteger el desarrollo de la función. Por último, cuando se pone un valor en el parámetro cuant (cantidad de bytes que se desean leer) que comprometa leer más allá del tamaño real del archivo, pero el valor inicial de lectura ini es válido, internamente la función ajusta el valor de manera que sólo se leen los últimos bytes del archivo. Por ejemplo leer los primeros 100 bytes de un archivo guardado en la posición 0.: int main(void){... char temp[100]; //busca el archivo 1 root("archivos", D ); noroot("textos generales", D ); noroot("teclado.txt", A ); save(0); readfile(0,1,100,temp); //lectura de los primeros 100 bytes del archivo 0. } Para leer más de 2048 bytes (3000) y destinarlo a un mismo arreglo. int main(void){... char temp[3000]; readfile(3,1,2000,temp); //lee desde , el archivo 3. readfile(3,2001,1000,&temp[2000]); //lee desde , el archivo 3. } Para leer los últimos 512 bytes de un archivo 9. int main(void){... char temp[512]; readfile(9,archiv_open[9].tamarchiv-512,512,temp); } Escritura en archivos La escritura en archivo consiste en copiar desde memoria del microcontrolador datos, variables y cadenas de caracteres, a partir del final del archivo. Para realizar tal función, 107

108 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO se procedió a obtener los datos necesarios del último cluster en donde está la parte final del archivo. Con las anteriores funciones desarrolladas se procede a completar los bytes que faltan del último sector, para así continuar con rellenos por sectores completos según sea la cantidad de información que se desea guardar. En caso que se terminen los bytes disponibles que posee el último cluster, la función de escritura se apoya en otras funciones para la búsqueda de un cluster vacío, de manera que se siga realizando la escritura de datos faltantes. En caso de éxito (búsqueda correcta de un cluster vacío) la función de escritura procede a realizar los respectivos cambios en la FAT, para darle continuidad al archivo (FAT1 y FAT2). Una vez que se tiene un cluster vacío, la función de escritura sigue rellenado los sectores al igual que en la primera parte. Una forma gráfica de lo explicado anteriormente se muestra la figura 5.14, para un dispositivo que tiene 4 sectores por cluster. Figura 5.14: Relleno de sectores y cluster en la escritura de datos. En la figura se puede observar como está distribuido la última parte del archivo. El tamaño del archivo del ejemplo es de 2862 bytes, los primeros 2048 bytes están distribuido en un cluster en que no es importante para el relleno de los datos, sin embargo, si es importa saber todo lo referente al último cluster, en donde están los últimos 824 bytes del archivo. También se consideró para el diseño de la función de escritura, el caso de los archivos con tamaño cero, pues estos archivos no tienen un cluster asignado. Para ello, previamente se le asigna un cluster en la FAT. Finalmente cualquier que sea el caso, la función de escritura termina su rutina modificando el nuevo tamaño del archivo en donde se encontró, además, se actualizan los valores que se guardan en la estructura de la función save(). De esta forma, en la próxima escritura de datos todos los archivos parten con los nuevos cambios que guiaran correctamente la escritura, como la lectura del archivo. Las funciones de escritura son las siguientes: 108

109 CAPÍTULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO int writefile_array( int numero, char *ptr, WORD cuanto_escribir); int writefile_var(int numero, long entero); int writefile_string( int numero, char *ptr); El parámetro numero indica el archivo que se desea escribir. Al igual que en la lectura de archivo, estas tres funciones están basadas en una función base de escritura, de manera que son pequeñas variaciones para utilizarlas en diferentes casos. La primera función writefile array() corresponde prácticamente a la función base de escritura pues permite escribir en un archivo un arreglo del tamaño que desea el usuario. La segunda función writefile var() permite escribir al final de un archivo una variable de tamaño long. Para ello se procede a transformar la variable a caracteres. La tercera función writefile string() permite escribir un string cualquiera. Entre los múltiples ejemplos que se realizaron para verificar el correcto funcionamiento de las funciones, fue realizar una lectura por segmentos iguales de datos (excepto por el último segmento) de un archivo, realizando al mismo tiempo una copia de esos segmentos a otro archivo con tamaño inicial de 0 bytes. De esta manera, se realiza una copia idéntica del archivo original. También se realizó la lectura de MBR, PBR y FAT, para luego pasar la información a un archivo de texto. Por ultimó se realizó una copia de datos de un archivo a otro, con la comprobación de datos escritos en el mismo dispositivo. Todos los ejemplos se pueden consultar en el CD-ROM adjunto a la memoria, cual trae las respectivas aclaraciones para cada ejemplo. 109

110 Capítulo 6 Conclusiones El desarrollo del driver que permite la escritura y lectura de archivos en dispositivos de almacenamiento masivo USB se concretó exitosamente. Sin embargo se abordaron otros tópicos de gran importancia del protocolo USB como son: peticiones, descriptores y dispositivos de interfaz humana (HID). Estos temas, en conjunto con el tema principal tratado, permitirán al futuro programador trabajar desde un sólida base tanto con el controlador USB SL811HS, como para otros tipos de controladores en donde se requieran realizar nuevos drivers. Con respecto al controlador USB en el cual se trabajó, se generaron sencillas funciones para el usuario como son: cargar de forma automática los descriptores del dispositivo, detectar la velocidad de trabajo, configurar y visualizar si el dispositivo está enumerado, recibir datos desde dispositivos HID (mouse, teclado y joystick) y manipular en forma sencilla archivos de datos. Con esto, sin entrar en gran profundidad en el protocolo USB o en el controlador, el usuario sólo se encargará de manipular los datos que provienen desde el dispositivo. Al hacer múltiples pruebas con dispositivos de almacenamiento masivo, se observó que la velocidad de transferencia de los archivos que se manipularon, fue notoriamente más baja de lo que el protocolo USB 1.1 puede brindar. Esto se debe a que la mayoría de las funciones que se crearon, fueron diseñadas para asegurar el correcto funcionamiento en dispositivos de cualquier tamaño de memoria. Además, la poca memoria RAM que dispone el microcontrolador con respecto a la memoria física de los dispositivos, implicó realizar las funciones no de forma más optima. A pesar que una norma asegura que un dispositivo USB 2.0 debe por lo menos ser reconocido en los controladores USB 1.1, la norma no asegura el completo funcionamiento de ellos. Esto se pudo comprobar en los distintos dispositivos en que se realizaron pruebas, y se verificó que no todos los dispositivos USB 2.0 funcionan adecuadamente en un controlador 1.1. Sin embargo, el funcionamiento para los dispositivos USB 1.1 fue correcto para todos. En general, las aplicaciones que se pueden desarrollar con los dispositivos USB de la clase HID y MSD tienen un sin fin de posibilidades, el cual sólo dependerá de la imaginación de quien ocupe estos recursos. 110

111 Apéndice A Detalles del protocolo USB En este apéndice se encuentra el detalle del protocolo USB. Algunos de los paquetes que se nombran en este apéndice se pueden manejar directamente en los registros de control del SL811HS. A.1. Paquetes que se encuentran en las transacciones Nombre Tamaño Tipos de paquetes Propósito SYNC 8 bits todos inicio de la tramas y sincronización PID 8 bits todos identifica el tipo de paquete Adress 7 bits IN, OUT, Setup identifica la dirección del dispositivo (funciones) ENDP 4 bits IN, OUT, Setup identifica el número del endpoint Frame 11 bits SOF identifica el número del frame Number Data Data0, Data1 datos bytes CRC 5 ó 16 IN, OUT, Setup, detectar errores bits Data0, Data1 Cuadro A.1: Paquetes del protocolo USB. A.1.1. SYNC SYNC es usado por el circuito de entrada para alinear los datos de llegada con el reloj local, de esta manera SYNC sólo sirve como un mecanismo de sincronización en el cual todos los paquetes lo contienen (Token, Data, Handshake). La estructura del campo SYNC para low y full-speed corresponde a una secuencia de 8 bits con el string KJKJKJKK en codificación NRZI. Los últimos dos bits del campo SYNC ( KK ) es un rotulador que se usa para identificar el fin del campo SYNC, para dar el comienzo al campo PID. Sin embargo, para la transmisión high-speed se requieren de 15 pares KJ terminando con KK dando un total de 32 símbolos. Los hubs tienen el permiso de poder descartar hasta 4 bits 111

112 APÉNDICE A. DETALLES DEL PROTOCOLO USB desde el principio del patrón SYNC, pero no pueden agregar símbolos al campo SYNC. De esa manera, después de ser repetido por 5 hubs el campo original SYNC de 32 símbolos, puede llegar a quedar a 12 bits (KJKJKJKJKJKK). Este método de eliminación es para detectar cuando se conecten más de 5 hubs al bus de datos. A.1.2. PID El PID indica el tipo del paquete en la trama USB. Este consta de 8 bits de los cuales los primeros cuatro son empleados para indicar el código del formato del paquete (cuadro A.2) y los cuatro últimos llamado IPID son los mismos 4 primeros bits del paquete pero en forma negada, utilizado como un mecanismo de detección de errores. Cuadro A.2: Bits del paquete PID. A.1.3. Address El campo ADDR especifica la dirección del dispositivo de manera que el host pueda establecer la comunicación. Esto se realiza a través de 7 bits como lo muestra el cuadro A.3. Con la cantidad 7 bits se puede establecer como máximo 127 direcciones para la enumeración de los dispositivos, siendo la dirección 0 una dirección reservada para la configuración de los dispositivos. Cuadro A.3: Bits del paquete Adress. A.1.4. ENDP Cuadro A.4: Bits del paquete ENDP. El campo ENDP especifica en 4 bits (cuadro A.4) el endpoint con el cual el host va establecer la pipe de comunicación. Los dispositivos low-speed dan un soporte como máximo a tres pipes: una pipe de Control obligatoria en el endpoint-0 y dos pipes adicionales (ya sea dos de Control, una de Control y otra del tipo Interrupt, o dos del tipo Interrupt). 112

113 APÉNDICE A. DETALLES DEL PROTOCOLO USB Para los dispositivos full-speed y high-speed se establece un máximo de 16 endpoint. A.1.5. CRC La Verificación de Redundancia Cíclica (CRC) se usa para proteger a todos los paquetes excepto los paquetes PID. En el caso de la fase Token el CRC5 es aplicado sobre los paquetes ADDR y ENDP. Para la fase Data, el CRC16 es aplicado solamente para el campo DATA. El motivo de no agregar el paquete PID para la verificación de errores, es porque los paquetes tipo PID trae su propio mecanismo de verificación, al repetir nuevamente los bits pero en forma negada. A.2. Estados en la línea de transmisión Gracias al transmisor diferencial, receptor diferencial y las resistencias en los terminales, posibilitan transmitir y detectar varios estados eléctricos en la línea. Esto es de gran importancia mencionar pues los controladores USB incluyendo el SL811H manejan estos estados en sus registros de configuración. Los estados eléctricos son: A.2.1. Diferencial0 y Diferencial1 Estos estados están definidos por las señales D+ y D-. Diferencial1 existe cuando la señal D+ está en nivel lógico bajo y la señal D- está en el nivel lógico alto. De la forma contraria se define Diferencial0. A.2.2. Single-Ended Zero El estado Single-Ended-Zero (SE0) ocurre cuando las señales D+ y D- tienen un nivel lógico 0. El bus usa el estado Single-Ended-Zero para detectar la conexión y desconexión de dispositivos, para indicar el EOP (fin de paquete) y para generar reset. A.2.3. J y K USB también define dos datos de estados J y K. Estos están definidos por los estados diferencial0 y diferencial1 dependiendo si se está conectado de la forma low-speed o fullspeed (cuadro A.5). Las definiciones de los estados de datos J y K posibilita el uso de una terminología para describir eventos o estados lógicos cuando los voltajes de las líneas low y full-speed difieren. Por ejemplo, el estado SOF (start of frame) existe cuando el bus cambia de un estado Idle a un estado K. En full-speed, el estado ocurre cuando D- es más positivo que D+, mientras que en low-speed, el estado ocurre cuando D+ queda más positivo que D-. 113

114 APÉNDICE A. DETALLES DEL PROTOCOLO USB Estado Low-Speed Full-Speed Diferencial0 J K Diferencial1 K J Cuadro A.5: Estados J y K. A.2.4. Bus Idle Indica reposo o línea en alta impedancia, necesario para permitir transferencias semidúplex, detectar la conexión y desconexión de dispositivos y discriminar entre dispositivos FS y LS. A.3. Special Packet para el protocolo USB 2.0 En el grupo de paquetes especiales USB 1.1 define sólo un tipo de paquete llamado PRE para indicarle a todos los hubs que un paquete de baja velocidad será transmitido. Los hubs toman estos paquetes y los repiten a todos los dispositivos que estén habilitados, sean estos de alta o baja velocidad. El paquete subsiguiente que sea transmitido hacia los dispositivos sea una fase Handshake, Data o Token, será transmitido en baja velocidad. En cambio USB 2.0 define tres nuevos tipos de paquetes 1 especiales: ERR: Se usa para indicar errores en transacciones Split high-speed. Sólo lo puede transmitir un hub 2.0 (en modo high-speed) en el campo de handshake de una transacción Split. SPLIT: Lo transmite el host en el campo de Token con el motivo de que los hubs ejecuten toda la transferencia en high-speed y sólo en la parte final de la transacción se ejecute a la velocidad correspondiente al dispositivo (low-speed o full-speed). En USB 1.1, si se realiza una transacción a velocidad low-speed, la transacción comenzaría desde el primer hub a esa velocidad trayendo como consecuencia el desaprovechamiento del ancho de banda. PING: Es transmitido por el host en el campo de Token de una transacción para el control de flujo. Esto lo envía el host para preguntar si el dispositivo está disponible sin enviar los datos del tipo Control o Bulk, de esta manera se ahorra ancho de banda. En el caso que el dispositivo responde con un ACK es porque el dispositivo puede atender al host. Si todavía no está disponible responde con un NAK al Token PING hecho por el host. 1 Estos tipos de paquetes no son soportados por el host controlador SL811HS. 114

115 APÉNDICE A. DETALLES DEL PROTOCOLO USB A.4. Resumen de los paquetes en las transacciones La figura A.1se muestra el resumen de la estructuras de todos los paquetes, incluyendo el protocolo USB 2.0. Figura A.1: Resumen de la estructura de los paquetes del protocolo USB. 115

116 APÉNDICE A. DETALLES DEL PROTOCOLO USB A.5. Resumen de las transferencias USB La figura A.2 detalla todas las transferencias del protocolo USB 1.1 y USB 2.0, incluyendo todos los paquetes que se ven involucrados en cada caso. Figura A.2: Resumen de las transferencias del protocolo USB. 116

117 Apéndice B Diagrama de conexiones La figura B.1 muestra el diagrama de conexiones que se realizó para desarrollar la presente memoria. La conexión corresponde al microcontrolador MSP430F1612, el controlador USB SL811HS (módulo uusb-hs) y un display LCD de 4 líneas. Figura B.1: SL811HS USB Host/Slave Controlador, Pin Layout. 117

118 Apéndice C Registros del controlador SL811HS en modo Host En este apéndice se detallan los registros de control que posee el controlador SL811HS. Los registros pertenecen al modo de operación en host. A su vez, se muestran diversos ejemplos en los registros de mayor interés y uso. Los registros del SL811HS en modo host están resumidos en el cuadro C.1. Registro Definición Dirección USB-A Control CTL 0x00 USB-A Address BUFADR 0x01 USB-A Length BUFLEN 0x02 USB-A PID/EP PID EP 0x03 USB-A Status PKTSTAT 0x03 USB-A Address FNADDR 0x04 Ctrl1 CTL1 0x05 Interrupt Enable IE 0x06 Interrupt Status INTSTATUS 0x0D SOF Low SOFCT L 0x0E HW Revision HWR 0x0E SOF High/Ctrl2 SOFCT H 0x0F Cuadro C.1: Registros en modo host. Detalles Las principales características de cada registro con las configuraciones bit a bit, son explicadas a continuación: Registro 0x00, USB-A Control: Se usa para proveer el control básico de las transacciones realizada por el host. Por ejemplo: habilita las transacciones USB, fija la dirección 118

119 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST (IN-OUT), DATA toggle, etc. En el cuadro C.2 se detalla el registro 0x00 (CTL). Bit Nombre función 0 Arm 1 permite realizar la transferencia, luego vuelve automáticamente a 0 1 Enable 1 permite habilitar al endpoint, cuando es puesto en 0 la transacción es ignorada. Si Enable=1 y Arm=0 el endpoint retornara un NAK 2 Dirección 1 transmite el host. 0 el host recibe 3 Reservado 4 ISO 1 permite transferencias isócronas para el endpoint 5 SOF 1 sincroniza la transferencia con el SOF 6 Data Toggle 0 es DATA0, 1 es DATA1 7 Preamble 1 para transferencias a dispositivos low-speed (si hay un hub) Cuadro C.2: Registro 0x00. El acceso a este registro se establece con la función go(byte cmd) que tiene como parámetro cmd, correspondiente a un valor de configuración del registro 0x00 (cuadro C.2). La función go() sirve para enviar o recibir transferencias, en donde además, se utiliza otro registro dentro de la función go() para retornar el resultado de la operación (ACK, NAK, STALL). Esta función sólo debe utilizarse al final de un proceso de configuración, puesto que para establecer una transferencia final, se deben fijar otros registros como dirección, tamaño del buffer, endpoint etc. Considerando que no existe un hub de por medio, además, con la posibilidad de error utilizando la sincronización por SOF (Errata), los típicos valores se reducen a go(0x03) y go(0x07). Ejemplos: //Recibir datos de un endpoint (DATA0) go(0x03); // DIREC=0(in), ENAB=1, ARM=1 //Enviar datos go(0x07); a un endpoint (DATA0) // DIREC=1(out), ENAB=1, ARM=1 Se debe resaltar que es importante saber si el tipo de transacción es IN, OUT con DATA0, DATA1 o DATA toggle. En el caso de la transferencia de dispositivos de almacenamiento masivo, los endpoint son del tipo Bulk, para lo cual el envío y recibimiento de los datos es del tipo DATA toggle. De esta manera, siempre se debe estar alternando de DATA0 a DATA1, de lo contrario se produce un error de transferencia. Los endpoint tipo Interrupted y Control funcionan con DATA0. Registro 0x01, Host Base Address: Cuando se reciben datos, este registro debe configurarse para indicar en que parte de la memoria del SL811HS se van a recibir. En caso 119

120 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST de enviar datos, el registro indica donde comienzan los datos que se van a enviar. En ambos casos el valor de este registro debe ser siempre un valor válido para el buffer del SL811HS, esto es entre 10h hasta FFh. Ejemplo: wr811(bufadr,0x10); Típicamente el valor usado tanto para recibir y entregar datos es el valor 10h. Esto se hace de manera de aprovechar el total del espacio que se encuentra disponible en el buffer del SL811HS. Sin embargo, es necesario que el registro esté fijado antes de rellenar el buffer con los datos que se van a enviar. Registro 0x02, Base Length: Es usado para determinar el largo máximo de la transacción. Cuando el SL811HS envía datos hacia un periférico, este registro determina el largo del tamaño del paquete. Cuando un dispositivo va a entregar datos al host, el registro sirve para determinar el tamaño máximo que aceptará. Es importante utilizar bien este registro al momento de enviar datos, pues usar un tamaño menor al indicado por el endpoint trae consecuencias que no se reconozcan los comandos de Control, o simplemente no realizar los comandos de bloques especiales para los dispositivos de almacenamiento masivos. Ejemplos. wr811(buflen,0x08); //recibir datos en dispositivos low-speed o enviar datos de control. wr811(buflen,0x40); //recibir de un endpoint tipo Bulk 64 bytes. wr811(buflen,0x00); //recibir Handshake. wr811(buflen,0x1f); //enviar comandos CBW a dispositivos de almacenamientos masivo. Si se reciben datos desde dispositivos low-speed con endpoint del tipo interrupción, tales como teclados y mouses, los datos transferidos hacia el host serán en cada transferencia a lo más 8 bytes. De la misma manera sucede para realizar una transferencia de Control, ya que el tamaño del paquete siempre tiene el largo de 8 bytes. Por otra parte, cuando se hacen transferencias de Handshake, en el cual sólo se recibe el resultado de la operación, el valor del registro debe ser de 0. De esta manera se asegura que no hay datos en la próxima transacción, además se evitan errores cuando el registro tiene otro valor por antiguas operaciones de transferencias. Cuando se reciben transferencias tipo Bulk, los valores puede tener un valor hasta de 64 bytes (dependiendo de cada endpoint). Finalmente para el caso de transferencias isócronas (ISO), el máximo paquete permitido por USB 1.1 es de 1023 bytes, sin embargo, el SL811HS sólo soporta un máximo de 240 bytes (buffer). Registro 0x03, PID/Endpoint: Este registro tiene las siguientes funciones: indicar el resultado de la operación, establecer que tipo de paquete se va enviar en la próxima transacción y establecer a que endpoint se va establecer la comunicación. Cuando se lee el registro, éste cumple con la función de entregar el resultado de la última transacción. El cuadro C.3 muestra los valores que puede tener el registro 0x03 cuando es leído. 120

121 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST Bit Nombre función 0 ACK el dispositivo retorna un ACK 1 Error error detectado en la comunicación 2 Time-out time-out ocurrido 3 Sequence 0 es DATA0, 1 es DATA1 4 Setup cuando es 1 indica un Setup-Packet 5 Overflow largo excedido durante el recibo de datos 6 NAK el dispositivo retorna un NAK 7 STALL el dispositivo retorna un STALL Cuadro C.3: Registro 0x03, resultados de la última transacción. La lectura de este registro entra en juego en una gran parte de los códigos realizados. La función GO() al mandar un paquete retornará el resultado de la operación a través de la lectura del registro 0x03. Dependiendo tanto del valor entregado como el propósito del programa, se pueden tomar decisiones de qué hacer al respecto con el paquete. Si se están enviando datos a un dispositivo y se recibe un NAK se debe intentar nuevamente enviar el paquete hasta que el dispositivo esté disponible o desocupado. En caso de recibir un STALL simplemente se debe descartar el envió de paquetes y no insistir nuevamente, puesto que puede significar que no acepta el comando o simplemente el endpoint no existe. También es muy útil el bit de overflow para no aceptar más datos, pues después del overflow el registro indicará un error de comando. Cuando se escribe en este registro, los primeros 4 bits (b0-b3) corresponden al número del endpoint con el cual se va establecer la comunicación. Los bits restantes del registro (b4-b7) establecen el tipo de paquete PID de la próxima transacción. Los valores para el campo PID se muestra en la tabla C.4. PID Tipo b7-b4 SETUP 1101 IN 1001 OUT 0001 SOF 0101 PREAMBLE 1100 NAK 1010 STALL 1110 DATA DATA Cuadro C.4: Registro 0x03, valores para el paquete PID. Para un mejor manejo se establecen las siguientes definiciones: #define SETUP_PID 0xD0 // #define IN_PID 0x90 // 121

122 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST #define OUT_PID 0x10 // #define SOF_PID 0x50 // #define PRE_PID 0xC0 // Ejemplo: \\establecer una transferencia del tipo Control, en el endpoint cero. wr811(pid_ep,setup_pid 0x00); Registro 0x04, Transfer Count Register/USB Address: Cuando se escribe en el registro se indica la dirección del dispositivo con el cual el host va establecer la comunicación (el dispositivo debe existir en esa dirección), con un total de 127 posibles direcciones. A su vez, cuando es leído el registro, indicará los bytes sobrantes de la última transacción. Si se vuelven a pedir datos teniendo bytes sobrantes distintos de 0, el dispositivo entregará un STALL indicando que no reconoce el comando. Ejemplos: wr811(fnaddr,0x00); //comunicación con un dispositivo no configurado. wr811(fnaddr,0x01); //comunicación con el dispositivo en dirección 1. Registro 0x05, Control Register 1: El registro habilita la generación automática de SOF, reset del SL811HS, configuración de la velocidad del bus (low-speed y full-speed) y la suspensión del Sl811HS (cuadro C.5). Bit Nombre Función 0 SOF ena/dis 1 permite generación automática de SOF, 0 desactivado 3 USB Engine Reset 1 para reset 4 J-K state force mirar tabla C.6 5 USB Speed 0 para full-speed, 1 para low-speed 6 Suspend 1 habilitado, 0 desactivado Cuadro C.5: Registro 0x05. El cuadro C.6 muestra el modo de operación de las líneas D+ y D-. En donde forzando los estados J y K se pueden invertir el orden de los voltajes de la líneas de transmisión. Bit4 Bit3 Función 0 0 modo normal operación 0 1 fuerza USB Reset 1 0 fuerza J-State 1 1 fuerza K-State Cuadro C.6: Estados de operación de las líneas D+ y D-. Registro 0x06, Interrupt Enable: Este registro permite habilitar la señal de interrupción (INTRQ) cuando ocurran ciertos eventos. Estos eventos incluye SOF, conexión y desconexión 122

123 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST C.7 muestra las habilita- de dispositivos y detección de resumen/suspención. El cuadro ciones que se pueden realizar. Bit Nombre Función 0 USB-A interrupción USB-A 1 USB-B interrupción USB-B 2 reservado 3 reservado 4 SOF timer 1 = interrupción por SOF (1ms) 5 Insert/Remove interrupción por insertar o remover dispositivos 6 Device Detect/Resume interrupción por detect/resume Cuadro C.7: Registro 0x06. Registro 0x0D, Interrupt Status: El registro permite leer el estado de las interrupción programadas. Las interrupciones son borradas fijando en 1 el respectivo bit. El cuadro C.8 muestra los valores de cada bit. Bit Nombre Función 0 USB-A interrupción dispositivo USB-A 1 USB-B interrupción dispositivo USB-B 2 Reservado 3 Reservado 4 SOF timer interrupción por SOF (1ms) 5 Insert/Remove interrupción por insert/remove 6 Device Detect/Resume interrupción por detect/resume 7 D+ valor del pin D+ Cuadro C.8: Registro 0x0D. El valor del bit7 sirve para identificar si la línea conectada es D+ o D-, determinando de esta manera si el dispositivo es low-speed o full-speed. Registro 0x0E, SOF Counter Low/Hardware Revision: El registro fija el valor del contador low que permite generar el SOF de 1 ms (escritura), basado en un reloj de 12-MHz. Para low-speed y full-speed tienen un valor fijo de 0xE0. Por otra parte, el cuadro C.9 muestra los valores que el registro retorna cuando es leído. Los valores indican la reversión del hardware. La presente memoria se realizó con la revisión 1.5. Bit Nombre Función 4-7 HW revisión 00h =SL11H, rev1.2 01h =SL811HS, rev h =SL811HS Cuadro C.9: Registro 0x0E, hardware revisión. Registro 0x0F, SOF Counter High/Control2: Cuando se escribe en el registro 123

124 APÉNDICE C. REGISTROS DEL CONTROLADOR SL811HS EN MODO HOST permite: fijar el contador high para generar el SOF de 1 ms, elegir el modo de operación del SL811HS (master o slave) y cambiar la polaridad de las señales D+/D-. El cuadro C.10 muestra las posibles configuraciones. Cuando se lee el registro, retorna un valor proporcional al contador SOF para poder calcular el ancho de banda disponible. Bit Nombre Función 0-5 SOF HIGH Counter Register contador high para el SOF 6 Data Polarity Swap 1 cambia la polaridad, 0 no cambia la polaridad 7 Master/Slave selection 1 master, 0 slave Cuadro C.10: Registro 0x0F. Las configuraciones típicas para establecer la comunicación con dispositivos low-speed y full-speed son puestos en el siguiente ejemplo: Ejemplos: \\full-speed wr811(sofct_h, 0x2E 0x80); // 1 msec SOF rate, b7=host, b6=no change \\low-speed wr811(sofct_h, 0x2E 0xC0); // 1 msec SOF rate, b7=host, b6=polswap 124

125 Apéndice D Construcción de las peticiones En este apéndice se encuentra el detalle del paquete de Control para realizar las peticiones llamado Setup Packet. También se detalla la construcción de la función Request() encargada de enviar el Setup Packet. De esta manera se podrán construir nuevas peticiones para las diferentes clases. D.1. Setup Packet El Setup Packet se compone de 5 campos tal como se muestra en el cuadro D.1. Posición Nombre Bytes Descripción 0 bmrequesttype 1 fija la dirección de la transferencia 1 brequest 1 valores de 0 a 12, según se la petición. 2 wvalue 2 varía según la petición 4 windex 2 varía según la petición 6 wlength 2 número de bytes a transferir Cuadro D.1: Campos del Setup Packet. Los cinco campos que se definen el Setup Packet tienen las siguientes características: bmrequesttype: Este valor indica en la mayoría de las veces la dirección de la transferencia, especificando que parte del dispositivo va dirigida la transferencia. En caso general cuando se pregunta por descriptores del dispositivo esto significará que se desean recibir datos (Device-to-Host) y para ello se fija el valor de bmrequesttype en 0x80. Por lo contrario cuando una petición es para fijar algún valor dentro del dispositivo, esto significará que la dirección de los datos es Host-to-Device, por lo que el valor deberá de ser 0. Los dos valores mencionados son estándar para las peticiones básicas (Standard Request), sin embargo una clase especifica de dispositivo o algún fabricante pueden soportar otros valores. En el código realizado para el host se definieron los siguientes valores de uso muy común: 125

126 APÉNDICE D. CONSTRUCCIÓN DE LAS PETICIONES #define DTH #define HTD 0x80 //device to host 0x00 //host to device brequest: Este campo especifica una de las 11 peticiones standard que se pueden consultar, cada una de ellas realiza una función o tarea diferente y tienen un valor fijo sólo para el campo brequest. Las peticiones tienen el mismo valor para todos los protocolos USB ( USB 1.1 y USB 2.0) y no hay nuevas peticiones o variación de funciones de un protocolo a otro. Todas las posibles peticiones con sus respectivos valores se muestran en el cuadro D.2. Algunos de los valores están reservados para futuros usos. Nombre Valor Nombre Valor get status 0 set descriptor 7 clear feature 1 get configuration 8 reservado 2 set configuration 9 set feature 3 get interface 10 reservado 4 set interface 11 set adress 5 synch frame 12 get descriptor 6 Cuadro D.2: Peticiones Standard. Las definiciones son las siguientes: #define GET_STATUS #define CLEAR_FEATURE #define SET_FEATURE #define SET_ADDRESS #define GET_DESCRIPTOR #define SET_DESCRIPTOR #define GET_CONFIG #define SET_CONFIG #define GET_INTERFACE #define SET_INTERFACE #define SYNCH_FRAME 0x00 0x01 0x03 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c Es importante no confundir por ejemplo SET ADRESS con set adress(), lo primero define la petición dentro del Setup Packet y lo segundo es la petición que realiza la rutina para la cual fue diseñada. wvalue: Este campo varía según la petición que se esté realizando, cada petición tiene su propio valor para wvalue, pero algunos pueden definir un valor cero. La petición para solicitar los descriptores generales del los dispositivos (get descriptor) utilizan valores dependiendo sobre que cosa del dispositivo se desea solicitar, por ejemplo endpoint, configuraciones, interfaces etc. Los valores que se puede utilizar para las peticiones están estipulados en el cuadro D

127 APÉNDICE D. CONSTRUCCIÓN DE LAS PETICIONES Descriptor Tipo (wvalue) Valor device 1 configuration 2 string 3 interface 4 endpoint 5 Cuadro D.3: Tipos de descriptores. Los tipos de descriptores van el byte más significativo del campo wvalue. Las definiciones para el código se muestran a continuación: #define DEVICE #define CONFIGURATION #define STRING #define INTERFACE #define ENDPOINT 0x0100 0x0200 0x0300 0x0400 0x0500 Para USB 2.0 se definen nuevos descriptores que son: DEVICE QUALIFIER, OTH- ER SPEED CONFIGURATION, INTERFACE POWER, pero que no son soportados por controladores USB 1.1. windex: Este valor de 2 bytes varía según la petición. Su uso no está definido para una sola cosa. Por ejemplo en algunas peticiones sirve para definir el número del endpoint o definir que interfaz se desea comunicar el host. Es un parámetro específico. wlength: Este campo sólo tiene una función: indicar el largo del paquete de la transferencia en una segunda etapa. Esto es porque el host controlador, en este caso el SL811HS, es el que define a través de sus registros de configuración cuanto es el largo de los paquetes que se van a transmitir o recibir, en este caso controla el largo del Setup Packet, pero como se está realizando una petición al dispositivo éste entrega una serie de datos en una segunda etapa que no pueden ser controlados directamente por el host, sino más bien, es el campo wlength quien determina el largo de los datos. El dispositivo nunca entregará más datos de los que se indica en este valor o bien, si se define un valor cero para este campo nunca retornaría algún valor. D.2. Función Request() Para el controlador SL811HS las peticiones se realizan a través de la función construida Request(). El código de la función junto con los comentarios de la construcción se muestra a continuación: 127

128 APÉNDICE D. CONSTRUCCIÓN DE LAS PETICIONES int Request(BYTE bmrequesttype, BYTE brequest, WORD wvalue, WORD windex, WORD wlength, BYTE adress, char *ptr ) { int i, menor; int overflow; wr811(bufadr,0x10); //Comienza el buffer en la dirección 0x10 wr811(buflen,8); //Reserva 8 bytes para el setup packet wr811(fnaddr,adress); //datos de control todos en la dirección //setup packet wr811(0x10, bmrequesttype) ; // bmrequesttype wr811(0x11, brequest) ; // brequest wr811(0x12, (wvalue & 0x00FF)); // wvaluel wr811(0x13,((wvalue & 0xFF00)>>8)); // wvalueh wr811(0x14, (windex & 0x00FF)); // windexl wr811(0x15,((windex & 0xFF00)>>8) ); // windexh wr811(0x16, (wlength & 0x00FF)); // wlengthl wr811(0x17,((wlength & 0xFF00)>>8) ); // wlengthh //envio del Setup Packet result = 0; while(!(result & 0x01)) //ACK=0x01. { wr811(pid_ep,setup_pid); //Configura un PID tipo s.packet, endpoint0 result=go(0x07); // Envía el S.Packet DIREC=1(out), ENAB=1, ARM=1(0x07) } //reconfigura el tama~no del endpoint IN y del largo del buffer. if (buffer_bmaxpacketsize0<=wlength) menor=buffer_bmaxpacketsize0; else menor=wlength; wr811(buflen,buffer_bmaxpacketsize0); //asigna al buffer el tama~no mínimo del paquete. /*recibir datos de control en la pipe, si no hay datos por recibir se debe recibir un Handshake como IN*/ wr811(pid_ep,in_pid); // PID tipo IN en endpoint0 do { result = 0; while(!(result & 0x01) &&!(result==bit6)) //ACK o STALL sale. { // Si hay NAK vuelve a pedir datos. waitframes(4); result=go(0x03); } if ((result==bit6) wlength==0) //si hay STALL o no hay datos que recibir sale. { overflow=0; 128

129 APÉNDICE D. CONSTRUCCIÓN DE LAS PETICIONES return 0; //retorna 0 en caso de error. } else{ overflow=rd811(4); for(i=0;i<menor;i++) *ptr++=rd811(0x10+i); // se copian los datos a la ram } }//end do while (overflow ==0); //repite todo, hasta el overflow. return 1; //retorna 1 en caso de éxito } La función Request() retorna el valor 1 en el caso de éxito, de lo contrario retorna el valor 0. Se debe también mencionar que la función soporta al mismo tiempo las transferencias de datos del tipo Control-No-Data y Control-Read. Para el primer caso en donde las peticiones no retornan datos (Control-No-Data), la transferencia de control por lo menos debe recibir un Data-IN para el handshake, a su vez el parámetro de entrada ptr debe usar un puntero nulo 1. D.2.1. Ejemplo de la construcción de la petición Set Adress El siguiente código ilustra la construcción de la petición Set Adress usando la función Request() y las definiciones. int Set_Adress(WORD adress_nueva) { return Request(HTD, SET_ADDRESS,adress_nueva, 0x00, 0x00,0, (char *) 0); } La función Set Adress es una de las más simples de implementar porque no retorna datos (puntero nulo) y además no depende de ninguna otra petición. 1 Un puntero nulo es igual a (char *)0. 129

130 Apéndice E Construcción de los comandos SCSI En este apéndice se encuentra el detalle de los comandos SCSI que permiten la lectura y escritura de datos. Junto con ello, se muestra el llenado del buffer para el posterior envío del bloque de comando CBW. E.0.2. INQUIRY El comando INQUIRY permite obtener información generalizada del dispositivo. El código de operación corresponde al valor 0x12. El formato se muestra en el cuadro E.1. Cuadro E.1: Campo de envío del comando INQUIRY. El campo Allocation Length especifica el largo de bytes que se quieren retornar, el máximo valor es de 0x24 (formato general del retorno). Un valor distinto del valor máximo no causa error de comando. El campo Page Code es de valor cero (no es soportado en los pendrives). Por último el campo Allocation Length especifica la partición lógica del dispositivo (0 a 7). 130

131 APÉNDICE E. CONSTRUCCIÓN DE LOS COMANDOS SCSI El bloque CBW en conjunto con el comando INQUIRY se envía en la pipe Bulk del endpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envío del paquete al endpoint correspondiente, se muestra a continuación void CBW_INQUIRY() { /* * se rellena el comando CBW en el buffer y se envía como Data Out * */ wr811(bufadr,0x10); // inicio del buffer. wr811(buflen,0x1f); // reserva 31 bytes. //dcbwsignature. wr811(0x10,0x55); wr811(0x11,0x53); wr811(0x12,0x42); wr811(0x13,0x43); //dcbwtag. aleatorio para identificar. wr811(0x14,0x71); wr811(0x15,0x72); wr811(0x16,0x73); wr811(0x17,0x74); //dcbwdatatransferlength. wr811(0x18,0x24); // 36 bytes de regreso. wr811(0x19,0x00); wr811(0x1a,0x00); wr811(0x1b,0x00); //bmcbwflags wr811(0x1c,0x80); //bcbwlun wr811(0x1d,0x00); //bcbwcblength wr811(0x1e,0x06); /* CBWCB (bloque de comando SCSI=INQUIRY) INQUIRY siempre tiene el mismo formato.*/ wr811(0x1f,0x12); wr811(0x20,0x00); wr811(0x21,0x00); wr811(0x22,0x00); wr811(0x23,0x24); wr811(0x24,0x00); wr811(0x25,0x00); wr811(0x26,0x00); wr811(0x27,0x00); wr811(0x28,0x00); //código INQUIRY. //Logical Unit Number. //Allocation Length. 131

132 APÉNDICE E. CONSTRUCCIÓN DE LOS COMANDOS SCSI wr811(0x29,0x00); wr811(0x2a,0x00); wr811(0x2b,0x00); wr811(0x2c,0x00); wr811(0x2d,0x00); wr811(0x2e,0x00); //se envía como Data Out. result = 0; while(!(result & 0x01) ) { wr811(pid_ep,out_pid EndBulk.OutDir); waitframes(4); result=go((0x07 DATA_OUT )); } DATA_OUT ^= BIT6; } Cuando se realiza el comando INQUIRY, los datos que retornan se reciben como DATA- IN, en donde además, deben ser recibidos por el controlador SL811HS en forma de Data- Toggle (DATA1 y DATA0 alternadamente). Esta acotación es válida para todos los comandos SCSI que reciben datos. Los campos que retorna el comando INQUIRY es mostrado en el cuadro E.2. Cuadro E.2: Campos de retorno del comando INQUIRY. 132

133 APÉNDICE E. CONSTRUCCIÓN DE LOS COMANDOS SCSI E.0.3. READ(10) El comando READ(10) permite realizar transferencia de datos desde los dispositivos al host. Tiene un código de operación de 0x28. El formato se muestra en el cuadro E.3. Cuadro E.3: Formato del comando READ(10). Los campos DPO, FUA y RelAdr deben tener el valor 0. El bloque CBW en conjunto con el comando READ(10) se envía en la pipe Bulk del endpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envío del paquete al endpoint correspondiente, se muestra a continuación void CBW_READ(DWORD sector, BYTE veces) { /* * se rellena el comando CBW en el buffer y se envía como Data Out * */ wr811(bufadr,0x10); // inicio del buffer. wr811(buflen,0x1f); // reserva 31 bytes. //dcbwsignature. wr811(0x10,0x55); wr811(0x11,0x53); wr811(0x12,0x42); wr811(0x13,0x43); //dcbwtag. aleatorio para identificar. wr811(0x14,0x71); wr811(0x15,0x72); wr811(0x16,0x73); wr811(0x17,0x74); //dcbwdatatransferlength (512 bytes). wr811(0x18,0x00); 133

134 APÉNDICE E. CONSTRUCCIÓN DE LOS COMANDOS SCSI wr811(0x19,0x02); wr811(0x1a,0x00); wr811(0x1b,0x00); //bmcbwflags wr811(0x1c,0x80); //bcbwlun wr811(0x1d,0x00); //bcbwcblength wr811(0x1e,0x0a); /* CBWCB (bloque de comando SCSI) */ //Operation Code wr811(0x1f,0x28); wr811(0x20,0x00); //Logical Block Address wr811(0x21,((sector & 0xFF000000)>>24)); wr811(0x22,((sector & 0xFF0000)>>16)); wr811(0x23,((sector & 0xFF00)>>8)); wr811(0x24,(sector & 0x00FF)); //Reservado wr811(0x25,0x00); //Transfer Length (MSB) wr811(0x26,0x00); //Transfer Length (LSB) wr811(0x27,veces); //reservado wr811(0x28,0x00); wr811(0x29,0x00); wr811(0x2a,0x00); wr811(0x2b,0x00); wr811(0x2c,0x00); wr811(0x2d,0x00); wr811(0x2e,0x00); //se envía como Data Out. result = 0; while(!(result & 0x01) ) { wr811(pid_ep,out_pid EndBulk.OutDir); waitframes(4); result=go((0x07 DATA_OUT )); } DATA_OUT ^= BIT6; } En la función anterior, el parámetro sector indica la dirección del sector que se desea leer. El parámetro veces indica la cantidad de bloques (512 bytes) que se desean leer con- 134

135 APÉNDICE E. CONSTRUCCIÓN DE LOS COMANDOS SCSI secutivamente. E.0.4. WRITE(10) El comando WRITE(10) permite transferir datos desde el host al dispositivo. Tiene un código de operación de 0x2A. El formato de los campos se muestra en el cuadro E.4. Cuadro E.4: Campo de envío del comando INQUIRY. Los campos DPO, FUA y RelAdr deben tener el valor 0. El bloque CBW en conjunto con el comando WRITE(10) se envía en la pipe Bulk del endpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envío del paquete al endpoint correspondiente, se muestra a continuación void CBW_WRITE(DWORD sector, BYTE veces) { /* * se rellena el comando CBW en el buffer y se envía como Data Out * */ wr811(bufadr,0x10); // inicio del buffer. wr811(buflen,0x1f); // reserva 31 bytes. //dcbwsignature. wr811(0x10,0x55); wr811(0x11,0x53); wr811(0x12,0x42); wr811(0x13,0x43); //dcbwtag. aleatorio para identificar. wr811(0x14,0x71); wr811(0x15,0x72); wr811(0x16,0x73); 135

Protocolo USB CDM 2012. 22/11/2012 Autor: Ing. Jorge R. Osio 1

Protocolo USB CDM 2012. 22/11/2012 Autor: Ing. Jorge R. Osio 1 Protocolo USB CDM 2012 1 Temario Prestaciones del protocolo Principales características Elementos de una transferencia USB Enumeración de dispositivos 2 Prestaciones del protocolo Soporta variedad de dispositivos

Más detalles

USB. Ing. Pablo Martín Gomez pgomez@fi.uba.ar

USB. Ing. Pablo Martín Gomez pgomez@fi.uba.ar USB Ing. Pablo Martín Gomez pgomez@fi.uba.ar 1 USB Historia Introducido y estandarizado por un grupo de compañias Compaq, DEC, IBM, Intel, Microsoft, NEC, HP, Lucent, Philips y Nortel) en 1995 La idea

Más detalles

T-92, S.L. Interfaz USB V 2.0 Acceso a Internet. Número de referencia de la Interfaz de Acceso

T-92, S.L. Interfaz USB V 2.0 Acceso a Internet. Número de referencia de la Interfaz de Acceso T-92, S.L. Interfaz USB V 2.0 Acceso a Internet Número de referencia de la Interfaz de Acceso Versión Descripción del cambio Páginas afectadas Fecha de la versión V.1.1 Primera publicación de la Interfaz

Más detalles

USB. Teoría. INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Protocolo

USB. Teoría. INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Protocolo Protocolo USB INGENIERIA EN MICROCONTROLADORES Protocolo USB (UNIVERSAL SERIAL BUS) Teoría PROTOCOLO USB www.i-micro.com Ingeniería en Microcontroladores Teléfono 044 55 11 29 55 05 E-mail: cursos@i-micro.com

Más detalles

Electrocomponentes S.A. SASE 2011. Soluciones USB Freescale

Electrocomponentes S.A. SASE 2011. Soluciones USB Freescale Electrocomponentes S.A. SASE 2011 Soluciones USB Freescale Beneficios del USB Puertos RS232 desapareciendo Fácil de Usar Rápido Bajo Costo Confiable Bajo consumo Beneficios del USB Fácil de usar: Una interfase

Más detalles

CeTAD (Centro de Técnicas Analógico Digitales) Facultad de Ingeniería Universidad Nacional de La Plata

CeTAD (Centro de Técnicas Analógico Digitales) Facultad de Ingeniería Universidad Nacional de La Plata CeTAD (Centro de Técnicas Analógico Digitales) Facultad de Ingeniería Universidad Nacional de La Plata Contacto: jorge.osio@ing.unlp.edu.ar 29/08/2012 Autores: Ing. Luis Antonini - Ing. Jorge Osio 1 Temario

Más detalles

Firmware para dispositivo esclavo USB de Clase HID

Firmware para dispositivo esclavo USB de Clase HID Firmware para dispositivo esclavo USB de Clase HID Emanuel G. Aguirre, Pablo A. Di Giulio Universidad Tecnológica Nacional, Facultad Regional San Francisco Abstract El objetivo del presente trabajo es

Más detalles

USB 3.0 SuperSpeed. t e c n o l o g í a usb

USB 3.0 SuperSpeed. t e c n o l o g í a usb t e c n o l o g í a usb Por José Luis Rupérez Fombellida (España) El Bus Serie Universal (USB) nació en 1996 para conectar fácilmente diferentes dispositivos a un ordenador mediante conexión serie. Desde

Más detalles

Sistemas de Almacenamiento y Periféricos. ricos

Sistemas de Almacenamiento y Periféricos. ricos Sistemas de Almacenamiento y Periféricos ricos 1 Sistemas de Almacenamiento y Periféricos ricos -Almacenamiento Interfaces: ATA/IDE, SCSI, SATA Dispositivos: Discos duros, almacenamiento óptico, FLASH

Más detalles

Número de referencia de la Interfaz de Acceso

Número de referencia de la Interfaz de Acceso Interfaz USB V.1.1 Acceso a Internet Número de referencia de la Interfaz de Acceso Versión Descripción del cambio Páginas afectadas Fecha de la versión V.1.1 Primera publicación de la Interfaz Todas 30-06-2001

Más detalles

USB (Universal Serial Bus)

USB (Universal Serial Bus) USB (Universal Serial Bus) USB es una interfaz para transmisión de datos y distribución de energía que ha sido introducida en el mercado de PC s y periféricos para mejorar las lentas interfaces serie (RS-232)

Más detalles

2.6 Componentes Conectores. 2.6.1 Puertos serie y paralelos

2.6 Componentes Conectores. 2.6.1 Puertos serie y paralelos 2 2.6 Componentes Conectores 2.6.1 Puertos serie y paralelos 109 Un puerto de I/O es una ruta hacia y fuera de la computadora a través de un conector que se encuentra en su parte posterior. Todos los dispositivos

Más detalles

INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB

INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB INTERFACE DE TRANSFERENCIA DE DATOS A TRAVÉS DEL BUS USB Ing.Pedro Ignacio Martos, pmartos@fi.uba.ar Facultad de Ingeniería, Universidad de Buenos Aires Resumen: En aplicaciones de control que requieren

Más detalles

Componentes de una Red

Componentes de una Red Qué es una red? Una red de computadoras (también llamada red de computadoras o red informática) es un conjunto de equipos (computadoras y/o dispositivos) conectados por medio de cables, señales, ondas

Más detalles

BUSES GRUPO 8 Miguel París Dehesa Ricardo Sánchez Arroyo

BUSES GRUPO 8 Miguel París Dehesa Ricardo Sánchez Arroyo BUSES GRUPO 8 Miguel París Dehesa Ricardo Sánchez Arroyo - Trabajo de ampliación. BUSES. - 1 INDICE 1. Introducción 2. Integrated Drive Electronics (IDE) (1986) 3. Universal Serial Bus (USB) (1996) 4.

Más detalles

Unidad 3: El sistema operativo. Trabajo con conexión.

Unidad 3: El sistema operativo. Trabajo con conexión. Unidad 3: El sistema operativo. Trabajo con conexión. 1.- Red de ordenadores Vamos a describir que es una red informática o red de ordenadores. Una red informática es un sistema de interconexión entre

Más detalles

La motivación que ha dado origen al Bus Serial Universal proviene de tres aspectos fuertemente interrelacionados: 1. Conexión del teléfono a la PC

La motivación que ha dado origen al Bus Serial Universal proviene de tres aspectos fuertemente interrelacionados: 1. Conexión del teléfono a la PC Universal Serial Bus The Easy Way to Plug & Play INTRODUCCION Cada cierto tiempo dentro del mundo de la computación se dan cambios realmente importantes, cambios que de cierta forma abren nuevos horizontes

Más detalles

Elección De Componentes De Reemplazo Para Una PC

Elección De Componentes De Reemplazo Para Una PC Área y Sub-área: Informatica/Reparacion De PC Educador: _Luis Orozco Ciclo Escolar: 2015 Grado: 5to Secciones: A,B,C y D Elección De Componentes De Reemplazo Para Una PC Gabinete y fuente de energía Antes

Más detalles

INSTITUTO POLITÉCNICO NACIONAL

INSTITUTO POLITÉCNICO NACIONAL INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA SISTEMA DE ALMACENAMIENTO DE DATOS UTILIZANDO MEMORIA SDRAM, UN FPGA Y COMUNICACIÓN USB TESIS QUE PARA OBTENER EL TÍTULO

Más detalles

GUÍA PARA CAPTURA E IMPORTACIÓN DE VÍDEO CON CAMARA DE VIDEO DIGITAL A TRAVÉS DE LOS PUERTOS USB E I LINK

GUÍA PARA CAPTURA E IMPORTACIÓN DE VÍDEO CON CAMARA DE VIDEO DIGITAL A TRAVÉS DE LOS PUERTOS USB E I LINK GUÍA PARA CAPTURA E IMPORTACIÓN DE VÍDEO CON CAMARA DE VIDEO DIGITAL A TRAVÉS DE LOS PUERTOS USB E I LINK Presentado por CINDY JULIETTE BERNAL TABORDA JHOAN ALEJANDRO GARCÍA TRUJILLO LUIS DAVID MALES JOHN

Más detalles

2.1 Discos Duros y Bus IDE

2.1 Discos Duros y Bus IDE Capítulo 2 Marco Teórico Para iniciar con este capítulo se presenta información general de los discos duros y del bus IDE que usan las computadoras personales. En las secciones siguientes se presenta una

Más detalles

Sistema Modular de Adquisición de Datos

Sistema Modular de Adquisición de Datos Sistema Modular de Adquisición de Datos AUTOR: Raúl Bartolomé Castro. DIRECTOR: Alfonso Romero Nevado. FECHA: Octubre / 2004. Sistema Modular de Adquisición de Datos 1 Índice AUTOR: Raúl Bartolomé Castro.

Más detalles

Capítulo 3 Fundamentos de una PC

Capítulo 3 Fundamentos de una PC Fundamentos de una PC Es importante saber reconocer y denominar los componentes básicos de una PC. Una PC es una pequeña red de computadoras. Fundamentos de una PC Componentes electrónicos.- Transistor

Más detalles

Puertos de comunicación del PC.

Puertos de comunicación del PC. Puertos de comunicación 1/7 Puertos de comunicación del PC. PUERTOS DE COMUNICACION: QUE SON Y PARA QUE SIRVEN. Los puertos de comunicación, como su nombre indica, son una serie de puertos que sirven para

Más detalles

Proyecto de Grado. Estado del Arte. Interfaz USB genérica para comunicación con dispositivos electrónicos

Proyecto de Grado. Estado del Arte. Interfaz USB genérica para comunicación con dispositivos electrónicos Proyecto de Grado Interfaz USB genérica para comunicación con dispositivos electrónicos Estado del Arte A/C Andrés Aguirre, A/C Pablo Fernández y A/C Carlos Grossy Tutores: MSc Ing. Gonzalo Tejera y MSc

Más detalles

2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA. JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5.

2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA. JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5. ARQUITECTURAS DE COMPUTADORES 2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5. Unidad de E/S 1 Unidad de E/S Indice Introducción.

Más detalles

FUNDAMENTOS DE INFORMATICA

FUNDAMENTOS DE INFORMATICA FUNDAMENTOS DE INFORMATICA TEMAS QUE SE TRATARÁN: Arquitectura Interna Sistemas Operativos Programación en Visual Basic Bases de Datos Redes e Internet 1 FUNDAMENTOS DE INFORMATICA Tema 1: Arquitectura

Más detalles

Denominamos Ordenador o Computadora, a una máquina electrónica que es capaz de dar un tratamiento automatizado a la información.

Denominamos Ordenador o Computadora, a una máquina electrónica que es capaz de dar un tratamiento automatizado a la información. INTRODUCCIÓN AL ORDENADOR Denominamos Ordenador o Computadora, a una máquina electrónica que es capaz de dar un tratamiento automatizado a la información. Se compone de dos elementos fundamentales que

Más detalles

Diseño del módulo RS-232. Por Michael Kusch tintronic@yahoo.com Versión preliminar 0.2

Diseño del módulo RS-232. Por Michael Kusch tintronic@yahoo.com Versión preliminar 0.2 Diseño del módulo RS-. Por Michael Kusch tintronic@yahoo.com Versión preliminar 0. Introducción Muchos microcontroladores poseen una interfaz UART o USART para comunicación serial asincrónica, tipo RS-,

Más detalles

Introducción. Trabajo Práctico de TAI 2 - PCI Express Página 1

Introducción. Trabajo Práctico de TAI 2 - PCI Express Página 1 Introducción El Bus PCI ha sido utilizado ampliamente utilizado por mas de una década y aun se seguirá utilizando por lo menos un poco mas. Sin embargo, dado el gran avance tecnológico, tanto los procesadores

Más detalles

Cuál es el secreto de esta Tecnología, como logra que varios usuarios trabajen sobre un ordenador (PC)?

Cuál es el secreto de esta Tecnología, como logra que varios usuarios trabajen sobre un ordenador (PC)? De qué se compone el Terminal? El dispositivo NComputing tiene un chip propietario, una placa de red, una memoria caché para el vídeo y una memoria flash para el firmware (El setup inicial, se conoce como

Más detalles

PROPUESTA DE ESTUDIO (febrero 2004 marzo 2005) SISTEMA DE DESPLIEGUE PANORÁMICO EN TRESCOLORES PARA TEXTO Y ANIMACIONES.

PROPUESTA DE ESTUDIO (febrero 2004 marzo 2005) SISTEMA DE DESPLIEGUE PANORÁMICO EN TRESCOLORES PARA TEXTO Y ANIMACIONES. PROPUESTA DE ESTUDIO (febrero 2004 marzo 2005) TÍTULO: SISTEMA DE DESPLIEGUE PANORÁMICO EN TRESCOLORES PARA TEXTO Y ANIMACIONES. Registro asignado por CGPI: 20040678 CENTRO: CENTRO DE INNOVACIÓN Y DESARROLLO

Más detalles

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de datos y la tipología de redes que se emplean. Además este

Más detalles

TEMA 3: Buses, puertos e interfaces

TEMA 3: Buses, puertos e interfaces TEMA 3: Buses, puertos e interfaces Contenidos 1. Introducción. de buses. 3. Jerarquía de buses. 4. Ejemplos de buses. 5. Puertos e interfaces. 6. Ejemplos de puertos e interfaces. Periféricos de Computadores

Más detalles

Taller de Operaciones Informáticas

Taller de Operaciones Informáticas Taller de Operaciones Informáticas Unidad 1: Componentes Físicos de un Sistema Informático 4- Qué es el motherboard? Identificar modelos, y elementos conectados sobre ella. Es la parte principal de una

Más detalles

Trabajo Practico Análisis placa madre

Trabajo Practico Análisis placa madre Trabajo Practico Análisis placa madre Facultad de Tecnología Informática Cátedra: OFC Comisión: 560 Integrantes: Alejo Julián Alfonso Profesor: Sergio Omar Aguilera Año: 1ero. Comentario [S1]: Muy bien.

Más detalles

En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el

En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el Capítulo 2 Estándar IEEE 802.11 En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el WEP como protocolo de seguridad. Se mencionan las características generales de

Más detalles

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876.

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Prof: Bolaños D. En unión del hardware adecuado, el software IC-PROG permite programar gran cantidad de dispositivos electrónicos. Esta guía

Más detalles

CABLES Y CONECTORES EN COMPUTACION

CABLES Y CONECTORES EN COMPUTACION CABLES Y CONECTORES EN COMPUTACION La costumbre hace que cuando contestamos alguna pregunta relacionada con un PC digamos que compruebe tal o cual cable o que mire este o aquel conector, pero pocas veces

Más detalles

Adaptador USB a LPT para la recuperación de equipos de rehabilitación

Adaptador USB a LPT para la recuperación de equipos de rehabilitación Adaptador USB a LPT para la recuperación de equipos de rehabilitación Javier Barragan; Fernando Anaut, Jorge Osio* 1 ; José Rapallini 1 ; Flavio Ferrari 2 ; Facultad de Ingeniería - Universidad Nacional

Más detalles

Compresión y comunicación de datos con un microcontrolador PIC. TITULACIÓN: Ingeniería Técnica Industrial en Electrónica Industrial

Compresión y comunicación de datos con un microcontrolador PIC. TITULACIÓN: Ingeniería Técnica Industrial en Electrónica Industrial Compresión y comunicación de datos con un microcontrolador PIC TITULACIÓN: Ingeniería Técnica Industrial en Electrónica Industrial AUTOR: Miguel Periago de la Torre DIRECTOR: Nicolau Cañellas Alberich

Más detalles

Utilización de los puertos serial y paralelo de una PC usando LabView

Utilización de los puertos serial y paralelo de una PC usando LabView Universidad del Táchira Departamento de Ingeniería Electrónica Instrumentación Electrónica Utilización de los puertos serial y paralelo de una PC usando LabView Hecho Por: Ing. Rafael Chacón Ing. José

Más detalles

UNIDAD FORMATIVA 1: Instalación y Configuración de los Nodos de Area Local

UNIDAD FORMATIVA 1: Instalación y Configuración de los Nodos de Area Local UNIDAD FORMATIVA 1: Instalación y Configuración de los Nodos de Area Local OBJETIVOS: - Explicar las topologías de una red local en función de las tecnologías y arquitecturas existentes. - Clasificar los

Más detalles

Guía DUB-A2 y sistema operativo Windows XP

Guía DUB-A2 y sistema operativo Windows XP Guía DUB-A2 y sistema operativo Windows XP D-Link ha desarrollado una completa solución de conectividad USB 1.1 o 2.0, lo cual permite abrir puertos bajo ese estándar en las computadoras de escritorio

Más detalles

MODULO 4: EL DISCO DURO

MODULO 4: EL DISCO DURO MODULO 4: EL DISCO DURO Es un dispositivo mecánico por la forma de acceder a la información (cabeza que se mueve sobre el disco) y electrónico ya que guarda los datos en señales magnéticas. Es de alta

Más detalles

REDES DE COMPUTADORAS INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD ADOLFO LÓPEZ MATEOS - ZACATENCO

REDES DE COMPUTADORAS INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD ADOLFO LÓPEZ MATEOS - ZACATENCO INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD ADOLFO LÓPEZ MATEOS - ZACATENCO ACADEMIA DE COMPUTACIÓN LABORATORIO DE DESARROLLO DE REDES PRACTICA No.2 México

Más detalles

Tecnología de la Información y las Comunicaciones. Colegio Bosque Del Plata. UNIDAD 6 Hardware Procesador y Unidades de Almacenamiento.

Tecnología de la Información y las Comunicaciones. Colegio Bosque Del Plata. UNIDAD 6 Hardware Procesador y Unidades de Almacenamiento. Colegio Bosque Del Plata Tecnología de la Información y las Comunicaciones UNIDAD 6 Hardware Procesador y Unidades de Almacenamiento. E-mail: garcia.fernando.j@gmail.com Profesor: Fernando J. Garcia Ingeniero

Más detalles

Dispositivos de Entrada/Salida

Dispositivos de Entrada/Salida Dispositivos E/S. CPU Memoria Central Tarjeta de Red Red BUS Controlador de Discos Dispositivos E/S Dispositivos E/S. Los dispositivos de Entrada/Salida sirven al ordenador para obtener información del

Más detalles

Introducción a la Entrada/Salida

Introducción a la Entrada/Salida Introducción a la Entrada/Salida Organización de entrada/salida La familia de procesadores 80x86, presente en el IBM PC, utiliza la arquitectura Von Neumann, que puede verse en la figura 1. El denominado

Más detalles

ProRAE Guardian V1.5 Guía de referencia rápida

ProRAE Guardian V1.5 Guía de referencia rápida ProRAE Guardian V1.5 Guía de referencia rápida Para obtener una descripción completa de las funciones del programa, consulte la Guía del usuario de ProRAE Guardian (incluida en el CD de software). CONTENIDO

Más detalles

Guía DUB-C2 y sistema operativo Windows XP

Guía DUB-C2 y sistema operativo Windows XP Guía DUB-C2 y sistema operativo Windows XP D-Link ha desarrollado una completa solución de conectividad USB 1.1 o 2.0, lo cual permite abrir puertos bajo ese estándar en las computadoras de escritorio

Más detalles

1. INTRODUCCIÓN A LAS REDES

1. INTRODUCCIÓN A LAS REDES 1. INTRODUCCIÓN A LAS REDES CONCEPTO El término genérico "red" hace referencia a un conjunto de entidades (objetos, personas, etc.) conectadas entre sí con el objetivo de compartir cualquier tipo de recursos.

Más detalles

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa.

Archivo de programa Es el que inicia una aplicación o un programa y tiene una extensión EXE, PIF, COM, BAT. Véase también Programa. Glosario de términos Ancho de Banda El ancho de banda es la máxima cantidad de datos que pueden pasar por un camino de comunicación en un momento dado, normalmente medido en segundos. Cuanto mayor sea

Más detalles

Entrada salida y comunicación

Entrada salida y comunicación Entrada salida y comunicación E/S de los computadores Introducción: Variedad de dispositivos. Modo de transfer. Tipo de información. Diferencias de velocidades (tasas de transferencias). Ejemplos de periféricos:

Más detalles

Rede de área local (LAN)

Rede de área local (LAN) Rede de área local (LAN) LAN son las siglas de Local Area Network, Red de área local. Una LAN es una red que conecta los ordenadores en un área relativamente pequeña y predeterminada (como una habitación,

Más detalles

REDES DE COMPUTADORAS

REDES DE COMPUTADORAS REDES DE COMPUTADORAS INTRODUCCIÓN Qué es una RED DE COMPUTADORAS?: Conjunto de computadoras interconectadas a través de un medio común. POR QUÉ USAR UNA RED? Las organizaciones implementan redes con el

Más detalles

5. Interfaces de comunicación para la televisión digital (parte II)

5. Interfaces de comunicación para la televisión digital (parte II) Interfaces de comunicación para la televisión digital 5. Interfaces de comunicación para la televisión digital (parte II) Una vez digitalizada la información de video, y considerando que todos los equipos

Más detalles

Tema 1: Sistemas Informáticos Unit 1 : Computing systems. Parte 1: arquitectura de un ordenador personal Part 1 : architecture of a personal computer

Tema 1: Sistemas Informáticos Unit 1 : Computing systems. Parte 1: arquitectura de un ordenador personal Part 1 : architecture of a personal computer Tema 1: Sistemas Informáticos Unit 1 : Computing systems Parte 1: arquitectura de un ordenador personal Part 1 : architecture of a personal computer Qué vamos a ver? Qué es un sistema informático y qué

Más detalles

COMUNICACIÓN Y REDES DE COMPUTADORES II. Clase 02. Aspetos basicos de Networking Parte 1 de 2

COMUNICACIÓN Y REDES DE COMPUTADORES II. Clase 02. Aspetos basicos de Networking Parte 1 de 2 COMUNICACIÓN Y REDES DE COMPUTADORES II Clase 02 Aspetos basicos de Networking Parte 1 de 2 1 Contenido de la Clase 1. Terminología de Networking 1. Redes de Datos 2. Historia de las redes informáticas

Más detalles

Ejemplos de una tarjeta Madre o Principal:

Ejemplos de una tarjeta Madre o Principal: Tarjeta Madre o Principal La Tarjeta Madre, también conocida como Tarjeta Principal, Mainboard, Motherboard, etc. es el principal y esencial componente de toda computadora, ya que allí donde se conectan

Más detalles

Guía de selección de hardware Windows MultiPoint Server 2010

Guía de selección de hardware Windows MultiPoint Server 2010 Guía de selección de hardware Windows MultiPoint Server 2010 Versión de documento 1.0 Publicado en marzo del 2010 Información sobre los derechos de reproducción Este documento se proporciona como está.

Más detalles

ENTRADA PROCESAMIENTO SALIDA

ENTRADA PROCESAMIENTO SALIDA SEMINARIO DIOCESANO DE CRISTO SACERDOTE TECNOLOGIA E INFORMATICA DOCENTE: CARLOS ARMANDO CABAL MUÑOZ GRADO: 6 TEMA: EL COMPUTADOR OBJETIVOS Identificar los componentes y dispositivos de un sistema computacional.

Más detalles

ORBI 2012 Programador Universal USB Manual del Usuario

ORBI 2012 Programador Universal USB Manual del Usuario 1 ORBI 2012 Programador Universal USB Manual del Usuario 2 ORBI 2012 Programador Universal USB Manual del Usuario Indice : 1. Introducción 2 2. Principios de funcionamiento 2 3. Instalación del programador

Más detalles

Tarjeta IEEE 1394. Versión 1.0

Tarjeta IEEE 1394. Versión 1.0 Tarjeta IEEE 1394 Versión 1.0 Contenido 1.0 Qué es IEEE1394?.P.2 2.0 Características de 1394..P.2 3.0 Requisitos de sistema de PC..P.2 4.0 Información técnica..p.3 5.0 Instalación del hardware...p.3 6.0

Más detalles

Periféricos Interfaces y Buses

Periféricos Interfaces y Buses Periféricos Interfaces y Buses I. Arquitectura de E/S II. Programación de E/S III. Interfaces de E/S de datos IV. Dispositivos de E/S de datos V. Buses VI. Controladores e interfaces de dispositivos de

Más detalles

Cableado estructurado

Cableado estructurado Los conectores de internet router,hud,switch, Concentrador Introducción Para los servicios de internet te varios aparatos conectados para que funcione de forma correcta Entre estos estas router,hud, switch

Más detalles

BUSES. Una comunicación compartida Un conjunto de cables para comunicar múltiples subsistemas. Memoria

BUSES. Una comunicación compartida Un conjunto de cables para comunicar múltiples subsistemas. Memoria BUSES UPCO ICAI Departamento de Electrónica y Automática 1 Qué es un bus? Una comunicación compartida Un conjunto de cables para comunicar múltiples subsistemas Procesador Control Datapath Memoria Entrada

Más detalles

Fundamentos de Redes de Computadoras

Fundamentos de Redes de Computadoras Fundamentos de Redes de Computadoras Modulo III: Fundamentos de Redes de Area Extendida (WAN) Objetivos Redes conmutadas Circuito Paquetes Conmutación por paquetes Datagrama Circuito virtual Frame Relay

Más detalles

PUERTOS DE COMUNICACIÓN EXTERNOS TIPO VELOCIDAD DESCRIPCION GRAFICO

PUERTOS DE COMUNICACIÓN EXTERNOS TIPO VELOCIDAD DESCRIPCION GRAFICO PUERTOS DE COMUNICACIÓN EXTERNOS TIPO VELOCIDAD DESCRIPCION GRAFICO PUERTO PS/2 150 Kbytes/seg. La comunicación en ambos casos es serial (bidireccional en el caso del teclado), y controlada por microcontroladores

Más detalles

GRUPO SEMILLERO DE BIONANOELECTRÓNICA ING. LEWIN LÓPEZ JULIO 2009

GRUPO SEMILLERO DE BIONANOELECTRÓNICA ING. LEWIN LÓPEZ JULIO 2009 GRUPO SEMILLERO DE BIONANOELECTRÓNICA ING. LEWIN LÓPEZ JULIO 2009 Problema: falta de flexibilidad en la reconfiguración de todo computador MS-DOS Windows 95 facilidad PCI ISA PCMCIA facilidad? 1 USB -

Más detalles

Manual de Instalación de BioClock

Manual de Instalación de BioClock www.biotracksoftware.com 1 TABLA DE CONTENIDOS 1 ANTES DE INSTALAR... 1 1.1 NOTA... 1 1.2 PANEL DE OPERACIÓN DEL DISPOSITIVO... 2 1.3 PUERTOS DE ALIMENTACIÓN ELÉCTRICA Y COMUNICACIÓN... 3 1.4 CONTENIDO

Más detalles

Capítulo 5 Fundamentos de Ethernet

Capítulo 5 Fundamentos de Ethernet Ethernet, en sus varias formas, es la tecnología de red de área local (LAN) más ampliamente utilizada. Los objetivos de su diseño incluye la simplicidad, un bajo coste, la compatibilidad, el poco retardo

Más detalles

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma INFORMÁTICA Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma Informática Teoría Unidad 5 Prof. Ing Ezequiel Benavente Ciclo lectivo 2014 Definición Redes de Computadoras:

Más detalles

COMUNICACIONES. Medios para transmitir señales: Conexión por lazo de corriente 4 20 ma. Transmisión analógica: corriente proporcional a una magnitud

COMUNICACIONES. Medios para transmitir señales: Conexión por lazo de corriente 4 20 ma. Transmisión analógica: corriente proporcional a una magnitud PLCs COMUNICACIONES Introducción Medios para transmitir señales: Conexión por lazo de corriente 4 20 ma Transmisión analógica: corriente proporcional a una magnitud Extremo receptor incluye un conversor

Más detalles

MON AMI MATRIZ DE LEDS 7X30 Manual del Usuario

MON AMI MATRIZ DE LEDS 7X30 Manual del Usuario 1 MON AMI MATRIZ DE LEDS 7X30 Manual del Usuario 2 MON AMI MATRIZ DE LEDS 7X30 Manual del Usuario Indice : 1. Introducción 2 2. Características principales 3 3. Software MON AMI v2.0.exe y Tiny 3 4. Puesta

Más detalles

conjunto de dispositivos físicos que hacen posible el funcionamiento de un computador.

conjunto de dispositivos físicos que hacen posible el funcionamiento de un computador. Se denomina HARDWARE a todo el conjunto de dispositivos físicos que hacen posible el funcionamiento de un computador. Este concepto abarca a todos los componentes eléctricos y mecánicos que permiten llevar

Más detalles

Placa de control MCC03

Placa de control MCC03 Placa de control MCC03 Placa de control MCC03 La placa de control basada en el micro controlador PIC 16F874A de Microchip, es la encargada del procesar los datos que se introducen en el sistema y actuar

Más detalles

CONCEPTOS INFORMÁTICOS BÁSICOS

CONCEPTOS INFORMÁTICOS BÁSICOS CONCEPTOS INFORMÁTICOS BÁSICOS Informática Def 1: Se define como la ciencia que estudia el tratamiento Def 2: Ciencia que estudia la de una forma lógica y racional, empleando para ello medios humanos,

Más detalles

Tema 10: Buses de comunicación

Tema 10: Buses de comunicación Tema 10: Buses de comunicación Objetivos: Comprender la estructura y el funcionamiento de un bus como elemento de comunicación entre diferentes unidades de un computador. Analizar la forma de sincronización

Más detalles

DISCOS DUROS. Grupo 11: Arkaitz Lázaro Abel Velasco

DISCOS DUROS. Grupo 11: Arkaitz Lázaro Abel Velasco DISCOS DUROS Grupo 11: Arkaitz Lázaro Abel Velasco Índice: 1. Que es un disco duro? 2. Estructura física de un disco duro 3. Especificaciones hardware fundamentales de un disco duro - El formato físico

Más detalles

Lector de tarjetas SD en microcontrolador NXP. Ing. Luis Antonini*; Ing. Jorge Osio*; Ing. Jose Rapallini

Lector de tarjetas SD en microcontrolador NXP. Ing. Luis Antonini*; Ing. Jorge Osio*; Ing. Jose Rapallini Segundas Jornadas de Investigación y Transferencia - 2013 Lector de tarjetas SD en microcontrolador NXP Ing. Luis Antonini*; Ing. Jorge Osio*; Ing. Jose Rapallini Centro de Técnicas Analógico Digitales

Más detalles

3º- Arquitectura de red : Bus : Los ordenadores parten de una ramal centrada. Anillo : Los equipos rompen loa red forman un anillo.

3º- Arquitectura de red : Bus : Los ordenadores parten de una ramal centrada. Anillo : Los equipos rompen loa red forman un anillo. TEMA 1 Redes de área local 1º- Redes informáticas : Una red de área local, también conocida como LAN ( Local Area Network ), es un conjunto de ordenadores y dispositivos de hadware unidos entre sí con

Más detalles

CAPITULO 1. Redes de Area Local LAN

CAPITULO 1. Redes de Area Local LAN CAPITULO 1 Redes de Area Local LAN Objetivos Dispositivos de LAN Básicos Evolución de los dispositivos de Red Aspectos básicos del flujo de datos a través de las LAN s Desarrollo de una LAN Qué son las

Más detalles

REDES INFORMATICAS 1. CONCEPTO DE RED. PDF created with pdffactory trial version www.pdffactory.com. Departamento de Tecnología 4º E.S.O.

REDES INFORMATICAS 1. CONCEPTO DE RED. PDF created with pdffactory trial version www.pdffactory.com. Departamento de Tecnología 4º E.S.O. REDES INFORMATICAS Departamento de Tecnología INDICE 1. CONCEPTO DE RED. 2. CLASIFICACION DE LAS REDES. 3. COMPONENTES HARDWARE DE UNA RED. 4. TOPOLOGIA DE LAS REDES. 5. CONTROL DE ACCESO AL MEDIO DE TRANSMISION.

Más detalles

UNIVERSIDAD TECNOLÓGICA ECOTEC FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES Y TELECOMUNICACIONES LA ARQUITECTURA BLADE SISTEMAS OPERATIVOS I

UNIVERSIDAD TECNOLÓGICA ECOTEC FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES Y TELECOMUNICACIONES LA ARQUITECTURA BLADE SISTEMAS OPERATIVOS I UNIVERSIDAD TECNOLÓGICA ECOTEC FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES Y TELECOMUNICACIONES LA ARQUITECTURA BLADE SISTEMAS OPERATIVOS I CÉSAR ZÚÑIGA SAN LUCAS PROFESOR: INGENIERA SARA NORIEGA

Más detalles

Redes de área local Javier Fernández Rivera - www.aurea.es

Redes de área local Javier Fernández Rivera - www.aurea.es Redes de área local Javier Fernández Rivera - www.aurea.es Para que se proveen las redes de área local? 1. Para compartir recursos, tanto de software como de hardware 2. Para compartir información 3. Para

Más detalles

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos.

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos. RAIDS MODO LINEAL Es un tipo de raid que muestra lógicamente un disco pero se compone de 2 o más discos. Solamente llena el disco 0 y cuando este está lleno sigue con el disco 1 y así sucesivamente. Este

Más detalles

DIFERENTES TIPOS DE CABLES Y CONECTORES DEL PC

DIFERENTES TIPOS DE CABLES Y CONECTORES DEL PC Página 1 de 7 DIFERENTES TIPOS DE CABLES Y CONECTORES DEL PC 1. Cables de datos: Los principales cables (también llamados fajas) utilizados para la transmisión de datos son: 1.1 Faja FDD o de disquetera:

Más detalles

SNIFFER USB 2.0 (FULL SPEED) Julián S. Bruno, Jerónimo F. Atencio, Pablo H. Gómez Martino

SNIFFER USB 2.0 (FULL SPEED) Julián S. Bruno, Jerónimo F. Atencio, Pablo H. Gómez Martino SNIFFER USB 2.0 (FULL SPEED) Julián S. Bruno, Jerónimo F. Atencio, Pablo H. Gómez Martino Departamento de Ingeniería Electrónica Universidad Tecnológica Nacional FRBA Av. Medrano 951, Buenos Aires, Argentina

Más detalles

SoftXpand 2011 Guía de instalación rápida Página 1 SoftXpand 2011 Guía de instalación rápida

SoftXpand 2011 Guía de instalación rápida Página 1 SoftXpand 2011 Guía de instalación rápida SoftXpand 2011 Guía de instalación rápida Página 1 SoftXpand 2011 Guía de instalación rápida Recomendamos ampliamente seguir las instrucciones siguientes al instalar SoftXpand 2011. Instalación de SoftXpand

Más detalles

5.- Qué significan las siglas DNS? Sistema de Nombres de Dominios.

5.- Qué significan las siglas DNS? Sistema de Nombres de Dominios. 1.- Cuál es su función de un protocolo en una red? Define las reglas y procedimientos para transmitir datos. 2.- Menciona por que utilizan los protocolos el emisor y el receptor Romper el dato en paquetes,

Más detalles

DISPOSITIVO DE ALMACENAMIENTO ESTANDAR PARA SOLUCION EMBEBIDA

DISPOSITIVO DE ALMACENAMIENTO ESTANDAR PARA SOLUCION EMBEBIDA DISPOSITIVO DE ALMACENAMIENTO ESTANDAR PARA SOLUCION EMBEBIDA Di Giulio, Pablo Andrés / Grupo T.D.A. / Departamento de Ingeniería Electrónica / U.T.N. Facultad Regional San Francisco CONTEXTO El grupo

Más detalles

Principales elementos de una RED

Principales elementos de una RED Principales elementos de una RED: Principales Componentes de una RED Libreta: Articulos Creado: 27/03/2014 9:27 p. m. A ctualizado: 27/03/2014 9:33 p. m. URLO rigen: http://elementosderedadpq.blogspot.com/2012/10/principales-componentes-de-una-red.html

Más detalles

Potente PLC para todo tipo de industria

Potente PLC para todo tipo de industria Potente PLC para todo tipo de industria OPLC Vision 1040 La serie V1040 es un potente PLC con un panel de operador integrado HMI que comprende una pantalla táctil color de 10,4 y nueve teclas de función

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA DISEÑO DE UN SISTEMA DE ADQUISICIÓN DE DATOS UTILIZANDO EL PROTOCOLO USB EN UN MICROCONTROLADOR AVR Tesis para optar el Título

Más detalles

MANUAL DE USUARIO CONVERSOR TCP/IP A RS232 Y TCP/IP A RS485

MANUAL DE USUARIO CONVERSOR TCP/IP A RS232 Y TCP/IP A RS485 MANUAL DE USUARIO CONVERSOR TCP/IP A RS232 Y TCP/IP A RS485 ZEBRA ELECTRÓNICA 2 ÍNDICE MANUAL DE USUARIO CONVERSOR TCP/IP A RS232 Y TCP/IP A RS485 Pág. 1. CONVERSORES TCP A RS232 / TCP A RS485... 3 1.1.

Más detalles

INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia

INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia Qué es una Red? Es un grupo de computadores conectados mediante cables o algún otro medio. Para que? compartir recursos. software

Más detalles

INFORMATICA A BORDO CAPITULO 33. EL PORTATIL (y II)

INFORMATICA A BORDO CAPITULO 33. EL PORTATIL (y II) INFORMATICA A BORDO CAPITULO 33 EL PORTATIL (y II) Una vez elegida, en la anterior entrega, la marca y el sistema operativo óptimos para nuestras necesidades, debemos analizar los requisitos que debemos

Más detalles

Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular.

Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular. Que es una red? Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular. Cuantos tipos de redes hay? Red de área personal,

Más detalles

Redes (IS20) Ingeniería Técnica en Informática de Sistemas. http://www.icc.uji.es. CAPÍTULO 6: Estándares en LAN

Redes (IS20) Ingeniería Técnica en Informática de Sistemas. http://www.icc.uji.es. CAPÍTULO 6: Estándares en LAN Redes (IS20) Ingeniería Técnica en Informática de Sistemas http://www.icc.uji.es CAPÍTULO 6: Estándares en LAN ÍNDICE (Ethernet) 3. Estándar IEEE 802.2 (LLC) 4. Estándar IEEE 802.4 (Token Bus) Curso 2002-2003

Más detalles