Idiomas
Páginas
Jurídico
Sistema Modular de Adquisición de Datos
AUTOR: Raúl Bartolomé Castro.
DIRECTOR: Alfonso Romero Nevado.
FECHA: Octubre / 2004.
Sistema Modular de Adquisición de Datos
1 Índice
AUTOR: Raúl Bartolomé Castro.
DIRECTOR: Alfonso Romero Nevado.
FECHA: Octubre / 2003.
Índice
3
1.1 Índice de Contenidos 1 Índice ..................................................................................................................... 2
1.1 Índice de Contenidos ..................................................................................... 3
1.2 Índice de Ilustraciones ................................................................................... 6
1.3 Índice da Tablas............................................................................................. 8
2 Memoria Descriptiva ............................................................................................. 9
2.1 Introducción................................................................................................. 10
2.1.1 Contexto .............................................................................................. 10
2.1.1.1 Sistema de Comprobación ISA (INTE ISA)................................... 10
2.2 Objetivos...................................................................................................... 12
2.2.1 Sistema de Comprobación USB (INTE USB)..................................... 12
2.2.2 Sistema de Adquisición de Datos USB (AINTE USB)....................... 14
2.3 El bus USB .................................................................................................. 15
2.3.1 Introducción......................................................................................... 15
2.3.2 Características generales ..................................................................... 15
2.3.2.1 USB 1.0 ........................................................................................... 16
2.3.2.2 USB 1.1 ........................................................................................... 16
2.3.3 Especificaciones técnicas .................................................................... 17
2.3.3.1 Topología ........................................................................................ 17
2.3.3.2 El flujo de datos .............................................................................. 22
2.3.3.3 Protocolo ......................................................................................... 27
2.3.3.4 Características eléctricas ................................................................. 35
2.4 Descripción general ..................................................................................... 38
2.4.1 Hardware ............................................................................................. 39
2.4.1.1 El sistema modular.......................................................................... 40
2.4.1.2 Subsistema de control y comunicaciones USB............................... 41
2.4.1.3 Subsistema de medida ..................................................................... 42
2.4.1.4 Subsistema de conmutación ............................................................ 46
2.4.2 Software............................................................................................... 48
2.4.2.1 Enumeración ................................................................................... 50
2.4.2.2 Archivos de sistema ........................................................................ 51
2.4.2.3 Bibliotecas de Enlace Dinámico ..................................................... 52
2.4.2.4 Aplicación ProvaR.exe.................................................................... 54
2.4.3 Especificaciones del sistema ............................................................... 56
3 Pliego de Condiciones ......................................................................................... 58
Índice
4
3.1 Condiciones Generales ................................................................................ 59
3.1.1 Introducción......................................................................................... 59
3.1.2 Reglamentos y Normas........................................................................ 59
3.1.3 Materiales ............................................................................................ 59
3.1.4 Ejecución del proyecto ........................................................................ 60
3.1.5 Interpretación y Desarrollo.................................................................. 60
3.1.6 Trabajos y Complementos ................................................................... 60
3.1.7 Modificaciones .................................................................................... 61
3.1.8 Realización Defectuosa ....................................................................... 61
3.1.9 Medios Auxiliares ............................................................................... 61
3.1.10 Recepción del Proyecto ....................................................................... 61
3.1.11 Responsabilidades ............................................................................... 62
3.1.12 Fianza .................................................................................................. 62
3.2 Condiciones Técnicas .................................................................................. 63
3.2.1 Condiciones de las Placas de CI .......................................................... 63
3.2.2 Condiciones de los Componentes Electrónicos................................... 63
3.2.3 Condiciones del Montaje de Placas ..................................................... 63
3.3 Condiciones Facultativas............................................................................. 64
3.3.1 Normas a Seguir .................................................................................. 64
3.3.2 Personal ............................................................................................... 64
3.3.3 Reconocimiento de Ensayos Previos................................................... 64
3.3.4 Ensayos................................................................................................ 65
3.3.5 Ensayos de Aparellaje ......................................................................... 65
3.4 Condiciones Económicas............................................................................. 66
3.4.1 Precios ................................................................................................. 66
3.4.2 Abono del Proyecto ............................................................................. 66
3.4.3 Revisión de Precios ............................................................................. 66
3.4.4 Penalizaciones ..................................................................................... 66
3.4.5 Contrato ............................................................................................... 66
3.4.6 Rescisión del Contrato......................................................................... 67
3.4.7 Liquidación en el Caso de Rescisión del Contrato .............................. 67
4 Anexo: Especificaciones Técnicas ...................................................................... 69
4.1 Circuitos Integrados..................................................................................... 70
4.1.1 Conmutadores Analógicos................................................................... 70
4.1.2 Buffers Transceivers............................................................................ 70
Índice
5
4.1.3 Convertidores AD................................................................................ 70
4.1.4 Convertidores DA................................................................................ 70
4.1.5 Dispositivos Lógicos Programables (PLD) ......................................... 70
4.1.6 Lógica Digital ...................................................................................... 70
4.1.6.1 Decodificadores .............................................................................. 70
4.1.6.2 Flip-Flops ........................................................................................ 71
4.1.7 Inter-Integrated Circuit (I2C) .............................................................. 71
4.1.7.1 EEPROM ........................................................................................ 71
4.1.7.2 Sensor Digital de Temperatura ....................................................... 71
4.1.8 Reguladores Lineales........................................................................... 71
4.1.9 Microcontroladores.............................................................................. 71
4.1.10 Memoria .............................................................................................. 71
4.1.11 Amplificadores Operacionales ............................................................ 72
4.1.11.1 Amplificador Operación de Precisión........................................... 72
4.1.11.2 Amplificadores de Instrumentación .............................................. 72
4.1.12 Diodos.................................................................................................. 72
4.1.12.1 Generales....................................................................................... 72
4.1.12.2 Diodos de Voltaje de Referencia .................................................. 72
4.1.12.3 Diodos Emisores de Luz (LED).................................................... 72
4.2 Componentes Pasivos.................................................................................. 73
4.2.1 Condensadores..................................................................................... 73
4.2.2 Resistencias ......................................................................................... 73
4.3 Conectores ................................................................................................... 74
4.3.1 USB ..................................................................................................... 74
4.3.2 DIN41612 ............................................................................................ 74
4.3.3 IDC ...................................................................................................... 74
4.4 Software....................................................................................................... 74
4.4.1 Especificaciones USB 1.1. .................................................................. 74
4.4.2 EZ-USB Especificaciones del GPD .................................................... 74
5 Anexo: Bibliografía ............................................................................................. 75
5.1 Diseño electrónico ....................................................................................... 76
5.2 Especificaciones esenciales ......................................................................... 76
5.3 Proyectos ..................................................................................................... 77
5.4 Páginas WEB............................................................................................... 77
Índice
6
1.2 Índice de Ilustraciones Ilustración 1: Sistema de Comprobación ISA ..................................................................... 10
Ilustración 2: Tipos de comprobaciones de continuidad ..................................................... 10
Ilustración 3: Sistema de Comprobación USB.................................................................... 12
Ilustración 4: Estructura de capas del bus USB................................................................... 17
Ilustración 5: Diagrama de capas del USB.......................................................................... 17
Ilustración 6: La capa física USB........................................................................................ 18
Ilustración 7: HUB USB...................................................................................................... 20
Ilustración 8: La capa lógica USB....................................................................................... 21
Ilustración 9: Relación software cliente y función .............................................................. 21
Ilustración 10: Campo PID.................................................................................................. 28
Ilustración 11: Campo dirección.......................................................................................... 28
Ilustración 12: Campo endpoint .......................................................................................... 28
Ilustración 13: Campo de datos ........................................................................................... 29
Ilustración 14: Transferencia bula ....................................................................................... 33
Ilustración 15: Transferencias de control ............................................................................ 33
Ilustración 16: Transferencia de interrupción...................................................................... 34
Ilustración 17: Transferencias isócronas ............................................................................. 34
Ilustración 18: Identificación de la velocidad del dispositivo ............................................. 35
Ilustración 19: Codificación de datos NRZI........................................................................ 35
Ilustración 20: Señal Sync ................................................................................................... 36
Ilustración 21: Descripción general..................................................................................... 38
Ilustración 22: Sistema de Adquisición de Datos INTE...................................................... 39
Ilustración 23: El sistema modular ...................................................................................... 40
Ilustración 24: Subsistema de control y comunicaciones USB ........................................... 41
Ilustración 25: Subsistema de medida ................................................................................. 42
Ilustración 26: Multímetro de 4 hilos .................................................................................. 43
Ilustración 27: Subsistema de medida real .......................................................................... 44
Ilustración 28: Medición por divisor de tensión.................................................................. 45
Ilustración 29: Subsistema de conmutación ........................................................................ 46
Ilustración 30: Esquema de medición.................................................................................. 47
Ilustración 31: Descripción general del software ................................................................ 48
Ilustración 32: Diagrama de bloques simplificado del microcontrolador ........................... 49
Ilustración 33: Descripción de InteUSB32.dll..................................................................... 52
Ilustración 34: Descripción de InteDrv32.dll ...................................................................... 53
Índice
7
Ilustración 35: Mediaciones de ProvaR.exe ........................................................................ 54
Ilustración 36: Medida con patrón de ProvaR.exe .............................................................. 55
Índice
8
1.3 Índice da Tablas Tabla 1: PIDs USB .............................................................................................................. 27
Tabla 2: Comportamiento en transferencia IN de endpoint ................................................ 31
Tabla 3: Comportamiento en transferencia IN de host........................................................ 31
Tabla 4: Comportamiento en transferencias OUT del host ................................................. 32
Tabla 5: Cable de velocidad baja......................................................................................... 37
Tabla 6: Especificaciones del sistema ................................................................................. 56
Sistema Modular de Adquisición de Datos
2 Memoria Descriptiva
AUTOR: Raúl Bartolomé Castro.
DIRECTOR: Alfonso Romero Nevado.
FECHA: Octubre / 2004.
Memoria Descriptiva
10
2.1 Introducción En este proyecto se describe cómo se ha implementado un Sistema Modular de
Adquisición de Datos. Éste consiste en una carcasa o rack en el que se conectan diversas tarjetas electrónicas: comunicación, medición, conmutación, etc. y mediante un PC, se procesa y controla todo el sistema.
Numerosas veces se hará referencia al Sistema de Comprobación como INTE y al Sistema de Adquisición de Datos como AINTE que son sus nombres comerciales. Éstos pertenecen a la empresa CreaSoft.
2.1.1 Contexto
2.1.1.1 Sistema de Comprobación ISA (INTE ISA)
Ilustración 1: Sistema de Comprobación ISA
El INTE ISA está concebido como una máquina para la comprobación de continuidad del cableado para la automoción. Esto quiere decir que puede determinar si en un cable eléctrico existe continuidad o no.
Para realizar las medidas de continuidad se utilizan unas tarjetas de datos digitales de lectura/escritura de 64 puntos de test cada una. Éstas son el elemento fundamental de comprobación de continuidad. Permiten la comprobación punto a punto así como la de un punto respecto a n. En la siguiente ilustración se puede apreciar la idea:
Ilustración 2: Tipos de comprobaciones de continuidad
Memoria Descriptiva
11
Además de las tarjetas de datos digitales el sistema posee una tarjeta de comunicación entre el equipo y el PC que se realiza mediante el bus ISA, de tal manera que la memoria de las tarjetas de datos es accesible a velocidad de este bus. En términos de diseño electrónico diríamos que las tarjetas de datos están mapeadas directamente en la memoria del bus ISA. Este hecho caracteriza al equipo con una gran velocidad de comprobación de cables, ya que los algoritmos de comprobación se ejecutan mediante el microprocesador del PC.
Como se puede apreciar en la ilustración 1, existen varios armazones o racks para este sistema de comprobación: tamaño A, B, C y el D no representado en la ilustración. Con unos puntos de comprobación que oscilan entre 320 y 4032.
Lo expuesto anteriormente es el punto de partida para el desarrollo de un equipo de comprobación de cableado que solventase varios problemas inherentes a la tecnología utilizada.
La utilización del bus ISA presenta ciertos problemas e incertidumbres a nivel de evolución tecnológica. Con la aparición de Windows 2000 y futuras ediciones, la accesibilidad al bus ISA desaparece. También las placas base de los PC de hoy en día, no presentan ranuras para la conexión de tarjetas ISA.
Por estas razones fue necesario emigrar de un sistema basado en el bus ISA, a otro con grandes expectativas de futuro y buenas prestaciones; el bus USB fue escogido por cumplir varios de los requisitos deseados, como ancho de banda, conexión en caliente, comunicaciones seguras, redes de 126 dispositivos, etc.
Otro aspecto a mejorar es el hecho de utilizar tarjetas de datos digitales para la comprobación de continuidad. Éstas presentan el inconveniente que el umbral de continuidad y no continuidad es fijo y de un valor aproximado de 5 kΩ.
Para mejorar esto se optó por obtener el valor exacto de resistencia del cable eléctrico. De esta forma queda a nivel de programación decidir el umbral de continuidad o no continuidad. Para conseguirlo se utilizaron tarjetas analógicas de medición, implementadas mediante una tarjeta de medición y uno o varias de conmutación.
Memoria Descriptiva
12
2.2 Objetivos Los objetivos de este proyecto se pueden separar en dos grupos
1) Cómo se implemento la transición del Sistema de Comprobación ISA (INTE ISA) al Sistema de Comprobación USB (INTE USB).
Esto consiste en el diseño e implementación de una tarjeta de comunicaciones y control USB así como su software. Se tuvo que realizar de tal manera que pudiese soportar todo el legado del Sistema Comprobación ISA (INTE ISA), es decir, que pudiese soportar tarjetas de datos digitales, hasta los 4032 puntos, compatibilidad de software, etc.
2) Cómo se implemento el Sistema de Adquisición de Datos USB (AINTE USB)
Trabajando sobre el marco proporcionado por el Sistema de Comprobación USB (INTE USB) se pretende diseñar e implementar un Sistema de Adquisición de Datos USB (AINTE USB). Nuevamente se desea que soporte el legado del sistema anterior INTE USB pero que además tenga la posibilidad de realizar mediciones analógicas de resistencias. Para alcanzar el objetivo se diseñaron e implementaros dos tarjetas, una encargada de realizar mediciones a modo de multímetro digital y la otra encargada de realizar conmutaciones analógicas.
2.2.1 Sistema de Comprobación USB (INTE USB)
Ilustración 3: Sistema de Comprobación USB
El objetivo principal es emigrar del bus de comunicaciones ISA al USB, pero existen unas restricciones. Esto es el legado del equipo anterior, el hardware y el software del Sistema de Comprobación ISA, es decir tarjetas de datos digitales, tarjeta de relés electromecánicos y opto acopladores y compatibilizad con el software de comprobación existente llamado HETOS.
Para alcanzar este primer objetivo de pasar del INTE ISA al INTE USB a nivel de hardware, el autor del presente proyecto tuvo de diseñar, implementar y programar una tarjeta para controlar todo el rack y además realizar las comunicaciones USB.
Memoria Descriptiva
13
Esto consistió en la implementación de la tarjeta TBCU, que es la que tiene leds y el conector USB de la ilustración anterior. El diseño está basado en un microcontrolador, un dispositivo lógico programable, memoria RAM, etc.
La compatibilidad de hardware se obtiene manteniendo la misma interfase de tarjeta de control que se utiliza en el INTE ISA, es decir, utilizando la misma conexión al bus ‘backplane’ que se utilizaba anteriormente.
Debido al hecho que el conector USB está ubicado en la parte delantera del equipo, también se ubicó el de alimentación en la parte delantera (orientación similar a la de un autómata PLC), a diferencia del INTE ISA, donde el conector de datos y el de alimentación estaban el la parta trasera del equipo.
Para alcanzar los objetivos a nivel de software, se tuvo que trabajar mucho, esto es así por el cambio radical en la filosofía de acceso. En el INTE ISA las tarjetas de datos digitales están mapeadas directamente en memoria del bus ISA del PC, pero en el INTE USB es el microcontrolador de la tarjeta TBCU el que tiene las tarjetas de datos digitales mapeadas en memoria.
El firmware de la TBCU se describe ampliamente en este proyecto, en la memoria descriptiva, en la memoria de cálculo y también está disponible todo el código fuente en el anexo. Sólo se hace hincapié en la parte de comprobación de cableado a nivel analógico y comunicaciones USB, a pesar de que el autor del proyecto desarrolló todas las funciones, esto es así porque se consideró la parte de comprobación analógica la más interesante del proyecto.
La DLL InteUSB21.dll se describe completamente en los apartados de memoria descriptiva, memoria de cálculo y anexo. Como se ha dicho encapsula todas las comunicaciones USB, otorgando una interfase amigable para la siguiente capa. Este archivo se desarrollo con las indicaciones que proporcionadas por el fabricante del microcontrolador. Implementa una “tubería” de comunicación con el apartado de comunicaciones USB del firmware, de esta manera para el resto de código fuente las comunicaciones son transparentes.
La DLL InteUSB.dll, también fue desarrollado e implementado por el autor del proyecto, este archivo tiene por objetivo, la implementación de todas las funciones que estaban disponibles en el INTE ISA. De esta manera se mantiene una compatibilidad total con el equipo anterior. En esta ocasión no se ha descrito en este proyecto la implementación de este archivo, esto ha sido así para acotar la amplitud del proyecto y también porque se ha considerado mas interesante la parte de comprobación analógica.
Memoria Descriptiva
14
2.2.2 Sistema de Adquisición de Datos USB (AINTE USB) Sobre el marco de trabajo del INTE USB, el objetivo es otorgarle a éste la
posibilidad de realizar mediciones analógicas. En concretos las especificaciones fueron la medición de 20 resistencias con un error del 5% respecto al valor real y mantener el legado del Sistema de Comprobación USB.
Para cumplir el objetivo a nivel de hardware, el autor del proyecto diseñó, desarrolló y programó dos tarjetas. La primera de ella está basada en un multímetro digital de cuatro hilos con la intención de poder realizar mediciones de voltaje, intensidad y resistencia a dos y cuatro hilos, esta tarjeta se llama TVIR.
La otra tarjeta consiste en una matriz de conmutación analógica de dos canales y numerosos puntos de entrada llamada TCA, de esta forma hay disponibles muchos puntos de comprobación gracias a técnicas de multiplexación de los canales de medición de la tarjeta multímetro digital TVIR.
Como se puede observar las especificaciones iniciales eran fácilmente alcanzables, por ello los objetivos fueron mucho más ambiciosos. Se pretendió poder realizar mediciones de resistencias a 4 y 2 hilos, tensión y corriente. Además mediante las tarjetas de conmutación, el número de puntos de comprobación podía ser muy elevado, y próximos a los 4032 puntos digitales del INTE ISA o INTE USB.
Pero debido a lo reducido de los plazos de entrega para el AINTE USB, se produjeron algunos fallos de diseño, entre ellos el más significativo, fue el hecho que la tarjeta de medición sólo pudo hacer medición de resistencias por el principio de divisor de tensión. La tarjeta de conmutación fue de 56 puntos de comprobación, en lugar de los 64.
A nivel de software se tuvo que ampliar el firmware de la tarjeta TBCU para incluir el control de las tarjetas TVIR y TCA, la descripción de cómo se realizó esto se puede leer en la memoria descriptiva, la de cálculo y el anexo.
Para proporcionar unas funciones amigables al programador final, se desarrolló la DLL InteDrv32.dll, está se describe totalmente en el presente proyecto en sus correspondientes apartados de descripción, cálculos y anexo. Este archivo proporciona una única función llamada GetR que devuelve el valor óhmico entre dos puntos de comprobación de la tarjeta TCA.
Finalmente el autor del proyecto implementó la sencilla aplicación ProvaR.exe para ejemplificar el potencial del Sistema Modular de Adquisición de Datos. La explicación y código fuente del mismo están disponibles completamente en este proyecto en sus correspondientes apartados
Memoria Descriptiva
15
2.3 El bus USB
2.3.1 Introducción El bus USB o Universal Serial Bus es una interfaz para la transmisión serie de datas
y distribución de energía desarrollado por empresas líderes del sector de las telecomunicaciones. Ha sido introducida en el mercado de los PC’s y periféricos para mejorar las lentas interfaces series y paralelo.
Este interfaz de 4 hilos distribuye 5 V para la alimentación y puede transmitir datos a velocidad de hasta 480 Mbps en la versión 2.0. Es un bus serie que hace posible la conexión de hasta 127 periféricos a un único conector del PC, con detección u configuración automáticas, siendo esto posible con el PC encendido y sin tener que reiniciarlo.
2.3.2 Características generales La especificación de USB proporciona una serie de características que pueden ser
distribuidas en categorías. Estas características son comunes para todas las versiones.
Facilidad de uso para el usuario:
• Modelo simple para el cableado y los conectores
• Detalles eléctricos aislados del usuario
• Periféricos auto-identificativos
• Periféricos acoplados y reconfigurados dinámicamente
Ancho de banda isócrono:
• Se garantiza un ancho de banda y bajas latencias apropiadas para telefonía, audio, etc.
• Utilización de todo el ancho de banda del bus en este modo
• Control de flujo para el manejo del buffer construido en el protocolo
Amplia gama de aplicaciones:
• Se puede adecuar el ancho de banda de pocos Kbps hasta varios Mbps
• Soporta tanto las transferencias isócronas como las isócronas.
• Soporta hasta 127 dispositivos físicos
Robustez:
• Manejo de errores y mecanismos de recuperación ante fallos
• Inserción dinámica de dispositivos
• Soporte para identificar dispositivos defectuosos
Implementación a bajo coste:
• Comunicaciones a 1,5Mbps
• Conectores y cables de bajo coste
Memoria Descriptiva
16
2.3.2.1 USB 1.0
Esta versión, publicada en Enero del 1996, fue iniciada por el USB-IF cuyos integrantes son Compaq, Digital Equipment Co, IBM, Inte, Microsoft, NEC y Northern Telecom. Es la primera versión que abarca todas las características anteriormente mencionadas. Está limitado a una velocidad máxima de 12Mbps.
Inicialmente fue concebido para la conexión de teléfonos al PC, pero debido a su gran aceptación se desarrolló para convertirse en un estándar.
2.3.2.2 USB 1.1
El objetivo de esta versión, que salió a la luz en septiembre de 1998, era solucionar los problemas de ambigüedad de la especificación 1.0 para facilitar el trabajo a los desarrolladores tanto de hardware como de software.
Existen otras especificaciones USB como la 2.0, 2.0 OTG no las describiré, porque en la implementación de este proyecto se utilizó la especificación 1.1.
Memoria Descriptiva
17
2.3.3 Especificaciones técnicas
2.3.3.1 Topología
La interconexión física USB es una topología de estrellas apiladas donde un hub es el centro de cada estrella. Cada segmento de cable es una conexión punto a punto entre el host y los hubs, o un hub conectado a otro hub.
El número máximo de dispositivos o funciones es de 127, pero el número de capas permitidas (incluida la raíz) es de siete, la longitud de cable máxima entre un hub y el dispositivo o función es de 5m.
Ilustración 4: Estructura de capas del bus USB
La topología del bus USB se puede dividir en tres partes
• La capa física: define cómo están conectados los electos físicamente
• La capa lógica: define los roles y las responsabilidades de los elementos USB
• La relación software del cliente-función: cómo se ven mutuamente el software del cliente y los interfaces de las funciones relacionadas
Ilustración 5: Diagrama de capas del USB
Memoria Descriptiva
18
2.3.3.1.1 La capa física La arquitectura física del USB se centra en las piezas de plástico y de metal con las
que el usuario debe tratar para construir un entrono USB. En la capa física podemos identificar:
• El host
• El controlador del host
• Los enlaces
• Los dispositivos
• Los hubs
Los dispositivos están conectados físicamente al host mediante una topología en estrella, como se aprecia en la siguiente ilustración. Los punto de acople se llaman hubs. Los cuales poseen puertos. Los hubs se conectan entre si o con dispositivos mediante los enlaces (cables de cuatro hilos).
Ilustración 6: La capa física USB
Todas las comunicaciones físicas son iniciadas por el host. Además el host inicia todas las transacciones físicas y soporta todas las transferencias de datos sobre la capa física.
2.3.3.1.1.1 El host USB EL host es el sistema de computación completo, incluyendo el software y el
hardware, sobre el cual se sostiene el USB.
El host tiene la habilidad de procesar y gestionar los cambios de configuración que puedan ocurrir en el bus durante su funcionamiento. El host gestiona el sistema y los recursos del bus como el uso de la memoria del sistema, la asignación del ancho de banda y la alimentación del bus. El host también ayuda con la configuración automática de los dispositivos conectados y reaccionaron los desconectados.
Un host puede soportar uno o más buses USB. Los gestionará cada uno independientemente de los demás. Los recursos específicos del bus como el ancho de banda son únicos para cada bus. Cada bus está conectado al host a través de un controlador host. Sólo hay un host en cualquier sistema USB.
Memoria Descriptiva
19
2.3.3.1.1.2 El controlador del host El controlador del host está formado por el hardware y el software que permite a los
dispositivos USB estar conectados al host. Este controlador es el que inicia las transferencias en el bus. El controlador del host es el master de un bus USB (no existen múltiples masters).
Las funciones básicas del controlador host son:
• Detectar la inserción o desconexión de dispositivos USB
• Gestionar el flujo de control entre el host y los dispositivos
• Gestionar el flujo de datos entre el host y los dispositivos
• Coleccionar estadísticas de actividad y estado
• Proveer una cantidad limitada de energía a los dispositivos conectados
Existen dos implementaciones típicas en el mercado:
• El Universal Host Controller Inteface (UHCI) definido por Intel
• Open Host Controller Interface (OpenHCI o OHCI) definido por Microsoft
2.3.3.1.1.3 Los dispositivos Un dispositivo es una colección de funcionalidades que llevan a cabo algún propósito
(por ejemplo: ratón, teclado, etc.). Cada dispositivo lleva consigo información que puede ser útil para identificar sus características. Esta información se divide en tres categorías:
• Estándar: es la información cuya definición es común a todos los dispositivos USB e incluye electos como la identificación del fabricante, la clase, la gestión de energía, etc.
• Clave: La definición de esta información varía dependiendo del aparato. Es una característica de los dispositivos en cuanto a sus prestaciones.
• USB Vendor: el fabricante del periférico puede poner aquí cualquier información deseada.
El software del host es capaz de determinar el tipo de dispositivo conectado haciendo usa de esta información y de un direccionamiento individual. Todos los dispositivos USB son accedidos por una dirección USB que se asigna dinámicamente cuando se conecta, asignándole también un número. Cada periférico soporta uno o más canales a través de los cuales el host puede comunicarse con los dispositivos, el software del host puede hacer que los drivers del dispositivo apropiados obtengan el control del nuevo dispositivo conectado.
Cuando desconectamos el dispositivo, la dirección puede ser reutilizada para el próximo dispositivo conectado.
Memoria Descriptiva
20
2.3.3.1.1.4 Los hubs Los hubs son un elemento clave en la arquitectura Plug and Play del USB. Plug &
Play el sistema de reconocimiento por el que el sistema operativo detecta un nuevo hardware. Tras la detección, el sistema busca el software que lo gestione, y que puede estar en los discos que el fabricante ofrece con el dispositivo.
Ilustración 7: HUB USB
Un bus tradicional puede ser dividido en segmentos conectados por puentes. Cada segmento tiene un número limitado de puntos de conexión debido a la limitada energía y la carga de cada bus. En la arquitectura USB, el número de puntos de conexión de dispositivos se expande añadiendo dispositivos únicos llamados HUBs o concentradores. Estos dispositivos expanden la arquitectura del USB de dos formas:
• Incrementando los puntos de conexión a través de puertos adicionales
• Proporcionando energía a los dispositivos al expandir el bus
Los HUBs sirven para simplificar la conectividad USB desde la perspectiva del usuario y proporcionar robustez y complejidad a un precio relativamente bajo. Según esta arquitectura, se puede expandir el bus acoplando hubs adicionales, interconectando dichos hubs mediante enlaces. Cada hub convierte un punto simple de conexión en múltiples puntos, donde estos puntos de conexión se les llaman puertos.
Memoria Descriptiva
21
2.3.3.1.2 La capa lógica El punto de vista lógico presenta capas y abstracciones que son relevantes para los
distintos diseñadores. La arquitectura lógica describe cómo unir el hardware del dispositivo USB a un drivers del dispositivo en el host para que tenga el comportamiento que el usuario final desea.
La vista lógica de esta conexión es la mostrada en el esquema siguiente. En el podemos ver cómo el host proporciona conexión al dispositivo, donde esta conexión es a través de un simple enlace USB. La mayoría de los demás buses como PCI, ISA, etc. proporcionan múltiples conexiones a los dispositivos y los drivers lo manipulan mediante algunas combinaciones de estas conexiones (I/O, direcciones de memoria, interrupciones y canales DMA).
Físicamente el USB tiene sólo un cable simple de bus que es compartido por todos los dispositivos del bus. Sin embargo, desde el punto de vista lógico cada dispositivo tiene su propia conexión punto a punto mediante el host.
Ilustración 8: La capa lógica USB
Aunque la mayoría de las actividades de los host o de los dispositivos lógicos usan perspectiva lógica, el host mantiene el conocimiento de la topología física para dar soporte del proceso de desconexión de los hubs. Cuando se quita un hub, todos los dispositivos conectados a él son quitados también de la vista lógica de la topología
2.3.3.1.3 La capa funcional A pesar de que la topología física y lógica del USB refleja la naturaleza de bus
compartido, la manipulación del interfaz de una función USB por parte del software de cliente (CSw) se presenta con una vista distinta.
El software de cliente para las funciones USB debe usar el interfaz de programación software USB para manipular sus funciones en contraposición de las que son manipuladas directamente a través de la memoria o los accesos I/O como pasa con otros buses (PCI, EISA, PCMCIA, etc.). Durante esta operación, el software del cliente debería ser independiente a otros dispositivos que pueden conectarse al USB.
Ilustración 9: Relación software cliente y función
Memoria Descriptiva
22
2.3.3.2 El flujo de datos
Un dispositivo USB desde el punto de vista lógico hay que entenderlo como una seri de endpoints, a su vez los endpoints se agrupan en conjuntos que dan lugar a interfaces, las cuales permiten controlar la función del dispositivo.
Como ya se ha visto la comunicación entre el host y un dispositivo físico USB se puede dividir en tres niveles o capas. En el nivel mas bajo el controlador host USB se comunica con la interfaz del bus utilizando el cable USB, mientras que en el nivel superiores software USB del sistema se comunica con el dispositivo lógico utilizando la tubería de control por defecto (“Default Control Pipe”). En lo que al nivel de función se refiere, el software cliente establece la comunicación con las interfaces de la función a través de tubería a endpoints.
2.3.3.2.1 Endpoints y direcciones de dispositivo Cada dispositivo USB está compuesto por una colección de endpoints
independientes, y una dirección única asignada por el sistema en tiempo de conexión de forma dinámica. A su vez cada endpoint dispone de un identificador único dentro del dispositivo al que pertenece, a este identificador se le conoce como número de endpoint y viene asignado de fábrica. Cada endpoint tiene una determinada orientación de flujo de datos. La combinación de dirección, número de endpoint y orientación, permite referenciar cada endpoint de forma inequívoca. Cada endpoint es por si solo una conexión simple que soporta un flujo de datos en una única dirección, bien de entrada o bien de salida.
Cada endpoint se caracteriza por:
• Frecuencia de acceso al bus requerida
• Ancho de banda requerido
• Número de endpoint
• Tratamiento de errores requerido
• Máximo tamaño de paquete que el endpoint puede enviar o recibir
• Tipo de transferencia para el endpoint
• La orientación en la que se transmiten los datos
Existen dos endpoints especiales que todos los dispositivos deben tener, los endpoints con número 0 de entrada y de salida, que deben de implementar un método de control por defecto al que se le asocia la tubería de control por defecto. Estos endpoints están siempre accesibles mientras que el resto no lo estarán hasta que no hayan sido configurados por el host.
Memoria Descriptiva
23
2.3.3.2.2 Tuberías Una tubería USB es una asociación entre uno o dos endpoints en un dispositivo, y el
software en el host. Las tuberías permiten mover datos entre software en el host, a través de un buffer, y un endpoint en un dispositivo. Hay dos tipos de tuberías:
• Stream: Los datos se mueven a través de la tubería sin una estructura definida.
• Mensaje: Los datos se mueven a través de la tubería utilizando una estructura USB.
Además una tubería se caracteriza por:
• Demanda de acceso al bus y uso del ancho de banda
• Un tipo de transferencia
• Las características asociadas a los endpoints
Como ya se ha comentado, la tubería que esta formada por dos endpoints con número cero se denomina tubería de control por defecto. Esta tubería está siempre disponible una vez se ha conectado el dispositivo y ha recibido un reset del bus. El resto de tuberías aparecen después que se configure el dispositivo. La tubería de control por defecto es utilizada por el software USB del sistema para obtener la identificación y requisitos de configuración del dispositivo, y para configurar al dispositivo.
El software cliente normalmente realiza peticiones para transmitir datos a una tubería vía IRPs (petición de paquetes de entrada/salida) y entonces, o bien espera, o bien es notificado de que se ha completado la petición. El software cliente puede causar que una tubería devuelva todas las IRPs pendientes. El cliente es notificado de que una IRP se ha completado cuando todas las transacciones del bus que tiene asociadas se han completado correctamente, o bien porque se han producido errores.
Una IRP puede necesitar de varias tandas para mover los datos del cliente al bus. La cantidad de datos en cada tanda será el tamaño máximo de un paquete excepto el último paquete de datos que contendrá los datos que faltan. De modo que un paquete recibido por el cliente que no consiga llenar el buffer de datos de la IRP puede interpretarse de diferentes modos en función de las expectativas del cliente, si esperaba recibir una cantidad variable de datos considerará que se trata del último paquete de datos, sirviendo pues como delimitador de final de datos, mientras que si esperaba una cantidad específica de datos lo tomará como un error.
2.3.3.2.2.1 Streams No necesita que los datos se transmitan con una cierta estructura. Las tuberías stream
son siempre unidireccionales y los datos se transmiten de forma secuencial: "first in, first out". Están pensadas para interactuar con un único cliente, por lo que no se mantiene ninguna política de sincronización entre múltiples clientes en caso de que así sea. Un stream siempre se asocia a un único endpoint en una determinada orientación.
Memoria Descriptiva
24
2.3.3.2.2.2 Mensajes A diferencia de lo que ocurre con los streams, en los mensajes la interacción de la
tubería con el endpoint consta de tres fases. Primero se realiza una petición desde el host al dispositivo, después se transmiten los datos en la dirección apropiada, finalmente un tiempo después se pasa a la fase estado. Para poder llevar a acabo este paradigma es necesario que los datos se transmitan siguiendo una determinada estructura.
Las tuberías de mensajes permiten la comunicación en ambos sentidos, de hecho la tubería de control por defecto es una tubería de mensajes. El software USB del sistema se encarga de que múltiples peticiones no se envíen a la tubería de mensajes concurrentemente. Un dispositivo ha de dar únicamente servicio a una petición de mensaje en cada instante por cada tubería de mensajes.
Una tubería de mensajes se asocia a un par de endpoints de orientaciones opuestas con el mismo número de endpoint.
2.3.3.2.3 Frames y microframes USB establece una unidad de tiempo base equivalente a 1 milisegundo denominada
frame y aplicable a buses de velocidad media o baja, en alta velocidad se trabaja con microframes, que equivalen a 125 microsegundos. Los (micro) frames no son más que un mecanismo del bus USB para controlar el acceso a este, en función del tipo de transferencia que se realice. En un (micro) frame se pueden realizar diversas transacciones de datos.
Memoria Descriptiva
25
2.3.3.2.4 Transferencias La interpretación de los datos que se transmitan a través de las tuberías,
independientemente de que se haga siguiendo o no una estructura USB definida, corre a cargo del dispositivo y del software cliente. No obstante, USB proporciona cuatro tipos de transferencia de datos sobre las tuberías para optimizar la utilización del bus en función del tipo de servicio que ofrece la función.
2.3.3.2.4.1 Transferencias de control Es el único tipo de transferencia que utiliza tuberías de mensajes, soporta por lo tanto
comunicaciones de tipo configuración/comando/estado entre el software cliente y su función. Una transferencia de tipo control se compone de una transacción de setup del host a la función, cero o mas transacciones de datos en la dirección indicada en la fase de setup, y por último una transacción de estado de la función al host. La transacción de estado devolverá éxito cuando el endpoint haya completado satisfactoriamente la operación que se había solicitado.
Por lo tanto este tipo de transferencia esta pensado para configurar, obtener información, y en general para manipular el estado de los dispositivos. El tamaño máximo de datos que se transmiten por el bus viene determinado por el endpoint. En dispositivos de velocidad media los posibles tamaños máximos son de 8, 16, 32 o 64 bytes, en velocidad baja el tamaño es de 8 bytes y en velocidad alta 64 bytes. El porcentaje de (micro)frame utilizado ronda el 30% en velocidad baja, 5% en velocidad media y el 2% en alta.
El endpoint puede estar ocupado durante la fase de envío de datos y la fase de estado, en esos casos el endpoint indica al host que se encuentra ocupado, invitando al host a intentarlo mas tarde. Si el endpoint recibe un mensaje de setup y se encontraba en mitad de una transferencia de control, aborta la transferencia actual y pasa a la nueva que acaba de recibir. Normalmente el host no inicia una nueva transferencia de control con un endpoint hasta que no ha acabado la actual, si bien debido a problemas de transmisión el host puede considerar que se han producido errores y pasar a la siguiente. USB proporciona detección y recuperación, vía retransmisión, de errores en las transferencias de control.
2.3.3.2.4.2 Transferencias isócronas Hacen uso de tuberías stream. Garantiza un acceso al bus USB con una latencia
limitada, asegura una transmisión constante de los datos a través de la tubería siempre y cuando se suministren datos, además en caso de que la entrega falle debido a errores no se intenta reenviar los datos.
USB limita el máximo tamaño de datos para los endpoints con tipo de transferencia isócrona a 1023 bytes para los endpoints de velocidad media y 1024 bytes para velocidad alta. De hecho las transferencias isócronas solo se pueden usar en dispositivos de velocidad alta o media. En función de la cantidad de datos que se estén transmitiendo en un momento dado, en velocidad media porcentual de frame utilizado puede variar desde un 1% hasta un 69%, mientras que el porcentaje de microframe utilizado en velocidad alta varía entre un 1% y un 41%.
Memoria Descriptiva
26
2.3.3.2.4.3 Tranferencias de interrupción Utiliza tuberías stream. Este tipo de transferencia está diseñado para servicios que
envían o reciben datos de forma infrecuente. Esta transferencia garantiza el máximo servicio para la tubería durante el periodo en el que envía. En caso de error al enviar los datos se reenvían en el próximo periodo de envío de datos.
El tamaño de paquete de datos máximo es de 1024 bytes para alta velocidad, 64 bytes para velocidad media y 8 bytes para baja velocidad. En ningún caso se precisa que los paquetes sean de tamaño máximo, es decir, no es necesario rellenar los paquetes que no alcancen el máximo. Cuando en una transferencia de interrupción se necesite transmitir más datos de los que permite el paquete máximo, todos los paquetes a excepción del último paquete deben de tener el tamaño máximo. De modo que la transmisión de un paquete se ha llevado a cabo cuando se ha recibido la cantidad exacta esperada o bien, se ha recibido un paquete que no alcanza el tamaño máximo. El porcentaje de (micro) frame utilizado ronda el 13% en velocidad baja y el 2.5% en velocidad media, mientras que en velocidad alta para cantidades similares utilizadas para obtener los anteriores porcentajes se obtienen resultados del 1%, pero para cantidades muy superiores se puede llegar a una utilización del 42%.
2.3.3.2.4.4 Transferencias de bultos (Bulk) Hace uso de tuberías stream. Esta diseñado para dispositivos que necesitan transmitir
grandes cantidades datos en un momento determinado sin importar mucho el ancho de banda disponible en ese momento. Esta transferencia garantiza el acceso al USB con el ancho de banda disponible, además en caso de error se garantiza el reenvío de los datos. Por lo tanto este tipo de transferencia garantiza la entrega de los datos pero no un determinado ancho de banda o latencia.
El tamaño máximo de paquete de datos para velocidad media es de 8, 16, 32 o 64 bytes, mientras que en velocidad alta es de 512 bytes. Los dispositivos de velocidad baja no disponen de endpoints con este tipo de transferencia. No es necesario que los paquetes se rellenen para alcanzar el tamaño máximo. El porcentaje de frame utilizado en velocidad media en función del número de bytes enviados varía entre el 1% y el 5%, mientras que el porcentaje de microframe en velocidad alta varía entre un 1% y un 5%, eso sí, teniendo en cuenta mayor cantidad de datos.
Memoria Descriptiva
27
2.3.3.3 Protocolo
La forma en la que las secuencias de bits se transmiten en USB es la siguiente; primero se transmite el bit menos significativo, después el siguiente menos significativo y así hasta llegar al bit más significativo. Cuando se transmite una secuencia de bytes se realiza en formato "little-endian", es decir del byte menos significativo al byte más significativo.
El primer campo de todo paquete de datos es el campo PID. El PID indica el tipo de paquete y por lo tanto, el formato del paquete y el tipo de detección de errores aplicado al paquete. En función de su PID podemos agrupar los diferentes tipos de paquetes en cuatro clases:
Tipo PID Nombre PID Descripción
OUT 0001B Dirección + número de endpoint en una transacción host a función.
IN 1001B Dirección + número de endpoint en una transacción función a host.
SOF 0101B Indicador de inicio de frame (Start Of Frame) y número de frame.
Token
SETUP 1101B Dirección + número de endpoint en una transacción host a función para realizar un Setup de una tubería de control.
DATA0 0011B PID de paquete de datos par.
DATA1 1011B PID de paquete de datos impar.
DATA2 0111B PID de paquete de datos de alta velocidad, elevado ancho de banda en una transferencia isócrona en un microframe.
Data
MDATA 1111B PID de paquete de datos de alta velocidad para split y elevado ancho de banda en una transferencia isócrona.
ACK 0010B El receptor acepta el paquete de datos libre de errores.
NAK 1010B El dispositivo receptor no puede aceptar los datos o el dispositivo emisor no puede enviar los datos.
STALL 1110B Endpoint sin servicio o una petición de control sobre una tubería no está soportado.
Handshake
NYET 0110B Aún no se ha recibido una respuesta del receptor.
PRE 1100B (Token) Habilita trafico de bajada por el bus a dispositivos de velocidad baja.
ERR 1100B (Handshake) Error de transferencia split.
SPLIT 1000B (Token) Transferencia de alta velocidad split.
PING 0100B (Token) Control de flujo sobre endpoints de tipo control o bulk.
Special
Reservad 0000B PID reservado.
Tabla 1: PIDs USB
Memoria Descriptiva
28
2.3.3.3.1 Formato de los campos Los paquetes se dividen en campos, a continuación se presenta el formato de
diferentes campos.
2.3.3.3.1.1 Campo identificador de paquete PID Es el primer campo que aparece en todo paquete. El PID indica el tipo de paquete, y
por tanto el formato del paquete y el tipo de detección de error aplicado a éste. Se utilizan cuatro bits para la codificación del PID, sin embargo el campo PID son ocho bits, que son los cuatro del PID seguidos del complemento a 1 de esos cuatro bits. Estos últimos cuatro bits sirven de confirmación del PID. Si se recibe un paquete en el que los cuatro últimos bits no son el complemento a 1 del PID, o el PID es desconocido, se considera que el paquete está corrupto y es ignorado por el receptor.
Ilustración 10: Campo PID
2.3.3.3.1.2 Campo dirección Este campo indica la función, a través de la dirección, que envía o es receptora del
paquete de datos. Se utilizan siete bits, de lo cual se deduce que hay un máximo de 128 direcciones.
Ilustración 11: Campo dirección
2.3.3.3.1.3 Campo endpoint Se compone de cuatro bits e indica el número de "enpoint" al que se quiere acceder
dentro de una función, como es lógico este campo siempre sigue al campo dirección.
Ilustración 12: Campo endpoint
2.3.3.3.1.4 Campo número de frame Es un campo de 11 bits que es incrementado por el host cada (micro)frame en una
unidad. El máximo valor que puede alcanzar es el 7FFH, si se vuelve a incrementar pasa a cero.
Memoria Descriptiva
29
2.3.3.3.1.5 Campo de datos Los campos de datos pueden variar de 0 a 1024 bytes. En el dibujo se muestra el
formato para múltiples bytes.
Ilustración 13: Campo de datos
2.3.3.3.1.6 Campo CRC El CRC (Cyclic Redundancy Checks) se usa para proteger todos los campos no PID
de los paquetes de tipo token y de datos. El CRC siempre es el último campo y se genera a partir del resto de campos del paquete, a excepción del campo PID. El receptor al recibir el paquete comprueba si se ha generado de acuerdo a los campos del paquete, si no es así, se considera que alguno o más de un campo están corruptos, en ese caso se ignora el paquete.
El CRC utilizado detecta todos lo errores de un bit o de dos bits. El campo de CRC es de cinco bits para los paquetes de tipo IN, SETUP, OUT, PING y SPLIT.
2.3.3.3.2 Formato de lo paquetes
2.3.3.3.2.1 Paquetes tipo token Un token está compuesto por un PID que indica si es de tipo IN, OUT o SETUP. El
paquete especial de tipo PING también tiene la misma estructura que token. Después del campo PID viene seguido de un campo dirección y un campo endpoint, por último hay un campo CRC de 5 bits.
En los paquetes OUT y SETUP esos campos identifican al endpoint que va a recibir el paquete datos que va a continuación. En los paquetes IN indican el endpoint que debe transmitir un paquete de datos. En el caso de los paquetes PING hacen referencia al endpoint que debe responder con un paquete "handshake".
2.3.3.3.2.2 Paquete inicio de frame SOF Estos paquetes son generados por el host cada un milisegundo en buses de velocidad
media y cada 125 microsegundos para velocidad alta. Este paquete está compuesto por un campo número de frame y un campo de CRC de 5 bits.
2.3.3.3.2.3 Paquete de datos Este paquete está compuesto por cero o más bytes de datos seguido de un campo de
CRC de 16 bits. Existen cuatro tipos de paquetes de datos: DATA0, DATA1, DATA2 y MDATA. El número máximo de bytes de datos en velocidad baja es de ocho bytes, en media de 1023 bytes y en alta de 1024 bytes. El número de bytes de datos ha de ser entero.
Memoria Descriptiva
30
2.3.3.3.2.4 Paquetes Handshake Los paquetes "handshake", en castellano apretón de manos, se utilizan para saber el
estado de una transferencia de datos, indicar la correcta recepción de datos, aceptar o rechazar comandos, control de flujo, y condiciones de parada. El único campo que contiene un paquete de este tipo es el campo PID.
Existen cuatro paquetes de tipo "handshake" además de uno especial:
ACK: Indica que el paquete de datos ha sido recibido y decodificado correctamente. ACK sólo es devuelto por el host en las transferencias IN y por una función en las transferencias OUT, SETUP o PING.
NAK: Indica que una función no puede aceptar datos del host (OUT) o que no puede transmitir datos al host (IN). También puede enviarlo una función durante algunas fases de transferencias IN, OUT o PING. Por último se puede utilizar en el control de flujo indicando disponibilidad. EL host nunca puede enviar este paquete.
STALL: Puede ser devuelto por una función en transacciones que intervienen paquetes de tipo IN, OUT o PING. Indica que una función es incapaz de transmitir o enviar datos, o que una petición a una tubería control no está soportada. El host no puede enviar bajo ninguna condición paquetes STALL.
NYET: Sólo disponible en alta velocidad es devuelto como respuesta bajo dos circunstancias. Como parte del protocolo PING, o como respuesta de un hub a una transacción SPLIT indicando que la transacción de velocidad media o baja aún no ha terminado, o que el hub no está aún habilitado para realizar la transacción.
ERR: De nuevo sólo disponible en alta velocidad y de nuevo formando parte del protocolo PING, permite a un hub de alta velocidad indicar que se ha producido un error en un bus de media o baja velocidad.
Memoria Descriptiva
31
2.3.3.3.3 Transacciones Los paquetes de tipo token tiene como objetivo indicar el inicio de una transacción
de datos de una determina forma.
2.3.3.3.3.1 Transferencia IN La transacción empieza con el envío de un paquete de tipo IN por parte del host a un
determinado endpoint en una función. Un endpoint cuando recibe un paquete de tipo IN debe comportarse como muestra la siguiente tabla:
Token recibido corrupto
Estado de endpoint
La función puede transferir los datos
Acción
Si - - No responde
No Deshabilitado - Envía STALL
No Habilitado No Envía NAK
No Habilitado Si Envía el paquete de datos
Tabla 2: Comportamiento en transferencia IN de endpoint
La respuesta que del host al recibir un paquete de datos en la transacción se puede observar en la siguiente tabla:
Paquete de datos corrupto
El host puede aceptar los datos
Respuesta del host
Si - Descarta el paquete, no responde
No No Descarta el paquete, no responde
No Si Envía ACK
Tabla 3: Comportamiento en transferencia IN de host
2.3.3.3.3.2 Sincronización mediante conmutación de bits USB ofrece un mecanismo que garantiza la sincronización entre el emisor y el
receptor de datos a lo largo de múltiples transacciones. La idea es garantizar que los dos sean conscientes de que los handshakes han sido recibidos correctamente. Para ello se utilizan los dos PID DATA0 y DATA1 que sólo varían en un bit. De manera que inicialmente tanto el emisor y el receptor están sincronizados en la secuencia de bits. De modo que, el que recibe datos conmuta su bit cuando puede aceptar datos y ha recibido un paquete de datos libre de errores. Por su parte el que envía conmuta su bit cuando recibe un ACK, tal que si el último paquete de datos tenía PID DATA0 el siguiente tendrá DATA1, y viceversa, además si todo ha salido bien, el PID del paquete coincidirá con la secuencia de bits del receptor.
Memoria Descriptiva
32
2.3.3.3.3.3 Transacción OUT El host envía un paquete OUT a un determinado endpoint y seguidamente envía el
paquete de datos. Suponiendo que el endpoint ha decodificado correctamente el token, en caso contrario se ignora el token y lo datos, espera a recibir un paquete de datos. El comportamiento del endpoint cuando recibe el paquete de datos es el siguiente. Paquete de datos corrupto
Estado del receptor
Coincidencia de la secuencia de bits
La función puede aceptar los datos
Acción
Si - - - No responde
No Deshabilitado - - Envía STALL
No Habilitado No - Envía ACK
No Habilitado Si Si Envía ACK
No Habilitado Si No Envía NAK
Tabla 4: Comportamiento en transferencias OUT del host
2.3.3.3.3.4 Transacción SETUP La transacción SETUP es una transacción especial que tiene las mismas fases que
una transacción OUT, que sólo se puede utilizar con endpoints de tipo control y cuya finalidad es la de indicar el inicio de la fase setup.
2.3.3.3.4 Las transferencias En este apartado se muestra de forma general las transacciones que se realizan, y las
particularidades de cada tipo de transferencia.
De forma general toda función en principio está esperando a que el host le envíe un paquete, si este paquete es de tipo token entonces cambia el estado de la función iniciándose una transacción. También se debe de tener en cuenta, que cuando o bien el host, o bien una función se encuentran en un estado que no es el de reposo, aparecen los timeouts como otra causa de error.
Memoria Descriptiva
33
2.3.3.3.4.1 Transferencias de bulto (Bulk) En las transferencias de bulto se puede hablar en parte de transacciones de bulto,
pues la idea es enviar datos de paquete en paquete sin que tenga que haber un flujo de datos continuo. La diferencia reside en que si hablamos de transferencia, no se puede considerar que haya terminado hasta que el host haya conseguido enviar los datos, o bien que después de varios intentos fallidos de un error.
Cada transacción de bulto se puede dividir en tres fases: token, datos y "handshake", si bien gracias al token PING pueden haber transacciones de dos fases: token y "handshake". A continuación un esquema de una transacción de bultos.
Ilustración 14: Transferencia bula
2.3.3.3.4.2 Transferencias de control Estas transferencias constan de tres fases: transacción setup, fase de datos y
transacción de estado. La transacción siempre la inicia el host, y sirve para enviar información de control para indicar al endpoint que se quiere realizar. El siguiente esquema representa una transacción setup.
Ilustración 15: Transferencias de control
Memoria Descriptiva
34
A continuación se inicia la fase de transferencia de datos, que consiste en una secuencia de transacciones de datos siempre en la misma dirección alternando DATA0 y DATA1. Esta fase no es obligatoria, la dirección se establece en la fase setup. Finalmente tiene lugar una transacción estado, esta transacción es idéntica a una transacción de bultos. La dirección de esta transacción es siempre la contraria a la de la fase de transferencia de datos, y si esta no exisitiese, la dirección es del endpoint al host.
2.3.3.3.4.3 Transferencias de interrupción Las transferencias de interrupción son solamente transacciones de tipo IN y OUT.
Desde el punto de vista de las transacciones es muy similar a una transferencia de bultos. A continuación el esquema de una transacción de interrupción.
Ilustración 16: Transferencia de interrupción
2.3.3.3.4.4 Transferencias isócronas Una transferencia isócrona se plantea como una secuencia de transacciones muy
sencillas para enviar o recibir datos. Estas transacciones no utilizan "handshakes" y por lo tanto no se reenvían paquetes, ya que el objetivo de la transferencia es simular un flujo constante de datos. A continuación un esquema de una transacción.
Ilustración 17: Transferencias isócronas
Memoria Descriptiva
35
2.3.3.4 Características eléctricas
2.3.3.4.1 Identificación de la velocidad del dispositivo Para poder iniciar cualquier tipo de transacción cuando se conecta el dispositivo al
host, es necesario que este conozca la velocidad a la que trabaja. Con esa finalidad existe un mecanismo a nivel eléctrico. La diferencia entre los dispositivos de velocidad media y los de velocidad baja, es que en velocidad media tiene una resistencia conectada al D+, en velocidad baja la misma resistencia se encuentra en D- y no en D+ como se puede observar en los dibujos.
Ilustración 18: Identificación de la velocidad del dispositivo
De forma que después del reset el estado de reposo de la línea es diferente si se trata de baja o media velocidad. En el caso de dispositivos de alta velocidad lo que se hace es que en un principio se conecta como un dispositivos de velocidad media y mas tarde a través de un protocolo se pasa a velocidad alta.
2.3.3.4.2 Codificación de datos El USB utiliza la codificación NRZI para la transmisión de paquetes. En esta
codificación los "0" se representan con un cambio en el nivel, y por el contrario los "1" se representan con un no cambio en el nivel. De modo que las cadenas de cero producen transiciones consecutivas en la señal, mientras que cadenas de unos produce largos periodos sin cambios en la señal. A continuación un ejemplo:
Ilustración 19: Codificación de datos NRZI
Memoria Descriptiva
36
2.3.3.4.3 Relleno de bits Debido a que cadenas de unos pueden producir largos periodos en los que la señal no
cambia dando lugar a problemas de sincronización, se introducen los bits de relleno. Cada 6 bits consecutivos a "1" se inserta un bit a "0" para forzar un cambio, de esta forma el receptor puede volverse a sincronizar. El relleno bits empieza con el patrón de señal Sync. El "1" que finaliza el patrón de señal Sync es el primer uno en la posible primera secuencia de seis unos.
En las señales a velocidad media o baja, el relleno de bits se utiliza a lo largo de todo el paquete sin excepción. De modo que un paquete con siete unos consecutivos será considerado un error y por lo tanto ignorado.
En el caso de la velocidad alta se aplica el relleno de bits a lo largo del paquete, con la excepción de los bits intencionados de error usados en EOP a velocidad alta.
2.3.3.4.3.1 Sync Teniendo en cuenta que K y J representan respectivamente nivel bajo y nivel alto, el
patrón de señal Sync emitido, con los datos codificados, es de 3 pares KJ seguidos de 2 K para el caso de velocidad media y baja. Para velocidad alta es una secuencia de 15 pares KJ seguidos de 2 K. A continuación el caso de velocidad media y baja:
Ilustración 20: Señal Sync
El patrón de señal Sync siempre precede al envío de cualquier paquete, teniendo como objetivo que el emisor y el receptor se sincronicen y se preparen para emitir y recibir datos respectivamente.
Si partimos de que el estado de reposo de la señal es J, podemos interpretar Sync como una secuencia impar de "0's" y un "1" que se inserta antes de los datos.
2.3.3.4.3.2 EOP A todo paquete le sigue EOP, cuya finalidad es indicar el final del paquete.
En el caso de velocidad media y baja el EOP consiste en que, después del último bit de datos en el cual la señal estará o bien en estado J, o bien en estado K, se pasa al estado SE0 durante el periodo que se corresponde con el ocupado por dos bits, finalmente se transita al estado J que se mantiene durante 1 bit. Esta última transición indica el final del paquete.
En el caso de la velocidad alta se utilizan bits de relleno erróneos, que no están en el lugar correcto, para indicar el EOP. Concretamente, el EOP sin aplicar codificación consisitiría en añadir al final de los datos la secuencia 0111 1111.
Memoria Descriptiva
37
2.3.3.4.4 Cable de velocidad baja Al igual que el cable fijo de alta y media velocidad tiene un conector macho de Serie
A en un extremo, mientras que el otro depende del fabricante. La diferencia es que este tipo de cables sólo funciona con dispositivos de velocidad baja.
Contacto Señal Cable
1 VBUS Rojo
2 Datos- Blanco
3 Datos+ Verde
4 GND Negro
Tabla 5: Cable de velocidad baja
Memoria Descriptiva
38
2.4 Descripción general
Ilustración 21: Descripción general
En la anterior ilustración se describe de forma general todo el sistema INTE. El usuario se comunica mediante el PC en un entorno Windows para medir variables eléctricas con el INTE. Se puede apreciar claramente dos bloques:
1) PC
En este soporte se ejecuta la aplicación ‘ProvaR.exe’ que sirve para demostrar el potencial del sistema. Este ejecutable accede al INTE mediante un conjunto de archivos según aparecen en el dibujo: ‘InteDrv32.dll’ y ‘InteUSB32.dll’, que implementan las funciones del INTE y las comunicaciones USB respectivamente; ‘InteDrv.sys’ y el ‘Host Controller Driver’ que proporcionan nuevas API’s a Windows y el driver del hardware USB de placa base respectivamente.
2) INTE
Éste esta constituido básicamente por un bus denominado Tarjeta de Enlace (TE) en el cual se conectan el resto de placas: la Tarjeta Base de Control USB (TBCU), que se encarga de las comunicaciones USB y el control de todo el INTE, gracias a su software residente en memoria ‘FirmwareTBCU.hex’; la Tarjeta de medición de Voltaje, Intensidad o Resistencia (TVIR), que como su nombre indica es la que adquiere la información del exterior; y las Tarjetas de Conmutación Analógica (TCA), cuya función es realizar caminos entre los puntos de medida y la TVIR
Memoria Descriptiva
39
2.4.1 Hardware
Ilustración 22: Sistema de Adquisición de Datos INTE
En la ilustración anterior observamos el Sistema de Adquisición de Datos INTE, los elementos con los que está constituido y cómo se relaciona con el exterior. De izquierda a derecha identificamos la fuente de alimentación, conectada a tensión de línea; la Tarjeta Base de Control USB TBCU, conectada al PC mediante el bus USB; la Tarjeta de medición de Voltaje, Intensidad y Resistencias TVIR; y finalmente las Tarjetas de Conmutación Analógica, que mediante cables planos se conectan los elementos a medir.
Todas las tarjetas, así como la fuente de alimentación, están conectadas entre si mediante la Tarjeta de Enlace TE, que realiza la función de ‘backplane’.
Memoria Descriptiva
40
2.4.1.1 El sistema modular
Ilustración 23: El sistema modular
El sistema modular se consigue mediante un ‘backplane’ que lo llamamos Tarjeta de Enlace TE. Existen dos modelos, la primera es la TE6 de seis conectores de bus, y la segunda es la TE17 de 17 conectores de bus.
En todos los conectores de bus se pueden conectar periféricos como tarjetas TCA, a excepción del primero, que está dedicado a la fuente de alimentación, y el segundo, que esta reservado para la tarjeta TBCU o equivalente. Sólo existen dos tipos de conectores físicamente diferentes, un tipo es el conector de alimentación y el resto es el otro tipo.
La TE es un ‘backplane’ pasivo, sin compensar, es decir sin elementos activos como semiconductores, ni impedancias de terminación de línea. Se caracteriza por 8 líneas de datos, 4 de direcciones, 3 de control, 4 analógicas, 4 de alimentación y 1 línea extra por cada periférico.
Memoria Descriptiva
41
2.4.1.2 Subsistema de control y comunicaciones USB
Ilustración 24: Subsistema de control y comunicaciones USB
La Tarjeta Base de Control USB para los amigos TBCU, se encarga de controlar todo el Sistema de Adquisición de Datos INTE, y también las comunicaciones USB. De derecha a izquierda, observamos el conector de bus para la conexión con la TE, debiéndose utilizar sólo el conector de bus master. Seguidamente encontramos el Conector de Piso, que otorga la posibilidad de expansión a otro piso, con un total máximo de 6. En la parte izquierda identificamos el conector para el cable USB y un conjunto de leds que informan sobre las tensiones del sistema y del estado de la propia TBCU.
Está diseñada alrededor del microcontrolador de la familia 8051 con ‘interface’ USB, éste ejecuta un programa que está ubicado en una memoria SRAM de 32 kBy. En el diseño interviene muy activamente un PLD de Altera de la familia MAX300, que se caracteriza por un gran número de pines, a un precio muy razonable, sus funciones son la de implementar toda la lógica discreta del la tarjeta, así como la de ‘interface’ entre 5 V y 3,3 V. Mediante un ‘jumper’ ubicados cerca del conector de bus (selección de piso), se habilita un decodificador de 4 a 16 para generar las señales de selección de periféricos. El resto de elementos son ‘buffer’ bidireccionales del tipo 245, utilizados como cabeceras de bus.
La TBCU posee un sensor digital de temperatura y una memoria EEPROM (no presentes en la ilustración), ambos se comunican con el microcontrolador mediante el bus I2C; el primero interviene en el control de la ventilación del INTE cuando este es de grandes dimensiones; y el segundo almacena los identificadores del dispositivo USB (TBCU) que son el identificador del vendedor VID y el identificador del dispositivo PID.
Memoria Descriptiva
42
2.4.1.3 Subsistema de medida
Ilustración 25: Subsistema de medida
La Tarjeta de medición de Voltajes, Intensidades y Resistencias, fue concebida como un multímetro digital, con la capacidad de medir pequeñas tensiones o corrientes y mediciones de resistencias a 2, 4 o 5 hilos. De derecha a izquierda, observamos el conector de bus para la conexión con la TE, pudiéndose utilizar cualquier conector de bus para periférico. En el extremo izquierdo identificamos los 5 conectores necesarios para realizar todos los tipos de mediciones deseados.
Está diseñada alrededor de un PLD de Altera de la familia MAX 7000, se caracteriza por 128 macrocélulas de memoria y 84 pines. Sus funciones son las de controlar todos los componentes de la tarjeta, así como la comunicación mediante el bus TE. La tarjeta también posee una memoria de 8 kBy para realizar adquisiciones de datos en modo ráfaga. Mediante un buffer 245 se comunica con el backplane TE.
El sistema analógico de adquisición está constituido por el conversor analógico digital ADS7806 de 12 bits, que es compatible con el ADS7807 que es de 16 bits. A continuación se puede identificar un amplificado de ganancia variable PGA aunque en realidad son dos concatenados, mediante éstos se obtienen 7 posibles ganancias.
Para la medición de resistencia es necesaria una corriente constante y además debe ser variable para poder medir en un amplio rango, por lo tanto fue necesaria la implementación de una fuente de corriente controlada digitalmente. Para ello se optó por un conversor digital analógico AD7945 de 12 bits, que es la entrada de un conversor tensión corriente.
Memoria Descriptiva
43
A modo ilustrativo se presenta la siguiente la siguiente figura:
Ilustración 26: Multímetro de 4 hilos
En la ilustración anterior se puede apreciar cómo debería ser el conjunto TVIR de 4 hilos con el ‘backplane’ TE. Esquemáticamente se puede apreciar la fuente de corriente que proporciona una intensidad de Iout y un amplificador de instrumentación.
La configuración anterior el la típica de un multímetro de baja tensión con la capacidad de medir resistencia d 4 hilos. Para realizar la medición de corriente lo es necesario ubicar una resistencia entre los terminales positivo y negativo del amplificador.
Memoria Descriptiva
44
2.4.1.3.1 Subsistema de medida definitivo
Ilustración 27: Subsistema de medida real
El diseño inicial de la TVIR es el que se ha presentada en la ilustración anterior, pero se produjo un error de diseño al escoger el módulo de conversión de tensión a corriente. Éste fue una fuente de corriente Howland, que presento una muy mala respuesta frente a variaciones de carga.
Como en el momento que se implementó el sistema había mucha prisa por el plazo de entrega, se tuvo que reaprovechar el circuito y no se pudo rehacer. Se Optó por cambiar la filosofía de medición de resistencias.
El criterio inicial de medida fue utilizar una fuente de corriente constate para aplicar la ley de Ohm, de esta manera podía realizar mediciones a 2 y 4 hilos. Como no era una especificación necesaria la medición a 4 hilos se decidió descartarla y utilizar sólo la de 2 hilos.
Finalmente se optó por utilizar el principio de divisor de tensión para realizar la medición de resistencias, de ahí que el ‘nuevo’ diseño de la TVIR aparezca una resistencia y desaparezcan el conversor digital analógico y la el conversor tensión corriente.
Memoria Descriptiva
45
En la siguiente ilustración se puede apreciar cómo quedó finalmente el esquema electrónico de medición de resistencias
Ilustración 28: Medición por divisor de tensión
Se puede observar que el principio de medición es el de divisor de tensión. Para deducir la resistencia incógnita lo que se realiza es la medición de la caída de tensión sobre una resistencia de sensado, esto es la medición indirecta de la corriente que circula por el divisor de tensión.
En esta configuración, sólo se puede realizar la medición de resistencias. Se puede observar que se han reducido sustancialmente las prestaciones iniciales que se pretendían alcanzar.
Memoria Descriptiva
46
2.4.1.4 Subsistema de conmutación
Ilustración 29: Subsistema de conmutación
La Tarjeta de medición de Conmutación Analógica tiene por objetivo en enrutamiento de las señales eléctricas entre las cargas o variables a medir y la tarjeta de medición TVIR. En la derecha, observamos el conector de bus para la conexión con la TE, pudiéndose utilizar cualquier conector de bus para periférico. En el extremo izquierdo identificamos otro conector con las mismas características que el conector de bus, pero esta está destinado para la conexión con el exterior.
Está constituida por 56 puntos de conexión, cada uno de los puntos se pueden conectar a cualquiera de los dos canales internos de la tarjeta, éstos a su vez se encaminan hacia el conector de bus.
El componente clave del diseño es el conmutado analógico de 4 canales DG442 o su homólogo de mejores características MAX313. Cada pareja de estos conmutadores está gobernado por un octal flip-flop tipo D 273.
Está conjunto esta controlado por un PLD de Altera de la familia MAX 7000, se caracteriza por 64 macrocélulas de memoria y 44 pines. Sus funciones son las de decodificar las direcciones provenientes del conector de bus así como las señales de control de lectura, escritura y reset.
En un sistema típico de adquisición de datos se utilizan numerosas TCA y una TVIR. De esta forma se consigue tener muchos canales de medición sin aumentar excesivamente el coste del sistema, ya que sólo una tarjeta es la que se encarga de medir. Se debe tener en cuenta que esta filosofía de trabajo implica que la velocidad de adquisición de datos se va
Memoria Descriptiva
47
reduciendo proporcionalmente al número de canales utilizados (característica típica de los sistemas multiplexados).
El circuito resultante es el siguiente:
Ilustración 30: Esquema de medición
En la ilustración anterior se puede apreciar el conjunto final de medición de resistencias. La tarjeta TVIR en configuración de medición mediante divisor de tensión, el ‘backplae’ TE encargado de trasmitir las señales analógicas a lo largo del bus y la tarjeta TCA para conmutar las señales analógicas y así poseer muchos canales de medición.
Cabe hacer la anotación que podrían haber numerosas tarjetas TCA, para alcanzar así un gran número de canales de medición.
Memoria Descriptiva
48
2.4.2 Software
Ilustración 31: Descripción general del software
En la ilustración anterior podemos observar la descripción general del software que participa en el sistema de adquisición de datos. Se presenta un diagrama de capas de forma similar al descrito en el apartado del bus USB, las líneas verticales es la comunicación real de datos y las líneas horizontales son las comunicaciones virtuales de datos a excepción del cable USB que circulación real, también podemos distinguir tres capas:
• Capa interfaz de bus USB que es la capa física
• Capa de dispositivo USB que es la capa lógica
• Capa funcional que es la capa funcional
A diferencia del diagrama de capas del USB presentado en el apartado de especificaciones técnicas del bus USB que era genérico, en el que presentamos en este apartado es específico de la aplicación. La ilustración contempla el hecho de utilizar el microcontrolador Cypress EZ-USB y el software que interviene de este fabricante.
El microcontrolador implementa la capa física del USB, esto es, el transceiver y el SIE (“Serial Interface Engine”). Esta es una de la soluciones posible de implementación, otra muy típica con un nivel de integración menor, es la utilización de un microcontrolador genérico y un periférico USB.
Memoria Descriptiva
49
Ilustración 32: Diagrama de bloques simplificado del microcontrolador
El SIE decodifica y codifica los datos serie e implementa la corrección de errores, el relleno de bits, y otros detalles de señales requeridos por el USB y en última instancia transferencia de datos de y hacia el interfaz USB.
El microprocesador interno del EZ-USB es una mejora del 8051 con tiempo de ejecución rápido y nuevas características. Utiliza memoria interna RAM (también puede ser externa) para almacenar el programa y el código, convirtiendo a la familia EZ-USB en una solución software de la implementación. El controlador host descarga el código de programa y la personalidad del dispositivo del 8051 en la memoria RAM a través del bus USB, y entonces el chip EZ-USB re-conecta como un dispositivo personalizado cómo define el código cargado. El código o firmware que se descarga es el archivo InteDrv.sys de la primera ilustración del apartado.
La familia EZ-USB usa una mejora del interfaz SIE/USB (llamado núcleo USB) el cual tiene la inteligencia de funcionar como un dispositivo USB completo incluso antes que el 8051. La mejora del núcleo simplifica el código del 8051 implementando por si mismo mucho del protocolo USB.
La capa funcional abarca la aplicación del cliente, en el lado del PC está la librería de enlace dinámico ‘InteUSB32.dll’ la cual encapsula las llamadas a las API’s de Windows. También se desarrolló la biblioteca dinámica ‘InteDrv32.dll’ que es el último nivel de abstracción al hardware, permitiendo un interfaz amigable para el programador final. Por último está la aplicación ‘ProvaR.exe’ que sirve para ejemplificar el acceso al hardware. En el lado del microcontrolador tenemos el ‘FirmwareTBCU.hex’ que es el resultado del compilador Keil para 8051, este archivo esta empotrado dentro de ‘InteDrv.sys’ el cual se encarga de descargar el firmware en el encendido de la máquina (INTE).
Memoria Descriptiva
50
2.4.2.1 Enumeración
Este término es muy utilizado dentro de las especificaciones del bus USB, consiste en lo siguiente. Cuando el PC está encendido. Conectas un dispositivo USB, y Windows cambia el cursor por un reloj de arena y luego vuelve al cursor al estado inicial. Mágicamente, el dispositivo es conectado y su driver de Wiondows es cargado. Esto es un auténtico Plug and Play.
¿Qué ha sucedido automáticamente? Dentro de cada dispositivo USB hay una tabla de ‘descriptores’ que son la suma total de los requerimientos y características de los dispositivos. Cuando se conecta en el USB, el host realiza la siguiente secuencia:
• El host envía una petición “Get_Descriptor/Device” a la dirección cero (el dispositivo debe responder mediante la dirección cero tras su primera conexión)
• El dispositivo responde a la petición devolviendo un PID de datos diciendo quien es
• El host envía al dispositivo una petición de”Set_Address”, la cual da una única dirección para distinguirlo de otros dispositivos conectados en el bus.
• El host envía mas peticiones de “Get_Descriptor”, preguntando más información al dispositivo. De esta forma sabe cuantos end-points posee, sus requerimientos de energía, el ancho de banda necesario y que driver cargar.
2.4.2.1.1 Re-Enumeración Como hemos dicho, la familia EZ-USB tiene la característica ‘soft’, esto es, poder
cambiar la identidad del chip en múltiples momentos. En el inicio de la conexión del periférico, el primer driver descarga el firmware en el 8051 y las tablas de descriptores mediante el cable USB. Una vez ha sido descargado el firmware, otro driver se carga totalmente diferente según especifique el firmware. Este segundo proceso, se llama Re-Enumeración, sucede en la conexión inicial del dispositivo USB.
Para mas información sobre el microcontrolador remítase a la documentación técnica del anexo, en concreto “EZ-USB Technical Reference Manual”.
Memoria Descriptiva
51
2.4.2.2 Archivos de sistema
Los archivos de sistema pertenecen al núcleo del sistema operativo, esto quiere decir que para compilarlos es necesario utilizar DDK (Developer Driver Kit). Si se utiliza Windows 2000 o posterior debe hacerse la instalación en modo administrador.
2.4.2.2.1 InteUSB.inf Este no es un archivo compilado, es simplemente de texto. Se utiliza en el
procedimiento de instalación del hardware. En su interior asocia el identificado del periférico con un driver en concreto.
Debido a las características de este microcontrolador existen dos asociaciones como mínimo, la primera para la Enumeración y la segunda par la Re-Enumeración. En el anexo de Código fuente puede observarse la implementación de este archivo.
2.4.2.2.2 InteLdr.sys Este archivo es el encargado de descargar el firmware en el microcontrolador 8051.
Es durante el proceso de Enumeración descrito en los apartados anteriores cuando este archivo entra en acción.
Cuando le llega por primera vez la alimentación al 8051, Windows identifica el periférico y utiliza el archivo InteLdr.sys como driver, éste en su interior almacena el firmware, que en nuestro caso proviene de un compilador de 8051 (Keil). El firmware se descarga y en consecuencia se provoca la Re-Enumeración, que provoca que se cargue otro driver, ‘InteDrv.sys’ descrito en el siguiente apartado.
El armazón de este archivo viene dado por el fabricante del microcontrolador, Cyprees.
2.4.2.2.3 InteDrv.sys Este archivo es un driver de propósito general proporcionado por Cypress, permite el
acceso al hardware mediante aplicaciones en SDK, es decir, las que no son en modo kernel de Windows.
Para trabajar con este archivo se disponen de tres funciones de API:
• CreateFile: ésta retorna un handle (manejador) de un dispositivo.
• CloseHandle: cierra un handle anteriormente abierto.
• DevideIoControl: esta función implementa todos los tipos de transferencia USB, así como la lectura de sus descriptores, etc.
Para una información más detallada puede referirse al anexo de especificaciones técnicas y leer el documento ‘EZ-USB General Purpose Driver Spec.pdf’
Memoria Descriptiva
52
2.4.2.3 Bibliotecas de Enlace Dinámico
Las bibliotecas de enlace dinámico han sido compiladas en modo SDK, es decir, en modo no kernel. Tienen por objetivo la implementación de un interfaz amigable para la aplicación final, que pretende acceder al hardware.
2.4.2.3.1 InteUSB32.dll
Ilustración 33: Descripción de InteUSB32.dll
En la ilustración anterior se presentan las funciones de la biblioteca ‘InteUSB32.dll’. Esta DLL accede a las API’s proporcionadas por el driver ‘InteDrv.sys’ para implementar la apertura y el cierre del hardware, y también las transferencias de tipo bulk.
En la parte superior proporciona una única función de acceso cuyos parámetros son el número de operación que se pretende realizar con el hardware y el buffer de lectura y el des escritura. El driver ‘InteDrv.sys’ tiene las característica que debe conocerse el tamaño de información a leer antes de realizar la escritura. Esta situación es razonable, ya que el host (PC) es el master del bus, es decir, el que toma la iniciativa y en todo momento sólo él sabe lo que quiere leer, o lo que es lo mismo, cuan grande será la respuesta.
Memoria Descriptiva
53
2.4.2.3.2 InteDrv32.dll
Ilustración 34: Descripción de InteDrv32.dll
Esta DLL es el mayor grado de abstracción. Por debajo accede a la DLL descrita anteriormente, con la función ‘Connecta’, por arriba proporciona la función ‘GetR’. Los parámetros de esta función son la carta y el borne de un extremo de medida, la carta y el borne del otro extremo de medida y retorna el valor de la medida realizada mediante un puntero a un ‘double’.
Obsérvese que de cara al programador final, el que realiza la aplicación ejecutable, se le proporciona un interfaz muy amigable y sencillo, las dos cartas bornes y el resultado. Esta DLL también implementa un gran número de funciones para la comprobación de la continuidad del cableado, pero no se han descrito aquí porque los algoritmos no los desarrolló el autor de este proyecto.
Memoria Descriptiva
54
2.4.2.4 Aplicación ProvaR.exe
Para ejemplificar el potencial de sistema se presenta una aplicación basada en un diálogo, con algunas de las opciones posibles de medida de resistencias. En las siguientes ilustraciones se pueden apreciar las capturas del programa.
Ilustración 35: Mediaciones de ProvaR.exe
En la parte superior izquierda se puede apreciar un cuadro de texto de sólo lectura que dice TVIR POS, esto es la posición de la TVIR dentro del equipo. De forma análoga también podemos identificar TCA POS que es la posición inicial de las TCA’s y el número que hay presente TOT. Estos valores se almacenan en un archivo de configuración, que se carga en la inicialización, llamado HETOS.ini.
A continuación podemos identificar la carta borne A y la carta borne B, que son los puntos sobre los que se realizan la medida. Son cuadros de texto en los que se puede escribir cualquier valor dentro de los permitidos
La fila de botones son las funciones implementadas por la aplicación. Primero esta la mediada de una sola muestra, que correspondería a una llamada a la función ‘GetR’ descrita anteriormente. Este caso se puede apreciar en la ilustración de la izquierda, donde se puede apreciar que se han realizado 8 operaciones de este tipo con diferentes valores de cartas bornes.
En la ilustración de la derecha se ha realizado la medida de 20 adquisiciones sobre una misma carta borne, la aplicación muestra un diálogo con la media aritmética de las 20 muestras y con el valor superior e inferior.
Memoria Descriptiva
55
Ilustración 36: Medida con patrón de ProvaR.exe
En esta última pantalla captura se presenta el proceso de calibración del sistema y comprobación de todos los puntos de test. Consiste en un conjunto de resistencia metálicas del 1% de tolerancia distribuidas como se presenta el la columna de ‘Real value’, este conjunto es leído y presentado en la columna de ‘Measured value’ y finalmente se presenta el porcentaje de error en la columna de ‘Error’. Obsérvese que el error siempre es inferior al 5% que era la especificación deseada.
El sistema permite ser calibrado mediante un offset de resistencia que se resta a cualquier valor leído, este valor viene dado por el archivo de configuración HETOS.ini. Esto es necesario debido a la existencia de numerosos conmutadores analógico en la ruta de mediación, pero sólo es significativo para valores de medida bajos.
Memoria Descriptiva
56
2.4.3 Especificaciones del sistema El sistema de adquisición de datos presentado presenta las especificaciones
siguientes:
Mínimo Máximo
Numero de tarjetas TCA 1 62
Número de puntos de test analógicos
56 3472
Numero de tarjetas TD (Tarjeta digital)
1 63
Número de puntos de test digitales
64 4032
Resolución en bits 12 16
Margen de medición en Ω 10 10 M
Error de medida - 5%
Tabla 6: Especificaciones del sistema
Sistema Modular de Adquisición de Datos
3 Pliego de Condiciones
AUTOR: Raúl Bartolomé Castro.
DIRECTOR Alfonso Romero Nevado.
FECHA: Octubre / 2004.
Pliego de Condiciones
59
3.1 Condiciones Generales
3.1.1 Introducción El presente proyecto desarrolla un osciloscopio para Windows 95 utilizando el
puerto serie.
Dada la condición de "Final de carrera" del proyecto, las consideraciones de tipo contractual poseen un carácter de suposición.
El presente pliego de Condiciones tiene por objeto definir al contratista el alcance del trabajo y la ejecución cualitativa del mismo.
El alcance del trabajo del Contratista incluye el diseño y preparación de todos los planos, diagramas, lista de material y requisitos para la adquisición e instalación del trabajo.
3.1.2 Reglamentos y Normas Todas las unidades de obra se ejecutaran cumpliendo las prescripciones indicadas
en los Reglamentos de Seguridad y Normas Técnicas de obligado cumplimiento para este tipo de instalaciones, tanto de ámbito nacional, autonómico como municipal, así como todas las otras establecidas en el proyecto.
Se adaptarán además, a las presentes condiciones particulares que complementarán las indicadas por los Reglamentos y Normas citadas.
3.1.3 Materiales Todos los materiales empleados serán de primera calidad, cumplirán las
especificaciones y tendrán las características indicadas en el proyecto y en las normas técnicas generales.
Toda especificación o característica de materiales que figuren en uno solo de los documentos del Proyecto, aún sin figurar en los otros es igualmente obligatoria.
En caso de existir contradicción u omisión en los documentos del proyecto, el contratista obtendrá la obligación de ponerlo de manifiesto al Técnico Director de la obra, quien decidirá sobre el particular. En ningún caso podrá suplir la falta directamente, sin la autorización expresa.
No podrá utilizarse materiales que no hayan sido aceptados por el director Técnico.
Pliego de Condiciones
60
3.1.4 Ejecución del proyecto Comienzo. El contratista dará comienzo al proyecto en el plazo que figure en el
contrato establecido con la Propiedad, o en su defecto a los quince días de la adjudicación definitiva de la obra.
El contratista está obligado a notificar por escrito al Técnico director la fecha de comienzo de los trabajos.
Plazo de ejecución. La obra se ejecutará en el plazo que se estipule en el contrato suscrito con la Propiedad o en su defecto en el que figure en las condiciones de este pliego.
Cuando el ritmo de trabajo establecido por el contratista, no sea el normal, o bien a petición de una de las partes, se podrá convenir una programación de inspecciones obligatorias de acuerdo con el plan de obra.
Libro de órdenes. El contratista dispondrá en la realización de proyecto de un Libro de Ordenes en el que se escribirán las que el Técnico Director estime darle a través del encargado o persona responsable, sin perjuicio de las que le dé por oficio cuando lo crea necesario y que tendrá la obligación de firmar el enterado.
3.1.5 Interpretación y Desarrollo El Director Técnico es la persona a quien le corresponde interpretar los documentos
del proyecto, a él se le tiene que someter cualquier duda, aclaración o contradicción que surja durante la ejecución de la obra, siempre con la suficiente antelación en función de la importancia del asunto.
El contratista se hace responsable de cualquier error de la ejecución motivado por la no consulta y consecuentemente deberá rehacer a su costa los trabajos que correspondan a la correcta interpretación del Proyecto.
El contratista ha de hacer todo los necesario para la buena ejecución de la obra, aún cuando no se halla expresado en el proyecto.
El contratista ha de notificar por escrito o personalmente al director de obra, las fechas en que quedarán preparadas para inspección, cada una de las partes del proyecto o para aquellas que, total o parcialmente deban posteriormente quedar ocultas.
3.1.6 Trabajos y Complementos El contratista ha de realizar todas los trabajos complementarios necesarios para
ejecutar el proyecto tal y como estaba previsto, aunque en él no figuren explícitamente dichos trabajos complementarios. Todo ello sin variación del importe contratado.
Pliego de Condiciones
61
3.1.7 Modificaciones El contratista está obligado a realizar las variaciones (ampliaciones, reducciones o
modificaciones) del proyecto siempre que estas no supongan una variación sobre el global proyectado superior al 25%.
Si el contratista, desea realizar alguna modificación, deberá darla a conocer por escrito al Técnico Director, si se considera razonable y se acepta, será confirmada por escrito, así como las nuevas condiciones económicas que mutuamente se acuerden. Si lo anterior no se da como se especifica, no se aceptará modificación alguna.
La valoración se hará de acuerdo, con los valores establecidos en el presupuesto por el Contratista y que ha sido tomado como base del contrato.
3.1.8 Realización Defectuosa Cuando el contratista halle cualquier unidad de trabajo que no se ajuste a lo
especificado en el proyecto o en este Pliego de Condiciones, el Técnico Director podrá aceptarlo o rechazarlo, en el primer caso, éste fijará el precio que crea justo con arreglo a las diferencias que hubiera, estando obligado el Contratista a acatar dicha valoración, en el otro caso, se reconstruirá a expensas del Contratista la parte mal ejecutada sin que ello sea motivo de reclamación económica o de ampliación del plazo de ejecución.
3.1.9 Medios Auxiliares Serán de cuenta del Contratista todos los medios y máquinas auxiliares que sean
precisas para la ejecución del proyecto. En el uso de los mismos estará obligado a hacer cumplir todos los Reglamentos de Seguridad en el trabajo vigentes y a utilizar los medios de protección a sus operarios.
3.1.10 Recepción del Proyecto Recepción provisional. Una vez terminadas los trabajos, tendrá lugar la recepción
provisional y para ello se practicará en ellas un detenido reconocimiento por el Técnico Director y la Propiedad en presencia del Contratista, levantando acta y empezando a correr desde ese día el plazo de garantía si se hallan en estado de ser admitidos.
De no ser admitidos se hará constar en el acta y se darán instrucciones al Contratista para subsanar los defectos observados, fijándose un plazo para ello, expirando el cual se procederá a un nuevo reconocimiento a fin de proceder a la recepción provisional.
Plazo de garantía. El plazo de garantía será como mínimo de un año, contando desde la fecha de la recepción provisional, o bien el que se establezca en el contrato también contado desde la misma fecha. Durante este período queda a cargo del Contratista la conservación del sistema y arreglo de los desperfectos causados por mala construcción.
Recepción definitiva. Se realizará después de transcurrido el plazo de garantía de igual forma que la provisional. A partir de esta fecha cesará la obligación del Contratista de conservar y reparar a su cargo los desperfectos, si bien subsistirán las responsabilidades que pudiera tener por defectos ocultos y deficiencias de causa dudosa.
Pliego de Condiciones
62
3.1.11 Responsabilidades El contratista es responsable de la ejecución de los trabajos como fija el proyecto, y
tendrá que reconstruir toda parte que no se ajuste al programa, sin servir de excusa la razón de que el director de obra haya examinado y reconocido la obra.
El contratista es el único responsable de los posibles fallos cometidos por él o su personal, así como de los accidentes o perjuicios producidos a la propiedad, vecinos o terceros a causa de la inexperiencia o métodos inadecuados.
El contratista es el único responsable del incumplimiento de las disposiciones vigentes en la materia laboral respecto de su personal y por tanto los accidentes que puedan sobrevenir y de los derechos que puedan derivarse de ellos.
3.1.12 Fianza En el contrato se establecerá la fianza que el contratista deberá depositar en garantía
del cumplimiento del mismo, o, se convendrá una retención sobre los pagos realizados a cuenta del trabajo ejecutado.
De no estipularse la fianza en el contrato se entiende que se adopta como garantía una retención del 5% sobre los pagos a cuenta citados.
En el caso de que el Contratista se negase a hacer por su cuenta los trabajos para ultimar el proyecto en las condiciones contratadas, o a atender la garantía, la Propiedad podrá ordenar ejecutarlas a un tercero, abonando su importe con cargo a la retención o fianza, sin perjuicio de las acciones legales a que tenga derecho la Propiedad si el importe de la fianza no bastase.
La fianza retenida se abonará al Contratista en un plazo no superior a treinta días una vez firmada el acta de recepción definitiva de la obra.
Pliego de Condiciones
63
3.2 Condiciones Técnicas
3.2.1 Condiciones de las Placas de CI Las placas de circuito impreso, deberán ser diseñadas por el fabricante bajo las
siguientes normas:
- Ancho de las pistas de señal: 0.5 mm. - Ancho de las pistas de alimentación: 2 mm. - Osciladores de cuarzo tumbados sobre plano de masa. - Los condensadores de desacoplo deberán ir situados lo más cerca posible del
pin de alimentación. - Dimensiones de los taladros:
• 1 mm para los circuitos integrados y componentes discretos. • 1.25 mm para regletas y reguladores de tensión. • 3.2 mm para los tornillos de los disipadores. • 4 mm para los taladros de sujeción de la placa.
Todas las placas una vez salidas de producción deberán ser testeadas, de tal forma que el índice de fallos en pistas, sea inferior al 1%.
3.2.2 Condiciones de los Componentes Electrónicos La premisa básica a seguir en la compra de los componentes electrónicos, es buscar
componentes de marcas de reconocido prestigio y que posean un índice de rechazo en producción, inferior al 20%.
Así por ejemplo, se recomienda la utilización de componentes de la firma MOTOROLA o cualquiera de sus subsidiaras (RCA. AMD) que hasta la fecha han demostrado un muy alto grado de fiabilidad de los componentes suministrados.
No se recomienda recurrir bajo ningún concepto a las pleyades de fabricantes de Oriente que han surgido en Corea, Singapur, Malasia, etc., puesto que en anteriores producciones han puesto de manifiesto un bajísimo grado de fiabilidad, dándose el caso de encontrar partidas enteras de componentes que a los 6 meses de funcionamiento han fallado íntegramente.
3.2.3 Condiciones del Montaje de Placas El montaje de placas deberá ser realizado por inserción automatizada, puesto que el
índice de errores es prácticamente nulo, no así cuando se recurre al montaje manual de componentes.
La soldadura de las placas debe ser realizada por ola, con estaño de buena calidad, y una vez finalizado el proceso, las placas deben ser perfectamente limpias con algún producto específico basado en flúor de los muchos que hay disponibles en el mercado.
De cada partida de placas producidas, al menos lo de ellas deberán ser verificadas en horno a 40 grados centígrados y en funcionamiento de tal forma que se les proporcione el equivalente a 6 meses de funcionamiento ininterrumpido durante las pruebas, sea superior al 20%, la partida entera deberá ser retirada y sustituida por una nueva.
Pliego de Condiciones
64
3.3 Condiciones Facultativas
3.3.1 Normas a Seguir El diseño de la instalación eléctrica estará de acuerdo con las exigencias o
recomendaciones expuestas en la última edición de los siguientes códigos:
- Reglamento Electrotécnico de Baja Tensión e Instrucciones complementarias. - Normativa UNE. - Normativa DIN. - Plan nacional y ordenanza general de Seguridad e Higiene en el trabajo. - Normas de la Compañía Suministradora. - Publicaciones del Comité Electrotécnico Internacional (CEI). - Lo indicado en este pliego de condiciones con preferencia a todos los códigos y
normas.
3.3.2 Personal El Contratista tendrá al frente de la obra un encargado con autoridad sobre los
demás operarios y conocimientos acreditados y suficientes para la ejecución del proyecto.
El encargado recibirá, cumplirá y transmitirá las instrucciones y órdenes del Técnico Director de la obra.
El Contratista tendrá el número y clase de operarios que haga falta para el volumen y naturaleza de los trabajos que se realicen, los cuales serán de reconocida aptitud y experimentados en el oficio. El Contratista estará obligado a separar de la realización del proyecto, a aquel personal que a juicio del Técnico Director no cumpla con sus obligaciones, realice el trabajo defectuosamente, bien por falta de conocimientos o por obrar de mala fe.
3.3.3 Reconocimiento de Ensayos Previos Cuando lo estime oportuno el Técnico Director, podrá encargar y ordenar el
análisis, ensayo o comprobación de los materiales, elementos o instalaciones, bien sea en fábrica de origen, laboratorios oficiales o en la misma obra, según crea más conveniente, aunque estos no estén indicados en este pliego.
En el caso de discrepancia, los ensayos o pruebas se efectuarán en el laboratorio oficial que el Técnico Director de obra designe.
Los gastos ocasionados por estas pruebas y comprobaciones, serán por cuenta del Contratista.
Pliego de Condiciones
65
3.3.4 Ensayos Antes de la puesta en servicio del sistema eléctrico, el Contratista habrá de hacer
los ensayos adecuados para probar, a la entera satisfacción del Técnico Director del proyecto, que todo el equipo, aparatos y cableado han sido instalados correctamente de acuerdo con las normas establecidas y están en condiciones satisfactorias para le funcionamiento.
Todos los ensayos serán presenciados por el Ingeniero que representa el Técnico Director de obra.
Los resultados de los ensayos serán pasados en certificados indicando fecha y nombre de la persona a cargo del ensayo, así como categoría profesional.
Los cables, antes de ponerse en funcionamiento, se someterán a un ensayo de resistencia de aislamiento entre fase y tierra.
3.3.5 Ensayos de Aparellaje Antes de poner el aparellaje bajo tensión, se medirá la resistencia de aislamiento de
cada equipo entre fases y tierra.
Las medidas deben repetirse con los interruptores en posición de funcionamiento.
Todo relé de protección que sea ajustable será calibrado y ensayado, usando contador de ciclos, caja de carga, amperímetro y voltímetro, según se necesite.
Se dispondrá, en lo posible, de un sistema de protección selectiva. De acuerdo con esto, los relés de protección se elegirán y coordinarán para conseguir un sistema que permita actuar primero el dispositivo de interrupción más próximo a la falta.
Todos los interruptores automáticos se colocarán en posición de prueba y cada interruptor será cerrado y disparado desde su interruptor de control. Los interruptores deben ser disparados por accionamiento manual y aplicando corriente a los relés de protección. Se comprobarán todos los enclavamientos.
Pliego de Condiciones
66
3.4 Condiciones Económicas
3.4.1 Precios El contratista presentará, al formalizarse el contrato, relación de los precios de las
unidades de trabajo que integran el proyecto, los cuales de ser aceptados tendrán valor contractual y se aplicarán a las posibles variaciones que puedan haber.
Estos precios unitarios, se entiende que comprenden la ejecución total de la unidad del proyecto, incluyendo todos los trabajos aún los complementarios y los materiales así como la parte proporcional de imposición fiscal, las cargas laborales y otros gastos repercutibles.
En caso de tener que realizarse unidades de trabajo no prevista en el proyecto, se fijará su precio entre el Técnico Director y el Contratista antes de iniciar la obra y se presentará a la propiedad para su aceptación o no.
3.4.2 Abono del Proyecto En el contrato se deberá dejar detalladamente la forma y plazas que se abonarán las
partes del proyecto. Las liquidaciones parciales que puedan establecerse tendrán carácter de documentos provisionales a buena cuenta, sujeto a las certificaciones que resulten de la liquidación final. No suponiendo, dichas liquidaciones, aprobación ni recepción de las obras que comprenden.
Terminadas las obras se procederá a la liquidación final que se efectuará de acuerdo con los criterios establecidos en el contrato.
3.4.3 Revisión de Precios En el contrato se establecerá si el contratista tiene derecho a revisión de precios y la
fórmula a aplicar para calcularla. En defecto de esta última, se aplicará a juicio del Técnico Director alguno de los criterios oficiales aceptados.
3.4.4 Penalizaciones Por retraso en los plazos de entrega de las obras, se podrán establecer tablas de
penalización cuyas cuantías y demoras se fijarán en el contrato.
3.4.5 Contrato El contrato se formalizará mediante documento privado, que podrá elevarse a
escritura a petición de cualquiera de las partes. Comprenderá la adquisición de todos los materiales, transporte, mano de obra, medios auxiliares para la ejecución de la obra proyectada en el plazo estipulado, así como la reconstrucción de las unidades defectuosas, la realización de las obras complementarias y las derivadas de las modificaciones que se introduzcan durante la ejecución, éstas últimas en los términos previstos.
La totalidad de los documentos que componen el Proyecto técnico de la obra serán incorporados al contrato y tanto el contratista como la Propiedad deberán firmarlos en testimonio de que los conocen y aceptan.
Pliego de Condiciones
67
3.4.6 Rescisión del Contrato Causas de rescisión: Se consideran causas suficientes para la rescisión del contrato
las siguientes:
1- Muerte o incapacitación del Contratista. 2- La quiebra del contratista. 3- Modificación del proyecto cuando produzca alteración en más o menos 25% del
valor contratado. 4- Modificación de las unidades de obra en número superior al 40% del original. 5- La no iniciación de los trabajos en el plazo estipulado cuando sea por causas ajenas
a la Propiedad. 6- La suspensión de las obras ya iniciadas siempre que el plazo de suspensión sea
mayor de seis meses. 7- Incumplimiento de las condiciones del Contrato cuando implique mala fe. 8- Terminación del plazo de ejecución de la obra sin haberse llegado a completar ésta. 9- Actuación de mala fe en la ejecución de los trabajos. 10- Destajar o subcontratar la totalidad o parte de los trabajos a terceros sin la
autorización del Técnico Director y la propiedad.
3.4.7 Liquidación en el Caso de Rescisión del Contrato Siempre que se rescinda el contrato por causas anteriores o bien por acuerdo de
ambas partes, se abonará al Contratista las unidades del proyecto ejecutado y los materiales acopiados que reúnan las condiciones y sean necesarios para el mismo.
Cuando se rescinda el contrato llevará implícito la retención de la fianza para obtener los posibles gastos de conservación de el período de garantía y los derivados del mantenimiento hasta la fecha de nueva adjudicación.
Sistema Modular de Adquisición de Datos
4 Anexo: Especificaciones Técnicas
AUTOR: Raúl Bartolomé Castro.
DIRECTOR Alfonso Romero Nevado.
FECHA: Octubre / 2003.
Anexo: Especificaciones
70
4.1 Circuitos Integrados
4.1.1 Conmutadores Analógicos
DG441 DG442.pdf
MAX312 MAX313 MAX314.pdf
4.1.2 Buffers Transceivers
74abt245.pdf
74HC_HCT245.pdf
4.1.3 Convertidores AD
AD7943 AD7945 AD7948.pdf
4.1.4 Convertidores DA
ADS7806P .pdf
ADS7807P .pdf
4.1.5 Dispositivos Lógicos Programables (PLD)
Max3000.pdf
Max7000.pdf
4.1.6 Lógica Digital
4.1.6.1 Decodificadores
MC54HC138A MC74HC138A.pdf
74HC_HCT154.pdf
Anexo: Especificaciones
71
4.1.6.2 Flip-Flops
MM74HC273.pdf
74hc273.pdf
4.1.7 Inter-Integrated Circuit (I2C)
4.1.7.1 EEPROM
ST24_25C01 ST24C01R.pdf
4.1.7.2 Sensor Digital de Temperatura
Lm75.pdf
4.1.8 Reguladores Lineales
TI TPS75101Q TPS75115Q TPS75118Q TPS75125Q TPS75133Q.pdf
MOT MC70M00 MC70M00A.pdf
MOT MC7800 MC7800A LM340 LM340A.pdf
4.1.9 Microcontroladores
Ez-usb.pdf
4.1.10 Memoria
A61L5308 series.pdf
AS7C256 AS7C3256.pdf
IDT71V256SA.pdf
Anexo: Especificaciones
72
4.1.11 Amplificadores Operacionales
4.1.11.1 Amplificador Operación de Precisión
Opa177.pdf
4.1.11.2 Amplificadores de Instrumentación
PGA204 PGA205.pdf
4.1.12 Diodos
4.1.12.1 Generales
1N4004 1N4007.pdf
4.1.12.2 Diodos de Voltaje de Referencia
Ref01.pdf
Ref02.pdf
4.1.12.3 Diodos Emisores de Luz (LED)
HLMP-5029.pdf
Anexo: Especificaciones
73
4.2 Componentes Pasivos
4.2.1 Condensadores
AVX Cerámicos.pdf
AVX Tántalo.pdf
Panasonic Electrolytic.pdf
4.2.2 Resistencias
General Purpose Surface Resistor.pdf
BOURNS Resistor Networks.pdf
BOURNS Trimmers.pdf
Anexo: Especificaciones
74
4.3 Conectores
4.3.1 USB
USB A.pdf
USB B.pdf
4.3.2 DIN41612
TB_0903264x825_BL01_R30815.pdf
TB_0903196x921_BL01_R27479.pdf
4.3.3 IDC
IDC 3M.pdf
IDC 3M 2.pdf
4.4 Software
4.4.1 Especificaciones USB 1.1.
USB Specification.pdf
4.4.2 EZ-USB Especificaciones del GPD
EZ-USB General Purpose Driver Spec.pdf
Anchor Firmware FW.pdf
Sistema Modular de Adquisición de Datos
5 Anexo: Bibliografía
AUTOR: Raúl Bartolomé Castro.
DIRECTOR Alfonso Romero Nevado.
FECHA: Octubre / 2003.
Anexo: Bibliografía
76
5.1 Diseño electrónico Luis Martínez Salamero, Alberto Poveda López, Luis García de Vicuña, Frances Guinjoan Gispert, Antonio F. Sánchez García y Frances J. Sánchez Robert.
Funcions electròniques
Edicions UPC
C. J. Savant, Jr, Martin S. Roden, Gordon L. Carpenter
Diseño electrónico
Addison-Wesley Iberoamericana
5.2 Especificaciones esenciales Compaq, Intel, Microsoft, NEC
Universal Serial Bus Specification
Revision 1.1, September 23, 1998
Altera
MAX 3000A Programmable Logis Device Family
September 2000, ver. 1.1
http://www.altera.com/
Altera
MAX 7000 Programmable Logis Device Family
August 2000, ver. 6.02
http://www.altera.com/
Cypress Semiconductor
EZ-USB Technical Reference Manual
Version 1.1
http://www.cypress.com/
Burr-Brown
ADS7806 Low-Power 12-Bit Sampling CMOS ANALOG-to-DIGITAL CONVERTER
November 1994
http://www.burr-brown.com/
Anexo: Bibliografía
77
Analog Devices
AD7943 AD7945 AD7948 +3.3V / +5V Multiplying 12-Bit DACs
REV A, 1998
http://www.analog.com/
5.3 Proyectos Raúl Bartolomé Castro, director Ernest Gil i Dolcet
Osciloscopio para Win95 mediante puerto serie Proyecto Final de Carrera de Ingeniería Técnica Industrial en Electrónica Industrial
Pere Miquel Guiu i Arbonés, director Ernest Gil i Dolcet
Analitzador lògic suportat per PC
Proyecto final de Carrera, Setembre 2001
5.4 Páginas WEB Organización USB: http://www.usb.org/home
Compilador C para 8051: http://www.keil.com/
Top Related