diseno de un driver para dispositivos˜ de almacenamiento ...lsb/elo325/clases/memoria...

UNIVERSIDAD TECNICA FEDERICO SANTA MARIADEPARTAMENTO DE ELECTRONICA

——————————————————————————————–

DISENO DE UN DRIVER PARA DISPOSITIVOSDE ALMACENAMIENTO MASIVO USB

Alexander Illich Volantines RiveraIngenierıa Civil Electronica

Diciembre del 2006——————————————————————————————–

UNIVERSIDAD TECNICA FEDERICO SANTA MARIADEPARTAMENTO DE ELECTRONICA

——————————————————————————————–

DISENO DE UN DRIVER PARA DISPOSITIVOSDE ALMACENAMIENTO MASIVO USB

Memoria presentada por

Alexander Illich Volantines Rivera

Como requisito parcial para la obtencion del tıtulo de

Ingeniero Civil Electronico

Profesor Guıa:

Sr. Leopoldo Silva Bijit

ValparaısoDiciembre del 2006

——————————————————————————————–

tıtulo de la memoria

DISENO DE UN DRIVER PARA DISPOSITIVOS DE ALMACENAMIENTOMASIVO USB

AUTOR


TRABAJO DE MEMORIA, presentado en cumplimiento parcial de los requisitospara el Tıtulo de Ingeniero Civil Electronico de la Universidad Tecnica Federico SantaMarıa.

Sr. Leopoldo Silva B. . . . . . . . . . . . . . . . . . . . . . . . .

Sr. Wolfgang Freund G. . . . . . . . . . . . . . . . . . . . . . . . .

Valparaıso, Diciembre del 2006

Gracias a mis padres Arturo e Irma por educarmeA mi hermana Violeta por su companıa y consejos

A Don Leopoldo Silva por su apoyoA Daniela por su carino

A mi amiga ACB (Q.E.P.D)

Diseno de un driver para dispositivos de almacenamientomasivo USB


Requisito parcial para la obtencion del Tıtulo de Ingeniero Civil Electronico.

Profesor Guıa: Leopoldo Silva B.

Diciembre 2006

Resumen

Hoy en dıa el protocolo USB ha tenido un exito inesperado. Los factores clavesde la gran aceptacion entre los usuarios de computadores son sin duda: los costospara el fabricante y para el usuario; la sencillez de la conexion y la velocidad desus productos. Universal Serial Bus fue disenado para ser una interfaz capaz de co-municar diferentes tipos de dispositivos. Cada nuevo PC o Macintosh que sale almercado incluyen puertos USB que pueden conectar automaticamente a los dispo-sitivos estandar tales como: teclados, mouses, scanners, impresoras, etc., o tambiendispositivos con hardware personalizado con cualquier tipo de proposito.

En una etapa inicial de este trabajo, se realiza una vision general de los aspectosmas importantes del protocolo USB. De esta manera lleva al lector a comprender ya relacionarse tanto con los terminos mas comunes en el ambiente USB, como en elprotocolo propiamente tal. Un host controlador es el encargado de manejar, controlary dirigir todas las comunicaciones con los dispositivos USB. En el segundo capıtu-lo se describe el funcionamiento y las operaciones del host controlador SL811HS dela companıa Cypress Semiconductor Corporation. El tercer capıtulo se desarrolla laimplementacion de las herramientas que entrega el protocolo USB. Las herramientasllamadas Peticiones (Request) sirven para realizar la configuracion e interrogacion delos dispositivos USB. En el cuarto capıtulo se describe el funcionamiento de los dis-positivos que pertenecen a la clase de interfaz humana, que abarca a los dispositivoscomo teclados y mouses. Por ultimo, en el quinto capıtulo, se explica el funcionamien-to de los dispositivos de la clase de almacenamiento masivo, en donde se desarrollaun programa para la lectura y escritura de archivos para los Pendrives.

Palabras Claves– Universal Serial Bus (USB), Endpoint, Bulk-Only, Class, BusEnumeration, Standard Request (peticiones), SCSI, HID, MSD, Pendrives.

Indice general

1. Protocolo USB 141.1. Caracterısticas Generales . . . . . . . . . . . . . . . . . . . . . . . . . 141.2. USB-IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3.1. USB 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3.2. USB 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3.3. USB OTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3.4. USB Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3.5. USB Vs. FireWire . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4. Nivel Fısico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.1. Transmision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.2. Identificacion de velocidades . . . . . . . . . . . . . . . . . . . 23

1.5. Topologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5.1. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5.2. Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.5.3. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.6. Transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.6.1. Pipes y endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 271.6.2. Paquetes y fases de las transacciones . . . . . . . . . . . . . . 281.6.3. Token Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.4. Data Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.5. Handshake Packet . . . . . . . . . . . . . . . . . . . . . . . . 30

1.7. Transferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.7.1. Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.7.2. Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.7.3. Isochronous . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.7.4. CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2. Controlador SL811HS 362.1. Aspectos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.1.1. Modulo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . 372.1.2. Modos host/slave . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2. Registro y memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.1. Registros generales de configuracion . . . . . . . . . . . . . . . 39

6

2.2.2. Registros en modo host . . . . . . . . . . . . . . . . . . . . . . 402.3. Senales de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4. Funciones basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.1. Escritura en registros . . . . . . . . . . . . . . . . . . . . . . . 432.4.2. Lectura de registros . . . . . . . . . . . . . . . . . . . . . . . . 442.4.3. Inicializacion del SL811HS . . . . . . . . . . . . . . . . . . . . 452.4.4. Deteccion low/full speed . . . . . . . . . . . . . . . . . . . . . 46

2.5. Visualizacion de los registros . . . . . . . . . . . . . . . . . . . . . . . 492.5.1. Visualizacion de los registros a traves del display . . . . . . . 492.5.2. Visualizacion de los registros a traves de la ventana Watch . . 49

3. Peticiones, descriptores y configuracion general 513.1. Peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.1.1. Tipos de peticiones . . . . . . . . . . . . . . . . . . . . . . . . 513.1.2. Principales peticiones . . . . . . . . . . . . . . . . . . . . . . . 523.1.3. set adress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.1.4. set configuration . . . . . . . . . . . . . . . . . . . . . . . . . 533.1.5. get configuration . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2. Descriptores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.1. Descriptores Standard . . . . . . . . . . . . . . . . . . . . . . 543.2.2. Device Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.3. Configuration Descriptor . . . . . . . . . . . . . . . . . . . . . 583.2.4. Interface Descriptor . . . . . . . . . . . . . . . . . . . . . . . . 593.2.5. Endpoint Descriptor . . . . . . . . . . . . . . . . . . . . . . . 623.2.6. String Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . 633.2.7. Construccion de las peticiones . . . . . . . . . . . . . . . . . . 64

3.3. Configuracion de un dispositivo cualquiera . . . . . . . . . . . . . . . 653.4. Programas para los descriptores . . . . . . . . . . . . . . . . . . . . . 68

3.4.1. USBview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.4.2. USBCommandVerifer . . . . . . . . . . . . . . . . . . . . . . . 693.4.3. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4. Dispositivos de interfaz humana 714.1. HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2. Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3. Pipes de la Clase HID . . . . . . . . . . . . . . . . . . . . . . . . . . 724.4. Identificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.4.1. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.2. Subclases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.3. Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.5. Descriptores de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.5.1. HID Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . 754.5.2. Report Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . 774.5.3. Physical Descriptor . . . . . . . . . . . . . . . . . . . . . . . . 78

4.6. Recibimientos de los datos en un dispositivo HID . . . . . . . . . . . 79

4.7. Configuracion de un Mouse . . . . . . . . . . . . . . . . . . . . . . . 80

5. Dispositivos de almacenamiento masivo 835.1. Mass Store Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2. Reconocimiento de un dispositivo MSD . . . . . . . . . . . . . . . . . 84

5.2.1. Clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.2. Subclase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.2.3. Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3. Peticiones de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.3.1. Bulk-Only Mass Storage Reset . . . . . . . . . . . . . . . . . . 865.3.2. Get Max LUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4. Protocolo de transporte Bulk-Only . . . . . . . . . . . . . . . . . . . 875.4.1. Transferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4.2. Bloque CBW . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.4.3. Bloque CSW . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.5. Bloques de comandos SCSI-2 . . . . . . . . . . . . . . . . . . . . . . . 905.5.1. Inquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.5.2. Read(10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.5.3. Write(10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.6. Organizacion De La Memoria Fısica . . . . . . . . . . . . . . . . . . . 945.6.1. FAT16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.6.2. Master Boot Record - MBR . . . . . . . . . . . . . . . . . . . 965.6.3. Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.6.4. Funcion para encontrar particiones . . . . . . . . . . . . . . . 985.6.5. Distribucion de los archivos en memoria . . . . . . . . . . . . 100

5.7. Archivos y directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.7.1. Desarrollo de una funcion base de busqueda . . . . . . . . . . 1025.7.2. Busqueda de archivos y directorios en la raız . . . . . . . . . . 1035.7.3. Busqueda de archivos y directorios en directorios . . . . . . . 104

5.8. Lectura de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.8.1. Escritura en archivos . . . . . . . . . . . . . . . . . . . . . . . 107

6. Conclusiones 110

A. Detalles del protocolo USB 111A.1. Paquetes que se encuentran en las transacciones . . . . . . . . . . . . 111

A.1.1. SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111A.1.2. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112A.1.3. Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112A.1.4. ENDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112A.1.5. CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.2. Estados en la lınea de transmision . . . . . . . . . . . . . . . . . . . 113A.2.1. Diferencial0 y Diferencial1 . . . . . . . . . . . . . . . . . . . . 113A.2.2. Single-Ended Zero . . . . . . . . . . . . . . . . . . . . . . . . 113A.2.3. J y K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.2.4. Bus Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.3. Special Packet para el protocolo USB 2.0 . . . . . . . . . . . . . . . . 114A.4. Resumen de los paquetes en las transacciones . . . . . . . . . . . . . 115A.5. Resumen de las transferencias USB . . . . . . . . . . . . . . . . . . . 116

B. Diagrama de conexiones 117

C. Registros del controlador SL811HS en modo Host 118

D. Construccion de las peticiones 125D.1. Setup Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125D.2. Funcion Request() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

D.2.1. Ejemplo de la construccion de la peticion Set Adress . . . . . 129

E. Construccion de los comandos SCSI 130E.0.2. INQUIRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130E.0.3. READ(10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133E.0.4. WRITE(10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135E.0.5. Funcion de lectura de sectores, Leer Sector() . . . . . . . . . . 137E.0.6. Funcion de escritura de sectores, Escribir Sector() . . . . . . . 137E.0.7. Funcion INQUIRY . . . . . . . . . . . . . . . . . . . . . . . . 137

F. Estructura de informacion FAT16 139F.0.8. Master Boot Record . . . . . . . . . . . . . . . . . . . . . . . 139F.0.9. Partition Boot Record . . . . . . . . . . . . . . . . . . . . . . 141

F.1. Formatos DOS 8.3 y LFN (Long File Name) . . . . . . . . . . . . . . 142

G. Glosario. 144

Indice de figuras

1.1. Logo USB 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2. Logo USB 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3. Logo USB On-The-Go 2.0. . . . . . . . . . . . . . . . . . . . . . . . . 191.4. Logo USB Wireless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5. Modelo Hub and Spoke. . . . . . . . . . . . . . . . . . . . . . . . . . 201.6. Cable de cuatro hilos USB. . . . . . . . . . . . . . . . . . . . . . . . . 221.7. Transmision de los datos en el cable USB. . . . . . . . . . . . . . . . 231.8. Reconocimiento de full-speed. . . . . . . . . . . . . . . . . . . . . . . 231.9. Topologıa del bus USB. . . . . . . . . . . . . . . . . . . . . . . . . . . 241.10. Modelo hub de 7 puertos. . . . . . . . . . . . . . . . . . . . . . . . . 251.11. Distribucion de diferentes transacciones en un frame. . . . . . . . . . 271.12. Pipes y endpoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.13. Fases de una transaccion. . . . . . . . . . . . . . . . . . . . . . . . . . 281.14. Fases de una transaccion Interrupt. . . . . . . . . . . . . . . . . . . . 321.15. Fases de una transaccion Bulk. . . . . . . . . . . . . . . . . . . . . . . 331.16. Fases de una transaccion Isochronous. . . . . . . . . . . . . . . . . . . 341.17. Fases de una transaccion de Control. . . . . . . . . . . . . . . . . . . 35

2.1. SL811HS pin layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2. Modulo de trabajo para el SL811HS. . . . . . . . . . . . . . . . . . . 372.3. Conectores Serie-A y Serie-B. . . . . . . . . . . . . . . . . . . . . . . 382.4. Distribucion de la memoria y registros. . . . . . . . . . . . . . . . . . 392.5. Senales de acceso para el SL811HS. . . . . . . . . . . . . . . . . . . . 412.6. Formas de ondas cuando se escribe en un registro del SL811HS. . . . 422.7. Visualizacion de los registros a traves del display. . . . . . . . . . . . 492.8. Visualizacion de los registros con la herramienta watch. . . . . . . . . 50

3.1. Descriptores Standard. . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2. Estructura de los descriptores para la herramienta watch. . . . . . . . 573.3. Device Descriptor al conectar un teclado USB. . . . . . . . . . . . . . 583.4. Configuration Descriptor de un mouse. . . . . . . . . . . . . . . . . . 593.5. Mensaje de Windows para un dispositivo USB. . . . . . . . . . . . . . 613.6. Interface Descriptor para un mouse. . . . . . . . . . . . . . . . . . . . 613.7. Endpoint Descriptor para una impresora. . . . . . . . . . . . . . . . . 633.8. Mensaje de Windows XP para el nombre del producto. . . . . . . . . 63

10

3.9. Nombre del producto de un dispositivo usando el SL811HS. . . . . . . 643.10. Visualizacion de la pantalla despues de usar Bus Enumeracion. . . . . 683.11. USBview mostrando los dispositivos conectados. . . . . . . . . . . . . 693.12. USBview mostrando los descriptores. . . . . . . . . . . . . . . . . . . 693.13. USBcommandVerifer. . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.14. Conexion de un sniffer para la captura de datos. . . . . . . . . . . . . 70

4.1. Pipes de la clase HID. . . . . . . . . . . . . . . . . . . . . . . . . . . 724.2. Descriptores de la clase HID. . . . . . . . . . . . . . . . . . . . . . . . 754.3. HID Descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.4. Tabla de reportes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.5. Software HID Descriptor Tool. . . . . . . . . . . . . . . . . . . . . . . 78

5.1. Estructura interna de los pendrives. . . . . . . . . . . . . . . . . . . . 845.2. Flujo de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.3. Command Block Wrapper. . . . . . . . . . . . . . . . . . . . . . . . . 895.4. Command Status Wrapper. . . . . . . . . . . . . . . . . . . . . . . . 905.5. Resultado del comando Inquiry. . . . . . . . . . . . . . . . . . . . . . 925.6. Organizacion de la memoria. . . . . . . . . . . . . . . . . . . . . . . . 955.7. Master Boot Record del pendrive Packerbell 256MB. . . . . . . . . . 965.8. Estructura de las particiones. . . . . . . . . . . . . . . . . . . . . . . 975.9. Ejemplo de la Partition Boot Record. . . . . . . . . . . . . . . . . . . 985.10. Valores obtenidos al ejecutar la funcion buscaparticion(). . . . . . . . 995.11. Ejemplo de la distribucion de un archivo en memoria. . . . . . . . . . 1005.12. Ejemplos de nombres y carpetas en la tabla de directorios. . . . . . . 1025.13. Estructura de la funcion save(). . . . . . . . . . . . . . . . . . . . . . 1065.14. Relleno de sectores y cluster en la escritura de datos. . . . . . . . . . 108

A.1. Resumen de la estructura de los paquetes del protocolo USB. . . . . . 115A.2. Resumen de las transferencias del protocolo USB. . . . . . . . . . . . 116

B.1. SL811HS USB Host/Slave Controlador, Pin Layout. . . . . . . . . . . 117

Indice de cuadros

1.1. Ejemplos de aplicaciones OTG. . . . . . . . . . . . . . . . . . . . . . 191.2. Tipos de protocolos y sus usos. . . . . . . . . . . . . . . . . . . . . . 211.3. Token Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.4. Data Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.5. Handshake Packet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.6. Resumen de las transferencias y sus usos. . . . . . . . . . . . . . . . . 31

2.1. Registros de configuracion del SL811HS. . . . . . . . . . . . . . . . . 392.2. Registros y definiciones para modo host. . . . . . . . . . . . . . . . . 40

3.1. Peticiones Standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2. Estructura del Device Descriptor. . . . . . . . . . . . . . . . . . . . . 563.3. Configuration Descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . 583.4. Interface Descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.5. Clases USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.6. Endpoint Descriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.7. Campos del Setup Packet. . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1. Resumen de la comunicacion HID. . . . . . . . . . . . . . . . . . . . . 734.2. Codigos de Subclases. . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3. Codigos de protocolos. . . . . . . . . . . . . . . . . . . . . . . . . . . 744.4. Estructura del HID Descriptor. . . . . . . . . . . . . . . . . . . . . . 754.5. Descriptores especiales para la clase HID. . . . . . . . . . . . . . . . . 764.6. Valores para los botones del mouse. . . . . . . . . . . . . . . . . . . . 814.7. Valores para el movimiento del mouse. . . . . . . . . . . . . . . . . . 81

5.1. Codigo de subclase para Mass Store Device. . . . . . . . . . . . . . . 845.2. Codigo de protocolo para Mass Store Device. . . . . . . . . . . . . . . 855.3. Interface Descriptor para distintos pendrives. . . . . . . . . . . . . . . 865.4. Tıpicos comandos SCSI. . . . . . . . . . . . . . . . . . . . . . . . . . 915.5. Cluster por tamano. . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.6. Master Boot Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.7. Codigos para el cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.1. Paquetes del protocolo USB. . . . . . . . . . . . . . . . . . . . . . . . 111A.2. Bits del paquete PID. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

12

A.3. Bits del paquete Adress. . . . . . . . . . . . . . . . . . . . . . . . . . 112A.4. Bits del paquete ENDP. . . . . . . . . . . . . . . . . . . . . . . . . . 112A.5. Estados J y K. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

C.1. Registros en modo host. . . . . . . . . . . . . . . . . . . . . . . . . . 118C.2. Registro 0x00. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119C.3. Registro 0x03, resultados de la ultima transaccion. . . . . . . . . . . . 121C.4. Registro 0x03, valores para el paquete PID. . . . . . . . . . . . . . . 121C.5. Registro 0x05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122C.6. Estados de operacion de las lıneas D+ y D-. . . . . . . . . . . . . . . 122C.7. Registro 0x06. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123C.8. Registro 0x0D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123C.9. Registro 0x0E, hardware revision. . . . . . . . . . . . . . . . . . . . . 123C.10.Registro 0x0F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

D.1. Campos del Setup Packet. . . . . . . . . . . . . . . . . . . . . . . . . 125D.2. Peticiones Standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . 126D.3. Tipos de descriptores. . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

E.1. Campo de envıo del comando INQUIRY. . . . . . . . . . . . . . . . . 130E.2. Campos de retorno del comando INQUIRY. . . . . . . . . . . . . . . 132E.3. Formato del comando READ(10). . . . . . . . . . . . . . . . . . . . . 133E.4. Campo de envıo del comando INQUIRY. . . . . . . . . . . . . . . . . 135

F.1. Master Boot Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . 139F.2. Informacion de los 16 bytes para cada particion. . . . . . . . . . . . . 139F.3. Tipos de particiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 140F.4. Campos del sector Partition Boot Record. . . . . . . . . . . . . . . . 141F.5. Formato de nombres cortos para DOS 8.3. . . . . . . . . . . . . . . . 142F.6. Formato de nombres cortos para LFN. . . . . . . . . . . . . . . . . . 142F.7. Formato de nombres largos para LFN . . . . . . . . . . . . . . . . . . 143

Capıtulo 1

Protocolo USB

Este capıtulo describe el protocolo USB incluyendo sus ventajas y sus lımites, lahistoria acerca de la interfaz y sus ultimos avances. El conocimiento general del pro-tocolo USB y sus principales caracterısticas es una referencia en el cual debe estarinvolucrado cualquier disenador y programador de un dispositivo USB.

1.1. Caracterısticas Generales

El protocolo USB (Universal Serial Bus) ha sido una verdadera revolucion en elmundo de la computacion, caracterısticas como sencillez en la conexion y velocidadde transmision han hecho masivo el uso de esta tecnologıa, dejando atras antiguasformas de conectar perifericos por los puertos paralelos o el serial RS-232. USB tienela gran ventaja que es un estandar abierto, lo cual permite ir mejorando el protocolosegun las nuevas necesidades que vayan saliendo en el mercado, ademas ya ha sidoadoptado por cientos de fabricantes de perifericos y ha recibido una gran aceptacionentre los fabricantes de computadores personales. En un principio el estandar USBfue solo una especificacion de las empresas Compaq, Intel, Microsoft y NEC, pero conel paso del tiempo se incorporaron grandes empresas como Hewlett-Packard, Lucenty Philips y ahora ha sido formalmente adoptado por los sistemas operativos de Appley Linux, que en conjunto con Microsoft Windows representan a casi el total del sectorde la informatica personal.

USB fue disenado expresamente para proporcionar las caracterısticas mas requeri-das por los usuarios, las principales son:

Una interfaz para muchos dispositivos: USB es lo suficientemente versatilpara ser utilizable con una variedad de perifericos. En lugar de tener un tipo deconector diferente para cada dispositivo y tener un soporte para cada hardware,en USB una interfaz sirve para todos.

14

CAPITULO 1. PROTOCOLO USB

Configuracion automatica para clases conocidas: Cuando un usuarioconecta un dispositivo USB, el sistema operativo detecta el periferico y carga elsoftware apropiado. Si una clase desconocida se conecta, los sistemas operativoscomo Windows advierten al usuario para insertar un disco con los drivers, peroaparte de eso, la instalacion es automatica.

Facil de manejar: La implementacion del USB elimina el uso de IRQ’s ycanales de DMA. Ası como la necesidad de abrir los gabinetes para instalar oquitar dispositivos. El usuario no tienen la necesidad de preocuparse sobre lacorrecta seleccion del puerto serial, la instalacion de tarjetas de expansion oconfigurar los jumpers de la placa madre. Un PC tıpicamente tiene cuatro omas puertos USB los cuales son ampliables a traves de hubs.

Simple conexion: Los conectores del cable USB son como una llave, ası que noes posible poder conectar incorrectamente el dispositivo. El largo puede llegarhasta los 5 metros. Con hubs, un dispositivo puede llegar hasta los 30 metrosde distancia desde el host base. Los conectores USB son pequenos y compactosen contraste a los tıpicos RS-232 y conectores paralelos. En resumen USB usaunicamente un solo tipo de conector para cualquier tipo de dispositivo, masalla de la funcion que cumplan. Para asegurar la buena operacion, la especifi-cacion USB incluye requisitos electricos que todos los cables y los conectoresdeben incorporar.

Conexion en caliente: USB permite conectar y desconectar un dispositivocuando se requiera, no importando si los sistemas estan energizados.

No requiere alimentacion externa: La interfaz USB incluye suministro deenergıa a traves de la lınea de tierra y los +5V nominal entregado por el com-putador o el hub. Un dispositivo puede tomar hasta maximo 500 mA a travesdel bus. Por lo contrario, los dispositivos que usan interfaces en el cual requieranmas corriente, pueden incluir un suministro de energıa dentro del dispositivo ousar un suministro externo.

Conectividad: Hasta 127 dispositivos diferentes pueden estar conectados si-multaneamente y operando con el mismo computador.

Bajos costos de diseno: Para casi la mayorıa de las aplicaciones que sonestandar y no tienen una configuracion propia, los costos de diseno son compa-rativamente menores que otras tecnologıas.

15


1.2. USB-IF

Para los disenadores de dispositivos USB se dispone de una gran cantidad deayuda por: USB Implementers Forum S.A. (USB-IF) y su sitio Web www.usb.org.USB-IF es una corporacion sin fines de lucro fundada por las companıas que estandesarrollando continuamente especificaciones y productos USB. La mision de USB-IFes dar soporte al avance y la utilizacion de la tecnologıa USB. Para ese fin, USB-IFofrece informacion, herramientas y test de pruebas. La informacion incluye los docu-mentos de especificacion, artıculos, FAQs y foros en la Web, donde los desarrolladorespueden discutir temas relacionados a USB. Las herramientas previstas por el USB-IFincluyen software y hardware para ayudar a desarrollar y probar productos. El so-porte para experimentar incluye tests para verificar que las operaciones realizadaspor los dispositivos USB sean las correctas.

Cualquiera puede desarrollar drivers, programas y dispositivos USB sin pagar al-guna tarifa de licencias, sin embargo cualquiera que distribuye un dispositivo con unainterfaz USB debe obtener los derechos para usar un Vendor ID1. Al momento deescribir la presente memoria, el cargo administrativo para obtener un Vendor ID esde US$1500. Para ser partıcipe de USB-IF la cuota anual es de US$2500, con lo cualjunto con el Vendor ID se puede participar en talleres y foros para el mejoramiento dela tecnologıa USB. Estas cuotas no son problemas para desarrolladores de productoscon volumenes altos de dispositivos, sino mas bien puede ser un impedimento paralos desarrolladores que planean realizar cantidades pequenas de dispositivos y a bajoscostos.

1.3. Versiones

En la actualidad existen cuatro tipos de diferentes versiones USB. Estos hanaparecido principalmente por la necesidad de ir mejorando la velocidad de la trans-mision serial y ademas por las nuevas formas a la hora de interconectar dispositivos.

1.3.1. USB 1.1

Esta especificacion fue realizada por las empresas Compaq, Intel, Microsoft yNEC, en septiembre de 1998 y marcaba la primera version final de una serie de an-tiguas versiones. La version USB 1.1 define y caracteriza casi por completo lo que eshoy en dıa el protocolo USB, pues en ella se especifica un canal serial para soportara una gran gama de perifericos de media y baja velocidad, con soporte integral paratransferencias en tiempo real como voz, audio y vıdeo.

1El Vendor ID es asignado por USB-IF y se incorpora en cada dispositivo para su identificacion.

16


Las principales caracterısticas de USB 1.1 son:

Dos velocidades de transmision: 12 Mbps llamada full-speed, con proposito dediseno para dispositivos que requieren grandes velocidades de transmision. Ylow-speed de 1,5 Mbps para dispositivos mas lentos como son los mouse, tecladosy joysticks.

Manejar hasta 127 dispositivos simultaneamente que se pueden conectar y des-conectar en caliente, sin tener que reiniciar el sistema.

Una configuracion automatica de dispositivos que elimina la necesidad de rea-lizar configuraciones.

Un acceso al bus gestionado directamente por el controlador USB para permitirtransferencias isocronas y eliminar los tiempos de arbitracion.

La coexistencia de dispositivos isocronos y asıncronos. Los dispositivos isocronosse atienden en funcion del ancho de banda y tiempo requerido, y los asıncronos seatienden durante el tiempo restante no consumido por los dispositivos isocronos.

Una distribucion de alimentacion desde el controlador USB, que permite laconexion de los dispositivos sin alimentacion externa.

Una arquitectura facilmente escalable para permitir la existencia de varios con-troladores USB en un sistema.

Para el reconocimiento del protocolo USB 1.1 se dispone del logo mostrado en lafigura 1.1.

Figura 1.1: Logo USB 1.1.

1.3.2. USB 2.0

USB 1.1 gano gran popularidad entre los usuarios y disenadores de productos. Enabril del ano 2000, en conjunto con nuevas empresas para el mejoramiento del pro-tocolo como: Hewlett-Packard, Lucent y Philips se publica finalmente USB 2.0, cuyologo de reconocimiento se muestra en la figura 1.2. Esto demostraba el gran interespor desarrollar e integrar nuevos dispositivos mas rapidos y que demandaran gran

17


cantidad de datos de transferencias. La nueva velocidad que se incorpora se llamahigh-speed y es de 480 Mbps, lo que es cuarenta veces mas rapido que la antigua full-speed. La incorporacion de high-speed hizo que USB sea mucho mas atractivo para eldiseno de dispositivos como: impresoras, scanners, camaras fotograficas 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 nuevostipos de paquetes. Los dispositivos high-speed tambien soportan una funcionalidaden modo full-speed, de forma que cuando se conectan a un puerto que esta trabajandoen modo full-speed pueden al menos:

Detectar y procesar el reset.

Aceptar, procesar y responder adecuadamente a las funciones estandar de asig-nacion de direccion y de configuracion, ası como la lectura de la informaciondescriptiva del dispositivo y de sus posibles configuraciones (peticiones y des-criptores).

Los dispositivos high-speed pueden o no soportar su total funcionalidad cuandotrabajan en modo full-speed, pero la mayorıa lo hacen para que sean compatibles.USB pone a disposicion herramientas como USB command Verifier Tool1 para com-probar si cumplen con los requisitos para su funcionamiento en ambas velocidades.

1.3.3. USB OTG

Los desarrolladores de perifericos comenzaron a solicitar una nueva forma parapoder conectar los dispositivos USB. Por ejemplo, un usuario podrıa querer usaruna impresora directamente con una camara fotografica. El protocolo On-The-Go,cuyo logo se muestra en la figura 1.3, fue el que pudo hacer posible la conexionpedida por los fabricantes. Se publico en diciembre del 2001 y corresponde a unavariacion de USB 2.0. Con este nuevo protocolo el host tiene una capacidad limitada,pero posibilita la comunicacion entre perifericos y elimina la indispensabilidad detener un PC para establecer la comunicacion. Igualmente USB OTG permite a undispositivo actuar como servidor o como cliente dependiendo como originalmente seconecto el cableado. Incluso despues de que las unidades se estan comunicando, los

1El programa se encuentra en www.org.usb o en el CD adjunto a la memoria “Programas/USB commandVerifier Tool/USBCV121.msi” y requiere de un ROOT USB 2.0.

18


dos dispositivos pueden cambiar el rol bajo el control de un programa. Esta facilidadesta especıficamente disenada para dispositivos como PDA, camaras e impresoras.

Las principales caracterısticas son:

Habilidad Dual-Rol, con la cual se puede intercambiar papeles entre host y slavebajo el protocolo de negociacion de host (HPN).

Nuevos conectores mas pequenos (mini-A y mini-B) con un cableado diferente.

Ahorro de consumo de energıa para facilitar durabilidad de la baterıa en losdispositivos.

Figura 1.3: Logo USB On-The-Go 2.0.

En el cuadro 1.1 muestra algunos ejemplos de conexion directa entre perifericoscon las respectivas aplicaciones.

Host Periferico AplicacionPDA -PDA -Intercambiar informacion

-Impresora -Imprimir documentos-Telefonos -Subir/bajar archivos-Scanner -Digitalizar fotos-Pendrive -Subir/bajar archivos-GPS -Obtener mapas, direcciones-Camaras -Subir/bajar fotos

Impresora -Camaras -Imprimir archivos-Telefonos-Pendrive- PDA

Cuadro 1.1: Ejemplos de aplicaciones OTG.

1.3.4. USB Wireless

USB inalambrico (WUSB) es la tecnologıa desarrollada mas reciente por USB-IF.La version 1.0 de WUSB fue publicada en mayo del 2005 y entrega mas facilidades ymovilidad a los dispositivos que se conectan a los PC. Esta especificacion mantieneel mismo uso y arquitectura que el USB con cables, con una conexion high-speed

19


desde el host al dispositivo. Aunque el despliegue masivo de dispositivos compati-bles con esta tecnologıa no se producira hasta 2006. La utilizacion de WUSB noha sido aprobado aun por una buena cantidad de organismos regulatorios europeosy asiaticos, debido a potenciales conflictos con otras tecnologıas inalambricas. Estopodrıa oscurecer las perspectivas de Wireless USB de alcanzar economıas de escalaque puedan reducir costos y competir de igual con Bluetooth, que ha alcanzado unimportante crecimiento en el campo de la tecnologıa inalambrica durante los ultimosanos.

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 andSpoke”. El host WUSB es el hub que esta representado en la parte central de la figura1.5 y cada dispositivo que se conecta se llama spoke. Un spoke es una conexion point-to-point entre el host y el dispositivo. El host puede soportar 127 dispositivos y comono tiene puertos fısicos no hay necesidad de definir nuevos hubs para la expansion delos puertos. Las principales caracterısticas son:

Transferencia de 480 Mbps a 3 metros y 110 Mbps a 10 metros de distancia.

20


Tecnologıa CMOS, con ahorro de energıa (Sleep/Listen/Wake) y bajos costosde disenos.

Conexion maxima de 127 dispositivos WUSB.

Seguridad y asociacion de dispositivos con mecanismo de cifrado AES-128/CCMa nivel de las aplicaciones.

Usa el espectro UWB (Ultra-Wideband), 3.1-10.6 Ghz.

Dispositivos WUSB con protocolo OTG para funciones Dual-Rol.

Arquitectura y protocolo escalable a 1 Gbps.

Interface Formato Dispos. Max. Veloc. Max. Uso tıpico

USB asynchronousserial

127 1.5M, 12M, 480M. teclados, mouse,impresoras, scanner,pendrives, camarasfotograficas, etc.

Ethernet serial 1024 10G general network

IEEE-1394a(FireWire)

serial 64 400M video y audio

IEEE-1394b(FireWire)

serial 64 3.2G video y audio

IEEE-488(GPIB)

paralelo 15 8M instrumentacion

IrDA infrarrojoserial

2 16M manos libres, impre-soras

I2C asynchronousserial

40 3.4M microcontroladores

Microwire asynchronousserial

8 2M microcontroladores

Puerto Paralelo paralelo 2 8M impresoras, scanner

RS-232 asynchronousserial

2 20k modem, mouse, ins-trumentacion

RS-485 asynchronousserial

32 10M adquisicion de datosy sistemas de control

SPI asynchronousserial

8 2.1M microcontroladores

Cuadro 1.2: Tipos de protocolos y sus usos.

1.3.5. USB Vs. FireWire

Otra popular eleccion de interfaz para dispositivos perifericos es el protocoloIEEE-1394, tambien conocido como FireWire. La implementacion de la interfaz 1394fue desarrollado por Apple Computer. Ambas tecnologıas persiguen un mismo meto-do de conectar multiples perifericos a un computador con la capacidad de permitir

21


que los perifericos sean anadidos o desconectados sin la necesidad de reiniciar. Perola diferencia radica en que generalmente IEEE-1394 puede ser mas rapido y flexibleque USB, pero los costos de implementacion suelen ser mayores. Con USB un solohost es el que controla todas las comunicaciones de los dispositivos, el host manipulala mayorıa de la complejidad, ası es que la electronica de los dispositivos puede serrelativamente simple y menos costosa.

Como se muestra el cuadro comparativo 1.2, la velocidad y capacidad de transfe-rencia marca la principal distincion entre estas dos tecnologıas. Hoy USB high-speedlo hace competitivo con el IEEE-1394A con velocidad de 480 Megabits/sec, peroIEEE-1394B es superior con 3.2 Gigabits/sec.

1.4. Nivel Fısico

La interfaz USB se conecta con el equipo del usuario a traves de un cable de cua-tro hilos. Dos son dedicados a la alimentacion y los dos restantes a la senal de datos(D+ y D-), estos ultimos estan como par trenzado. Los conductores de alimentacion(figura 1.6) VBus y GND entregan una tension continua de 5V y 500mA maximo. Enfuncion de las necesidades de alimentacion electrica de los dispositivos, estos puedentomar la alimentacion de estas lıneas, o bien tener una fuente de alimentacion alter-nativa. Todos los aspectos tecnicos relativos al cable y conector USB se encuentranen la especificacion USB entregada por USB-IF.

Figura 1.6: Cable de cuatro hilos USB.

1.4.1. Transmision

El bus USB es sıncrono y los paquetes de datos estan codificados usando NRZI1

agregando la insercion de bits llamado Bit Stuffing. La insercion de bits es requeridopor el dispositivo receptor porque este funciona sincronicamente con las transiciones.Si los datos son todos “0”, entonces existen bastantes transiciones, pero si los datoscontienen demasiados “1”, entonces la falta de transiciones podrıa causar que elaparato receptor pueda salir del sincronismo (SYNC). Si los datos tienen seis “1”consecutivos el transmisor inserta un “0” (representado por una transicion). Esto

1Non Return to Zero Inverted, la lınea cambia de nivel si se transmite un “0” y no cambia si transmiteun “1”.

22


asegura al menos una transicion para cada siete bits transmitidos. El aparato recep-tor detecta y descarta cualquier bit que tenga seis 1s consecutivos. La insercion debits puede aumentar el numero de bits transmitidos que en teorıa puede llegar hastaun 17%, pero en la practica el promedio es mucho menos. El overhead por bit stuffingpara datos aleatorios es aproximadamente un 0.8%, lo cual significa 1 bit de rellenopor cada 125 bits de datos.

Despues, los datos codificados son conducidos en el cable USB por el conductordiferencial. El dispositivo receptor amplifica los datos diferenciales entrantes (verfigura 1.7) y entrega los datos para ser decodificados. La codificacion y la senalizaciondiferencial se usan para ayudar a asegurar la integridad de los datos y eliminarproblemas de ruido.

Figura 1.7: Transmision de los datos en el cable USB.

1.4.2. Identificacion 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 deteccion serealice en forma electrica a traves de un voltaje diferencial (2.7V a 3.3V para ambasvelocidades). Para los dispositivos full-speed la resistencia Pull-up es conectada enla lınea D+ (figura 1.8) y para los dispositivos low-speed la resistencia Pull-up esconectada en la lınea D-. La ausencia de un dispositivo se detecta con las senales D+y D- estando en 0.

Figura 1.8: Reconocimiento de full-speed.

En un principio USB fue pensado con un diseno de dos tipos de velocidades, espor eso que los dispositivos high-speed se tienen que identificar electricamente comodispositivos full-speed. Luego se ejecutan unas secuencias de senales electricas que

23


determinan finalmente si el dispositivo corresponde a full-speed o high-speed.

1.5. Topologıa

La conexion en el bus USB se denomina Estrella en Niveles de 7 capas. En elcentro de cada estrella hay un hub y en cada punta puede ser un dispositivo o otrohub (figura 1.9). Debido a los retardos producidos por la propagacion de la senal enel largo del cable, se fija un maximo de 7 niveles para el control de todo el traficode informacion en el bus. El numero de puertos de cada hub puede variar de dos,cuatro o siete, dependiendo del hub conectado. Un dispositivo compuesto ocupa dosfilas, por consiguiente, no puede ser colocado al final del nivel 7, solo los dispositivossimples pueden ser colocados en ese nivel. Considerando el hub raız y el ultimo nivel,la maxima 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 agentesparticipativos: el controlador host, los hubs y las funciones.

1.5.1. Controlador

Es el responsable de las comunicaciones entre los perifericos USB y el microcontro-lador. Para cada periferico anadido, el controlador determina su clase y le asigna una

24


direccion logica para utilizarla en las comunicaciones. El host controlador puede serimplementado usando una combinacion entre hardware, firmware o software, dondelas principales funciones que lleva a cabo son:

Detectar si un dispositivo se ha conectado o ha sido removido de alguno de lospuertos.

Manejar el flujo de control y flujo de datos entre el microcontrolador y losdispositivos.

Proveer la alimentacion a los dispositivos USB conectados.

Comunicar al microcontrolador o CPU los errores durante la comunicacion.

1.5.2. Hubs

El hub es un dispositivo mas de la gran lista de aparatos USB que se pueden conec-tar. Estos dispositivos simplifican de gran manera la sencillez de la interconexion,dando la posibilidad de extender la cantidad de dispositivos que se puedan conectar(127 dispositivos). El hub USB esta hecho para detectar si un periferico ha sido conec-tado o si un dispositivo ha sido removido de sus puertos a traves de un estado internodentro del hub: el controlador debe estar constantemente revisando1 los estados de loshub para procesar el equipo nuevo o para remover los programas de administracion(drivers) del dispositivo retirado. Otra de las funciones importantes de los hubs esaislar los puertos de baja velocidad, de las transferencias de alta velocidad, procesosin el cual, todos los dispositivos de baja velocidad conectados al bus entrarıan encolapso. La proteccion de los dispositivos low-speed de los full-speed ha sido siempreun serio problema dentro de las redes mixtas, disminuyendo el rendimiento como esel 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 este da soporte a velocidadeshigh-speed (480Mbs), con la gran diferencia que realiza todas las transacciones dedatos a la velocidad high-speed, convirtiendo la velocidad que necesita el dispositivoen la ultima parte de la conexion. De esta forma la entrega de datos es mucho mas

1Las revisiones de los estados se realizan a traves de las peticiones. Para mayor detalle ver Capıtulo 3.

25


eficiente comparado con los hubs 1.1 (full-speed). Internamente el hub 1.1 esta com-puesto por el controlador hub y el repetidor hub, sin embargo el hub 2.0 posee unnuevo elemento llamado Traductor de Transacciones (TT).

1.5.3. Funciones

Una funcion es un dispositivo USB no compuesto, que esta disenado para trans-mitir y recibir datos. Se puede decir que es un periferico, sin embargo un dispositivocomun y corriente fısicamente puede incorporar multiples funciones e incluso llevardentro un hub, en cuyo caso se conoce como un dispositivo compuesto, donde cadafuncion no puede ser desconectada o conectada de modo individual.

1.6. Transacciones

El host es el que maneja todo el flujo de datos en el BUS, para ello USB 1.1 divideel tiempo en segmentos equivalente a 1 milisegundo denominado Frame o Trama yaplicable a los buses low-speed y full-speed. En high-speed que pertenece al protocoloUSB 2.0, se trabaja con frame y microframes donde cada microframe equivalen a 125microsegundos. Los frames no es mas que un mecanismo del bus USB para controlarel acceso a este, en funcion del tipo de transferencia que se realice reservando ciertosporcentajes del tiempo de la trama. En cada transaccion incluye un numero deter-minado de paquetes y cada frame incluye un numero determinado de transacciones.

La figura 1.11 muestra como las diferentes transacciones que producen los dispo-sitivos se van agrupando en el frame. En cada frame puede suceder que no se hagauso completo del tiempo, ya que a veces no existen mas transacciones en el bus o sim-plemente porque el tiempo sobrante no es suficiente para asegurar que la transaccionse realice.

Las transacciones se agrupan formando transferencias. Cada transferencia obe-dece a un tipo predeterminado como lo son: Interrupt, Control, Bulk e Isochronous.Una transferencia puede estar distribuida entre distintos frames o incluida comple-tamente en una sola (dependiendo del tamano de la informacion). Las transferenciasque necesitan una tasa especıfica de velocidad, se garantizan reservando la cantidadde tiempo que necesitan en cada frame. Si el ancho de banda no esta disponible,entonces el host no establece la comunicacion dando al driver la posibilidad de poderpedir una porcion mas pequena del ancho de banda o esperar hasta que el ancho debanda demandado este disponible. La maxima cantidad de informacion util que sepuede transferir en un paquete de datos depende de la velocidad del dispositivo y deltipo de Endpoint.

26


Figura 1.11: Distribucion de diferentes transacciones en un frame.

1.6.1. Pipes y endpoint

El flujo de datos del bus USB desde un punto de vista virtual se realiza porcaminos denominados pipes (figura 1.12).

Figura 1.12: Pipes y endpoint.

Cada pipe tiene asociado un endpoint que son los respectivos terminales de cadapipe. Cada endpoint tiene una direccion que puede ser IN, OUT o bi-direccional.El controlador puede acceder a cada endpoint para establecer la comunicacion, puescada dispositivo USB define un grupo de endpoint que forman la interfaz final. A suvez, cada endpoint define el tamano maximo de transferencia. En USB 1.1 los valores

27


son de 8, 16, 32 o 64 bytes. Para USB 2.0 se suma un nuevo tamano de 512 bytes.En los dispositivos low-speed solo es posible tener endpoint de 8 bytes.

1.6.2. Paquetes y fases de las transacciones

El protocolo de comunicaciones del bus USB entre el host y el dispositivo fısicose realiza a traves de Tokens (testigos). De forma general toda funcion (dispositivo)en principio, esta esperando a que el host le envıe un paquete. Si un paquete tienela misma direccion (device adress) que el dispositivo, entonces este cambia de estadopara proceder aceptar la transaccion.

Figura 1.13: Fases de una transaccion.

Como se muestra en la figura 1.13 una transaccion tıpicamente puede estarcompuesta por una, dos o tres fases. Las tres posibles fases son Token, Data yHandshake, las cuales de existir lo haran de forma secuencial: una fase Token essiempre seguida de una fase Data y esta a su vez sera seguida de una fase Handshake.Las fases Data y Handshake son opcionales de acuerdo al tipo de transmision que sesolicite. A su vez, cada fase esta compuesta por una serie de paquetes1 como: SYNC,PID, ENDPOINT, DEVICE ADDRESS, DATA y CRC.

1El detalle de los paquetes del protocolo se pueden encontrar en el Apendice A.

28


1.6.3. Token Packet

Se compone de un paquete enviado por el controlador USB y siempre esta presenteen toda transaccion. En esta fase se envıa: el tipo del paquete, la direccion del dis-positivo y la direccion del endpoint. El paquete finaliza con un control de error CRC5.

Los paquetes que componen un Token Packet (cuadro 1.3) son:

0 8 15 19 23

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 soportablespara el PID tipo Token son: IN, OUT, SETUP y SOF. Todos los PIDs vanauto-protegidos con bits redundantes.

ADDR: Direccion del dispositivo a comunicar, con un total de 127 direccionesposibles.

ENDP: Numero del endpoint para establecer la transferencia. Son soportablessolo 16 endpoints como maximo.

CRC5: El ultimo campo en todos los paquetes Tokens consta de 5 bits y co-rresponde al codigo de redundancia cıclica. Este no abarca los campos SYNC yPID.

1.6.4. Data Packet

Data Packet (cuadro 1.4) consiste en un paquete PID, luego cero o mas bytesde los datos utiles asociado con la transferencia (DATA) y finaliza con un paquetede correccion de 16 bits. Hay dos tipos de Data Packet identificados por diferentesPIDs1: DATA0 y DATA1. Estos dos paquetes estan definidos para usarlos en formade toggle para la disminucion de errores y confusiones por parte del host.

En USB 1.1 un paquete de datos puede transmitir una carga maxima de 1023bytes de datos (en transacciones isocronas) durante una sola transaccion, mientrasen los otros tipos de transferencia tienen cargas maximas de 64 bytes (Bulk).

1El protocolo USB 2.0 agrega nuevos tipos de paquetes para la fase Data Packet: DATA2 y MDATA.

29


0

PID DATA CRC16

8 bits 0-1023 bytes 16 bits

Cuadro 1.4: Data Packet.

1.6.5. Handshake Packet

Todas las transferencias USB (excepto isocronas) son implementadas para garan-tizar la entrega de datos. Para ello se incluye la fase Handshake que permite verificarsi la transferencia ha sido exitosamente realizada. Si un error ocurre en la transaccion,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 eldispositivo ha recibido satisfactoriamente los datos sin errores. El dispositivo retornaun ACK en el Handshake para transacciones OUT o SETUP y el host retorna unACK solo para transacciones tipo IN.

NAK

Not Acknowledged o Reconocimiento Negativo: este paquete es transmitido cadavez que el dispositivo no esta listo para una operacion, tanto de transmision como derecepcion de paquetes. Por definicion el host siempre puede transmitir o recibir unpaquete de datos, de lo contrario nunca habrıa transmitido el paquete Token (OUT oIN). Consecuentemente el paquete handshake NAK solo puede ser transmitido haciaarriba (Upstream) por el dispositivo y solo puede ser recibido por el host. Luego deque el controlador host transmita un paquete de datos asociado a un paquete Tokende salida (OUT Token), el dispositivo transmite un paquete handshake NAK si noesta listo para recibir los datos. Esto se da tambien en el caso de que el host trans-mita un paquete Token de entrada (IN Token) y que el dispositivo no este listo paratransmitir. Las transferencias del tipo isocronas no retornan NAK porque ese tipode transferencias no usan Handshake.

30


STALL

El Handshake STALL puede significar: que no soporta una peticion de control,la peticion de control ha fallado o el endpoint no existe. En el caso que el endpointfalle, el dispositivo es incapaz de recibir o trasmitir los datos. El comando STALL estransmitido solo por los dispositivos (upstream), y pueden ser recibidos unicamentepor el controlador, el cual debe intervenir para solucionar el problema antes de quela comunicacion puede ser reanudada.

1.7. Transferencias

USB fue disenado para manipular diferentes perifericos con diversos requisitoscomo: velocidad de transferencia, tiempo de respuesta, tamano de datos enviados ycorreccion de errores. Los cuatro tipos de transferencias que existen en USB cumplencon las necesidades que se nombraron. Las transferencias son: Control, Interrupt,Bulk y Isochronous y un dispositivo puede integrar a los tipos de transferenciasque mas les convengan y satisfagan, segun sean sus proposito, siendo el del tipo Con-trol el unico de uso obligatorio para los dispositivos USB.

Tipo Control Bulk Interrupt Isochronous

Uso tıpico Identificacion con-figuracion

Impresoras,scanner, pendrives

Mouse, teclados,joysticks

Streaming audio yvideo.

Requerido Si No No No

Permite low-speed

Si No Si No

¿Correccion deerrores?

Si Si Si No

Reserva anchode banda

10% para low yfull-speed, 20%para high-speed

No 90% para low yfull-speed, 80%para high-speed

90% para low yfull-speed, 80%para high-speed

Maxima tasafull-speed

832 bytes/frame 1216 bytes/frame 64 bytes/frame 1023 bytes/Frame

Maxima tasalow-speed

24 bytes/frame No permitido 0.8 bytes/frame No permitido

¿Tasa garanti-zada de entre-ga?

No No No Si

Cuadro 1.6: Resumen de las transferencias y sus usos.

El cuadro 1.6 muestra los tipos de transmision con un resumen de las cualidades ysus tıpicos usos. Para cada transferencia se considera el maximo tamano del paquetepermitido.

31


1.7.1. Interrupt

Este tipo de comunicacion incorpora deteccion de errores y retransmision de datos.Es utilizado por aquellos dispositivos que desean transferir muy poca informacion yademas poco frecuente, asegurando la lectura de los datos dentro de un perıodo maxi-mo de tiempo. Los dispositivos full-speed pueden solicitar entre 1 y 255 ms, mientrasque los dispositivos low-speed pueden solicitar un perıodo maximo de servicio entre10 y 255 ms.

Interrupt tiene la particularidad de ser unidireccional por cada endpoint que sedefina (desde el host al dispositivo o desde el dispositivo al host). Ademas juntocon las transferencias de Control, las transferencias del tipo Interrupt son las unicasformas en que los dispositivos low-speed pueden transferir datos. Los teclados y losmouse usan este tipo de transferencias para enviar informacion de teclas, botones ydatos de los movimientos. Las transferencias de interrupcion pueden usar cualquiervelocidad ya sea low, full o high speed, pero los dispositivos no estan obligados asoportar las transferencias de interrupcion. Una clase especıfica de dispositivo laspodrıa precisar si la requiere.

Figura 1.14: Fases de una transaccion Interrupt.

Durante cada frame la maxima carga util de datos permitidos por las transfe-rencias de interrupcion es de 8 bytes para low-speed y de 8, 16, 32 o 64 bytes paradispositivos full-speed. Para USB 2.0 en modo high-speed el tamano maximo del pa-quete para las transferencias de interrupcion es aumentado a 1024 bytes. La reservade tiempo para acomodar transferencias de interrupcion es como maximo el 90% deltiempo del frame y 80% para microframe, esto porque las transferencias de Controltienen reservado el otro 10% restante. El sistema USB puede ir estableciendo pipes

32


de interrupcion con distintos dispositivos hasta agotar dicha reserva, en caso queesten agotadas las reservas y se incorporen nuevos dispositivos con transferencias deltipo Interrupt, el dispositivo respondera como no configurado.

Las transacciones del tipo Interrupt pueden ser transferencias IN o OUT1. Latransaccion se compone de tres fases: Token, Data y Handshake, tal como se muestraen la figura 1.14.

1.7.2. Bulk

La transferencia Bulk es una comunicacion no periodica, tıpicamente empleadapor transferencias que requieren usar todo el ancho de banda disponible o esperar has-ta que el ancho de banda este disponible. Esto implica particularmente movimientosde imagenes, archivos o video, donde se requiere de gran potencial de transferencia enpoco tiempo. Para estas aplicaciones, las transferencias pueden ser muy rapidas perolos datos pueden esperar si es necesario. Si el bus USB esta muy ocupado, entonceslas transferencias Bulk son lentas, pero si el bus de lo contrario esta desocupado,entonces las transferencias Bulk son muy rapidas.

Figura 1.15: Fases de una transaccion Bulk.

Los dispositivos full-speed y high-speed pueden hacer transferencias Bulk. Losdispositivos low-speed no pueden soportar las transferencias Bulk. Para dispositivosfull-speed el maximo tamano del paquete puede ser 8, 16, 32 o 64 bytes y para dis-positivos high-speed es de 512 bytes. Los dispositivos no estan obligados a tener unapipe tipo Bulk, pero una clase especıfica del dispositivo las podrıa precisar. Otra delas caracterısticas de la transferencia Bulk es la habilidad de garantizar la entrega de

1USB 1.0 solo admite transferencias del tipo IN, USB 1.1 soporta ambas.

33


datos libres de errores entre el host y el dispositivo.

Bulk usa 3 fases: Token, Data y Handshake (figura 1.15). Bajo ciertas condi-ciones del endpoint en el cual su estado esta en modo suspendido, la fase Data esreemplazada por el Handshake resultando solo 2 fases de transmision. Los camposPING y NYET solo son usados por dispositivos high-speed.

1.7.3. Isochronous

La transmision isocrona ha sido desarrollada especialmente para satisfacer las de-mandas de la transmision en tiempo real para voz, video e imagenes, donde los errorespueden ser tolerados (los posibles errores no se recuperan, la informacion que no llegaa su tiempo se descarta). La transferencia isocrona provee comunicacion continua yperiodica entre el host y el dispositivo, con el fin de mover informacion relevante a uncierto momento, donde la informacion util por paquete puede oscilar entre 1 y 1,023bytes. Solo los dispositivos full y high-speed pueden hacer transferencias isocronas ypara el caso de full-speed se puede reservar un ancho de banda de hasta un 90%. Enel caso que el sistema no puede garantizar el tiempo suficiente como para manejaruna nueva conexion isocrona (transmitir un nuevo paquete dentro del perıodo maxi-mo requerido), simplemente no se establece la conexion.

Figura 1.16: Fases de una transaccion Isochronous.

La figura 1.16 resume las fases permitidas dentro de una transferencia isocrona.Existen dos fases: Token y Data, no existe ninguna fase Handshake en las transfe-rencias isocronas.

1.7.4. CONTROL

Las transferencias de control estan definida para un solo uso: transportar las peti-ciones (request) standard y especificas definidas por la especificacion USB. El objetivo

34


es facultar al host para que este interrogue y configure a los dispositivos conectadosen los puertos. Por esta razon, la intervencion de este tipo de comunicacion es obliga-toria y solo aparece al principio de la conexion de un dispositivo, para luego dar pasoa las otras tres transferencias posibles. La transferencia de Control se hace a travesdel endpoint-0 bidireccional. Un fabricante puede colocar otros endpoint de Controla disposicion, pero no trae ninguna ventaja comparativa.

En la figura 1.17 se resumen las fases de una transaccion de Control.

Figura 1.17: Fases de una transaccion de Control.

35

Capıtulo 2

Controlador SL811HS

Este capıtulo explica el funcionamiento general del host controlador SL811HS, de-tallando las principales senales que posee. A su vez, se nombran las funciones basicasque permiten acceder a la lectura y escritura de los registros de configuracion delSL811HS, para luego nombrar y explicar cuales son los registros principales para elfuncionamiento en modo host.

2.1. Aspectos generales

El controlador USB SL811HS cuyo diagrama se muestra en la figura 2.1, esun chip de la companıa Cypress Semiconductor Corporation, capaz de comunicarsecon dispositivos USB tanto como para la velocidad low-speed, como para la veloci-dad full-speed. El controlador SL811HS solo soporta la norma del protocolo USB 1.11

Figura 2.1: SL811HS pin layout.

1USB 1.1 no soporta high-speed.

36

CAPITULO 2. CONTROLADOR SL811HS

A diferencia de otros controladores USB, el SL811HS puede ser controlado pordiversos dispositivos tales como: microprocesadores, microcontroladores, DSPs, yvariedades de buses como: ISA, PCMCIA y otros. De esta manera, el controladorSL811HS sirve para una variedad de sistemas embebidos en donde requieren de unaconfiguracion independiente del dispositivo que lo controle, ya sea para un modo host(controlador) o un modo slave (dispositivo USB).

2.1.1. Modulo de trabajo

La companıa Cypress a lo largo del tiempo ha sacado diferentes modelos de estechip, como por ejemplo: SL811, SL811S y SL811HS. A su vez, se ha revisado elfirmware del SL811HS agregando en varias ocasiones modificaciones, como por ejem-plo la generacion automatica de CRC. En la presente memoria se trabajo con el chipSL811HS version 1.5, ensamblado en un modulo de trabajo que es mostrado en lafigura 2.2. Este modulo fue realizado por el Departamento de Electronica como partedel trabajo de tıtulo de Michael Kusch.

Figura 2.2: Modulo de trabajo para el SL811HS.

En la presente memoria el modulo fue controlado a traves del microcontroladorMSP430F1612. El detalle de la conexion entre el microcontrolador, el controladorSL811HS y el display de 4 lıneas, se puede consultar en el Apendice B.

37


2.1.2. Modos host/slave

El SL811HS soporta dos modos de trabajo. El primer modo es USB Host quesirve para manejar y controlar diversos dispositivos USB. La segunda opcion es elegirel modo de trabajo USB Slave, que se utiliza para disenar dispositivos USB con lacapacidad de manejar diversos endpoints segun la necesidad del disenador. Estos dosmodos se pueden elegir a traves de un solo pin: se fija a tierra en caso que se trabajeen modo host o se conecta a Vcc para trabajar modo slave. Junto con la elecciondel pin master o slave, se debe construir un circuito propuesto por el fabricante paracada caso, pero que tienen una gran similitud de construccion. La similitud de loscircuitos fue aprovechado por Michael Kusch para ensamblar ambos modos en unasola placa, dando la opcion de elegir entre host y slave a traves de tres jumper talcomo lo muestra la figura1 2.2.

Figura 2.3: Conectores Serie-A y Serie-B.

La eleccion del modo de trabajo host o slave, lleva consigo a la utilizacion deconectores unicos para cada caso. Para trabajar en modo host los conectores y cablesse denominan Serie-A, en cambio los conectores en modo slave son llamados Serie-B(figura 2.3). Nunca se debe usar un modo de operacion y conectar ambas series,puesto que el SL811HS no trabaja en ambos modos al mismo tiempo.

2.2. Registro y memoria

El SL811HS usa un mapa de memoria de 256 bytes, los cuales se direccionan atraves de un bus de datos de 8 bits. Las primeras 16 direcciones (00h-0Fh) correspon-den a los 16 registros que se disponen para el control del chip tanto para el modo host

1En la figura 2.2, los tres jumper tienen el color azul.

38


y slave. Las direcciones restantes (10h-FFh) estan disponible para la implementaciondel buffer que envıa y recibe los datos a los dispositivos USB. El mapa de la memoriadel SL811HS se muestra graficamente en la figura 2.4.

Figura 2.4: Distribucion de la memoria y registros.

2.2.1. Registros generales de configuracion

ADDR. Funcion Escritura Funcion Lectura0x00 USB-A Control USB-A Control0x01 USB-A Address USB-A Address0x02 USB-A Length USB-A Length0x03 USB-A PID/EP USB-A Status0x04 USB-A Address USB-A Count0x05 Ctrl1 Ctrl10x06 Int. Enable Int. Enable0x07 Reservado Reservado0x08 USB-B Control USB-B Control0x09 USB-B Address USB-B Address0x0A USB-B Length USB-B Length0x0B USB-B PID/EP USB-B Status0x0C USB-B Address USB-B Count0x0D Int. Status Int. Status0x0E SOF Low HW Revision0x0F SOF High/Ctrl2 SOF High/Ctrl2

Cuadro 2.1: Registros de configuracion del SL811HS.

Los 16 registros mostrado en el cuadro 2.1 se pueden separar en 3 bloques:registros para la utilizacion en modo host (USB-A), registros para la utilizacion enmodo slave (USB-B) y registros comunes de control para ambos modos.

39


Los registros de configuracion tienen la caracterıstica que despues de escribir enellos se puedan leer para verificar los valores, sin embargo algunos registros funcio-nan de diferente manera para la lectura y escritura, adquiriendo una doble funcion:configurar los registros para el control e informar datos revelantes respecto a la co-municacion USB. La comprobacion de un registro solo tendra sentido para aquellosregistros que cumplan con la misma funcion (deben tener el mismo nombre para lec-tura y escritura en el cuadro 2.1).

2.2.2. Registros en modo host

Son 10 registros que se ocupan en modo host (12 funciones diferentes), los cualesse resumen en el cuadro 2.2. En el cuadro mencionado se muestra: el nombre de cadaregistro (columna 1), la definicion que ocupa en el codigo del programa (columna 2),la direccion del registro en el SL811HS (columna 3) y un resumen de las principalescaracterısticas (columna 4). La mayorıa de los registros son configuraciones bit a bit.Para mayor detalles de los registros y su configuracion se puede consultar el ApendiceC de este trabajo, donde ademas se incluyen ejemplos con los registros en modo host,o bien consultar el documento1 oficial.

Registro. Definicion Direcc. Caracterısticas

USB-A Control CTL 0x00 provee el control basico de las transacciones realizada porel host

USB-A Address BUFADR 0x01 fija en que parte de la memoria van a llegar o enviar losdatos

USB-A Length BUFLEN 0x02 fija el largo maximo de la transaccion

USB-A PID/EP PID EP 0x03 establece que tipo de paquete se va enviar y en que end-point

USB-A Status PKTSTAT 0x03 indica el resultado de la ultima transaccion

USB-A Address FNADDR 0x04 fija la direccion del dispositivo USB (0-127)

Ctrl1 CTL1 0x05 genera reset, control de low/full, suspension/habilitaciondel USB y generacion automatica 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 version del hardware

SOF High/Ctrl2 SOFCT H 0x0F contador high, para generar frame de 1ms

Cuadro 2.2: Registros y definiciones para modo host.

2.3. Senales de control

El microcontrolador accede al SL811HS por medio de una serie de pines de en-trada y de salida. Estas senales permiten realizar las funciones basicas para realizar

1El documento se puede encontrar en la pagina www.cypress.com o en el CD-ROM adjunto a la memoria,“Documentos/Sl811hs/SL811HS - Datasheet.pdf”.

40


las operaciones dentro del chip y ası poder establecer una comunicacion USB. Sibien es importante saber el funcionamiento de estas senales para poder construirlas primeras operaciones basicas dentro del chip, en un momento dado, luego de lasconstrucciones de las funciones basicas (lectura y escritura), estas senales pasaran aun segundo plano, ya que difıcilmente seran manipuladas en una forma directa porel programador. Las senales basicas se muestran en la figura 2.5.

Figura 2.5: Senales de acceso para el SL811HS.

A continuacion se explican las senales del SL811HS y se muestran las definicionesdel codigo para el uso del microcontrolador.

CHIP SELECT (nCS): Esta senal se usa para habilitar la lectura o escrituratanto de los registros de configuracion como del buffer para almacenamientode datos, de esta manera se protege el uso del chip cuando se compartan lasmismas senales 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 senal baja, el microcontrolador puede acceder a lalectura de los registros y memoria del SL811HS, sin embargo antes de que unalectura pueda llevarse a cabo, la direccion del registro o memoria que se desealeer debe estar escrita en el puntero del SL811HS. Previamente la senal nCSdebe habilitar la lectura del chip para que se pueda reconocer la senal 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


WRITE (nWR): Esta senal se activa con un bit bajo para que el microcon-trolador pueda escribir en el puntero, registro o memoria del chip. Al igual quela senal 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; // DigitalIO;

#define USB_WR_OUT P1DIR=BIT3;

#define USB_WR_IN P1DIR&=~BIT3;

ADDRESS (A0): La senal A0 es manejada para que en conjunto con la senalnWR 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; //OUT; DigitalIO;

#define USB_A0_OUT P1DIR=BIT5;

#define USB_A0_IN P1DIR&=~BIT5;

Las formas de ondas que se producen dentro del SL811HS cuando se produceuna 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 senal INTRQ entrega un valor alto al microcon-trolador, cuando ocurre una de las posibles interrupciones programadas dentrodel SL811HS, como por ejemplo la conexion de un nuevo dispositivo. INTRQvuelve a cero solo cuando el registro de interrupcion es borrado a traves desoftware.

42


#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 transferirdatos 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 senal NRST se realiza a traves de un nivel bajo de en-trada para generar un reset. El reset es valido cuando se cumplen 16 ciclos dereloj 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 basicas

El objetivo es poder realizar cuatro funciones que permitiran configurar y estable-cer la comunicacion USB: iniciar el SL811HS, leer registros/memoria, escribir en losregistros/memoria del SL811HS y detectar la velocidad de un dispositivo.

2.4.1. Escritura en registros

La funcion wr811(), cuyo codigo es mostrado mas abajo, realiza la funcion deescribir en la direccion del registro/memoria “a” del SL811HS, el valor del byte “d”.Para ello utiliza la habilitacion de las senales discutidas anteriormente.

void wr811(BYTE a, BYTE d) 1

USB_SELECT; //Make SL811 ready to communicate with.2

USB_DIR=0xFF; //Data port to outputs3

USB_OUT=a;4

USB_A0_OFF; //Write address to pointer5

USB_WR_OFF;6

USB_WR_ON;7

USB_OUT=d;8

USB_A0_ON; //Write data to register9

USB_WR_OFF;10

USB_WR_ON;11

43


USB_DIR=0x00; //Data port to inputs (for multiplexing)12

USB_DESELECT; //Liberate used signals13

14

Se construyo una funcion mas util para copiar datos en bloques desde memoriadel 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 funcion BuffWr811() es una variacion que permite escribir un bloque de datosde largo especıfico “c” desde un puntero “ptr” a la direccion addr del SL811HS.Como precaucion se debe usar siempre a partir de la direccion 0x10h (addr), puestoque antes se encuentran los registros de configuracion. En caso de querer modificar losregistros de configuracion, siempre sera mejor hacerlo a traves de la funcion wr811()que permite operaciones paso a paso, y de esta manera evitar posibles errores.

Otra operacion de escritura en el SL811HS es la funcion BuffClear811(). La fun-cion fue construida para borrar bloques de memoria del SL811HS. De esta manerase podra borrar basura o limpiar los registros para realizar analisis de los datosrecibidos y ası no mezclar los antiguos datos del SL811HS. El codigo para esta fun-cion es mostrado a continuacion:

void BuffClear811(BYTE addr, BYTE c)

if(c<=0)

return;

while (c--)

wr811(addr++,0x00);

2.4.2. Lectura de registros

La funcion que permite la lectura de los registros o buffer del SL811HS es la fun-cion rd811() donde el codigo es muy parecido a la funcion de escritura. El codigo

44


para esta funcion es mostrado a continuacion:

BYTE rd811(BYTE a) 1

unsigned char d;2

USB_SELECT; //Make SL811 ready to communicate with.3

USB_DIR=0xFF; //Data port to outputs4

USB_OUT=a;5

USB_A0_OFF; //Write address to pointer6

USB_WR_OFF;7

USB_WR_ON;8

USB_DIR=0x00; //Data port to inputs9

USB_A0_ON; //Read data from register10

USB_RD_OFF;11

d=USB_IN; //Read DATA12

USB_RD_ON;13

USB_DESELECT; //Liberate used signals14

return d;15

16

Al igual que en la seccion de la escritura, esta vez se diseno la funcion contraria.La funcion BuffRead811() permite leer y copiar datos en bloques desde el SL811HSal microcontrolador. El codigo de esta funcion es mostrado a continuacion.

void BuffRead811(BYTE addr, BYTE c, char *s)

if(c<=0)

return;

while (c--)

*s++=rd811(addr+);

2.4.3. Inicializacion del SL811HS

La inicializacion del SL811HS consiste en primer lugar en aplicar por medio desenales un reset1 al SL811HS . En segundo lugar se habilitan los puertos del microcon-trolador que van controlar las senales del SL811HS. Todo este proceso se encuentradisponible en la funcion USB init(). El codigo de la funcion se muestra a continuacion:

unsigned char USB_init(void)1

2

unsigned char rev;3

1Tambien es posible aplicar un reset a traves de los registro de configuracion, pero para ello tiene queestar inicializado el SL811HS.

45


USB_RST_OFF; //Reset activado4

USB_RST_init; //inicializacion de las se~nales5

USB_EN_ON;6

USB_EN_init;7

USB_PWR_OFF;8

USB_PWR_init;9

USB_WR_init;10

USB_RD_init;11

USB_INT_init;12

USB_PWR_FLG_init;13

Delayx100us(250);14

USB_RST_ON; //Reset desactivado.15

USB_SEL=0x00; //DigitalIO16

USB_PWR_ON;17

18

//obetencion de la version del Hardware.19

rev=( (rd811(HWR)&0xF0) >>4 );20

return rev;21

22

Antes que se desactive el reset con una senal alta (lınea 15 del codigo) se esperaun tiempo suficiente para asegurar que se cumplan los 16 ciclos de reloj y ası el resettenga efecto. Esta funcion retorna la version del hardware, leyendo el registro HWR1

del SL811HS. El numero obtenido tiene que desplazarse puesto que la informacionesta en los ultimos 4 bits del registro. El valor de la actual version del chip es 02h(version 1.5).

2.4.4. Deteccion low/full speed

Las cuatro interrupciones que se generan dentro del SL811HS activan una solasenal en el microcontrolador. Las interrupciones se habilitan o deshabilitan con elregistro IE (0x06) del SL811HS, dando las posibilidades de configurar las interrup-ciones para: la deteccion del puerto USB-A o USB-B, interrupciones de desconexiono conexion de un dispositivo esclavo, interrupcion por resumen/suspension de undispositivo y finalmente interrupcion cuando se produce un SOF (Start Of Frame).Como se puede analizar, las interrupciones (excluyendo la interrupcion por SOF) solotienen que ver con el dispositivo fısico. El registro que se encarga de informar cual esla interrupcion que se activa corresponde al registro INTSTATUS (0x0D), que juntocon decir la presencia o ausencia de un dispositivo, entrega informacion (en el bit7)si la lınea conectada es D+ o D-, determinando de esta manera si el dispositivo eslow-speed o full-speed.

Se puede decir que cuando se usa el SL811HS con un solo puerto de entrada (sinhub), las interrupciones que tienen que ver con el dispositivo fısico pueden llegar aser de uso ocasional. Por lo contrario, la interrupcion por SOF es una interrupcion deuso frecuente: cuando se envıan paquetes de control o datos a un dispositivo, estos

1El registro HWR esta definido como el registro de lectura 0x0E.

46


se hacen normalmente despues de generarse un SOF1 (inicio de un frame) y para ellose usa las interrupcion por SOF usando la funcion waitframes(BYTE n). La funcionmencionada retorna cuando pasa la cantidad de n-frame y justo despues de habersegenerado el SOF.

Funcion deteccion de velocidad

Internamente la funcion detectar velocidad() consiste en cuatro partes: desac-tivacion de las transferencias USB; comprobacion de la presencia o ausencia de undispositivo a traves de las interrupciones; determinar si el dispositivo es full o lowspeed y finalmente la configuracion para cada caso de velocidad. El codigo de la fun-cion detectar velocidad() es mostrado a continuacion:

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 operacion.

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.


printf("no hay dispositivo.");

return 0;

else

if (rd811(INTSTATUS)&USB_IF_D) //bit7 de registro 1=full,0=low.


printf("full speed.");

//activa para usar en full.

wr811(SOFCT_L, 0xE0);

wr811(SOFCT_H, 0x2E 0x80);

wr811(CTL1,0x01);

return 2;

else


printf("low speed.");

//activar low.

wr811(SOFCT_L, 0xE0);

wr811(SOFCT_H, 0x2E 0xC0);

wr811(CTL1,0x21);

return 1;

1La entrega de los paquetes se puede hacer de forma automatica despues de un SOF usando los registrosde configuracion, pero el SL811HS contiene un error que no permite el uso normal de esta configuracion.

47


//end detectar_velocidad.

Hay que mencionar que la funcion detectar velocidad() retorna valores segun seael caso: el valor 0 cuando no hay dispositivo, el valor 1 para dispositivos low-speed yel valor 2 para los dispositivos que sean full-speed. De esta manera la funcion detec-tar velocidad() es el primer paso para la enumeracion del bus.1

Existen dos escenarios distintos para la deteccion de un dispositivo: primer casocuando el dispositivo esta conectado desde un principio al controlador, y segundo casocuando ya se ha iniciado el funcionamiento del controlador y el usuario conecta untiempo despues el dispositivo USB. Para ambos casos la funcion detectar velocidad()cumple con el reconocimiento y configuracion del dispositivo. En el primer caso, endonde un dispositivo se encuentra inicialmente conectado al SL811HS, simplementebasta 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 funcion se puede condicionar el paso al restodel codigo con una sentencia while() hasta que se cumpla una condicion verdadera, esdecir, hasta que se conecte un dispositivo. Sin embargo, cuando se ocupa el microcon-trolador para realizar otras tareas y no tiene dedicacion exclusiva para el controladorSL811HS, se debe usar la funcion detectar velocidad() en una rutina de interrupciondel microcontrolador, tal como se muestra el siguiente codigo:

#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 utilizacion, ya sea en forma indirecta o di-recta, son convenientes dependiendo de las circunstancias. Por ejemplo, cuando seesta disenando dispositivos USB es preferible usar la funcion en forma directa parala mayor comprension y descartar posibles errores.

1Posteriormente la funcion detectar velocidad() va a ser incluida en otra funcion mas completa llamadaBus Enumeracion().

48


2.5. Visualizacion de los registros

Para la construccion de los primeros codigos de programas, la visualizacion de losregistros de configuracion fue un factor muy importante; cuando se producen erroresde comunicacion es necesario consultar los registros de configuracion y ası poder ais-lar el error verificando cada registro del SL811HS. Tambien es util consultar por losdatos que se estan enviando o recibiendo, ubicados en el buffer de SL811HS. Paraambos casos hay dos posibles soluciones: a traves del display de 4 lıneas o a travesde la herramienta watch del IAR Embedded Workbench1.

2.5.1. Visualizacion de los registros a traves del display

El display de 4 lıneas permite mostrar solo hasta 16 numeros en formato hexade-cimal (4 registros por lınea), lo cual es precisamente la cantidad de registros que tieneel SL811HS. Para ello se construyo la funcion Registros(BYTE a). El parametro “a”indica de donde empezar a mostrar los registros.

Figura 2.7: Visualizacion de los registros a traves del display.

Por lo tanto, con solo poner Registros(0x00) en cualquier parte del codigo delprograma, se podra obtener los primeros 16 registros de del SL811HS. En la figura2.7 se muestra un ejemplo real. Utilizando el ejemplo de la figura 2.7 se debe aclarardos cosas: no todos los registros mostrados en el display son para el modo host ysegundo, no todos los registros tienen la misma funcion de lectura y escritura.

2.5.2. Visualizacion de los registros a traves de la ventana Watch

Utilizando la herramienta watch del IAR embedded se pueden visualizar varia-bles, estructuras, arreglos, etc. La manera de cargar los registros a la memoria delmicrocontrolador es por medio de la funcion BuffRead811() mencionada en seccionesanteriores de este capıtulo y que permite leer bloques de memoria del SL811HS. Elprocedimiento para cargar los 16 registros es muy sencillo:

1Software que se utilizo para programar el microcontrolador MSP430f1612.

49


char temp[16] ;

BuffRead811(0, 16,temp);

La ventana watch se obtiene desde menu/view/watch y luego se escribe el nom-bre de arreglo que se desea ver. La figura 2.8 muestra el resultado obtenido de losregistros de configuracion en la misma situacion que en el ejemplo anterior. Se puedeobservar que los resultados son los mismos exceptuando por el ultimo registro. Estose debe a que el ultimo registro es un indicador de velocidad de transmision y siempreva a estar en constante cambio.

Figura 2.8: Visualizacion de los registros con la herramienta watch.

50

Capıtulo 3

Peticiones, descriptores yconfiguracion general

Este capıtulo describe como el host tiene a disposicion un set de herramientasdenominadas peticiones (Request). Se detalla el funcionamiento y nombre de lasprincipales peticiones que fueron creadas para que el host pueda utilizarlas en la in-terrogacion y configuracion de los dispositivos, mostrando en cada caso la estructurainterna de cada peticion. Ademas, se explican cuales son los pasos necesarios para laconfiguracion basica de un dispositivo USB y ası luego lograr establecer una comuni-cacion de transferencia en forma exitosa. Finalmente se nombran algunos programasque manejan diferentes aspectos de los dispositivos y protocolos, y de esta maneradescartar posibles errores en la construccion de codigos.

3.1. Peticiones

Las peticiones o Request son una serie de instrucciones definidas por USB-IF quepermiten a los controladores USB la interrogacion y configuracion de los dispositivos.La interrogacion permite obtener informacion clave para la asignacion de un driveradecuado. En total son 11 las peticiones standard que el host puede utilizar en dife-rentes tareas: desde asignar una direccion al dispositivo, hasta desactivar un endpointpara no recibir mas datos. No todas las peticiones tienen un uso fijo, un grupo reduci-do se dividen internamente para generar nuevas sub-peticiones. Algunas peticionesparticipan solo despues de que el dispositivo esta configurado, para ası monitorearmultiples sucesos. Un grupo importante de las peticiones se ejecutan solo al principiode cada configuracion, generando un proceso que se denomina Bus Enumeracion.

3.1.1. Tipos de peticiones

Las 11 peticiones que se muestran en el cuadro 3.1 son llamadas peticiones deltipo standard (Standard Request), definidas en el capıtulo 9 del protocolo USB y vali-das para USB 1.1 y 2.0. Las peticiones standard son de caracter de obligatoriedad de

51

CAPITULO 3. PETICIONES, DESCRIPTORES Y CONFIGURACION GENERAL

implementar por los disenadores de dispositivos USB, de esta manera siempre se vaa tener la seguridad que las peticiones responderan cuando el host las ocupa. Sin em-bargo, no es ası para las peticiones de clase donde grupos de dispositivos de similarescaracterısticas se asocian. Por ejemplo la clase de dispositivos de almacenamientomasivos, en donde se agrupan dispositivos tales como pendrives, CD-ROM, DVD,discos duros, etc. Las clases disponen de nuevas peticiones que son definidas en susrespectivos document class. Las peticiones de clases pueden entregar algun tipo deinformacion adicional, o bien realizar alguna funcion especıfica dentro del dispositivo.

Nombre Valor Nombre Valor(bRequest) (bRequest)

get status 0 set descriptor 7clear feature 1 get configuration 8reservado 2 set configuration 9set feature 3 get interface 10reservado 4 set interface 11set adress 5 synch frame 12get descriptor 6

Cuadro 3.1: Peticiones Standard.

El nombre de cada peticion tiene asociado un valor unico para la identificacion.El valor de cada peticion es pasado como parametro en conjunto con otros valoresque finalmente definen a la peticion. El detalle de las construcciones de las peticionesse vera posteriormente.

3.1.2. Principales peticiones

Las principales peticiones son las que pertenecen al llamado Bus Enumeracion.Estas son: set adress, set configuration, get configuration y get descriptor (descrip-tores generales).

3.1.3. set adress

Todos los dispositivos al conectarse por primera vez estan en la direccion cerodel host, lo que lleva a que siempre se deba estar liberando la direccion para laconfiguracion de los nuevos dispositivos. Mientras un dispositivo permanezca en ladireccion cero, el host no podra reconocer otro dispositivo. La peticion set adressrealiza la asignacion de una entre las 127 direcciones que estan disponibles. En loscontroladores USB la asignacion es unica para el dispositivo, por lo tanto solo unavez se puede asignar una direccion a un dispositivo. La funcion creada para que elhost pueda obtener el acceso a esta peticion se muestra a continuacion:

52


Funcion:

set_adress(BYTE adress);

La peticion no retorna ningun valor hacia el host. El parametro adress determi-na la nueva direccion del dispositivo. Por ejemplo set adress(0x01) significara queel nuevo dispositivo estara en la direccion numero 1. La direccion no tiene que sernecesariamente una direccion correlativa, puede tomar cualquier valor menos el valorde 0. Sin embargo, en caso de que el SL811HS tenga configurado un HUB, es re-comendable usar direcciones ordenadas.

3.1.4. set configuration

La peticion set configuration es para declarar que el dispositivo esta completa-mente configurado. De esta manera, el dispositivo ya puede comenzar a usarse sinproblemas. Los dispositivos que no estan declarados como configurados no suelenresponder a las transferencias de datos. La funcion creada para tener acceso a estapeticion se muestra a continuacion:

Funcion:

set_configuration (BYTE adress, BYTE value);

El parametro adress indica la direccion del dispositivo en donde se aplicara estapeticion. El parametro value indica la configuracion que se ha elegido para el dispo-sitivo. El valor lo determina otra peticion llamada Configuration Descriptor en sucampo de retorno llamado bConfigurationValue. Por lo general los dispositivos traenuna sola configuracion y el valor del parametro value es siempre de 0x01.

3.1.5. get configuration

Una manera de saber si realmente un dispositivo esta configurado es a traves dela peticion get configuration. La peticion retorna al host el valor de la actual confi-guracion del dispositivo. En caso que el dispositivo no esta configurado, la peticionget configuration retorna el valor 0. Por lo general la peticion get configuration no esun requisito obligatorio dentro del Bus Enumeracion. La funcion creada para teneracceso a esta peticion se muestra a continuacion:

53


Funcion:

int set_configuration (BYTE adress);

3.2. Descriptores

Sin duda una de las peticiones que caracteriza el funcionamiento USB, donde nece-sariamente es un punto de discusion con mas detalle para cualquier tipo de diseno,son las peticiones que se obtienen por medio de get descriptor, comunmente nombra-do como descriptores. La importancia de esta peticion standard radica en el hecho deque cada dispositivo USB tiene grabado en una ROM las descripciones e interfaceshechas por el fabricante del producto. Saber el detalle de las descripciones es com-pletamente necesario para que el host pueda determinar el driver apropiado. Entrelos muchos datos que se pueden obtener estan por ejemplo: tipo de transferencia(Control, Isochronous, Bulk, Interrupt), clase de dispositivo, transferencia maxima,numeros de endpoints disponibles, etc., en fin, una cantidad de informacion util. Sinembargo, tambien se puede consultar por detalles que no son necesarios para el fun-cionamiento del dispositivo pero puede servir de informacion general, por ejemplolos descriptores del tipo string donde entregan datos como: nombre del fabricante,modelo del aparato, numero de serie, etc.

3.2.1. Descriptores Standard

Figura 3.1: Descriptores Standard.

54


Son cuatro los Descriptores Standard que se pueden solicitar. La figura 3.1 mues-tra como se dividen jerarquicamente ya que cada descriptor depende del anterior. Sepuede observar que cada dispositivo tiene un Device Descriptor que contiene infor-macion general acerca del dispositivo: numero de la version del USB, maximo tamanopara el endpoint-0, identificadores de fabrica y producto, etc. A su vez, un dispositivoUSB puede tener diferentes configuraciones para que el host puede elegir cual masle convenga, como por ejemplo ahorrar energıa. Normalmente no existen productosUSB con alternativas de configuraciones. Configuration Descriptor contiene in-formacion como: configuraciones posibles, energıa requerida para funcionar, indicarsi la energıa es proveniente del propio Bus USB o de alimentacion externa. CadaConfiguration Descriptor tiene varios Interface Descriptor que detallan: endpointdisponibles y tipo de clase al cual pertenece el dispositivo. Finalmente, el ultimodescriptor corresponde al Endpoint Descriptor que contiene el detalle sobre cadaendpoint, indicando: tamano, tipo de transferencia y direccion (IN-OUT).

Cada descriptor entrega los valores a traves de campos que estan identificadoscon sus respectivos nombres. Ademas, cada descriptor puede tener hasta 18 camposde 1 a 2 bytes. Los primeros dos campos de los descriptores comienzan siempre dela misma manera: el primer campo muestra el largo del descriptor (bLength) y el se-gundo campo identifica el descriptor que se solicito (bDescriptorType). Los nombresde los campos empieza con una letra que identifica el tipo o la forma como debe serleıdo: la letra “b” indica que es del tipo byte, “bcd” indica codigo decimal binario,“id” indica que es identificacion y por ultimo la letra “i” indica que es del tipo string.

A continuacion se describen los campos de cada descriptor, destacandose los cam-pos mas importante para el desarrollo de aplicaciones con dispositivos USB. En cadadescriptor se muestra la respectiva funcion que permite el acceso a ellas, en donde seincluye un ejemplo real obtenido con las funciones para los descriptores. El detalleespecıfico de cada campo se puede encontrar en el capıtulo 9 del protocolo USB.

3.2.2. Device Descriptor

El formato del Device Descriptor corresponde al mostrado en el cuadro 3.2.

El campo bcdUSB describe la version del protocolo USB para el dispositivointerrogado. USB 2.0 es interpretado por el numero 0x0200, USB 1.1 por 0x0110y USB 1.0 por 0x0100. Para el caso del controlador SL811HS la version sera 1.1indistintamente si el dispositivo es para la version 2.0.

Los campos bDeviceClass, bDeviceSubclass, bDeviceProtocol identificana que grupo (clase) de dispositivo corresponde y a que dispositivo especıfica-mente corresponde de ese grupo. Normalmente los valores de estos campos sonsiempre cero, exceptuando por los hub y algunos dispositivos especiales. Cuando

55


Campo Tamano Descripcion Ejemplo(bytes)

bLength 1 tamano del descriptor en bytes 0x12

bDescriptorType 1 constante DEVICE(01h) 0x01

bcdUSB 2 num. de especificacion USB 0x0110

bDeviceClass 1 codigo de clase 0x00

bDeviceSubclass 1 codigo de subclase 0x00

bDeviceProtocol 1 codigo de protocolo 0x00

bMaxPacketSize0 1 tamano maximo para el paquete del endpoint0 0x40

idVendor 2 vendedor ID 0x3540

idProduct 2 producto ID 0x0215

bcdDevice 2 num. de version del producto. 0x0110

iManufacturer 1 index del String Descriptor para la fabrica 0x01

iProduct 1 index del String Descriptor para el producto 0x01

iSerialNumber 1 index del String Descriptor para la serie 0x00

bNumConfigurations 1 numero de posibles configuraciones 0x01

Cuadro 3.2: Estructura del Device Descriptor.

los valores tienen el valor cero, los valores reales de estos campos son definidosen el Interface Descriptor a traves de los campos bInterfaceClass, bInterface-SubClass, bInterfaceProtocol. El detalle de las clases y subclases se discutiranposteriormente.

Los campos iManufacturer, iProduct, iSerialNumber entregan un valorllamado index el cual es ingresado como parametro dentro del descriptor op-cional llamado String Descriptor. El valor cero indica que no hay informacionconsultable, como es el caso de numeros de series para dispositivos como tecla-dos y mouse.

La funcion construida con la cual se puede acceder a este descriptor es:

Get_DescriptorDevice(BYTE adress);

El parametro adress indica la direccion del dispositivo. Esta funcion tiene laventaja de mostrar los descriptores no solo para aquellos dispositivos que seestan conectando por primera, sino tambien, para los dispositivos que ya hansido configurados. La funcion Get DescriptorDevice(), al igual que las otras fun-ciones que se construyeron para solicitar a los descriptores, retornan los valoresen estructuras de datos con los mismos nombres del descriptor original. Porejemplo la funcion Get DescriptorDevice() retorna los valores en la siguiente

56


estructura1:

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 vi-sualizar 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 funcion Get DescriptorDevice()cuando se conecta un teclado USB al controlador SL811HS.

1El resto de las funciones para los descriptores retornan en estructuras similares cambiando los nombresde los campos y el nombre de la estructura.

57


Figura 3.3: Device Descriptor al conectar un teclado USB.

3.2.3. Configuration Descriptor

El formato del Configuration Descriptor corresponde al mostrado en cuadro 3.3.

Campo Tamano Descripcion EjemplobLength 1 largo de este descriptor en bytes 0x09bDescriptorType 1 constante CONFIGURATION(02h) 0x02wTotalLength 2 largo real 0x0022bNumInterfaces 1 numero de interfaces 0x01bConfigurationValue 1 identificador de la configuracion 0x01iConfiguration 1 ındice del string configuracion 0x00bmAttributes 1 alimentacion propia o remota 0xA0MaxPower 1 corriente requerida 0x32

Cuadro 3.3: Configuration Descriptor.

El campo wTotalLength (tercer campo) indica el largo total del actual descrip-tor, agregando ademas, la suma de todo el resto de los descriptores que quedan porconsultar: cuando se accede a este descriptor, uno de los parametros que se fijanes indicar el largo del Descriptor (corresponde al valor 0x09, primer campo). Sinembargo, la manera de acceder a los demas descriptores que quedan por consultares a traves del mismo formato del descriptor (codigo original de la funcion), perocambiando el parametro que indica el largo de retorno de los datos. De esta manerael dispositivo devuelve al host todo el resto de los descriptores, incluyendo algunosdescriptores de clase. El maximo retorno de datos es de 255 bytes. Poner un valordiferente al establecido al wTotalLength hace que el dispositivo no reconozca el co-mando y retorne un Stall.

bmAttributes y MaxPower son campos que describen las necesidades de energıadel dispositivo. Si el bit6 del campo bmAttributes es 1, este indicara que el dispositivo

58


es auto-alimentado, de lo contrario, un valor 0 indicara que es el Bus quien alimentaal dispositivo. Por su parte el campo MaxPower indica la corriente necesaria parael dispositivo, para ello se multiplica el valor del campo por 2 y el resultado sera enmiliamperes.

La funcion construida con la cual se puede acceder a este descriptor es mostradoa continuacion:

Get_DescriptorConfig(BYTE adress);

La figura 3.4 muestra los datos obtenidos por medio de la herramienta watchpara el Configuration Descriptor. En este caso los datos obtenidos corresponden a unmouse.

Figura 3.4: Configuration Descriptor de un mouse.

3.2.4. 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 mas importante detodos los descriptores. Una clase se emplea para especificar la manera en que unainterfaz se comunica con el host, tanto a nivel de datos como a nivel de control,entregando informacion sobre la funcionalidad del interfaz. Las distintas clases es-tandarizadas por USB-IF hacen que la gran mayorıa de los fabricantes de dispositivosUSB trabajen con ellas, pues de lo contrario deberan desarrollar sus propios drivers.Otra ventaja de las clases es que se asegura que el host reconocera y manejara sinningun tipo de problemas al dispositivo. Tambien existen los dispositivos compuestos

59


que usan multiples clases, por ejemplo un telefono tiene la clase HID (human inter-face device), la clase audio y clase de telefonıa. Los valores para bInterfaceClass ysus respectivas clases estan en el cuadro 3.5.

Campo Tamano Descripcion EjemplobLength 1 tamano del descriptor en bytes 0x09bDescriptorType 1 constante INTERFACE(04h) 0x04bInterfaceNumber 1 valor para fijar la interface 0x00bAlternateSetting 1 valor para consultar sentencias alternativas 0x00bNumEndpoints 1 numeros de endpoints para la interfaz 0x02bInterfaceClass 1 codigo de la clase 0x03bInterfaceSubClass 1 codigo de la subclase 0x00bInterfaceProtocol 1 codigo del protocolo 0x00iInterface 1 index del string de la interface 0x00

Cuadro 3.4: Interface Descriptor.

Class Device bInterfaceClassAudio 0x01CDC-Control 0x02Human Interface 0x03Physical 0x05Image 0x06Printer 0x07Mass-Storage 0x08HUB 0x09CDC-Data 0x0AChip/Smart Card 0x0BContent-Security 0x0DVideo 0x0EDiagnostic Device 0xDCWireless Controller 0xE0Application-Specific 0xFEVendor-Specific 0xFF

Cuadro 3.5: Clases USB.

El sistema operativo Windows utiliza las clases para mostrar en la barra de inicioel grupo de dispositivo que se ha conectado. En la figura 3.5 se puede observar queWindows esta reconociendo y configurando la clase llamada Human Interface Device(dispositivo de interfaz humana), que corresponde a los dispositivos como tecladosy mouse. En la presente memoria se trabajaron con las clases de interfaz humana(0x03) y de almacenamiento masivo (0x08).

60


Figura 3.5: Mensaje de Windows para un dispositivo USB.

Los valores de lo campos para bInterfaceSubClass y bInterfaceProtocol de-penden de cada clase. Por ejemplo en la clase de interfaz humana especifica si eldispositivo es un mouse o teclado.

La funcion 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 delIAR embedded. En este caso corresponde a un mouse conectado al puerto USB delSL811HS.

Figura 3.6: Interface Descriptor para un mouse.

61


3.2.5. Endpoint Descriptor

El formato del Endpoint Configuration corresponde al mostrado en el cuadro 3.6.

Campo Tamano Descripcion EjemplobLength 1 tamano del descriptor en bytes 0x07bDescriptorType 1 constante ENDPOINT(05h) 0x05bEndpointAddress 1 direccion de la transferencia 0x82bmAttributes 1 tipo de transferencia 0x03wMaxPacketSize 2 maximo tamano de paquete 0x0040bInterval 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 restode los bit son reservados. Si el valor es 00 indica que es del tipo Control, 01Isochronous, 10 Bulk y 11 del tipo Interrupt.

El campo bEndpointAddress indica la direccion del endpoint. El ultimo bitindica el sentido que tiene el endpoint (IN o OUT). Por ejemplo el endpoint 0x02equivaldrıa a un endpoint con la direccion 0x02 tipo OUT y 0x82 equivaldrıa aun endpoint con la direccion 0x02 pero tipo IN.

bInterval es el tiempo medido en frames que indica el perıodo maximo en quese debe consultar por las interrupciones. Es obligacion del host consultar porlas interrupciones.

La funcion construida con la cual se puede acceder a este descriptor es mostradoa continuacion:

Get_DescriptorEndpoint(BYTE adress);

La figura 3.7 muestra los datos obtenidos (dos endpoint) para Get DescriptorEndpointal conectar una impresora1 EPSON C60 al puerto USB del host SL811HS.

1Los datos de una impresora a otra son variables, pero siempre son los mismos para un mismo dispositivo.

62


Figura 3.7: Endpoint Descriptor para una impresora.

3.2.6. String Descriptor

Un String Descriptor es una peticion opcional de implementar por los fabricantes.Lo que entrega esta peticion es un texto UNICODE1 sobre configuraciones, fabrica,producto, numero de serie, interfaces, etc. Muchas veces se pueden encontrar textosvacıos a la hora de consultar por estas descripciones, como los casos de los mouse yteclados, ya que por la gran cantidad de productos emitidos no se declaran por ejem-plo numeros de series. Sin embargo, tiene mas sentido declarar numeros de series endispositivos de mayores costos como los pendrives o modems. Un numero de seriepuede a veces resolver problemas de conflictos con equipos o simplemente cargar masrapido un driver, ya que las series de una fabrica son unicas.

La figura 3.8 muestra un mensaje que emite el sistema operativo WindowsXPcuando se conecta un mouse de marca Genius modelo NetScroll. Este mensaje no sevuelve a mostrar si el mouse es colocado en el mismo puerto del computador, perosı se muestra un mensaje sobre la clase de dispositivo que se encontro (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 conel String Descriptor. Para ello se ingresa como parametro de entrada el valor delcampo del iProduct que entrega el Device Descriptor. Todos los campos que son del

1El texto por defecto es UNICODE pero es configurable a otros tipos de textos.

63


tipo index son los campos que comienzan con la letra i1. Si el valor del index es dis-tinto de cero significa que trae informacion consultable a traves del String Descriptor.

Para consultar el String Descriptor en el controlador SL811HS, se realiza con lasiguiente funcion:

Get_DescriptorString(BYTE adress, BYTE index, char *ptr);

El parametro adress indica la direccion del dispositivo, por su parte index especi-fica lo que se va a consultar. A diferencia de los demas descriptores, este descriptorno tiene una estructura fija, es decir, no tiene un tamano unico pues los datos queentregan los dispositivos es variable desde 0 a 255 bytes.

Codigo de ejemplo:

char temp[255];

Get_DescriptorString(0x01,Device_Descriptor.iProduct, temp);

En el codigo de ejemplo se puede observar que se esta consultando por el nombredel producto del dispositivo. El dispositivo esta conectado en la direccion 1 del con-trolador. 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 barrade inicio (Netscroll).

3.2.7. Construccion de las peticiones

Las peticiones van en un paquete de 8 bytes denominado Setup Packet. Es el hostel encargado de entregar este paquete al dispositivo. El Setup Packet a su vez se

1Los campos tipo id no son validos.

64


compone de 5 campos tal como se muestra en el cuadro 3.7. Cada uno de los camposes de tamano de 1 o 2 bytes, donde algunos son configuraciones bit a bit. Los valoresde los campos del Setup Packet son siempre fijos para cada una de las peticionesestandar establecido por USB-IF en el capıtulo 9 del protocolo USB.

Posicion Nombre Bytes Descripcion0 bmRequestType 1 fija la direccion de la transferencia1 bRequest 1 valores de 0 a 12, segun se la peticion.2 wValue 2 varıa segun la peticion4 wIndex 2 varıa segun la peticion6 wLength 2 cantidad de bytes a transferir

Cuadro 3.7: Campos del Setup Packet.

Se construyo una funcion que enviara el Setup Packet y retornara los resultadosen un puntero. La funcion construida se muestra a continuacion:

int Request(BYTE bmRequestType,

BYTE bRequest,

WORD wValue,

WORD wIndex,

WORD wLength,

BYTE adress,

char *ptr

)

La funcion Request() es la base de la construccion de las peticiones que se hanexpuesto en este capıtulo. En ella se le ingresan los cinco campos del Setup Packeten conjunto con la direccion del dispositivo. La funcion retorna el valor “1” cuandola peticion que se solicito existe, de lo contrario, retorna el valor “0”. La funcionRequest() permite experimentar con los valores cuando los documentos oficiales pro-porcionado por USB-IF no son claros para el relleno del Setup Packet. Los documen-tos de clases entregan los valores de los campos de una forma mas precisa para laspeticiones de clases. En el Apendice D se encuentran los detalles de la construccionde la funcion Request(), para ası construir nuevas peticiones.

3.3. Configuracion de un dispositivo cualquiera

Como se dijo al principio de este capıtulo, la configuracion de cualquier dispositivo USBes por medio de una serie de pasos llamado Bus enumeracion. Los pasos para el SL811HSson los siguientes:

65


Deteccion de Velocidad

Get Descriptor (Device)

Get Descriptor (Configuracion)

Get Descriptor (Interface)

Get Descriptor (Endpoint)

Set Adress

Set Configuration

Get Configuration

El primer paso corresponde a la deteccion de la velocidad del dispositivo, y es realizadopor el host (SL811HS ) sin hacer ningun tipo de comunicacion directa con el dispositivo,pues es un juego de las senales en conjunto con el manejo de los registros de configuracion.El resto de los pasos son descriptores y peticiones que necesitan una comunicacion deltipo Control y fueron analizados anteriormente. Entre cada paso que se realiza en el BusEnumeracion, hay tomas de decisiones entre los descriptores a traves de las estructurasde los campos, esto lleva a la dependencia de los resultados. Es por eso que esta serie depasos tienen un orden que hay que respetar. No es solo para el caso del host controladorSL811HS, sino tambien, para todos los sistemas operativos que manejan USB. El sistemaoperativo Windows al realizar la Bus Enumeracion agrega la peticion del tipo string parautilizar el nombre del equipo y ası mostrar al usuario lo que se esta configurando en esemomento.

Se desarrollo una funcion estricta y segura para la realizacion de la Bus Enumeracion. Lafuncion que reune a todos los pasos y carga los descriptores es la funcion Bus Enumeracion().El codigo es mostrado a continuacion:

int Bus_Enumeracion(BYTE direccion)1

2

if( detectar_velocidad() ==0) //si no hay dispositivo conectado retorna3

return 0;4

else5

6

//solo si hay algun dispositivo conectado.7

Get_DescriptorDevice(0x00);8

Get_DescriptorConfig(0x00);9

Get_DescriptorInterf(0x00);10

Get_DescriptorEndpoint(0x0);11

Set_Adress(direccion);12

Set_Configuration(direccion,Config_Descriptor.bConfigurationValue);13

14

//comprobacion del dispositivo configurado15

if (Get_Configuration(direccion) == Config_Descriptor.bConfigurationValue)16

17

SEND_CMD(LINE2);18

66


printf("Disp. Configurado");19

return 1; // exito20

21

else22

23

SEND_CMD(LINE2);24

printf("Disp. No Configurado");25

return 0;26

27

28

29

En caso de no detectar un dispositivo o no comprobar el estado de la configuracion, lafuncion Bus Enumeracion() retorna un “0” y en caso de exito la funcion retorna el valor “1”.

Con la presencia de un hub, los pasos nombrados anteriormente tambien cumplen con elobjetivo de asignarle una direccion, ya que el hub es un dispositivo USB como otro mas. Ladiferencia radica en que una vez que el hub termina de ser configurado, se deben construirnuevas peticiones definidas especialmente para el hub, las cuales se pueden construir con lafuncion Request(). Estas nuevas peticiones sirven para el control y monitoreo de los puertos.

Con la construccion de las peticiones y la funcion Bus Enumeracion(), la parte princi-pal del programa solamente tendrıa unos pocos pasos para la configuracion inicial de undispositivo. El codigo siguiente muestra como serıa la configuracion de un equipo USB.

#include <stdio.h> /* For printf(). */1

#include <msp430x16x.h>2

#include "LCD_4.inc"3

#include "minhost.c"4

#include "peticiones.c"5

6

/*-----------------------------------------------------------------------------------*/7

int main(void)8

9

Init_Osc_X2();10

Init_LCD();11

Delayx100us(5000);12

USB_init(); //inicializacion del SL811HS13


15

Bus_Enumeracion(0x01); //bus enumeracion direccion 1.16

17

Se debe subrayar que algunos dispositivos como los de almacenamiento masivo que traenincorporado reproductores de mp3 y otras funciones (display y radio), pueden afectar detal manera que no se configure el dispositivo. Esto porque algunos de ellos se enciendende forma mas lenta que otros, causando que las peticiones no respondan. Las peticionesson validas en un cierto tiempo que el host tolera. Sobrepasar ese tiempo involucra que laspeticiones se pierdan y el host responda con un timeout. La colocacion de tiempos grandesantes de hacer las peticiones evita problemas de esa indole. La figura 3.10 muestra como

67


se vera la pantalla luego de realizar un bus enumeracion en el SL811HS de forma exitosa1.

Figura 3.10: Visualizacion de la pantalla despues de usar Bus Enumeracion.

3.4. Programas para los descriptores

Unas de la maneras de comprobar los descriptores es por medio de programas especiali-zados. Los programas para diseno USB pueden ser herramientas muy utiles en el principiodel diseno de drivers, pues se debe estar seguro que los descriptores obtenidos son los co-rrectos y ası descartar algun tipo de error en la construccion de ellos. Poner datos erroneosen los drivers, ya sea como el asignar una direccion de un endpoint no valido, lleva a quelos dispositivos nunca realicen sus funciones.

3.4.1. USBview

Hay muchos programas que muestran de manera didactica los descriptores, pero en sumayorıa son limitados hasta que no se pague por el precio del programa. Sin embargo, elprograma mas simple, liviano y gratis es el que en un principio dispuso USB-IF en su paginaoficial www.usb.org llamado USBview (figura 3.11). Sin embargo, actualmente el programase encuentra no disponible en su web. En la presente memoria se incluye USBview para suutilizacion.

En un principio, el programa USBview muestra todos los Root Hub que se encuentraen el computador. Para un optimo resultado se debe tener marcada las opciones mostradasen la figura 3.11. De esta manera el detalle de los descriptores sera mejor. La figura 3.14muestra el listado de los descriptores utilizando USBview.

1La implementacion de la pantalla no es requisito para utilizar las peticiones, solo bastara con desactivarlas funciones printf().

68


Figura 3.11: USBview mostrando los dispositivos conectados.

Figura 3.12: USBview mostrando los descriptores.

3.4.2. USBCommandVerifer

Otro programa de uso libre que dispone USB-IF es USBCommandVerifer (figura 3.13).El programa tiene varias herramientas donde la mas importante es verificar que las peti-ciones que estan estipuladas en el capıtulo 9 del protocolo USB estan bien establecidas enel dispositivo y pueden ser solicitadas. Tambien tiene otras funciones como por ejemplo:verificar si un dispositivo USB 2.0 puede funcionar en un host USB 1.1, test para disposi-tivos de interfaz humana y test para Hub.

69


Figura 3.13: USBcommandVerifer.

3.4.3. Hardware

Existe Hardware especializado de gran costo que sirve para monitorear el trafico USB(sniffer). La ventaja de estos instrumentos es que pueden capturar todo el trafico incluyen-do cuando se produce la enumeracion del bus, cosa que los programas en su mayorıa nopueden hacer. La captura de datos puede facilitar la construccion de funciones y driversespecializados como tambien facilitar el aprendizaje del protocolo USB. Uno de los hard-ware mas usado por su menor costo es Usbviewer1 cuyo valor es cercano a los US$1000.

Figura 3.14: Conexion de un sniffer para la captura de datos.

1El producto se puede ubicar en la pagina Web: www.usbdeveloper.com.

70

Capıtulo 4

Dispositivos de interfaz humana

Este capıtulo describe al grupo de dispositivos que pertenece a la clase de interfaz hu-mana, detallando la comunicacion y su forma de entregar los datos al host. Se explican losdescriptores standard y especiales para esta clase, mostrando ejemplos reales de dispositivosencuestados. Se establece como se debe reconocer los dispositivos de esta clase y cuales sonlos pasos a seguir para su eventual configuracion. Finalmente se muestra una aplicacioncon los dispositivos HID.

4.1. HID

Human Interface Device (HID) es la clase de dispositivo mas popular entre los usua-rios de computadores. La razon radica en que esta clase define y clasifica principalmentea dispositivos que son utilizados en una forma directa por las personas, con el objetivo deinteractuar y dar ordenes al computador. Tambien otro factor que ha influido en la masifi-cacion de los productos, es su bajo costo de elaboracion. Por su parte, el sistema operativoWindows fue el pionero (1995) en incorporar los drivers para el soporte USB-HID, a travesde su sistema operativo Windows95b.

4.2. 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 ordenes del usuario, sin embargo esta claseincorpora en una gran mayorıa a los dispositivos de baja velocidad de transmision (low-speed), donde es comun encontrar dispositivos que no necesariamente interactuan de unaforma directa con las personas como se dijo inicialmente, sino mas bien, son dispositivosque cuya mision es informar como es el caso de los lectores de codigo de barra.

Los dispositivos de interfaz humana que necesitan estar en tiempo real, donde tienenrequisitos como estar en una constante retroalimentacion de datos con el host, son clasi-ficados en otra clase llamada PID (Physical Interface Device) como es el caso de algunos

71

CAPITULO 4. DISPOSITIVOS DE INTERFAZ HUMANA

controles de juego avanzados que no pertenecen a la clase HID. Tambien es el caso de dispo-sitivos como camaras Webs o camaras fotograficas que suelen confundirse con dispositivosde clase HID, ellos pertenecen a la clase llamada imagen class.

Los ejemplos mas tıpicos de la clase HID son:

Teclados, apuntadores, mouses, joysticks y trackballs.

Paneles de controles tales como: tabletas graficas, sliders, botones, controles remotos,pedales.

Algunos dispositivos de audio como: telefonos, microfonos o altavoces digitales, etc.

Dispositivos que no requieren de una intervencion humana pero comparten la mismaclase como por ejemplo: lectores de codigos de barras, voltımetros, termometros, lin-ternas, ventiladores, etc.

En la clase HID es considerable destacar que dada su versatilidad, un dispositivo com-puesto puede llevar incluido en su composicion fısica un dispositivo de clase HID. Es elcaso de los telefonos que perteneciendo a la clase de audio, tienen incorporado parte de unainterfaz humana en los botones u otras funcionalidades anadidas al telefono.

4.3. Pipes de la Clase HID

La clase HID solo se puede comunicar a traves dos pipes, tal como lo muestra la figura4.1.

Figura 4.1: Pipes de la clase HID.

La primera comunicacion por defecto y ademas de caracter obligatorio de tener porparte de los dispositivos de clase HID, es la pipe de Control. Esta pipe, como se dis-cutio en el primer capıtulo, es bi-direccional y corresponde al endpoint-0. Se utilizabasicamente para recibir y responder las peticiones de configuracion del dispositivoUSB-HID. De esta manera, se intercambian en una etapa inicial los datos necesariospara el reconocimiento del dispositivo, usando los Descriptores y Peticiones Standard.

72


El otro tipo de comunicacion que se encuentra, corresponde a la pipe del tipo Inte-rrupt. Esta atiende, por medio de su endpoint, la recepcion y envıo asıncrona de losdatos.

En el caso de la comunicacion de la clase HID se tiene la particularidad que en lamayorıa de los dispositivos el flujo de datos se hace en una sola direccion (IN), dondepracticamente es muy difıcil encontrar dispositivos que tengan incorporado un endpointInterrupt del tipo OUT. Esto es porque en la clase HID el endpoint OUT es totalmenteopcional. El cuadro 4.1 muestra un resumen de la comunicacion en la clase HID.

Pipe Descripcion RequeridoControl USB control, peticiones, descriptores siInterrupt In datos de entrada, esto es desde el device al host siInterrupt Out datos de salida, esto es desde el host al device opcional

Cuadro 4.1: Resumen de la comunicacion HID.

4.4. Identificacion

Para la identificacion de la clase HID y especificar el dispositivo que se encuentraconectado al controlador, se realiza la comprobacion de los siguiente tres campos: bInter-faceClass, bInterfaceSubClass, bInterfaceProtocol. Estos campos definen la clase,subclase y protocolo respectivamente. Los tres campos pertenecen a la peticion InterfaceDescriptor.

4.4.1. Clases

La especificacion USB define a la clase HID con el valor 0x03 para el campo bIn-terfaceClass, de esta manera todos los dispositivos que cumplan con las caracterısticas yconfiguraciones de la clase HID deberan tener el valor mencionado para el campo.

4.4.2. Subclases

El cuadro 4.2 muestra los valores posibles para el campo bInterfaceSubClass. El valor1 para la subclase define la capacidad de los dispositivos para funcionar en el arranquey Bios, de lo contrario el valor para el campo bInterfaceSubClass es de 0. Hoy en dıa lamayorıa de los teclados USB tienen soporte para BIOS, pero no es ası para los dispositivoscomo mouse y joystick.

73


bInterfaceSubClass Descripcion0 sin subclase1 boot interface2-255 reservado

Cuadro 4.2: Codigos de Subclases.

4.4.3. Protocolos

El valor del campo (bInterfaceProtocol) pueden llevar tres valores y es mostrado enel cuadro 4.3. Los valores definen finalmente si el dispositivo es un mouse o teclado. Esimportante resaltar que USB-IF no define valores de protocolos para otros productos po-pulares como es el joystick. La razon de ello radica en que cada fabricante de productosHID, en donde no tienen un comportamiento standard (como el joystick), definen a travesde una tabla llamada Report las caracterısticas del dispositivo como por ejemplo: numerosde botones, movimientos, fuerzas ejercidas, etc. No es el caso de los teclados y mouses queposeen un funcionamiento con un numero de botones fijos.

bInterfaceProtocol Descripcion0 especıfico1 teclado2 mouse3-255 reservado

Cuadro 4.3: Codigos de protocolos.

En resumen, para la identificacion de un dispositivo HID se debe consultar por la fun-cion Get DescriptorInterf() que llama a la peticion solicitando los los descriptores del tipoInterface. Cuando se solicita la funcion Bus Enumeracion() se cargaran automaticamentetodos los descriptores y no sera necesario ejecutar la funcion Get DescriptorInterf(). Laestructura donde se guardan los datos de la Interface es Interface Descriptor.1

4.5. Descriptores de clase

Como se muestra en la figura 4.2, en los dispositivos de clase HID se encuentran losdescriptores Standard y descriptores del tipo String discutido ampliamente en el capıtulo3. Tambien se encuentran los descriptores de clase HID que son unicamente de esta clase.Los descriptores de clase son: HID Descriptor, Report Descriptor y Physical Descriptor, loscuales estan dentro del descriptor Interface.

Si bien es importante saber el detalle y funcionamiento de cada descriptor de la claseHID, la informacion que entrega cada uno de los descriptores de clase, no influye en la

1Para mayor detalles se puede consultar en la presente memoria por el capıtulo 3, seccion de descriptores.

74


Figura 4.2: Descriptores de la clase HID.

configuracion general de un dispositivo de clase HID tales como teclados y mouse. Sin em-bargo, para dispositivos desconocidos para el host (dispositivo especial) y que forman partede esta clase (HID), la informacion entregada por los descriptores es de gran importanciapara el fruncimiento.

4.5.1. HID Descriptor

La estructura de HID Descriptor se muestra en el cuadro 4.4:

Campo Tamano Descripcion Ejemplo

bLength 1 tamano del descriptor en bytes 0x0B o 0x09

bDescriptorType 1 constante HID 0x21

bcdHID 2 especificacion de la clase 0x0110

bCountryCode 1 numero que especifica el paıs 0x00

bNumDescriptors 1 numero de descriptores de la clase 0x02

bDescriptorType2 1 codigo del primer descriptor 0x22

wItemLength2 2 largo del descriptor 0x0040

bDescriptorType3 1 codigo 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 o 11 campos, donde su codigode identificacion es 0x21 (bDescriptorType). HID Descriptor es la cabecera de los demas

75


descriptores de la clase, donde la funcion principal es informar la existencia o no de los otrosdos descriptores de la clase. Como se dijo en el capıtulo anterior, cuando se solicita unapeticion y no concuerda el largo exacto del descriptor que se esta solicitando, se produceun error de comando. Es por eso que el HID Descriptor junto con entregar la existencia ono de los descriptores, entrega ademas, el largo exacto de los otros dos descriptores, puescomo se vera mas adelante, los otros dos descriptores de la clase son estructuras no fijas yvarıan de un dispositivo a otro. El tercer descriptor (bDescriptorType3 ) puede tener el valorcero, indicando que no existe el descriptor. Los codigos para identificar los descriptores semuestra en el cuadro 4.5.

bDescriptorType Clase Descriptor0x21 HID0x22 Report0x23 Physical Descriptor0x24 Reservado

Cuadro 4.5: Descriptores especiales para la clase HID.

Para solicitar el HID Descriptor se construyo la funcion Get DescriptorHID() utilizan-do la funcion base Request() que permite enviar el Setup Packet.

Un resultado obtenido al ejecutar la funcion Get DescriptorHID() conectando un mousegenerico al puerto SL811HS se muestra en la figura 4.3:

Figura 4.3: HID Descriptor.

Se observa en la figura 4.3 que solo existe un descriptor adicional (0x22), el cual corres-ponde al descriptor llamado Report Descriptor. Por otro lado, el valor del campo bcdHIDindica la version de la clase USB del dispositivo. El valor corresponde justamente a la ulti-ma version que es HID 1.1.

76


4.5.2. Report Descriptor

Report Descriptor entrega una tabla que describe cada pieza del dispositivo que generadatos. Por ejemplo un Report Descriptor define items en un mouse como la posicion ybotones, a su vez determina cuanto esfuerzo hay que aplicar para que el dispositivo generelos datos mınimos y maximos. Debido a esto, la estructura del Report Descriptor es variabley lleva a realizar una funcion en donde la captura de los reportes sea en un arreglo temporal.

La funcion que solicita el Report Descriptor es la siguiente:

int Get_DescriptorReport(BYTE adress, char *ptr)

La peticion se realiza en forma directa a traves de la funcion Request(), pero previamentese solicita el HID Descriptor de manera de asegurar que los campos del HID Descriptor secarguen y ası funcione correctamente el Report Descriptor.

La figura 4.4 muestra los datos obtenidos de un mouse generico. La interpretacionse debe realizar leyendo cada 1, 2 o 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 esindicar que el dispositivo es de un formato conocido (generico). Para el segundo par (0902)su significado es indicar que el dispositivo generico es un mouse. La interpretacion de cadavalor es bastante extensa, pero para los dispositivos conocidos mayormente no influye. Paralos valores de los reportes se puede consultar los documentos oficiales “Device Class Defi-nition for Human Interface Devices (HID 1.1)” y “HID Usage Tables 1.12”, descargablesde la pagina www.usb.org. En los documentos se pueden encontrar tablas genericas paralos dispositivos mas usados de la clase HID.

Figura 4.4: Tabla de reportes.

77


Los reportes resultan algo engorroso de utilizar para los que realizan dispositivos es-pecıficos de la clase HID. Sin embargo, se disponen de herramientas que facilitan la cons-truccion de las tablas de reportes. Una herramienta muy utilizada es HID descriptor Tool,donde de una manera mas facil se van agregando botones, movimientos, rangos, etc., y deesta manera se va llenando automaticamente la tabla de reportes. La figura 4.5 muestra laherramienta nombrada anteriormente, en donde se configura la tabla de reportes para unmouse.

Figura 4.5: Software HID Descriptor Tool.

4.5.3. Physical Descriptor

Es un descriptor opcional el cual provee informacion sobre que parte del cuerpo humanoes usado para activar los controles. Al igual que en el caso anterior se pueden consultar porlas tablas entregadas por USB-IF en los mismos documentos, pero su implementacion noes vital para el funcionamiento de dispositivos standard o desconocidos. La funcion paraacceder al Physical Descriptor se muestra a continuacion:

int Get_DescriptorPhysical(unsigned int adress, char *ptr)

En los diferentes dispositivos de clase HID que se conectaron al controlador SL811HS, nose encontraron registro alguno del Physical Descriptor. Saber que parte del cuerpo humano

78


es la que controla al dispositivo, no influye en el funcionamiento general del dispositivo.

4.6. Recibimientos de los datos en un dispositivo HID

Los datos entregados por los dispositivos HID, como al apretar un boton o una tecla,son enviados a traves de los endpoint que especifica el fabricante del dispositivo. General-mente los dispositivos HID traen un solo endpoint del tipo Interrupt. La cantidad maximade datos que pueden enviar los dispositivos low-speed es de 8 bytes. Los teclados ocupan los8 bytes para transmitir los datos al host, en cambio el mouse solo ocupa 4 bytes. Por otraparte, es deber del host preguntar por las interrupciones generadas por los dispositivos, enel 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 usuarioproduzca una nueva interrupcion.

La funcion RecibirInt() permite preguntar si hay datos que el dispositivo desea en-viar (interrupcion 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 recepcion de 8 bytes (lınea 5 del codigo). La funcion RecibirInt()tiene 3 parametros de entradas: adress indica la direccion del dispositivo, endpointhidcorresponde al endpoint que va a trasmitir los datos y ptr el puntero que indicara la di-reccion de memoria para guardar los datos. Si no hay datos en el endpoint, la funcionRecibirInt() retorna el valor 0, por el contrario en caso de recibir datos la funcion retornael valor 1. El codigo de la funcion RecibirInt() se muestra a continuacion:

int RecibirInt(BYTE adress, char endpointhid, char *ptr) 1

BuffClear811(0x10,8); //borra basura del buffer2

wr811(FNADDR,adress); //direccion del dispositivo3

wr811(BUFADR,0x10) ; // inicio de los datos de llegada.4

wr811(BUFLEN,0x08) ; //en low mode, los paquetes son de 8 bytes5

wr811(PID_EP,IN_PID endpointhid); // paquetes tipo IN6

result=go(0x03); // enviar comando, DIREC=0(in), ENAB=1, ARM=17

if (result & 0x01) // ACK si se reciben datos8

9

BuffRead811(0x10, ptr, 8); // copia los datos llegados.10

return 1; //retorna indicado datos positivo11

12

else13

return 0; //no hay datos14

15

En el main() principal del programa, mostrado a continuacion de este parrafo, se mues-tra una rutina para configurar y preguntar por las interrupciones de los dispositivos declase HID. Desde la lınea 1 a 12 del codigo, es la parte en donde se inicializa el controladory se asigna una direccion al dispositivo USB (direccion numero 5). Las lıneas 14, 15 y 16rescatan en variables mas didacticas, los valores esenciales para el funcionamiento del dis-positivo, que corresponden a la clase, protocolo y endpoint del dispositivo. A continuacion,se verifica que la clase obtenida pertenece a clase HID (valor 0x03) y luego se ejecuta la

79


funcion RecibirInt(). En caso de haber datos, la rutina despliega un mensaje en la pantallaLCD, dependiendo si que el dispositivo que realizo la interrupcion fue un mouse o un tecla-do.

int main(void)1

2

char temp[8]; //temporal para recibir los datos, debe ser 8.3

BYTE clase, protocol, endInter, direccion;4

5

Init_Osc_X2();6

Init_LCD();7

Delayx100us(5000);8

USB_init();9


direccion=0x05; // direccion a asignar al dispositivo.11

Bus_Enumeracion(direccion); //bus enumeracion12

13

clase =Interface_Descriptor[0].bInterfaceClass ;14

protocol =Interface_Descriptor[0].bInterfaceProtocol;15

endInter =Endpoint_Descriptor[0].bEndpointAddress ;16

17

if (clase==0x03) //si es de clase HID.18

19

while(1)20

21

if ( RecibirInt(direccion,endInter,temp) ) //si hay datos 1.22

23

if(protocol==1) // si es teclado.24

printf("teclado interrupcion"); //funcion del usuario25

if(protocol==2) //si es mouse.26

printf("mouse interrupcion"); //funcion del usuario27

28

29

30

31

4.7. Configuracion 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 unicopara cada boton, tal como se muestra en el cuadro 4.6. Para los casos en que se presionanbotones al mismo tiempo, el valor generado para el byte0 es la respectiva suma de losvalores de cada boton que se presiono. Por ejemplo al presionar al mismo tiempo el botonizquierdo (0x01) con el boton derecho (0x02), el valor para el byte0 es de 0x03.

Cuando se realiza un click en un boton, este genera dos interrupciones: la primera esproducida cuando el boton se presiona y es mantenido en la posicion, entregando el valorcorrespondiente al boton; la segunda interrupcion es producida al momento de soltar elboton, generando el valor 0x00 para el byte0.

80


Boton (Byte 0) Izquierdo Derecho MedioValor 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 byte1es para el eje-x, el byte2 para el eje-y y el byte3 representa al movimiento del roller quees utilizado para avanzar y retroceder paginas. Para diferenciar movimientos positivos ynegativos se divide cada byte en dos partes iguales (cuadro 4.7).

Movimiento x+ x - y+ y- roller+ roller-Byte 1 1 2 2 3 3Valor 1 a 127 255 a 129 255 a 129 1 a 127 1 a 127 255 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, porejemplo movimientos muy lentos en el eje x+ significaran valores entre 1 a 10 en el byte1,de igual manera movimientos muy lentos en el eje x- significaran valores desde 255 a 240.Sin embargo, el movimiento del mouse puede pasar por todos los valores, ya que la accioncompleta para acceder a un objeto en la pantalla, pasa desde un movimiento inicial del tipobrusco, finalizando en un movimiento lento. Caso especial es el movimiento del roller, endonde en su mayorıa son movimientos del tipo lento, principalmente porque se requierenque los movimientos sean de esa manera y ademas porque el desplazamiento se realiza atraves de los dedos.

Se puede emular el movimiento del eje-x de un mouse utilizando una pantalla LCD de4 lıneas. Para ello se realizo una sencilla funcion llamada MouseX():

Codigo:

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


En la rutina MouseX(), primero se fija los rangos en el cual se aceptan movimientos vali-dos para x- y x+, descartando valores pequenos y valores grandes. Cada vez que se entre enel rango establecido se activa el cursor y el parpadeo (Cursor On+Blink On) de manera devisualizar el movimiento en la pantalla. Luego se procede a realizar el corrimiento del cursorsegun sea el caso (Right o Left). Un movimiento simple y corto del mouse puede provocardecenas de interrupciones dependiendo del tiempo que destine el host para preguntar porlas interrupciones, pero por lo general puede provocar que el cursor se pierda en la pantallaLCD y no se logre seguir el cursor con la vista, principalmente porque la pantalla tiene 30caracteres por lınea, que equivaldrıan a 30 movimiento de cursor por lınea. El problemaanterior se soluciono introduciendo retardos de manera de perder algunas interrupcionespor tiempo y ası demorar el movimiento en la pantalla.

En el main() principal del programa, se debe pasar el valor que representa al movimien-to en el eje-x (byte1 o temp[1]) a la funcion mouseX(). El siguiente codigo ilustra la funcioncompleta.

int main(void)1

2

char temp[8]; //temporal para recibir los datos, debe ser 8.3

BYTE clase, protocol, endInter, direccion;4

5

Init_Osc_X2();6

Init_LCD();7

Delayx100us(5000);8

USB_init();9


direccion=0x05; // direccion a asignar al dispositivo.11

Bus_Enumeracion(direccion); //bus enumeracion12

13

clase =Interface_Descriptor[0].bInterfaceClass ;14

protocol =Interface_Descriptor[0].bInterfaceProtocol;15

endInter =Endpoint_Descriptor[0].bEndpointAddress ;16

17

if (clase==0x03) //si es de clase HID.18

19

while(1)20

21

if ( RecibirInt(direccion,endInter,temp) ) //si hay datos 1.22

23

if(protocol==1) // si es teclado.24

printf("teclado interrupcion");25

if(protocol==2) //si es un mouse.26

MouseX(temp[1]); //temp[1]=eje x.27

28

29

30

31

82

Capıtulo 5

Dispositivos de almacenamientomasivo

Este capıtulo describe la clase Mass Store Device, donde el principal objetivo de anali-sis son los dispositivos llamados pendrives. Ademas, se estudia y desarrolla el protocolo decomandos Bulk-Only que permite encapsular los comandos SCSI para ası realizar la lecturay escritura de archivos. Tambien se explica el sistema de estructura FAT16 que distribuyelas particiones y los archivos en memoria.

5.1. Mass Store Device

La clase Mass Store Device (MSD) corresponde a los dispositivos que tienen la capaci-dad de almacenar y transportar datos. Los dispositivos tıpicos que se pueden encontraren esta clase son: diskette, discos duros, CD-ROM, DVD y pendrives. Sin embargo, el dis-positivo que mas comunmente es usado por el usuario es el pendrive. En un principio lospendrives solo fueron disenados para que cumplieran la funcion de almacenar y transportardatos, teniendo la gran ventaja con respecto a los diskette: la velocidad y capacidad de al-macenamiento. Actualmente el mercado ofrece pendrives con incorporacion de radio, mp3,telefono y video, lo que ha hecho que la utilizacion de los pendrives reemplace en granmedida a los diskettes. Hoy en dıa, los nuevos computadores que salen al mercado estansuprimiendo el uso de las disketeras1, incorporando ranuras para conectar directamentememorias flash y pendrives.

Un pendrive basico, tal como se muestra en la figura 5.1, internamente se componede: varios chip de memoria flash, un controlador de memoria y un interfaz USB. Con estostres componentes los dispositivos emulan el comportamiento de un disco magnetico. Porsu parte, la memoria de datos de los pendrives se asocia a sectores de 512 bytes (bloques),leyendo y escribiendo datos unicamente de esta manera.

1Las nuevas placas madres, soportan que los pendrives tengan la capacidad de ser booteable o cargar unsistema operativo.

83

CAPITULO 5. DISPOSITIVOS DE ALMACENAMIENTO MASIVO

Figura 5.1: Estructura interna de los pendrives.

5.2. Reconocimiento de un dispositivo MSD

Los dispositivos de la clase MSD se identifican al igual que otros dispositivos USB, estoes a traves de los campos bInterfaceClass, bInterfaceSubClass y bInterfaceProtocol. Los trescampos mencionados pertenecen al Interface Descriptor1.

5.2.1. Clase

El campo bInterfaceClass devuelve el valor 0x08, lo cual aclara que el dispositivo es dela clase Mass Store Device.

5.2.2. Subclase

Codigo Juego de comandos Comentarios01h Reduced Block Commands (RBC).

T10 Project 1240-Dnormalmente utilizado por memorias Flashaunque cualquier dispositivo de almace-namiento masivo puede utilizarlo

02h SFF-8020i, MMC-2 normalmente utilizado por CD y DVD03h QIC-157 normalmente utilizado por unidades de cinta04h UFI normalmente usado por unidades de diskette05h SFF-8070i normalmente utilizado por disquete, aunque

tambien puede utilizar otra subclase (comoRBC)

06h SCSI-2 cualquier dispositivo de almacenamiento ma-sivo puede utilizar esta subclase

07h-FFh reservados para uso futuro

Cuadro 5.1: Codigo de subclase para Mass Store Device.

El campo bInterfaceSubClass entrega distintos valores para los dispositivos de la claseMSD (cuadro 5.1). Los distintos valores sirven para identificar el tipo de juego de coman-dos que soporta la interfaz. El cuadro 5.1 muestra los codigos y utilizacion para el campo

1Para mayor informacion sobre los descriptores, dirigirse al capıtulo 3.

84


subclase.

Los pendrives utilizan los juegos de comandos SCSI-2 que corresponde al valor 06hdel campo bInterfaceSubClass. Actualmente USB-IF esta intentando unificar todos los dis-positivos con los comandos UFI (Floppy Disk Unit), publicado en el documento oficial“Universal Serial Bus Mass Storage Class - UFI Command Specification1”. El documentosirve para consultar por los comandos SCSI-2 ya que UFI tienen como base a los comandosSCSI-2 y SFF-8070i.

5.2.3. Protocolo

El campo bInterfaceProtocol devuelve un valor para indicar la manera como se trans-porta el juego de comandos. Esto se refiere a como se emplean las transferencias en elprotocolo USB (Control, Bulk, Interrupt, Isochronous). Los valores son mostrados en lacuadro 5.2.

Codigo Protocolo de Transporte de comandos00h CBI con interrupcion de fin de comando01h CBI sin interrupcion de fin de comando50h Bulk-Only02-4Fh reservado51h-FFh reservado

Cuadro 5.2: Codigo de protocolo para Mass Store Device.

El protocolo de transporte de comandos CBI (Control, Bulk, Interrupt) fue el que enun principio se utilizo en los pendrives con capacidad de memoria no superior a 64MB.CBI utiliza tres endpoint para las transferencias de los comandos y datos, produciendoineficiencias en los dispositivos de gran tamano y capaces de soportar high-speed. El usode CBI para cualquier diseno de pendrives fue descartado y puesto por USB-IF en calidadde obsoleto. Hoy en dıa se utiliza el protocolo de transporte Bulk-Only que es mas simplepara la comunicacion, pues solo 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 tamano, velocidad y modelo de fabrica.Los datos fueron obtenidos por medio de la funcion Bus Enumeracion()2 conectando losdispositivos al puerto USB del SL811HS. Como se observa en el cuadro 5.3 los valores delos campos no varıan de un modelo a otro. Ademas se observa que la cantidad de endpointde cada dispositivo es 2, ya que necesita un endpoint para datos de entrada y un endpointpara datos de salida.

1El documento se encuentra en el CD-ROM adjunto al trabajo, “Documentos/usborg/usbmass-ufi10.pdf”o en www.usb.org.

2La funcion Bus Enumeracion() carga todos los descriptores en sus respectivas estructuras, tal como losenala el capıtulo 3 de la presente memoria.

85


Campos Creative1GB

PackerBell256MB

Kingston256MB

I-storage128MB

numeros deinterfaces

0x00 0x00 0x00 0x00

alternativassentencias

0x00 0x00 0x00 0x00

numeros deendpoint

0x02 0x02 0x02 0x02

clase 0x08 0x08 0x08 0x08subclase 0x06 0x06 0x06 0x06protocolo 0x50 0x50 0x50 0x50interface 0x00 0x00 0x00 0x00

Cuadro 5.3: Interface Descriptor para distintos pendrives.

5.3. Peticiones de clase

El protocolo de transporte Bulk-Only define dos peticiones especıficas que deben sopor-tar los dispositivos de la clase MSD, estas son: Bulk-Only Mass Storage Reset y Get MaxLUN.

5.3.1. Bulk-Only Mass Storage Reset

El objetivo de la peticion es aplicar un reset al dispositivo MSD. Ası el dispositivo seprepara para recibir el juego de comandos que tiene especificado (SCSI-2 para los pen-drives). La peticion no retorna ningun dato.

La funcion para acceder a esta peticion es la siguiente:

MassStorageReset(BYTE adress, BYTE interface)

El parametro adress indica la direccion del dispositivo y el parametro interface co-rresponde al valor que entrega el campo bNumInterfaces (interface que se escogio para eldispositivo).

5.3.2. Get Max LUN

La peticion especial Get Max LUN se usa para determinar el numero de unidades logicassoportadas por el dispositivo. Es posible que un dispositivo pueda tener varias unidadeslogicas. Las unidades logicas del dispositivo son enumeradas contiguamente a partir de LUN0 hasta LUN 15 (Fh). Como se vera posteriormente, el host usa el comando encapsulado

86


bCBWLUN (Command Block Wrapper) para elegir a que unidad logica sera enviado elpaquete. Por lo general los pendrives solo tienen una unidad logica disponible.

Solicitando la peticion Get Max LUN el dispositivo devolvera un byte de datos con elmaximo LUN (unidades logicas) soportado. Por ejemplo, si el dispositivo soporta cuatroLUNs entonces el valor de retorno serıa 3. Si ningun LUN es asociado con el dispositivo,entonces el valor retornado sera 0 (1 particion). En caso que se envıe un paquete a unaunidad logica que no exista, el dispositivo respondera con un STALL.

La funcion construida para acceder a la peticion Get Max LUN es la siguiente:

GetMaxLUN(BYTE adress, BYTE interface)

5.4. Protocolo de transporte Bulk-Only

El protocolo Bulk-Only1 es el encargado de transportar los datos y estados de un dis-positivo de almacenamiento masivo cualquiera. Esto se hace exclusivamente a traves de lastransferencias tipo Bulk.

5.4.1. Transferencias

La figura 5.2 muestra el flujo de las transferencias de datos en el protocolo Bulk-Only.Las transferencias se realizan a traves de tres bloques: Command, Data y Status Protocol. Elprimer bloque es llamado CBW (Command Block Wrapper), corresponde a un bloque decomando que indica la inicializacion de la transferencia, especificando el tipo de operaciona 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 bloqueData corresponde a los datos reales de la transferencia. La transferencia termina con elbloque CSW (Command Status Wrapper) que contiene la informacion del estado de latransferencia. CSW tiene un estructura similar a CBW y ambos estan encapsulado en unpaquete tipo DATA, sin embargo la estructura especial y fija de los paquetes CBW y CSWpermiten 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 solamentesirven para realizar una lectura o escritura en la memoria de los dispositivos, sino tam-bien, se utilizan para realizar distintas operaciones extras con los dispositivos. En generalse puede decir que el uso de los comandos es para realizar la lectura, escritura y pedirinformacion al dispositivo.

1El documento que especifica USB-IF para el transporte Bulk-Only, se denomina Bulk-Only Transport1.0, el cual se puede encontrar en el CD adjunto a la memoria, con el nombre “usbmassbulk 10.pdf”.

87


Figura 5.2: Flujo de datos.

Por otra parte, el protocolo Bulk-Only no permite el encolado de comandos, por lo que elcontrolador USB no envıa ningun nuevo CBW hasta no haber recibido el CSW correspon-diente al ultimo comando enviado. Tampoco se permiten transferencias bi-direccionales,por lo cual, todas las transferencias de datos entre el CBW y el CSW seran en la mismadireccion, es decir todas en su momento OUT o IN.

5.4.2. Bloque CBW

La estructura del CBW comienza exactamente al principio de un paquete de datos ytiene 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 previamenteen el buffer (31 bytes) del SL811HS de tal manera que el comando que se desea enviarsea el correcto para establecer la comunicacion con el dispositivo. Cualquier tipo de erroren el llenado de los campos lleva a que la comunicacion no se establezca con los dispositivos.

Para la construccion de las funciones basicas con los dispositivos de almacenamiento ma-sivo, es de vital importancia saber el detalle de los campos del bloque CBW. A continuacionse detalla cada campo del bloque CBW.

CBWSignature: Se trata de una firma de 4 bytes. El contenido de la firma son loscaracteres ASCII 0x43-0x42-0x53-0x55 que significa USBC (USB Command, en formatolittle-endian). De esta manera el dispositivo identifica que el paquete que esta recibiendoes el comando encapsulado CBW, para luego en un segundo paso verificar que el largo delpaquete sea de longitud de 31 bytes.

CBWTag: Se trata de un numero asignado por el host. El dispositivo devuelve este mismonumero en el paquete CSW para identificar claramente a que CBW pertenece el CSW.Debido a que solo hay un puerto en el SL811HS, se procedio a utilizar los valores: 0x71-0x72-0x73-0x74h.

88


Figura 5.3: Command Block Wrapper.

CBWDataTransferLength: Aquı se indica el numero de datos en bytes que el contro-lador espera que se transfieran durante la fase de datos. Si este campo se rellena con uncero, 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-Outdesde controlador a dispositivo o Data-In desde dispositivo a controlador). Un valor de0x00 indica que la transferencia es desde el dispositivo al host. Para el sentido contrario elvalor del campo es de 0x80.

CBWLUN: Aquı se indica a que unidad logica va dirigido el comando. Tıpicamente elvalor es de 0x00, pues los dispositivos como pendrives suelen tener una sola unidad logicadisponible.

CBWCBLength: Aquı se indica la longitud (en bytes) del juego de comandos. En estecaso corresponderıa a los comandos SCSI-2 (campo CBWCB). Los valores pueden variarde comando a comando, por ejemplo para un comando de lectura corresponderıa el valorde 0x0A bytes.

CBWCB: En este campo se situa el comando que debe ejecutar el dispositivo. El juego decomandos soportado es indicado por el valor del campo de la subclase (Interface Descrip-tor). CBWCB tiene una longitud de 16 bytes, aunque el juego de comandos utilizado puedeusar una menor longitud. La longitud del bloque viene especificada en el campo anterior yel dispositivo ignora los bytes sobrantes.

5.4.3. Bloque CSW

La estructura del bloque CSW tiene un largo de 13 bytes (figura 5.4).

89


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 Sta-tus, en formato little-endian). El controlador USB identifica que el paquete es un CSW poresta firma y porque el paquete tiene una longitud de 13 bytes.

CSWTag: El dispositivo devuelve en este campo el mismo valor del campo CBWTag delCBW correspondiente.

CSWDataResidue: Para transferencias de datos, el dispositivo indica aquı la diferenciaentre 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 sise ha producido algun error. El host puede confirmar la causa concreta mediante los me-canismos proporcionados por el juego de comandos que se este utilizando. Por ejemplo, sise esta utilizando SCSI o ATAPI, tras un error en la ejecucion de un comando el contro-lador puede enviar el comando Request Sense para que el dispositivo envıe el tipo de errorconcreto.

5.5. Bloques de comandos SCSI-2

En general los comandos SCSI1 o SCSI Block Command (SBC) son una serie de ins-trucciones estandarizadas que permiten la interaccion con los dispositivos que manejandatos. Los comandos SCSI-2 (SBC-2) son comandos reducidos, que estan unicamente orien-tados a realizar acciones en los discos rıgidos, en este caso aplicables a los pendrives. Sinembargo, existen otros comandos SCSI muy parecidos en funciones entre sı, pero orientados

1Small Computer Systems Interface.

90


a otros dispositivos como son los comandos SBC-3 para CD-ROM y lectores de DVD. Loscomandos SCSI se encuentran regulados por el comite INCITS (International Committeefor Information Technology Standards) que dispone de los documentos oficiales en la paginaweb www.t10.org.

Los bloques de comandos SCSI tienen una serie de campos que varıan de comando a co-mando, donde deben ser llenados de acuerdo a las especificaciones. Cada comando empiezacon un numero llamado codigo de identificacion, el cual permite diferenciar los comandosentre sı. Tambien, cada comando SCSI tiene establecido una serie de campos que retornanal host.

Codigo Comando0x00 Test Unit Ready0x03 Request Sense0x12 Inquiry0x1A Mode Sense0x1E Prevent Allow Media Removal0x25 Read Capacity0x28 Read(10)0x2A Write(10)0x2F Verify0x5A 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 estan implementados por los fabricantes de pendrives. Esto se debeporque algunos comandos SCSI son reemplazables por las peticiones propias del protocoloUSB. Otro motivo del no soporte a todos los comandos SBC-2, es porque algunos se puedenobtener por otros comandos SCSI. Es el caso del comando Read Capacity que entrega lacapacidad total de memoria del pendrive, sin embargo la informacion tambien se encuentradisponible en la particion logica de la unidad, que entrega una informacion mas precisacon respecto al que entrega el comando Read Capacity, accesible por medio de el comandoRead(10) que permite la lectura de sectores de bloques de memoria.

De todas las pruebas realizadas en diferentes pendrives, se pudo constatar que todos losdispositivos soportan al menos tres comandos basicos que permiten la lectura y escriturade datos, estos son: Inquiry, Read(10) y Write(10). Estos tres comandos fueron construidossegun las especificaciones, llenado los 31 bytes del bloque de comando CBW que envıa lapeticion de comando SCSI.

5.5.1. Inquiry

El comando Inquiry entrega informacion mas precisa sobre el dispositivo, como porejemplo: fabrica del producto, nombre del producto, version del producto, etc. Inquiry es

91


muy parecido a las peticiones USB del tipo String, la diferencia radica en que este comandose envıa tıpicamente despues de aplicar un reset al dispositivo, de manera de comprobarque el dispositivo soporta los comandos SCSI y ası indicar al dispositivo que esta listopara recibir otros comandos SCSI. Para acceder al llenado y envıo del comando Inquiry sepuede consultar en el Apendice E. Tambien se incluyen el resto de los comandos construidos.

A continuacion se muestra la funcion construida para ejecutar el comando SCSI Inquiry.

INQUIRY(char *ptr)

Figura 5.5: Resultado del comando Inquiry.

El siguiente codigo muestra la forma de realizar el comando Inquiry.

int main(void)

.

.

.

char temp[36]

Bus_Enumeracion(0x02); //bus enumeracion en 0x02

Buscar_EndpointBulk(); //busca y ordena los endpoint tipo bulk en los descriptores

NUM_DISP=0x02; //var. general, fija la direccion 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 version del dispositivo, demostrando de esta manera que esta listo para seguirrecibiendo comandos SCSI. Sin duda, este comando es muy parecido a las peticiones deltipo string.

92


5.5.2. 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 cantidadde bloques que se leen puede ir variando dependiendo de las necesidades del programador.Lo ideal y optimo para la lectura de datos es leer por cluster1. Sin embargo, al usar un mi-crocontrolador se reduce la posibilidad de leer en forma optima los dispositivos con mayormemoria y que a su vez tengan un cluster de mayor tamano. La memoria RAM que poseeel 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 realizara el microcontrolador, la lectura no debesobrepasar mas alla de los 2048 bytes, es decir 4 bloques consecutivos de memoria.

La siguiente funcion 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 parametro veces indica lacantidad de bloques de sectores de memoria (512 bytes). El resultado de la lectura empiezaen el puntero ptr.

En el siguiente ejemplo ilustra como leer el sector de memoria 0x40 y 0x41 utilizandolas propiedades.

int main(void)

.

.

.

char temp[1024];

Leer_Sector(0x000040, 2, temp);

En el ejemplo anterior tambien es posible leer los dos sectores de memoria por se-parado, pero usando las propiedades de la funcion SCSI se pueden reducir notablementelos tiempos de acceso a memoria en los pendrives. Sin duda, la funcion de lectura es laclave del posterior proceso de busqueda y escritura de archivos. Pero en si, la lectura desectores no tiene mucho sentido sino se tiene claro que representa cada sector de memo-ria. En secciones mas adelante se discutira la organizacion de la memoria en los dispositivos.

1Un cluster es una agrupacion de sectores de 512 bytes que dependen de cada dispositivo.

93


5.5.3. Write(10)

La funcion SCSI Write(10) permite escribir en un sector de memoria de los dispositi-vos. Esta funcion tiene las mismas caracterısticas y consideraciones que la funcion anteriorRead(10). Sin embargo, la construccion interna es bastante diferente, pues los llenados delos bloques de comandos CBW son distintos y la comunicacion entre el host y el dispositivoes del tipo DATA-OUT.

La siguiente funcion 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 memoria0x40 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 afectarel funcionamiento de los dispositivos. Por ejemplo escribir datos incorrectos en el sector0x00 puede causar que el dispositivo no sea reconocido en los S.O, o escribir en un sectorque no este libre puede causar que se danen los archivos y posteriormente no puedan serrecuperados.

Con la ayuda de la funcion de escritura se creo una nueva funcion capaz de escribira partir desde una posicion del sector (1-512). La funcion es EscrSectorPosic(), donde seutilizo para rellenar sectores cuando se desea escribir al final de un archivo.

5.6. Organizacion De La Memoria Fısica

Actualmente los pendrives tienen una capacidad de almacenamiento desde 16MB a 2GB,lo cual es relativamente pequeno comparado con los actuales discos duros que superan los500GB. La estructura de memoria para discos con capacidades menores a 2GB correspondea 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 causaralgunos problemas o danos como: reduccion del tamano original, perdida de la Master Boot

94


Record o simplemente la perdida del firmware en los Mp3 Player. Sin duda, con el aumen-to gradual de las capacidades de memorias de los pendrives, estos tendran que funcionarnormalmente en otros formatos, lo que esta en plena discusion por USB-IF.

5.6.1. FAT16

La figura 5.6 muestra la estructura para FAT16. En los primeros 512 bytes de memoriase encuentra el sector llamado Master Boot Record (MBR). A continuacion se encuentrancuatro posibles unidades logicas (logical disk). Cada unidad logica contiene: una PartitionBoot Record (PBR), dos FAT identicas (FAT1 y FAT2) y una tabla de directorios raız.En el caso del protocolo USB, el acceso es solo a traves de sectores de 512 bytes y no pormedio de CHS (Cylinder, Head, Sector).

Figura 5.6: Organizacion de la memoria.

Ademas de agrupar la memoria por sectores de 512 bytes, tambien se agrupan sectoresconsecutivos los cuales se llaman cluster. Estos dependen del tamano de la memoria decada dispositivo. El cuadro 5.5 se muestran los cluster por la capacidad de cada dispositivo,en donde mas grande la memoria implicara mas sectores por cluster. El total de cluster quedebe haber en FAT16 es de 65535 cluster (0xFFFF) por area de datos.

Tamano 32MB 64MB 128MB 256MB 512MB 1GBnumero de cluster 1 2 4 8 16 32

Cuadro 5.5: Cluster por tamano.

95


5.6.2. Master Boot Record - MBR

El sector Master Boot Record (primer sector de memoria) lleva el control de las diversasparticiones (unidades logicas) que existen en el dispositivo, entregando detalles importantescomo el sector donde comienza dicha particion.

Posicion Descripcion Largo000h Codigo ejecutable (booteable) 446 bytes1BEh 1o Particion 16 bytes1CEh 2o Particion 16 bytes1DEh 3o Particion 16 bytes1EEh 4o Particion 16 bytes1FEh 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 posicion0x1BE de la MBR entrega la informacion necesaria para determinar donde se inicia laprimera particion del disco. Toda esta informacion parcial sobre la primera particion seencuentra en 16 bytes (el detalle de los 16 bytes se encuentra en el Apendice 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


que los primeros 446 bytes de codigo ejecutable (color verde) no se encuentra en el dispo-sitivo, sin embargo en otros modelos se pudo constatar la presencia del codigo ejecutable.Luego en la figura, se muestran las cuatro unidades logicas disponibles con un largo de16 bytes de informacion. Se puede observar que solo la primera particion esta activa. Porultimo la MBR finaliza con los valores fijos 55h AAh (firma).

No siempre se puede encontrar la MBR en el primer sector. Cuando ocurre esto, elprimer sector de memoria pasa a ser la PBR (Partition Boot Record) de la primera unidadlogica. Esto sucede cuando los dispositivos cuentan con una sola particion (muy comun) yse formatean bajo Windows, pero en caso contrario, la MBR debera estar presente paraindicar las distintas particiones.

5.6.3. Particiones

Cada particion tiene 6 secciones definidas (figura 5.8). Toda particion comienza con laPartition Boot Record (PBR) de un un tamano fijo de 512 bytes. Seguido se encuentran detamano variable: los sectores reservados, dos tablas FAT, tabla de directorios y termina conel area de datos. Toda la informacion respecto del tamano y direcciones de las seccionesnombradas anteriormente la proporciona la PBR, que ademas entrega la cantidad de sec-tores por cluster que tiene la particion1.

Figura 5.8: Estructura de las particiones.

1EL detalle referente a toda la PBR se puede consultar en el Apendice F.

97


La figura 5.9 muestra la PBR de un pendrive conectado al SL811HS.

Figura 5.9: Ejemplo de la Partition Boot Record.

5.6.4. Funcion para encontrar particiones

Se construyo una funcion que buscara y calculara los datos utiles para la posteriorbusqueda de archivos (direcciones de cada seccion de la estructura de la particion). Tam-bien que diferenciara entre la MBR y la PBR ya que ambas pueden aparecer en el sector0x00 con un tamano de 512 bytes. El codigo interno de la funcion se basa en lo que ante-riormente se discutio sobre las particiones, en conjunto con los detalles que se encuentranen el Apendice F sobre las particiones.

La funcion construida es la siguiente:

buscaparticion(BYTE adress)

La figura 5.10 muestra los resultados obtenidos al utilizar la funcion buscaparticion()al mismo pendrive del ejemplo de la figura 5.9.

98


Figura 5.10: Valores obtenidos al ejecutar la funcion buscaparticion().

Como se puede observar de la figura 5.10, los valores obtenidos y calculados se guardanen la siguiente estructura:

struct Particion_struct

//MBR

DWORD Start; //inicio de la particion.

//PBR

WORD BytesPorSec; //bytes por sector.

BYTE SecPorCluster; //sectores por cluster.

WORD BytesporCluster; //bytes por cluster.

WORD ReservedSectors; //sectores reservados.

WORD MaxRootDir; //maximo root directorio.

WORD SecPorFAT; //sectores por FAT.

//datos calculados a partir de los datos obtenidos

DWORD RootDir; //directorio raız.

DWORD DataArea; //area de datos.

DWORD FAT1; //tabla FAT1.

DWORD FAT2; //tabla FAT2.

//datos utiles

DWORD TamanoCluster; //tama~no del cluster en bytes.

DWORD NumberSecPart; //numeros de sectores en la particion.

DWORD NumberSecData; //numeros de sectores de datos.

DWORD EspTotalBytes; //espacio total del dispositivo.

Particion;

99


5.6.5. Distribucion de los archivos en memoria

Como se menciono en este capıtulo, grupos de sectores de 512 bytes se agrupan en clus-ter1. La numeracion de los cluster sucede a partir del area de datos de la particion, para locual, se establece que el area de datos comienza exactamente en el cluster 0x02.

Figura 5.11: Ejemplo de la distribucion de un archivo en memoria.

Cuando se busca un archivo, uno de los datos que se obtienen de aquella busqueda esel cluster que da el comienzo al archivo, llamado cluster de inicio. El cluster de inicio serelaciona directamente con los datos obtenidos de la particion para establecer la direccionprecisa del sector que se debe leer. Ademas, la utilizacion de cluster produce que un archivosiempre ocupe como mınimo la cantidad de 1 cluster de memoria, excepto por los archivosde tamano cero que no tienen un cluster asignado. Por otra parte, los archivos superioresa un cluster se ubican en varios cluster (dependiendo del tamano del archivo), donde nonecesariamente pueden ser consecutivos. De esta manera, la distribucion total del archivoes repartida a lo largo de la memoria del dispositivo. En la figura 5.11 se muestra unejemplo grafico de un archivo repartido a traves de dos cluster.

Como se observa en la figura 5.11, la informacion sobre la continuidad del archivo esproporcionado por la tabla FAT2, indicando a traves de un numero de 2 bytes el proximocluster a leer . El archivo solo termina cuando la tabla FAT entrega el valor 0xFFFF. Sinembargo, la tabla FAT entrega otros valores, como indicar si un cluster esta vacio o danado.

1Mirar el cuadro 5.5.2FAT1 y FAT2 son tablas identicas.

100


Los valores que se pueden obtener de la tabla FAT y su interpretacion se muestran en elcuadro 5.7.

Valor Descripcion0x0000 cluster vacio0x0002-0xFFEF usado, proximo cluster0xFFF0 - 0xFFF6 cluster reservado0xFFF7 cluster danado0xFFF8-0xFFFF usado, ultimo cluster en el archivo

Cuadro 5.7: Codigos para el cluster.

5.7. Archivos y directorios

La asignacion de nombre para los archivos y directorios establece dos tipos de formatos:8.3 y LFN. El primer formato (8.3) se utilizo en el sistema operativo DOS para asignarcomo maximo 8 caracteres para el nombre y 3 caracteres para la extension, normalmenteconocido como nombres cortos. El formato 8.3 tiene la ventaja que por cada nombre que seguarde solo ocupara el espacio de 32 bytes, pero con la desventaja que recorta los nombresque se salgan del formato 8.3. Por su parte, el formato Long File Name, por problemasde compatibilidad conserva el formato 8.3, y ademas agrega espacio para los nombres quecontengan mas caracteres de lo que permite el formato 8.3, incluyendo casos como los ca-racteres especiales que no soporta 8.3. El formato LFN se empezo a utilizar a partir deWindows95, en donde se establece una asignacion de espacio multiplo de 32 bytes1.

Cada formato tiene sus propias caracterısticas de como se distribuye los caracteres a lolargo del espacio que tienen asignado para el nombre. Ademas cada archivo o directorio traeconsigo la informacion necesaria para la ubicacion posterior de los datos. La informacionque tiene cada archivo o directorio es en general: nombre, extension, atributos (archivo, di-rectorio, oculto, sistema), fecha de creacion, ultimo dıa de acceso, primer cluster de accesoy tamano del archivo. Hay que rescatar que el significado del primer cluster de acceso paraun archivo, es indicar en que sector de memoria hay que leer el archivo (primeros bytes delarchivo), sin embargo, para un directorio el significado es indicar en que sector de memoriaestan los nombres de archivos y sub-directorios que pertenecen a ese directorio. Para mayordetalle, en el Apendice F se encuentra la distribucion de los caracteres para el formato 8.3 yLFN en conjunto con toda la informacion que se puede obtener de los archivos y directorios.

En la figura 5.12 muestra cuatro ejemplos de diferentes nombres de archivos obtenido dela 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 elnombre va en mayuscula (no se conserva el nombre original) y ademas, el punto que divideel nombre de la extension es considerado como un caracter de espacio (0x20). En segundo

1El mınimo de espacio que ocupa el formato LFN es de 32 bytes para archivos y directorios cortos.

101


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. Seobserva del caso 2 que se ocupan 32 bytes para la asignacion del nombre corto y se agregan64 bytes para el nombre largo. Cada nombre largo tiene detalles como por ejemplo: la ca-dena siempre empieza con el valor 0x01; la continuacion de cada nombre es hacia atras; lainformacion correspondiente al archivo se guarda donde esta el nombre corto; el punto dedivision entre el nombre y la extension es considerando como un caracter de punto (0x2e);los espacios vacıos se rellena con 0xff, etc. El tercer caso 3 corresponde al archivo “todasmis fotografias1 del paseo.rar”, en donde corresponde al formato LFN y ocupa un total 128bytes. En el caso 4 (ultimo ejemplo) corresponde al archivo borrado “notas.doc”. Se puedeobservar que la primera letra del nombre se reemplazo por el valor 0xe5, de esta manera seindica que el archivo ya no existe. En general, como se vieron en los ejemplos, la busquedade un nombre no resulta ser una accion sencilla, ya que por la gran cantidad de detalles nose soluciona con una simple comparacion de cadenas.

5.7.1. Desarrollo de una funcion base de busqueda

Se desarrollo una funcion que sirviera de base para la posterior busqueda de nombresde archivos. La funcion permite buscar nombre entre un rango de sectores que determineel programador. La funcion se muestra a continuacion:

busqueda_archivo(char *name , char atr, DWORD sect_inic, DWORD sect_final)

1El archivo original no lleva acento.

102


La funcion permite la busqueda de un nombre name, entre las direccion inicial sect inicy la direccion final sect final, diferenciando con el parametro atr para establecer si se tratade un archivo o directorio (‘D’=directorio y ‘A’=archivo). La funcion retorna el valor 1 sila busqueda es exitosa o el valor 0 en caso contrario. Ademas, permite buscar nombres yasea de cualquier formato (8.3 y LFN), ya que la funcion reconoce y transforma los nom-bres segun sea el caso. Internamente la funcion se ayuda de otras funciones creadas quefacilitan la busqueda, como son: la reubicacion de los caracteres, comparaciones de atribu-tos, comparacion de cadenas, descartar nombres borrados, informacion de cluster, etc. Unavez encontrado el archivo, la funcion guarda en una estructura los datos necesarios parala posterior lectura y escritura del archivo. Los datos mas necesarios que se obtienen alencontrar un archivo son: tamano del archivo y direccion de inicio del sector de datos. A suvez, cuando se encuentra un archivo se guarda la informacion del sector y posicion exactaen donde esta ubicado el nombre del archivo, para que posteriormente se pueda modificarlos bytes que indica el tamano del archivo.

5.7.2. Busqueda de archivos y directorios en la raız

Los archivos y directorios que se encuentran en la raız, son todos aquellos que no estandentro de un directorio. Para encontrar estos archivos se procedio a realizar una funcion quebuscara en todo el sector designado para la tabla de directorios. Es decir, desde el inicio dela tabla de directorios, hasta un sector antes del area de datos1. Este espacio de busqueda,es siempre un rango limitado2 y conocido (dependiendo de la memoria fısica de cada dispo-sitivo), lo cual origina que cuando el espacio para la tabla de directorios se llena, no se puedaguardar un nuevo archivo en la raız, sin embargo se puede seguir escribiendo en los archivos.

Finalmente para la busqueda de nombres en la raız se desarrollo la funcion root(), paralo cual se fijaron los parametros de busqueda de la funcion base busqueda archivo(). Elcodigo de construccion se muestra a continuacion:

int root(char *name, char atr)1

2

int res;3

4

res=busqueda_archivo(name,atr,Particion.RootDir,Particion.DataArea-1);5

6

SEND_CMD(Display_Clear);7

if (res==1)8

printf("Arch o Dir encontrado");9

else10

11

printf("Arch o Dir No encontrado");12

borrartemp();13

14

return res;15

16

1Mirar la figura 5.8, sector Root Directory.2La tabla de directorios pueden ser varios cluster de memoria.

103


La funcion root() retorna un valor y un mensaje dependiendo del resultado de la busque-da.

5.7.3. Busqueda de archivos y directorios en directorios

Los archivos y directorios que se encuentran dentro de otro directorio (no-root), se di-ferencian de los archivos que se encuentran en la raız, en tener un espacio limitado solo porla memoria disponible que tenga en el disco (pendrive). Esto se debe porque los nombresde archivos y carpetas se guardan como datos de archivos, utilizando para ello el metododel seguimiento por cluster (FAT).

La funcion que se construyo para la busqueda en directorio es la funcion noroot(), cuyocodigo se muestra a continuacion:

int noroot(char *name, char atr)1

2

int res;3

DWORD ultimo_sectorleido, proximo, final;4

5

SEND_CMD(Display_Clear);6

proximo=Directemp.DireccArchiv; //fija el limite inicial7

final=proximo+Particion.SecPorCluster; //fija el limite final del cluster8

9

if(Directemp.DireccArchiv==0) //verifica si hay un directorio anterior buscado10

11

printf("error, no existe directorio anterior");12

return 0;13

14

15

//se realiza la busqueda hasta que se encuentre el archivo,16

//o hasta que se terminen los cluster de datos.17

18

do19

20

res=busqueda_archivo(name,atr,proximo,final);21

ultimo_sectorleido=proximo;22

proximo=infocluster(proximo);23

final=proximo+Particion.SecPorCluster;24

25

while((res==0) && (ultimo_sectorleido != Directemp.UltimoSector));26

27

if (res==1) //respuesta positiva28

printf("Arch o Dir encontrado");29

else //respuesta negativa30

31

borrartemp();32

printf("Arch o Dir No encontrado");33

34

35

return res;36

37

104


Inicialmente la funcion busca en todo el cluster inicial de datos, que es entregado porla funcion anterior root(). Si la busqueda es negativa, consulta si hay mas cluster por leery se fijan los nuevos lımites de busqueda. La busqueda se realiza hasta que se encuentre elarchivo o hasta que la informacion del cluster diga que no hay mas saltos de memoria (nohay mas 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 direccion en posicion 0.


root("strupr.c",’A’); //archivo "strupr.c"

save(1); //graba direccion en posicion 1.

En la primera parte del ejemplo, se busca un archivo en la ruta “archivos/textosgenerales/teclado.txt”, el resultado se guarda en la posicion 0 . Para el segundo caso sebusca en la raız el archivo “strupr.c” y se guarda en la posicion 1. La funcion save(), quese muestra en el codigo, se diseno para permitir operar con varios archivos: se guarda enuna posicion del 0 al 9 todos los datos respecto del ultimo archivo buscado, de maneraque posteriormente se pueda elegir la lectura y escritura de 10 archivos distintos. Por otrolado, cuando un nombre no se encuentra o no existe, la busqueda (noroot()) y el grabadode datos (save()) no se realizan. Esto porque las distintas funciones verifican si existe unresultado anterior positivo. Ademas, en cada caso se muestra a traves de la pantalla LCDel resultado de la operacion.

El resultado final de la funcion save() queda en la estructura Archiv Open. La figura5.13 muestra el resultado de los dos archivos encontrados en el ejemplo anterior.

Se puede observar en la figura 5.13 que los tamanos de los dos archivos son 4096 y 709bytes respectivamente (TamArchiv). El valor del tamano del archivo es el unico dato quepuede llegar a ser util para el usuario, como por ejemplo mostrarlo el tamano en pantalla.Ademas, es util para abrir el final de un archivo y posteriormente escribir a continuacion.El resto de los datos que se guardan con la funcion save() y que se muestran en la figura(direccion de inicio del archivo, ultimo cluster, index, etc) son para que posteriormente lasfunciones de lectura y escritura de archivos se guıen para cumplir con la tarea. En un futurose podrıa integrar estas tres funciones (root(), noroot() y save()) de manera de realizar unabusqueda general tipo D.O.S, MATLAB, Linux, etc.

105


Figura 5.13: Estructura de la funcion save().

5.8. Lectura de archivos

Se construyo una unica funcion capaz de realizar una lectura de archivos, de tal mane-ra que satisficieran las mayorıas de las necesidades de lectura de archivos. La funcion delectura es:

readfile(DWORD numr ,DWORD ini, WORD cuant, char *ptr)

La funcion permite leer un archivo de los que ya se han guardado con la funcion save().Para ello se le ingresa en el parametro numr para indicar el numero del archivo que se desealeer. Tambien se le ingresan los parametros ini y cuant, que permite decirle a la funcion enque byte del archivo empezar a leer y que cantidad de bytes leer respectivamente. Los datosse guardaran en la direccion de memoria ptr. La funcion retorna los bytes que se leyeron,pues se le pueden indicar leer una cantidad que sobrepase el tamano del archivo. En casoque no se pueda leer el archivo, la funcion retorna el valor 0.

La funcion tiene varias restricciones, una de ellas es que no se pueden leer mas de 2048bytes de cualquier parte del archivo, pues por problema de memoria en el microcontro-lador, puede afectar a la escritura de datos o a otras funciones paralelas que se quieranrealizar con el. De esta manera la funcion retorna el valor 0 cuando se ingresan parametros

106


de lectura mas grande que 2048 bytes (cuant). Otra restriccion que se realizo fue que elvalor ini solo sea valido desde el valor 1, pues el valor indica el primer byte del archivo.Tambien, la funcion retorna el valor 0 cuando se pone un valor ini mas grande de lo quees el tamano del archivo, de manera de proteger el desarrollo de la funcion. Por ultimo,cuando se pone un valor en el parametro cuant (cantidad de bytes que se desean leer) quecomprometa leer mas alla del tamano real del archivo, pero el valor inicial de lectura ini esvalido, internamente la funcion ajusta el valor de manera que solo se leen los ultimos bytesdel archivo.

Por ejemplo leer los primeros 100 bytes de un archivo guardado en la posicion 0.:

int main(void)

.

.

.

char temp[100];


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 mas de 2048 bytes (3000) y destinarlo a un mismo arreglo.

int main(void)

.

.

.

char temp[3000];

readfile(3,1,2000,temp); //lee desde 1-2000, el archivo 3.

readfile(3,2001,1000,&temp[2000]); //lee desde 2001-3000, el archivo 3.

Para leer los ultimos 512 bytes de un archivo 9.

int main(void)

.

.

.

char temp[512];

readfile(9,Archiv_Open[9].TamArchiv-512,512,temp);

5.8.1. 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 funcion,

107


se procedio a obtener los datos necesarios del ultimo cluster en donde esta la parte finaldel archivo. Con las anteriores funciones desarrolladas se procede a completar los bytesque faltan del ultimo sector, para ası continuar con rellenos por sectores completos segunsea la cantidad de informacion que se desea guardar. En caso que se terminen los bytesdisponibles que posee el ultimo cluster, la funcion de escritura se apoya en otras funcionespara la busqueda de un cluster vacıo, de manera que se siga realizando la escritura dedatos faltantes. En caso de exito (busqueda correcta de un cluster vacıo) la funcion deescritura procede a realizar los respectivos cambios en la FAT, para darle continuidad alarchivo (FAT1 y FAT2). Una vez que se tiene un cluster vacıo, la funcion de escritura siguerellenado los sectores al igual que en la primera parte. Una forma grafica de lo explicadoanteriormente 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 esta distribuido la ultima parte del archivo. Eltamano del archivo del ejemplo es de 2862 bytes, los primeros 2048 bytes estan distribuidoen un cluster en que no es importante para el relleno de los datos, sin embargo, si es impor-ta saber todo lo referente al ultimo cluster, en donde estan los ultimos 824 bytes del archivo.

Tambien se considero para el diseno de la funcion de escritura, el caso de los archivoscon tamano cero, pues estos archivos no tienen un cluster asignado. Para ello, previamentese le asigna un cluster en la FAT. Finalmente cualquier que sea el caso, la funcion de es-critura termina su rutina modificando el nuevo tamano del archivo en donde se encontro,ademas, se actualizan los valores que se guardan en la estructura de la funcion save().De esta forma, en la proxima escritura de datos todos los archivos parten con los nuevoscambios que guiaran correctamente la escritura, como la lectura del archivo.

Las funciones de escritura son las siguientes:

108


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 parametro numero indica el archivo que se desea escribir.

Al igual que en la lectura de archivo, estas tres funciones estan basadas en una funcionbase de escritura, de manera que son pequenas variaciones para utilizarlas en diferentescasos. La primera funcion writefile array() corresponde practicamente a la funcion base deescritura pues permite escribir en un archivo un arreglo del tamano que desea el usuario.La segunda funcion writefile var() permite escribir al final de un archivo una variable detamano long. Para ello se procede a transformar la variable a caracteres. La tercera funcionwritefile string() permite escribir un string cualquiera.

Entre los multiples ejemplos que se realizaron para verificar el correcto funcionamientode las funciones, fue realizar una lectura por segmentos iguales de datos (excepto por elultimo segmento) de un archivo, realizando al mismo tiempo una copia de esos segmentosa otro archivo con tamano inicial de 0 bytes. De esta manera, se realiza una copia identicadel archivo original. Tambien se realizo la lectura de MBR, PBR y FAT, para luego pasarla informacion a un archivo de texto. Por ultimo se realizo una copia de datos de un archivoa otro, con la comprobacion de datos escritos en el mismo dispositivo. Todos los ejemplosse pueden consultar en el CD-ROM adjunto a la memoria, cual trae las respectivas aclara-ciones para cada ejemplo.

109

Capıtulo 6

Conclusiones

El desarrollo del driver que permite la escritura y lectura de archivos en dispositivosde almacenamiento masivo USB se concreto exitosamente. Sin embargo se abordaron otrostopicos de gran importancia del protocolo USB como son: peticiones, descriptores y dispo-sitivos de interfaz humana (HID). Estos temas, en conjunto con el tema principal tratado,permitiran al futuro programador trabajar desde un solida base tanto con el controladorUSB SL811HS, como para otros tipos de controladores en donde se requieran realizar nuevosdrivers.

Con respecto al controlador USB en el cual se trabajo, se generaron sencillas funcionespara el usuario como son: cargar de forma automatica los descriptores del dispositivo, detec-tar la velocidad de trabajo, configurar y visualizar si el dispositivo esta enumerado, recibirdatos desde dispositivos HID (mouse, teclado y joystick) y manipular en forma sencillaarchivos de datos. Con esto, sin entrar en gran profundidad en el protocolo USB o en elcontrolador, el usuario solo se encargara de manipular los datos que provienen desde eldispositivo.

Al hacer multiples pruebas con dispositivos de almacenamiento masivo, se observo quela velocidad de transferencia de los archivos que se manipularon, fue notoriamente masbaja de lo que el protocolo USB 1.1 puede brindar. Esto se debe a que la mayorıa de lasfunciones que se crearon, fueron disenadas para asegurar el correcto funcionamiento en dis-positivos de cualquier tamano de memoria. Ademas, la poca memoria RAM que dispone elmicrocontrolador con respecto a la memoria fısica de los dispositivos, implico realizar lasfunciones no de forma mas optima.

A pesar que una norma asegura que un dispositivo USB 2.0 debe por lo menos ser re-conocido en los controladores USB 1.1, la norma no asegura el completo funcionamiento deellos. Esto se pudo comprobar en los distintos dispositivos en que se realizaron pruebas, y severifico que no todos los dispositivos USB 2.0 funcionan adecuadamente en un controlador1.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 laclase HID y MSD tienen un sin fin de posibilidades, el cual solo dependera de la imaginacionde quien ocupe estos recursos.

110

Apendice A

Detalles del protocolo USB

En este apendice se encuentra el detalle del protocolo USB. Algunos de los paquetes quese nombran en este apendice se pueden manejar directamente en los registros de controldel SL811HS.

A.1. Paquetes que se encuentran en las transacciones

Nombre Tamano Tipos de paque-tes

Proposito

SYNC 8 bits todos inicio de la tramas y sincronizacionPID 8 bits todos identifica el tipo de paqueteAdress 7 bits IN, OUT, Setup identifica la direccion del dispositivo (funciones)ENDP 4 bits IN, OUT, Setup identifica el numero del endpointFrameNumber

11 bits SOF identifica el numero del frame

Data 0-1023bytes

Data0, Data1 datos

CRC 5 o 16bits

IN, OUT, Setup,Data0, Data1

detectar errores

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 relojlocal, de esta manera SYNC solo sirve como un mecanismo de sincronizacion en el cualtodos los paquetes lo contienen (Token, Data, Handshake). La estructura del campo SYNCpara low y full-speed corresponde a una secuencia de 8 bits con el string “KJKJKJKK” encodificacion NRZI. Los ultimos dos bits del campo SYNC (“KK”) es un rotulador que seusa para identificar el fin del campo SYNC, para dar el comienzo al campo PID. Sin em-bargo, para la transmision 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

APENDICE A. DETALLES DEL PROTOCOLO USB

desde el principio del patron SYNC, pero no pueden agregar sımbolos al campo SYNC. Deesa manera, despues de ser repetido por 5 hubs el campo original SYNC de 32 sımbolos,puede llegar a quedar a 12 bits (KJKJKJKJKJKK). Este metodo de eliminacion es paradetectar cuando se conecten mas 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 cualeslos primeros cuatro son empleados para indicar el codigo del formato del paquete (cuadroA.2) y los cuatro ultimos llamado IPID son los mismos 4 primeros bits del paquete pero enforma negada, utilizado como un mecanismo de deteccion de errores.

Cuadro A.2: Bits del paquete PID.

A.1.3. Address

El campo ADDR especifica la direccion del dispositivo de manera que el host puedaestablecer la comunicacion. Esto se realiza a traves de 7 bits como lo muestra el cuadroA.3. Con la cantidad 7 bits se puede establecer como maximo 127 direcciones para laenumeracion de los dispositivos, siendo la direccion 0 una direccion reservada para la con-figuracion 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 vaestablecer la pipe de comunicacion. Los dispositivos low-speed dan un soporte como maxi-mo 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


Para los dispositivos full-speed y high-speed se establece un maximo de 16 endpoint.

A.1.5. CRC

La Verificacion de Redundancia Cıclica (CRC) se usa para proteger a todos los paque-tes excepto los paquetes PID. En el caso de la fase Token el CRC5 es aplicado sobre lospaquetes ADDR y ENDP. Para la fase Data, el CRC16 es aplicado solamente para el campoDATA. El motivo de no agregar el paquete PID para la verificacion de errores, es porquelos paquetes tipo PID trae su propio mecanismo de verificacion, al repetir nuevamente losbits pero en forma negada.

A.2. Estados en la lınea de transmision

Gracias al transmisor diferencial, receptor diferencial y las resistencias en los termi-nales, posibilitan transmitir y detectar varios estados electricos en la lınea. Esto es de granimportancia mencionar pues los controladores USB incluyendo el SL811H manejan estosestados en sus registros de configuracion. Los estados electricos son:

A.2.1. Diferencial0 y Diferencial1

Estos estados estan definidos por las senales D+ y D-. Diferencial1 existe cuando lasenal D+ esta en nivel logico bajo y la senal D- esta en el nivel logico alto. De la formacontraria se define Diferencial0.

A.2.2. Single-Ended Zero

El estado Single-Ended-Zero (SE0) ocurre cuando las senales D+ y D- tienen un nivellogico 0. El bus usa el estado Single-Ended-Zero para detectar la conexion y desconexionde dispositivos, para indicar el EOP (fin de paquete) y para generar reset.

A.2.3. J y K

USB tambien define dos datos de estados J y K. Estos estan definidos por los estadosdiferencial0 y diferencial1 dependiendo si se esta conectado de la forma low-speed o full-speed (cuadro A.5). Las definiciones de los estados de datos J y K posibilita el uso de unaterminologıa para describir eventos o estados logicos cuando los voltajes de las lıneas low yfull-speed difieren. Por ejemplo, el estado SOF (start of frame) existe cuando el bus cambiade un estado Idle a un estado K. En full-speed, el estado ocurre cuando D- es mas positivoque D+, mientras que en low-speed, el estado ocurre cuando D+ queda mas positivo que D-.

113


Estado Low-Speed Full-SpeedDiferencial0 J KDiferencial1 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 semi-duplex, detectar la conexion y desconexion de dispositivos y discriminar entre dispositivosFS y LS.

A.3. Special Packet para el protocolo USB 2.0

En el grupo de paquetes especiales USB 1.1 define solo un tipo de paquete llamadoPRE para indicarle a todos los hubs que un paquete de baja velocidad sera transmitido.Los hubs toman estos paquetes y los repiten a todos los dispositivos que esten habilitados,sean estos de alta o baja velocidad. El paquete subsiguiente que sea transmitido hacia losdispositivos sea una fase Handshake, Data o Token, sera transmitido en baja velocidad.

En cambio USB 2.0 define tres nuevos tipos de paquetes1 especiales:

ERR: Se usa para indicar errores en transacciones Split high-speed. Solo lo puedetransmitir un hub 2.0 (en modo high-speed) en el campo de handshake de unatransaccion Split.

SPLIT: Lo transmite el host en el campo de Token con el motivo de que los hubs eje-cuten toda la transferencia en high-speed y solo en la parte final de la transaccion seejecute a la velocidad correspondiente al dispositivo (low-speed o full-speed). En USB1.1, si se realiza una transaccion a velocidad low-speed, la transaccion comenzarıa des-de el primer hub a esa velocidad trayendo como consecuencia el desaprovechamientodel ancho de banda.

PING: Es transmitido por el host en el campo de Token de una transaccion para elcontrol de flujo. Esto lo envıa el host para preguntar si el dispositivo esta disponiblesin 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 puedeatender al host. Si todavıa no esta disponible responde con un NAK al Token PINGhecho por el host.

1Estos tipos de paquetes no son soportados por el host controlador SL811HS.

114


A.4. Resumen de los paquetes en las transacciones

La figura A.1se muestra el resumen de la estructuras de todos los paquetes, incluyendoel protocolo USB 2.0.

Figura A.1: Resumen de la estructura de los paquetes del protocolo USB.

115


A.5. Resumen de las transferencias USB

La figura A.2 detalla todas las transferencias del protocolo USB 1.1 y USB 2.0, in-cluyendo todos los paquetes que se ven involucrados en cada caso.

Figura A.2: Resumen de las transferencias del protocolo USB.

116

Apendice B

Diagrama de conexiones

La figura B.1 muestra el diagrama de conexiones que se realizo para desarrollar la pre-sente memoria. La conexion corresponde al microcontrolador MSP430F1612, el controladorUSB SL811HS (modulo uUSB-HS) y un display LCD de 4 lıneas.

Figura B.1: SL811HS USB Host/Slave Controlador, Pin Layout.

117

Apendice C

Registros del controlador SL811HSen modo Host

En este apendice se detallan los registros de control que posee el controlador SL811HS.Los registros pertenecen al modo de operacion en host. A su vez, se muestran diversosejemplos en los registros de mayor interes y uso.

Los registros del SL811HS en modo host estan resumidos en el cuadro C.1.

Registro Definicion DireccionUSB-A Control CTL 0x00USB-A Address BUFADR 0x01USB-A Length BUFLEN 0x02USB-A PID/EP PID EP 0x03USB-A Status PKTSTAT 0x03USB-A Address FNADDR 0x04Ctrl1 CTL1 0x05Interrupt Enable IE 0x06Interrupt Status INTSTATUS 0x0DSOF Low SOFCT L 0x0EHW Revision HWR 0x0ESOF 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, sonexplicadas a continuacion:

Registro 0x00, USB-A Control: Se usa para proveer el control basico de las tran-sacciones realizada por el host. Por ejemplo: habilita las transacciones USB, fija la direccion

118

APENDICE 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 funcion0 Arm “1” permite realizar la transferencia, luego vuelve automaticamente a

“0”1 Enable “1” permite habilitar al endpoint, cuando es puesto en “0” la transaccion

es ignorada. Si Enable=1 y Arm=0 el endpoint retornara un NAK2 Direccion “1” transmite el host. “0” el host recibe3 Reservado4 ISO “1” permite transferencias isocronas para el endpoint5 SOF “1” sincroniza la transferencia con el SOF6 Data Toggle “0” es DATA0, “1” es DATA17 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 funcion go(BYTE cmd) que tiene comoparametro cmd, correspondiente a un valor de configuracion del registro 0x00 (cuadroC.2). La funcion go() sirve para enviar o recibir transferencias, en donde ademas, se utilizaotro registro dentro de la funcion go() para retornar el resultado de la operacion (ACK,NAK, STALL). Esta funcion solo debe utilizarse al final de un proceso de configuracion,puesto que para establecer una transferencia final, se deben fijar otros registros como di-reccion, tamano del buffer, endpoint etc.

Considerando que no existe un hub de por medio, ademas, con la posibilidad de errorutilizando la sincronizacion por SOF (Errata), los tıpicos valores se reducen a go(0x03) ygo(0x07).

Ejemplos:

//Recibir datos de un endpoint (DATA0)

go(0x03); // DIREC=0(in), ENAB=1, ARM=1

//Enviar datos a un endpoint (DATA0)

go(0x07); // DIREC=1(out), ENAB=1, ARM=1

Se debe resaltar que es importante saber si el tipo de transaccion es IN, OUT conDATA0, DATA1 o DATA toggle. En el caso de la transferencia de dispositivos de almace-namiento masivo, los endpoint son del tipo Bulk, para lo cual el envıo y recibimiento delos datos es del tipo DATA toggle. De esta manera, siempre se debe estar alternando deDATA0 a DATA1, de lo contrario se produce un error de transferencia. Los endpoint tipoInterrupted y Control funcionan con DATA0.

Registro 0x01, Host Base Address: Cuando se reciben datos, este registro debeconfigurarse para indicar en que parte de la memoria del SL811HS se van a recibir. En caso

119


de enviar datos, el registro indica donde comienzan los datos que se van a enviar. En amboscasos el valor de este registro debe ser siempre un valor valido 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 sehace de manera de aprovechar el total del espacio que se encuentra disponible en el bufferdel SL811HS. Sin embargo, es necesario que el registro este fijado antes de rellenar el buffercon los datos que se van a enviar.

Registro 0x02, Base Length: Es usado para determinar el largo maximo de latransaccion. Cuando el SL811HS envıa datos hacia un periferico, este registro determi-na el largo del tamano del paquete. Cuando un dispositivo va a entregar datos al host, elregistro sirve para determinar el tamano maximo que aceptara. Es importante utilizar bieneste registro al momento de enviar datos, pues usar un tamano menor al indicado por elendpoint trae consecuencias que no se reconozcan los comandos de Control, o simplementeno realizar los comandos de bloques especiales para los dispositivos de almacenamientomasivos.

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 interrupcion, talescomo teclados y mouses, los datos transferidos hacia el host seran en cada transferenciaa lo mas 8 bytes. De la misma manera sucede para realizar una transferencia de Control,ya que el tamano del paquete siempre tiene el largo de 8 bytes. Por otra parte, cuando sehacen transferencias de Handshake, en el cual solo se recibe el resultado de la operacion, elvalor del registro debe ser de 0. De esta manera se asegura que no hay datos en la proximatransaccion, ademas se evitan errores cuando el registro tiene otro valor por antiguas ope-raciones de transferencias. Cuando se reciben transferencias tipo Bulk, los valores puedetener un valor hasta de 64 bytes (dependiendo de cada endpoint). Finalmente para el casode transferencias isocronas (ISO), el maximo paquete permitido por USB 1.1 es de 1023bytes, sin embargo, el SL811HS solo soporta un maximo de 240 bytes (buffer).

Registro 0x03, PID/Endpoint: Este registro tiene las siguientes funciones: indicarel resultado de la operacion, establecer que tipo de paquete se va enviar en la proximatransaccion y establecer a que endpoint se va establecer la comunicacion. Cuando se lee elregistro, este cumple con la funcion de entregar el resultado de la ultima transaccion. Elcuadro C.3 muestra los valores que puede tener el registro 0x03 cuando es leıdo.

120


Bit Nombre funcion0 ACK el dispositivo retorna un ACK1 Error error detectado en la comunicacion2 Time-out time-out ocurrido3 Sequence “0” es DATA0, “1” es DATA14 Setup cuando es “1” indica un Setup-Packet5 Overflow largo excedido durante el recibo de datos6 NAK el dispositivo retorna un NAK7 STALL el dispositivo retorna un STALL

Cuadro C.3: Registro 0x03, resultados de la ultima transaccion.

La lectura de este registro entra en juego en una gran parte de los codigos realizados.La funcion GO() al mandar un paquete retornara el resultado de la operacion a traves dela lectura del registro 0x03. Dependiendo tanto del valor entregado como el proposito delprograma, se pueden tomar decisiones de que hacer al respecto con el paquete. Si se estanenviando datos a un dispositivo y se recibe un NAK se debe intentar nuevamente enviar elpaquete hasta que el dispositivo este disponible o desocupado. En caso de recibir un STALLsimplemente se debe descartar el envio de paquetes y no insistir nuevamente, puesto quepuede significar que no acepta el comando o simplemente el endpoint no existe. Tambien esmuy util el bit de overflow para no aceptar mas datos, pues despues del overflow el registroindicara un error de comando.

Cuando se escribe en este registro, los primeros 4 bits (b0-b3) corresponden al numerodel endpoint con el cual se va establecer la comunicacion. Los bits restantes del registro(b4-b7) establecen el tipo de paquete PID de la proxima transaccion. Los valores para elcampo PID se muestra en la tabla C.4.

PID Tipo b7-b4SETUP 1101IN 1001OUT 0001SOF 0101PREAMBLE 1100NAK 1010STALL 1110DATA0 0011DATA1 1011

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


#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 elregistro se indica la direccion del dispositivo con el cual el host va establecer la comunicacion(el dispositivo debe existir en esa direccion), con un total de 127 posibles direcciones. A suvez, cuando es leıdo el registro, indicara los bytes sobrantes de la ultima transaccion. Si sevuelven a pedir datos teniendo bytes sobrantes distintos de 0, el dispositivo entregara unSTALL indicando que no reconoce el comando.

Ejemplos:

wr811(FNADDR,0x00); //comunicacion con un dispositivo no configurado.

wr811(FNADDR,0x01); //comunicacion con el dispositivo en direccion 1.

Registro 0x05, Control Register 1: El registro habilita la generacion automaticade SOF, reset del SL811HS, configuracion de la velocidad del bus (low-speed y full-speed)y la suspension del Sl811HS (cuadro C.5).

Bit Nombre Funcion0 SOF ena/dis “1” permite generacion automatica de SOF, “0” desactivado3 USB Engine Reset “1” para reset4 J-K state force mirar tabla C.65 USB Speed “0” para full-speed, “1” para low-speed6 Suspend “1” habilitado, “0” desactivado


El cuadro C.6 muestra el modo de operacion de las lıneas D+ y D-. En donde forzandolos estados J y K se pueden invertir el orden de los voltajes de la lıneas de transmision.

Bit4 Bit3 Funcion0 0 modo normal operacion0 1 fuerza USB Reset1 0 fuerza J-State1 1 fuerza K-State

Cuadro C.6: Estados de operacion de las lıneas D+ y D-.

Registro 0x06, Interrupt Enable: Este registro permite habilitar la senal de interrupcion(INTRQ) cuando ocurran ciertos eventos. Estos eventos incluye SOF, conexion y desconexion

122


de dispositivos y deteccion de resumen/suspencion. El cuadro C.7 muestra las habilita-ciones que se pueden realizar.

Bit Nombre Funcion0 USB-A interrupcion USB-A1 USB-B interrupcion USB-B2 reservado3 reservado4 SOF timer “1” = interrupcion por SOF (1ms)5 Insert/Remove interrupcion por insertar o remover dispositivos6 Device Detect/Resume interrupcion por detect/resume


Registro 0x0D, Interrupt Status: El registro permite leer el estado de las interrupcionprogramadas. Las interrupciones son borradas fijando en “1” el respectivo bit. El cuadroC.8 muestra los valores de cada bit.

Bit Nombre Funcion0 USB-A interrupcion dispositivo USB-A1 USB-B interrupcion dispositivo USB-B2 Reservado3 Reservado4 SOF timer interrupcion por SOF (1ms)5 Insert/Remove interrupcion por insert/remove6 Device Detect/Resume interrupcion por detect/resume7 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-, determinandode esta manera si el dispositivo es low-speed o full-speed.

Registro 0x0E, SOF Counter Low/Hardware Revision: El registro fija el valordel contador low que permite generar el SOF de 1 ms (escritura), basado en un reloj de12-MHz. Para low-speed y full-speed tienen un valor fijo de 0xE0. Por otra parte, el cuadroC.9 muestra los valores que el registro retorna cuando es leıdo. Los valores indican la re-version del hardware. La presente memoria se realizo con la revision 1.5.

Bit Nombre Funcion4-7 HW revision “00h”=SL11H, rev1.2 “01h”=SL811HS , rev 1.5 “02h”=SL811HS

Cuadro C.9: Registro 0x0E, hardware revision.

Registro 0x0F, SOF Counter High/Control2: Cuando se escribe en el registro

123


permite: fijar el contador high para generar el SOF de 1 ms, elegir el modo de operacion delSL811HS (master o slave) y cambiar la polaridad de las senales D+/D-. El cuadro C.10muestra las posibles configuraciones. Cuando se lee el registro, retorna un valor propor-cional al contador SOF para poder calcular el ancho de banda disponible.

Bit Nombre Funcion0-5 SOF HIGH Counter Register contador high para el SOF6 Data Polarity Swap “1” cambia la polaridad, “0” no cambia la polaridad7 Master/Slave selection “1” master, “0” slave

Cuadro C.10: Registro 0x0F.

Las configuraciones tıpicas para establecer la comunicacion con dispositivos low-speedy 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

Apendice D

Construccion de las peticiones

En este apendice se encuentra el detalle del paquete de Control para realizar las peti-ciones llamado Setup Packet. Tambien se detalla la construccion de la funcion Request()encargada de enviar el Setup Packet. De esta manera se podran construir nuevas peticionespara las diferentes clases.

D.1. Setup Packet

El Setup Packet se compone de 5 campos tal como se muestra en el cuadro D.1.

Posicion Nombre Bytes Descripcion0 bmRequestType 1 fija la direccion de la transferencia1 bRequest 1 valores de 0 a 12, segun se la peticion.2 wValue 2 varıa segun la peticion4 wIndex 2 varıa segun la peticion6 wLength 2 numero 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 direccion de la transfe-rencia, especificando que parte del dispositivo va dirigida la transferencia. En caso generalcuando se pregunta por descriptores del dispositivo esto significara que se desean recibirdatos (Device-to-Host) y para ello se fija el valor de bmRequestType en “0x80”. Por locontrario cuando una peticion es para fijar algun valor dentro del dispositivo, esto sig-nificara que la direccion de los datos es Host-to-Device, por lo que el valor debera de ser“0”. Los dos valores mencionados son estandar para las peticiones basicas (Standard Re-quest), sin embargo una clase especifica de dispositivo o algun fabricante pueden soportarotros valores. En el codigo realizado para el host se definieron los siguientes valores de usomuy comun:

125

APENDICE D. CONSTRUCCION DE LAS PETICIONES

#define DTH 0x80 //device to host

#define HTD 0x00 //host to device

bRequest: Este campo especifica una de las 11 peticiones standard que se pueden consul-tar, cada una de ellas realiza una funcion o tarea diferente y tienen un valor fijo solo parael 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 variacion de funciones de un protocoloa otro. Todas las posibles peticiones con sus respectivos valores se muestran en el cuadroD.2. Algunos de los valores estan reservados para futuros usos.

Nombre Valor Nombre Valorget status 0 set descriptor 7clear feature 1 get configuration 8reservado 2 set configuration 9set feature 3 get interface 10reservado 4 set interface 11set adress 5 synch frame 12get descriptor 6

Cuadro D.2: Peticiones Standard.

Las definiciones son las siguientes:

#define GET_STATUS 0x00

#define CLEAR_FEATURE 0x01

#define SET_FEATURE 0x03

#define SET_ADDRESS 0x05

#define GET_DESCRIPTOR 0x06

#define SET_DESCRIPTOR 0x07

#define GET_CONFIG 0x08

#define SET_CONFIG 0x09

#define GET_INTERFACE 0x0a

#define SET_INTERFACE 0x0b

#define SYNCH_FRAME 0x0c

Es importante no confundir por ejemplo SET ADRESS con set adress(), lo primerodefine la peticion dentro del Setup Packet y lo segundo es la peticion que realiza la rutinapara la cual fue disenada.

wValue: Este campo varıa segun la peticion que se este realizando, cada peticion tienesu propio valor para wValue, pero algunos pueden definir un valor cero. La peticion parasolicitar los descriptores generales del los dispositivos (get descriptor) utilizan valores de-pendiendo sobre que cosa del dispositivo se desea solicitar, por ejemplo endpoint, configura-ciones, interfaces etc. Los valores que se puede utilizar para las peticiones estan estipuladosen el cuadro D.3.

126


Descriptor Tipo (wValue) Valordevice 1configuration 2string 3interface 4endpoint 5

Cuadro D.3: Tipos de descriptores.

Los tipos de descriptores van el byte mas significativo del campo wValue. Las defini-ciones para el codigo se muestran a continuacion:

#define DEVICE 0x0100

#define CONFIGURATION 0x0200

#define STRING 0x0300

#define INTERFACE 0x0400

#define ENDPOINT 0x0500

Para USB 2.0 se definen nuevos descriptores que son: DEVICE QUALIFIER, OTH-ER SPEED CONFIGURATION, INTERFACE POWER, pero que no son soportados porcontroladores USB 1.1.

wIndex: Este valor de 2 bytes varıa segun la peticion. Su uso no esta definido para unasola cosa. Por ejemplo en algunas peticiones sirve para definir el numero del endpoint odefinir que interfaz se desea comunicar el host. Es un parametro especıfico.

wLength: Este campo solo tiene una funcion: indicar el largo del paquete de la transferen-cia en una segunda etapa. Esto es porque el host controlador, en este caso el SL811HS, es elque define a traves de sus registros de configuracion cuanto es el largo de los paquetes quese van a transmitir o recibir, en este caso controla el largo del Setup Packet, pero como seesta realizando una peticion al dispositivo este entrega una serie de datos en una segundaetapa que no pueden ser controlados directamente por el host, sino mas bien, es el campowLength quien determina el largo de los datos. El dispositivo nunca entregara mas datosde los que se indica en este valor o bien, si se define un valor cero para este campo nuncaretornarıa algun valor.

D.2. Funcion Request()

Para el controlador SL811HS las peticiones se realizan a traves de la funcion construidaRequest(). El codigo de la funcion junto con los comentarios de la construccion se muestraa continuacion:

127


int Request(BYTE bmRequestType,1

BYTE bRequest,2

WORD wValue,3

WORD wIndex,4

WORD wLength,5

BYTE adress,6

char *ptr7

)8

9

int i, menor; int overflow;10

11

12

wr811(BUFADR,0x10); //Comienza el buffer en la direccion 0x1013

wr811(BUFLEN,8); //Reserva 8 bytes para el setup packet14

wr811(FNADDR,adress); //datos de control todos en la direccion15

16

//setup packet17

wr811(0x10, bmRequestType) ; // bmRequestType18

wr811(0x11, bRequest) ; // bRequest19

wr811(0x12, (wValue & 0x00FF)); // wValueL20

wr811(0x13,((wValue & 0xFF00)>>8)); // wValueH21

wr811(0x14, (wIndex & 0x00FF)); // wIndexL22

wr811(0x15,((wIndex & 0xFF00)>>8) ); // wIndexH23

wr811(0x16, (wLength & 0x00FF)); // wLengthL24

wr811(0x17,((wLength & 0xFF00)>>8) ); // wLengthH25

26

//envio del Setup Packet27

result = 0; while(!(result & 0x01)) //ACK=0x01.28

29

wr811(PID_EP,SETUP_PID); //Configura un PID tipo s.Packet, endpoint030

result=go(0x07); // Envıa el S.Packet DIREC=1(out), ENAB=1, ARM=1(0x07)31

32

33

34

//reconfigura el tama~no del endpoint IN y del largo del buffer.35

if (buffer_bMaxPacketSize0<=wLength)36

menor=buffer_bMaxPacketSize0;37

else menor=wLength;38

wr811(BUFLEN,buffer_bMaxPacketSize0); //asigna al buffer el tama~no mınimo del paquete.39

40

41

/*recibir datos de control en la pipe, si no hay datos por recibir42

se debe recibir un Handshake como IN*/ wr811(PID_EP,IN_PID); //43

PID tipo IN en endpoint044

45

do 46

result = 0;47

while(!(result & 0x01) && !(result==BIT6)) //ACK o STALL sale.48

// Si hay NAK vuelve a pedir datos.49

waitframes(4);50

result=go(0x03);51

52

53

if ((result==BIT6) | wLength==0) //si hay STALL o no hay datos que recibir sale.54

55

overflow=0;56

128


return 0; //retorna 0 en caso de error.57

58

59

else60

overflow=rd811(4);61

for(i=0;i<menor;i++)62

*ptr++=rd811(0x10+i); // se copian los datos a la ram63

64

//end do65

66

while (overflow ==0); //repite todo, hasta el overflow.67

68

return 1; //retorna 1 en caso de exito 69

La funcion Request() retorna el valor “1” en el caso de exito, de lo contrario retorna elvalor “0”. Se debe tambien mencionar que la funcion soporta al mismo tiempo las transfe-rencias de datos del tipo Control-No-Data y Control-Read. Para el primer caso en donde laspeticiones no retornan datos (Control-No-Data), la transferencia de control por lo menosdebe recibir un Data-IN para el handshake, a su vez el parametro de entrada ptr debe usarun puntero nulo1.

D.2.1. Ejemplo de la construccion de la peticion Set Adress

El siguiente codigo ilustra la construccion de la peticion Set Adress usando la funcionRequest() y las definiciones.

int Set_Adress(WORD adress_nueva)

return Request(HTD, SET_ADDRESS,adress_nueva, 0x00, 0x00,0, (char *) 0);

La funcion Set Adress es una de las mas simples de implementar porque no retornadatos (puntero nulo) y ademas no depende de ninguna otra peticion.

1Un puntero nulo es igual a (char *)0.

129

Apendice E

Construccion de los comandosSCSI

En este apendice se encuentra el detalle de los comandos SCSI que permiten la lecturay escritura de datos. Junto con ello, se muestra el llenado del buffer para el posterior envıodel bloque de comando CBW.

E.0.2. INQUIRY

El comando INQUIRY permite obtener informacion generalizada del dispositivo. Elcodigo de operacion 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 maxi-mo valor es de 0x24 (formato general del retorno). Un valor distinto del valor maximo nocausa error de comando. El campo Page Code es de valor cero (no es soportado en los pen-drives). Por ultimo el campo Allocation Length especifica la particion logica del dispositivo(0 a 7).

130

APENDICE E. CONSTRUCCION DE LOS COMANDOS SCSI

El bloque CBW en conjunto con el comando INQUIRY se envıa en la pipe Bulk delendpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envıo del paqueteal endpoint correspondiente, se muestra a continuacion.

void CBW_INQUIRY()1

2

/*-----------------------------------------------------------------3

* se rellena el comando CBW en el buffer y se envıa como Data Out4

*---------------------------------------------------------------*/5

6

wr811(BUFADR,0x10); // inicio del buffer.7

wr811(BUFLEN,0x1F); // reserva 31 bytes.8

9

//dCBWSignature.10

wr811(0x10,0x55);11

wr811(0x11,0x53);12

wr811(0x12,0x42);13

wr811(0x13,0x43);14

15

//dCBWTag. aleatorio para identificar.16

wr811(0x14,0x71);17

wr811(0x15,0x72);18

wr811(0x16,0x73);19

wr811(0x17,0x74);20

21

//dCBWDataTransferLength.22

wr811(0x18,0x24); // 36 bytes de regreso.23

wr811(0x19,0x00);24

wr811(0x1A,0x00);25

wr811(0x1B,0x00);26

27

//bmCBWFlags28

wr811(0x1C,0x80);29

30

//bCBWLUN31

wr811(0x1D,0x00);32

33

//bCBWCBLength34

wr811(0x1E,0x06);35

36

/* CBWCB (bloque de comando SCSI=INQUIRY)37

INQUIRY siempre tiene el mismo formato.*/38

39

wr811(0x1F,0x12); //codigo INQUIRY.40

wr811(0x20,0x00); //Logical Unit Number.41

wr811(0x21,0x00);42

wr811(0x22,0x00);43

wr811(0x23,0x24); //Allocation Length.44

wr811(0x24,0x00);45

wr811(0x25,0x00);46

wr811(0x26,0x00);47

wr811(0x27,0x00);48

wr811(0x28,0x00);49

131


wr811(0x29,0x00);50

wr811(0x2A,0x00);51

wr811(0x2B,0x00);52

wr811(0x2C,0x00);53

wr811(0x2D,0x00);54

wr811(0x2E,0x00);55

56

//se envıa como Data Out.57

result = 0;58

while( !(result & 0x01) )59

60

wr811(PID_EP,OUT_PID EndBulk.OutDir);61

waitframes(4);62

result=go((0x07 DATA_OUT ));63

64

DATA_OUT ^= BIT6;65

66

Cuando se realiza el comando INQUIRY, los datos que retornan se reciben como DATA-IN, en donde ademas, deben ser recibidos por el controlador SL811HS en forma de Data-Toggle (DATA1 y DATA0 alternadamente). Esta acotacion es valida para todos los coman-dos SCSI que reciben datos. Los campos que retorna el comando INQUIRY es mostradoen el cuadro E.2.

Cuadro E.2: Campos de retorno del comando INQUIRY.

132


E.0.3. READ(10)

El comando READ(10) permite realizar transferencia de datos desde los dispositivos alhost. Tiene un codigo de operacion 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 delendpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envıo del paqueteal endpoint correspondiente, se muestra a continuacion.

void CBW_READ(DWORD sector, BYTE veces)1

2

/*----------------------------------------------------------------3


*---------------------------------------------------------------*/5

6



9

//dCBWSignature.10

wr811(0x10,0x55);11

wr811(0x11,0x53);12

wr811(0x12,0x42);13

wr811(0x13,0x43);14

15


wr811(0x14,0x71);17

wr811(0x15,0x72);18

wr811(0x16,0x73);19

wr811(0x17,0x74);20

21

//dCBWDataTransferLength (512 bytes).22

wr811(0x18,0x00);23

133


wr811(0x19,0x02);24

wr811(0x1A,0x00);25

wr811(0x1B,0x00);26

27

//bmCBWFlags28

wr811(0x1C,0x80);29

30

//bCBWLUN31

wr811(0x1D,0x00);32

33

//bCBWCBLength34

wr811(0x1E,0x0A);35

36

/* CBWCB (bloque de comando SCSI) */37

38

//Operation Code39

wr811(0x1F,0x28);40

wr811(0x20,0x00);41

42

//Logical Block Address43

wr811(0x21,((sector & 0xFF000000)>>24));44

wr811(0x22,((sector & 0xFF0000)>>16));45

wr811(0x23,((sector & 0xFF00)>>8));46

wr811(0x24,(sector & 0x00FF));47

48

//Reservado49

wr811(0x25,0x00);50

51

//Transfer Length (MSB)52

wr811(0x26,0x00);53

54

//Transfer Length (LSB)55

wr811(0x27,veces);56

57

//reservado58

wr811(0x28,0x00);59

wr811(0x29,0x00);60

wr811(0x2A,0x00);61

wr811(0x2B,0x00);62

wr811(0x2C,0x00);63

wr811(0x2D,0x00);64

wr811(0x2E,0x00);65

66

//se envıa como Data Out.67

result = 0;68


70


waitframes(4);72


74

DATA_OUT ^= BIT6;75

76

En la funcion anterior, el parametro sector indica la direccion del sector que se desealeer. El parametro veces indica la cantidad de bloques (512 bytes) que se desean leer con-

134


secutivamente.

E.0.4. WRITE(10)

El comando WRITE(10) permite transferir datos desde el host al dispositivo. Tiene uncodigo de operacion 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 delendpoint Out del dispositivo. El llenado del buffer en el SL811HS, con el envıo del paqueteal endpoint correspondiente, se muestra a continuacion.

void CBW_WRITE(DWORD sector, BYTE veces)1

2

/*----------------------------------------------------------------3


*---------------------------------------------------------------*/5

6



9

//dCBWSignature.10

wr811(0x10,0x55);11

wr811(0x11,0x53);12

wr811(0x12,0x42);13

wr811(0x13,0x43);14

15


wr811(0x14,0x71);17

wr811(0x15,0x72);18

wr811(0x16,0x73);19

135


wr811(0x17,0x74);20

21

//dCBWDataTransferLength.22

wr811(0x18,0x00);23

wr811(0x19,0x02);24

wr811(0x1A,0x00);25

wr811(0x1B,0x00);26

27

//bmCBWFlags28

wr811(0x1C,0x00);29

30

//bCBWLUN31

wr811(0x1D,0x00);32

33

//bCBWCBLength34

wr811(0x1E,0x0A);35

36

/* CBWCB (bloque de comando SCSI) */37

38

//Operation Code39

wr811(0x1F,0x2A);40

wr811(0x20,0x00);41

42

//Logical Block Address43

wr811(0x21,((sector & 0xFF000000)>>24));44

wr811(0x22,((sector & 0xFF0000)>>16));45

wr811(0x23,((sector & 0xFF00)>>8));46

wr811(0x24,(sector & 0x00FF));47

48

//Reservado49

wr811(0x25,0x00);50

51

//Transfer Length (MSB)52

wr811(0x26,0x00);53

54

//Transfer Length (LSB)55

wr811(0x27,veces);56

57

//reservado58

wr811(0x28,0x00);59

wr811(0x29,0x00);60

wr811(0x2A,0x00);61

wr811(0x2B,0x00);62

wr811(0x2C,0x00);63

wr811(0x2D,0x00);64

wr811(0x2E,0x00);65

66

//se envıa como Data Out67

result = 0;68


70


waitframes(4);72


74

DATA_OUT ^= BIT6; 75

136


En la funcion anterior, el parametro sector indica la direccion del sector que se deseaescribir. El parametro veces indica la cantidad de bloques (512 bytes) que se desean escribirconsecutivamente.

Una vez enviado el comando CBW se deben recibir o enviar los datos, para luego fi-nalizar la lectura del bloque CSW. Las funciones completas de lectura, escritura e INQUIRYse muestran a continuacion:

E.0.5. Funcion de lectura de sectores, Leer Sector()

int Leer_Sector(DWORD sect_leer, BYTE veces, char *ptr)

int factor,i;

factor=(veces*512/EndBulk.InSize);

/* 1. Se envıa el comando CBW con Data OUT. */

CBW_READ(sect_leer,veces);

/* 2. Se reciben los datos del tipo DATA-IN en el puntero ptr */

for(i=0;i<factor;i++)

ptr=Recive_IN_DTOGGLE(ptr);

/*3. Se pide el comando(CSW) como DATA-IN y se copia en el arreglo CSW_BUFF de 13B*/

Recive_IN_DTOGGLE(CSW_BUFF);

return 1;

E.0.6. Funcion de escritura de sectores, Escribir Sector()

int Escribir_Sector(DWORD sect_escr, BYTE veces, char *ptr)

int factor,i;

factor=(veces*512/EndBulk.OutSize);

/* 1. Se envıa el comando CBW con DATA-OUT. */

CBW_WRITE(sect_escr,veces);

/* 2. Se envıan los datos como DATA-OUT que estan en el puntero ptr.*/


ptr=BuffWr811(0x10, EndBulk.OutSize,ptr);

OUT_DTOGGLE();



return 1;

E.0.7. Funcion INQUIRY

INQUIRY(char *ptr)

137


int factor, i;

if(EndBulk.InSize==8)

factor=4;

if(EndBulk.InSize==16)

factor=2;

if(EndBulk.InSize>=32)

factor=1;

/* 1. Se Envia el comando CBW con data OUT. */

CBW_INQUIRY();

/* 2. Se reciben los datos del tipo DATA-IN en el puntero ptr */


ptr=Recive_IN_DTOGGLE(ptr);



138

Apendice F

Estructura de informacion FAT16

En este apendice se encuentra la informacion de la estructura FAT16. Tambien se in-cluye la informacion respecto a los formatos de nombres DOS 8.3 y LFN.

F.0.8. Master Boot Record

EL sector llamado MBR (Master Boot Record) informa sobre las diversas particiones(unidades logicas) que existen. Se ubica en los primeros 512 bytes (primer sector de memoriapara los pendrive y Cylinder 0, Head 0, Sector 1, para discos rıgidos). El cuadro F.1 mues-tra los campos que pertenecen al sector MBR, con sus respectivas posiciones y tamanos.

Posicion Descripcion Largo000h Codigo ejecutable (booteable) 446 bytes1BEh 1o Particion 16 bytes1CEh 2o Particion 16 bytes1DEh 3o Particion 16 bytes1EEh 4o Particion 16 bytes1FEh Identificador (55h AAh) 2 bytes

Cuadro F.1: Master Boot Record.

Posicion Descripcion Largo00h Estado de la particion (00h=Inactiva, 80h=Activa) 1 bytes01h Inicio de la particion - Head 1 bytes02h Inicio de la particion - Cylinder/Sector 2 bytes04h Tipo de particion 1 bytes05h Fin de la particion - Head 1 bytes06h Fin de la particion - Cylinder/Sector 2 bytes08h Numero del sector donde se inicia la particion 4 bytes0Ch Numero de sectores en la particion 4 bytes

Cuadro F.2: Informacion de los 16 bytes para cada particion.

139

APENDICE F. ESTRUCTURA DE INFORMACION FAT16

El significado de los 16 bytes que entrega los datos con respecto a las particiones 1, 2,3 y 4, se muestran en el cuadro F.2. Los datos mas importantes que muestra el cuadroF.2, donde ademas fueron considerados para el posterior acceso a las particiones de losdispositivos (pendrives), son los siguientes:

Estado de la particion, Posicion 00h: Indica si la particion esta activa o inactiva.

Tipo de particion, posicion 04h: Indica el tipo de formato de la particion. Los valoresse encuentran en el cuadro F.3. Para el caso de los pendrives el valor corresponde a 06h,equivalente a decir que es una particion tipo FAT16.

Valor Tipo de particion00h Desconocida01h 12-bit FAT04h 16-bit FAT (Particiones menores a 32MB)05h Particion Extendida MS-DOS06h 16-bit FAT (Particiones mayores o iguales a 32MB)0Bh 32-bit FAT (Particiones mayores o iguales 2048GB)

Cuadro F.3: Tipos de particiones.

Sector de inicio, posicion 08h: Indica en que sector de memoria comienza la particion.En caso que no exista el sector MBR, el inicio de la particion correspondera al sector 0x00.

Numero de sectores en la particion, posicion 0Ch: Indica cuantos sectores tiene laparticion. Esto incluye la estructura interna de la particion (PBR, FAT1, FAT2, tabla dedirectorios, sectores reservados y area de datos), por lo cual no corresponde al espacio totaldisponible.

El tamano de cada bloque interno de la particion, en conjunto con otra informacionrelevante que se proporciona sobre la particion, viene establecido en el primer sector decada particion, llamado sector PBR (Partition Boot Record).

140


F.0.9. Partition Boot Record

El cuadro F.4 muestra la organizacion del sector PBR (Partition Boot Record) paraFAT16.

Posicion Descripcion Largo (bytes)000h Jump Code + NOP 3B003h Nombre OEM 8B00Bh Bytes por Sector 2B00Dh Sectores por Cluster 1B00Eh Sectores Reservados 2B010h Numero de Copias de FAT 1B011h Maximo Root Directory 2B013h Numero de Sectores en la Particion menor a 32MB 2B015h Media Descriptor (F8h para discos duros) 1B016h Sectores por Fat 2B018h Sectores por Track 2B01Ah Numero de Heads 2B01Ch Numero de sectores escondidos en la Particion 4B020h Numero de sectores en la Particion 4B024h Numero del Logical Drive de la Particion 2B026h Firma (29h) 1B027h Serial de la Particion 4B02Bh Nombre de la Particion 11B036h Nombre de la FAT (FAT16) 8B03Eh Codigo Ejecutable 448B1FEh Marca de Termino (55h AAh) 2B

Cuadro F.4: Campos del sector Partition Boot Record.

Obteniendo los datos del sector PBR (inicio de la particion), se determina la posicionde los otros sectores importantes:

Tabla de directorios = inicio de la particion + sectores reservados + 2 x (sectores porfat)

Tabla FAT1 = inicio de la particion + sectores reservados

Tabla FAT2 = FAT1 + (tabla de directorios)/2

Area de datos = tabla de directorio + ((maximo root directory)*32/bytes por sector)

141


F.1. Formatos DOS 8.3 y LFN (Long File Name)

En el cuadro F.7 muestra el formato para nombres DOS 8.3 (nombres cortos).

Offset Tamano Contenido0 8 bytes nombre8 3 bytes extension11 1 byte atributo(00ARSHDV)

0: unused bita: archive bitr: read-only bits: system bitd: directory bitv: volume bit

22 2 bytes time24 2 bytes date26 2 bytes cluster28 4 bytes tamano de archivo

Cuadro F.5: Formato de nombres cortos para DOS 8.3.

El formato de nombre LFN incluye al formato 8.3, agregando nuevos campos que noafecta a los nombres del antiguo formato 8.3, para que estos puedan ser reconocidos en sis-temas nuevos y antiguos. El formato LFN para nombres cortos se muestra en el cuadro F.6.

Offset Tamano Contenido0 8 bytes nombre8 3 bytes extension11 1 byte atributo(00ARSHDV)

0: unused bita: archive bitr: read-only bits: system bitd: directory bitv: volume bit

12 1 byte 0 (reservado para Windows NT)13 1 byte hora de creacion; milisegundos14 2 bytes hora de creacion; hora y minuto16 2 bytes fecha de creacion18 2 bytes ultimo dıa de acceso20 2 bytes 0 (reservado para OS/2)22 2 bytes time24 2 bytes date26 2 bytes cluster28 4 bytes tamano de archivo

Cuadro F.6: Formato de nombres cortos para LFN.

142


El formato LFN para nombres largos se muestra a continuacion:

Offset Tamano Contenido0 1 bytes ordinal field1 2 bytes unicode caracter 13 2 byte unicode caracter 25 2 byte unicode caracter 37 2 byte unicode caracter 49 2 bytes unicode caracter 511 1 bytes attribute12 1 bytes type (reservado; siempre 0)13 1 bytes checksum14 2 bytes unicode caracter 616 2 bytes unicode caracter 718 2 bytes unicode caracter 820 2 bytes unicode caracter 922 2 bytes unicode caracter 1024 2 bytes unicode caracter 1126 2 bytes cluster (sin uso; siempre 0)28 2 bytes unicode caracter 1230 2 bytes unicode caracter 13

Cuadro F.7: Formato de nombres largos para LFN

El campo ordinal field corresponde un valor a partir de 1, que indica el orden de la cade-na del nombre. El nombre total se puede repartir a lo largo de diferentes bloques de 32 bytes.

El campo checksum corresponde a los 11 caracteres en formato 8.3. La operacion paracalcular el checksum se muestra a continuacion:

for (sum = i = 0; i < 11; i++)

sum = (((sum & 1) << 7) ((sum & 0xfe) >> 1)) + name[i];

El valor de name[i] corresponde al valor ASCII de cada caracter.

143

Apendice G

Glosario.

En esta seccion se incluyen las principales abreviaciones, terminos, palabras y proto-colos, utilizados en el desarrollo de la memoria. Orientado principalmente a las personasque desean obtener una vision generalizada de los terminos mas comunes que se usan en latecnologıa USB.

A

ACK:Acknowledged o reconocimiento. Este paquete es transmitido cuando el host o el dispositi-vo han recibido satisfactoriamente los datos sin errores. El dispositivo retorna un ACK enel handshake para transacciones OUT o SETUP. En cambio, el host retorna este paquetesolo para transacciones tipo IN.

B

BCD:Codigo Decimal Binario.

Bulk:Una de los cuatro tipos de transferencia que realizan los endpoint para transportar datos

en el protocolo USB. La transferencia Bulk, garantiza la entrega de datos libre de errores.

Bulk-Only:Protocolo de transporte para dispositivos de almacenamiento masivos.

144

APENDICE G. GLOSARIO.

Bus Enumeracion:Deteccion, identificacion y configuracion de un dispositivo USB. Esto incluye: detec-tar la velocidad del dispositivo, asignar una direccion unica al dispositivo y obtenerlos multiples descriptores para la eleccion del driver adecuado.

C

CBI:Control-Bulk-Interrupt. Primer protocolo usado para el transporte de datos en dispositivosde almacenamiento masivo. Actualmente esta obsoleto.

CBW:Command Block Wrapper. Corresponde a un bloque de comando encapsulado utilizado enlos dispositivos de almacenamiento masivo, indicando: la inicializacion de la transferenciay el tipo de operacion a realizar con el dispositivo.

Class o Clases:Agrupaciones de dispositivos USB que reunen similares caracterısticas de funcionamiento

y proposito. La comunicacion entre el host y los dispositivos es similar para los dispositivosde una misma clase. Las clases estan normalizadas por USB-IF.

Control:Una de los cuatro tipos de transferencia que realizan los endpoint para transportar datos

en el protocolo USB. Se utiliza para el transporte inicial de las peticiones (request) que seencargar de configurar un dispositivo USB.

CRC:Verificacion de Redundancia Cıclica. Se usa para proteger los paquetes que se envıan en

el protocolo USB.

CSW:Command Status Wrapper. Es la respuesta del comando CBW que contiene la informaciondel estado de la transferencia.

D

DATA Packet:Consiste en una de las tres fases de las transacciones que se producen en la trama USB. Lafase DATA Packet se compone de un paquete PID, un paquete DATA que lleva los datosreales de la transaccion y finaliza con un paquete de correccion CRC de 16 bits.

145


DMA:Direct Memory Access.

Downstream:Indica que la direccion de las transferencias va desde el host al dispositivo.

E

Endpoint:Puertos que tienen los dispositivos USB para que el host controlador los utilice, con fin

de realizar las multiples transferencias. El maximo de puertos que puede tener un dispo-sitivo es de 16 endpoint. Existen cuatro tipos de endpoint: Control, Bulk, Isochronous eInterrupt. Ademas, cada endpoint tiene asociado un sentido de la transferencia (In-Out),y un tamano maximo de transporte de datos.

EOP:End Of Packet. Fin del paquete en una trama.

F

FireWire o IEEE-1394:Interfaz de comunicacion de alta velocidad para dispositivos perifericos. Este protocolo

busca el mismo proposito que el protocolo USB. La implementacion de la interfaz IEEE-1394 fue desarrollada por la companıa Apple.

Frame:Dirıjase a la definicion de trama.

FS:Abreviacion de full-speed.

Full-Speed:Velocidad de transmision de 12 Mbps, con proposito para disenos de dispositivos que re-

quieren grandes velocidades de transmision.

H

HID:Human interface Device. Corresponde a la clase de dispositivos que interactuan directa-

mente con las personas.

146


High-Speed:Velocidad de transicion de 480 Mbps, solo disponible en el protocolo USB 2.0.

Host Controlador:Es el responsable de gestionar todas las transacciones y transferencias entre los perifericos(USB) y el microcontrolador. El host se encarga de obtener los datos necesarios del dispo-sitivo para cargar el driver adecuado. El host controlador puede ser implementado usandouna combinacion entre hardware, firmware y software.

HUB USB:Dispositivo USB que entrega la posibilidad de aumentar la cantidad de conexion (puertos)de dispositivos USB. La maxima cantidad de dispositivos que se puede realizar es de 127perifericos.

I

IAR Embedded Workbench:Software para programar los microcontroladores MSP430 de Texas Instruments.

IDLE:Indica reposo en la lınea de transmision. El estado IDLE es necesario para permitir:

transferencias, detectar la conexion/desconexion de los dispositivos y discriminar entre dis-positivos LS/FS.

Interrupt:Uno de los cuatro tipos diferentes de transferencias que se realizan con los endpoint. Este

tipo de comunicacion incorpora deteccion de errores y retransmision de datos. Es utilizadopor aquellos dispositivos que desean transferir muy poca informacion y ademas poco fre-cuente, asegurando la lectura de los datos dentro de un perıodo maximo de tiempo.

Isochronous:Uno de los cuatro tipos diferentes de transferencias que se realizan con los endpoint. Ha

sido desarrollado especialmente para satisfacer las demandas de la transmision de tiemporeal de voz, video e imagenes.

L

Low-Speed:Velocidad mas baja que se encuentra disponible en los dispositivos USB. La velocidad

corresponde a 1.5 Mbps, donde tıpicamente es usado por los dispositivos como teclados ymouse.

147


LS:Abreviacion de low-speed.

M

MBR:Master Boot Record. Corresponde al primer sector de memoria de un dispositivo de alma-cenamiento (discos duros o pendrives). El sector MBR entrega informacion de las diversasparticiones que se encuentran activas, indicando la direccion y el tipo de formato.

Microtrama o microframe:Segmentos de tiempos de 125 microsegundos del bus de datos para realizar las transaccio-nes. Esta definicion es aplicable solo a los buses high-speed del protocolo USB 2.0.

MSD:Clase USB llamada Mass Store Device. Corresponde a los dispositivos que tienen la ca-

pacidad de almacenamiento y transporte de datos. Los dispositivos tıpicos que se puedenencontrar en esta clase son: diskette, discos duros, CD-ROM, DVD y pendrives.

N

NAK:Not Acknowledged o Reconocimiento Negativo. Este paquete es transmitido cada vez que

el dispositivo no esta listo para una operacion, tanto de transmision como de recepcion depaquetes.

NRZI:Non Return Zero Inverted. Corresponde a un metodo de codificacion de datos que se utilizaen el protocolo USB. Este consiste en que la lınea cambia de nivel si se transmite un 0 y lalınea se mantiene si transmite un 1.

O

OTG:On-The-Go. Protocolo USB desarrollado con el fin de establecer una comunicacion directaentre lo diversos dispositivos USB.

148


P

PBR:Partition Boot Record. Primer sector de cada particion en donde se encuentra los datos

revelantes sobre la estructura y distribucion de los datos.

Peticiones:Las peticiones o request, son una serie de instrucciones definidas por USB-IF que permitena los controladores USB la interrogacion y configuracion de los dispositivos. La interrogacionpermite obtener informacion clave para la asignacion de un driver adecuado. USB-IF nor-maliza las peticiones en el capıtulo 9 de los protocolos USB 1.1 y USB 2.0

PID:Corresponde a 8 bits de una trama que identifican el tipo de paquete que se esta enviandoo recibiendo.

Pipe:Nombre para indicar los caminos virtuales que recorren los datos entre el endpoint y el host.

R

Request:Dirıjase a la definicion de peticiones.

S

SCSI-2:Small Computer Systems Interface. Serie de comandos reducidos para realizar operacionescomo lectura y escritura de datos en los discos rıgidos. Estos comandos son aplicables a lospendrives siempre y cuando lo soporten.

SE0:Single Ended Zero. Las senales D+ y D- del cable USB tienen el valor de 0 Volts. Se utilizapara: detectar la conexion/desconexion de dispositivos, indicar el fin de paquete (EOP) ypara generar reset.

SL811HS:Controlador USB de la companıa: Cypress Semiconductor Corporation. El controlador

permite realizar transferencias segun el protocolo USB 1.1

149


Slave:Termino comun, para referirse a cualquier dispositivo USB.

SOF:Start Of Frame. Inicio de la trama, se repite cada 1 milisegundo.

SOP:Start Of Packet. Inicio de un paquete en una trama.

STALL:El handshake STALL puede tener tres tipos significado: No soporta una peticion de con-

trol (no existe), la peticion de control ha fallado o el endpoint no existe. En el caso que elendpoint falle, el dispositivo es incapaz de recibir o trasmitir los datos. El comando STALLes transmitido hacia arriba (upstream) solo por los dispositivos, y pueden ser recibidosunicamente por el controlador, el cual debe intervenir para solucionar el problema antes deque la comunicacion puede ser reanudada.

T

Trama o Frame:Segmentos de tiempos de 1 milisegundo del bus de datos, en donde se realizan las tran-

sacciones. Aplicable a los buses low-speed y full-speed.

U

UFI:USB Floppy Interface. Son comandos unificados en base a los comandos SCSI-2 y SFF-

8070i.

Upstream:Indica que la direccion de la transferencia es desde el dispositivo al host. Termino muy

recurrente en los dispositivos como los hub USB.

USB:Protocolo de comunicacion Universal Serial Bus.

USB-IF:USB Implementers Forum S.A. Organismo oficial que se encarga de las normas de la

tecnologıa USB. Su pagina web (www.usb.org) cuenta con herramientas y documentostecnicos, que permiten el desarrollo de los dispositivos.

150


W

WUSB:Wireless Universal Serial Bus. Corresponde al mas reciente protocolo USB, desarrollado

para conectividades inalambricas.

151

Bibliografıa

Textos:

-“Usb Design By Example”:John Hyde, Intel.

-“USB System Architecture (USB 2.0)”:Don Anderson.

-“USB Complete”:Jan Axelson, tercera edicion.

-“Developing USB PC Peripherals”:Wooi Ming Tan.

-“USB Hardware And Software”:John Garney, Ed Solari, Shelagh Callahan, Kosar Jaff, Bradd Hosler.

-“Tecnicas De Diseno Con Microcontrolador MSP430”:Memoria presentada por Jaime A. Zuniga Camiruaga, UTFSM.

Documentos tecnicos:

-“Universal Serial Bus Specification 1.1”:Revision 1.1 Septiembre 23, 1998, http://www.usb.org.

-“Universal Serial Bus Specification 2.0”:Revision 2.0 Abril 27, 2000, http://www.usb.org.

-“Wireless Universal Serial Bus Specification 2.0”:Revision 1.0, http://www.usb.org.

-“Universal Serial Bus Common Class Specification”:Revision 1.0 Diciembre 16, 1997, http://www.usb.org/developers/devclass.html.

152

-“Universal Serial Bus Mass Storage Class, Bulk-Only Transport”:Revision 1.0, http://www.usb.org/developers/devclass.html.

-“Universal Serial Bus Mass Storage Class, Control/Bulk/Interrup (CBI) Transport”:Revision 1.1, http://www.usb.org/developers/devclass.html.

-“Device Class Definition for Human Interface Devices (HID)”:Revision 1.11, http://www.usb.org/developers/devclass.html.

-“SL811HS Embedded USB Host/Slave Controller”:Cypress Semiconductor Corporation.

-“Basic Embedded Host Using the SL811HS”:Cypress Semiconductor Corporation.

-“Interfacing an External Processor to the SL811HS/S”:Cypress Semiconductor Corporation.

-“Errata for SL811HS Embedded USB Host/Slave Controller”:Cypress Semiconductor Corporation.

-“SCSI Block Commands - 2 (SBC-2)”:INCITS, Revision 13, http://www.t10.org/drafts.htm.

-“Un paseo por los dispositivos de almacenamiento masivo USB”:Soporte Tecnico FUJITSU Espana, Marzo de 2003.

-“Un Paseo Por USB-1”:Soporte Tecnico FUJITSU Espana, Marzo de 2000.

Sitios Webs:

-http://www.t10.org/drafts.htm

-http://www.usb.org

-http://www.intel.com/technology/usb

diseno de un driver para dispositivos˜ de almacenamiento ...lsb/elo325/clases/memoria...

Documents