Control en Tiempo Real de Aplicaciones Multimedia...

Escuela Superior de Ingenieros

Departamento de Ingeniería Electrónica

Universidad de Sevilla

PROYECTO FIN DE CARRERA

INGENIERÍA DE TELECOMUNICACIÓN

Control en Tiempo Real de Aplicaciones Multimedia sobre

Redes Ethernet

El Protocolo OpenSound Control

Autor: Jorge Bernal Aguilar

Director: Dr. Manuel Perales Esteve

agradecimientosLa mitad de este trabajo, y más aún de lo que soy, pertenece a mis padres, Juan y Juani. Muy pocas personas en el mundo podrán sentirse tan queridas y apoyadas como me he sentido yo con ellos durante toda mi vida, por difíciles que fueran las circunstancias. Por eso no existen palabras para agradecerles todo lo que les debo.

Gracias a mis hermanos: Eva, Juan y Álvaro, y a toda mi familia. Han sido confidentes y testigos de excepción durante todo el camino, y son lo más valioso que tengo.

A Bego, por aparecer en mi vida en el momento en que más lo necesitaba, y porque sin ella nada de esto tendría sentido.

A mis amigos encontrados en Sevilla. Siempre es y será un placer compartir el tiempo con ellos, por breve que éste sea.

Por último, quisiera dar las gracias a Manuel Perales, por su colaboración en este trabajo y por demostrar que la profesionalidad no tiene por qué estar reñida con el sentido del humor.

Dedicado a Antonio Bernal González

«En este mundo de locos hacen falta más abrazos como los que tú regalabas»

Índice de Contenidos

PARTE I: Introducción

CAPÍTULO 1: Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

La interfaz MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

La interfaz física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19El protocolo de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Alternativas a MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Objetivos y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

CAPÍTULO 2: El protocolo OpenSound Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Modelo cliente - servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Mensajes y paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Agrupaciones de mensajes (bundles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Comparativa con MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Detalles de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Paquetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Ejemplo de mensaje OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Espacio de direcciones del controlador OSC. . . . . . . . . . . . . . . . . . . . . . . . . . 28

7

ÍNDICE DE CONTENIDOS8

PARTE II: Hardware

CAPÍTULO 3: Ethernet en sistemas integrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Introducción a Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Ethernet en el modelo de referencia OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Topologías de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36La capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37La capa física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Alternativas de implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39El controlador ENC28J60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CAPÍTULO 4: Hardware del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

El microcontrolador PIC18F4620 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Proceso de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Alimentación y frecuencia de funcionamiento . . . . . . . . . . . . . . . . . . . 46Programación ICSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Asignación de líneas de entrada y salida . . . . . . . . . . . . . . . . . . . . . . . . . 48Módulo USART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Controlador Ethernet ENC28J60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Interfaz Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Comunicación mediante bus SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

La EEPROM 25LC1024 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Generación de las tensiones de alimentación . . . . . . . . . . . . . . . . . . . . . . . . 53La placa de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Sensores analógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Sensores digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Implementación física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Diseño CAD del circuito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Construcción de las placas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

PARTE III: Software

CAPÍTULO 5: Firmware del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Desarrollo de código para el PIC18F4620 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Estructura interna del microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

ÍNDICE DE CONTENIDOS 9

Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Juegos de instrucciones y modos de direccionamiento . . . . . . . . . . 63Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

El compilador MPLAB® C18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Introducción a las herramientas de lenguaje MPLAB . . . . . . . . . . . . . 65Tipos de datos y almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Ensamblador en línea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Secciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Parámetros específicos del microcontrolador . . . . . . . . . . . . . . . . . . . . 68Ejemplo de programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

La pila TCP/IP de Microchip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Base tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Internet Protocol (IP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Internet Control Message Protocol (ICMP) . . . . . . . . . . . . . . . . . . . . . . . 72User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Transmision Control Protocol (TCP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Domain Name System (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . . . 76NetBIOS Name Service (NBNS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Estructura de la pila TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Protocolos y servicios ofrecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Creación de una aplicación TCP/IP genérica . . . . . . . . . . . . . . . . . . . . . 79

Implementación del código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Configuración de la pila TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Definición del perfil de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Configuración de protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Interrupción de baja prioridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Interrupción de alta prioridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Aplicación principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Inicialización del hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Inicialización de componentes y estructuras de datos de la pila . . 86Inicialización de estructuras del controlador OSC . . . . . . . . . . . . . . . . 87Recuperación de la configuración por defecto . . . . . . . . . . . . . . . . . . . 92Inicialización de los protocolos TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Tareas asociadas a la pila TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Lectura de las entradas del controlador. . . . . . . . . . . . . . . . . . . . . . . . . . 93


Envío de los mensajes OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Inspección de paquetes de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

CAPÍTULO 6: Configuración web del controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Base tecnológica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Estructura de los mensajes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Respuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Cabeceras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Versiones del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Estructura y presentación estática de contenidos web . . . . . . . . . . . . . . . 112XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114CSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Aplicaciones web dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Asynchronous Javascript And XML (AJAX) . . . . . . . . . . . . . . . . . . . . . . 117

El servidor HTTP de Microchip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Configuración del servidor HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Desarrollo de una aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Sustitución de variables dinámicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Variables dinámicas sin argumentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Variables dinámicas con argumentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Procesamiento de formularios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Método GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Método POST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

La interfaz web de monitorización y control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Página de estado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Variables dinámicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Actualización del estado mediante AJAX . . . . . . . . . . . . . . . . . . . . . . . 129Activación y desactivación de métodos. . . . . . . . . . . . . . . . . . . . . . . . . 133

Página de configuración de parámetros OSC . . . . . . . . . . . . . . . . . . . . . . . . 134Página de configuración de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Diseño de las páginas web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Aptana Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Firebug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

ÍNDICE DE CONTENIDOS 11

CAPÍTULO 7: Consideraciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Mejoras y líneas de avance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

PARTE IV: Apéndices

APÉNDICE A: Esquemáticos del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

APÉNDICE B: Construcción de un depurador hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

APÉNDICE C: Compilación y control de versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Configuración del entorno de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Control de versiones con Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

APÉNDICE D: Ejemplos de aplicación práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

APÉNDICE E: Fotografías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Índice de Figuras

Figura 2.1: Espacio de direcciones de un servidor OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figura 2.2: Espacio de direcciones del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 3.1: El modelo OSI y su relación con Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 3.2: Ejemplo de topología en estrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 3.3: Estructura funcional del ENC28J60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figura 4.1: Diagrama de bloques del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 4.2: Relación voltaje-frecuencia del PIC18LF4620. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 4.3: Interfaz ICSP y reset de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 4.4: Líneas disponibles para la conexión de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 4.5: Interfaz USART / RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 4.6: Componentes externos del controlador ENC28J60. . . . . . . . . . . . . . . . . . . . . . . . 51Figura 4.7: La EEPROM serie 25LC1024 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Figura 4.8: Generación de las tensiones de alimentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 4.9: Sensor analógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 4.10: Operación del codificador rotativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 4.11: Diseño del PCB en EAGLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 4.12: Vista del editor de esquemáticos en EAGLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 4.13: Vista 3D de la placa principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 4.14: Vista 3D de la placa de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 5.1: Mapa de memoria de datos en el PIC18F4620. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 5.2: Flujo de ejecución de las herramientas MPLAB. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figura 5.3: Protocolos TCP/IP en diferentes niveles OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Figura 5.4: Encapsulamiento y cabecera de UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figura 5.5: Establecimiento y cierre de una conexión TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

13

ÍNDICE DE FIGURAS14

Figura 5.6: Sesión DHCP típica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figura 5.7: Flujo de una aplicación TCP/IP genérica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figura 5.8: Diagrama de flujo simplificado de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figura 5.9: Secuencia temporal de la conversión ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Figura 5.10: Diagrama de transición de estados de la tarea OSCClientTask() . . . . . . . . . . . . 98Figura 5.11: Captura e inspección de un mensaje OSC mediante Wireshark . . . . . . . . . . . 107Figura 6.1: Secuencia típica de interacción mediante AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . 118Figura 6.2: Proceso de creación de una aplicación web dinámica . . . . . . . . . . . . . . . . . . . . 121Figura 6.3: Página web inicial del controlador OSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Figura 6.4: Edición XHTML en el entorno de desarrollo Aptana Studio . . . . . . . . . . . . . . . 141Figura 6.5: Inspección de un elemento XHTML en Firebug . . . . . . . . . . . . . . . . . . . . . . . . . . 142Figura 7.1: Frecuencia de muestreo media en función de los métodos OSC activados 144Figura A.1: Fotolito de la placa principal (cara superior) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Figura A.2: Fotolito de la placa principal (cara inferior) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Figura A.3: Fotolito de la placa de controles (cara superior) . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figura A.4: Fotolito de la placa de controles (cara inferior) . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figura B.1: Clasificación de las herramientas de desarrollo MPLAB . . . . . . . . . . . . . . . . . . . 155Figura B.2: Vista 3D del depurador compatible ICD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Figura C.1: Configuración de los archivos de C18 en MPLAB IDE . . . . . . . . . . . . . . . . . . . . . 160Figura C.2: Configuración de los directorios del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Figura C.3: Opciones del compilador (categoría general) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Figura C.4: Selección del modelo de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Figura C.5: Grupo de archivos en un directorio de trabajo SVN. . . . . . . . . . . . . . . . . . . . . . . 163Figura C.6: TortoiseSVN mostrando las diferencias entre dos archivos . . . . . . . . . . . . . . . 164Figura D.1: Ejemplo de parche en Pure Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Figura D.2: Aspecto del IDE de Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Figura E.1: Fotografía de la placa principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Figura E.2: Fotografía de la placa de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Figura E.3: Fotografía del depurador compatible ICD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Figura E.4: Fotografía del controlador en funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . 169Figura E.5: Fotografía del montaje completo (proceso de desarrollo) . . . . . . . . . . . . . . . . 169

primera parte:

Introducción

1capítulo

Introducción

esde la aparición en 1983 de la especificación MIDI, el desarrollo de la tecnología electrónica digital ha sido enorme. El abaratamiento de los costes de producción y el

incremento de potencia e integración de los nuevos microprocesadores, han provocado una auténtica revolución del sector electrónico. Como consecuencia, los instrumentos musicales electrónicos han sufrido paralelamente una transformación de sus capacidades y prestaciones que ha permitido la expansión de un mercado tradicionalmente vetado a los usuarios aficio‐nados por el elevado coste de los productos. Este auge y modernización conlleva nuevas necesidades de interconexión de equipos que no existían a principios de los 80, cuando los primeros sintetizadores digitales con interfaz MIDI empezaron a comercializarse. Es por ello por lo que esta especificación, que apenas ha cambiado durante sus más de dos décadas de antigüedad resulta, en ocasiones, inapropiada en el marco de una aplicación moderna.

En el presente Proyecto Fin de Carrera se abordará el diseño y la implementación física de un dispositivo de control basado en uno de los protocolos que han sido concebidos para convertirse en sucesores de MIDI: OpenSound Control (OSC). Aunque todavía no se ha estanda‐rizado, este protocolo ha alcanzado un importante grado de aceptación entre fabricantes y usuarios de hardware y software multimedia, no sólo en el ámbito musical, sino también en otras aplicaciones como el control de espectáculos en vivo, la realidad virtual o la investi‐gación de nuevas interfaces de expresión artística basadas en sistemas complejos de sensores. Las ventajas que OSC ofrece frente a MIDI son múltiples, y se detallarán a medida que se avance en el desarrollo de la memoria. De entre ellas destacan la mejora sustancial en la resolución de los datos y la total flexibilidad en la definición de los mensajes, características que hacen al protocolo adecuado en una amplia variedad de contextos.

El dispositivo controlador diseñado en este proyecto no tendrá, de hecho, una aplicación específica. Su utilidad final dependerá de la interpretación particular que el usuario quiera hacer en cada momento de los mensajes de control asociados a un conjunto de señales analó‐gicas y digitales. A pesar de ello, la mayoría de los programas informáticos existentes en la actualidad que soportan la recepción de comandos OSC están enfocados a la presentación de contenidos de sonido, vídeo y/o gráficos, dotando al usuario de un cierto grado de interacti‐

D

17

CAPÍTULO 1: INTRODUCCIÓN18

vidad con los mismos. Puesto que ésta será su finalidad más inmediata, se ha titulado al proyecto «Control en tiempo real de aplicaciones multimedia sobre redes Ethernet: El protocolo OpenSound Control».

Aunque OSC es independiente de la capa de transporte y por tanto de la tecnología de red subyacente, es bastante habitual encontrar implementaciones basadas en Ethernet. Esta tecnología, en cualquiera de sus variantes, es probablemente la que ha alcanzado mayor implantación en redes de ordenadores de área local, debido a su elevada velocidad de trans‐misión y su coste reducido. Existe además una clara tendencia a introducir esta interfaz en un número cada vez mayor de sistemas integrados de propósito específico, como cámaras de seguridad, teléfonos VoIP o incluso máquinas expendedoras. Si bien estos sistemas no requieren, en general, de altas tasas de transferencia, se benefician de esta manera de un acceso sencillo y cómodo para su monitorización y control remotos, ya sea desde la propia red local o desde Internet. La utilización de esta tecnología en el controlador objetivo de este proyecto no sólo tendrá las ventajas ya mencionadas; también hará necesario el estudio de las peculiari‐dades de diseño, tanto hardware como software, de un sistema genérico basado en un micro‐controlador con conectividad Ethernet que ejecuta una pila simplificada de protocolos de Internet, lo que hará extensible este trabajo a multitud de aplicaciones diferentes a la que nos ocupa.

Con el fin de establecer un punto de partida que sirva de referencia para el análisis del protocolo OpenSound Control, en el resto del capítulo se hará un breve resumen de la especifi‐cación MIDI: sus virtudes, sus limitaciones y algunas de sus alternativas. Posteriormente se concretarán los objetivos del proyecto y por último se describirá la estructura de la memoria.

1.1 La interfaz MIDILas siglas «MIDI» corresponden en inglés a la Musical Instruments Digital Interface o Interfaz Digital de Instrumentos Musicales. Su uso más común es la transmisión de mensajes asociados a eventos que se generan en aparatos musicales, y que luego son interpretados en un dispo‐sitivo remoto para la síntesis de un determinado sonido. Estos eventos pueden ser de naturaleza muy diversa, aunque son ejemplos típicos la pulsación de una nota en un teclado electrónico o la variación del control de volumen en un amplificador. Aunque MIDI se utiliza fundamentalmente en entornos de producción musical, también es posible encontrar imple‐mentaciones en otros ámbitos como el control de espectáculos en directo, y su formato de archivo para el almacenamiento de mensajes se ha convertido en un estándar de telefonía móvil que resulta especialmente adecuado para la reproducción y transferencia de melodías.

Poco después de su creación a principios de los 80, MIDI se convirtió en un estándar ampliamente acogido por la industria que actualmente es mantenido por la MIDI Manufac‐turers Association (MMA). Esta asociación de fabricantes se encarga de proponer extensiones a la especificación original, que todavía continúa en su versión 1.0 [MIDI]. En ella se definen las características físicas y eléctricas de la interfaz de comunicación, así como también el formato de los mensajes y el de su almacenamiento. Un conocimiento básico previo de estas caracterís‐ticas es conveniente para poder establecer una comparativa con OSC, por lo que se expondrá a continuación un resumen de las mismas.

LA INTERFAZ MIDI 19

1.1.1 La interfaz física

El hardware de transporte definido en la especificación MIDI es probablemente uno de sus aspectos más criticados actualmente, dada su antigüedad. Se trata de enlaces serie simplex con una longitud máxima teórica de 15 metros y una tasa relativamente baja de 31.250 bps.

La sencillez de la interfaz y el hecho de no haber sufrido variaciones en sus más de dos décadas de vida tiene una ventaja en términos de interoperabilidad entre dispositivos: un teclado de principios de los 80 podrá comunicarse con un moderno secuenciador sin ningún problema. Sin embargo, la interfaz tiene grandes inconvenientes que la hacen inadecuada en ciertos casos, como son la reducida velocidad de transmisión, la necesidad de duplicar el cableado para establecer una comunicación bidireccional y, dependiendo de la aplicación, la limitada longitud de los enlaces.

Estas desventajas han propiciado la aparición de otros estándares para el transporte de mensajes MIDI sobre interfaces más modernas como USB o IEEE‐1394, aunque la descrita en este apartado y conocida a veces como MIDI‐DIN suele, erróneamente, considerarse la única alternativa, especialmente entre los detractores de la especificación.

1.1.2 El protocolo de comunicación

La segunda parte de la especificación define el formato de los mensajes. El conjunto de comandos MIDI se diseñó para describir la forma en la que la música debe generarse en un sintetizador, por lo que existen mensajes específicos para el comienzo y el fin de la repro‐ducción de una nota, su volumen, su tono, etcétera. En este sentido se diferencia bastante de OSC, que sólo define unas reglas para la construcción de los mensajes, siendo estos últimos dependientes de cada aplicación.

Cada conexión física MIDI se divide en un total de 16 canales lógicos, lo que hace posible el control simultáneo de varios instrumentos empleando un único enlace, o bien permite direc‐cionar entidades diferentes en un mismo dispositivo MIDI, como en aquellos instrumentos capaces de generar sonidos independientes (conocidos como dispositivos «multitimbre»).

Los mensajes MIDI tienen una longitud de entre 1 y 3 bytes, y normalmente están asociados a un determinado canal lógico. El primer byte identifica el tipo de mensaje y el canal, mientras que el resto corresponden al argumento del mensaje, cuya resolución suele ser de 7 bits. Esto significa que, en general, sólo será posible modificar un determinado parámetro en una escala de 128 valores1.

Existen también mensajes independientes del canal o «de sistema», que pueden usarse para la sincronización entre dispositivos o bien para la transferencia de información exclusiva, con un formato propietario definido de forma independiente por cada fabricante. Como ejemplos de la utilidad de este tipo de mensajes se pueden mencionar los volcados de memoria o el intercambio de presets, entre otras aplicaciones.

1. La excepción a esta regla es el control de portamento o pitch‐bend, que tiene una resolución extendida de 14 bits debido a la mayor sensibilidad del oído humano a los cambios de fre‐cuencia.


1.1.3 Alternativas a MIDI

Aunque MIDI se ha consolidado como el estándar por defecto de cualquier pieza de hardware o software musical, con el tiempo han surgido otras soluciones que intentan solventar sus limitaciones. Algunas de ellas se basan en MIDI e intentan añadir o mejorar características manteniendo la compatibilidad. Otras, sin embargo, divergen completamente de esta especifi‐cación desde su origen. Algunos ejemplos son los siguientes:

HD-MIDI

Ideado por la MMA, HD‐MIDI es actualmente un borrador que aspira a convertirse en la próxima versión MIDI 2.0. Se pretenden solucionar muchos de los problemas de los que adolece MIDI, mejorando la resolución de los datos, incrementando el número de canales y creando nuevos tipos de mensajes. Todo ello manteniendo la compatibilidad con la especifi‐cación original.

mLAN

Se trata de un protocolo propietario de Yamaha basado en el estándar IEEE‐1394. La idea es reducir el cableado entre dispositivos al combinar varios canales de audio con canales MIDI, transportándolos en una única conexión física a 400 Mbps. Por este motivo el sistema sólo puede considerarse una mejora del hardware de transporte MIDI.

ZIPI

El proyecto Zeta Instrument Processor Interface fue uno de los primeros orientados a sustituir por completo a MIDI. Sin embargo, la falta de dispositivos comerciales con soporte para esta interfaz y la aparición del estándar superior IEEE‐1394 (FireWire) han provocado el abandono de su desarrollo, en favor de OSC.

OSC

Es un nuevo protocolo de comunicaciones totalmente independiente de MIDI, mucho más genérico y enfocado a un rango más amplio de aplicaciones. OSC es independiente de la capa de transporte empleada, lo que significa que puede utilizarse en una amplia variedad de tecnologías de red. Dado que es una base fundamental en el presente proyecto, se dedicará el siguiente capítulo a una descripción más detallada.

1.2 Objetivos y alcance del proyectoEl objetivo del presente proyecto fin de carrera es doble. Por una parte se pretende desarrollar un dispositivo de control de aplicaciones multimedia basado en el protocolo OpenSound Control, dada la escasez de implementaciones físicas de este tipo en comparación con MIDI. La particular adecuación de este protocolo a la tecnología de red Ethernet es una buena oportunidad para abordar un estudio de las posibilidades, y también las dificultades, que entraña este tipo de conectividad en un sistema empotrado genérico, en concordancia con el creciente auge de este tipo de sistemas.

ESTRUCTURA DE LA MEMORIA 21

El proyecto comprende el desarrollo del hardware y el software necesarios para que la aplicación sea totalmente funcional; aunque no se especificaron en un principio sus caracterís‐ticas, necesarias o deseables, más allá de esta premisa, debido a que éstas dependían en gran medida de la elección concreta de cada aternativa de diseño. Sí debieron tenerse en cuenta los siguientes factores:

• El número de entradas del sistema no es crítico, así como tampoco lo será en princi‐pio la frecuencia de muestreo de las mismas. Un valor típico propuesto por algunos autores para la adquisición de señales de control basadas en gestos humanos es de 200 Hz [IRC78][WAN01], aunque en la mayoría de los casos prácticos bastará con tasas considerablemente inferiores.

• La mayor carga computacional y necesidad de memoria corresponde al manejo de la pila de protocolos de Internet, puesto que el resto de la aplicación es relativamente sencillo. Esto implica que prácticamente cualquier microprocesador con capacidad básica de ejecución de esta pila será válido para el propósito de este trabajo.

Al margen de estas consideraciones, las características definitivas del sistema depen‐dieron de las capacidades de los componentes elegidos. Estas características se enumeran a continuación, con el fin de dar una visión global del alcance del proyecto:

• El hardware se ha basado en la combinación de un microcontrolador PIC de 8 bits y un controlador Ethernet con comunicación mediante bus SPI.

• El sistema dispone de un total de 8 entradas analógicas y 8 digitales para la conexión de los sensores que conforman los mandos de la aplicación. Estas señales se mues‐trean, se procesan y se envían como mensajes OSC a una tasa superior a 400 Hz, dependiendo de la configuración.

• Los mensajes OSC se transportan mediante UDP/IP hasta un ordenador donde se ejecuta el software que se desea controlar, y que puede estar ubicado en la misma red local que el controlador o bien en otra red accesible a través de Internet.

• La configuración de los parámetros de red del dispositivo y de otros parámetros específicos del cliente OSC se realiza mediante un servidor HTTP incluido en el sis‐tema, por lo que puede realizarse desde cualquier navegador web sin necesidad de usar un software específico. Este servidor soporta características avanzadas como presentación dinámica de contenidos o AJAX, tecnología que permite la monitoriza‐ción en tiempo real del estado del controlador.

El proyecto tendrá, por tanto, un carácter multidisciplinar que comprende tareas dispares como el diseño hardware, la programación multitarea de microcontroladores o el desarrollo de contenidos web.

1.3 Estructura de la memoriaEl presente documento se ha estructurado en cuatro partes:


1 Introducción. Esta parte incluye los dos primeros capítulos: el presente homónimo y otro más dedicado a la descripción del protocolo OpenSound Control.

2 Hardware. Esta es la primera parte donde se tratan las aportaciones realizadas al proyecto, y consta de dos capítulos. En el capítulo 3 se describen las peculiaridades de la tecnología Ethernet en sistemas electrónicos simples y de propósito específico como el controlador OSC, mientras que en el capítulo 4 se concreta su diseño e implementación física.

3 Software. Este bloque, que constituye una parte fundamental del trabajo, se divide en tres capítulos. El capítulo 5 comprende el desarrollo del código que ejecuta el microcontrolador o firmware. El capítulo 6 describe las tecnologías web implicadas en la solución y su programación. En el capítulo 7 se establecen las conclusiones del proyecto.

4 Apéndices. La memoria concluye con una serie de apéndices donde se incluyen aportaciones relacionadas con el desarrollo del proyecto que por conveniencia se han separado de las partes anteriores.

2capítulo

El protocolo OpenSound Control

egún lo definen sus propios creadores, OpenSound Control es un protocolo de comuni‐cación entre ordenadores, sintetizadores de sonido y otros dispositivos multimedia

optimizado para su uso en modernas tecnologías de red. En este capítulo se describirán sus características, poniendo especial atención en aquellas más relevantes para la implementación de este proyecto. Su lectura facilitará la comprensión del resto de la memoria, en particular de la parte donde se describe el diseño del software.

2.1 Descripción generalOSC fue desarrollado y continúa siendo objeto de investigación en el Center for New Music and Audio Technology (CNMAT), Universidad de California, Berkeley. Fue diseñado como reemplazo de MIDI en aplicaciones donde las limitaciones de éste hacían imposible o muy difícil su utilización, y goza de gran popularidad en el campo de las nuevas interfaces para la expresión musical, sistemas musicales distribuidos en red, realidad virtual, etc. [NIME03].

Las características más destacadas del protocolo son [OSC08]:

• Arquitectura simple, ampliable, dinámica y flexible1.

• Esquema de nombres con una sintaxis similar a la de URL.

• Argumentos simbólicos y numéricos de alta resolución (32 bits).

• Lenguaje de coincidencia de patrones, que permite la recepción de un único mensaje por varios destinatarios.

• Marcas de tiempo (time‐tags) de alta resolución.

1. De hecho, la aparición de la palabra “sound” en su nombre es circunstancial, dado que a dife‐rencia de MIDI, no hay nada en la especificación del protocolo que limite o enfoque su uso a aplicaciones de sonido.

S

23

CAPÍTULO 2: EL PROTOCOLO OPENSOUND CONTROL24

• Posibilidad de enviar agrupaciones de mensajes (conocidas como bundles) para aquellos eventos que deban procesarse simultáneamente (como por ejemplo la reproducción de un acorde).

• Sistema de interrogación para averiguar de forma dinámica las características de un servidor OSC y para la obtención de documentación.

El protocolo se desarrolló con el objetivo de mejorar la integración entre dispositivos como ordenadores, controladores y sintetizadores de sonido, incrementando la fiabilidad, la facilidad de uso y la respuesta a las órdenes de control. Aunque es independiente de la tecno‐logía de red empleada para su transporte, se adapta mejor a medios de transmisión con tasas superiores a los 10 Mpbs, como por ejemplo Ethernet. Por otro lado, en lugar de enviar la información como un flujo constante de datos sobre una conexión establecida, OSC se basa en la transferencia de paquetes mayores e independientes que contienen toda la información pertinente en una única entidad. De esta manera, en la medida de lo posible, el receptor no tendrá que mantener el estado de las comunicaciones anteriores.

En el resto del apartado se dará una breve descripción de los conceptos más importantes relacionados con el protocolo desde el punto de vista del usuario [NIME03]. Se dedicará un apartado posterior a otros aspectos técnicos necesarios para la implementación del contro‐lador.

2.1.1 Modelo cliente - servidor

Como en otros campos del software, OSC utiliza una arquitectura cliente‐servidor. Cualquier nodo —ya sea un dispositivo físico o una aplicación informática— que envía paquetes OSC es un cliente, mientras que la recepción e interpretación de los mismos corresponde a un servidor. Existen nodos que pueden ser tanto clientes como servidores de manera simultánea.

En el presente proyecto se abordará únicamente el diseño de un cliente OSC, puesto que lo que se pretende es el envío de comandos de control. El servidor será típicamente una aplicación multimedia que se ejecuta en un ordenador remoto.

2.1.2 Mensajes y paquetes

El mensaje es la unidad básica de datos en OSC. Cada mensaje consta de un patrón de direc‐ciones, una etiqueta de tipos y una serie de argumentos.

El paquete es la unidad básica de transmisión de información, y puede constar de un único mensaje o de varios agrupados (bundles).

Un patrón de direcciones es una cadena que identifica a la entidad o entidades del servidor OSC («métodos», según la propia nomenclatura de la especificación) a las que el mensaje hace referencia. La capacidad de direccionar varios métodos a la vez es posible mediante el empleo de caracteres especiales para la búsqueda de expresiones regulares. Es por ello por lo que se habla de «patrón de direcciones» en lugar de simplemente «dirección» OSC. Sin embargo, en raras ocasiones se encuentran implementaciones de servidores OSC que soporten este sistema de coincidencia de patrones en el direccionamiento de sus métodos, por lo que no se considerará aquí la descripción del mismo.

DESCRIPCIÓN GENERAL 25

Los métodos de un servidor OSC se distribuyen de forma jerárquica en una estructura en árbol como la mostrada en el ejemplo de la figura 2.1. Esta estructura constituye el denominado «espacio de direcciones» OSC. A diferencia de MIDI, donde se especifica cómo debe ser la arquitectura de los dispositivos, el espacio de direcciones OSC es totalmente flexible, y además puede ser dinámico. Por este motivo el protocolo cuenta con un sistema de interrogación (query) que permite a un cliente conocer en cada momento el espacio de direc‐ciones de un servidor, así como solicitarle documentación u otro tipo de información.

Una dirección OSC es una cadena con una sintaxis similar a la de URL en la que se especifica la ruta completa desde la raíz del espacio de direcciones, representada por una barra diagonal (/), hasta el método que se quiere invocar, y donde los elementos intermedios se separan también mediante barras. En el ejemplo de la figura, el método Volume tiene la dirección /Amp/Volume, mientras que un mensaje con el patrón /Amp/EQ/* invocará a los métodos Bass y Treble del servidor con los mismos argumentos.

2.1.3 Tipos de datos

Un mensaje OSC puede contener un número indefinido de argumentos de distinto tipo, que se identifican mediante la etiqueta de tipos mencionada en el apartado anterior.

Los tipos básicos definidos por la especificación son: cadenas de caracteres ASCII, números enteros y de punto flotante de 32 bits, marcas de tiempo de 64 bits y blobs, un tipo especial que se emplea para la transmisión de una cantidad arbitraria de datos en formato binario.

2.1.4 Agrupaciones de mensajes (bundles)

Un bundle es un tipo de contenedor formado por un grupo de mensajes que se deben procesar en el servidor de forma atómica, en el instante especificado por una marca de tiempo OSC. Estas marcas de tiempo utilizan el mismo formato que el protocolo NTP de Internet, y requieren que el servidor tenga acceso a una representación correcta del tiempo absoluto.

Es posible que un bundle contenga otros bundles de forma recursiva, además de los mensajes mencionados, lo que es una prueba más de la flexibilidad del protocolo.

Figura 2.1: Espacio de direcciones de un servidor OSC


2.2 Comparativa con MIDIUna vez descritas las características básicas de OSC, se pueden comparar los aspectos claves que diferencian a este protocolo de MIDI [OSC07]. En la tabla 2.1 se resumen estas diferencias.

Si bien OSC puede considerarse superior en casi todos los aspectos, la realidad es que la mayor ventaja de MIDI radica en que se trata de una interfaz sumamente probada que cuenta con el soporte de los principales fabricantes de hardware y software musical, y que es suficiente para la mayoría de las aplicaciones. Por este motivo es difícil pensar que OSC pueda reemplazar a la tecnología actual a corto o medio plazo.

2.3 Detalles de la implementaciónEn este apartado se describirán aquellos aspectos técnicos de la especificación del protocolo [OSC02] que tienen interés para el desarrollo del proyecto. Es conveniente por tanto delimitar aquí el alcance de la aplicación, que por su naturaleza tiene las siguientes características:

• Se trata de un dispositivo controlador, y por tanto, cliente. Esto simplifica enorme‐mente la implementación, puesto que se pueden obviar aspectos avanzados de los servidores como la coincidencia de patrones de dirección o la ejecución asíncrona de métodos, entre otros.

MIDI OSC

Ejemplo de mensajes 0x903C40 (MIDI Note-on) /play-note 15 0.9

MensajesPredefinidos por la especificación

Formato binario

Definidos por el usuarioFormato ASCII

(excepto argumentos)

Actualización atómica de múltiples parámetros

No Mediante bundles

Marcas de tiempo No Mediante bundles

Hardware de transporte definido

SíNo

(Sólo los niveles OSI 6 y 7)

Número de canales 16 Ilimitado

Tipos de datos Enteros (8 bits)Enteros y decimales (32 bits)

Cadenas de caracteresOtros

Tasa de transferencia (típica)

31.250 bps > 10 Mbps

Formato de archivo Standard MIDI file No implementado

Tabla 2.1: Comparativa entre MIDI y OSC

DETALLES DE LA IMPLEMENTACIÓN 27

• El espacio de direcciones se define en el lado del cliente y es estático, por lo que no es necesario emplear el sistema de interrogación (queries), que por otro lado está poco soportado por los servidores OSC implementados hasta la fecha. El hecho de que el espacio de direcciones se defina en el lado del cliente no es una limitación, ya que la mayoría de los servidores son flexibles en la definición de sus métodos y del tipo de argumentos que soportan. Cuando no sea así, se puede utilizar un software intermedio como Pure Data (ver apéndice D) para adaptar el formato de los mensajes OSC del controlador a los requerimientos de la aplicación de destino.

• Los paquetes OSC están formados por un único mensaje. Los mensajes asociados a las entradas analógicas y digitales se envían tan pronto como se dispone de la lec‐tura correspondiente, y no es adecuado agruparlos en bundles, que requerirían el uso de marcas de tiempo y complicarían innecesariamente la implementación.

2.3.1 Paquetes

Un paquete OSC se compone de su contenido útil (mensaje o bundle) y de un número entero de 32 bits que indica su tamaño en bytes. El tamaño de un paquete OSC debe ser siempre un múltiplo de 4 para asegurar un esquema de alineación de datos consistente.

Sin embargo, dependiendo del protocolo que se emplee por debajo de OSC, puede no ser necesario adjuntar el tamaño del paquete a su contenido, al estar ya incluido de manera implícita en la cabecera del nivel de transporte. Esto ocurre por ejemplo en el caso de UDP, donde la carga de datos de cada datagrama coincide exactamente con un paquete OSC.

En este proyecto se usará UDP como protocolo de transporte, y cada datagrama portará un único mensaje OSC.

2.3.2 Mensajes

Como se indicó en el apartado 2.1.2, un mensaje consta de una dirección OSC1, una cadena de tipos y una serie opcional de argumentos. Veamos con más detalle cada una de estas partes.

Dirección OSC

Como se sabe, una dirección OSC es una cadena que contiene la ruta completa al método desde la raíz del espacio de direcciones. Esta cadena, como todas las que se usan en el protocolo, está formada por un conjunto de caracteres ASCII terminados con el carácter nulo, y seguidos luego por tantos nulos sean necesarios como para hacer el número total de bytes de la cadena un múltiplo de 4.

Cadena de tipos

La cadena de tipos es una cadena OSC que comienza por el carácter coma (,) seguido de una secuencia de caracteres que se corresponden, uno a uno, con la secuencia de argumentos que contiene el mensaje. Cada uno de estos caracteres se llama etiqueta de tipo y representa el tipo del argumento asociado.

1. No se hablará más de «patrón de dirección», puesto que en este proyecto cada mensaje tiene por destino a un único método.


Argumentos

El tipo de datos más adecuado para la presente implementación es el entero, que tiene una etiqueta de tipo representada por el carácter ‘i’. Por lo tanto, según se ha definido, un mensaje con cuatro argumentos enteros tendrá la cadena de tipos ‘,iiii’. Los argumentos enteros se codifican con 32 bits, en complemento a 2 y con almacenamiento big‐endian.

2.3.3 Ejemplo de mensaje OSC

En la tabla 2.2 se muestra con un ejemplo la manera en la que se construye un mensaje OSC. Cada celda representa un byte, y puede observarse cómo tanto cadenas de caracteres como argumentos en OSC se alinean en grupos de 32 bits.

Consideraremos para nuestro ejemplo que el método Drive de la figura 2.1 recibe como argumentos dos números enteros. El primero de ellos es un valor lógico que indica si el método debe activarse o desactivarse, y que en el ejemplo toma el valor 1. El segundo argumento es una ganancia en dB, por lo que podrá ser un número negativo. En el ejemplo este argumento vale ‐6, cuya representación en complemento a 2 con 32 bits es, en hexade‐cimal, FFFFFFFAhex.

Se observa cómo la cadena /Amp/Drive que aparece en la primera fila termina con un carácter nulo adicional en concordancia con el esquema de alineación de datos en grupos de 32 bits.

2.3.4 Espacio de direcciones del controlador OSC

En la figura 2.2 se muestra el conjunto de métodos del controlador diseñado en el proyecto y su estructura jerárquica.

‘/’ ‘A’ ‘m’ ‘p’ ‘/’ ‘D’ ‘r’ ‘i’ ‘v’ ‘e’ ‘\0’ ‘\0’

‘,’ ‘i’ ‘i’ ‘\0’ 0x00 0x00 0x00 0x01 0xFF 0xFF 0xFF 0xFA

Tabla 2.2: Ejemplo de mensaje OSC

Figura 2.2: Espacio de direcciones del controlador OSC

DETALLES DE LA IMPLEMENTACIÓN 29

El método principal (EtherOSC) es el único que no tiene argumentos asociados. Su nombre podrá modificarse para permitir la comunicación de varios controladores indepen‐dientes con un mismo servidor.

El método Analog consta de 8 argumentos enteros vinculados a cada una de las entradas analógicas del sistema. El resto de métodos se corresponden con distintas configuraciones de sensores digitales y cada uno de ellos contiene un único argumento entero. En el capítulo 5, dedicado al desarrollo del firmware de la aplicación, se profundizará más en estos aspectos.

segunda parte:

Hardware

3capítulo

Ethernet en sistemas integrados

e conocen como sistemas integrados (en inglés embedded systems) aquellos dispositivos electrónicos basados en un microprocesador que han sido diseñados con el fin de realizar

tareas concretas. En contraposición con un ordenador de propósito general, un sistema integrado ejecuta un código específico, y normalmente su diseño está sujeto a un conjunto más estricto de restricciones que pueden afectar a los tiempos de ejecución (sistemas en tiempo real), consumo de potencia, tamaño, etcétera. Estos sistemas encuentran aplicación en ámbitos de naturaleza muy diversa. Sirvan como pequeña muestra de sistemas integrados decodifica‐dores de televisión, teléfonos móviles, cajeros automáticos o cámaras de vigilancia, entre otros.

Ethernet es una tecnología de red que tiene sus orígenes en el mercado de los PCs, donde se emplea ampliamente en redes de área local. Sin embargo, tradicionalmente se ha consi‐derado poco adecuado su uso en sistemas integrados por diversas razones. En primer lugar, suponía en la mayoría de las ocasiones una solución más cara que otras alternativas. Dado que los controladores Ethernet existentes estaban enfocados a la industria del PC, la complejidad y los costes de producción asociados hacían inviable su utilización en sistemas empotrados, muchos de los cuales se basaban en procesadores que carecían de la potencia o memoria suficientes para albergar una pila de protocolos de red sobre Ethernet. Por otra parte, el tipo de acceso al medio de esta tecnología, donde las colisiones se resuelven mediante tiempos de espera aleatorios, se consideraba inadecuado para los sistemas en tiempo real.

En los últimos años esta situación ha cambiado significativamente, y cada vez son más los sistemas integrados que disponen de conectividad Ethernet. De entre las características que hacen atractiva ahora a esta tecnología, destacan:

• Ubicuidad. Las redes Ethernet están ampliamente desplegadas en un gran número de oficinas y edificios industriales. Además la práctica totalidad de los ordenadores comercializados en los últimos años integran una tarjeta de red Ethernet.

• Interoperabilidad. Ethernet está basado en estándares que permiten la comunica‐ción entre dispositivos muy heterogéneos, con independencia del fabricante.

S

33

CAPÍTULO 3: ETHERNET EN SISTEMAS INTEGRADOS34

• Escalabilidad. Las redes Ethernet son muy flexibles, pudiendo constar desde un único enlace entre dos dispositivos hasta una enorme cantidad de nodos (con un máximo teórico de 248 elementos).

• Conexión a Internet. Ethernet es uno de los medios más comunes de acceso a Internet. Esto elimina cualquier barrera espacial, permitiendo la monitorización, control, diagnóstico y recopilación de información de forma remota. Este acceso remoto y centralizado a los sistemas tiene grandes ventajas en reducción de tiempos de trabajo y coste.

Estas características han propiciado la aparición de una considerable cantidad de imple‐mentaciones hardware y software enfocadas a la industria de los sistemas integrados, como pueden ser controladores Ethernet de bajo coste con un número reducido de líneas de entrada y salida, o versiones simplificadas de la pila de protocolos TCP/IP que pueden ejecutarse en procesadores con grandes limitaciones de memoria y potencia. Por otro lado, el uso extendido de switches y routers ha resuelto los problemas de variabilidad en los tiempos de acceso al medio debidos a colisiones, lo que permite considerar a Ethernet como una buena alternativa incluso en aplicaciones en tiempo real.

En el presente capítulo se introducirán algunos conceptos básicos sobre Ethernet, y más tarde se analizarán las alternativas diseño consideradas en el proyecto. Por último se describirá el controlador ENC28J60 de Microchip, que como se verá es un componente funda‐mental de la implementación realizada.

3.1 Introducción a EthernetEl término Ethernet hace referencia a una familia de tecnologías de red basadas en tramas de datos y recogidas en el estándar IEEE 802.3. Este estándar se basa en el trabajo realizado por Robert Metcalfe en el Xerox PARC, quien definió un protocolo de acceso al medio compartido que se conoce como CSMA/CD.

Existen distintas variantes de Ethernet que aparecen como suplementos al estándar original y que dependen de la tasa de transferencia máxima, del modo de transmisión y del medio físico. Actualmente hay definidas cuatro tasas de transferencia sobre distintos medios de transmisión:

• 10 Mbps. (Por ejemplo Ethernet 10Base‐T, que define el transporte sobre cable de par trenzado).

• 100 Mbps (Fast Ethernet).

• 1000 Mbps (Gigabit Ethernet).

• 10 Gbps (10 Gigabit Ethernet).

En el resto del apartado se resumirán algunos conceptos sobre Ethernet. Su lectura facilitará la comprensión de las características del controlador Ethernet empleado en el proyecto. Para una descripción más detallada el lector puede consultar otras fuentes [CIS00][MICSi], o directamente el estándar IEEE 802.3.

INTRODUCCIÓN A ETHERNET 35

3.1.1 Ethernet en el modelo de referencia OSI

El modelo de Interconexión de Sistemas Abiertos (OSI) es un marco de referencia creado por la ISO para la definición de arquitecturas de interconexión de sistemas de comunicaciones. Un breve resumen de sus características puede resultar útil para dar una visión global del alcance de Ethernet y más adelante de la pila de protocolos TCP/IP.

El modelo de referencia OSI está compuesto por una serie de bloques denominados capas o niveles, cada uno de los cuales juega un papel específico en la transferencia de infor‐mación entre un sistema y otro. Cada capa se construye encima de otra cuyos servicios utiliza, y ofrece otros servicios a la capa situada en el nivel inmediatamente superior. Aunque es un modelo útil y ampliamente extendido, hay que tener en cuenta que sólo es válido como referencia, dado que en muchas ocasiones resulta imposible o poco práctico tratar de encajar un sistema determinado en este esquema.

En la figura 3.1 se muestran los siete niveles que componen el modelo OSI y su corres‐pondencia con aquellos definidos en el estándar IEEE 802.3. De forma resumida, las tareas asociadas con cada nivel son:

1 Nivel físico. Esta capa proporciona el servicio de transmisión transparente de secuencias de bits sobre el medio físico, incluyendo la adecuada señalización, sincro‐nización, multiplexión, recuperación de reloj, etc.

2 Nivel de enlace. Se ocupa de la transmisión ordenada de bloques de bits o tramas libres de error, incluyendo una forma de direccionamiento físico, control de flujo, control de acceso a la red, etc.

Figura 3.1: El modelo OSI y su relación con Ethernet


3 Nivel de red. Proporciona un servicio de encaminamiento de paquetes de datos desde un origen hasta un destino que puede pertenecer a otra red, proporcionando además direcciones de red a la capa de transporte.

4 Nivel de transporte. Esta capa provee a los niveles superiores de un servicio de transferencia de información independiente de los detalles de la red, incluyendo la conversión de direcciones de red, secuenciación, corrección de errores, etc.

5 Nivel de sesión. Establece, gestiona y finaliza las conexiones entre los procesos o aplicaciones finales.

6 Nivel de presentación. Realiza conversiones en la representación interna de los datos, de manera que distintos equipos puedan trabajar con ellos.

7 Nivel de aplicación. Ofrece a los usuarios la posibilidad de acceder a los servicios del resto de capas. Los niveles cinco, seis y siete suelen a menudo fusionarse en un único nivel de aplicación que se comunica directamente con la capa de trans‐porte, razón por la que se ha utilizado en la figura 3.1 el mismo color para representarlos.

Como se observa en la figura, el nivel de enlace se corresponde con dos subcapas del modelo IEEE 802.3. En la cima se sitúa la capa «cliente MAC», que se encarga de proporcionar una interfaz entre la capa MAC de Ethernet y el nivel de red superior denominada «Control Lógico del Enlace» (LLC), o bien actúa como capa puente entre dos redes LAN. Las defini‐ciones de esta subcapa no son específicas de Ethernet, sino comunes en toda la familia de protocolos de red IEEE 802.

La capa MAC controla el acceso del dispositivo al medio y es diferente en cada protocolo Ethernet individual, aunque todas las capas MAC de la familia IEEE 802.3 deben cumplir al menos con un mismo conjunto básico de requerimientos lógicos, independientemente de si incluyen o no alguna de las extensiones definidas.

Por su parte, la capa física depende de la tasa de transmisión, de la codificación de canal y del medio físico empleado. Por ejemplo, Gigabit Ethernet puede operar sobre cable de pares o sobre fibra óptica, pero cada tipo de medio requiere una implementación distinta de este nivel.

3.1.2 Topologías de red

Las primeras redes Ethernet se implementaron mediante segmentos de bus de cable coaxial, existiendo limitaciones en la longitud de estos segmentos y en el número máximo de nodos que se podían enlazar.

Sin embargo, desde principios de la pasada década la configuración más común es la de estrella, ilustrada en la figura 3.2, donde múltiples dispositivos se conectan mediante enlaces punto a punto con un nodo central que puede ser un repetidor o un switch.

Con esta topología se eliminan los problemas de colisión en el acceso al medio, puesto que éste deja de ser compartido, haciendo posible el funcionamiento en modo full‐duplex.

INTRODUCCIÓN A ETHERNET 37

3.1.3 La capa MAC

La capa MAC de Ethernet se encarga de dos tareas fundamentales:

• Ensamblado de datos, incluyendo la formación de tramas de bits antes de la trans‐misión y la detección de errores durante y después de la recepción.

• Control de acceso al medio, marcando el comienzo de la transmisión de tramas y proporcionano un mecanismo de recuperación en caso de error.

Formato básico de las tramas Ethernet

Como se indicó con anterioridad, el estándar IEEE 802.3 define un formato de trama requerido en todas las implementaciones MAC de Ethernet y que proporciona una funcionalidad básica. Este formato consta de siete campos, que se transmiten en el siguiente orden:

• Preámbulo. Consiste en un patrón de bits alternante con una longitud de 7 bytes que permite la sincronización de la capa física de recepción.

• Delimitador de comienzo de trama, con una longitud de 1 byte.

• Dirección de destino. Campo de 6 bytes que identifica el nodo individual (en el caso de las direcciones unicast) o el grupo de nodos (direcciones multicast o broadcast) a los que va dirigida la trama. Este tipo de dirección física se conoce como dirección MAC y es única para cada dispositivo fabricado.

• Dirección de origen. Similar al anterior, con la salvedad de que en este caso sólo puede tratarse de una dirección unicast.

• Longitud/Tipo. Campo de 2 bytes. Si tiene un valor menor o igual a 1500, el campo indica el número de bytes de datos enviados por la capa cliente MAC que contiene la trama. Si el valor es mayor de 1536, el campo es un identificador del protocolo de nivel superior transportado por la trama Ethernet.

• Datos. Secuencia de bytes de cualquier tipo que contiene la carga útil de la trama enviada por los protocolos de nivel superior. Tiene una longitud máxima de 1500 y mínima de 46, por lo que si el número de bytes enviado por la capa cliente MAC es inferior a este mínimo, este campo se extiende con bytes de relleno.

Figura 3.2: Ejemplo de topología en estrella


• Secuencia de verificacíon de trama. Consiste en un código CRC de 4 bytes que se cal‐cula en el transmisor sobre los campos de dirección, longitud y datos y se recalcula en recepción para detectar tramas erróneas.

Cuando la capa MAC recibe una petición de transmisión, se forma una trama con los campos indicados anteriormente que se almacena en el buffer de transmisión. El siguiente paso depende de si la MAC está operando en modo half‐duplex o full‐duplex.

Modo de transmisión half-duplex

En este modo de operación, la MAC no puede recibir y transmitir tramas de manera simul‐tánea. Según se define en el estándar IEEE 802.3, todas las implementaciones MAC de Ethernet deben soportar este modo de transmisión, mientras que el modo full‐duplex, que se describirá más adelante, es opcional.

El modo half‐duplex sigue una serie de reglas de acceso al medio definidas en el protocolo CSMA/CD (del inglés Carrier Sense Multiple Access with Collision Detection). Este protocolo se desarrolló originalmente para topologías de bus, y proporciona una forma de acceso compartido al medio físico en el que cada nodo MAC es capaz de determinar los tiempos de acceso sin necesidad de arbitraje externo.

El funcionamiento de CSMA/CD es simple. Cada elemento de la red monitoriza conti‐nuamente el canal y puede comenzar a transmitir en cualquier momento en el que éste se encuentre libre. En el caso de que dos o más nodos comiencen a transmitir aproximadamente en el mismo tiempo, sus señales interferirán y se producirá una colisión. Cada nodo debe entonces ser capaz de detectar la colisión y esperar un tiempo aleatorio antes de intentar la retransmisión de la trama.

Debido a los retardos de propagación de la señal en el medio, existe una limitación en la longitud máxima de los enlaces y en el tamaño mínimo de las tramas para asegurar la correcta detección de las colisiones. Estas limitaciones son más estrictas cuanto mayor es la tasa de transferencia.

Modo de transmisión full-duplex

La topología de red en estrella como la mostrada en la figura 3.2 permite este modo de operación opcional de la capa MAC de Ethernet, funcionalmente mucho más simple que half‐duplex puesto que no requiere control de acceso, detección de colisiones o retransmisión de tramas.

Con este esquema se consigue doblar el ancho de banda disponible, aunque la operación en modo full‐duplex requiere la implementación también opcional de un mecanismo de control de flujo para evitar la saturación de los dispositivos receptores.

3.1.4 La capa física

Como se indicó con anterioridad, la capa física de Ethernet define entre otras cosas la tasa de transmisón, la codificación de canal y el tipo de medio empleado. Estos tres factores pueden identificarse en la nomenclatura empleada para definir cada variante de Ethernet, por ejemplo:

ALTERNATIVAS DE IMPLEMENTACIÓN 39

• 10Base‐T: 10 Mbps, transmisión en banda base sobre cable de pares.

• 100Base‐T4: 100 Mbps, transmisión en banda base sobre cuatro pares.

• 1000Base‐LX: 1000 Mbps, transmisión en banda base sobre sobre fibra óptica.

Aunque no se pretende aquí detallar las diferentes opciones de codificación de señal definidas en la IEEE 802.3, se puede decir que todas deben proporcionar un método de recupe‐ración del reloj en recepción.

Una característica opcional e importante implementada completamente en el nivel físico es la «autonegociación». Mediante la autonegociación dos nodos pueden comunicar sus capacidades (como por ejemplo la velocidad máxima o el soporte del modo full‐duplex) con el fin de elegir la mejor configuración común antes de iniciar la transmisión. La autonegociación se realiza durante el tiempo de establecimiento del enlace y no requiere de ningún tipo de intervención por parte de la capa MAC o de protocolos de nivel superior.

3.2 Alternativas de implementaciónUna vez introducidas las características más importantes de Ethernet y su particular adaptación a los sistemas integrados, se enumerarán en este apartado las alternativas de diseño que se han considerado en la fase previa al desarrollo del hardware.

Como se sabe del primer capítulo, el conjunto de requerimientos del controlador OSC no se definió de manera estricta al establecer los objetivos del proyecto. Sin embargo se pueden considerar como deseables las siguientes características:

• Coste reducido.

• Disponibilidad de herramientas de software que faciliten el desarrollo de la aplica‐ción, especialmente un compilador y una pila de protocolos de Internet.

• Conectividad Ethernet básica. Dada la naturaleza del sistema, sólo se requiere el envío unidireccional de paquetes pequeños de datos (del orden de 100 bytes) a baja tasa de transmisión1, por lo que una interfaz 10Base‐T half‐duplex será suficiente.

Conociendo estas características, se plantearon las siguientes alternativas como base de diseño del controlador OSC:

Módulo hardware prefabricado

En el mercado existe una amplia gama de módulos prefabricados que contienen todo el hardware necesario para construir un sistema microprocesador con conexión Ethernet2, permi‐tiendo concentrar los esfuerzos de diseño en el software de la aplicación.

Estos módulos disponen normalmente de un potente microprocesador con una gran cantidad de puertos de entrada y salida, memoria externa y multitud de periféricos. Además suelen incluir todo el software necesario para su programación y una pila TCP/IP. Por estas

1. Un muestreo inferior a 200 Hz es normalmente suficiente para los objetivos que se pretenden.2. Véanse por ejemplo los módulos comercializados por Netburner o Rabbit Semiconductor.


razones constituyen una buena opción de diseño cuando el tiempo de desarrollo del producto es crítico, y su coste puede ser aceptable para la comercialización de un número medio de dispositivos.

Sin embargo, el empleo de uno de estos módulos en el presente proyecto se rechazó por las siguientes razones. En primer lugar, constituía la alternativa más cara de las consideradas, especialmente al tener en cuenta que en la mayoría de las ocasiones, además del hardware, es necesario adquirir un kit de desarrollo cuyo coste no está justificado para la implementación de un único dispositivo.

Por otra parte se ofrecían características totalmente prescindibles para la aplicación que nos ocupa. Aunque esto puede parecer una ventaja, lo cierto es que supone un aumento innecesario de la complejidad del sistema y de su coste.

Por último, la utilización de un módulo prefabricado supone la abstracción completa del hardware subyacente, y por tanto va en contra del objetivo pedagógico de este proyecto.

Controlador Ethernet externo

Como se indica al comienzo del capítulo, hasta hace pocos años todos los chips controladores Ethernet existentes en el mercado fueron diseñados para su uso en la industria de los PCs. De entre ellos, uno de los que ha alcanzado mayor popularidad en el marco de los sistemas integrados es el RTL8019 de Realtek, debido a que se basa en una interfaz ISA relativamente simple, que puede configurarse para su funcionamiento en 8 o 16 bits de datos. Aún así, se trata de un dispositivo complejo en un formato PQFP de 100 pines que requiere un mínimo de 15 líneas para la comunicación con el microcontrolador.

En el 2005 Microchip lanzó al mercado un controlador Ethernet 10Base‐T de caracterís‐ticas similares enfocado a aplicaciones integradas, el ENC28J60. Sus ventajas más relevantes son:

• Con sólo 28 pines, se anunció como el controlador Ethernet más pequeño del mundo. Esta reducción de tamaño implica una menor complejidad de la placa y por tanto, menores costes de producción. Su disponibilidad en formato DIP facilita la realización de prototipos y es especialmente deseable en una aplicación como la que nos ocupa.

• La comunicación con el microprocesador se realiza mediante un bus SPI estándar de sólo 4 líneas. Esto supone la posibilidad de emplear procesadores con un menor número de entradas y salidas y, por consiguiente, más baratos.

• Microchip ofrece de forma gratuita un driver para su manejo y una pila de protoco‐los TCP/IP, ambas escritas en lenguaje C.

• El coste unitario del dispositivo es inferior a 3 $, con la posibilidad de obtener mues‐tras gratuitas en diferentes formatos para el desarrollo de prototipos.

Por todas estas ventajes se decidió seleccionar esta alternativa de diseño. El siguiente apartado se dedicará a una descripción más detallada del ENC28J60.

EL CONTROLADOR ENC28J60 41

Microcontrolador con controlador Ethernet integrado

Recientemente han aparecido soluciones monolíticas que integran un microprocesador y un controlador Ethernet en el mismo chip. Esto tiene la ventaja de reducir aún más el coste, el tamaño la placa y la complejidad del sistema.

Por tratarse de procesadores simples (arquitectura de 8 bits) y de mediana potencia, se consideró en un principio la familia de microcontroladores PIC18F97J60 de Microchip. Sin embargo esta opción se desechó por las siguientes razones:

• El único formato disponible para toda esta familia es el TQFP de 64, 80 o 100 pines, lo que dificulta enormemente el diseño del PCB y hace virtualmente imposible su soldadura manual.

• La durabilidad de la memoria FLASH es limitada, con tan sólo 100 ciclos de borrado y escritura, lo que hace a estos dispositivos poco adecuados para el desarrollo y la depuración de aplicaciones.

• Aunque no es determinante, la ausencia de memoria EEPROM interna es otro factor en contra de estos microcontroladores.

3.3 El controlador ENC28J60El ENC28J60 de Microchip es un controlador Ethernet 10Base‐T diseñado para su uso en sistemas de control integrados. Debido a su reducido tamaño (sólo 28 pines) y a su interfaz de comunicación serie SPI, ha alcanzado una enorme popularidad y actualmente es usado en numerosas aplicaciones comerciales.

En la figura 3.3 se muestra el diagrama de bloques simplificado de la estructura del dispositivo. En referencia a éste, y como resumen global de características, se pueden destacar los siguientes puntos [ENC06]:

• El dispositivo integra tanto la capa física (PHY) Ethernet a 10 Mpbs como la corres‐pondiente capa MAC de acceso al medio, en base al estándar IEEE 802.3. Como se sabe de apartados anteriores, la capa PHY comprende toda la circuitería analógica necesaria para la codificación y decodificación de datos en el canal, mientras que la capa MAC se encarga del control de la transmisión y la recepción de tramas, la detección de colisiones, el cálculo de CRCs, etc.

Figura 3.3: Estructura funcional del ENC28J60


• El ENC28J60 contiene una memoria RAM de doble puerto de 8 KBytes, que el micro‐controlador puede asignar como buffer de transmisión o de recepción. Esta caracte‐rística proporciona un método eficiente de almacenamiento y modificación de paquetes, liberando al procesador de las tareas asociadas a la administración del buffer y eliminando necesidades adicionales de memoria RAM.

• Una de las características más relevantes del ENC28J60 es su interfaz de comunica‐ción con el microcontrolador, basada en un bus SPI que requiere sólo cuatro líneas: dos para la transferencia bidireccional de los datos, una para sincronización y otra línea para la selección del dispositivo. Esto permite que incluso los procesadores con un número reducido de líneas de entrada y salida puedan ser empleados en este tipo de aplicaciones.

El dispositivo es capaz de funcionar en los modos full‐duplex y half‐duplex. Sin embargo, es importante mencionar que la capa física no soporta la autonegociación, lo que en la práctica supone que se suela configurar en modo half‐duplex para maximizar su compatibilidad1.

Otras cualidades interesantes de la MAC del ENC28J60 son el filtrado configurable de paquetes y la posibilidad de interrumpir la ejecución de código en el microprocesador como respuesta a hasta 6 tipos diferentes de eventos, incluyendo Wake‐On‐LAN2.

En cuanto a sus características eléctricas, el ENC28J60 es un dispositivo que requiere 3.3V de alimentación; sin embargo, sus entradas soportan niveles lógicos de 5V, facilitando su integración en sistemas que trabajan con esta tensión de alimentación.

Por último, es destacable la existencia de una API gratuita de acceso al controlador, proporcionada por el fabricante y compatible con varios compiladores, que facilita considera‐blemente su operación y permite al usuario abstraerse de detalles específicos sobre la estructura interna del dispositivo. Por este motivo no se dará aquí más información acerca de estos detalles, aunque el lector interesado podrá encontrar una extensa descripción de los mismos en la hoja de características correspondiente [ENC06].

1. Recordemos que, según el estándar, el modo half‐duplex es el único cuyo soporte es reque‐rido en todas las implementaciones de controladores Ethernet.

2. Esta característica permite «despertar» a un microprocesador que estaba previamente en modo de ahorro energético al producirse la recepción de un paquete con un formato predefi‐nido.

4capítulo

Hardware del controlador OSC

na vez estudiadas las distintas opciones de diseño, se procederá a la descripción en profundidad la configuración hardware del controlador OSC basada en la alternativa

elegida: el ENC28J60.

En la primera parte de este capítulo se justificará la elección del microcontrolador que constituye el núcleo de la aplicación. Posteriormente se detallarán los aspectos de diseño, reali‐zando una separación del hardware en bloques funcionales. Finalmente se describirá el proceso de diseño CAD del controlador y su implementación física.

4.1 El microcontrolador PIC18F4620La elección correcta del microcontrolador es una de las partes más críticas en el diseño de la aplicación, dado que tiene un gran impacto en el coste del producto, el tiempo de desarrollo y el rendimiento final.

En el caso particular del dispositivo objeto del presente proyecto, la utilización del controlador Ethernet ENC28J60 es una razón fundamental que inclina la balanza hacia la elección de un microcontrolador de Microchip. Esto se debe principalmente a la disponibilidad de la pila gratuita de protocolos TCP/IP que proporciona el fabricante y que da soporte directo a estos dispositivos, minimizando considerablemente el tiempo de desarrollo. Por otro lado, con una gama de más de 350 microcontroladores, Microchip se ha consolidado como un líder en el mercado, especialmente en arquitecturas de 8 bits.

Dada la naturaleza flexible de la aplicación y por extensión de los objetivos de diseño, hay una gran variedad de microcontroladores de este fabricante que cumplen con el único requisito que existe a priori: la disponibilidad de un puerto SPI para la comunicación con el ENC28J601.

1. En realidad este requisito no es estricto, puesto que es posible emular en software el compor‐tamiento de un bus SPI usando líneas de entrada y salida de propósito general.

U

43

CAPÍTULO 4: HARDWARE DEL CONTROLADOR OSC44

Tras una exhaustiva búsqueda y comparación basada en parámetros como la cantidad de memoria, la potencia de cálculo o el conjunto de periféricos integrados, se decidió basar el diseño en un microcontrolador PIC18F4620 por las razones que se exponen a continuación:

• Con una arquitectura RISC Harvard de 8 bits y hasta 10 MIPS, el procesador cuenta con la potencia de cálculo suficiente para cumplir con los objetivos de la aplicación, por lo que el coste adicional que supondría la elección de un dispositivo de 16 bits o superior no estaría justificado en este caso.

• Dispone de una memoria FLASH de 64 KB capaz de alojar hasta 32.768 instruccio‐nes, así como de 3986 bytes de RAM. Hay que tener en cuenta que, según especifica el fabricante, una implementación sencilla de la pila TCP/IP proporcionada que incluya soporte para UDP puede construirse con aproximadamente 30 KB de código, con lo que la cantidad de memoria ROM disponible es adecuada para los propósitos del proyecto. Por otro lado, la elevada durabilidad de la memoria FLASH, con típicamente 100.000 ciclos de borrado y escritura, es una clara ventaja para el desarrollo y la depuración de software.

• Su memoria EEPROM interna de 1 KB proporciona un método seguro y conveniente de almacenamiento de información no volátil, como por ejemplo los parámetros de configuración del sistema.

• El PIC18F4620 integra un convertidor ADC con una resolución de 10 bits y un máximo de 13 canales. Como se sabe, este módulo resulta de especial utilidad en la aplicación, dado que minimiza el coste y la complejidad adicional que supone el empleo de un convertidor externo. Además, una resolución de 10 bits es suficiente para los objetivos buscados1.

• Otros periféricos integrados aportan aún más flexibilidad al microcontrolador. De entre ellos, se pueden mencionar sus temporizadores de 8 y 16 bits, USART, compa‐radores, PWM, puerto paralelo, etc. Estos periféricos suelen estar asociados a algu‐nas de las 36 líneas de entrada y salida disponibles.

• La programación puede hacerse de manera sencilla con el dispositivo alojado en la placa de circuito impreso. Esta técnica se denomina In‐Circuit Serial Programming (ICSP) y requiere sólo 2 líneas para su funcionamiento. Por otra parte, el microcon‐trolador integra una lógica específica que permite la depuración de código mientras se ejecuta. Esta característica recibe el nombre de In‐Circuit Debug (ICD). Ambas tec‐nologías resultaron de gran utilidad en el desarrollo del proyecto, como se verá a lo largo de la memoria.

• Otras características interesantes son la capacidad de autoprogramación de la memoria FLASH (útil para las actualizaciones de firmware mediante bootloaders), el multiplicador hardware, las interrupciones con dos niveles de prioridad o la posibi‐lidad de utilizar el dispositivo con un juego extendido de instrucciones (especial‐mente adecuado para la ejecución de código reentrante escrito en lenguajes de alto nivel como C).

1. Recordemos que la resolución de un controlador MIDI equivalente es de sólo 7 bits.

PROCESO DE DISEÑO 45

• El dispositivo soporta un amplio rango de tensiones de alimentación y de modos de oscilador.

• El microcontrolador está disponible en una amplia gama de formatos de 40 o 44 pines. Su existencia en encapsulado DIP es especialmente deseable en esta aplica‐ción particular puesto que simplifica la implementación de la placa de circuito impreso y la soldadura manual.

4.2 Proceso de diseñoEn el apartado anterior se han expuesto las razones que motivaron la elección concreta del microcontrolador PIC18F4620, en parte como consecuencia de la primera alternativa escogida: el controlador Ethernet ENC28J60. En adelante se detallará la disposición de estos compo‐nentes en el marco del presente trabajo.

El hardware del controlador OSC se ha separado en dos placas de diferente funciona‐lidad y complejidad. En la figura 4.1 se muestra un diagrama de bloques muy simplificado de cada una de estas placas, donde por claridad se han omitido detalles acerca de las tensiones de alimentación, la generación de las señales de reloj y otros componentes externos necesarios para el correcto funcionamiento.

La placa principal es el núcleo de la aplicación, y contiene todo el hardware necesario para desarrollar el software y comprobar su funcionamiento básico. Para dotarla de mayor flexibilidad, se ha procurado implementarla como una placa de desarrollo genérica indepen‐

Figura 4.1: Diagrama de bloques del controlador OSC


diente de la aplicación final. Con este fin el acceso a los puertos de entrada y salida de propósito general del microcontrolador se realiza a través de un conector estándar que permite la conexión de diferentes configuraciones de hardware, complementando la funcionalidad original. La placa cuenta con un puerto serie RS‐232 para su comunicación con un PC. Además, para facilitar el desarrollo de código, se han dedicado varias líneas del microcontro‐lador a la conexión de LEDs indicadores, pulsadores y potenciómetros, que en algunos casos pueden utilizarse para fines diferentes mediante el empleo de jumpers.

La segunda placa contiene los sensores analógicos y digitales que componen la interfaz de usuario. Puesto que el tipo y la configuración de estos sensores dependerán de la aplicación final, la placa sólo muestra una de las posibilidades que ofrece el controlador OSC. Como sensores analógicos se han utilizado una serie de potenciómetros deslizantes, mientras que un conjunto de pulsadores y un codificador binario rotativo constituyen los sensores digitales.

Para dar una visión más estructurada de todos los aspectos de diseño, en el resto del apartado se dividirá el conjunto en bloques funcionales, que se estudiarán por separado.

4.2.1 Microcontrolador

El primer y más importante bloque funcional lo constituye el propio microcontrolador. De sus características dependen en gran medida el resto de componentes de la placa. Tras una lectura detallada de la hoja de características del dispositivo [PIC07], se optó por la configuración que se expone a continuación.

4.2.1.1 Alimentación y frecuencia de funcionamiento

Como todos los dispositivos de la familia PIC18, el PIC18F4620 está disponible en una versión estándar y en otra de bajo voltaje. Los dispositivos estándar, designados con F en su nomen‐clatura (PIC10F4620), admiten un rango de tensiones de alimentación que va desde los 4.2V hasta los 5.5V. Por su parte, los dispositivos de bajo voltaje admiten un rango extendido de 2.0V a 5.0V, y se designan con LF (PIC18LF4620).

Figura 4.2: Relación voltaje-frecuencia del PIC18LF4620


Dado que el ENC28J60 es un dispositivo de 3.3V, resulta en principio deseable el empleo de un microcontrolador de bajo voltaje, alimentando todo el circuito a esta tensión y elimi‐nando la necesidad de utilizar componentes adicionales para realizar la conversión de los niveles de tensión. Existe, sin embargo, una importante dependencia entre la frecuencia máxima de operación del microcontrolador y su tensión de alimentación, como se observa en la figura 4.2.

Según esta gráfica, la frecuencia máxima de funcionamiento del microcontrolador cuando se alimenta a 3.3V es de 25 MHz, lo que supone una reducción de rendimiento del 37.5% frente a un dispositivo que opere a una frecuencia de 40 MHz. Puesto que el manejo de la pila de protocolos TCP/IP conlleva una carga computacional considerable, y con el fin de maximizar el rendimiento final1, se decidió alimentar el microcontrolador a una tensión de 5V. Esta decisión no implica un excesivo aumento del coste y la complejidad del circuito, en parte por la compatibilidad de las entradas del ENC28J60 con niveles lógicos de 5V.

El PIC18F4620 puede funcionar en diez modos de oscilador diferentes, seleccionables durante la programación del dispositivo mediante un registro de configuración. Estos modos pueden separarse en cuatro grupos, dependiendo del tipo de componentes externos que se requieran:

• Resonador cerámico o cristal de cuarzo. Los diferentes modos de este grupo depen‐den fundamentalmente de la frecuencia de oscilación deseada. En el modo HSPLL la frecuencia del oscilador se multiplica internamente por 4 mediante un circuito PLL.

• Oscilador RC. Estos modos permiten reducir el coste al prescindir de un resonador de cuarzo, aunque sólo son útiles en aplicaciones poco sensibles a las variaciones de la frecuencia del reloj, dado que ésta puede depender de factores como la tempera‐tura ambiente, la tensión de alimentación o la tolerancia de los componentes que conforman la red RC.

• Entrada de reloj externa. En estos modos la señal de reloj procede de un dispositivo externo, por lo que no se requieren componentes adicionales.

• Oscilador interno. El PIC18F4620 puede generar el reloj mediante un oscilador inte‐grado en el propio chip. Esta opción permite disponer de los dos pines asociados al oscilador como líneas de propósito general, ahorrando además el coste de los com‐ponentes externos. Sin embargo es necesario realizar la calibración de la señal gene‐rada en cada microcontrolador mediante la modificación de un registro. Por otro lado, la frecuencia máxima que puede obtenerse con esta configuración es de 32 MHz, combinando el oscilador interno con el multiplicador PLL.

En la aplicación se optó por una configuración en modo HSPLL, que permite generar una señal de 40 Mhz a partir de un cristal de cuarzo con una frecuencia de resonancia de 10 MHz y el multiplicador PLL integrado en el microcontrolador. La estabilidad del oscilador se consigue mediante dos condensadores cerámicos de 20 pF, como puede verse en el esquema del circuito incluido en el apéndice A.

1. Como se verá más adelante, la tasa máxima a la que se envían los paquetes OSC estará limi‐tada por la capacidad de procesamiento del microcontrolador, y no por el ENC28J60 o por el bus SPI.


4.2.1.2 Programación ICSP

Para la programación del microcontrolador se ha utilizado un depurador hardware compa‐tible con el ICD‐2 de Microchip, que se construyó como parte de un trabajo relacionado con el presente proyecto fin de carrera. En el apéndice B de la memoria el lector encontrará más información acerca de este trabajo y de otras alternativas de programación y depuración de los microcontroladores PIC.

Como se ha indicado previamente, la tecnología ICSP permite la programación del microcontrolador mientras se encuentra alojado en la placa de circuito impreso, reduciendo considerablemente el tiempo de desarrollo. Esta técnica requiere el uso exclusivo de las líneas PGD y PGC para este fin1. PGD es una línea bidireccional de datos, mientras que PGC es una señal de reloj procedente del programador.

La conexión del microcontrolador con el dispositivo programador se realiza por medio de un conector modular estándar de 6 pines como se muestra en el diagrama de la figura 4.3, extraído de los esquemáticos adjuntados en el apéndice A.

El resto de componentes conforman una configuración típica recomendada por el fabri‐cante [ICSP]. Las líneas PGD y PGC son dedicadas, y se conectan de forma directa al microcon‐trolador, así como la tierra (GND) y la tensión de alimentación (VCC). Por otro lado, el pin de reset (MCLR) del microcontrolador se mantiene normalmente a nivel alto mediante una resis‐tencia de pull‐up y un condensador de filtrado. Esta capacidad tiene un efecto negativo que puede afectar a la operación del programador, razón por la que se incluye el diodo Schottky. Además, este diodo aisla al resto del circuito de la tensión de programación, que puede elevar el voltaje del pin MCLR hasta los 13V.

4.2.1.3 Asignación de líneas de entrada y salida

El PIC18F4620 dispone de un máximo de 36 líneas de entrada y salida de propósito general, repartidas en cinco puertos. La disponibilidad de estos pines para la conexión de sensores depende de la configuración del dispositivo, puesto que suelen estar asociados a un deter‐minado periférico, o bien son necesarios para otras tareas como por ejemplo la programación ICSP. En la siguiente tabla se indica el nombre de cada línea de entrada y salida y su función particular en el circuito diseñado.

1. Aunque posible, el fabricante recomienda evitar el uso compartido de estas líneas que, en cualquier caso, deben aislarse del resto del circuito.

1

2

3

4

ICSP

5

6

312

4

S1

D2

R13 C17

GNDVCC

RESET

PGCPGD

MCLR

Re

se

t

1N

5819

10K

GND

100n

VC

C

Figura 4.3: Interfaz ICSP y reset de usuario


Pin Función asignada

Puerto A RA0/AN0 Entrada analógica AN0

RA1/AN1 Entrada analógica AN1

RA2/AN2/VREF-/CVREF Entrada analógica AN2

RA3/AN3/VREF+ Entrada analógica AN3

RA4/T0CKI/C1OUT Indicador LED amarillo

RA5/AN4/SS/HLVDIN/C2OUT Entrada analógica AN4

OSC2/CLKO/RA6 Salida de realimentación del oscilador principal OSC2

OSC1/CLKI/RA7 Entrada del oscilador principal OSC1

Puerto B RB0/INT0/FLT0/AN12 I/O Digital RB0

RB1/INT1/AN10 I/O Digital RB1

RB2/INT2/AN8 Entrada de interrupción externa del ENC28J60

RB3/AN9/CCP2 Salida de chip select del controlador ENC28J60

RB4/KBI0/AN11 Salida de chip select de la EEPROM 25LC1024

RB5/KBI1/PGM Salida de reset del controlador ENC28J60

RB6/KBI2/PGC Entrada de reloj para programación y depuración ICSP

RB7/KBI3/PGD I/O serie para programación y depuración ICSP

Puerto C RC0/T1OSO/T13CKI Indicador LED rojo

RC1/T1OSI/CCP2 Indicador LED rojo

RC2/CCP1/P1A Indicador LED rojo

RC3/SCK/SCL Salida de reloj SCK para comunicación por bus SPI

RC4/SDI/SDA Entrada SDI para comunicación por bus SPI

RC5/SDO Salida SDI para comunicación por bus SPI

RC6/TX/CK Salida TX del módulo serie asíncrono USART

RC7/RX/DT Entrada RX del módulo serie asíncrono USART

Puerto D RD0/PSP0 I/O Digital RD0

RD1/PSP1 I/O Digital RD1




RD5/PSP5/P1B I/O Digital RD5

RD6/PSP6/P1C I/O Digital RD6

RD7/PSP7/P1D I/O Digital RD7

Puerto E RE0/RD/AN5 Entrada analógica AN5

RE1/WR/AN6 Entrada analógica AN6

RE2/CS/AN7 Entrada analógica AN7

MCLR/VPP/RE3 Entrada de reset maestro MCLR

Tabla 4.1: Asignación de puertos de entrada y salida


En la tabla 4.1 se han señalado en negrita las líneas analógicas y digitales disponibles para la conexión de los sensores de mando en la placa de controles. La conexión entre el micro‐controlador y esta placa se realiza directamente mediante un cable plano de 20 vías, tal como se muestra en la figura 4.4.

4.2.1.4 Módulo USART

Con el fin de dotar de mayor flexibilidad al circuito, y dado que el microcontrolador dispone de un número suficiente de líneas de entrada y salida para la conexión de los sensores del controlador OSC, se decidió emplear el módulo serie USART que integra el microcontrolador para establecer una interfaz de comunicación RS‐232. Esto permite la conexión de la placa con un PC a través de un puerto serie estándar.

Para la conversión entre los niveles lógicos TTL del módulo USART y los requeridos por la señalización RS‐232, se utilizó un convertidor MAX232 según una configuración típica especificada por el fabricante, como se indica en la figura 4.5. Este dispositivo requiere la conexión externa de cuatro condensadores para la generación de las tensiones de funciona‐miento y uno más de desacoplo que estabiliza su propia tensión de alimentación de 5V.

El MAX232 permite la traslación de nivel de dos pares de señales en ambos sentidos de la comunicación. De ellas sólo se conectaron las dos señales imprescindibles para establecer la transferencia: la señal de recepción RD y la de transmisión TD.

1

JP

2

2

1 2

3 4

5 6

7 8

9 1011 12

13 14

15 16

17 18

19 20

CON1

AN0AN1AN2AN3AN4AN5AN6AN7

RB1

RD0RD1RD2RD3RD4RD5RD6RD7RB0

VC

C

GND

Figura 4.4: Líneas disponibles para la conexión de sensores

++

+

+ +

C1+1

C1-3

C2+4

C2-5

T1IN11

T2IN10

R1OUT12

R2OUT9

V+2

V-6

T1OUT14

T2OUT7

R1IN13

R2IN8

IC3

16

15

GN

DV

CC

IC3P

16

27

3849

5

DB9M

C18

C19

C20

C21R14 C28

TX

RX

MAX232

1u

1u

1u

1u

GND10

VC

C

GND

VC

C

1u

Figura 4.5: Interfaz USART / RS-232


4.2.2 Controlador Ethernet ENC28J60

El segundo bloque funcional de la placa, por orden de importancia, lo constituye el ENC28J60. A diferencia del microcontrolador este dispositivo de 3.3V no admite modos diferentes de oscilador, y precisa para su funcionamiento de la conexión de un cristal de 25 MHz. Se estudiarán por separado los aspectos de diseño de la interfaz Ethernet del dispositivo y aquellos relacionados con la conexión al microcontrolador mediante el bus SPI.

4.2.2.1 Interfaz Ethernet

Para completar la interfaz física de Ethernet, el ENC28J60 requiere de la conexión de algunos componentes externos cuyo valor y disposición se especifican en la hoja de características del dispositivo [ENC06] y que se muestran por conveniencia en la figura 4.6. Se procederá a conti‐nuación a comentar este diagrama de conexión.

La resistencia RBIAS tiene un impacto directo en la amplitud de la señal de salida (TPOUT), por lo que cualquier valor diferente del especificado puede provocar la operación del dispositivo fuera de los márgenes de la especificación. Lo mismo ocurre con las resistencias de terminación de línea conectadas a los pares TPIN y TPOUT; cada par debe igualar la impedancia característica de la línea de transmisión (cuyo valor es de 100 Ω) para evitar reflexiones de señal no deseadas.

Por otro lado, el aislamientro entre el circuito y el cable de pares Ethernet debe realizarse mediante un par de transformadores de acoplamiento con una relación 1:1, que no se muestran en el diagrama de la figura 4.6 al estar integrados en el propio conector Ethernet. Este conector, del fabricante XFMRS, cumple con todas las especificaciones eléctricas reque‐ridas por el ENC28J60 como su inductancia mínima y otros parámetros de aislamiento. El conector incluye además dos LEDs que se conectan al controlador Ethernet para indicar del estado de la conexión.

Aunque no es necesario para el funcionamiento experimental del dispositivo, el fabri‐cante aconseja la utilización del núcleo de ferrita L1 en cualquier aplicación comercial, cuya finalidad es la reducción de EMI.

+

VCAP1

VS

S2

CLKOUT3

INT4

NC5

SO6

SI7

SCK8

CS9

RESET10

VS

SR

X1

1

TPIN-12

TPIN+13

RBIAS14

VD

DT

X1

5

TPOUT-16

TPOUT+17

VS

ST

X1

8V

DD

PL

L2

0V

DD

RX

19

VS

SP

LL

21

VS

SO

SC

22

OSC123

OSC224

VD

DO

SC

25

LEDB26

LEDA27

VD

D2

8IC21

23

IC4A

10

98

IC4C

21

XT2

J-L

J-R

1

2

3

4

J-LAN

5

6

L1

R2

R3

R4

R5

R6

C7

C8

C9

C10

R7

R8

C11

C12C13C14C15

R9

R10

R11

1

2

3JP1RESET

RB5

RB2

SDI

SDO

SCK

RB3

ENC28J60-DIL

74HCT125N

74HCT125N

25M

XFATM9GB

Ferrite Bead

49R

9 1

%

49R

9 1

%

49R

9 1

%

49R

9 1

%

2K

32 1

%

10u

100n

GNDGND GND

20p

20p

330

330

GND GND GND

100n

GND

GND

100n100n100n100n

GND

200

200

200

GND

+3V

3

Figura 4.6: Componentes externos del controlador ENC28J60


4.2.2.2 Comunicación mediante bus SPI

El bus SPI (del inglés Serial Peripheral Interface) es un enlace serie síncrono con capacidad para la transmisión full‐duplex que permite la comunicación de un dispositivo maestro con uno o varios dispositivos esclavos. Requiere para ello de cuatro líneas:

• SCK, señal de sincronismo que proviene del dispositivo maestro.

• SDI, entrada de datos serie.

• SDO, salida de datos serie.

• CS, salida del maestro que habilita a un único esclavo para su acceso al bus (chip select).

Los distintos modos de operación de un bus SPI dependen de la manera en la que el dispositivo maestro configura la polaridad y la fase de la señal SCK, determinando los instantes de muestreo.

En la aplicación objeto del presente documento, el PIC es en todo momento el único dispositivo maestro. Existen, sin embargo, dos esclavos que comparten el bus SPI —como se muestra en la figura 4.1— y que requieren por tanto de líneas de selección independientes. Estos dispositivos son el ENC28J60 y la EEPROM serie 25LC1024.

La conexión del controlador Ethernet al microcontrolador implica la solución de dos problemas:

• Por una parte, es necesario realizar un cambio de tensión entre los niveles lógicos de 3.3V del ENC28J60 y los del microcontrolador. La conexión del PIC a las entradas del ENC28J60 no es problemática, puesto que este dispositivo soporta niveles lógi‐cos de 5V. La comunicación en el otro sentido es diferente, debido a que la entrada SPI del microcontrolador es de tipo Schmitt Trigger y tiene una VIH mínima de 4V. Esta tensión es demasiado elevada para la conexión directa de un dispositivo de 3.3V.

• Por otro lado el uso compartido del bus SPI requiere una atención especial, siendo necesario evitar el acceso simultáneo en escritura de varios dispositivos esclavo.

Para solventar ambos problemas se incluyó un buffer no inversor con salida triestado 74HCT125. De las cuatro líneas disponibles en este dispositivo sólo se emplearon dos, como se indica en la figura 4.6. Se habilita de esta manera el acceso en escritura del ENC28J60 al bus SPI únicamente cuando su señal de chip select está activa. Las entradas TTL del 74HCT125, con una VIH mínima de 2V, resultan también adecuadas para la conversión de tensiones.

En cuanto a sus características dinámicas, el 74HCT125 es un dispositivo relativamente rápido que introduce un retardo de propagación típico de 12 ns. Siendo de 10 MHz la frecuencia máxima de la señal SCK, este retardo es suficientemente pequeño como para asegurar la correcta recepción de los datos en el lado del microcontrolador.


4.2.3 La EEPROM 25LC1024

La memoria EEPROM 25LC1024 de Microchip es un dispositivo de 128 Kbytes con una interfaz de comunicación SPI que se ha incluído en la aplicación para el almacenamiento estático de datos relacionados con el servidor web integrado, como páginas HTML, hojas de estilo, imágenes, etcétera (la información acerca de este servidor se dará en el capítulo 6).

El dispositivo admite un amplio rango de tensiones de alimentación desde 2.5V a 5.5V, y su conexión al microcontrolador es inmediata una vez que se ha indicado la forma en la que se comparte el bus SPI con el ENC28J60. La señal de chip select procedente del microcontrolador y activa a nivel bajo se mantiene normalmente inactiva mediante una resistencia de pull‐up.

La EEPROM cuenta con una entrada de protección (WP) que cuando se activa impide el acceso en escritura a diferentes sectores de la memoria. Existe también una entrada de pausa (HOLD) que permite interrumpir una secuencia de transmisión —por ejemplo para atender a un dispositivo de mayor prioridad con el que se comparte el bus SPI— y retomarla posterior‐mente en el mismo punto. Ninguna de estas características tiene utilidad en esta aplicación, por lo que ambas entradas se conectaron directamente a la tensión de alimentación para deshabilitarlas.

4.2.4 Generación de las tensiones de alimentación

El PIC18F4620 y el ENC28J60 son los dispositivos que más potencia demandan en el circuito. En sus máximos absolutos, ambos pueden llegar a consumir corrientes cercanas a los 200 mA. En términos relativos el consumo de potencia del resto de dispositivos y de los sensores de mando no es determinante, por lo que se puede esperar un consumo máximo de corriente total en torno a los 400 mA.

La generación de las tensiones de alimentación de 5V y 3.3V se realiza mediante la conexión en cascada de dos reguladores con voltaje de salida fijo: un LM7805 y un TPS79633 de Texas Instruments. Ambos reguladores pueden proporcionar corrientes de hasta 1A en condiciones adecuadas de disipación de calor, por lo que serán suficientes para el circuito diseñado.

Arr

ay

EE

PR

OM

84

CS\1

SO2

HOLD\7

SCK6

SI5

WP\3 VCC

GND

IC5

R12

C29

SDISDOSCK

RB4

25LC1024P

10K

GND

VC

C

100n

Figura 4.7: La EEPROM serie 25LC1024


El conjunto de condensadores que se muestra en la figura 4.8 proporciona estabilidad a las tensiones de salida y mejora la respuesta ante transitorios. Se ha incluído también un diodo de barrera Schottky que proteje al circuito de tensiones negativas en caso de error en la conexión de la fuente de alimentación, la cual debe proporcionar al menos 7.6V para superar la caída de tensión en el diodo (aprox. 0.6V) y en el regulador LM7805 (aprox. 2V).

Es importante también mencionar el uso de condensadores de desacoplo situados física‐mente cerca de las entradas de alimentación de cada circuito integrado, importantes para la derivación a tierra de transitorios indeseados que pueden provocar un mal funcionamiento de los dispositivos.

4.2.5 La placa de controles

La placa de controles constituye el último bloque funcional del circuito. En ella residen los sensores analógicos y digitales que proporcionan los mandos del controlador OSC.

4.2.5.1 Sensores analógicos

La interfaz de control analógica se compone de 8 potenciómetros lineales deslizantes conectados a la entrada de cada canal disponible en una configu‐ración de divisor de tensión, como se muestra en la figura.

Según especifica el fabricante, la impedancia de salida máxima de las fuentes de señal analógicas a la entrada del convertidor ADC es de 2.5 kΩ. Si se desprecia la resistencia parásita del rail de alimentación y de la tierra, esta impedancia de salida máxima se produce cuando el potenciómetro se encuentra a la mitad de su recorrido, por lo que el valor máximo del mismo es de 10 kΩ.

En el circuito se emplearon potenciómetros de 4.7 kΩ a los que se conectaron condensa‐dores de filtrado para reducir el ruido a la entrada del convertidor ADC. El conjunto de sensores consume menos de 9 mA.

4.2.5.2 Sensores digitales

Con el fin de demostrar diferentes alternativas en la interfaz de control digital, se realizaron en la placa dos configuraciones de sensores, seleccionables mediante el intercambio de jumpers:

1 En la primera configuración el microcontrolador realiza la lectura directa de los 8 bits asociados al puerto D. El usuario puede modificar el valor lógico de estos bits

+++

3

2

1

PWR_JACK

VI1

2

VO3

REG1

GND

D1

C1C2C3 C5

EN

IN

GN

D

OUT

NR

REG2

C6C24C4

7805T

1N5819

10u47u100n 100n

GND GND GNDGND GND GNDGND GND

TPS79633

100n

GND

VC

C

+3V

3

100n

GND

470u

Figura 4.8: Generación de las tensiones de alimentación

AC

B

PO

T1

C1

AN0

4K

7

100n

GND

VC

C

Figura 4.9: Sensor analógico

IMPLEMENTACIÓN FÍSICA 55

mediante cuatro pulsadores y un codificador rotativo en cuadratura que conecta secuencialmente un pin común C con otros dos terminales A y B, según se muestra en el siguiente diagrama. El terminal C está conectado a tierra, mientras que A y B se mantienen normalmente a nivel alto mediante dos resistencias de pull‐up. El sentido de rotación puede determinarse a partir de la diferencia de fase entre las señales de A y B.

2 En la segunda configuración se aumenta el número de controles disponibles hasta 16 mediante el escaneo por filas y columnas de una matriz de pulsadores.

La lectura de las entradas digitales y su mapeado en mensajes OSC serán distintos para cada una de estas configuraciones. Los cambios de hardware en la placa de control deben ser objeto de especial cuidado por parte del software de la aplicación, puesto que en la segunda disposición algunos pines del microcontrolador se configuran como salidas, y una configu‐ración incorrecta puede provocar daños irreversibles al dispositivo.

4.3 Implementación físicaEl siguiente paso en el desarrollo de la aplicación consiste en el diseño de las placas de circuito impreso (PCB). El programa CAD utilizado en esta fase fue EAGLE Layout Editor. EAGLE es un editor de esquemáticos y PCBs multiplataforma, potente y fácil de usar, con características profesionales como la generación de datos CAM, la automatización de tareas mediante scripts de usuario o el trazado automático de pistas.

Figura 4.10: Operación del codificador rotativo

Figura 4.11: Diseño del PCB en EAGLE


4.3.1 Diseño CAD del circuito

El proceso comienza con la creación del esquemático del circuito, siendo en algunos casos necesaria la definición previa de algunos componentes no incluídos en las librerías estándar del programa. Un error en esta fase puede suponer el fracaso de todo el trabajo posterior, por lo que es de vital importancia comprobar su correcta ejecución. El programa facilita esta tarea mediante el chequeo de un conjunto de reglas donde se buscan problemas potenciales como terminales sin conexión, líneas cruzadas o incongruencias en la definición de entradas y salidas.

Una vez finalizada esta etapa, se aborda el diseño del PCB. El programa genera automá‐ticamente a partir del esquemático un entramado de líneas que representan los puntos a conectar, conocido en inglés como ratsnest, que puede observarse en la captura de pantalla de la figura 4.11. La adecuada disposición física de los componentes en este punto es muy impor‐tante para reducir el tamaño —y por tanto el coste— de la placa, evitando complicar demasiado el dibujo de las pistas y cumpliendo además con cualquier otro tipo de restric‐ciones físicas o eléctricas que pudieran existir. De entre las que afectan a esta aplicación en particular, destacan:

• El adecuado emplazamiento de los conectores es importante para asegurar una conexión cómoda entre las dos placas que no dificulte su operación.

• Los condensadores de desacoplo deben colocarse junto a los terminales de alimenta‐ción de cada circuito integrado.

• Se debe minimizar la longitud de las pistas entre el ENC28J60 y el conector Ethernet para evitar reflexiones espurias por desadaptación de impedancias. También es deseable la colocación de la resistencia RBIAS lo más cerca posible del ENC28J60, evitando además el dibujo de pistas adyacentes que pudieran introducir ruido por acoplamiento capacitivo.

• Por último, es aconsejable el trazado de pistas más anchas en aquellas líneas por las que circula mayor corriente, como las de alimentación y masa.

Figura 4.12: Vista del editor de esquemáticos en EAGLE

IMPLEMENTACIÓN FÍSICA 57

Tras el trazado de las pistas, el trabajo finaliza con la comprobación de un conjunto de reglas de diseño donde se detectan problemas como solapamientos o violaciones de la distancia mínima de separación entre objetos.

4.3.2 Construcción de las placas

La construcción física de las placas se ha realizado mediante el proceso fotolitográfico habitual consistente en la insolación de la placa presensibilizada positiva, revelado, atacado y soldadura. Los fotolitos utilizados a escala natural se han incluido en el apéndice A.

El resultado final puede observarse en las siguientes representaciones, así como en las fotografías del montaje incluidas en el apéndice E.

Figura 4.13: Vista 3D de la placa principal

Figura 4.14: Vista 3D de la placa de controles

tercera parte:

Software

5capítulo

Firmware del controlador OSC

n este capítulo se tratará el diseño del firmware de la aplicación. Para ello se comienza con una descripción cualitativa de algunos aspectos relacionados con el desarrollo de código

en el microcontrolador, como son la organización interna del dispositivo o las herramientas de lenguaje utilizadas. El capítulo continúa con un estudio de la pila TCP/IP de Microchip —que como se sabe es una base fundamental de la aplicación— para discutir por último la estructura del código desarrollado, con la excepción del entorno de configuración web del controlador, que se describirá en el siguiente capítulo.

5.1 Desarrollo de código para el PIC18F4620Con independencia del nivel de abstracción que puedan proporcionar las herramientas de alto nivel disponibles para el diseño de una aplicación como la que nos ocupa, el conocimiento básico de la estructura interna del microcontrolador contribuye a un desarrollo de software más eficaz y facilita la depuración de errores. Por este motivo se tratarán aquí los aspectos de mayor relevancia en el funcionamiento del microcontrolador, aunque un análisis pormeno‐rizado está fuera de los objetivos de este documento.

Seguidamente en este mismo apartado se introducirán las características del compilador de C usado durante la fase de desarrollo de código: el MPLAB C18.

5.1.1 Estructura interna del microcontrolador

Se exponen a continuación algunas características acerca del funcionamiento interno del microcontrolador con el fin de ofrecer una visión general del dispositivo. Para otros aspectos más específicos, como el manejo de periféricos, puede consultarse su hoja de características.

5.1.1.1 Organización de la memoria

El PIC18F4620 es un microcontrolador de 8 bits con arquitectura Harvard que dispone de tres tipos de memoria: memoria de programa, memoria de datos y EEPROM.

E

61

CAPÍTULO 5: FIRMWARE DEL CONTROLADOR OSC62

Como en todos los dispositivos con arquitectura Harvard, las memorias de programa y de datos usan buses diferentes, lo que permite el acceso concurrente a ambos espacios de memoria. Por otro lado, el acceso a la memoria EEPROM se realiza a través de una serie de registros de control en el espacio de memoria de datos, por lo que en la práctica puede consi‐derarse un periférico más del microcontrolador.

Se estudiarán por separado los restantes tipos de memoria:

Memoria de programa

El PIC18F4620 alberga 64 Kbytes de memoria FLASH disponibles para el almacenamiento del código de usuario. Puesto que la mayoría de las instrucciones ocupan una única palabra de 16 bits, el tamaño máximo de este código es de 32.768 instrucciones.

Dado que el direccionamiento de la memoria de programa se realiza en bytes, y que sólo existen instrucciones de 2 o 4 bytes, el incremento del contador de programa (PC) se hace de forma automática en intervalos de dos para garantizar la correcta alineación del código. Como en toda la familia PIC18, el PC tiene una anchura de 21 bits, y es accesible a través de tres registros de 8 bits que el código de la aplicación puede modificar de forma directa o indirecta.

Cuando se produce una interrupción o se invoca a una función, este registro PC se guarda automáticamente en la pila de 31 niveles implementada para permitir la continuación posterior del programa en el punto donde se produjo la llamada. Esta pila no pertenece al espacio de memoria de programa ni tampoco al de datos. El control de la misma se hace mediante un puntero de pila de 5 bits que apunta al nivel situado en su cima, característica que puede emplear un RTOS u otra aplicación de usuario para la gestión avanzada de la ejecución de código.

Además de instrucciones, la memoria de programa puede almacenar estructuras de datos estáticos, accesibles en lectura y escritura en tiempo de ejecución mediante un conjunto específico de instrucciones. Esta característica permite también la carga de programas en el microcontrolador mediante bootloaders.

Memoria de datos

Cada registro del espacio de memoria de datos tiene una dirección de 12 bits, permitiendo un rango de direccionamiento de 4096 bytes. De ellos, 128 bytes pertenecen a los registros de propósito especial (SFR), cuya finalidad es el manejo de periféricos y otras funciones del microcontrolador. El resto se denominan registros de propósito general (GPR), y están dispo‐nibles para el almacenamiento de las variables de usuario.

En figura 5.1 la se muestra el mapeo de estos registros en el espacio de memoria de datos. Se puede observar cómo este espacio está particionado en 16 bancos de 256 bytes cada uno. Dado que la mayoría de las instrucciones incluyen sólo los 8 bits menos significativos de la dirección de memoria a la que hacen referencia, es necesario completar esta dirección mediante la modificación previa de un registro de selección de banco (BSR).

Este esquema de selección de banco puede resultar muy ineficaz si se suele acceder alter‐nativamente a GPRs y SFRs, motivo por el que el microcontrolador define un bloque especial de memoria conocido como banco de acceso.

DESARROLLO DE CÓDIGO PARA EL PIC18F4620 63

El banco de acceso está formado por los primeros 128 bytes del primer banco (correspon‐dientes a registros de propósito general) y los últimos 128 bytes del espacio de memoria (registros de función especial). Su finalidad es proporcionar un método de acceso más rápido a los registros más usados. Para ello, algunas instrucciones incluyen en su código de operación un bit de acceso, que indica si se hace referencia a un registro del banco de acceso o si, por el contrario, se debe completar la dirección del dato referenciado con los bits del BSR.

5.1.1.2 Juegos de instrucciones y modos de direccionamiento

El PIC18F4620 dispone de dos juegos de instrucciones que, aunque similares, tienen modos de direccionamiento de datos diferentes:

Juego de instrucciones estándar

La familia PIC18 implementa un conjunto de 75 instrucciones estándar separadas en cuatro grupos dependiendo del tipo de operandos que requieren. Todas las instrucciones ocupan una sola palabra en la memoria de programa, con la excepción de cuatro de ellas que ocupan dos. Aunque la mayoría se ejecutan en un sólo ciclo de instrucción1, algunas instrucciones requieren dos ciclos para completarse, como las que afectan al PC o aquellas en las que el resultado de una comparación es verdadero.

Un listado de estas instrucciones está fuera del alcance de este documento, aunque se comentarán brevemente los modos de direccionamiento disponibles:

• Direccionamiento inherente e inmediato. Algunas instrucciones no requieren de nin‐gún argumento para su ejecución, como es el caso de RESET o SLEEP. En otras el argu‐mento está incluido en el código de operación de la instrucción, por lo que tampoco se realiza acceso alguno a la memoria de datos.

1. Debido a la estructura interna del microcontrolador, un ciclo de instrucción es igual a cuatro ciclos de reloj, por lo que la velocidad máxima a 40 MHz es de 10 MIPS.

Figura 5.1: Mapa de memoria de datos en el PIC18F4620


• Direccionamiento directo. En este modo la dirección del dato a acceder se incluye, total o parcialmente, en el código de operación. En el último caso la dirección se completa con los bits del BSR, o bien se accede al banco de acceso.

• Direccionamiento indirecto. Este modo permite acceder a un registro de memoria sin especificar su dirección en el código de operación. Para ello se emplean tres gru‐pos de registros, cada uno de los cuales contiene una dirección de 12 bits que puede apuntar a todo el espacio de memoria disponible. Por este motivo el esquema de selección de banco no es necesario en este caso. Los datos se acceden a través de un conjunto de registros virtuales que permiten además la manipulación automática de estos punteros en la misma instrucción. Este modo de direccionamiento es muy efi‐ciente en la implementación de estructuras de datos, como por ejemplo arrays.

Juego de instrucciones extendido

Existe la opción de habilitar un juego extendido que introduce 8 nuevas instrucciones y modifica ciertos aspectos del espacio de memoria de datos y de su direccionamiento. Este juego se diseñó específicamente para la optimización de código reentrante1 escrito en lenguajes de alto nivel como C; especialmente cuando se requiere el almacenamiento dinámico de datos en una pila software, como en el caso de usar un sistema operativo en tiempo real.

La configuración extendida añade un modo de direccionamiento indexado a los comen‐tados con anterioridad. Para ello se modifica el comportamiento del banco de acceso, entre otros aspectos. No se entrará aquí en más detalles acerca de este juego por no tener utilidad en la aplicación, puesto que ni la pila TCP/IP de Microchip ni el resto del código diseñado puede considerarse reentrante. De hecho, se ha comprobado que el compilador genera un código más extenso e ineficiente cuando se configura el microcontrolador con el juego de instrucciones extendido.

5.1.1.3 Interrupciones

El PIC18F4620 dispone de una gran cantidad de fuentes de interrupción, así como de la opción de asignar dos niveles de prioridad diferentes en la atención de las mismas. De esta forma, una rutina de interrupción de bajo nivel puede ser interrumpida si se genera un evento de alto nivel. Cada uno de estos niveles de prioridad tiene asignado un vector de interrupción en el espacio de memoria de programa. La discriminación de la fuente de interrupción en cada nivel de prioridad se debe realizar en la correspondiente rutina de atención.

Por otro lado, cuando se genera una interrupción de alto nivel, el contenido de los registros de estado (STATUS), de trabajo (WREG) y de selección de banco (BSR) se guarda automáticamente en unos registros imagen para su restauración al finalizar la rutina de interrupción. Esto proporciona un método rápido y eficaz de copia del contexto de ejecución.

Debido a un error en la versión de microcontrolador empleado en la aplicación, esta copia temporal puede hacerse de forma incorrecta si la interrupción se produce durante el acceso a alguno de los registros mencionados [PICA4], por lo que se ha de prestar atención a este problema en el diseño del firmware.

1. Es decir, código que puede ser ejecutado de manera recursiva, lo que implica que se deban guardar las variables de entorno en una pila software.


5.1.2 El compilador MPLAB® C18

Cuando la envergadura de la aplicación que se pretende diseñar en un sistema integrado es considerable, el empleo de un lenguaje de alto nivel resulta casi fundamental. El código del controlador OSC se desarrolló en lenguaje C, usando para ello el compilador MPLAB C18 de Microchip. Aunque la pila TCP/IP tiene soporte directo para compiladores de otras compañías como HI‐TECH PICC o CCS, el compilador de Microchip puede descargarse de forma gratuita en su versión para estudiantes. Esta versión es completamente funcional durante un período de dos meses, transcurridos los cuales sólo dejan de funcionar algunas características no esenciales como la optimización avanzada de código, y estando permitido su uso incluso en aplicaciones comerciales.

El MPLAB C18 es un compilador compatible con el estándar ANSI C para toda la familia de microcontroladores PIC18 que incluye un conjunto de aplicaciones para la consola de Windows® y una extensa librería de funciones para el acceso a periféricos y el manejo de datos en memoria. Otra característica interesante es su fácil integración con el resto de herramientas proporcionadas por Microchip, en particular con el entorno de desarrollo MPLAB IDE, del que se comentarán algunos detalles sobre su configuración para este proyecto en el apéndice C.

En este apartado se hará una breve introducción de las herramientas involucradas en la generación de código máquina para luego comentar algunos detalles específicos del compi‐lador MPLAB C18, como siempre, sin pretender reemplazar la lectura de los manuales corres‐pondientes [C18GS][C18UG][C18LB].

5.1.2.1 Introducción a las herramientas de lenguaje MPLAB

En la figura 5.2 se muestra un diagrama del proceso de generación de código máquina en una aplicación genérica a partir de sus fuentes. Según este ejemplo, dos ficheros escritos en lenguaje C son compilados por el MPLAB C18, mientras que el ensamblador MPASM hace lo propio con un tercer fichero. El resultado es un conjunto de archivos objeto precompilados que pueden combinarse y almacenarse en una librería1, o bien pueden ser procesados por el enlazador para generar una imagen programable en el microcontrolador. Este proceso, típico en la compilación de cualquier aplicación informática, se realiza normalmente de forma trans‐parente al usuario por el entorno de desarrollo.

Para generar los resultados, el enlazador MPLINK hace uso de un archivo de texto conocido como linker script donde se definen los rangos de memoria de programa disponibles para el almacenamiento de instrucciones. Este script es distinto en cada microcontrolador, y también en el caso de usar el depurador hardware ICD2, puesto que algunas direcciones están reservadas para alojar el código que permite su funcionamiento.

Una vez finalizado el proceso, el enlazador genera un archivo binario con extensión .hex que contiene una imagen de memoria capaz de ser interpretada por el hardware programador. Otro archivo de texto de interés tiene extensión .map, y en él se incluye información detallada sobre la asignación de secciones de código y datos a direcciones físicas de memoria.

1. La aplicación desarrollada hace únicamente uso de las librerías estándar de C proporcionadas por el compilador. Por esta razón no se comentará el software de creación de librerías MPLIB.


5.1.2.2 Tipos de datos y almacenamiento

El compilador C18 soporta todos los tipos de datos definidos por el estándar ANSI C. Sin embargo, sólo tendrán utilidad práctica en la aplicación los tipos enteros sin signo, en especial el de 8 bits (unsigned char). Hay que tener en cuenta que el ordenamiento en memoria de las variables multi‐byte se realiza en little‐endian.

Por otro lado, además de los calificadores de almacenamiento estándar const y volatile, C18 introduce cuatro nuevos calificadores:

• ram/rom, necesarios para identificar el espacio de memoria al que se hace referencia.

• near/far, donde far denota una variable localizada en cualquier dirección de mem‐moria RAM o ROM y near implica que la variable está en el banco de acceso de la RAM, o en una dirección de la memoria de programa inferior a 64K.

El compilador generará un código más eficiente cuando una variable ubicada en el banco de acceso se declara como near.

El tamaño de los punteros a memoria de programa también se ve afectado por los califi‐cadores near y far. Un puntero a rom far ocupa 24 bits, mientras que el resto de punteros a memoria de datos o de programa tienen un tamaño de 16 bits. Por este motivo es importante la configuración correcta del calificador usado por defecto, lo que se conoce como «selección del modelo de memoria». Dado que el PIC18F4620 tiene precisamente 64KB de memoria de programa, no será necesario en ningún caso definir una variable o un puntero como rom far, por lo que se debe configurar el compilador para el uso del modelo de memoria pequeña (más acerca de esta configuración en el apéndice C).

Figura 5.2: Flujo de ejecución de las herramientas MPLAB


5.1.2.3 Ensamblador en línea

El compilador tiene soporte básico para instrucciones en ensamblador, que deben introducirse entre las directivas _asm y _endasm. Sin embargo, cualquier función que contenga un bloque de código escrito en ensamblador no será optimizada por el compilador, por lo que en general debe reducirse el uso de esta característica al mínimo.

5.1.2.4 Secciones

Una sección es una porción de código de la aplicación localizada en una dirección de memoria específica. Las secciones pueden contener datos o instrucciones, y definirse en la RAM o en la memoria de programa. Existen dos tipos de secciones por cada tipo de memoria:

• Memoria de programa: Una sección de tipo code contiene instrucciones, mientras que romdata contiene variables y constantes.

• Memoria de datos: Las secciones idata y udata albergan variables de usuario inicia‐lizadas y no inicializadas, respectivamente. Estas variables deben ser globales o tener el calificador static, lo que asegura que su dirección de memoria no será com‐partida por ninguna otra variable.

Mediante la directiva #pragma es posible definir nuevas secciones y asignar bloques de código o datos a las mismas. Para ello se especifica, tras esta directiva, uno de los cuatro tipos de sección mencionados, y opcionalmente su nombre y un conjunto de argumentos. En el siguiente ejemplo se muestra cómo es posible situar código en una determinada dirección de la memoria de programa, para luego retornar a la sección por defecto:

#pragma code nueva_seccion=0xE8

// El código insertado aquí se alojará en la sección "nueva_seccion",

// que comienza a partir de la dirección 0xE8 ...

#pragma code

Otro ejemplo importante del uso de las secciones es la colocación de variables en el banco de acceso. En el ejemplo siguiente, todas las variables no inicializadas que se definan entre las directivas #pragma se ubicarán en este banco. Si una variable que no pertenece a una sección del banco de acceso se define como near, se producirá un error de compilación.

#pragma udata access nueva_seccion

static near char c;

#pragma udata

5.1.2.5 Interrupciones

Existen dos directivas para la definición de las rutinas de servicio de interrupción:

• #pragma interruptlow nombre_funcion declara a la rutina nombre_funcion como la rutina de servicio de interrupciones de baja prioridad.

• #pragma interrupt nombre_funcion define la rutina de servicio de alta prioridad.

La diferencia entre ellas es que el compilador generará un código más denso en el caso de la rutina de alta prioridad, debido a la copia automática del contexto de ejecución que se comentó en un apartado anterior.


Hay que tener en cuenta que el compilador no aloja automáticamente estas rutinas de servicio en sus vectores de interrupción correspondientes. Normalmente será necesario incluir en estos vectores alguna instrucción de salto, para llevar el control hasta estas subrutinas.

En el siguiente ejemplo se muestra cómo se almacena esta instrucción de salto escrita en ensamblador en el vector de interrupción de alta prioridad situado en la dirección 0x08, así como la definición de su rutina de servicio:

#pragma code high_vector=0x08

void vector_de_interrupcion(void)

{

_asm GOTO rutina_de_servicio _endasm

}

#pragma code

#pragma interrupt rutina_de_servicio

void rutina_de_servicio(void)

{

/*....*/

}

5.1.2.6 Parámetros específicos del microcontrolador

La directiva #pragma config especifica los bits de configuración del microcontrolador que son usados en la aplicación. Mediante estos bits se configuran ciertas funciones como el tempori‐zador perro guardián, el juego de instrucciones extendido o los diferentes modos de oscilador disponibles. La lista completa de opciones puede encontrarse en [PICCS].

Por otro lado, existen una serie de archivos de cabecera específicos de cada microcontro‐lador donde se declaran las variables que permiten acceder a sus registros de función especial, y que deben incluirse al comienzo del código.

5.1.2.7 Ejemplo de programa

A continuación se incluye un ejemplo sencillo donde se activa el bit RA0 del puerto A para el encendido de un LED. Las variables TRISA, PORTA y PORTAbits, que permiten el acceso a los registros homónimos del microcontrolador1, están declaradas en la cabecera p18cxxx.h.

#include <p18cxxx.h> /* Fichero de cabecera para la famila PIC18XXXX */

#pragma config WDT=OFF /* Deshabilita el perro guardián */

void main (void)

{

TRISA = 0; /* Configura el puerto A como salida */

PORTA = 0; /* Reset del puerto A */

PORTAbits.RA0 = 1; /* Activa el bit RA0 */

while (1); /* Bucle de espera infinito */

}

1. PORTAbits es una estructura de C que permite el direccionamiento individual de los bits que forman parte de este puerto, y por tanto hace referencia al mismo espacio de memoria que PORTA.

LA PILA TCP/IP DE MICROCHIP 69

5.2 La pila TCP/IP de MicrochipUna vez introducidas las características más relevantes de la arquitectura del microcontrolador y de las herramientas de lenguaje empleadas en el diseño de la aplicación, se procederá al estudio de la implementación TCP/IP que Microchip proporciona de forma gratuita.

El desarrollo requiere un conocimiento básico de las tecnologías de red implicadas, por lo que el presente apartado comienza con una breve introducción a las mismas. Finalmente se analizará la estructura de la pila y su configuración en una aplicación genérica.

5.2.1 Base tecnológica

Se denomina TCP/IP al conjunto de protocolos sobre el que se basan las comunicaciones a través de Internet. Aunque se han desarrollado otros protocolos a este efecto, TCP/IP se ha convertido en un estándar de facto. El concepto de pila surge para denotar una estructura en capas o niveles, donde cada capa es responsable de una faceta determinada de la comuni‐cación. TCP/IP es considerado un sistema de cuatro niveles: enlace, red, transporte y aplicación, cuyas funciones se describieron en el capítulo 3.

La pila TCP/IP de Microchip es un software con estructura modular que implementa un conjunto importante de protocolos de Internet, proporcionando servicios básicos de red a aplicaciones basadas en microcontroladores. En la figura 5.3 se muestran aquellos protocolos TCP/IP más importantes en la aplicación desarrollada y su posición en el modelo de referencia OSI. Sin embargo, en ocasiones esta correspondencia no es perfecta; por ejemplo el protocolo IP usa los servicios de ARP, aunque ambos se incluyen en el mismo nivel.

Se introducirán aquí aquellos protocolos que han sido implementados en el controlador objeto de este proyecto, comenzando por los niveles más bajos de la pila (con la excepción de Ethernet, al que ya se ha dedicado un capítulo). El lector interesado en un análisis más riguroso de estos aspectos puede consultar los RFCs de los protocolos correspondientes, así como otras excelentes fuentes bibliográficas [SteWR].

Figura 5.3: Protocolos TCP/IP en diferentes niveles OSI


5.2.1.1 Internet Protocol (IP)

IP es probablemente el protocolo más importante de toda la estructura TCP/IP, puesto que la gran mayoría de la información que alcanza el enlace está encapsulada en un datagrama IP. Este protocolo hace posible la comunicación entre hosts situados físicamente en diferentes tipos de redes, proporcionando un servicio «no fiable» y «no orientado a conexión»:

• «No fiable» significa que no hay garantías de que un datagrama IP pueda alcanzar su destino. Cuando se detecta un problema, como por ejemplo en el caso de un router que no tiene recursos para almacenar un datagrama, éste se descarta y se intenta enviar un mensaje ICMP de error a la fuente de los datos. La fiabilidad en la entrega de los datos deben proporcionarla los protocolos de niveles superiores.

• Por «no orientado a conexión» se entiende que cada datagrama se maneja como una entidad independiente, lo que supone que dos datagramas pueden tomar rutas dife‐rentes y llegar a su destino desordenados.

Direcciones de red

IP asigna una dirección única a cada nodo perteneciente a una misma red. Esta dirección es un número de 32 bits1 independiente de la dirección física subyacente (dirección MAC, en el caso de Ethernet). Por legibilidad, las direcciones IP suelen representarse tratando cada bloque de 8 bits como un entero decimal sin signo y separando estos números por puntos (por ejemplo 192.168.0.1). Cada datagrama IP contiene en su cabecera las direcciones de red de los hosts de origen y destino, entre otra información.

Las direcciones IP se dividen conceptualmente en dos partes: un prefijo que identifica a la red y un sufijo que identifica a un nodo concreto dentro de la misma. Para determinar ambas partes se usan máscaras de red, que permiten a cualquier nodo comprobar con un simple AND lógico si una dirección pertenece o no a su misma red, y si es por tanto accesible directamente.

Encaminamiento de datagramas

Conceptualmente, el encaminamiento de datagramas IP en un host es simple. Si el destino está en la misma subred, la información se envía directamente. En caso contrario el host envía el datagrama a un router, el cual se encarga de encaminarlo hacia su destino.

Todas las implementaciones de IP usan una tabla en memoria que se consulta cada vez que un protocolo superior realiza una petición de envío, para determinar cómo se deben encaminarlos datos. Si el datagrama se recibe desde el nivel de enlace, se comprueba si su dirección de destino coincide con alguna de las direcciones del host (en cuyo caso se envía el datagrama al protocolo superior especificado en su cabecera) o se descarta en caso contrario.

Cuando IP recibe un paquete desde algún protocolo superior como UDP o TCP, se busca en la tabla de encaminamiento la mejor ruta posible para alcanzar el destino. Para ello la búsqueda se realiza en el siguiente orden de prioridad:

• Una ruta que iguale la dirección IP de destino.

1. En este texto se considerará únicamente la versión IPv4 del protocolo.


• Una ruta con el mismo identificador de red que la dirección IP de destino.

• Una ruta por defecto.

Si no se encuentra ninguna ruta en la tabla, el datagrama se descarta.

Por otro lado, para evitar que un datagrama pueda quedar «atrapado» indefinidamente en rutas cerradas sin posibilidad de alcanzar su destino, en la cabecera IP se incluye un campo que limita el número máximo de routers que el datagrama puede atravesar. Este campo se denomina time‐to‐live (TTL), y es decrementado en cada router hasta llegar a cero, momento en el que se descarta y se notifica al remitente con un mensaje ICMP.

Fragmentación IP

Aunque la longitud máxima de un datagrama IP es de 65536 bytes, la capa física de la red normalmente impone un límite máximo en el tamaño de la trama que puede ser transmitida. Este límite se conoce como «unidad máxima de transferencia» (Maximum Tranfer Unit, MTU) y en Ethernet es de 1500 bytes.

Cuando la capa IP recibe una petición de envío desde un protocolo superior, se determina el MTU de la interfaz de red sobre la que se debe encaminar el paquete. Si éste es mayor que el MTU, IP lo fragmenta en datagramas independientes que pueden tomar rutas diferentes. Esta fragmentación puede tener lugar en el host remitente o en cualquier router intermedio. El ensamblado del datagrama se realiza al alcanzar el destino, haciendo este proceso transparente a los protocolos de la capa de transporte. La información incluida en la cabecera IP de cada fragmento es suficiente para garantizar este ensamblado.

Un importante problema de este esquema de fragmentación es la ausencia de un método de retransmisión. Si algún fragmento se pierde durante la comunicación, el datagrama completo debe retransmitirse. De hecho, si la fragmentación ocurre en un router intermedio y no en el remitente, éste no tiene forma de conocer cómo se realizó esta fragmentación. Por este motivo la fragmentación IP se evita en la medida de lo posible, y es poco probable que ocurra.

5.2.1.2 Address Resolution Protocol (ARP)

El protocolo ARP se usa para convertir las direcciones virtuales asignadas por el nivel de red (direcciones IP) a las direcciones físicas de las interfaces de red (en Ethernet, la dirección MAC de 48 bits). Esta conversión es necesaria, puesto que cuando una trama Ethernet se envía entre dos hosts de una misma red local, es la dirección física la que determina el destino de la infor‐mación, y nunca la dirección IP que pueda incluir la trama Ethernet en su campo de datos.

Existen, en general, tres estrategias que pueden usarse en esta traducción de direcciones:

1 Conversión basada en tabla de asignación de direcciones.

2 Conversión basada en una expresión matemática.

3 Intercambio de mensajes.

ARP emplea la tercera estrategia, definiendo para ello un esquema de petición y respuesta.


La petición consiste en una trama Ethernet broadcast que contiene la dirección IP a traducir y que es recibida por todos los nodos de la red. Únicamente responderá a esta petición el host que tenga asignada esta dirección IP, por lo que de esta respuesta se puede obtener su dirección física correspondiente.

La situación de ARP en el modelo OSI no es clara, y aunque en la figura 5.3 se emplazó en el nivel de red, en ocasiones se le considera un protocolo a medio camino entre éste y el nivel de enlace.

5.2.1.3 Internet Control Message Protocol (ICMP)

ICMP se considera normalmente una extensión de la capa IP. Este protocolo define un conjunto de mensajes para comunicar problemas en la transferencia de datagramas y otras condiciones que requieren atención.

Aunque los mensajes ICMP se encapsulan en datagramas IP, ICMP no puede ser consi‐derado un protocolo de transporte como UDP o TCP, puesto que generalmente no es utilizado directamente por las aplicaciones de usuario en la red. Una excepción es la herramienta ping, que permite determinar si una dirección IP es accesible mediante el envío de un mensaje ICMP de petición de respuesta (Echo Request). Mediante el envío de varios de estos paquetes, se pueden determinar los tiempos medios de respuesta y el porcentaje de datagramas perdidos.

La generación de comandos ICMP puede ser consecuencia de eventos producidos no sólo en la capa IP, sino también en TCP o UDP. Por ejemplo, cuando una aplicación UDP recibe un datagrama UDP cuyo puerto de destino no se corresponde con ninguno de los puertos activos, UDP responde con un mensaje ICMP de error por puerto inalcanzable.

La situación de ICMP en el modelo OSI es también motivo de controversia —al igual que ARP— puesto que algunos autores lo consideran un protocolo de la capa de transporte.

5.2.1.4 User Datagram Protocol (UDP)

UDP es el protocolo usado en la aplicación para el transporte de los mensajes OSC. A diferencia de los protocolos orientados a la transferencia de un flujo continuo de información como TCP, UDP se basa en el intercambio de datagramas: cada operación de envío de un proceso produce exactamente un datagrama UDP, que se encapsula en un datagrama IP.

Como en IP, no hay garantías de que un datagrama UDP alcance finalmente su destino, lo que se conoce como un servicio best‐effort. El remitente tampoco retiene información de los paquetes enviados con anterioridad, puesto que no existe un mecanismo de retransmisión en caso de fallo. A pesar de estas características indeseables, UDP es usado por otros protocolos donde el establecimiento previo de una conexión supone una carga innecesaria en compa‐ración con la cantidad de información útil que se desea transmitir. También es muy común en aplicaciones de audio y video en tiempo real, donde los estrictos requisitos de latencia preva‐lecen sobre la posible pérdida de algunos paquetes de datos.

Los servicios que UDP añade a la capa IP son la multiplexación de la información en base a números de puerto y un control de errores opcional basado en una suma de verificación o checksum. El cálculo de esta suma se realiza tomando también algunos campos de la propia cabecera IP (que se conoce como «pseudocabecera»).


Para identificar al proceso de un host que genera o recibe un datagrama, UDP utiliza dos números de puerto de 16 bits, de los cuales sólo el de destino es obligatorio.

Otro campo de 16 bits incluido en la cabecera UDP indica la longitud total del datagrama. Su valor mínimo es 8, lo que implica que es posible enviar un datagrama UDP que no contiene carga útil de datos. Nótese que este campo de longitud es redundante, puesto que el tamaño del datagrama UDP puede determinarse a partir de longitud del datagrama IP y de su cabecera (ambas longitudes incluidas en la cabecera IP).

5.2.1.5 Transmision Control Protocol (TCP)

Aunque TCP y UDP utilizan el mismo protocolo de nivel de red (IP), TCP proporciona un servicio totalmente diferente a la capa de aplicación. Se trata de un protocolo conceptualmente mucho más complejo que UDP, cuya implementación requiere una considerable carga compu‐tacional.

Servicios ofrecidos por TCP

TCP proporciona un servicio de transferencia bidireccional de un flujo continuo de datos, fiable y orientado a conexión. El servicio es orientado a conexión porque dos aplicaciones que se comunican a través de TCP deben establecer una conexión previa antes de comenzar la transmisión. La fiabilidad en la entrega de datos se garantiza mediante las siguientes medidas:

• TCP fragmenta los datos que recibe desde el nivel de aplicación en unidades de transmisión denominadas «segmentos» de tamaño variable. Esto es completamente diferente de lo que ocurre en UDP, donde cada bloque de datos enviado por la apli‐cación produce exactamente un datagrama del mismo tamaño.

• Cuando TCP envía un segmento, se establece un contador a la espera de recibir un asentimiento por parte del receptor. Si este asentimiento no se recibe transcurrido un periodo de tiempo razonable, el segmento (presuntamente desaparecido) se retrans‐mite.

• Cuando TCP recibe un segmento, se envía un asentimiento al remitente de los datos.

• TCP comprueba en cada momento posibles errores en la transmisión mediante una suma de verificación. Si recibe un segmento erróneo, éste se descarta y se espera a que el remitente lo retransmita transcurrido un tiempo.

Figura 5.4: Encapsulamiento y cabecera de UDP


• Dado que los segmentos TCP pueden llegar al receptor desordenados (puesto que están encapsulados en datagramas IP), TCP reordena la información antes de enviarla a la capa de aplicación.

• TCP descarta posibles segmentos duplicados debidos al enrutamiento de IP.

• TCP proporciona también un método de control de flujo. Puesto que cada lado de la conexión tiene recursos para recibir sólo una cantidad limitada de datos, el receptor no permite al remitente enviar más información de la que es capaz de admitir.

Cabecera TCP

Cada segmento TCP contiene una cabecera de 20 bytes (a menos que se incluyan campos opcionales que no se comentarán) que incluye principalmente la siguiente información:

• Puertos TCP de origen y destino. Como en el caso de UDP, estos puertos de 16 bits identifican a la aplicación emisora y receptora. Estos dos puertos, junto con las direc‐ciones IP de origen y destino incluidas en su cabecera correspondiente, constituyen lo que se conoce como socket. Por lo tanto, cada socket identifica unívocamente a una conexión TCP.

• Número de secuencia. Este número representa el lugar que el primer byte del campo de datos ocupa en el flujo continuo de información, y permite el reensamblado de los datos en recepción. El número de secuencia es un entero de 32 bits que vuelve a cero tras el siguiente byte después del 232‐1. Cuando una aplicación cliente quiere establecer una conexión con un servidor, este campo contiene un número de secuen‐cia inicial (ISN) elegido arbitrariamente por el cliente para esa conexión. La petición de conexión se envía además con un bit que la identifica como tal (SYN), y que con‐sume un número de secuencia. Por lo tanto, el siguiente segmento enviado por el cliente tendrá un número de secuencia igual al ISN más uno.

• Número de asentimiento. Este número de 32 bits contiene el siguiente número de secuencia que el remitente del asentimiento espera recibir, permitiendo informar de que los datos han sido recibidos correctamente. El campo es sólo válido si el bit ACK está activado. Puesto que el envío de un asentimiento no tiene coste alguno (al estar incluido en la cabecera de todo segmento TCP), este bit se mantiene siempre activo una vez se ha establecido la conexión.

• Bits de control. De los 6 bits de control incluidos en la cabecera TCP, los más relevan‐tes son SYN, ACK, FIN y RST. La utilidad de SYN y ACK ya se ha comentado. FIN se utiliza cuando el cliente quiere notificar al servidor que no tiene más datos que enviar. En ese caso el servidor puede seguir enviando datos al cliente o cerrar la conexión. RST se utiliza para reiniciar la conexión. Por ejemplo, un servidor res‐ponde con este bit activado cuando recibe un segmento TCP a un puerto no válido.

• Tamaño de la ventana. Este campo de 16 bits proporciona la capacidad de control de flujo en el protocolo. En él se indica el número máximo de bytes, empezando por el especificado en el campo de asentimiento, que el receptor es capaz de admitir. De esta forma, el remitente de los datos debe esperar hasta recibir un nuevo asenti‐miento antes de seguir enviando información.


• Campo de control de errores. Se trata de una suma de verificación de 16 bits similar a la de UDP que proporciona un método bastante débil de control de errores. Sólo es posible la detección de los mismos, no su corrección.

Establecimiento y cierre de la conexión

Existen tres fases en la transferencia de información a través de TCP:

1 Establecimiento de conexión. Consiste en un proceso de negociación en tres pasos (three‐way handshake) en el que normalmente el cliente inicia la negociación con el servidor mediante el envío de un segmento con el bit de control SYN activado y un número de secuencia inicial. El servidor responde asintiendo a este segmento e indi‐cando su propio número de secuencia. El asentimiento por parte del cliente a este último segmento marca el establecimiento de la conexión.

2 Transferencia de datos. El proceso de transferencia de datos se ve afectado por muchos factores como el tráfico de la red, la naturaleza de la información que se desea transmitir o la velocidad de cada parte de la comunicación. TCP proporciona mecanismos complejos para maximizar la eficiencia de la comunicación, como el de ventana deslizante ya comentado, el comienzo lento o el asentimiento selectivo. La casuística es enorme, por lo que una descripción de estos aspectos está fuera del alcance de este documento.

3 Cierre de la conexión. Mientras que el establecimiento de una conexión es un pro‐ceso en tres pasos, su cierre requiere cuatro. Puesto que la comunicación es bidirec‐cional, cada parte debe finalizarla independientemente, lo que supone normalmente transferir un par de segmentos FIN y ACK desde cada lado de la transmisión. Esto significa que una conexión puede estar «medio establecida», en cuyo caso sólo será posible el envío de datos en un sentido (sí será necesario el envío de asentimientos en sentido contrario).

En la siguiente figura se muestra el proceso de establecimiento y finalización de una conexión TCP, donde puede apreciarse cómo el envío de los segmentos SYN y FIN requieren el incremento del número de secuencia.

Figura 5.5: Establecimiento y cierre de una conexión TCP


5.2.1.6 Domain Name System (DNS)

DNS es una base de datos distribuida que relaciona nombres de dominio con direcciones IP. El sistema es distribuido porque no existe ningún sitio en Internet que almacene toda la infor‐mación. En lugar de eso, cada servidor DNS gestiona su propia base de datos con un segmento de la información global y la comparte con los clientes (denominados resolvers).

Un nombre de dominio es simplemente una «etiqueta» en forma de cadena de caracteres alfanuméricos divididos en segmentos mediante puntos. De esta forma es posible hacer referencia a una dirección IP usando un nombre de dominio como www.ietf.org. El uso de nombres de dominio en lugar de direcciones IP no sólo es más práctico, sino también más fiable, puesto que si bien una dirección IP está normalmente sujeta a posibles cambios, los nombres de dominio suelen ser estáticos.

El cliente DNS o resolver es normalmente parte de la aplicación, y por tanto indepen‐diente de los protocolos TCP/IP. Cualquier aplicación que pretenda establecer una comuni‐cación mediante TCP/IP debe hacerlo usando direcciones IP.

Tanto las peticiones DNS como las respuestas asociadas tienen el mismo formato de mensaje, y generalmente se transportan mediante UDP. Esto implica que el resolver debe implementar su propio mecanismo de retransmisión en caso de pérdida de la información.

5.2.1.7 Dynamic Host Configuration Protocol (DHCP)

El protocolo DHCP permite a un conjunto de nodos de una red obtener determinados parámetros de configuración de forma automática, reduciendo al mínimo el tiempo requerido para la administración de la red. Para ello varios clientes de una red contactan a un servidor DHCP que asigna estos parámetros de forma dinámica.

De entre los parámetros de red que un servidor DHCP puede asignar a un cliente deter‐minado, los más importantes son la dirección IP del cliente, la máscara de subred, la puerta de enlace predeterminada y las direcciones IP de los servidores DNS.

Funcionamiento básico

El envío de mensajes entre el cliente y el servidor se realiza mediante UDP. Una operación DHCP típica consta de cuatro fases:

1 DHCP discovery. Cuando un nuevo cliente DHCP se conecta a una red local, éste rea‐liza una petición mediante broadcast para obtener información de los servidores dis‐ponibles. En este punto el cliente puede solicitar la asignación de su última IP conocida en la red, entre otras opciones.

2 DHCP offer. Cada servidor DHCP que recibe la petición puede contestar al cliente informando de los parámetros ofertados, como la dirección IP, la máscara se subred y el periodo de vigencia de la configuración. Para realizar la asignación, el servidor se basa en la dirección física del cliente y en el modo de asignación DHCP. Si el modo es dinámico, como suele ser habitual, los parámetros son válidos sólo durante un periodo de tiempo, transcurrido el cual el cliente deberá realizar otra petición para poder continuar su operación en la red.


3 DHCP request. Cuando un cliente acepta una oferta, debe informar de ello a todos los servidores (mediante broadcast). Este mensaje incluye la dirección IP del servidor DHCP seleccionado. El resto de servidores liberarán las direcciones IP que reserva‐ron para el cliente, pasando a estar disponibles para nuevas peticiones.

4 DHCP acknowledgement. En esta etapa el servidor confirma la oferta realizada al cliente, enviando todos los parámetros de configuración. En este punto, el proceso de configuración IP se da por concluido.

5.2.1.8 NetBIOS Name Service (NBNS)

NBNS es uno de los servicios de red que ofrece la API NetBIOS sobre TCP/IP. Su propósito es parecido al que ofrece DNS: la conversión entre nombres de máquina y direcciones de red.

Básicamente, cuando una aplicación quiere registrar un nombre NetBIOS, contacta con un repositorio central que contiene todas las asignaciones y que asiente positivamente la petición en caso de que el nombre no esté en uso. Lógicamente, un nodo debe consultar a este repositorio (mediante un mensaje de petición de nombre) si quiere acceder a otro usando su nombre NetBIOS. La transferencia de estos mensajes se realiza siempre por medio de UDP.

5.2.2 Estructura de la pila TCP/IP

La pila TCP/IP proporcionada por Microchip es un software modular, altamente configurable para adaptarse a los requisitos específicos de cada aplicación, y portable a una gran cantidad de microcontroladores y DSPs de la compañía.

El código es actualizado frecuentemente por sus desarrolladores, y con cada nueva versión suelen añadirse nuevas funcionalidades y modificarse otras, lo que ha provocado que la documentación existente [MICRa] pueda considerarse obsoleta a día de hoy. Sin embargo esto no supone un gran inconveniente, puesto que en general el propio código está bien documentado mediante comentarios. Si bien su análisis no es trivial, el diseño modular de la pila simplifica esta tarea, ya que la implementación de cada protocolo y la definición de su API se realiza en archivos independientes poco acoplados entre sí. Por otro lado, la mayoría de las aplicaciones prácticas no requerirán de un estudio detallado de la implementación de la pila TCP/IP para cumplir con sus objetivos de diseño, dado que la práctica totalidad de los parámetros configurables son fácilmente modificables mediante directivas de preprocesador.

Toda la información incluida en este texto se refiere a la versión 4.18 de la pila TCP/IP de Microchip.

Figura 5.6: Sesión DHCP típica


5.2.2.1 Protocolos y servicios ofrecidos

Por razones prácticas, y especialmente por las limitaciones del hardware, el controlador OSC diseñado implementa sólo algunos de los protocolos y servicios TCP/IP ofrecidos por la pila:

• Ethernet. La pila tiene soporte directo para el ENC28J60 y la familia de microcontro‐ladores PIC18F97J60 con controlador Ethernet integrado1. La implementación de la capa MAC de estos dispositivos se realiza, como en el resto de protocolos, en archi‐vos independientes. En ellos se define una interfaz de programación de aplicaciones (API) que proporciona un método conveniente para la transmisión y recepción de tramas Ethernet, así como para la configuración y monitorización del dispositivo. En la mayoría de los casos, el acceso a estas funciones no se realiza directamente desde la aplicación de usuario, sino que queda reservado al código de otros protocolos superiores.

• ARP. La pila incluye un servidor y un cliente ARP, siendo opcional la implementa‐ción de este último. Si bien la API de TCP permite la apertura de sockets en modo cliente realizando de forma transparente a la aplicación las posibles resoluciones DNS y ARP, no ocurre lo mismo con UDP. Cualquier aplicación cliente que use UDP deberá gestionar la resolución de la dirección física del destino mediante ARP, como se verá más adelante.

• IP. En general, las funciones asociadas al protocolo IP sólo serán accedidas por las de los protocolos de transporte, y no por la aplicación de usuario. Por limitaciones de RAM, la capa IP de la pila no soporta la fragmentación de datagramas.

• ICMP. La implementación de ICMP es opcional. En la aplicación desarrollada se ha incluido un servidor ICMP que responde a peticiones de ping. También es posible realizar este tipo de peticiones a un host remoto, aunque esta funcionalidad no se ha implementado por carecer de utilidad para el controlador OSC.

• UDP. La pila proporciona una API completa para la transmisión y recepción efi‐ciente de datagramas UDP. En un apartado posterior se detallarán las funciones involucradas en el envío de mensajes OSC sobre UDP.

• DNS. Para permitir el envío de mensajes OSC a un destino especificado por su nom‐bre de host, en lugar de su dirección IP, se habilitado el cliente DNS.

• DHCP. La pila dispone de un cliente y un servidor DHCP. De ellos, sólo se ha implementado el servidor, con la intención de permitir una configuración rápida de los parámetros de red cuando se conecta el controlador directamente a un PC.

• NBNS. El servidor NBNS incorporado responde a peticiones de resolución de nom‐bre NetBIOS, lo que permite asignar un nombre al controlador y acceder con él a su configuración desde un navegador web, en lugar de usar una dirección IP.

1. Aunque en principio es posible adaptar el código a controladores Ethernet de terceras partes, no se trata de una tarea simple. La implementación de algunos protocolos superiores como TCP, hace uso extensivo de características específicas de los dispositivos de Microchip con el fin de maximizar el rendimiento. Esto ha provocado que las versiones recientes de la pila dejen de tener soporte para dispositivos como el SMSC LAN91C111 o el Realtek RTL8019AS.


• TCP. El último protocolo TCP/IP implementado en el controlador es TCP. Su uso es necesario para el funcionamiento del servidor HTTP, que permite la configuración vía web de la aplicación, y que se describirá en el capítulo 6.

5.2.2.2 Creación de una aplicación TCP/IP genérica

El funcionamiento correcto de muchos de los protocolos implementados en la pila requiere la realización de determinadas tareas, no sólo cuando la aplicación principal solicita alguno de sus servicios, sino como respuesta a eventos que tienen lugar de manera asíncrona. Por ejemplo, un fragmento TCP deberá ser retransmitido si no se recibe un asentimiento válido transcurrido un determinado periodo de tiempo.

Para cumplir con estos requisitos y permanecer relativamente independiente de la aplicación, la pila TCP/IP emplea un esquema multitarea cooperativo. Este sistema permite prescindir de un sistema operativo que gestione los tiempos de ejecución, puesto que son las propias tareas las que ceden el control después de realizar algunas funciones. Cualquier aplicación que utilice la pila deberá seguir este mismo esquema, ya sea repartiendo el trabajo en múltiples tareas de menor tamaño o implementando una máquina de estados.

Este mecanismo se observa en el esquema típico de la figura 5.7, donde las tareas definidas por la aplicación de usuario comparten el tiempo de ejecución con las asociadas al funcionamiento de la pila. Para ello es importante que ninguna de estas tareas monopolice el uso de la CPU. En general, será suficiente con ceder el control a la pila cada 50 ms, aunque este tiempo varía considerablemente dependiendo de los protocolos habilitados.

Por otro lado, la mayoría de las modificaciones que el usuario debe realizar para adaptar la pila a las necesidades de la aplicación, se limitan a dos archivos de cabecera:

• HardwareProfile.h, donde se concretan las características del hardware.

• TCPIPconfig.h, donde se habilitan los protocolos y servicios de red deseados, y se configuran otros parámetros relacionados con los mismos.

Figura 5.7: Flujo de una aplicación TCP/IP genérica


5.3 Implementación del códigoEn lo que resta de capítulo se describirá la estructura de la aplicación desarrollada, comen‐zando por la configuración particular de la pila TCP/IP. La intención de este apartado es proporcionar una visión cualitativa que permita comprender mejor el código de la aplicación, incluido en el CD adjunto a la memoria del proyecto.

A medida que se vayan describiendo las distintas entidades que conforman el código, se indicará el archivo en el que se defininen éstas. La carpeta Microchip de las fuentes incluidas en el CD del proyecto contiene todos los archivos relativos a la pila TCP/IP y a sus servicios asociados. El resto de archivos, correspondientes al controlador OSC, se encuentran a dispo‐sición del lector en la carpeta EtherOSC.

En la figura 5.8 se muestra un diagrama de flujo simplificado de la aplicación, que se asemeja también al de la figura 5.7. En el bucle principal de ejecución, las tareas de la pila y las definidas por el usuario se ceden mutuamente el control de forma cooperativa. Existen, además, dos rutinas de servicio de interrupción; la primera de ellas asociada al funciona‐miento de los protocolos de red y la segunda al del controlador OSC.

En la medida de lo posible, el estudio del código que se expone en este apartado seguirá el orden de ejecución dictado por este diagrama.

Figura 5.8: Diagrama de flujo simplificado de la aplicación

IMPLEMENTACIÓN DEL CÓDIGO 81

5.3.1 Configuración de la pila TCP/IP

Como se ha indicado con anterioridad, la configuración mínima de la pila TCP/IP de Microchip requiere la modificación de dos archivos, que se exponen a continuación.

5.3.1.1 Definición del perfil de hardware

La pila define un conjunto de etiquetas simbólicas para hacer referencia a los terminales del microcontrolador encargados de realizar funciones especiales, tales como la comunicación con el controlador Ethernet o con la memoria EEPROM externa. También es importante especificar la frecuencia de trabajo del sistema, necesaria para la correcta inicialización de los temporiza‐dores que marcan la ejecución de eventos temporales.

Esta configuración se realiza mediante la definición de macros de C en el archivo HardwareProfile.h. Un conjunto de estas macros válidas para una pieza concreta de hardware se conoce como perfil, y en este archivo existen perfiles predefinidos para varias placas de desarrollo comercializadas por Microchip. Ninguno de ellos se adapta perfectamente al controlador OSC, por lo que ha sido necesario crear uno nuevo.

La elección de un perfil determinado se realiza también definiendo una macro que lo identifica, y que en esta aplicación se ha denominado ETHEROSC. De forma resumida, la creación del perfil de hardware se realiza como en el siguiente ejemplo:

/* ... Definición de otros perfiles ... */

#elif defined(ETHEROSC)

#define LED0_TRIS (TRISAbits.TRISA4) // Mapeo del LED0 en el pin RA4

#define LED0_IO (PORTAbits.RA4) //

/* ... Mapeo de otros LEDs y pulsador en RB1 ... */

#define ENC_CS_TRIS (TRISBbits.TRISB3) // Chip select de ENC28J60 en RB3

#define ENC_CS_IO (LATBbits.LATB3) //

/* ... Mapeo de otras conexiones al ENC y registros internos ... */

#define EEPROM_SCK_TRIS (TRISCbits.TRISC3)

#define EEPROM_SPI_IF (PIR1bits.SSPIF)

/* ... Mapeo de otras conexiones a la EEPROM y registros internos ... */

#endif

De esta manera, la última macro indica se podrá referenciar al bit SSPIF del registro PIR1 empleando el nombre simbólico EEPROM_SPI_IF, pero sólo si previamente se ha definido la macro ETHEROSC, ya sea en el propio código o de forma global en las opciones del proyecto.

5.3.1.2 Configuración de protocolos

Mediante este mismo esquema de definición de macros se habilitan los protocolos de red que se desean incluir en la aplicación, para lo cual es necesario modificar el archivo TCPIPConfig.h. Estas macros permiten la compilación condicional de bloques de código, y por tanto la capacidad de encontrar un compromiso entre prestaciones y memoria consumida.


Se exponen a continuación las distintas opciones que pueden configurarse en este archivo:

Inclusión y exclusión de protocolos

Las siguientes macros habilitan los protocolos y servicios de red opcionales involucrados en el controlador OSC. Nótese que es igualmente importante comentar las macros del resto de protocolos, para no desperdiciar la escasa memoria de programa del microcontrolador:

#define STACK_USE_UDP // Protocolo de transporte de los mensajes OSC

#define STACK_USE_ICMP_SERVER // Servidor ICMP para respuestas de Ping

#define STACK_USE_HTTP2_SERVER // Servidor HTTP (ver capítulo 6)

#define STACK_USE_DHCP_SERVER // Servidor DHCP

#define STACK_USE_DNS // Cliente DNS

#define STACK_USE_NBNS // Servidor de resolución de nombres NetBIOS

Cuando se incluye un protocolo de nivel superior que requiere los servicios de otro protocolo no incluido explícitamente, la pila da soporte también para este último. Por ejemplo, la primera de las macros es redundante, puesto que DHCP requiere la inclusión del módulo UDP. Lo mismo ocurre con TCP, incluido de manera implícita por el servidor HTTP.

Sistema de archivos MPFS

Como se sabe, la finalidad de la EEPROM serie externa es la de almacenar los archivos relacio‐nados con el servidor HTTP. Para poder indexar estos archivos en memoria, se ha utilizado un sistema de archivos sencillo implementado por Microchip y denominado Microchip Pic File System (MPFS). Las macros más importantes relacionadas con la configuración de este sistema son las siguientes:

#define MPFS_USE_EEPROM

#define USE_EEPROM_25LC1024

#define MPFS_RESERVE_BLOCK (0)

La primera de ellas indica que el conjunto de archivos asociados al servidor web se almacena precisamente en la EEPROM externa. En el caso de no definir esta macro, se debe generar una imagen MPFS en un archivo compilable de C (más acerca de esto en el próximo capítulo) para guardar estos archivos en la memoria de programa del microcontrolador.

La finalidad de la segunda macro es clara: la definición del modelo de EEPROM, necesario para el correcto direccionamiento y operación del dispositivo. Si no se define, se asume que se trata de un modelo 25LC256, u otro totalmente compatible.

Mediante la última macro, es posible reservar un bloque contiguo de datos al inicio del espacio de direcciones de la EEPROM que no se destina al almacenamiento de la imagen MPFS. Este espacio es útil para almacenar parámetros de configuración en aquellas aplica‐ciones basadas en un microcontrolador que carece de EEPROM interna, y así se utiliza por defecto en la pila TCP/IP.

Dado que el PIC18F4620 dispone de 1 KByte de EEPROM interna, todos los parámetros de configuración del controlador OSC se guardan en esta memoria, lo que permite un acceso más rápido y eficiente a estos datos y deja además más espacio disponible para los archivos del servidor HTTP.


Direcciones por defecto

En TCPIPConfig.h se define también la configuración de red que el controlador toma por defecto. Ésta incluye el nombre NetBIOS, las direcciones MAC1 e IP locales, la máscara de subred, la IP de la puerta de enlace y las de dos servidores DNS. Estos parámetros se almacenan en memoria de programa para que el usuario de la aplicación pueda restaurar la configuración original del controlador en caso necesario.

Parámetros de TCP y UDP

Es posible definir el número máximo de sockets UDP disponibles en la aplicación. Un número más alto implica la definición de más variables globales, y por tanto puede no ser deseable en microcontroladores con poca memoria RAM. Aunque el controlador OSC utiliza sólo un socket, hay que tener en cuenta que tanto el módulo DNS como DHCP requieren UDP para su funcionamiento. Por defecto el número máximo es 9, suficientes para esta aplicación.

También es posible activar o desactivar el cómputo del checksum en el envío de datagramas UDP, que como se sabe es un campo opcional. Este cálculo se ha deshabilitado (mediante la eliminación de la macro UDP_USE_TX_CHECKSUM), debido a que aumenta ligera‐mente la memoria de programa requerida, y su procesamiento disminuye considerablemente la tasa máxima de transferencia alcanzable.

En cuanto a TCP, no sólo es posible especificar el número de sockets, sino también la manera en la que se asigna la RAM disponible en el ENC28J60 y/o el PIC a sus buffers asociados de transmisión y recepción. Es importante asegurar la disponibilidad de un socket TCP por cada conexión HTTP que pueda establecerse de manera simultánea. Con este fin se han definido cuatro sockets, aumentando también el tamaño del buffer FIFO de transmisión de 200 a 500 bytes para maximizar el rendimiento en conexiones con round‐trip time elevado.

Parámetros del servidor HTTP

El resto de parámetros configurables en TCPIPConfig.h corresponden al servidor HTTP, y se comentarán en el capítulo 6.

5.3.2 Interrupciones

Como se muestra en la figura 5.8, la aplicación emplea sólo dos rutinas de servicio de interrupción, una de ellas asociada a la pila TCP/IP y la otra al controlador OSC. Por eficiencia y simplicidad, se han asignado distintos niveles de prioridad a cada una de ellas:

5.3.2.1 Interrupción de baja prioridad

La pila maneja internamente un registro temporal de 48 bits, que con la frecuencia de trabajo del microcontrolador y la configuración por defecto de sus temporizadores, se incrementa cada 25.6 μs. Esto permite controlar de forma precisa periodos de tiempo muy prolongados.

1. La dirección MAC de cada dispositivo Ethernet debe ser única. Aunque en la práctica es muy improbable que una dirección MAC elegida al azar coincida con la de otro dispositivo en una red local, es obligatorio en cualquier aplicación comercial asegurar su exclusividad. Para ello es necesario comprar un rango de direcciones al IEEE, u obtener la dirección a partir de un componente preprogramado como el DS2502‐E48 de Maxim.


Los 16 bits menos significativos de este registro corresponden al TIMER0 del PIC, por lo que se incrementan automáticamente. El resto se almacena en una variable que debe incre‐mentarse cuando se produce un desbordamiento de este temporizador, lo que ocurre aproxi‐madamente cada 1.7 segundos. Este periodo es suficientemente grande como para que la sobrecarga asociada a la copia del contexto de ejecución en una interrupción de baja prioridad sea despreciable en el rendimiento total de la aplicación.

5.3.2.2 Interrupción de alta prioridad

La interrupción de alta prioridad está asociada a la captura de los ocho canales analógicos disponibles en el controlador. Cada iteración del bucle principal de la aplicación supone el envío de un nuevo mensaje OSC que contiene los valores analógicos capturados en ese intervalo. Dado que el microcontrolador sólo cuenta con un ADC, los canales deben muestrearse secuencialmente, respetando un tiempo mínimo de conversión antes de iniciar la captura de un nuevo canal.

La lectura de los valores analógicos puede ser muy ineficiente si se realiza mediante espera activa, o si se convierte un sólo canal en cada iteración. Por este motivo, una vez que se inicia la captura del primer canal en el bucle principal, una rutina de servicio de interrupción se encarga de las capturas subsiguientes. Las lecturas correspondientes se almacenan en un array global de enteros de 16 bits para su posterior procesamiento por la aplicación. Una vez se han convertido todos los canales, la propia rutina de atención desactiva la interrupción asociada al ADC, a la espera de ser de nuevo habilitada en la siguiente iteración.

El tiempo de adquisición configurado determina la frecuencia con la que se invoca a la rutina de interrupción. Este tiempo debe ser lo suficientemente corto como para asegurar que todos los valores analógicos estén disponibles en memoria antes de proceder a la construcción del siguiente mensaje. Sin embargo, no puede hacerse arbitrariamente corto, puesto que se debe garantizar el mínimo necesario para la carga correcta de la capacidad interna del conver‐tidor.

Se ha comprobado que, incluso en una aplicación con mínima carga computacional, la máxima tasa a la que pueden enviarse datagramas UDP es inferior a 800 paquetes por segundo. Esto significa que entre cada lectura consecutiva de las entradas analógicas trans‐curre un periodo de al menos 1.25 ms. Si se utiliza el tiempo programado de adquisición más largo que se puede configurar (FOSC/64 y TACQ=20TAD, ver hoja de características del PIC), una conversión completa de los ocho canales puede realizarse en menos de 0.5 ms, por lo que esta configuración es adecuada para la aplicación desarrollada.

Figura 5.9: Secuencia temporal de la conversión ADC


A continuación se indica el código de la rutina de servicio:

#pragma interrupt HighISR

void HighISR(void)

{

static BYTE channel = 0; // Indicador de canal [0-7]

wAnalogArray[channel++].Val = (WORD)ADRES; // Almacena resultado en variable global

PIR1bits.ADIF = 0; // Reset de bandera de interrupción

if(channel < 8)

{

ADCON0 = (channel<<2) + 1; // Selección siguiente canal, ADC habilitado

ADCON0bits.GO = 1; // Comenzar una nueva conversión

}

else

{

channel = 0;

ADCON0 = 0b00000001; // Selección canal 0, ADC habilitado

PIE1bits.ADIE = 0; // Deshabilitar la interrupción del ADC

}

}

La variable global wAnalogArray debe declararse con el calificador volatile para que el compilador no realice optimizaciones inapropiadas. Esta variable se ha definido en el banco de acceso de la RAM. En cuanto al vector de interrupción, ha de tenerse en cuenta el error de hardware comentado en el apartado 5.1.1.3, que se ha solucionado de la siguiente manera:

#pragma code highVector=0x08

void HighVector (void)

{

_asm

CALL hv_branch, 1 // Llamada ficticia a función. Sobreescribe los reg. FAST

hv_branch: POP // Elimina de la pila la dirección de retorno incorrecta

GOTO HighISR // Salto a la ISR

_endasm

}

5.3.3 Aplicación principal

El siguiente estudio seguirá el orden de ejecución especificado en la figura 5.8, que se corres‐ponde de manera esquemática con el del archivo Main.c.

Además de la inclusión de los archivos de cabecera correspondientes, en este archivo debe declararse la siguiente directiva del preprocesador, que permite al código de la pila identificar el punto de entrada principal de la aplicación:

#define THIS_IS_STACK_APPLICATION

5.3.3.1 Inicialización del hardware

Este paso se realiza mediante una llamada al procedimiento InitializeBoard(), donde se especifican las entradas y salidas del procesador y se configuran otros parámetros como el convertidor ADC. El código está bien comentado, por lo que no será necesario aclararlo aquí.


5.3.3.2 Inicialización de componentes y estructuras de datos de la pila

La activación de la rutina de interrupción que actualiza el registro temporal se realiza mediante una llamada a TickInit(). Por su parte, MPFSInit() hace lo propio con las variables asociadas al funcionamiento del sistema de archivos MPFS.

La estructura AppConfig

La pila TCP/IP requiere la declaración en el archivo principal de una única estructura global de nombre AppConfig y tipo APP_CONFIG, que almacena los parámetros locales de red y otras variables de control. Los campos de esta estructura que tienen mayor importancia en la aplicación son los siguientes:

typedef struct _APP_CONFIG

{

IP_ADDR MyIPAddr; // IP local

IP_ADDR MyMask; // Máscara de subred

IP_ADDR MyGateway; // Puerta de enlace

IP_ADDR PrimaryDNSServer; // Servidor DNS primario

IP_ADDR SecondaryDNSServer; // Servidor DNS secundario

IP_ADDR DefaultIPAddr; // Normalmente coincide con MyIPAddr

IP_ADDR DefaultMask; // Normalmente coincide con MyMask

BYTE NetBIOSName[16]; // Nombre NetBIOS

MAC_ADDR MyMACAddr; // Dirección MAC

} APP_CONFIG;

La inicialización de la estructura AppConfig se realiza mediante una llamada a InitAppConfig(). En ella se asignan los valores por defecto almacenados en la memoria de programa y se comprueba si en la EEPROM interna existe alguna copia válida de otros valores configurados por el usuario, en cuyo caso se utilizan estos últimos. Se comentará primero la API de acceso a la EEPROM, y por último la función InitAppConfig().

Acceso a la EEPROM interna

En los archivos EEPROM.c y EEPROM.h, se ha definido un conjunto de funciones para el acceso eficiente a la EEPROM interna. Se comentan a continuación:

• void EEBeginRW(BYTE page, BYTE address); Esta función inicializa los registros necesarios para el control de la EEPROM. Se ha separado de las funciones de lectura y escritura para evitar la ejecución redundante de código durante los accesos secuenciales. El espacio de memoria EEPROM se organiza en cuatro páginas de 256 bytes, que se identifican con el primer parámetro recibido por la función. El segundo indica la dirección del dato dentro de cada página.

• BYTE EERead(void); Devuelve el dato e incrementa automáticamente el puntero de direcciones EEPROM para preparar la lectura del siguiente byte.

• void EEWrite(BYTE data); Realiza la escritura del dato recibido en la dirección del puntero EEPROM, que se incrementa posteriormente. El ciclo de escritura requiere la ejecución de una secuencia determinada de operaciones, por lo que la función deshabilita temporalmente las interrupciones.


Almacenamiento de la estructura AppConfig en la memoria EEPROM

Dado que existe una cantidad suficiente de memoria EEPROM, se ha asignado la primera página de la misma al almacenamiento de la estructura AppConfig. Como se sabe, la función InitAppConfig() determina si existe en esta memoria una copia válida de parámetros de confi‐guración asignados por el usuario. Para hacer esta discriminación se reserva el primer byte de la página al almacenamiento de un código que determina su validez, como se indica en el siguiente extracto de código:

/* ... Función InitAppConfig() ... */

p = (BYTE*) &AppConfig; // Puntero al primer byte de la estructura AppConfig

EEBeginRW(0x00,0x00);

c = EERead(); // Lectura del código de validez de la EEPROM

if(c == 0x60u) // Si el código es válido (60h), copiar secuencialmente

{ // sizeof(AppConfig) bytes a la estructura AppConfig

for ( c = 0; c < sizeof(AppConfig); c++ )

*p++ = EERead();

}

/* ... */

5.3.3.3 Inicialización de estructuras del controlador OSC

Las variables globales usadas por el controlador se han organizado en dos estructuras, de nombre OscConfig y OscData. Su inicialización se realiza en las funciones InitOscConfig() y FormatOscMessages(), respectivamente. Tanto las estructuras de datos como estas funciones se definen en los archivos OSC.c y OSC.h, y se comentan a continuación.

La estructura OscConfig

Esta estructura contiene todos los parámetros de la aplicación configurables por el usuario, a excepción de los de red, que se definen en AppConfig. Su contenido determina el comporta‐miento del controlador, como se verá más adelante. La estructura tiene los siguientes campos:

typedef struct _OSC_CONFIG

{

BYTE OscNodeName[16]; // Nombre del contenedor OSC principal

BYTE RemoteAddr[32]; // Dirección del host destino de los mensajes OSC

UDP_PORT RemotePort; // Puerto UDP de destino

UDP_PORT LocalPort; // Puerto UDP local

struct

{

unsigned char : 1; // (sin asignar)

unsigned char bSendOnChange : 1; // Desactivar «modo ráfaga»

unsigned char bSendAnalog : 1; // Enviar mensaje OSC de entradas analógicas

unsigned char bSendDigital : 1; // Enviar mensaje OSC de entradas digitales

unsigned char bUseRot : 1; // Interpretar entradas digitales como codif. rotat.

unsigned char bUseSwm : 1; // Sensores digitales en modo matriz de pulsadores

unsigned char bAnalogAvg2 : 1; // Filtrado de valores analógicos (fuerte)

unsigned char bAnalogAvg1 : 1; // Filtrado de valores analógicos (suave)

} Flags;

} OSC_CONFIG;


Mediante el array OscNodeName[] se puede asignar un nombre al controlador, modifi‐cando el método principal de su espacio de direcciones (ver figura 2.2). El tamaño del array se ha limitado a 16 bytes para hacerlo coincidir con su nombre NetBIOS1. De esta manera se simplifica la conexión de varios controladores OSC a una misma red local, pudiéndose deter‐minar la procedencia de cada mensaje por el nombre del método principal, y accediendo a la configuración de cada dispositivo en un navegador web por medio de este mismo nombre.

La dirección de destino se especifica en la cadena de caracteres RemoteNode[], que puede contener una dirección IP en la típica representación decimal con separación por puntos (p. ej. 192.168.0.1) o un nombre de host que requiere resolución DNS (p.ej. www.kde.org).

Como se sabe, los puertos UDP son números enteros de 16 bits, siendo sólo obligatorio especificar el puerto remoto. Cualquier entero mayor de 1023 será adecuado para este fin (los puertos 1 a 1023 se denominan «bien conocidos» y están reservados para la operación de algunos protocolos estándar), aunque no se impondrá ninguna limitación al usuario.

El último byte de la estructura (Flags) contiene una serie de bits de bandera que modifican el comportamiento del controlador, y que se explican a continuación:

• bSendOnChange. Cuando se activa este bit, el controlador sólo envía un mensaje si éste difiere del último enviado; es decir, si ha habido algún cambio en las entradas correspondientes. Si se desactiva, en cada iteración del bucle principal se enviará un mensaje OSC por cada tipo de entrada habilitado, independientemente de que éste sea una repetición del anterior. Es lo que se ha denominado «modo ráfaga».

• bSendAnalog. Indica si deben enviarse los mensajes asociados a los canales analógi‐cos; es decir, habilita el método Analog.

• bSendDigital. Ídem para las entradas digitales. Nótese que esto afecta a tres de los métodos definidos, y no sólo a uno como en el caso anterior (ver apartado 2.3.4).

• bUseRot. Activa el método Rotary, que interpreta las entradas digitales como si pro‐cedieran de un codificador binario rotativo en cuadratura. Esto sólo es cierto si no se configuran las entradas digitales en el modo matriz de pulsadores. De esta manera, el método Rotary es compatible con el método Digital, pero no con SwitchMatrix.

• bUseSwm. Habilita la matriz de pulsadores. En contraposición al caso anterior, esto implica la activación del método SwitchMatrix y la desactivación de los métodos Digital y Rotary.

• bAnalogAvg2. Habilita un filtrado digital de los valores analógicos capturados antes de formar el mensaje. El filtro consiste en una simple media aritmética de la última lectura realizada y el último valor enviado (filtro IIR de un polo).

• bAnalogAvg1. Su función es idéntica a la del caso anterior, salvo que ahora se realiza un filtrado menos agresivo, consistente en la media aritmética de las dos últimas conversiones (filtro FIR). En el caso de que ambos bits estén activados, el filtro IIR prevalecerá sobre éste.

1. La especificación NetBIOS establece un tamaño máximo de 15 bytes para estos nombres, más un carácter terminador de cadena.


La estructura OscData

Esta estructura contiene toda la información necesaria para el envío de mensajes OSC, como las direcciones de cada método y sus argumentos. También incluye información acerca de eventos que requieren atención por parte de la aplicación. La estructura consta de los siguientes campos:

typedef struct _OSC_DATA

{

BYTE OscAnaAddr[OSC_ANA_ADDR_LEN]; // Dirección del método Analog (sin argumentos)

BYTE OscDigAddr[OSC_DIG_ADDR_LEN]; // Dirección del método Digital (sin argumentos)

BYTE OscSwmAddr[OSC_SWM_ADDR_LEN]; // Dirección del método SwitchMatrix (sin arg.)

BYTE OscRotAddr[OSC_ROT_ADDR_LEN]; // Dirección del método Rotary (sin argumentos)

BYTE sizeofAnaAddr; // Tamaño de las direcciones anteriores

BYTE sizeofDigAddr; //

BYTE sizeofSwmAddr; //

BYTE sizeofRotAddr; //

DWORD_VAL dwAnalog[8]; // Argumentos método Analog (8 enteros 32 bits)

DWORD_VAL dwDigital; // Argumento método Digital (1 entero 32 bits)

DWORD_VAL dwSwitchMatrix; // Argumento método SwitchMatrix (1 ent. 32 bit)

DWORD_VAL dwRotary; // Argumento método Rotary (1 entero 32 bits)

struct

{

unsigned char : 3; // (sin asignar)

unsigned char bNewConfig : 1; // La estructura OscConfig ha sido modificada

unsigned char bChangeDMode : 1; // Cambio de modo digital (Normal <-> Matriz)

unsigned char bNewSwmVal : 1; // Mensaje SwitchMatrix es distinto del anterior

unsigned char bNewDigVal : 1; // Mensaje Digital o Rotary distinto del anterior

unsigned char bNewAnaVal : 1; // Menasje Analog es distinto del anterior

} Flags;

} OSC_DATA;

Las cuatro primeras cadenas contienen las direcciones completas de los métodos OSC, y sólo se inicializan tras un reset, o bien cuando el usuario introduce una nueva configuración vía web (recuérdese que el nombre del método principal es configurable y que éste afecta al formato de toda la cadena de dirección, como puede verse en el ejemplo del apartado 2.3.3). Aunque este sistema implica un uso ligeramente superior de memoria RAM, tiene una gran ventaja en términos de rendimiento, puesto que entre cada mensaje consecutivo sólo será necesario calcular los nuevos argumentos.

Los siguientes cuatro bytes de la estructura indican la longitud de las cadenas descritas anteriormente. Como se verá más adelante, esto permite el llenado más rápido posible del buffer de transmisión UDP, empleando para ello la función UDPPutArray(). Nótese que no es posible determinar la longitud total de las direcciones a partir de las propias cadenas, puesto que éstas contienen caracteres nulos adicionales, además del terminador.

Los argumentos de los mensajes se almacenan en variables de tipo DWORD_VAL, una unión de C que permite el direccionamiento flexible de datos de 32 bits a nivel de bit, byte o palabra. Como se sabe, cada método tiene un argumento entero, salvo Analog que tiene 8.


El byte Flags contiene un conjunto de bits de bandera, al igual que en la estructura OscConfig. Sus funciones se exponen a continuación:

• bNewConfig. Este bit indica a la tarea de control OSC que la estructura de configura‐ción OscConfig ha sido modificada por el usuario a través del servidor HTTP.

• bChangeDMode. Como se comentó en el capítulo anterior, un cambio en la disposición de los sensores digitales implica una configuración distinta de las líneas de entrada y salida del microcontrolador. Este bit se utiliza para advertir al usuario de este hecho, y evitar posibles daños físicos a la placa cuando se cambia el modo de entrada digital.

• bNewSwmVal, bNewAnaVal. Estos bits indican que los mensajes SwitchMatrix y Analog, respectivamente, difieren de los últimos enviados. Sólo son relevantes cuando la bandera bSendOnChange de la estructura OscConfig está activada.

• bNewDigVal. Ídem, salvo que este bit se refiere conjuntamente a los métodos Digital y Rotary.

Inicialización y almacenamiento de la estructura OscConfig

Esta estructura es accedida frecuentemente durante la ejecución, por lo que se ha definido en el banco de acceso. Su inicialización se realiza en la función InitOscConfig(), cuyo funciona‐miento es muy parecido a la ya comentada InitAppConfig().

Los parámetros configurados por el usuario se almacenan esta vez en la segunda página de la EEPROM interna. La función determina si existe una copia válida de estos parámetros mediante el mismo sistema; es decir, comprobando el contenido del primer byte de la página. Una diferencia con InitAppConfig() es que se configuran también algunos bits del puerto D como salida, necesarios en el caso de utilizar el modo de matriz de pulsadores.

Si no existe una copia válida en memoria EEPROM, la estructura se inicializa con sus valores por defecto, como se muestra en el siguiente extracto del código:

/* ... Función InitOscConfig() ... */

strcpypgm2ram((void*)OscConfig.OscNodeName, (ROM void*)DEFAULT_NODE_NAME);

strcpypgm2ram((void*)OscConfig.RemoteAddr, (ROM void*)DEFAULT_REMOTE_ADDR);

OscConfig.RemotePort = DEFAULT_REMOTE_PORT;

OscConfig.LocalPort = DEFAULT_LOCAL_PORT;

/* ... */

La función strcpypgm2ram(), incluida en la librería estándar del compilador, copia una cadena de caracteres almacenada en la memoria de programa a una zona de memoria RAM. Por defecto, el nombre del controlador es EtherOSC, la dirección de destino es una IP broadcast (255.255.255.255), el puerto UDP remoto es 1234 y el local es 9 (puerto discard). En cuanto al funcionamiento del controlador, se habilita el modo normal de las entradas digitales y los métodos Analog y Digital. Se desactivan el modo de envío en ráfaga, el método Rotary y el filtrado digital de las entradas analógicas.

Una vez inicializada la estructura con los parámetros por defecto, se invoca a la función SaveOscConfig(), que copia todos los valores en la EEPROM y los marca como válidos.


Inicialización de la estructura OscData

La estructura OscData contiene —además de las direcciones de los métodos OSC, que pueden considerarse estáticas— los parámetros asociados a los mensajes y otros indicadores de eventos que afectan al funcionamiento de la aplicación. Es importante asegurar que estos últimos no están activos al comienzo de la ejecución del programa, para lo cual se declara la estructura de la siguiente manera:

OSC_DATA OscData = {0}; // Declaración e inicialización a cero

La función FormatOscMessages() se encarga de inicializar las direcciones OSC, tras un reset del sistema o cuando el usuario establece una nueva configuración. El proceso es sencillo, aunque se debe ser cuidadoso para minimizar el tamaño del código generado.

La función comienza concatenando el nombre del controlador, almacenado en OscConfig, con el nombre de cada uno de los métodos y con los caracteres de separación (/). Las variables que indican la longitud de las direcciones deben también incrementarse adecua‐damente. El resultado será una cadena como /EtherOsc/Analog, terminada con un carácter nulo. Como se sabe del capítulo 2, una cadena OSC debe alinearse en bloques de 32 bits, inclu‐yendo para ello tantos nulos como sean necesario. Esto se realiza como en el siguiente ejemplo, extraído del código de la función:

/* ... Función FormatOscMessages() ... */

while (OscData.sizeofAnaAddr % 4)

{

OscData.OscAnaAddr[OscData.sizeofAnaAddr] = 0x00;

OscData.OscRotAddr[OscData.sizeofAnaAddr++] = 0x00;

}

while (OscData.sizeofDigAddr % 4)

OscData.OscDigAddr[OscData.sizeofDigAddr++] = 0x00;

while (OscData.sizeofSwmAddr % 4)

OscData.OscSwmAddr[OscData.sizeofSwmAddr++] = 0x00;

/* ... */

En el ejemplo anterior se ha aprovechado el hecho de que las direcciones OSC de Analog y Rotary tienen siempre el mismo tamaño. Para terminar la formación de las direcciones se anexionan las cadenas de tipo correspondientes:

/* ... Función FormatOscMessages() ... */

memcpypgm2ram((void*)&OscData.OscAnaAddr + OscData.sizeofAnaAddr,

(ROM void*)",iiiiiiii\0\0", 12);

memcpypgm2ram((void*)&OscData.OscDigAddr + OscData.sizeofDigAddr,

(ROM void*)",i\0", 4);

/* ... */

En este caso los caracteres nulos adicionales se conocen de antemano y pueden copiarse directamente. Ahora es necesario utilizar la función memcpypgm2ram(), ya que no se puede determinar el tamaño de las cadenas por la posición de su terminador. Esta función recibe como último argumento el número de bytes que se desean mover desde la memoria de programa hacia la de datos.

Para concluir, la función actualiza adecuadamente los indicadores de tamaño de las direcciones OSC.


5.3.3.4 Recuperación de la configuración por defecto

Para evitar que una configuración inapropiada de los parámetros de red impida al usuario establecer una comunicación con el dispositivo, se realiza tras el reset una comprobación del estado de uno de los pulsadores incluidos en la placa. Si éste se mantiene pulsado (es decir, a nivel bajo) durante más de cuatro segundos, se invalida el contenido de la EEPROM y poste‐riormente se genera un reset por software. El código se muestra a continuación:

/* ... */

static TICK t = 0; // TICK contiene los 32 bits menos signif. del registro de tiempo

if(BUTTON0_IO == 0u)

{

TICK StartTime = TickGet(); // Inicio del intervalo de 4 segundos

while(BUTTON0_IO == 0u)

{

if(TickGet() - StartTime > 4*TICK_SECOND)

{

EEBeginRW(0x00,0x00); // Borrado del byte de validez, página 1 de la EEPROM

EEWrite(0xFF);

EEBeginRW(0x01,0x00); // Borrado del byte de validez, página 2 de la EEPROM

EEWrite(0xFF);

/* ... Indicar reseteo con LEDs ... */

Reset();

}

}

}

/* ... */

5.3.3.5 Inicialización de los protocolos TCP/IP

Como paso previo a la utilización de los servicios de la pila TCP/IP, deben inicializarse todos sus módulos. Esto se hace mediante sendas llamadas a las funciones StackInit() y HTTPInit().

StackInit() inicializa la máquina de estados de la tarea StackTask() y llama a los inicia‐lizadores de los módulos MAC, ARP, UDP y TCP. De forma cualitativa, se realizan las siguientes funciones:

• En la capa MAC, el módulo SPI del microcontrolador es configurado a su máxima velocidad (10 MHz). También se configuran los registros internos del ENC28J60 que establecen, entre otras cosas, el tamaño de las tramas Ethernet, la asignación del buffer FIFO, la dirección MAC o el modo de transmisión (que por compatibilidad es half‐duplex, dado que no se soporta la autonegociación).

• La inicialización de ARP consiste en el borrado de la caché interna que contiene el par de direcciones MAC e IP.

• Se asegura que todos los sockets UDP están convenientemente cerrados y disponi‐bles.


• Se inicializa el estado de todos los sockets TCP definidos.

Por su parte, la función HTTPInit() inicializa todos los sockets disponibles, poniéndolos a la escucha de peticiones de conexión en el puerto 80 (puerto HTTP estándar).

5.3.3.6 Tareas asociadas a la pila TCP/IP

Una vez configurado el hardware e inicializadas todas las variables de la aplicación, da comienzo la ejecución de las tareas en el bucle principal. Como se sabe, ninguna de ellas puede monopolizar el control de la CPU durante periodos de tiempo prolongados. Se comentan a continuación aquellas definidas por la pila TCP/IP:

• StackTask(). Esta es la única tarea esencial para el funcionamiento de la pila. Imple‐menta una máquina de estados finita que, entre otras cosas, realiza las tareas tempo‐rales necesarias para el funcionamiento de las conexiones TCP (retransmisión, cierre, envío de asentimientos...), analiza el tipo de paquete recibido e invoca a los módulos correspondientes para su posterior procesamiento.

• HTTPServer(). Se trata de una aplicación TCP que responde a las peticiones realiza‐das desde un navegador web, llevando el control de las conexiones establecidas.

• NBNSTask(). Esta tarea es un servidor UDP que responde a peticiones de nombre NetBIOS con la dirección IP local del controlador.

• DHCPServerTask(). Se trata también de una aplicación UDP que responde a peticio‐nes DHCP. Por defecto, este servidor asigna un tiempo de validez de la configura‐ción DHCP de sólo 15 segundos, aunque se ha modificado a dos minutos para reducir el número de renovaciones, y por tanto el tráfico asociado. Por otra parte, el servidor DHCP puede ser desactivado por el usuario mediante la modificación de un bit de la estructura AppConfig. Para desactivarlo sólo es necesario no invocar a esta tarea en el bucle de ejecución.

5.3.3.7 Lectura de las entradas del controlador

La función OSCProcessIO(), definida en OSC.c, calcula en cada iteración del bucle principal los argumentos de los métodos del controlador, en función de las entradas y de la configuración establecida por el usuario. El resultado se almacena en la estructura OscData para su posterior envío, realizado por la tarea OSCClientTask().

Es importante aquí que el código de la función se optimice en la medida de lo posible, de forma que se requiera un mínimo de instrucciones para su implementación y se maximice el rendimiento.

Se analizarán por separado cada uno de los métodos:

Método Analog

Como se sabe, la rutina de interrupción de alta prioridad inicializa un array de memoria global que contiene las lecturas más recientes de cada canal analógico. Sin embargo, para la imple‐mentación del filtro digital y la desactivación del modo ráfaga se requieren dos más, por lo que en cada momento se deben manejar tres arrays, que se declaran de la siguiente manera:


• volatile near WORD_VAL wAnalogArray[8]; Variable global actualizada por la rutina de interrupción que contiene las lecturas analógicas más recientes.

• WORD_VAL wAnalogLastSent[8]; Variable global que contiene los valores analógicos enviados en el último mensaje.

• static WORD_VAL wAnalogLastAcq[8]; Variable local a OSCProcessIO() que alma‐cena los valores analógicos capturados, asociados al último mensaje enviado.

La función comienza comprobando si la rutina de interrupción del ADC está habilitada. Ese caso improbable implicaría que todavía existía una conversión en progreso cuando se invocó a la función, y que por tanto la iteración del bucle principal ha sido excesivamente rápida (ver figura 5.9). Si esto ocurriera, se debe esperar a la siguiente llamada para completar el cálculo de los argumentos, aunque como se explicó en el apartado 5.3.2.2 este hecho resulta prácticamente imposible.

El siguiente paso consiste en la actualización de los arrays arriba mencionados, para lo cual debe tenerse en cuenta la configuración del filtro digital. El código responsable se muestra a continuación:

/* ... Función OSCProcessIO(), actualización de arrays ... */

if(PIE1bits.ADIE == 0) // Comprobación de que la conversión anterior ha finalizado

{

if(OscConfig.Flags.bAnalogAvg2)

{

// Filtro IIR. Valor a enviar = (valor más reciente + último enviado)/2

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

wAnalogLastSent[i].Val = (wAnalogArray[i].Val + wAnalogLastSent[i].Val) >> 1;

}

else if(OscConfig.Flags.bAnalogAvg1)

{

// Filtro FIR. Valor a enviar = (valor más reciente + último capturado)/2

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

wAnalogLastSent[i].Val = (wAnalogArray[i].Val + wAnalogLastAcq[i].Val) >> 1;

}

else

{

// Filtro desactivado. Copiar wAnalogArray a wAnalogLastSent.

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

wAnalogLastSent[i].Val = wAnalogArray[i].Val;

}

// En cualquier caso, actualizar wAnalogLastAcq

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

wAnalogLastAcq[i].Val = wAnalogArray[i].Val;

/* ... */

Aunque el último bucle for es prescindible en dos de las configuraciones, se ha incluido con el fin de evitar posibles transitorios indeseados en la salida cuando el usuario activa el filtro FIR.


En este punto de la ejecución, el array wAnalogLastSent[] almacena los 8 argumentos correspondientes al próximo mensaje del método Analog. Cada elemento de esta cadena es un entero de 16 bits con ordenamiento little‐endian, que como se indicó es el utilizado por el compilador C18. Sin embargo, la especificación OSC define argumentos de 32 bits, big‐endian. La conversión se realiza a continuación, copiando cada valor en la estructura OscData, que a partir de ahora contendrá un mensaje OSC completo y listo para su envío en OSCClientTask():

/* ... Función OSCProcessIO(), actualización de OscData y cambio a BIG ENDIAN ... */

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

{

wTemp = wAnalogLastSent[i]; // wTemp es un entero de 2 bytes

p = &OscData.dwAnalog[i].v[2]; // OscData.dwAnalog[i] tiene 4 bytes

*p++ = wTemp.v[1]; // 2do byte de wTemp -> 3er byte de dwAnalog[i]

if(*p != wTemp.v[0])

{

*p = wTemp.v[0]; // 1er byte de wTemp -> 4to byte de dwAnalog[i],

OscData.Flags.bNewAnaVal = 1; // sólo si el valor ha cambiado

}

}

/* ... */

En el código anterior, hay que tener en cuenta que los dos primeros bytes de cada argumento almacenado en la cadena dwAnalog[] serán siempre cero, por lo que no es necesario modificarlos (ver la inicialización de la estructura OscData, en el apartado 5.3.3.3). Por otro lado, la copia sólo se completa si los 8 bits menos significativos de la captura más reciente difieren de los de la captura anterior, en cuyo caso se activa la bandera bNewAnaVal para forzar el envío del mensaje. Resulta razonable asumir que dos conversiones consecutivas del mismo canal no diferirán exclusivamente en sus 2 bits más significativos, por lo que es posible ahorrar una nueva comparación por cada canal y mejorar así el rendimiento de la aplicación.

Para finalizar el procesamiento de las entradas analógicas, se habilita de nuevo la interrupción del ADC y se inicia la siguiente captura. Esta relación entre la tarea OSCProcessIO() y la rutina de servicio de interrupción se ha representado en la figura 5.8 mediante una línea discontinua.

/* ... Función OSCProcessIO(), inicio de la próxima conversión ADC ... */

PIR1bits.ADIF = 0;

PIE1bits.ADIE = 1;

ADCON0bits.GO = 1;

}

// Fin ‘if(PIE1bits.ADIE == 0)’

Métodos Digital y Rotary

En este caso, la variable vDigitalLastRead almacena el valor de la última lectura realizada en el puerto correspondiente a los sensores digitales (puerto D). Esta variable no sólo es necesaria para determinar si ha ocurrido un nuevo evento en alguna de las entradas cuando el modo ráfaga está desactivado, sino también para calcular el sentido de giro del codificador rotativo.


La actualización del argumento del método Digital en la estructura OscData es simple: se trata de la copia negada del puerto D del microcontrolador en el último byte del campo dwDigital. La negación es necesaria, puesto que las entradas son activas a nivel bajo.

El método Rotary requiere un tratamiento más especial, debiéndose tener en cuenta las siguientes consideraciones:

• Dado que el puerto digital tiene un tamaño de 8 bits, es posible conectar hasta 4 codificadores simultáneamente. Se asume que cada uno de ellos está conectado a un par contiguo de terminales de este puerto.

• Los 4 bytes del argumento de este método se han asociado a cada uno de los codifi‐cadores. La correspondencia se realiza en el mismo orden de conexión; es decir, el byte menos significativo del argumento se refiere al codificador conectado al par de terminales RD0 y RD1 del puerto D.

• En referencia a la figura 4.10, la transición de las entradas de cada codificador seguirá un patrón determinado que depende del sentido de giro. Por cada transición correcta se generará un mensaje cuyo argumento será 1 o ‐1, en función de este sen‐tido. Un argumento nulo indicará que no ha habido movimiento, o bien que se ha producido una transición errónea que no sigue ninguno de los dos patrones.

• La función OSCProcessIO() se invoca a una frecuencia superior a 400 Hz. Esta tasa es suficientemente alta como para detectar cualquier transición por simple muestreo, sin necesidad de realizar la lectura por interrupción. El modelo de codificador empleado en el controlador es el NSE10 de ITT Industries, que produce sólo 48 tran‐siciones por cada giro de 360°.

La determinación del argumento asociado a cada codificador es un proceso que puede requerir una cantidad considerable de estructuras condicionales, y por tanto generar un código muy poco eficiente. Para evitar esto, se ha implementado una tabla de verdad en memoria RAM que contiene cada uno de los 16 resultados posibles, en función de la lectura actual del codificador y de la inmediatamente anterior. Esta tabla se muestra a continuación:

Lectura en tn

0 0 0 1 1 0 1 1

0 0 0 -1 1 0

0 1 1 0 0 -1

1 0 -1 0 0 1

1 1 0 1 -1 0

Tabla 5.1: Determinación del argumento del codificador rotativo

Lect

ura

en t n

-1


La definición de esta tabla en memoria y el código responsable del cálculo de los argumentos Digital y Rotary se indican a continuación:

/* ... Función OSCProcessIO(), cálculo de métodos Digital y Rotary ... */

static const CHAR lookup[16] = {0,-1,1,0,1,0,0,-1,-1,0,0,1,0,1,-1,0};

if(!OscConfig.Flags.bUseSwm) // Comprobación del modo digital ‘normal’

{

OscData.dwDigital.v[3] = ~PORTD; // Actualización del argumento ‘Digital’

if(OscData.dwDigital.v[3] == vDigitalLastRead)

return;

OscData.Flags.bNewDigVal = 1;

if(OscConfig.Flags.bUseRot) // Sólo si método ‘Rotary’ está activado

{

vTemp = OscData.dwDigital.v[3];

p = &OscData.dwRotary.v[3]; // p apunta al LSB, arg. del codific. 0

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

{

offset = vDigitalLastRead & 0x03; // Cálculo del índice de la tabla, se

offset <<= 2; // anexionan los dos bits de la entrada

offset |= vTemp & 0x03; // actual con los dos de la anterior.

*p-- = lookup[offset]; // Luego se actualiza el argumento y se

vDigitalLastRead >>= 2; // preparan las variables para el

vTemp >>= 2; // siguiente codificad. en otra iteración

}

}

vDigitalLastRead = OscData.dwDigital.v[3];

}

Método SwitchMatrix

De los 32 bits que conforman el argumento del método SwitchMatrix, sólo son relevantes los últimos 16. Cada uno de ellos está asociado a un pulsador de la matriz, correspondiendo el menos significativo al pulsador 0 (puede consultarse la numeración de los pulsadores en la figura 4.14, o en el esquemático del controlador incluido en el apéndice A).

El código encargado de realizar el escaneo por filas y columnas de esta matriz, y la actua‐lización del argumento en la estructura OscData se indica a continuación:

/* ... Función OSCProcessIO(), cálculo del método SwitchMatrix ... */

else

{

LATD = 0xFE; // Selección de la primera fila de la matriz

vTemp = (~PORTD)&0xF0;

vTemp >>= 4;

LATD = 0xFD; // Segunda fila

vTemp |= (~PORTD)&0xF0; // vTemp contiene los 8 LSb del argumento

if(vTemp != OscData.dwSwitchMatrix.v[3])

{

OscData.dwSwitchMatrix.v[3] = vTemp; // Copia del primer byte del argumento


OscData.Flags.bNewSwmVal = 1;

}

LATD = 0xFB; // Tercera fila

vTemp = (~PORTD)&0xF0;

vTemp >>= 4;

LATD = 0xF7; // Cuarta fila

vTemp |= (~PORTD)&0xF0; // vTemp contiene los 8 MSb del argumento

if(vTemp != OscData.dwSwitchMatrix.v[2])

{

OscData.dwSwitchMatrix.v[2] = vTemp; // Copia del segundo byte del argumento


}

}

5.3.3.8 Envío de los mensajes OSC

La última y más importante tarea invocada en el bucle principal de la aplicación es OSCClientTask(). Esta función se encarga del envío de los datagramas UDP que transportan cada mensaje OSC, para lo cual utiliza las estructuras, ya inicializadas, OscConfig y OscData.

Figura 5.10: Diagrama de transición de estados de la tarea OSCClientTask()


El envío de datagramas a través de UDP requiere el seguimiento de una serie de pasos:

1 Resolución DNS del host de destino, en caso necesario.

2 Resolución ARP de la IP de destino. Nótese que el paso anterior puede requerir tam‐bién una resolución ARP del propio servidor DNS, aunque este paso es realizado por la API de la pila TCP/IP de manera transparente.

3 Apertura del socket UDP.

4 Envío de datagramas.

Para poder organizar todas estas tareas, la función OSCClientTask() implementa una máquina de estados finita. Estos estados se declaran en OSC.h mediante la siguiente sentencia:

typedef enum _SM_OSC

{

SM_START = 0,

SM_DNS_RESOLVE,

SM_SEND_ARP,

SM_GET_ARP,

SM_SOCKET_OBTAIN,

SM_SEND_OSC,

SM_NEW_CONFIG

} SM_OSC

Los estados arriba indicados y las transiciones entre los mismos se han representado en la figura 5.10. El análisis del código de OSCClientTask() se separará en función de cada uno de ellos.

Estado inicial (SM_START)

Siguiendo la secuencia de operación arriba indicada, el primer paso necesario para la apertura de un socket UDP consiste en la resolución del nombre de host remoto mediante DNS. La pila TCP/IP de Microchip proporciona un módulo software que realiza estas tareas de forma trans‐parente al usuario.

Sin embargo, este módulo no puede prestar sus servicios a más de una tarea simultánea‐mente. Su utilización requiere una comprobación previa de su disponibilidad. Cuando hay una resolución DNS en progreso asignada a una aplicación, se debe esperar a que ésta concluya y el módulo quede liberado antes de que cualquier otra pueda utilizarlo.

Aunque en el controlador sólo la tarea OSCClientTask() puede tomar el control del módulo DNS, es necesario seguir este esquema de solicitud, bloqueo y liberación. La solicitud se realiza mediante una llamada a la función DNSBeginUsage(), que devuelve TRUE indicando la disponibilidad del cliente DNS y bloqueando sus servicios a cualquier otra tarea.

El inicio de la resolución de nombre DNS lo marca una llamada a la siguiente función:

void DNSResolve(BYTE *Hostname, BYTE RecordType);

El parámetro RecordType puede recibir dos constantes: DNS_TYPE_A, para resoluciones de IP típicas y DNS_TYPE_MX para la resolución de direcciones de correo.


Hostname recibe la dirección de la cadena que contiene el nombre de host a resolver. Una característica importante y útil de la implementación de esta función es que esta cadena puede representar una dirección IP en la notación decimal con puntos. Lógicamente en este caso no se producirá ninguna petición de resolución al servidor DNS, pero el módulo devolverá la misma IP en formato binario como si ésta hubiese ocurrido. Este comportamiento permitirá unificar el tratamiento de las direcciones remotas especificadas por el usuario.

Las operaciones a realizar en el estado inicial (SM_START) son las indicadas hasta ahora. La función permanece en este estado solicitando la utilización del módulo DNS en cada iteración, hasta que al fin éste se encuentra disponible. Cuando esto ocurre, se inicia la resolución y se produce una transición hasta el siguiente estado (SM_DNS_RESOLVE):

/* Función OSCClientTask(), inicio de la ejecución ... */

SM_OSC OSCClientState = SM_START;

void OSCClientTask(void)

{

switch(OSCClientState)

{

case SM_START:

if(DNSBeginUsage()) // Solicitud del módulo DNS

{

DNSResolve(OscConfig.RemoteAddr, DNS_TYPE_A); // Módulo obtenido, inicio de la

OSCClientState++; // resolución. Ir a SM_DNS_RESOLVE.

}

break;

/* ... */

Resolución DNS (SM_DNS_RESOLVE)

El resultado de la resolución se obtiene mediante llamadas sucesivas a la siguiente función:

BOOL DNSIsResolved(IP_ADDR *HostIP);

HostIP es un puntero a la variable de memoria de 32 bits donde ha de almacenarse el resultado. La función devuelve FALSE mientras la conversión se encuentre en progreso. Cuando se devuelve TRUE la resolución se da por finalizada, aunque para determinar si tuvo éxito es necesario invocar a esta función:

BOOL DNSEndUsage(void);

DNSEndUsage() libera el módulo DNS, pasando a estar disponible para dar servicio a otras tareas. La función devuelve TRUE si la conversión ha sido correcta, y FALSE en caso de que la dirección del host remoto no exista, o si se ha producido un timeout.

El controlador permanece en el estado SM_DNS_RESOLVE mientras exista una resolución en progreso, lo que puede llevar hasta 1 segundo (este es el tiempo máximo por defecto en la pila TCP/IP). Cuando la resolución tiene éxito, se produce una transición hasta el siguiente estado (SM_SEND_ARP). Si no es así, se comprueba si el usuario ha modificado la configuración del controlador (en cuyo caso se cambia al estado SM_NEW_CONFIG) o se retorna al estado inicial:


/* ... Función OSCClientTask(), resolución DNS ... */

case SM_DNS_RESOLVE:

if(!DNSIsResolved(&RemoteNode.IPAddr))

break; // Todavía en progreso

if(!DNSEndUsage()) // Resolución sin éxito:

{

if(OscData.Flags.bNewConfig) // Comprobar si hay una nueva configuración

OSCClientState = SM_NEW_CONFIG; //

else // Intentarlo de nuevo con la misma

OSCClientState--; //

break;

}

OSCClientState++; // Resolución con éxito, siguiente estado

/* ... */

Petición ARP (SM_SEND_ARP)

Como se ha mencionado en apartados anteriores, la API UDP de la pila no gestiona de manera automática la resolución de la dirección física del destino. Esta tarea corre por cuenta de la aplicación de usuario, que debe llamar a la siguiente función para comenzar el proceso de resolución:

void ARPResolve(IP_ADDR* IPAddr);

El único parámetro recibido es la dirección IP, en formato binario, del host remoto.

La aplicación de usuario debe también controlar la retransmisión de la petición ARP en caso de que no se reciba una respuesta en un intervalo de tiempo razonable, dado que ninguna función de la API ARP indicará este hecho (a diferencia de lo que ocurría con el módulo DNS).

El inicio de la petición ARP se realiza en el estado SM_SEND_ARP, siendo éste inestable. Aquí se determina, en primer lugar, si la IP remota corresponde a algún tipo de broadcast. En ese caso la resolución es innecesaria (puesto que la MAC de destino será también un broadcast1) y puede iniciarse directamente la apertura del socket UDP en el estado SM_SOCKET_OBTAIN.

En el caso habitual de que la IP remota sea unicast, se inicia la resolución mediante una llamada a ARPResolve(), guardando una marca de tiempo antes de realizar la transición al siguiente estado para poder controlar el tiempo de respuesta.

/* ... Función OSCClientTask(), inicio de la resolución ARP ... */

case SM_SEND_ARP:

if(RemoteNode.IPAddr.v[3] == 0xFF)

{

// Si la IP remota es multicast: IP = 255.255.255.255, MAC = FF:FF:FF:FF:FF:FF

memset(&RemoteNode, 0xFF, sizeof(RemoteNode));

1. El controlador OSC soporta sólo la «difusión limitada» o limited broadcast, y no la multidifu‐sión IP. Cualquier envío de paquete en multidifusión alcanzará únicamente a los nodos conectados a la misma red física subyacente.


OSCClientState = SM_SOCKET_OBTAIN; // No es necesaria la resolución ARP.

break;

}

ARPResolve(&RemoteNode.IPAddr); // Iniciar la resolución.

timer = TickGet(); // Guardar la marca de tiempo del inicio.

OSCClientState++; // Ir a SM_GET_ARP.

break;

/* ... */

En el código anterior, RemoteNode es una estructura de sólo dos campos que contiene las direcciones IP y MAC remotas, en formato binario. Por este motivo la selección de un broadcast consiste simplemente en la inicialización de todos sus bytes a 255.

Respuesta ARP (SM_GET_ARP)

La resolución ARP tiene éxito cuando la siguiente función devuelve TRUE:

BOOL ARPIsResolved(IP_ADDR *IPAddr, MAC_ADDR *MACAddr);

En ese caso, la dirección de memoria especificada por el puntero MACAddr contendrá la MAC de la IP especificada en IPAddr.

El controlador permanecerá en el estado SM_GET_ARP mientras esta función devuelva FALSE, o bien mientras no haya transcurrido un tiempo superior al límite especificado para la obtención de una respuesta válida (2 segundos). Si la resolución ARP tarda demasiado, se comprueba un posible cambio de configuración, o se retransmite la petición mediante una transición al estado anterior. El código se muestra a continuación:

/* ... Función OSCClientTask(), fin de la resolución ARP ... */

case SM_GET_ARP:

if(!ARPIsResolved(&RemoteNode.IPAddr, &RemoteNode.MACAddr))

{

if(TickGet()-timer > 2*TICK_SECOND)

{

if(OscData.Flags.bNewConfig)

OSCClientState = SM_NEW_CONFIG; // El usuario ha modificado la configuración

else

OSCClientState--; // Demasiado tiempo, reiniciar la petición ARP

}

break; // Resolución aún en progreso.

}

OSCClientState++; // Resolución finalizada, ir a SM_SOCKET_OBTAIN

/* ... */

Apertura del socket UDP (SM_SOCKET_OBTAIN)

Una vez obtenidas las direcciones IP y MAC del host remoto, es posible iniciar la apertura del socket UDP a través del cual se enviarán los mensajes OSC.


Como se sabe, un socket es un identificador de conexión que mantiene información acerca de las direcciones y puertos locales y remotos. Existe un límite superior en el número de sockets que la pila puede manejar, especificado en la macro MAX_UDP_SOCKETS del archivo TCPIPConfig.h. Por cada socket definido se reserva un espacio de memoria RAM para el almacenamiento de sus datos de conexión.

Cuando una aplicación «abre» un socket, se reserva uno de estos espacios de memoria y se le asigna un manejador que lo identifica unívocamente. Dado que el controlador envía mensajes a un único host y puerto en cada momento, sólo se requiere un manejador que se ha denominado OSCSocket, una variable global inicializada a la constante INVALID_UDP_SOCKET. Esta constante identifica a un manejador que no ha sido asignado todavía a ningún socket. La asignación se realiza mediante una llamada a la siguiente función:

UDP_SOCKET UDPOpen(UDP_PORT localPort, NODE_INFO *remoteNode, UDP_PORT remotePort);

UDPOpen() devuelve un manejador, o bien INVALID_UDP_SOCKET si no hay más sockets disponibles. El controlador OSC realiza sucesivas llamadas a la misma en el estado SM_SOCKET_OBTAIN mientras no se obtenga un manejador válido (aunque la apertura del socket tendrá siempre éxito en este caso, dado que no hay ninguna otra aplicación, a parte de los módulos DNS, DHCP y NBNS, que se comunique mediante UDP):

/* ... Función OSCClientTask(), apertura del socket UDP ... */

case SM_SOCKET_OBTAIN:

OSCSocket = UDPOpen(OscConfig.LocalPort, &RemoteNode, OscConfig.RemotePort);

if(OSCSocket != INVALID_UDP_SOCKET)

OSCClientState++; // Socket obtenido. Ir a SM_SEND_OSC

break;

/* ... */

Envío de mensajes OSC (SM_SEND_OSC)

El controlador permanece la mayor parte de su tiempo de funcionamiento normal en el estado SM_SEND_OSC. En él se comprueba, en primer lugar, si la configuración del controlador ha sido modificada por el usuario. En ese caso se libera el socket UDP obtenido en el estado anterior mediante una llamada a UDPClose(). Como en otras ocasiones, el siguiente paso consiste en una transición a SM_NEW_CONFIG.

Si la configuración es aún válida, se transmiten una serie de datagramas UDP que dependen de ella: habrá un datagrama por método activado, y éstos sólo deberán transmitirse si el modo ráfaga está activado o si se ha producido un cambio respecto del mensaje anterior.

El inicio de una transferencia mediante UDP requiere del llenado previo de un buffer de transmisión. Para comprobar que este buffer dispone de espacio suficiente, debe llamarse a la siguiente función:

WORD UDPIsPutReady(UDP_SOCKET s);


Esta función devuelve el número de bytes libres en el buffer de transmisión del socket especificado. Además tiene el efecto de marcar a este socket como el activo, de manera que cualquier operación posterior de llenado o transmisión se referirá a su buffer. Esta caracte‐rística es la que tiene interés en el código desarrollado, puesto que los mensajes OSC serán siempre suficientemente cortos como para no llenar nunca completamente el buffer de trans‐misión.

Existen diversas funciones que permiten el llenado de este buffer, dependiendo de la cantidad y la ubicación en memoria de los datos a transmitir. De entre ellas, la más adecuada para los objetivos buscados es la siguiente:

WORD UDPPutArray(BYTE *cData, WORD wDataLen);

Esta función realiza el llenado a partir de una secuencia de wDataLen bytes almacenados en la dirección cData de la RAM. El valor devuelto es el número de bytes correctamente alojados en el buffer de transmisión. Un llenado secuencial realizado de esta manera es mucho más rápido que si se realiza byte a byte, y es el motivo por el que la estructura OscData contiene mensajes completos (incluyendo, por ejemplo, los bytes siempre nulos de algunos argumentos).

La transferencia del datagrama y la liberación del buffer se realiza a través de la llamada a la siguiente función:

void UDPFlush(void);

A continuación se muestra el código que implementa este estado:

/* ... Función OSCClientTask(), envío de mensajes OSC ... */

case SM_SEND_OSC:

// Comprobar si la estructura OscConfig ha sido modificada vía HTTP...

if(OscData.Flags.bNewConfig)

{

UDPClose(OSCSocket); // Cerrar socket UDP para posterior apertura.

OSCClientState = SM_NEW_CONFIG; // Ir a SM_NEW_CONFIG.

break;

}

// Comprobar si deben enviarse los mensajes del método "Analog"...

if(OscConfig.Flags.bSendAnalog)

{

if((!OscConfig.Flags.bSendOnChange)||(OscData.Flags.bNewAnaVal))

{

if(!UDPIsPutReady(OSCSocket))

break; // El socket no esta listo (no debe ocurrir).

OscData.Flags.bNewAnaVal = 0; // Borrar flag de nuevo mensaje

// Llenado del buffer de transmisión y envío del datagrama...

UDPPutArray(OscData.OscAnaAddr, OscData.sizeofAnaAddr);

UDPPutArray((BYTE*)OscData.dwAnalog, 32);

UDPFlush();

}

}


// Comprobar si hay algún método digital activado...

if(!OscConfig.Flags.bSendDigital)

break;

if(!OscConfig.Flags.bUseSwm)

{

if((!OscConfig.Flags.bSendOnChange)||(OscData.Flags.bNewDigVal))

{

// Envío del método "Digital"


break;

OscData.Flags.bNewDigVal = 0;

UDPPutArray(OscData.OscDigAddr, OscData.sizeofDigAddr);

UDPPutArray((BYTE*)&OscData.dwDigital, 4);

UDPFlush();

if(OscConfig.Flags.bUseRot)

{

// Envío del método "Rotary"


break;

UDPPutArray(OscData.OscRotAddr, OscData.sizeofRotAddr);

UDPPutArray((BYTE*)&OscData.dwRotary, 4);

UDPFlush();

}

}

}

else if((!OscConfig.Flags.bSendOnChange)||(OscData.Flags.bNewSwmVal))

{

// Envío del método "SwitchMatrix"


break;


UDPPutArray(OscData.OscSwmAddr, OscData.sizeofSwmAddr);

UDPPutArray((BYTE*)&OscData.dwSwitchMatrix, 4);

UDPFlush();

}

break;

Cambio en la configuración del controlador (SM_NEW_CONFIG)

Este estado permite continuar la operación normal del controlador cuando se modifica su configuración, sin necesidad de realizar un reset. Aunque este reset no implicaría ningún incon‐veniente en las transferencias mediante UDP, sí afectaría a las conexiones HTTP establecidas, así como posiblemente también al servidor DHCP. De esta manera, sólo se producirá un reset cuando el usuario modifique algún parámetro de red como por ejemplo la IP local, pero nunca si el cambio afecta sólo al cliente OSC.

Las acciones a realizar en este estado son las siguientes:


• Almacenamiento de la nueva configuración en la memoria EEPROM. En este punto se debe tener en cuenta que los nuevos parámetros pueden afectar al modo de entrada digital, en cuyo caso se requieren los cambios oportunos en el hardware del controlador. Cuando un usuario modifica algún parámetro OSC, la nueva configu‐ración es almacenada en la EEPROM, y todos los cambios surten efecto inmediata‐mente salvo el modo de entrada digital. De esta forma, el modo digital cambiará únicamente tras el siguiente reset del dispositivo. El usuario es informado de este hecho a través de la página web de configuración, como se verá en el próximo capí‐tulo.

• Formateo de las direcciones OSC. Si el usuario modifica el nombre del controlador, también cambiará el nombre del método principal, por lo que las direcciones OSC deben calcularse de nuevo. Este paso consiste en una simple llamada a la función FormatOscMessages().

• Inicialización del estado del controlador, que se traduce en el borrado de los bits de bandera bNewConfig y bChangeDMode.

• Transición al estado inicial.

El código responsable de estas funciones, y que finaliza así la tarea OSCClientTask(), es el siguiente:

/* ... Función OSCClientTask(), nueva configuración OSC ... */

case SM_NEW_CONFIG:

if(OscData.Flags.bChangeDMode)

{

// El usuario ha modificado el modo de entrada digital. Este parámetro se cambia

// temporalmente para su almacenamiento en la EEPROM y se restaura posteriormente.

// Este cambio es necesario porque SaveOscConfig() copia toda la estructura

// OscConfig en la EEPROM.

OscConfig.Flags.bUseSwm = ~OscConfig.Flags.bUseSwm;

SaveOscConfig();

OscConfig.Flags.bUseSwm = ~OscConfig.Flags.bUseSwm;

}

else

SaveOscConfig();

// Reformateo de las direcciones OSC.

FormatOscMessages();

// Borrado de bits de bandera.

OscData.Flags.bNewConfig = 0;

OscData.Flags.bChangeDMode = 0;

// Ir al estado inicial con la nueva configuración.

OSCClientState = SM_START;

break;

}

}


5.3.3.9 Inspección de paquetes de red

Una herramienta de gran importancia en el desarrollo de una aplicación de red como la que nos ocupa es Wireshark (anteriormente conocido como Ethereal).

Wireshark es un analizador de protocolos que se ha convertido en el estándar de facto en numerosas instituciones y es, sin ninguna duda, una de las «joyas» del software open source. Esta herramienta multiplataforma permite el análisis en profundidad de cientos de protocolos, en un entorno gráfico atractivo y configurable, y permitiendo la definición de miles de filtros diferentes de captura y visualización de paquetes que facilitan enormemente la depuración de problemas.

Además de facilitar el análisis de las transmisiones TCP y UDP, este software ha resultado de gran ayuda en la obtención de estadísticas que permiten averiguar cómo afectan las modificaciones en el código al rendimiento del controlador OSC.

Figura 5.11: Captura e inspección de un mensaje OSC mediante Wireshark

6capítulo

Configuración web del controlador

a rápida evolución de las tecnologías de Internet ha propiciado en muchos casos la susti‐tución de aplicaciones tradicionales por otras basadas en interfaces web. Una de las

principales ventajas de estas aplicaciones es su motor de ejecución, que consiste en un cliente ligero y disponible en la práctica totalidad de los ordenadores modernos: el navegador web. De esta manera se hace innecesaria la distribución e instalación de software en distintas máquinas, que por otra parte pueden fundamentarse en arquitecturas y sistemas operativos diferentes sin que ésto suponga problema alguno, siempre y cuando el diseño se realice en base a los estándares establecidos.

En este capítulo se expondrá el desarrollo de la interfaz de configuración web del contro‐lador OSC, cuya base es el servidor HTTP de la pila TCP/IP proporcionada por Microchip. Más allá de la presentación estática de contenidos, esta interfaz proporcionará al usuario infor‐mación en tiempo real sobre el estado del controlador. Como consecuencia existirán un número importante de tecnologías implicadas, que serán introducidas en la primera parte del capítulo. Posteriormente se describirán las características del servidor HTTP, cuyo mecanismo de presentación dinámica de información hará necesaria una fuerte interacción entre el firmware del controlador y el resto del código diseñado (páginas web, hojas de estilo, etc.). Este código se detallará en la última parte del capítulo, así como las herramientas de software utilizadas durante la fase de desarrollo y depuración.

6.1 Base tecnológicaEn este apartado se introducirán los protocolos y tecnologías en los que se fundamenta la interfaz de configuración web. Se comenzará con HTTP, el protocolo utilizado en las comuni‐caciones entre cliente y servidor. Posteriormente se comentarán los lenguajes necesarios para la presentación básica de contenidos web, para tratar por último otras técnicas que la enriquecen, como la adición de elementos dinámicos o los nuevos esquemas de comunicación con el servidor.

L

109

CAPÍTULO 6: CONFIGURACIÓN WEB DEL CONTROLADOR110

6.1.1 Hypertext Transfer Protocol (HTTP)

HTTP son las siglas en inglés del protocolo de transferencia de hipertexto, desarrollado conjuntamente por el consorcio W3C y la IETF, cuyo trabajo concluyó con la publicación de una serie de RFCs que se han convertido en estándares de internet desde principios de los 90. Se trata de un protocolo de nivel de aplicación sin estado y genérico, que puede ser usado para otras tareas más allá de la transferencia de hipertexto, permitiendo la construcción de sistemas de forma independiente del tipo de datos transferidos [RFC2616].

El protocolo se basa en un esquema de peticiones y respuestas (transacciones) entre un cliente y un servidor. Las aplicaciones cliente se denominan user agents (normalmente un navegador web), y realizan peticiones de algún recurso a un servidor. Estos recursos pueden ser archivos HTML, imágenes, o cualquier otro conjunto de datos identificable mediante una URL (Uniform Resource Locator). El tipo más común de recurso es un fichero, pero también puede tratarse de otro tipo de información generada dinámicamente por el servidor, como por ejemplo el resultado de un script CGI.

Las comunicaciones HTTP normalmente tienen lugar a través de TCP. El puerto TCP por defecto que los servidores emplean para aceptar las conexiones de los clientes es el 80, aunque pueden usarse otros. Sin embargo, HTTP puede implementarse sobre otros protocolos, siempre que éstos proporcionen un servicio fiable y orientado a conexión como el de TCP.

6.1.1.1 Estructura de los mensajes HTTP

Tanto las peticiones como las respuestas HTTP tienen el mismo formato, y constan de los siguientes campos:

• Una línea inicial, que identifica el tipo de petición o respuesta del mensaje.

• Cero o más campos de cabecera, cada uno de ellos en una línea, y que proporcionan información adicional.

• Una línea en blanco (i.e. sólo los caracteres de retorno de carro y nueva línea) que separa la cabecera del resto del mensaje.

• Opcionalmente, el cuerpo del mensaje.

6.1.1.2 Peticiones

Como se ha indicado, la línea inicial de un mensaje HTTP identifica el tipo de petición. Este tipo varía en función del «método» que afecta al recurso solicitado.

La línea inicial de una petición consta de tres campos separados por espacios: un nombre de método, la URL del recurso (o su término más genérico URI) y la versión del protocolo en uso. Por ejemplo, la petición típica de una página web tendría la siguiente línea inicial:

GET /EtherOSC/web/index.xml HTTP/1.1

La versión del protocolo tiene siempre el mismo formato HTTP/x.x, y tanto ésta como el nombre del método deben ser en mayúsculas. Existen un total de 8 métodos, aunque pueden definirse otros. Los más comunes son GET y POST, cuyas diferencias se exponen a conti‐nuación.

BASE TECNOLÓGICA 111

GET

Es sin duda el método más usado en las comunicaciones a través de internet. Se utiliza para obtener cualquier tipo de información identificada por su URI.

GET se considera un método «seguro» y por consiguiente «idempotente». La calificación de seguro significa que cualquier petición realizada con este método no tendrá ningún tipo de efecto colateral en el estado del servidor, y que por tanto sucesivas peticiones obtendrán exactamente la misma respuesta. La idempotencia se refiere a que múltiples peticiones tendrán, en algún caso, el mismo efecto que una sola de ellas.

En la práctica, el manejo de una petición GET por parte del servidor puede ser total‐mente arbitrario, y por tanto no cumplir con las consideraciones expuestas arriba.

POST

El método POST se emplea para la transferencia de datos al servidor que deben ser procesados de alguna forma por el mismo. Se diferencia de GET en los siguientes aspectos:

• El cuerpo del mensaje no está vacío. Se incluyen también otras líneas de cabecera que describen la información de alguna manera, como su longitud (con la cabecera Content-Length) o su tipo (Content-Type).

• La URI no identifica a un recurso que se desea obtener, sino normalmente a un pro‐grama o script que procesa la información.

• La respuesta HTTP suele representar la salida de este programa, y no un recurso estático.

La aplicación más extendida de este método es, con diferencia, el envío de formularios web. Por otra parte, este método no puede considerarse idempotente, según la definición anterior.

6.1.1.3 Respuestas

La primera línea de una respuesta HTTP se conoce como la «línea de estado», y contiene también tres campos separados por espacios: la versión del protocolo, un código numérico que identifica el estado de la transacción y una frase corta que lo explica.

El código de estado consiste en un entero decimal de tres dígitos, el primero de los cuales identifica la categoría general de la respuesta:

• 1xx indica un mensaje informativo.

• 2xx indica el éxito de alguna acción.

• 3xx redirecciona la petición hasta otra URL.

• 4xx indica un error por parte del cliente.

• 5xx indica un error en el lado del servidor.

Los siguientes son ejemplos de líneas de estado típicas:


HTTP/1.1 200 OK

HTTP/1.1 302 Moved Temporarily

HTTP/1.1 404 Not found

HTTP/1.1 500 Internal Server Error

6.1.1.4 Cabeceras

Las líneas de cabecera proporcionan información sobre la petición o respuesta, o sobre los datos incluidos en el cuerpo del mensaje.

Cada cabecera es una línea formada por un par Nombre: Valor, y su orden en el mensaje no es significativo. Su obligatoriedad depende del tipo de transacción y de la versión del protocolo. Un listado completo de las mismas está fuera de los objetivos de este documento, aunque pueden mostrarse las siguientes como ejemplo:

Content-Type: text/plain

Transfer-Encoding: chunked

6.1.1.5 Versiones del protocolo

La especificación de la versión HTTP en la línea inicial del mensaje permite la coexistencia de varias versiones. Un cliente que realice una petición en una versión determinada no obtendrá una respuesta en otra superior.

La versión más extendida en la actualidad es HTTP/1.1, aunque todavía existen sistemas que utilizan HTTP/1.0. Las principales mejoras que introdujo la primera son las siguientes [GettysJ]:

• Conexiones persistentes. En versiones anteriores del protocolo, la obtención de cada recurso implicaba la apertura y cierre de una conexión TCP, con el consiguiente mal‐gasto de tiempo, CPU y memoria. El comportamiento por defecto en HTTP/1.1 es el mantenimiento de una o varias conexiones TCP sobre las que pueden realizarse sucesivas transacciones en paralelo (pipelining). Esto requiere un control más estricto de la longitud de los mensajes, pero tiene grandes ventajas. Cuando un cliente o un servidor no soporte esta característica, deberá incluir la cabecera Connection: close en cada mensaje para cerrar la conexión tras finalizar la transacción.

• División del cuerpo del mensaje en trozos. Un servidor puede comenzar una res‐puesta antes de conocer la longitud total de la misma. Para ello se emplea un esquema de transferencia indicado por la cabecera Transfer-Encoding: chunked.

• Mejora de la caché de datos, por ejemplo indicando a un user agent que no debe almacenar un recurso en caché mediante la cabecera Cache-Control: no-cache.

• Introducción de nuevos métodos.

6.1.2 Estructura y presentación estática de contenidos web

Una vez introducido el protocolo encargado de la transferencia de información con el servidor web, se describe en este apartado la naturaleza de la propia información. El listado de tecno‐logías incluido aquí hace referencia únicamente a aquellas que de alguna manera tienen


relación con la implementación particular realizada en este proyecto. El objetivo es ofrecer una visión superficial de la utilidad de las mismas, dado que se podrían dedicar libros enteros a una descripción medianamente rigurosa.

6.1.2.1 XML

El eXtensible Markup Language (XML) es un lenguaje de marcas desarrollado por el consorcio W3C a partir del estándar más complejo SGML, cuya recomendación puede obtenerse en [W3XML]. Para una introducción a las características de XML puede consultarse [JohnM], entre una infinidad de fuentes disponibles en Internet.

Como SGML, XML se considera un metalenguaje usado para describir otros lenguajes de marcado, permitiendo la definición totalmente flexible de etiquetas en multitud de documentos de distinto tipo. Puede decirse que XML no realiza nada en particular por sí mismo, sólo es una manera de estructurar, almacenar y transmitir información. Sin embargo, permite definir la gramática de otros lenguajes y dotar de significado a la información.

Diferencias con HTML

HTML también derivó de SGML, aunque sus objetivos de diseño fueron muy distintos de los de XML. Mientras XML trata de estructurar y dar sentido a la información, HTML se centra en cómo ésta debe ser representada. Entre sus puntos débiles, se pueden mencionar:

• HTML no es extensible. El conjunto de etiquetas HTML está predefinido, lo que puede ser una limitación en algunas aplicaciones que requieran un tratamiento especial, difícilmente obtenible a partir de este conjunto.

• HTML es un lenguaje centrado en la representación de contenidos. Además, sólo proporciona una única visión de la información.

• HTML carece de estructura semántica, haciendo imposible dotar de significado a los distintos elementos de la información. Por ejemplo, con HTML sería posible presen‐tar una tabla que contenga las características de los libros almacenados en una biblioteca, pero no habría forma de diferenciar semánticamente los elementos que corresponden a su título de los de su autor.

SGML no tiene ninguno de estos problemas, aunque su extremada complejidad lo hace poco adecuado en la mayoría de las ocasiones. Por este motivo surgió XML, una simplificación de SGML que conserva sus cualidades de extensibilidad, estructuración y validación de conte‐nidos, en un lenguaje mucho más fácil de aprender e implementar.

Ejemplo de un documento XML

A continuación se muestra un ejemplo simple de documento XML:

<?xml version="1.0" encoding="ISO-8859-1"?>

<instrumentos>

<guitarra tipo="electrica">

<marca>Ibanez</marca>

<precio moneda="euro">780</precio>

</guitarra>

</instrumentos>


La primera línea es la declaración XML, y no forma parte de la información, sino que identifica al documento como código XML. La declaración puede indicar la versión del lenguaje, la codificación empleada o un archivo de definición de tipos (DTD) donde se especi‐fican los elementos y atributos permitidos para que el documento se considere válido.

El resto del documento sigue una estructura jerárquica en árbol de elementos, el primero de los cuales se denomina raíz (instrumentos, en el ejemplo anterior). Algunos elementos pueden contener atributos, en cuyo caso se especifican en la etiqueta de apertura (por ejemplo, el elemento precio contiene un atributo denominado moneda). La última línea del documento es siempre la etiqueta de cierre del elemento raíz (</instrumentos>).

A diferencia de HTML, XML es sintácticamente muy estricto. Sus documentos deben estar «bien formados», lo que significa, entre otras cosas, que se debe ser coherente con el uso de las mayúsculas y minúsculas, así como respetar perfectamente la estructura jerárquica en el orden de apertura y cierre de etiquetas.

6.1.2.2 XHTML

El eXtensible HyperText Markup Language (XHTML) es un lenguaje basado en XML y concebido para convertirse en sustituto de HTML [W3XHTML].

XHTML puede considerarse una versión más estricta y limpia de HTML. De hecho, dispone de la mayoría de las etiquetas definidas en la especificación HTML 4, lo que facilita enormemente la migración a esta nueva tecnología. Entre las razones que justifican su aparición, pueden mencionarse:

• Al tratarse de una aplicación de XML, XHTML es extensible, por lo que es relativa‐mente sencillo introducir nuevos elementos o atributos para adaptarse a futuras recomendaciones y navegadores.

• Con la aparición de nuevos dispositivos y formas de acceso a Internet, se hace nece‐sario un lenguaje más estricto que HTML que permita una correcta interpretación de los contenidos, mejorando la interoperabilidad.

En la práctica, son pocas las diferencias con HTML. Algunos ejemplos son:

• Los documentos deben estar bien formados, es decir, la anidación de elementos debe realizarse de forma correcta, y todos ellos deben incluir la etiqueta de cierre:

<p>Ejemplo de elementos bien <em>anidados</em>.</p>

<p>Ejemplo de elementos mal <em>anidados</p>.</em>

• Los nombres de elementos y atributos deben escribirse en minúsculas:

<body>Ejemplo correcto</body>

<BODY>Ejemplo incorrecto</BODY>

• Todos los atributos deben tener un valor asociado, escrito entre comillas (incluso si son numéricos):

<td rowspan="3">Correcto</td>

<td rowspan=3>Incorrecto</td>

• Al derivar de XML, el documento debe comenzar con una línea de declaración seguida de la definición de tipo de documento (DTD) que se desea utilizar, y que dependerá de la propia versión de XHTML. Además, sólo puede existir un elemento raíz en todo el documento. Por ejemplo, un documento XHTML 1.0 Strict podría especificarse de esta manera:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es">

<head>

<title>Ejemplo de código XHTML 1.0 Strict</title>

</head>

<body>



</body>

</html>

Para asegurar que un documento cumple con este conjunto estricto de normas, la W3C proporciona una herramienta de validación en línea que puede consultarse en el sitio web http://validator.w3.org/.

6.1.2.3 CSS

Las hojas de estilo en cascada (Cascading Style Sheets) son un mecanismo que permiten describir cómo se va a presentar la información contenida en un documento, ya sea en un navegador web, en papel, o incluso mediante sonido a través de un dispositivo de lectura.

CSS surge con la necesidad de separar el estilo de la estructura en lenguajes de marcado como HTML o XML. Esto permite a los desarrolladores web controlar el estilo y el formato de múltiples páginas web al mismo tiempo, así como transformar radicalmente la presentación de un mismo documento sin modificar una sóla línea del código HTML o XML original (véanse ejemplos en http://www.csszengarden.com).

Funcionamiento básico de CSS

CSS funciona a base de reglas, es decir, declaraciones sobre el estilo de uno o más elementos. Las hojas de estilo están compuestas por una o más de esas reglas aplicadas a un documento HTML o XML. La regla tiene dos partes: un selector y la declaración. A su vez la declaración está compuesta por una o varias propiedades y el valor que se le asigne a cada una de ellas. Un ejemplo de regla CSS es el siguiente:

div {

width: 780px;

margin: 0 auto;

background: url(img1.gif) repeat-y;

}

En el ejemplo anterior, div es el selector, e identifica a todos los elementos que van a ser afectados por la declaración de estilo. Si se aplicara esta regla a un documento HTML, todos los elementos div tendrían la misma anchura de 780 px (especificada por la propiedad width), así como el resto de propiedades incluidas en la declaración anterior.

El selector puede ser también una clase o un identificador único de elemento. En el primer caso, el nombre del selector comienza con el carácter (#), mientras que en el último comienza con un punto (.). Por ejemplo, la regla #c0 {left: 0px;} afectará únicamente a los elementos que pertenezcan a la clase c0 (es decir, aquellos que tengan el atributo class="c0").

Otra característica importante de CSS es la propiedad de herencia, por la cual un estilo no se aplica únicamente a un elemento concreto, sino que es heredado por sus descendientes y aplicado por estos. En el siguiente ejemplo, si cambiamos la propiedad de color de la cabecera h1, el elemento em también se verá afectado:

<h1>Si esto es azul, <em>esto también lo es</em></h1>

Formas de aplicación de estilos

Las tres formas más conocidas de dar estilo a un documento son las siguientes:

• Utilizando una hoja de estilo externa que estará vinculada a un documento a través del elemento <link>, el cual debe ir situado en la sección <head>:

<html>

<head>

<title>Aplicando CSS al documento (1)</title>

<link href="estilos.css" rel="stylesheet" type="text/css" />

</head>

<body>



</body>

</html>

• Definiendo el estilo en la propia cabecera de la página, mediante el elemento <style>:

<html>

<head>

<title>Aplicando CSS al documento (2)</title>

<style type="text/css">

h1 {

font-family: Helvetica, Geneva, Arial, sans-serif;

}

</style>

</head>

<body>



</body>

</html>

• Utilizando estilos directamente sobre aquellos elementos que lo permiten a través del atributo <style> dentro de <body>. Este tipo de definición del estilo pierde las ventajas que ofrecen las hojas de estilo, al mezclar el contenido con la presentación.


6.1.3 Aplicaciones web dinámicas

Hasta ahora, todo lo que se ha comentado permite la presentación estática de contenidos: un usuario solicita un recurso y éste le es devuelto siempre de la misma manera. Sin embargo, existen numerosas técnicas que mejoran la interactividad entre el cliente y el servidor, y enriquecen la experiencia del usuario en la web. Todas ellas se basan en la ejecución de un programa o script en alguna de las partes de la comunicación.

Una de las primeras tecnologías que hizo posible la creación de contenido dinámico en páginas web fue CGI. Mediante esta técnica, un cliente solicita el resultado que genera un programa ejecutado en el servidor. Con otras tecnologías como ASP, JSP o PHP ocurre algo parecido: el usuario envía algún tipo de información al servidor (como puede ser un formu‐lario), el cual tras realizar las tareas oportunas (comprobación de errores, búsquedas en bases de datos, etc.) devuelve una página estática, pero generada dinámicamente.

También desde el lado del cliente es posible aportar dinamismo al contenido web. Por ejemplo, usando JavaScript se pueden realizar tareas que no requieren la intervención del servidor, como por ejemplo la validación de los campos de un formulario, o la modificación de los elementos de la página a través de su DOM (Document Object Model).

Sin embargo, el problema fundamental reside en la naturaleza síncrona de las transac‐ciones a través de Internet: cualquier solicitud al servidor implica la repetición de todo el proceso de generación, es decir, la página completa debe recargarse. Aunque se han propuesto varias soluciones a este problema, ninguna de ellas ha tenido tanta repercusión como AJAX, en especial por el éxito de aplicaciones como Gmail, Flickr, Google Maps, etc.

6.1.3.1 Asynchronous Javascript And XML (AJAX)

AJAX no puede considerarse una tecnología propiamente dicha, sino más bien una metodo‐logía de creación dinámica de contenidos basada en otras tecnologías, especialmente JavaScript. Este término se acuñó por primera vez en un artículo de Jesse James Garrett a principios de 2005 [GarrettJJ].

AJAX se fundamenta en la ejecución de un script en el lado del cliente, siendo totalmente independiente de la tecnología de servidor subyacente (ASP, CGI, PHP, etc.). Por otra parte, es soportado por defecto en la mayoría de los navegadores actuales, puesto que consiste en una combinación de XHTML, CSS, JavaScript, XML y otros estándares.

Lo realmente novedoso acerca de AJAX es que permite realizar peticiones asíncronas al servidor y obtener sólo pequeños fragmentos de información que luego son procesados por el cliente, de manera que se puede actualizar inmediatamente el contenido de la página sin necesidad de recargarla completamente. JavaScript proporciona una gran flexibilidad en la generación de estas peticiones y en el control del contenido de la página a través del DOM.

Como se verá más adelante, AJAX se utiliza en la página inicial del controlador OSC para indicar, en tiempo real, su configuración y el estado de sus entradas.


Funcionamiento básico de AJAX

La pieza clave de AJAX es el objeto de JavaScript XMLHttpRequest (abreviado como XHR), que se implementó originalmente como un control ActiveX de Internet Explorer 5 y luego fue adoptado como un estándar de facto por otros navegadores [AslesonR]. Aunque todavía no es un estándar, el W3C está desarrollando un borrador donde se especifican sus métodos y propiedades [W3XHR].

Un ejemplo típico de interacción cliente‐servidor mediante AJAX es el mostrado en la siguiente figura.

Cada uno de los pasos puede resumirse de la siguiente manera:

1 Se produce un evento en el navegador, que inicia el proceso. Este evento puede corresponder a multitud de circunstancias, como por ejemplo un click del usuario sobre un enlace determinado:

<a onclick="calcularPresupuesto();">Haga click aquí para confirmar</a>

2 El siguiente paso es la creación e inicialización de un objeto XMLHttpRequest. Dado que este objeto no es todavía estándar, su creación depende del navegador. En parti‐cular, Internet Explorer lo considera un control ActiveX, mientras que el resto de servidores lo tratarán como un objeto nativo de JavaScript. Una vez creado se invoca a su método open() para establecer los parámetros de conexión con el servidor. También es posible especificar que se realice automáticamente una llamada a una función determinada (función callback) cuando se reciba la respuesta. Finalmente, la petición se envía con una llamada al método send() del objeto XHR:

var xmlHttp; // Esta variable global almacenará el objeto XHR

function calcularPresupuesto() {

if (window.ActiveXObject) { // Si el navegador es IE, crear como ActiveX

xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

}

Figura 6.1: Secuencia típica de interacción mediante AJAX

EL SERVIDOR HTTP DE MICROCHIP 119

else if (window.XMLHttpRequest) { // En otro caso, como objeto JavaScript

xmlHttp = new XMLHttpRequest();

}

xmlHttp.open("GET", "/validar.cgi"); // HTTP método GET, url="/validar.cgi"

xmlHttp.onreadystatechange = callback; // Invoca a ‘callback’ al finalizar

xmlHttp.send(null); // Enviar la petición al servidor

}

3 Se realiza la petición, que puede incluir una llamada a un CGI o a cualquier otra téc‐nica del lado del servidor.

4 El servidor procesa la petición de alguna manera, lo que puede incluir la consulta a una base de datos, a otro sistema, etc.

5 La respuesta es devuelta al servidor. Esta respuesta normalmente se formatea como contenido XML.

6 En el ejemplo, se ha configurado el objeto XMLHttpRequest para invocar a la fun‐ción callback() cuando se recibe la respuesta. Para ello esta función determina el estado de la transacción mediante la propiedad readyState del objeto XHR, y tam‐bién mediante el código de estado HTTP devuelto por el servidor. Si todo es correcto, la información se procesa de alguna manera.

function callback() {

if (xmlHttp.readyState == 4 && xmlHttp.status == 200) {

// Hacer algo con la información aquí

}

}

Mediante la repetición de este proceso se pueden crear aplicaciones áltamente dinámicas e interactivas.

6.2 El servidor HTTP de MicrochipEn su versión 4.18, la pila de protocolos TCP/IP de Microchip incluye un servidor HTTP dispo‐nible en dos versiones. La segunda de ellas ofrece un conjunto más amplio de funciones y una API mejorada, aunque su implementación requiere más memoria. El controlador OSC hace uso de la segunda versión (aunque no de todas sus características), por lo que todo este desarrollo se referirá a la misma, definida en el archivo HTTP2.c.

En este apartado se describirá el servidor desde el punto de vista de un programador usuario del mismo. Se comenzará con la configuración de los distintos módulos que lo componen, para luego tratar el proceso de construcción de una aplicación web genérica.

6.2.1 Configuración del servidor HTTP

En el capítulo 5 se describieron las tareas que deben ser invocadas desde el código principal de la aplicación para permitir el funcionamiento del servidor. También se habló de la configu‐ración del resto de módulos de la pila mediante la modificación de determinadas macros, definidas en TCPIPConfig.h.


Algunas de estas macros son específicas del servidor HTTP. Las opciones más impor‐tantes pasan a comentarse a continuación:

• El número máximo de conexiones HTTP simultáneas se define mediante la macro MAX_HTTP_CONNECTIONS. Debe asegurarse la existencia de, al menos, un socket TCP por conexión HTTP.

• El nombre del archivo que el servidor devolverá por defecto, cuando no se especifica de manera explícita en la petición, se define de la siguiente manera:

#define HTTP_DEFAULT_FILE "index.html"

• La longitud del nombre especificado en el caso anterior debe también definirse para evitar problemas por desbordamiento de buffer provocados por la implementación propia del servidor:

#define HTTP_DEFAULT_LEN 11

• El servidor proporciona un método sencillo para actualizar el contenido de la EEPROM externa con una imagen MPFS del sistema de archivos que componen la aplicación web (páginas XHTML, hojas de estilo, etc.). Si se quiere utilizar esta fun‐cionalidad, se debe definir la macro mostrada a continuación, donde se especifica el nombre de un recurso del servidor asociado a ella. Normalmente esta macro se define sólo durante el desarrollo de la aplicación, y se comenta antes de generar el código definitivo:

#define HTTP_MPFS_UPLOAD "mpfsupload"

• Otras macros habilitan el soporte básico de cookies, autenticación y el método POST. Sólo este último se ha implementado en el controlador, dado que el resto tiene poca utilidad práctica para los objetivos buscados:

#define HTTP_USE_POST

6.2.2 Desarrollo de una aplicación web

Con los pasos dados hasta ahora en este capítulo y el anterior, el servidor está preparado para aceptar peticiones de páginas web estáticas. Únicamente será necesario disponer de una imagen MPFS válida en la EEPROM externa, que represente al conjunto de archivos accesibles a través de un navegador. Microchip proporciona una herramienta gratuita para la generación de esta imagen, y también para su almacenamiento en memoria no volátil a través del servidor HTTP. Otras opciones serían la utilización de un servidor FTP o la escritura directa en la EEPROM mediante un dispositivo programador específico, aunque ninguna de estas alterna‐tivas es más conveniente que la primera mencionada.

Por otro lado, en la mayoría de las aplicaciones el objetivo buscado será algo más práctico que la presentación de un documento estático. Para mejorar la interactividad con el usuario, el servidor ofrece dos funcionalidades importantes: la sustitución dinámica de variables y la lectura de valores enviados desde el cliente mediante formularios HTML, sopor‐tando los métodos GET y POST. Estas técnicas se analizarán en lo que sigue, aunque primero se comentarán de forma general los archivos y herramientas implicados en la aplicación.


En la figura 6.2 se muestra un esquema simplificado del proceso de construcción de una aplicación web. Debido a las limitaciones propias de un sistema empotrado como este, existirá una fuerte relación entre el firmware del microcontrolador y el propio contenido web. Por ejemplo, el servidor reconocerá secuencias especiales de caracteres en las páginas web y realizará llamadas a determinadas funciones de usuario asociadas a las mismas (lo que se conoce como sustitución de variables dinámicas).

De forma resumida, el proceso requiere los siguientes pasos:

1 Creación del conjunto de páginas web en un directorio único. Todos los archivos incluidos en él serán procesados por la utilidad MPFS y posteriormente almacena‐dos en la EEPROM, por lo que es importante reducir en lo posible el tamaño de los mismos.

2 Generación de la imagen MPFS. En este paso, la herramienta MPFS aplicará por defecto compresión GZip a los archivos de texto, salvo a aquellos con contenido dinámico o a los expresamente indicados por el usuario. Por cada variable dinámica encontrada en cualquiera de los archivos, la herramienta producirá la declaración de una función que el programador debe implementar para manejarla. El conjunto de declaraciones se guarda automáticamente en un archivo de cabecera llamado HTTPPrint.h, que no debe ser modificado. La otra salida generada por la herra‐mienta es la imagen MPFS del sistema de archivos, que debe almacenarse en la EEPROM externa del sistema por cualquiera de los métodos mencionados anterior‐mente.

3 La definición de todas las funciones declaradas en HTTPPrint.h, así como de otras necesarias para el procesamiento de formularios, se realiza por defecto en un archivo denominado CustomHTTPApp.c. Ambos archivos deben incluirse en el pro‐yecto de la aplicación junto con el resto de archivos de la pila y los definidos por el usuario. El proyecto se creará normalmente en el entorno de desarrollo MPLAB IDE (aunque existen otras alternativas de software libre).

4 La modificación posterior de las páginas web requiere la repetición de todo el pro‐ceso, salvo que sólo afecte a contenido estático.

Figura 6.2: Proceso de creación de una aplicación web dinámica


6.2.3 Sustitución de variables dinámicas

A continuación se ilustrará con ejemplos el empleo de variables dinámicas para la generación flexible de contenido web. Lo que sigue es igualmente válido para cualquier archivo de texto, ya sea una página web, una hoja de estilos o un código JavaScript, entre otros. Esta caracte‐rística ofrece un amplio rango de posibilidades al diseñador de la aplicación.

6.2.3.1 Variables dinámicas sin argumentos

Una variable dinámica es simplemente una cadena de caracteres delimitada por dos caracteres tilde (~). Cuando el servidor encuentra una de estas variables mientras procesa la respuesta a una petición HTTP, inmediatamente invoca a una función de usuario asociada antes de continuar con el llenado del buffer de transmisión TCP. El nombre de esta función comienza siempre con la cadena HTTPPrint_, seguida del nombre de la propia variable (recuérdese que las declaraciones de estas funciones las genera automáticamente la herramienta de construcción de imágenes MPFS).

Considérese un ejemplo en el que se pretende consultar el estado del pin RA0 del micro‐controlador mediante el servidor HTTP. Para ello se puede definir una variable denominada ~pin~ e incluirla en el siguiente código HTML:

<h1>Actualmente el pin está a nivel ~pin~</h1>

El programador debe también implementar la siguiente función en CustomHTTPApp.c:

void HTTPPrint_pin(void)

{

if(PORTAbits.RA0)

TCPPutROMString(sktHTTP, (ROM BYTE*)"alto"); // RA0=1, sustituye ~pin~ por "alto"

else

TCPPutROMString(sktHTTP, (ROM BYTE*)"bajo"); // RA0=0, sustituye ~pin~ por "bajo"

}

Como puede observarse, el programador toma el control del buffer TCP mientras se ejecuta la función HTTPPrint_pin() (función callback). La función TCPPutROMString() pertenece a una familia de funciones definidas en la API del módulo TCP para el llenado del buffer de transmisión. Debe tenerse en cuenta que, debido a la implementación interna del servidor, cuando se invoca a la función callback sólo se garantiza la existencia de 16 bytes libres en este buffer. Por lo tanto, si fuera necesario escribir más de 16 bytes, el programador debe asegurarse de la disponibilidad de espacio suficiente (por ejemplo mediante una llamada a TCPIsPutReady()). Si no existiese suficiente espacio libre, la función callback debe ceder el control a la pila para la transmisión del segmento TCP, y ser invocada posteriormente para continuar la escritura. Veamos un ejemplo de este caso.

Si se supone que la variable global cadena contiene un conjunto de caracteres recibidos a través de la UART, y que éstos se quieren mostrar en una página web mediante la variable dinámica ~uart~, la función callback asociada podría escribirse de la siguiente forma:

void HTTPPrint_uart(void)

{

if(strlen((char*)cadena) > TCPIsPutReady(sktHTTP))

{

// No hay espacio suficiente en el buffer. Intentarlo en la siguiente llamada.

curHTTP.callbackPos = 0x01; // callbackPos != 0 para invocar de nuevo a la función.

return;

}

// Sí hay espacio. Escribir y limpiar callbackPos para dar por finalizada a la función.

TCPPutString(sktHTTP, cadena);

curHTTP.callbackPos = 0x00;

}

curHTTP es una estructura que mantiene información sobre la conexión HTTP que está siendo procesada, y se almacena en la RAM del microcontrolador. Nótese que en este ejemplo se supone que en algún momento existirá espacio suficiente para toda la cadena. Si ésta es demasiado grande, se deben realizar escrituras parciales en el buffer de transmisión.

6.2.3.2 Variables dinámicas con argumentos

En determinadas ocasiones este sistema puede ser ineficiente en términos de consumo de memoria ROM. Para solucionarlo, el servidor hace posible la reutilización de código mediante el paso de parámetros a las funciones callback. Se pueden definir variables dinámicas con uno o dos parámetros enteros de 16 bits.

Supongamos que se quiere extender la funcionalidad del primer ejemplo de forma que se pueda leer el estado de todos los pines del puerto A. El código HTML quedaría en este caso de la siguiente manera:

<h1>Actualmente el pin RA0 está a nivel ~pin(0)~</h1>

<h1>Actualmente el pin RA1 está a nivel ~pin(1)~</h1>



El código de la función asociada podría definirse así:

void HTTPPrint_pin(WORD i)

{

BYTE temp;

temp = PORTA; // Lectura del puerto A

while(i!=0)

{

temp >>= 1; // Desplazar ‘i’ veces los bits a la derecha

i--;

}

temp &= 1; // temp es 1 sólo si el bit ‘i’ de PORTA también lo es

if(temp)

TCPPutROMString(sktHTTP, (ROM BYTE*)"alto"); // temp=1, sustituye ~pin(i)~ por "alto"

else

TCPPutROMString(sktHTTP, (ROM BYTE*)"bajo"); // temp=0, sustituye ~pin(i)~ por "bajo"

}

De esta forma es posible definir una única función para producir el mismo resultado que ocho funciones independientes, con el consiguiente ahorro de memoria y la mayor facilidad en la depuración de errores.

6.2.4 Procesamiento de formularios

La sustitución de variables dinámicas es una técnica adecuada para mostrar información acerca del estado interno del microcontrolador. Si se desea además que el usuario de la aplicación web pueda tener cierto control sobre el funcionamiento del dispositivo, será necesario utilizar alguna de las técnicas que se exponen a continuación1.

El servidor permite el procesamiento de los datos enviados a través de un formulario HTML en cualquiera de los métodos GET y POST de HTTP.

6.2.4.1 Método GET

Cuando un formulario HTML se envía mediante el método GET de HTTP, el conjunto de datos del mismo (form data set) se anexiona a la URI del recurso en el servidor [W3FDS]. Este conjunto de datos está formado por pares nombre=valor asociados a los elementos de entrada concretos de un formulario. Los datos se separan de la URI del recurso mediante un signo de interrogación (?), mientras que cada par se separa del siguiente con un carácter (&) (otros caracteres son también transformados en sus secuencias de escape correspondientes, aunque esto no se tratará aquí).

El método GET es el que se maneja de forma más sencilla por el servidor HTTP. Esto se debe a que toda la información proporcionada por el usuario se encuentra inmediatamente disponible en memoria cuando se invoca a la función encargada de su análisis. Sin embargo, por razones técnicas de la implementación del servidor, la longitud máxima del conjunto de datos del formulario es de unos 100 bytes. Cuando se necesita procesar más información es necesario emplear el método POST, que se verá más adelante.

Cuando el servidor recibe una petición de recurso con un conjunto de datos anexionados a su URL, éste se decodifica automáticamente y se almacena en el array curHTTP.data. Poste‐riormente se invoca a la función HTTPExecuteGet(), definida también en el archivo CustomHTTPApp.c y que el programador debe adaptar a su aplicación. Siguiendo el ejemplo anterior, supongamos que se pretende cambiar de nivel algún pin del puerto A mediante un formulario web. Los pasos a seguir podrían ser:

1 El primer paso consiste en la creación de un formulario HTML con un campo de control apropiado. Si suponemos que el usuario puede elegir mediante un menú desplegable el pin sobre el que quiere actuar, el código asociado podría ser el siguiente:

<form action=”index.html” method=”get”>

<select name=”pin”>

<option>0</option>

<option>1</option>



</select>

<input type="submit" value="Modificar estado">

</form>

1. Esto no es estrictamente necesario, puesto que este control puede conseguirse mediante lla‐madas a funciones callback asociadas a variables dinámicas. Sin embargo esto no hará posible la lectura de información proporcionada por el usuario.


2 Cuando se envía el formulario (o cuando se invoca al recurso mediante una URL con argumentos, como por ejemplo /index.html?pin=1) el servidor invoca a la función HTTPExecuteGet(), como se indicó anteriormente. Dado que esta función es invo‐cada siempre se recibe una petición sobre un recurso con argumentos, se debe com‐probar el nombre del recurso para poder diferenciarlos. La función MPFSGetFilename() devolverá el nombre del archivo asociado a la petición HTTP en la dirección que recibe como segundo argumento:

HTTP_IO_RESULT HTTPExecuteGet(void)

{

BYTE *ptr;

BYTE filename[20];

MPFSGetFilename(curHTTP.file, filename, 20);

if(!memcmppgm2ram(filename, (ROM void*)"index.html", 10))

{

// El recurso solicitado es "index.html", pueden procesarse los argumentos

3 Los argumentos almacenados en curHTTP.data pueden obtenerse mediante las fun‐ciones HTTPGetArg() y HTTPGetROMArg(), que reciben el nombre asociado a cada uno de ellos. En el caso del ejemplo, existe un único nombre llamado pin que puede reci‐bir 8 valores numéricos diferentes:

ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE *)"pin");

switch(*ptr)

{

case ‘0’:

PORTAbits.RA0 ^= 1;

break;

case ‘1’:

PORTAbits.RA1 ^= 1;

break;

// Continuar con el resto de pines...

}

} // Fin ‘if’

return HTTP_IO_DONE;

} // Fin de HTTPExecuteGet()

6.2.4.2 Método POST

En algunos casos la cantidad de información a enviar en el formulario es demasiado grande como para poder usar el método GET, o simplemente se quiere evitar que el usuario pueda modificar el conjunto de datos a través de la URL del recurso. En estos casos es necesario emplear el método POST, que como se verá es más complejo que el anterior.

Cuando se utiliza el método POST, los datos se anexionan al cuerpo del mensaje HTTP, después de las cabeceras. El usuario debe tomar el control del buffer TCP, buscando la infor‐mación necesaria y liberando espacio para permitir la llegada de más datos. Dado que este buffer se aloja normalmente en la FIFO interna del controlador Ethernet, ya no es posible usar las funciones HTTPGetArg() anteriores para encontrar la información útil.


La petición de un recurso mediante POST implica normalmente la inclusión de una cabecera HTTP que indica la longitud total del cuerpo del mensaje (salvo que ésta sea cero). Esta cabecera (Content-Length) permite al programador conocer cuándo se han terminado de procesar todos los datos recibidos.

Como en el caso anterior, el servidor invoca automáticamente una función callback cada vez que recibe una petición POST, denominada HTTPExecutePost(). También almacena la longitud del cuerpo del mensaje en la variable curHTTP.byteCount. El programador debe decrementar esta variable cada vez que se extraigan datos del buffer TCP, que se consigue mediante las familias de funciones TCPFind() y TCPGet(). La primera proporciona un método flexible de localización de datos en el buffer, ya sea un carácter determinado o una cadena. Una vez determinada la localización de la información útil, la segunda realiza una copia de datos desde el buffer TCP hasta la RAM del microcontrolador, liberando espacio para permitir la llegada de nuevos segmentos.

Si se supone que al formulario del ejemplo anterior se le añaden nuevos elementos de entrada, y que se envía al servidor mediante el método POST, la función HTTPExecutePost() podría implementarse de la siguiente manera:

1 El primer paso consiste en la discriminación del recurso al que hace referencia la petición, y no se diferencia en nada del caso anterior:

HTTP_IO_RESULT HTTPExecutePost(void)

{

BYTE *ptr;

BYTE filename[20];

WORD len;


if(memcmppgm2ram(filename, (ROM void*)"index.html", 10))

return HTTP_IO_DONE; // El recurso solicitado no es "index.html", terminar.

2 Seguidamente se procesan consecutivamente los pares nombre=valor, hasta que se requieran más datos del buffer TCP o se llegue al final del cuerpo del mensaje (es decir, hasta que curHTTP.byteCount sea igual a cero). La función TCPFind() será útil para determinar la posición de cada par, que como se sabe se separan mediante (&). Por otra parte, TCPIsGetReady() devolverá el número de bytes todavía disponibles en el buffer de recepción TCP:

while(curHTTP.byteCount)

{

len = TCPFind(sktHTTP, '&', 0, FALSE); // Determina la posición de ‘&’

if(len == 0xffff)

{

// ‘&’ no encontrado, comprobar si es el último par nombre=valor

if (TCPIsGetReady(sktHTTP) == curHTTP.byteCount)

len = curHTTP.byteCount; // Es el último par

else

return HTTP_IO_NEED_DATA; // Se necesitan más datos. Devolver esto para

// que el servidor invoque de nuevo a la func.

}


3 En este punto, la variable len contiene la longitud de un par nombre=valor. Ahora este par puede extraerse del buffer TCP y almacenarse en la RAM. Como almacena‐miento temporal se utilizará el array curHTTP.data, asociado a la conexión HTTP. Nótese que debe asegurarse que este array contiene espacio suficiente para la lectura del buffer TCP, aunque esta comprobación no se hará en este ejemplo. Una vez en la RAM, los datos se decodifican mediante una llamada a HTTPURLDecode() antes de comenzar con el chequeo de cada campo:

// Obtener ‘len’ bytes desde el buffer TCP y actualizar curHTTP.byteCount

curHTTP.byteCount -= TCPGetArray(sktHTTP, curHTTP.data, len);

// Incluir el terminador de cadena

curHTTP.data[len] = '\0';

// Decodificar los datos

HTTPURLDecode(curHTTP.data);

4 El array curHTTP.data contiene ahora dos cadenas terminadas con el carácter nulo que representan el nombre de un campo del formulario y su valor asociado:

if(!memcmppgm2ram(curHTTP.data, (ROM void*)"pin\0", 4))

{

// El nombre del campo es ‘pin’. Su argumento es un número [0-7].

switch (curHTTP.data[4])

{

case ‘0’:

PORTAbits.RA0 ^= 1;

break;

case ‘1’:

PORTAbits.RA1 ^= 1;

break;

// Continuar con el resto de pines...

}

}

else if( // Comprobar el resto de nombres del formulario...

5 El último paso consiste en eliminar los posibles caracteres de separación de variables que puedan encontrarse al comienzo del buffer de recepción. Esto se realiza aquí para preparar la lectura del próximo par nombre=valor:

// Eliminar caracteres de separación para preparar la próxima lectura.

while( TCPFind(sktHTTP, '&', 0, FALSE) == 0 ||

TCPFind(sktHTTP, '\r', 0, FALSE) == 0 ||

TCPFind(sktHTTP, '\n', 0, FALSE) == 0 )

{

curHTTP.byteCount -= TCPGet(sktHTTP, NULL);

}

} // Fin del bucle while

} // Fin de la función HTTPExecutePost().

Como puede verse, el procesamiento de un formulario enviado mediante POST puede ser considerablemente más complejo que con el método GET, aunque en algunos casos su utilización resulta imprescindible.


6.3 La interfaz web de monitorización y controlLa aplicación web integrada en el controlador OSC permite la modificación de sus parámetros de funcionamiento y la monitorización del estado de las entradas. En este apartado se comen‐tarán algunos aspectos relativos al diseño de la interfaz. Ésta se compone de cuatro páginas web de las cuales la última es completamente estática, por lo que no se mencionará aquí.

6.3.1 Página de estado

En la figura 6.3 se muestra el aspecto de la página inicial del controlador. El menú superior permite navegar entre las distintas páginas que componen la interfaz, mientras que el resto es información relativa al estado. Se indicará brevemente cómo se ha implementado.

6.3.1.1 Variables dinámicas

La información acerca de la configuración del controlador no varía normalmente durante su funcionamiento, por lo que se ha implementado mediante variables dinámicas. Las variables definidas y sus funciones asociadas son las siguientes:

Figura 6.3: Página web inicial del controlador OSC

LA INTERFAZ WEB DE MONITORIZACIÓN Y CONTROL 129

• Nombre del controlador, que se sustituye mediante la variable ~nodename~. Como se indicó en el capítulo anterior, este nombre se almacena en la estructura OscConfig, por lo que la función asociada es simplemente:

void HTTPPrint_nodename(void)

{

TCPPutArray(sktHTTP, OscConfig.OscNodeName,

strlen((char*)OscConfig.OscNodeName));

}

• Dirección del host remoto, cuya variable dinámica es ~remotehost~:

void HTTPPrint_remotehost(void)

{

TCPPutArray(sktHTTP, OscConfig.RemoteAddr,

strlen((char*)OscConfig.RemoteAddr));

}

• Puerto UDP remoto, con variable ~remoteport~. Dado que un puerto es un entero de 16 bits, será necesario transformarlo en una cadena con representación decimal:

void HTTPPrint_remoteport(void)

{

BYTE String[8];

uitoa(OscConfig.RemotePort, String);

TCPPutArray(sktHTTP, String, strlen((char*)String));

}

• Indicación del modo digital (normal o matriz de interruptores), con la variable ~dmode~:

void HTTPPrint_dmode(void)

{

if(OscConfig.Flags.bUseSwm)

TCPPutROMArray(sktHTTP, (ROM BYTE*)"Matriz", 6);

else

TCPPutROMArray(sktHTTP, (ROM BYTE*)"Normal", 6);

}

• Indicación del método Rotary. La variable dinámica asociada es ~denc~:

void HTTPPrint_denc(void)

{

if(OscConfig.Flags.bUseRot)

TCPPutROMArray(sktHTTP, (ROM BYTE*)"Sí", 9);

else

TCPPutROMArray(sktHTTP, (ROM BYTE*)"No", 2);

}

6.3.1.2 Actualización del estado mediante AJAX

El gráfico de las entradas analógicas es una representación de los argumentos asociados al método Analog que están siendo enviados en cada momento. Lo mismo ocurre con la matriz de entradas digitales.


Para permitir esta monitorización sin tener que recargar continuamente la página en el navegador, se ha recurrido al empleo de AJAX. El efecto se consigue mediante la combinación de esta técnica con el posicionamiento adecuado de contenedores XHTML (<div> y <span>) mediante CSS. Veamos con más detalle algunos aspectos de la implementación.

Envío de peticiones con AJAX

Toda la información necesaria para actualizar la página web de estado se obtiene de un mismo archivo XML, que se definirá más adelante. Una vez esta página es cargada por completo en el cliente, se ejecuta el código JavaScript incluido en el archivo etherosc.js1. De forma resumida, el código realiza las siguientes acciones:

1 Se realiza el envío de una petición AJAX del recurso status.xml mediante una lla‐mada a la función newAJAXCommand(), que se encarga de la construcción y el manejo de los objetos XMLHttpRequest que se introdujeron en el apartado 6.1.3.1. Cada objeto XHR creado en una petición se almacena en otro objeto con información sobre la función encargada de procesar la respuesta, la marca de tiempo en la que comenzó el envío, etc. Es importante tener en cuenta que todas las peticiones se rea‐lizan mediante el método POST de HTTP, aunque no se incluya ninguna informa‐ción en el cuerpo del mensaje. De esta manera, el servidor responderá con la cabecera HTTP Cache-Control: no-cache, indicando al navegador que no debe con‐siderar que la respuesta es estática, e impidiendo su almacenamiento en la caché interna2. La primera petición AJAX se genera de la siguiente manera:

// status.xml es el recurso. updateStatus es la función que procesa la respuesta

// El último parámetro indica que se debe repetir la petición indefinidamente

newAJAXCommand('status.xml', updateStatus, true);

2 El objeto asociado a cada petición se almacena en un array de JavaScript. La función pollAJAX(), invocada cada 10 ms, comprueba el estado de cada uno de estos objetos. Si se ha recibido la respuesta de uno de ellos, el objeto se elimina del array y se invoca a su función asociada con los datos recibidos. Cuando una respuesta tarda demasiado en llegar (más de 5 segundos), se aborta la transferencia del método XHR y se invoca a la función asociada con null como argumento. En cualquier caso, si se especificó que la petición debe repetirse indefinidamente, se vuelve a invocar a la función newAJAXCommand() con los mismos parámetros. De esta manera, con una única petición inicial se puede obtener un flujo continuo de información sobre el estado del controlador.

Procesamiento de las respuestas

Como se ha indicado, el recurso solicitado en cada petición mediante AJAX es el archivo XML status.xml. Este archivo contiene la siguiente información:

1. La definición de este código en un archivo distinto del de la página web no sólo es una manera más ordenada de organizar la aplicación, sino que permite ahorrar espacio en la memoria EEPROM (recordemos que un archivo sin contenido dinámico puede ser compri‐mido mediante GZip).

2. Este comportamiento es diferente del caso en el que la petición se realice mediante GET, por la propiedad de idempotencia que se asocia a este método.


<response>

<sta>~sta~</sta>

<an0>~ana(0)~</an0>

<an1>~ana(1)~</an1>

<an2>~ana(2)~</an2>

<an3>~ana(3)~</an3>

<an4>~ana(4)~</an4>

<an5>~ana(5)~</an5>

<an6>~ana(6)~</an6>

<an7>~ana(7)~</an7>

<dig>~dig~</dig>

<swm>~swm~</swm>

</response>

El servidor sustituirá cada variable dinámica por su valor correspondiente antes de realizar el envío. Estas variables se definieron de la siguiente manera:

• Como puede verse en la figura 6.3, el primer elemento de la lista indica el estado de la conexión de red. Éste depende a su vez del estado de la tarea OSCClientTask() que se describió en el capítulo 5 (resoluciones ARP y DNS, obtención de socket UDP, etc.). La variable ~sta~ devolverá este estado, aunque como un valor numérico, y no como una serie de cadenas de caracteres que lo describen. El propio script ejecutado en el cliente sustituirá este valor por su descripción correspondiente, agilizando de esta forma la respuesta del servidor:

void HTTPPrint_sta(void)

{

// Devuelve el estado actual de la máquina de estados de OSCClientTask()

TCPPut(sktHTTP, (BYTE)(OSCClientState + '0'));

return;

}

• La variable ~ana()~ recibe un parámetro que hace referencia a uno de los ocho cana‐les analógicos disponibles. Únicamente se devolverán estos valores cuando el método Analog esté activado. De esta manera, la función que procesa la respuesta XML puede tomar las acciones oportunas sobre estilo del gráfico mostrado en la página web. Por conveniencia, los argumentos devueltos se toman del array wAnalogLastSent, reflejando incluso el efecto del filtro digital sobre las entradas:

void HTTPPrint_ana(WORD num)

{

BYTE ANAString[8];

// Si el método está desactivado o el argumento no es válido, terminar.

if((!OscConfig.Flags.bSendAnalog)||(num>7))

return;

// Convertir el argumento en una cadena de caracteres y llenar el buffer TCP.

// La cadena no llegará nunca al límite de 16 bytes.

uitoa(wAnalogLastSent[num].Val, ANAString);

TCPPutArray(sktHTTP, ANAString, strlen((char*)ANAString));

}


• La variable ~dig~ devuelve el argumento del método Digital como una cadena de caracteres de ceros y unos. Como en el caso anterior, no se devuelve ninguna infor‐mación si el método no está activado:

void HTTPPrint_dig(void)

{

BYTE DIGString[8];

BYTE i;

BYTE *p;

BYTE data;

BYTE mask;


return;

mask = 0x80;

p = &DIGString[0];

data = OscData.dwDigital.v[3];

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

{

*p++ = (data&mask) ? '1':'0';

mask >>= 1;

}

TCPPutArray(sktHTTP, DIGString, 8);

}

• La variable ~swm~ hace lo propio con el argumento del método SwitchMatrix. Nótese que en este caso se devuelve una cadena de 16 caracteres, que es justamente el límite máximo de información que puede escribirse en el buffer de transmisión sin necesi‐dad de comprobar su espacio disponible. En este caso se devuelve off si el modo de entrada digital no es el de matriz de interruptores.

void HTTPPrint_swm(void)

{

BYTE SWMString[16];

BYTE i;

BYTE *pLow;

BYTE *pHigh;

BYTE dataLow;

BYTE dataHigh;

BYTE mask;


return;

if(!OscConfig.Flags.bUseSwm)

{

TCPPutROMArray(sktHTTP, (ROM BYTE*)"off", 3);

return;

}

mask = 0x80;


pHigh = &SWMString[0];

pLow = &SWMString[8];

dataHigh = OscData.dwSwitchMatrix.v[2];

dataLow = OscData.dwSwitchMatrix.v[3];

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

{

*pHigh++ = (dataHigh&mask) ? '1':'0';

*pLow++ = (dataLow&mask) ? '1':'0';

mask >>= 1;

}

TCPPutArray(sktHTTP, SWMString, 16);

}

Todos estos valores son analizados por el script del cliente, que finalmente actualiza la presentación de la información en la página web. Esto se realiza mediante las funciones de acceso al DOM, que permiten actuar sobre la definición de los estilos y el contenido de elementos XHTML concretos. La función encargada de esta tarea a partir del análisis del archivo XML se ha denominado updateStatus(), incluida en el archivo etherosc.js. Esta función es bastante densa, y depende además del código XHTML desarrollado, así como de las reglas de estilo definidas en etherosc.css. Por este motivo, una descripción aquí de esta función puede resultar poco intuitiva para el lector, aunque el código desarrollado contiene numerosos comentarios sobre su implementación y se encuentra disponible en el CD adjunto a esta memoria.

6.3.1.3 Activación y desactivación de métodos

Aunque el objetivo de la página inicial es el de mostrar información, también es posible activar o desactivar el envío de mensajes OSC analógicos y/o digitales. Para ello puede hacerse click en el título de la sección correspondiente. Por ejemplo, el título en el caso de la sección analógica se define mediante el siguiente código XHTML:

<a onclick="newAJAXCommand('toggle.cgi?input=a');">Entradas analógicas</a>

Un click en este enlace provocará el envío de una petición AJAX del recurso toggle.cgi?input=a. Aunque la petición se realiza mediante el método POST de HTTP, la función HTTPExecuteGet() será también invocada, puesto que la URL del recurso contiene argumentos. En este caso la respuesta no se procesará en el navegador, por lo que la infor‐mación contenida en el archivo toggle.cgi es completamente indiferente, y de hecho conviene que sea nula. La función HTTPExecuteGet() se ha implementado de la siguiente manera:

HTTP_IO_RESULT HTTPExecuteGet(void)

{

BYTE *ptr;

BYTE filename[20];


if(!memcmppgm2ram(filename, (ROM void*)"toggle.cgi", 10))

{

// El recurso es "toggle.cgi"


ptr = HTTPGetROMArg(curHTTP.data, (ROM BYTE *)"input");

// Cambiar la activación de las entradas si el parámetro recibido es válido

if(*ptr == 'a')

OscConfig.Flags.bSendAnalog = ~OscConfig.Flags.bSendAnalog;

else if(*ptr == 'd')

OscConfig.Flags.bSendDigital = ~OscConfig.Flags.bSendDigital;

}


}

6.3.2 Página de configuración de parámetros OSC

La página osc.html contiene un formulario desde donde se pueden configurar todos los parámetros del cliente OSC, y que se envía mediante el método POST. Cuando la página se carga, el formulario refleja el estado actual de la configuración, para lo cual se han definido un conjunto de variables dinámicas. Veamos los campos que contiene este formulario:

• Nombre del controlador. Este campo consiste en una entrada de texto cuyo valor por defecto se establece mediante el atributo XHTML value="~nodename~". La fun‐ción asociada a la variable dinámica ya se ha descrito, por lo que no se repetirá aquí.

• Host remoto. Similar al anterior, con un valor por defecto establecido por la variable ~remotehost~.

• Puertos UDP local y remoto. También consisten en un control de texto con variables ~localport~ y ~remoteport~, respectivamente.

• Activación de las entradas analógicas. Este control es de tipo checkbox, y contiene una variable dinámica ~sendanalog~ que se sustituye por el atributo XHTML checked="checked" cuando las entradas analógicas están activadas. En ese caso, la casilla correspondiente aparecerá marcada al cargar la página web:

void HTTPPrint_sendanalog(void)

{

if(OscConfig.Flags.bSendAnalog)

TCPPutROMArray(sktHTTP, (ROM BYTE*)"checked=\"checked\"", 17);

}

• Filtro digital. Dado que las opciones de configuración del filtro digital son excluyen‐tes, se ha utilizado un control de tipo radio button. Como en el caso anterior, las dis‐tintas opciones pueden contener el atributo checked. Para ello se ha implementado la variable dinámica ~average()~, que recibe un parámetro distinto por cada opción disponible. El orden de aparición de estas opciones en el formulario coincide con el orden de prioridad de cada tipo de filtro (recuérdese que el filtro IIR tiene prioridad sobre el FIR), por lo que no habrá ambigüedad en el caso no deseable de que existan varias opciones con este atributo.

void HTTPPrint_average(WORD i)

{

BYTE res;


switch(i)

{

case 0:

res = !(OscConfig.Flags.bAnalogAvg1 || OscConfig.Flags.bAnalogAvg2);

break;

case 1:

res = OscConfig.Flags.bAnalogAvg1;

break;

case 2:

res = OscConfig.Flags.bAnalogAvg2;

break;

default:

res = 0;

}

if(res)

TCPPutROMArray(sktHTTP, (ROM BYTE*)"checked=\"checked\"", 17);

}

• Activación de las entradas digitales. Similar al de las entradas analógicas.

• Configuración del modo de entrada digital. Control de tipo radio button, equivalente al ya mencionado para el filtro digital.

• Activación del método Rotary, mediante un control tipo checkbox.

• Activación del envío de mensajes en ráfaga, idéntico al anterior.

La página contiene además un pequeño script que deshabilita algunos de estos controles cuando dependen de otros que no están activados. Por ejemplo, no será posible activar el método Rotary en el modo digital de matriz de interruptores.

Como ya se ha explicado, cuando se envía el formulario mediante el método POST, el servidor invoca a la función HTTPExecutePost(). Esta función comprueba el nombre del recurso al que hace referencia la petición y llama a una función asociada al mismo, que en el caso de este formulario se denomina HTTPPostOsc().

HTTPPostOsc() sigue el esquema de funcionamiento comentado en el apartado 6.2.4.2, y modifica la estructura OscConfig y algunos bits de OscData. Su código es bastante denso, por lo que aquí se omitirán algunos detalles sobre su implementación, aunque se insta al lector a consultar el apartado mencionado y los archivos adjuntos a este documento.

static HTTP_IO_RESULT HTTPPostOsc(void)

{

BYTE *ptr;

WORD len;

// Es necesario establecer en este punto los valores por defecto de los controles

// ‘checkbox’, puesto que éstos no se envían en el formulario cuando están desactivados

OscConfig.Flags.bSendAnalog = 0;

OscConfig.Flags.bSendDigital = 0;

OscConfig.Flags.bUseRot = 0;

OscConfig.Flags.bSendOnChange = 1;



{

/* ... lectura del buffer TCP y decodificación de valores, ver ap. 6.2.4.2 ... */

if(!memcmppgm2ram(curHTTP.data, (ROM void*)"nodename\0", 9))

{

// Comprobar primero que el nombre especificado es válido

ptr = &curHTTP.data[9];

if(!isValidHostName(ptr, 15))

continue;

// El nombre es válido, actualizar OscConfig

strcpy(OscConfig.OscNodeName, (char*)&curHTTP.data[9]);

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"remotehost\0", 11))

{

ptr = &curHTTP.data[11];

if(!isValidHostName(ptr, 31))

continue;

strcpy(OscConfig.RemoteAddr, (char*)&curHTTP.data[11]);

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"localport\0", 10))

{

// Convertir la cadena especificada en un número de puerto, sólo si ésta es válida

StringToPort((BYTE*)&curHTTP.data[10], &OscConfig.LocalPort);

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"remoteport\0", 11))

{

StringToPort((BYTE*)&curHTTP.data[11], &OscConfig.RemotePort);

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"sendanalog\0", 11))

{

// Se puede ignorar el valor asociado a un control ‘checkbox’. Si existe el nombre,

// el control estará activado.

OscConfig.Flags.bSendAnalog = 1;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"senddigital\0", 12))

{

OscConfig.Flags.bSendDigital = 1;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"userotary\0", 10))

{

OscConfig.Flags.bUseRot = 1;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"burst\0", 6))

{

OscConfig.Flags.bSendOnChange = 0;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"avg\0", 4))

{

// Inicializar a cero el filtro digital y luego activarlo si es necesario

OscConfig.Flags.bAnalogAvg1 = 0;


if(curHTTP.data[4] == '1')



else if(curHTTP.data[4] == '2')


}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"dmode\0", 6))

{

// La bandera OscData.Flags.bChangeDMode debe activarse sólo si el modo digital

// es diferente del actual

if((curHTTP.data[6] == '1' && !OscConfig.Flags.bUseSwm) ||

(curHTTP.data[6] == '0' && OscConfig.Flags.bUseSwm))

OscData.Flags.bChangeDMode = 1;

}

/* ... preparar el buffer TCP antes de procesar el siguiente valor ... */

}

// En cualquier caso, indicar que hay una nueva configuración para poder cambiar al

// estado SM_NEW_CONFIG de la tarea OSCClientTask()

OscData.Flags.bNewConfig = 1;

// Redireccionar a la página "warning.html" si el modo de entrada digital ha cambiado

if(OscData.Flags.bChangeDMode)

{

strcpypgm2ram((char*)curHTTP.data, (ROM void*)"warning.html");

curHTTP.httpStatus = HTTP_REDIRECT;

}


}

En referencia a este código se pueden hacer los siguientes comentarios:

• La función isValidHostName() comprueba que la cadena que recibe como primer parámetro contiene únicamente caracteres alfanuméricos y/o los caracteres punto (.) y guión (‐), y que además tiene una longitud no nula inferior al máximo especificado en su segundo parámetro. Por lo tanto, se ignorarán los nombres de controlador y las direcciones remotas que no cumplan este formato.

• Como ya se indicó en el capítulo anterior, el cambio de modo de entrada digital puede dañar el hardware si no se realizan las modificaciones oportunas. Para adver‐tir al usuario de este hecho, la página de configuración se redirecciona a otra que contiene un mensaje de advertencia, de nombre warning.html. La redirección se rea‐liza como se indica en la última sentencia if del código anterior.

6.3.3 Página de configuración de red

El otro formulario de la aplicación se encuentra en la página network.html. En él se definen los parámetros de red, que no afectan sólo a las funciones OSC sino a todos los módulos de la pila. Todos sus campos son entradas de texto, salvo el primero de ellos. Se enumeran a conti‐nuación:

• Activación del servidor DCHP. Es el único campo de tipo checkbox. Tiene una varia‐ble dinámica asociada que establece el atributo checked en caso necesario, tal y como se vio anteriormente.


• Dirección IP, máscara de subred, pasarela y direcciones DNS. Estos campos de texto se inicializan con los valores adecuados mediante variables dinámicas. Por ejemplo, en el caso de la dirección IP, el campo tiene el atributo HTML value="~config_ip~" y la siguiente función asociada:

void HTTPPrint_config_ip(void)

{

HTTPPrintIP(AppConfig.MyIPAddr);

}

void HTTPPrintIP(IP_ADDR ip)

{

BYTE digits[4];

BYTE i;

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

{

if(i != 0)

TCPPut(sktHTTP, '.');

uitoa(ip.v[i], digits);

TCPPutArray(sktHTTP, digits, strlen((char*)digits));

}

}

• El último campo es la dirección MAC del dispositivo, y es solamente informativo. Su representación requiere más de 16 bytes, por lo que es necesario asegurar la existen‐cia de suficiente espacio en el buffer de transmisión (ver apartado 6.3.1.1). La fun‐ción asociada es la siguiente:

void HTTPPrint_config_mac(void)

{

BYTE i;

if(TCPIsPutReady(sktHTTP) < 18)

{

// Se necesitan 17 bytes para escribir la MAC. Si no hay espacio,

// intentarlo de nuevo más tarde


return;

}

// Sí hay espacio en el buffer, escribir cada byte en hexadec separados por ‘:’

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

{

if(i != 0)

TCPPut(sktHTTP, ':');

TCPPut(sktHTTP, btohexa_high(AppConfig.MyMACAddr.v[i]));

TCPPut(sktHTTP, btohexa_low(AppConfig.MyMACAddr.v[i]));

}

// Hecho, evitar que se invoque de nuevo a la función


}


La función encargada de procesar el conjunto de datos del formulario se denomina ahora HTTPPostNetwork(), y es muy similar a HTTPPostOsc(). Se expone a continuación un resumen de su código:

static HTTP_IO_RESULT HTTPPostNetwork(void)

{

BYTE *ptr;

WORD len;

// Establecer en este punto el valor por defecto del control ‘checkbox’

AppConfig.Flags.bIsDHCPEnabled = 0;


{

/* ... lectura del buffer TCP y decodificación de valores, ver ap. 6.2.4.2 ... */

if(!memcmppgm2ram(curHTTP.data, (ROM void*)"ip\0", 3))

{

if(StringToIPAddress(&curHTTP.data[3], &AppConfig.MyIPAddr))

memcpy((void*)&AppConfig.DefaultIPAddr,(void*)&AppConfig.MyIPAddr,sizeof(IP_ADDR));

else

continue;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"gw\0", 3))

{

if(!StringToIPAddress(&curHTTP.data[3], &AppConfig.MyGateway))

continue;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"subnet\0", 7))

{

if(StringToIPAddress(&curHTTP.data[7], &AppConfig.MyMask))

memcpy((void*)&AppConfig.DefaultMask, (void*)&AppConfig.MyMask, sizeof(IP_ADDR));

else

continue;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"dns1\0", 5))

{

if(!StringToIPAddress(&curHTTP.data[5], &AppConfig.PrimaryDNSServer))

continue;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"dns2\0", 5))

{

if(!StringToIPAddress(&curHTTP.data[5], &AppConfig.SecondaryDNSServer))

continue;

}

else if(!memcmppgm2ram(curHTTP.data, (ROM void*)"dhcpenabled\0", 12))

{

// Es un ‘checkbox’, la existencia del nombre ya indica que está marcado

AppConfig.Flags.bIsDHCPEnabled = 1;

}

/* ... preparar el buffer TCP antes de procesar el siguiente valor ... */

}


// Hacer coincidir el nombre NetBIOS con el del controlador OSC. La función

// FormatNetBIOSName() convierte la cadena a mayúsculas y fija su longitud en 15 bytes

strcpy(AppConfig.NetBIOSName, OscConfig.OscNodeName);

FormatNetBIOSName(AppConfig.NetBIOSName);

// Guardar la nueva configuración en EEPROM interna

SaveAppConfig();

// Resetear el sistema para que los cambios tengan efecto

Reset();


}

Como se deduce del código anterior, los parámetros incorrectos son simplemente ignorados. La función StringToIPAddress() convierte a formato binario una cadena de carac‐teres que representa una IP en formato decimal con puntos, sólo en el caso de que ésta esté bien formada. El resto del código de la función es bastante intuitivo, por lo que no necesita mayor explicación.

6.3.4 Diseño de las páginas web

Las páginas que componen la aplicación web han sido diseñadas conforme a los estándares XHTML 1.0 Strict y CSS versión 2.1, y todas ellas pasan las pruebas de validación correspon‐dientes del W3C para asegurar su interoperabilidad. Aunque la única herramienta estricta‐mente necesaria para su desarrollo es un editor de texto, existen otras alternativas gratuitas que lo facilitan considerablemente. En este proyecto se emplearon las que se indican a conti‐nuación.

6.3.4.1 Aptana Studio

Aptana Studio es un entorno de desarrollo open source basado en la plataforma Eclipse y enfocado a aplicaciones web, con especial atención a AJAX. Entre sus características, se pueden mencionar:

• Edición y depuración de código HTML, CSS, DOM y JavaScript con coloreado de sintaxis.

• Asistentes de código para estos lenguajes, así como una extensa documentación y referencias de sus APIs.

• Previsualización en los principales navegadores web.

• Multitud de ejemplos de código.

• Entorno extensible por medio de cientos de plugins gratuitos.

Otra herramienta interesante es Aptana Jaxer, un servidor web para el desarrollo de aplicaciones AJAX que permite la escritura de scripts de servidor en JavaScript, permitiendo consultas a bases de datos, acceso al sistema de archivos, comunicaciones de red, etc.

Ambas herramientas pueden descargarse en http://www.aptana.com/products.


6.3.4.2 Firebug

Firebug es una extensión para Mozilla Firefox, también gratuita y de código abierto. Si bien no es una herramienta adecuada para el desarrollo de código (puesto que no permite guardar los cambios realizados), sí es extremadamente útil para inspeccionar los elementos de una página web y comprobar rápidamente cómo afectan a su apariencia los cambios realizados a sus reglas de estilo. También dispone de otras características interesantes como las que se indican a continuación:

• Integración en la ventana del navegador web, aunque puede abrirse en una ventana independiente.

• Inspección y modificación de elementos HTML, así como de reglas de estilo.

• Visualización avanzada de métricas CSS que facilita el posicionamiento de elemen‐tos.

• Monitorización de las conexiones de red.

• Depuración y ejecución de comandos JavaScript.

• Exploración de la jerarquía de objetos DOM.

Esta herramienta puede descargarse gratuitamente en http://www.getfirebug.com.

Figura 6.4: Edición XHTML en el entorno de desarrollo Aptana Studio


Figura 6.5: Inspección de un elemento XHTML en Firebug

7capítulo

Consideraciones finales

lo largo del presente Proyecto Fin de Carrera se ha abordado el diseño de un cliente OpenSound Control concebido como un controlador génerico de software multimedia.

Esta tarea se justifica por la escasez de dispositivos basados en este protocolo en comparación con su predecesor, menos potente, MIDI. La elección de Ethernet como red de transporte es una consecuencia directa del uso de OSC, y ha condicionado la mayor parte del desarrollo de este proyecto. Una vez concluido éste, puede decirse que se han alcanzado los siguientes objetivos:

• Realizar una comparativa de las tecnologías de comunicación actuales en el ámbito de la producción musical y el control multimedia.

• Estudiar la tecnología Ethernet, y especialmente su adaptación a un sistema empo‐trado genérico.

• Diseñar e implementar un sistema integrado completo basado en un microcontrola‐dor de 8 bits, incluyendo hardware y firmware.

• Profundizar en el estudio de la familia de protocolos de Internet.

• Diseñar una aplicación basada en tecnologías web modernas, aunque enfocada a un sistema muy limitado en cuanto a recursos de memoria y velocidad de proceso.

7.1 Mejoras y líneas de avanceSi atendemos a la tasa a la que se muestrean las entradas del controlador y se envían sus mensajes correspondientes, puede concluirse que el rendimiento del sistema es suficiente para la mayoría de las aplicaciones prácticas, aunque no impresionante. Esta tasa depende de la carga del microcontrolador, y por tanto de los métodos OSC activados, las transacciones HTTP, etc. La figura 7.1 muestra la frecuencia de muestreo y envío media en función de los métodos activados, y en condiciones de funcionamiento normales (es decir, sin monitorización del estado del controlador a través del servidor web).

A

143

CAPÍTULO 7: CONSIDERACIONES FINALES144

Los datos se han obtenido a partir de estadísticas de capturas realizadas con Wireshark en condiciones de red ideales (conexión directa de la placa al PC con un cable crossover). Se observa que la frecuencia oscila aproximadamente entre los 400 Hz, cuando los métodos Analog, Digital y Rotary están activados y los 700 Hz del método Digital. La activación del filtrado digital de las entradas analógicas también afecta ligeramente a esta frecuencia, aunque su efecto puede considerarse despreciable (reducción en torno al 1%).

Puede concluirse que el cuello de botella no lo constituye el controlador Ethernet ni su conexión SPI a 10 Mbps, sino el propio microcontrolador. Esta afirmación puede extenderse a cualquier otra aplicación de red que se ejecute en este hardware, y no solo al cliente OSC. Los puntos más débiles del microcontrolador empleado son los siguientes:

• Arquitectura de 8 bits. La pila de protocolos de red requiere el manejo de una gran cantidad de datos de 16 bits o más, por lo que se necesitan más instrucciones para realizar las mismas operaciones básicas.

• Segmentación de memoria en bancos. Una aplicación que emplee profusamente la RAM se beneficiaría de un procesador que permita el acceso uniforme a todo el rango de memoria.

• Ciclo de instrucción lento. La ejecución de una instrucción requiere al menos cuatro ciclos de reloj, por lo que incluso a la frecuencia máxima de 40 MHz sólo puede alcanzarse un máximo de 10 MIPS.

En cuanto al resto del hardware, las posibles mejoras dependerán de la utilidad que se le quiera dar. Una de ellas podría ser la protección del puerto de entrada y salida de propósito general del microcontrolador, por ejemplo por medio de optoacopladores. Por supuesto, la placa de controles es también mejorable, ya que la finalidad de la implementada en este proyecto es puramente ilustrativa de la funcionalidad del sistema.

650 Hz

700 Hz

Analog

500 Hz

550 Hz

600 Hz

Analog + DigitalSwitchMatrix

3 0

400 Hz

450 Hz

500 Hz

300 Hz

350 Hz

Analog + Digital + RotaryDigital + Rotary

Analog + SwitchMatrixDigital

Figura 7.1: Frecuencia de muestreo media en función de los métodos OSC activados

MEJORAS Y LÍNEAS DE AVANCE 145

Las mejoras del firmware dependerán, una vez más, de los objetivos buscados. Una de las más interesantes podría ser el transporte de los mensajes OSC sobre protocolos de voz sobre IP (por ejemplo RTP), dada la poca fiabilidad de UDP en transferencias a través de Internet, donde los datagramas pueden llegar al destino sin un orden establecido.

Por otra parte, si lo que prima es alcanzar la máxima velocidad de transferencia por encima de otras prestaciones y sin cambiar el microcontrolador, posiblemente serían prescin‐dibles algunos de los métodos OSC implementados, así como el servidor web y la mayor parte del código de la pila TCP/IP.

CAPÍTULO 7: CONSIDERACIONES FINALES146

cuarta parte:

Apéndices

Aapéndice

Esquemáticos del controlador OSC

n las siguientes páginas se muestran los diagramas electrónicos de cada una de las placas que componen el controlador diseñado.

Se han incluido, además, los fotolitos utilizados para la creación de las placas de circuito impreso (PCBs), en escala natural.

E

149

APÉNDICE A: ESQUEMÁTICOS DEL CONTROLADOR OSC150

+

+

+

ArrayEEPROM

3 2 1

PW

R_JA

CK

21XT

1

AE

S

R1

1 2 3 4

ICS

P 5 6

3 1

24

S1

31

2 4

S2

VI

1

2

VO

3

RE

G1 G

ND

D1

D2

C1

C2

C3

C5

EN

IN

GND

OU

T

NR

RE

G2

C6

R13

C17

LED1

LE

D2

1

JP2

2

1JP3

2

1JP4

2C

22

C23

C24

R15

C25

C26

R16

R17

R18

R19

C27

IC1

RC

7/R

X/D

T2

6R

D4

/PS

P4

27

RD

5/P

SP

5/P

1B

28

RD

6/P

SP

6/P

1C

29

RD

7/P

SP

7/P

1D

30

VSS12

VDD11

RB

0/IN

T0

/FL

T0

/AN

12

33

RB

1/IN

T1

/AN

10

34

RB

2/IN

T2

/AN

83

5R

B3

/AN

9/C

CP

23

6R

B4

/KB

I0/A

N1

13

7R

B5/K

BI1

/PG

M3

8R

B6/K

BI2

/PG

C3

9R

B7/K

BI3

/PG

D4

0M

CLR

\/V

PP

/RE

31

RA

0/A

N0

2

RA

1/A

N1

3

RA

2/A

N2

/VR

EF

-/C

VR

EF

4

RA

3/A

N3

/VR

EF

+5

RA

4/T

0C

KI/C

IOU

T6

RA

5/A

N4

/SS

\/H

LV

DIN

/C2

OU

T7

RE

0/R

D\/A

N5

8

RE

1/W

R\A

N6

9

RE

2/C

S\/A

N7

10

VDD32

VSS31

OS

C1/C

LK

I/R

A7

13

OS

C2/C

LK

O/R

A6

14

RC

0/T

1O

SO

/T1

3C

KI

15

RC

1/T

1O

SI/C

CP

21

6

RC

2/C

CP

1/P

1A

17

RC

3/S

CK

/SC

L1

8

RD

0/P

SP

01

9

RD

1/P

SP

12

0R

D2

/PS

P2

21

RD

3/P

SP

32

2R

C4

/SD

I/S

DA

23

RC

5/S

DO

24

RC

6/T

X/C

K2

5

C4

8 4

CS

\1

SO

2

HO

LD

\7

SC

K6

SI

5

WP

\3

VC

C

GN

D

IC5

R12

LED3

LED4

LED5

R20

R21

R22

12

34

56

78

91

01

11

2

13

14

15

16

17

18

19

20

CO

N1

C29

GN

DV

CC

RE

SE

T

RB

5

RB

2

SD

I

SD

I

SD

O

SD

O

SC

K

SC

K

RB

3R

B4

RB

4

PG

C

PG

C

PG

D

PG

D

MC

LR

MC

LR

AN

0

AN

0

AN

0

AN

1

AN

1

AN

2

AN

2

AN

3

AN

3

AN

4

AN

4

AN

5

AN

5

AN

6

AN

6

AN

7

AN

7

TX

RX

RB

1

RB

1

RB

1R

D0

RD

0

RD

1

RD

1

RD

2R

D2

RD

3

RD

3

RD

4

RD

4

RD

5

RD

5

RD

6

RD

6

RD

7

RD

7

RB

0

RB

010M

10KReset

7805T

1N

5819

1N5819

10u

47u

100n

100n

GN

DG

ND

GN

DG

ND

GN

DG

ND

GN

DG

ND

TP

S79633

100n

GN

D

10K

GN

D

100n

VCC

+3V3

Green

Yello

w

GN

D

Button

Pot

VCC

GN

D

100n

100n

100n

GN

D

VCC

470

GN

D

20p

20p

GN

D

470

GN

D

10k

GN

D

VCC

470

VCC GN

D

330

100n

GN

D

PIC

18F

4620

VCC

470u

25LC

1024P

10K

GN

D

VCC

Red

Red

Red

470

470

470

GN

D

VCC

100n

151

+

+ +

+

+

+VC

AP

1

VSS2

CL

KO

UT

3

INT

4

NC

5

SO

6

SI

7

SC

K8

CS

9

RE

SE

T1

0

VSSRX11

TP

IN-

12

TP

IN+

13

RB

IAS

14

VDDTX15

TP

OU

T-

16

TP

OU

T+

17

VSSTX18

VDDPLL20

VDDRX19

VSSPLL21

VSSOSC22

OS

C1

23

OS

C2

24

VDDOSC25

LE

DB

26

LE

DA

27

VDD28

IC2

1

23 IC

4A

4

56 IC

4B

10

98 IC

4C

13

12

11 IC

4D

714 IC4P

GNDVCC

21XT

2

J-L

J-R

1 2 3 4

J-L

AN

5 6

L1

R2

R3

R4

R5

R6

C7

C8

C9

C10

R7

R8

C11

C12

C13

C14

C15

R9

R10

R11

1 2 3JP

1

C16

C1

+1

C1

-3

C2

+4

C2

-5

T1

IN1

1

T2

IN1

0

R1

OU

T1

2

R2

OU

T9

V+

2

V-

6

T1

OU

T1

4

T2

OU

T7

R1

IN1

3

R2

IN8

IC3

16 15GNDVCC

IC3P

16

27

38

49

5

DB

9M

C18

C19

C20

C21

R14

C28

RE

SE

T

RB

5

RB

2

SD

I

SD

O

SC

K

RB

3

TX

RX

EN

C28J60-D

IL

74H

CT

125N

74H

CT

125N

74H

CT

125N

74H

CT

125N

25M

XF

AT

M9G

B

Ferr

ite B

ead

49R9 1%

49R9 1%

49R9 1%

49R9 1%

2K32 1%

10u

100n

GN

DG

ND

GN

D

20p

20p

330

330

GN

DG

ND

GN

D

100n

GN

D

GN

D

100n

100n

100n

100n G

ND

200

200

200

GN

D

GN

D

100n

GN

D

+3V3

VCC

MA

X232

1u

1u

1u

1u

GN

D10

VCC

GN

D

VCC

1u


12

S1

12

S2

12

S3

12

S4

12

S5

12

S6

12

S7

12

S8

12

S9

12

S10

12

S11

12

S12

12

S13

12

S14

12

S15

12

S16

D1

D2

D3

D4

D5

D6

D7

D8

D9

D10

D11

D12

D13

D14

D15

D16

AC

B

POT1

AC

B

POT2

AC

B

POT3

ACB

POT4

AC

B

POT5

AC

B

POT6

AC

B

POT7

AC

B

POT8

C1

C2

C3

C4

C5

C6

C7

C8

R1

R2

R3

R4

123

JP

1

123

JP

2

123

JP

3

123

JP

4

R5 R6 R7 R8

CO

M

BA

RO

TA

RY

1

2

3

JP5

1 3 5 7 9

PL1

2 4 6 8 10

11

13

15

17

19

12

14

16

18

20

AN

7

AN

7

AN

6

AN

6

AN

5

AN

5

AN

4

AN

4

AN

3

AN

3

AN

2

AN

2

AN

1

AN

1

AN

0

AN

0

RD

7

RD

7

RD

6

RD

6

RD

5

RD

5

RD

4

RD

4

RD

3

RD

3

RD

2

RD

2

RD

1

RD

1

RD

0

RD

0

VCC

GN

D

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

1N4148

4K7

4K7

4K7

4K7

4K7

4K7

4K7

4K7

100n

100n

100n

100n

100n

100n

100n

100n

GN

DG

ND

GN

DG

ND

GN

DG

ND

GN

DG

ND

VCC

VCC

VCC

VCCVCC

VCC

VCC

VCC

10K

10K

10K

10K

VCC

VCC

VCC

VCC

10K 10K 10K 10K

VCC VCC VCC VCC

GN

D

GN

D

153

Figura A.1: Fotolito de la placa principal (cara superior)

Figura A.2: Fotolito de la placa principal (cara inferior)


Figura A.3: Fotolito de la placa de controles (cara superior)

Figura A.4: Fotolito de la placa de controles (cara inferior)

Bapéndice

Construcción de un depurador hardware

a disponibilidad de herramientas de desarrollo adecuadas es esencial a la hora de conseguir los objetivos de diseño en el plazo más corto posible. Por este motivo se decidió

dedicar la primera parte del trabajo asociado a este proyecto a la implementación de un depurador hardware para la familia de microcontroladores de Microchip. Como veremos, la funcionalidad de este dispositivo justifica sobradamente el tiempo invertido en su desarrollo.

Dentro de las alternativas posibles, lo más adecuado sería un dispositivo que pudiera integrarse en el entorno de desarrollo MPLAB, agilizando el proceso de programación y depuración de errores. Cualquier hardware completamente compatible con los dispositivos comercializados por Microchip tendrá esta característica, por lo que la opción más evidente es estudiar las herramientas de desarrollo que provee el propio fabricante.

L

Figura B.1: Clasificación de las herramientas de desarrollo MPLAB

155

APÉNDICE B: CONSTRUCCIÓN DE UN DEPURADOR HARDWARE156

Como se observa en la figura B.1, una de las alternativas más completas es el ICD2. Este dispositivo hace posible no sólo la programación de la amplia mayoría de los microcontrola‐dores y DSPs de Microchip, sino además su emulación y depuración, permitiendo establecer varios puntos de interrupción en la ejecución del código y analizar las variables internas del procesador. La comunicación con el microcontrolador se realiza mientras éste está alojado en la placa final de la aplicación mediante la tecnología In‐Circuit Debug, que ya se comentó en el capítulo 4. En cuanto a la conexión con el ordenador, puede hacerse mediante puerto serie o conexión USB.

El ICD2 supone una gran ventaja con respecto a la gran variedad de dispositivos progra‐madores existentes, más simples y económicos pero mucho más limitados. A medida que la complejidad del código aumenta, el uso de un depurador es esencial, dado que reduce notablemente el ciclo de creación, modificación y reprogramación. Sin embargo, el coste de un depurador ICD2 original, aunque muy inferior al de sus hermanos mayores ICE, era lo suficientemente elevado como para plantearse su implementación.

En Internet existen una amplia variedad de proyectos enfocados a la clonación del ICD2. De todos ellos, la mayoría se diseñaron basándose en la interfaz RS232 para la comunicación con el PC. Si bien esto simplifica bastante el hardware, tiene varios inconvenientes. Por un lado, la tasa de transferencia es bastante inferior a la que puede alcanzarse con una interfaz USB de alta velocidad. Por otra parte, cada vez es más común que los ordenadores modernos no dispongan de puerto serie, especialmente los equipos portátiles. Por este motivo se decidió que sería deseable disponer de un dispositivo con interfaz USB.

Varios miembros del foro web EDABoard (www.edaboard.com) han aunado esfuerzos para conseguir una alternativa más económica al ICD2 original, aunque manteniendo sus mismas características, con especial atención a la conectividad USB. Como resultado han aparecido diversas implementaciones del depurador, algunas de las cuales pueden consultarse en el sitio web www.icd2clone.com. De entre ellas, se eligió realizar un hardware basado en la versión potyo2, con ligeras modificaciones. Esta versión, aún siendo más compleja y requi‐riendo algunos componentes más que las otras, tiene la ventaja de permitir la programación y depuración de microcontroladores con tensiones de alimentación de 3.3V e incluso menores. Por este motivo se convierte en un reemplazo totalmente funcional del ICD2 original, salvo por la ausencia del puerto serie que, en nuestro caso, es totalmente prescindible.

La figura B.2 es una representación del dispositivo implementado, que básicamente se compone de los siguientes elementos:

• Microcontrolador PIC16F877P. Este dispositivo alberga el bootloader del depurador, y ejecuta un código de depuración cargado desde el entorno de desarrollo MPLAB. Este código es específico para cada modelo de microcontrolador y normalmente se actualiza con las distintas versiones de MPLAB, de manera que se pueda emplear el ICD2 incluso con dispositivos de futura aparición.

• Microcontrolador PIC18F4550. Dispone de un puerto USB de alta velocidad, por lo que sirve de intermediario entre el PC y el PIC16F877P, controlando el funciona‐miento de este último. La comunicación entre los procesadores se realiza mediante el puerto paralelo externo del que ambos disponen

157

• Convertidor de tensión MC34063. Eleva la tensión de alimentación de 5V del puerto USB hasta la tensión de programación requerida por cada procesador (normalmente alrededor de 13V).

• Potenciómetro digital MCP41010. Permite regular digitalmente la tensión de progra‐mación.

• 74HCT125, 74HC126, 74LS07, 74HC4066. Buffers y switches estándar que proporcio‐nan la lógica de protección del circuito y la correcta comunicación del PIC16F877P con el microcontrolador de la aplicación de destino, realizando la adecuada conver‐sión de tensiones en caso de ser necesario.

El resto son componentes pasivos necesarios para el funcionamiento de los arriba mencionados. Los archivos CAD para Eagle y el firmware de ambos microcontroladores están también incluidos en el CD adjunto a la memoria del proyecto.

Figura B.2: Vista 3D del depurador compatible ICD2

APÉNDICE B: CONSTRUCCIÓN DE UN DEPURADOR HARDWARE158

Capéndice

Compilación y control de versiones

n este apéndice se esbozarán algunas opciones de configuración del entorno de desarrollo y del compilador C18 que son necesarias para la compilación correcta de las fuentes

incluidas en el CD del proyecto. También se hará una pequeña introducción a Subversion, la herramienta de control de versiones utilizada durante el desarrollo del código.

C.1 Configuración del entorno de desarrolloÚnicamente se enumerarán aquí algunas opciones que pueden diferir de las establecidas por defecto, y que es necesario comprobar antes de iniciar la compilación de las fuentes. Se asumirá que tanto el entorno de desarrollo MPLAB IDE como el compilador C18 están insta‐lados, y que el lector tiene cierta familiaridad con los mismos. Ambos pueden descargarse gratuitamente en el sitio web del fabricante (www.microchip.com). La información en este apartado corresponde a la versión 8.01 de MPLAB IDE.

Selección del microcontrolador

Puede realizarse a través del menú Configure > Select Device o en el asistente de creación de proyectos (menú Project > Project Wizard).

Selección de las herramientas de lenguaje

De nuevo a través del asistente de creación de proyectos o en el menú Project > Select Language Toolsuite. Será necesario activar el conjunto de herramientas del compilador C18 (Microchip C18 Toolsuite).

Localización de los archivos del compilador

Si se instala el compilador antes que el entorno de desarrollo MPLAB IDE, será necesario indicar a este último la ubicación por defecto de las librerías y los archivos ejecutables de C18 en el disco. Para ello debe usarse el menú Project > Set Language Tool Locations.

E

159

APÉNDICE C: COMPILACIÓN Y CONTROL DE VERSIONES160

Localización de los archivos del proyecto

También deben especificarse los directorios donde el entorno de desarrollo buscará las librerías, cabeceras y scripts de enlazador usados por el proyecto. Es importante que estos últimos sean los instalados por C18, y no los de la herramienta MPASM que se incluye con MPLAB IDE. Todos estos directorios, así como el de salida y el temporal, pueden especificarse en la pestaña Directories del menú Project > Build Options > Project.

Opciones del enlazador MPLINK

Pueden establecerse en la pestaña MPLINK Linker del mismo menú.

Figura C.1: Configuración de los archivos de C18 en MPLAB IDE

Figura C.2: Configuración de los directorios del proyecto

CONFIGURACIÓN DEL ENTORNO DE DESARROLLO 161

Conviene activar las opciones Generate map file y Suppress COD‐file generation. Con la primera, el enlazador generará en el directorio de salida un archivo de texto donde se especifica la ubicación en memoria de programa y RAM de las distintas secciones de código y datos, y de todas las variables de usuario. Este archivo es útil para determinar la causa de posibles errores de enlazado y para ubicar variables en el banco de acceso. La segunda opción hace referencia a un formato de salida antiguo que ya no es usado por MPLAB IDE, y que por tanto se puede suprimir.

Opciones del compilador

Las opciones del compilador, como el nivel de optimización o los calificadores de almacena‐miento de variables que se usan por defecto, se establecen a través de la pestaña MPLAB C18 del menú Project > Build Options > Project. Estas opciones se organizan en tres categorías: general, modelo de memoria y optimización. La siguiente figura muestra las opciones estable‐cidas en la categoría general.

La clase de almacenamiento por defecto se ha establecido en overlay, una clase no estándar definida por el compilador. Puede considerarse a esta clase como una combinación de las estándares static y auto. Como con static, las variables locales declaradas con overlay se almacenarán estáticamente (es decir, en una dirección de memoria determinada y no en una pila software) pero serán inicializadas cada vez que se invoque a su función correspondiente. Por otra parte, el compilador usará las mismas direcciones físicas para almacenar las variables overlay que pertenezcan a aquellas funciones que nunca puedan estar activas simultánea‐mente, de manera que se reduzca el consumo de memoria RAM. Al ser almacenadas estática‐mente, las variables overlay requerirán menos instrucciones para su acceso. Esta clase no es compatible con el juego de instrucciones extendido del microcontrolador.

Figura C.3: Opciones del compilador (categoría general)


Desde esta ventana también es posible realizar definiciones de macros de preprocesador, y así se ha hecho con la macro ETHEROSC (aunque también podría haberse definido directa‐mente en el código de la aplicación).

En la categoría Memory Model será necesario configurar el modelo de memoria correcto para el microcontrolador empleado. El PIC18F4620 tiene exactamente 64 KB de memoria de programa, por lo que se empleará el modelo de pequeña memoria de código, que como se sabe afecta al tamaño de los punteros a memoria ROM. También se debe indicar el uso de todos los bancos de memoria disponibles, y no sólo del banco de acceso, como se muestra en la figura C.4.

La última categoría corresponde a las opciones de optimización del compilador. En general, se debe usar la opción por defecto Debug cuando se esté depurando el código con el ICD2. Esta opción habilita todas las optimizaciones posibles, salvo las que afectan a la depuración (como el reordenamiento o la eliminación de código redundante, que pueden afectar al emplazamiento de los puntos de ruptura o breakpoints).

En la compilación del código definitivo, es deseable el uso de todas las optimizaciones posibles, salvo Procedural abstraction. Esta optimización identifica secuencias de instrucciones similares, considerándolas nuevas subrutinas y ahorrando notablemente en el uso de memoria de programa. Sin embargo, también generará un código mucho más lento. A menos que sea estrictamente necesario por motivos de espacio, se debe desactivar esta optimización, que por otra parte sólo está disponible en la versión gratuita de C18 durante un periodo de tiempo limitado.

Figura C.4: Selección del modelo de memoria

CONTROL DE VERSIONES CON SUBVERSION 163

Selección del juego de instrucciones

En la pestaña MPASM/C17/C18 Suite del mismo menú se puede seleccionar el juego de instruc‐ciones del microcontrolador. Es importante que esta selección sea consistente con los bits de configuración programados mediante la directiva #pragma config.

En este proyecto se ha comprobado que el juego extendido de instrucciones genera un código más ineficiente que el tradicional, debido a que la mayoría de las funciones de la aplicación no son reentrantes. Recuérdese además que este juego es incompatible con la clase de almacenamiento overlay.

C.2 Control de versiones con SubversionSubversion (también conocido como SVN) es una herramienta de control de versiones de código abierto y multiplataforma. Se basa en un repositorio central que actúa como un servidor de ficheros, con la capacidad de recordar todos los cambios realizados tanto en la estructura de directorios como en el contenido de los archivos. El repositorio incrementa un número global de revisión con cada conjunto de cambios enviados al mismo (mediante una operación commit). Sólo las diferencias son almacenadas en cada nueva revisión, de forma que el tamaño del repositorio no crece considerablemente.

Aunque es en grupos de trabajo descentralizados donde una herramienta como ésta cobra mayor sentido, son muchas las ventajas que supone su uso incluso con un repositorio local accedido por un solo usuario. Más allá de la creación de simples copias de seguridad, Subversion ofrece características muy útiles como la capacidad de comparar cambios entre archivos de cualquier revisión, la creación de diferentes ramas de un mismo proyecto o la facilidad de exportar el repositorio completo, generando archivos «entregables».

SVN es una herramienta de línea de comandos, aunque existen interfaces gráficas que facilitan su uso. Si se trabaja en Windows la más conocida es TortoiseSVN, un cliente gratuito y de código abierto que se integra en el explorador a través de menús contextuales. Esta es la herramienta que se ha utilizado durante todo el proceso de desarrollo del proyecto.

En la figura anterior, TortoiseSVN identifica claramente los archivos del directorio de trabajo que difieren de la última revisión disponible en el repositorio. Estas diferencias pueden observarse en la siguiente captura, relativa a uno de los archivos enumerados.

Figura C.5: Grupo de archivos en un directorio de trabajo SVN


Tanto Subversion como TortoiseSVN pueden descargarse gratuitamente en sus respec‐tivos sitios web:

• http://subversion.tigris.org/

• http://tortoisesvn.tigris.org/

Figura C.6: TortoiseSVN mostrando las diferencias entre dos archivos

Dapéndice

Ejemplos de aplicación práctica

omo pequeña muestra de las posibilidades prácticas del controlador, se enumerarán aquí algunas aplicaciones que soportan un servidor OpenSound Control. Para una lista más

completa de programas y librerías de desarrollo relacionados con OSC, puede consultarse el sitio web de la especificación en http://opensoundcontrol.org/.

Max/MSP/Jitter

Max es un entorno de desarrollo gráfico e interactivo para música y multimedia desarrollado y mantenido por Cycling ʹ74. MSP proporciona los componentes de síntesis de sonido y DSP en este entorno de desarrollo, mientras que Jitter permite la manipulación en tiempo real de video y gráficos tridimensionales.

Pure Data

Aunque MAX no es gratuito, su autor original publicó en 1996 un sustituto en muchos aspectos equivalente denominado Pd (Pure Data), de libre distribución, multiplataforma, y mantenido en la actualidad por una comunidad de desarrolladores.

El soporte de OSC en Pure Data es posible a través de objetos (externals) desarrollados por el CNMAT y disponibles en la página web indicada al comienzo del capítulo. En la figura D.1 se ejemplifica la interconexión de estos objetos. Una vez extraidos los argumentos de los mensajes OSC es posible manipularlos arbitrariamente, e incluso pueden construirse nuevos mensajes para adaptar los métodos del controlador a los definidos por cualquier otra aplicación. Puede descargarse en http://puredata.info/.

ChucK

Se trata de un lenguage de programación orientado a la síntesis, grabación y análisis de sonido en tiempo real. ChucK es un proyecto open source multiplataforma que soporta OSC de forma nativa. Para más información puede consultarse la página web del proyecto en la dirección http://chuck.cs.princeton.edu/doc/.

C

165

APÉNDICE D: EJEMPLOS DE APLICACIÓN PRÁCTICA166

Processing

Es un proyecto de software libre que consiste en un lenguaje de programación y un entorno de desarrollo enfocado en la creación de animaciones para espectáculos. Se basa en las capaci‐dades gráficas de Java, siendo su sintaxis muy similar.

El soporte para OSC se consigue a través de la librería externa oscP5, disponible en http://www.sojamo.de/libraries/oscP5/. La web del proyecto es http://processing.org/.

Figura D.1: Ejemplo de parche en Pure Data

Figura D.2: Aspecto del IDE de Processing

Eapéndice

Fotografías

e incluyen en este apéndice las fotografías de las placas construidas y su interconexión.S

Figura E.1: Fotografía de la placa principal

167

APÉNDICE E: FOTOGRAFÍAS168

Figura E.2: Fotografía de la placa de controles

Figura E.3: Fotografía del depurador compatible ICD2

169

Figura E.4: Fotografía del controlador en funcionamiento

Figura E.5: Fotografía del montaje completo (proceso de desarrollo)

APÉNDICE E: FOTOGRAFÍAS170

Bibliografía

[AslesonR] Asleson, R.; Schutta, N. T.

Foundations of Ajax

2006, Apress

[BentJ] Bentham, J.

TCP/IP Lean: Web Servers for Embedded Systems

2002, CMP Books

[CIS00] Cisco Systems, et. al.

Internetworking Technologies Handbook, capítulo 7

2000, Cisco Systems Inc.

[C18GS] MPLAB® C18 C Compiler Getting Started (DS51295F)

2005, Microchip Technology Inc.

[C18LB] MPLAB® C18 C Compiler Libraries (DS51297F)


[C18UG] MPLAB® C18 C Compiler User’s Guide (DS51288J)


[ENC06] ENC28J60 Data Sheet (DS39662B)


171

CAPÍTULO F: BIBLIOGRAFÍA172

[GarrettJJ] Garrett, J. J.

Ajax: A New Approach to Web Applications

http://www.adaptivepath.com/ideas/essays/archives/000385.php

[GettysJ] Gettys, J.

Overview of new HTTP/1.1 functionality and changes from HTTP/1.0

http://www.w3.org/Protocols/

[ICSP] In-Circuit Serial Programming™ Guide (DS30277D)


[IRC78] Mathews, M. V.; Bennett G.

Real-time synthesizer control

Technical report, 5/78, Ircam Centre Pompidou. 1978.

[JohnM] Johnson, M.

XML for the absolute beginner

http://www.javaworld.com/javaworld/jw-04-1999/jw-04-xml.html

[MICRa] Rajbharti, N.

Application Note AN833: The Microchip TCP/IP Stack


[MICSi] Simmons, M.

Application Note AN1120: Ethernet Theory of Operation


[MIDI] MIDI Manufacturers Association, 2008

MIDI Specifications

http://www.midi.org

[NIME03] Wright, M.; Freed, A.; Momeni, A.

OpenSound Control: State of the Art 2003

Proceedings of the 2003 Conference on New Interfaces for Musical Expression (NIME-03), Montreal, Canada

[OSC02] Wrigth, M.

The OpenSound Control 1.0 Specification, March 2002

http://opensoundcontrol.org/spec-1_0

173

[OSC07] Freed, A.; Schmeder, A.; Zbyszynski, M.

OpenSoundControl: A flexible protocol for sensor networking

Maker Faire 2007 Conference, San Mateo, CA, USA

[OSC08] Center For New Music and Audio Technology (CNMAT), UC Berkeley, 2008

Introduction to OSC

http://opensoundcontrol.org/introduction-osc

[PICA4] PIC18F2525/2620/4525/4620 Rev. A4 Silicon Errata (DS80224D)


[PICCS] PIC18 Configuration Settings Addendum (DS51537D)


[PIC07] PIC18F2525/2620/4525/4620 Data Sheet (DS39626D)


[RFC2616] Fielding, R. et al

Hypertext Transfer Protocol - HTTP/1.1, Request For Comments 2616

http://www.ietf.org/rfc/rfc2616.txt

[SteWR] Stevens, W. R.

TCP/IP Illustrated, Volume 1: The protocols

1994, Addison-Wesley Professional

[WAN01] Wanderley, M. M.

Performer-Instrument Interaction: Applications to Gestural Control of Sound Synthesis

Université Pierre et Marie Curie, Paris. 2001.

[W3FDS] HTML 4.01 Specification: forms in HTML documents

http://www.w3.org/TR/html401/interact/forms.html#form-data-set

[W3XHR] The XMLHttpRequest Object

http://www.w3.org/TR/XMLHttpRequest/

[W3XHTML] XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)

http://www.w3.org/TR/2002/REC-xhtml1-20020801

CAPÍTULO F: BIBLIOGRAFÍA174

[W3XML] Extensible Markup Language (XML) 1.0 (Fourth Edition)

http://www.w3.org/TR/2006/REC-xml-20060816/

Control en Tiempo Real de Aplicaciones Multimedia...

Documents

Transcript of Control en Tiempo Real de Aplicaciones Multimedia...