Selected:

Sistema Modular de Adquisición de Datos

9,99

9,99

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.

La descarga include la siguiente información: memoria del proyecto en formato pdf y docx (el código fuente está presente en los apéndices), presentación en formato pptx y todo los datasheets relevantes para el diseño electrónico.

  • Fecha: Enero 2004 – Septiembre 2004
  • Autor: Raúl Bartolomé Castro
  • Director: Alfonso Romero Nevado
  • Estudio: Ingeniería en Automática y Electrónica Industrial
  • Asignatura: Proyecto Final de Carrera

Description

Índice de Contenidos

1 Índice 2

1.1 Índice de Contenidos 3

1.2 Índice de Ilustraciones 12

1.3 Índice da Tablas 15

2 Memoria Descriptiva 16

2.1 Introducción 17

2.1.1 Contexto 17

2.1.1.1 Sistema de Comprobación ISA (INTE ISA) 17

2.2 Objetivos 19

2.2.1 Sistema de Comprobación USB (INTE USB) 19

2.2.2 Sistema de Adquisición de Datos USB (AINTE USB) 21

2.3 El bus USB 22

2.3.1 Introducción 22

2.3.2 Características generales 22

2.3.2.1 USB 1.0 23

2.3.2.2 USB 1.1 23

2.3.3 Especificaciones técnicas 24

2.3.3.1 Topología 24

2.3.3.2 El flujo de datos 29

2.3.3.3 Protocolo 34

2.3.3.4 Características eléctricas 42

2.4 Descripción general 45

2.4.1 Hardware 46

2.4.1.1 El sistema modular 47

2.4.1.2 Subsistema de control y comunicaciones USB 48

2.4.1.3 Subsistema de medida 49

2.4.1.4 Subsistema de conmutación 53

2.4.2 Software 55

2.4.2.1 Enumeración 57

2.4.2.2 Archivos de sistema 58

2.4.2.3 Bibliotecas de Enlace Dinámico 59

2.4.2.4 Aplicación ProvaR.exe 61

2.4.3 Especificaciones del sistema 63

3 Memoria de Cálculo 64

3.1 Hardware 65

3.1.1 Tarjeta de Enlace (TE) 65

3.1.1.1 Arquitectura 65

3.1.2 Tarjeta Base de Control USB (TBCU) 66

3.1.2.1 Arquitectura 66

3.1.2.2 Microcontrolador 68

3.1.2.3 Dispositivo Lógico Programable (PLD) 70

3.1.2.4 Interfaz con Tarjetas de Enlace 74

3.1.3 Tarjeta de medida de Voltaje Intensidad y Resistencia (TVIR) 75

3.1.3.1 Arquitectura 75

3.1.3.2 Control Digital (DC) 78

3.1.3.3 Fuente de Alimentación (PS) 83

3.1.3.4 Conversor Analógico Digital (ADC) 85

3.1.3.5 Amplificadores de Ganancia Programable (PGA) 87

3.1.3.6 Conmutación Analógica (AS) 89

3.1.3.7 Fuente de Corriente (CS) 90

3.1.3.8 Conversor Digital Analógico (DAC) 94

3.1.4 Tarjeta de Conmutación Analógica (TCA) 95

3.1.4.1 Arquitectura 95

3.1.4.2 Control Digital (DC) 97

3.1.4.3 Conmutación Analógica (AS) 100

3.1.4.4 Memoria de Conmutación (SM) 101

3.2 Software 102

3.2.1 Programa de la Tarjeta de Control USB (FirmwareTBCU.hex) 102

3.2.1.1 Visión global 102

3.2.1.2 Código específico 104

3.2.2 Biblioteca de Enlace Dinámico (InteUSB32.dll) 106

3.2.3 Biblioteca de Enlace Dinámico (InteDrv32.dll) 109

3.2.3.1 Esquemas de medición 112

3.2.4 Aplicación (ProvaR.exe) 119

4 Planos 123

4.1 Tarjeta de Enlace (TE) 124

4.1.1 Fotografía 124

4.1.2 Esquema 125

4.1.3 PCB: Componentes 126

4.1.4 PCB: Cara Inferior 127

4.1.5 Lista de Materiales 128

4.1.5.1 Elementos Pasivos 128

4.2 Tarjeta Base de Control USB (TBCU) 129

4.2.1 Fotografía 129

4.2.2 Esquema: USB y Control 130

4.2.3 Esquema: Cabecera de Bus 131

4.2.4 Implementación PLD 132

4.2.5 PCB: Componentes 133

4.2.6 PCB: Cara Superior 134

4.2.7 PCB: Cara Inferior 135

4.2.8 Lista de Materiales 136

4.2.8.1 Semiconductores y Optoelectrónica 136

4.2.8.2 Elementos Pasivos. 137

4.3 Tarjeta de medida de Voltaje Intensidad y Resistencia (TVIR) 138

4.3.1 Fotografía 138

4.3.2 Esquema: Control 139

4.3.3 Esquema: Conversor AD 140

4.3.4 Esquema: Amplificadores de Ganancia Programable 141

4.3.5 Esquema: Conversor DA 142

4.3.6 Esquema: Fuente de Corriente 143

4.3.7 Esquema: Conmutación Analógica 144

4.3.8 Esquema: Energía 145

4.3.9 Implementación PLD 146

4.3.10 PCB: Componentes 148

4.3.11 PCB: Cara Superior 149

4.3.12 PCB: Cara Inferior 150

4.3.13 Lista de Materiales 151

4.3.13.1 Semiconductores y Optoelectrónica 151

4.3.13.2 Elementos pasivos 152

4.4 Tarjeta de Conmutación Analógica (TCA) 153

4.4.1 Fotografía 153

4.4.2 Esquema: Control 154

4.4.3 Esquema: Memoria 155

4.4.4 Esquema: Conmutación Analógica 156

4.4.5 Implementación PLD 157

4.4.6 PCB: Componentes 158

4.4.7 PCB: Cara Superior 159

4.4.8 PCB: Cara Inferior 160

4.4.9 Lista de Materiales 161

4.4.9.1 Semiconductores y Optoelectrónica 161

4.4.9.2 Elementos Pasivos 162

5 Presupuesto 163

5.1 Tarjeta de Enlace (TE) 164

5.1.1 Requerimientos de Materiales 164

5.1.2 Precios Unitarios 164

5.1.3 Escandallo 164

5.2 Tarjeta Base de Control USB (TBCU) 165

5.2.1 Requerimientos de Materiales 165

5.2.2 Precios Unitarios 167

5.2.3 Escandallo 169

5.3 Tarjeta de medida de Voltaje Intensidad y Resistencia (TVIR) 171

5.3.1 Requerimientos de Materiales 171

5.3.2 Precios Unitarios 174

5.3.3 Escandallo 177

5.4 Tarjeta de Conmutación Analógica (TCA) 180

5.4.1 Requerimientos de Materiales 180

5.4.2 Precios Unitarios 181

5.4.3 Escandallo 182

5.5 Rack A 183

5.5.1 Requerimientos de Materiales 183

5.5.2 Precios Unitarios 183

5.5.3 Escandallo 183

5.6 Diseño del software 184

5.6.1 Requerimientos de tiempo 184

5.6.2 Precio Unitario 184

5.6.3 Escandallo 184

5.7 Resumen del presupuesto 185

6 Pliego de Condiciones 186

6.1 Condiciones Generales 187

6.1.1 Introducción 187

6.1.2 Reglamentos y Normas 187

6.1.3 Materiales 187

6.1.4 Ejecución del proyecto 188

6.1.5 Interpretación y Desarrollo 188

6.1.6 Trabajos y Complementos 188

6.1.7 Modificaciones 189

6.1.8 Realización Defectuosa 189

6.1.9 Medios Auxiliares 189

6.1.10 Recepción del Proyecto 189

6.1.11 Responsabilidades 190

6.1.12 Fianza 190

6.2 Condiciones Técnicas 191

6.2.1 Condiciones de las Placas de CI 191

6.2.2 Condiciones de los Componentes Electrónicos 191

6.2.3 Condiciones del Montaje de Placas 191

6.3 Condiciones Facultativas 192

6.3.1 Normas a Seguir 192

6.3.2 Personal 192

6.3.3 Reconocimiento de Ensayos Previos 192

6.3.4 Ensayos 193

6.3.5 Ensayos de Aparellaje 193

6.4 Condiciones Económicas 194

6.4.1 Precios 194

6.4.2 Abono del Proyecto 194

6.4.3 Revisión de Precios 194

6.4.4 Penalizaciones 194

6.4.5 Contrato 194

6.4.6 Rescisión del Contrato 195

6.4.7 Liquidación en el Caso de Rescisión del Contrato 195

7 Anexo: Código Fuente 196

7.1 InteUSB.inf 197

7.2 InteLdr.sys 200

7.2.1 Ezloader.h 200

7.2.2 Ezloader.c 204

7.2.3 Loader.h 204

7.2.4 firmware.h 205

7.2.5 hex.dat 205

7.2.6 Resource.h 205

7.3 InteDrv.sys 206

7.3.1 Ezusbsys.h 206

7.3.2 Ezusbsys.c 223

7.3.3 Version.h 223

7.3.4 Resource.h 223

7.4 FirmwareTBCU.hex 224

7.4.1 Fw.c 224

7.4.2 Periph.c 230

7.4.3 Com.h 233

7.4.4 Com.c 234

7.4.5 Param.h 237

7.4.6 Param.c 238

7.4.7 Inte.h 240

7.4.8 Inte.c 241

7.4.9 Inte1.h 248

7.4.10 Inte1.c 249

7.4.11 Inte2.h 252

7.4.12 Inte2.c 253

7.4.13 Inte4.h 258

7.4.14 Inte4.c 259

7.4.15 Born.h 262

7.4.16 Pack.h 263

7.4.17 Pack.c 263

7.4.18 Pause.h 264

7.4.19 Pause.c 264

7.4.20 SByte.h 265

7.4.21 Sword.h 265

7.4.22 Temp.h 266

7.4.23 Temp.c 267

7.4.24 Dscr.a51 270

7.4.25 JmpTB.a51 275

7.4.26 Led.h 276

7.4.27 Led.c 277

7.4.28 LocalDefines.h 281

7.4.29 Tracer.h 281

7.4.30 Tracer.c 281

7.4.31 EZRegs.h 285

7.4.32 EZusb.h 293

7.5 InteUSB32.dll 299

7.5.1 InteUSB.hpp 299

7.5.2 InteUSB.cpp 300

7.5.3 InteUSB32.h 303

7.5.4 InteUSB32.cpp 304

7.5.5 InteUSB32.def 306

7.5.6 StdAfx.h 306

7.5.7 StadAfx.cpp 307

7.5.8 USB.hpp 307

7.5.9 USB.cpp 308

7.5.10 Resource.h 315

7.5.11 Excepcion.hpp 315

7.5.12 TracErr.hpp 316

7.5.13 TracErr.cpp 317

7.5.14 InteUSB32.hpp 320

7.6 InteDrv32.dll 321

7.6.1 Analog.hpp 321

7.6.2 Analog.cpp 322

7.6.3 InteDrv32.hpp 327

7.6.4 InteDrv32.h 327

7.6.5 InteDrv.cpp 328

7.6.6 InteUSB1.cpp 329

7.6.7 InteUSB2.cpp 329

7.6.8 InteUSB3.cpp 332

7.6.9 InteUSB4.cpp 333

7.6.10 InteUSB5.cpp 334

7.6.11 InteUSB6.cpp 336

7.6.12 Resource.h 336

7.6.13 EtdAfx.h 337

7.6.14 EtdAfx.cpp 338

7.6.15 Defines.h 338

7.6.16 InteUSB32.hpp 339

7.6.17 Ordres.h 339

7.6.18 TVIR.h 340

7.6.19 Born.hpp 340

7.6.20 Pack.hpp 341

7.6.21 Pack.cpp 342

7.6.22 SetBool.hpp 346

7.6.23 SetBool.cpp 347

7.6.24 SetBorns.hpp 348

7.6.25 SetBorns.cpp 349

7.6.26 SetByte.hpp 351

7.6.27 SetByte.cpp 352

7.6.28 SetShort.hpp 353

7.6.29 SetShort.cpp 354

7.6.30 SetWord.hpp 355

7.6.31 SetWord.cpp 356

7.6.32 USBParam.hpp 357

7.6.33 USBParam.cpp 358

7.7 ProvaR.exe 363

7.7.1 ProvaR.h 363

7.7.2 ProvaR.cpp 364

7.7.3 IndeDrv32.hpp 365

7.7.4 ProvaRDlg.h 366

7.7.5 ProvaRDlg.cpp 367

7.7.6 Resource.h 376

7.7.7 StdAfx.h 377

7.7.8 StdAfx.cpp 377

8 Anexo: Especificaciones Técnicas 378

8.1 Circuitos Integrados 379

8.1.1 Conmutadores Analógicos 379

8.1.2 Buffers Transceivers 379

8.1.3 Convertidores AD 379

8.1.4 Convertidores DA 379

8.1.5 Dispositivos Lógicos Programables (PLD) 379

8.1.6 Lógica Digital 379

8.1.6.1 Decodificadores 379

8.1.6.2 Flip-Flops 380

8.1.7 Inter-Integrated Circuit (I2C) 380

8.1.7.1 EEPROM 380

8.1.7.2 Sensor Digital de Temperatura 380

8.1.8 Reguladores Lineales 380

8.1.9 Microcontroladores 380

8.1.10 Memoria 380

8.1.11 Amplificadores Operacionales 381

8.1.11.1 Amplificador Operación de Precisión 381

8.1.11.2 Amplificadores de Instrumentación 381

8.1.12 Diodos 381

8.1.12.1 Generales 381

8.1.12.2 Diodos de Voltaje de Referencia 381

8.1.12.3 Diodos Emisores de Luz (LED) 381

8.2 Componentes Pasivos 382

8.2.1 Condensadores 382

8.2.2 Resistencias 382

8.3 Conectores 383

8.3.1 USB 383

8.3.2 DIN41612 383

8.3.3 IDC 383

8.4 Software 383

8.4.1 Especificaciones USB 1.1. 383

8.4.2 EZ-USB Especificaciones del GPD 383

9 Anexo: Bibliografía 384

9.1 Diseño electrónico 385

9.2 Especificaciones esenciales 385

9.3 Proyectos 386

9.4 Páginas WEB 386

Índice de Ilustraciones

Ilustración 1: Sistema de Comprobación ISA 17

Ilustración 2: Tipos de comprobaciones de continuidad 17

Ilustración 3: Sistema de Comprobación USB 19

Ilustración 4: Estructura de capas del bus USB 24

Ilustración 5: Diagrama de capas del USB 24

Ilustración 6: La capa física USB 25

Ilustración 7: HUB USB 27

Ilustración 8: La capa lógica USB 28

Ilustración 9: Relación software cliente y función 28

Ilustración 10: Campo PID 35

Ilustración 11: Campo dirección 35

Ilustración 12: Campo endpoint 35

Ilustración 13: Campo de datos 36

Ilustración 14: Transferencia bula 40

Ilustración 15: Transferencias de control 40

Ilustración 16: Transferencia de interrupción 41

Ilustración 17: Transferencias isócronas 41

Ilustración 18: Identificación de la velocidad del dispositivo 42

Ilustración 19: Codificación de datos NRZI 42

Ilustración 20: Señal Sync 43

Ilustración 21: Descripción general 45

Ilustración 22: Sistema de Adquisición de Datos INTE 46

Ilustración 23: El sistema modular 47

Ilustración 24: Subsistema de control y comunicaciones USB 48

Ilustración 25: Subsistema de medida 49

Ilustración 26: Multímetro de 4 hilos 50

Ilustración 27: Subsistema de medida real 51

Ilustración 28: Medición por divisor de tensión 52

Ilustración 29: Subsistema de conmutación 53

Ilustración 30: Esquema de medición 54

Ilustración 31: Descripción general del software 55

Ilustración 32: Diagrama de bloques simplificado del microcontrolador 56

Ilustración 33: Descripción de InteUSB32.dll 59

Ilustración 34: Descripción de InteDrv32.dll 60

Ilustración 35: Mediaciones de ProvaR.exe 61

Ilustración 36: Medida con patrón de ProvaR.exe 62

Ilustración 37: Arquitectura de TE 65

Ilustración 38: Arquitectura de TBCU 66

Ilustración 39: Microcontrolador 69

Ilustración 40: Dispositivo Lógico Programable 71

Ilustración 41: Implementación de la PLD 1 72

Ilustración 42: Implementación de la PLD 2 73

Ilustración 43: Interfaz con TE 74

Ilustración 44: Arquitectura de TVIR 75

Ilustración 45: Arquitectura definitiva de TVIR 77

Ilustración 46: Control Digital con PLD 79

Ilustración 47: Implementación de la PLD 1 80

Ilustración 48: Implementación de la PLD 2 81

Ilustración 49: Cronograma de lectura del AD 82

Ilustración 50: Fuente de alimentación y referencias de tensión 83

Ilustración 51: Esquema interno del conversor AD 85

Ilustración 52: Conversor Analógico Digital 86

Ilustración 53: Esquema interno del PGA 87

Ilustración 54: Amplificadores de Ganancia Variable 88

Ilustración 55: Conmutación Analógica 89

Ilustración 56: Fuente de Corriente 90

Ilustración 57: Fuente de Howland 91

Ilustración 58: Fuente de corriente de alta precisión 93

Ilustración 59: Esquema interno del conversor DA 94

Ilustración 60: Conversor Digital Analógico 94

Ilustración 61: Arquitectura TCA 95

Ilustración 62: Control Digital 98

Ilustración 63: Implementación de la PLD 99

Ilustración 64: Conmutación Analógica 100

Ilustración 65: Memoria de Conmutación 101

Ilustración 66: FrameWoks de la TBCU 103

Ilustración 67: Firmware específico TBCU 104

Ilustración 68: InitInstance de InteUSB32.dll 106

Ilustración 69: ExitInstance de InteUSB32.dll 106

Ilustración 70: Connecta de InteUSB32.dll 107

Ilustración 71: Transferencia de PC a 8051 108

Ilustración 72: Transferencia de 8051 a PC 108

Ilustración 73: Constructor de cAnalog 109

Ilustración 74: Función GetR 110

Ilustración 75: Medición a cuatro hilos 112

Ilustración 76: Medición a dos hilos 113

Ilustración 77: Esquema electrónico de medida 114

Ilustración 78: Implementación de GetR 115

Ilustración 79: Funciones TCA 118

Ilustración 80: Función Measure 1 119

Ilustración 81: Función Measure N 120

Ilustración 82: Función Test System 121

Índice da Tablas

Tabla 1: PIDs USB 34

Tabla 2: Comportamiento en transferencia IN de endpoint 38

Tabla 3: Comportamiento en transferencia IN de host 38

Tabla 4: Comportamiento en transferencias OUT del host 39

Tabla 5: Cable de velocidad baja 44

Tabla 6: Especificaciones del sistema 63

Tabla 7: Comparación entre el 8051 EZ-USB y algunos competidores 68

Tabla 8: Características de la familia MAX3000 70

Tabla 9: Características de la familia MAX7000 78

Tabla 10: Características de la familia MAX7000 97

Tabla 11: Distribución de TCA 111

Tabla 12: Elementos pasivos TE 128

Tabla 13: Semiconductores y Optoelectrónica TBCU 136

Tabla 14: Elementos Pasivos TBCU 137

Tabla 15: Semiconductores y Optoelectrónica TVIR 151

Tabla 16: Elementos Pasivos TVIR 152

Tabla 17: Semiconductores y Optoelectrónica TCA 161

Tabla 18: Elementos Pasivos TCA 162

Sistema Modular de Adquisición de Datos

Memoria Descriptiva

AUTOR: Raúl Bartolomé Castro.

DIRECTOR: Alfonso Romero Nevado.

FECHA: Octubre / 2004.

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.

Contexto

Sistema de Comprobación ISA (INTE ISA)

Inte

Ilustración : 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:

Sistema%20test

Ilustración : Tipos de comprobaciones de continuidad

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.

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.

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

Sistema de Comprobación USB (INTE USB)

Inte%20USB

Ilustración : 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.

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.

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

El bus USB

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.

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

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.

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.

Especificaciones técnicas

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.

USB%20arquitectura

Ilustración : 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

USB%20diagramacapas

Ilustración : Diagrama de capas del USB

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

USB%20capafisica

Ilustración : 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.

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.

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

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.

USB%20hub

Ilustración : 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.

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.

USB%20capalogica

Ilustración : 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

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.

USB%20csw

Ilustración : Relación software cliente y función

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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

Token

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.

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.

Data

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.

MDATA

1111B

PID de paquete de datos de alta velocidad para split y elevado ancho de banda en una transferencia isócrona.

Handshake

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.

NYET

0110B

Aún no se ha recibido una respuesta del receptor.

Special

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.

Reservad

0000B

PID reservado.

Tabla : PIDs USB

Formato de los campos

Los paquetes se dividen en campos, a continuación se presenta el formato de diferentes campos.

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.

USB%20campopid

Ilustración : Campo PID

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.

USB%20campodireccion

Ilustración : Campo dirección

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.

USB%20campoendpoint

Ilustración : Campo endpoint

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.

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.

USB%20campodatos

Ilustración : Campo de datos

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.

Formato de lo paquetes
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”.

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.

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.

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.

Transacciones

Los paquetes de tipo token tiene como objetivo indicar el inicio de una transacción de datos de una determina forma.

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 : 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 : Comportamiento en transferencia IN de host

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.

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 : Comportamiento en transferencias OUT del host

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.

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.

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.

USB%20bulkesquema

Ilustración : Transferencia bula

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.

USB%20setupesquema

Ilustración : Transferencias de control

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.

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.

USB%20interrupcionesquema

Ilustración : Transferencia de interrupción

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.

USB%20isoesquema

Ilustración : Transferencias isócronas

Características eléctricas

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.

USB%20identificacion

Ilustración : 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.

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:

USB%20nrzi

Ilustración : Codificación de datos NRZI

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.

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:

USB%20sync

Ilustración : 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.

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.

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 : Cable de velocidad baja

Descripción general

Sistema%20descripcion

Ilustración : 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.

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

Hardware

Sistema%20des%20hard

Ilustración : 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’.

El sistema modular

TE6%20des

Ilustración : 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.

Subsistema de control y comunicaciones USB

TBCU%20des

Ilustración : 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.

Subsistema de medida

TVIR%20des

Ilustración : 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.

A modo ilustrativo se presenta la siguiente la siguiente figura:

Sistema%204H

Ilustración : 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.

Subsistema de medida definitivo

TVIR%20des%202

Ilustración : 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.

En la siguiente ilustración se puede apreciar cómo quedó finalmente el esquema electrónico de medición de resistencias

Sistema%202H

Ilustración : 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.

Subsistema de conmutación

TCA%20des

Ilustración : 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 reduciendo proporcionalmente al número de canales utilizados (característica típica de los sistemas multiplexados).

El circuito resultante es el siguiente:

Sistema%202H%20TCA

Ilustración : 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.

Software

Sistema%20des%20soft

Ilustración : 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.

Cypress%20Diagrama%20de%20bloques%20simplificado

Ilustración : 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).

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

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.

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.

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.

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’

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.

InteUSB32.dll

InteUSB32%20des

Ilustración : 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.

InteDrv32.dll

InteDrv32%20des

Ilustración : 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.

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.

Captura%20ProvaR%20measure%201

Captura%20ProvaR%20measure%20n

Ilustración : 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.

Captura%20ProvaR%20test

Ilustración : 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.

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 : Especificaciones del sistema

Sistema Modular de Adquisición de Datos

Memoria de Cálculo

AUTOR: Raúl Bartolomé Castro.

DIRECTOR: Alfonso Romero Nevado.

FECHA: Octubre / 2004.

Hardware

Tarjeta de Enlace (TE)

Arquitectura

Download to continue reading…

4 reviews for Sistema Modular de Adquisición de Datos

  1. Felipe

    Hola Raúl,

    Soy Felipe y estoy estudiando Ingeniería Industrial (especialidad Electrónica Industrial). En la actualidad, estoy realizando mi Proyecto final de carrera que trata de módulos de adquisición y transmisión de datos. Estoy muy interesado en tu proyecto y te agradecería si lo pudiera ver como ayuda. Desde esta página no puedo descargármelo.

    Muchas gracias.

    Un saludo.

  2. Raúl Bartolomé Castro

    @Felipe
    Hola Felipe, he actualizado la página he incluido el PDF del PFD. Espero que te sea de utilidad.

    Saludos,
    Raúl

  3. Susana

    Holap, Raúl
    Estoy interesada en la definición de módulos para la enseñanza de electrónica industrial básica

    • Raúl Bartolomé Castro

      Hola Susana,

      No estoy seguro de entender tu comentario, ¿podrías desarrollar la pregunta?

  4. roberto contreras

    estimadao felipe

    me gustaria tener una copia de tus dos trabajos, estoy interesado en desarrollarun trabajo sobre medicion de ruido utilizando el puerto USB o el serial

Add a review

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu
×
×

Cart

%d bloggers like this: