Plataforma de experimentación para prototipado de diseños

Transcripción

TRABAJO FIN DE ESTUDIOS
PROYECTO FIN DE CARRERA
Plataforma de experimentación para prototipado de
diseños mediante Arduino
Santiago Reig Chiva
Tutor: Carlos Alberto Rodríguez González
Curso 2011-2012
Plataforma de experimentación para prototipado de diseños mediante
Arduino, trabajo fin de estudios
de Santiago Reig Chiva, dirigido por Carlos Alberto Rodríguez González (publicado por la
Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
©
©
El autor
Universidad de La Rioja, Servicio de Publicaciones, 2012
publicaciones.unirioja.es
E-mail: [email protected]
“PLATAFORMA DE EXPERIMENTACIÓN PARA
PROTOTIPADO DE DISEÑOS MEDIANTE ARDUINO”
Peticionario:
Universidad de La Rioja
Área de proyectos de ingeniería
Informante:
Santiago Reig Chiva
Alumno de I.T.I. Electrónica Industrial
Universidad de La Rioja
Director:
Carlos Alberto Rodríguez González
Departamento de Ingeniería Eléctrica
Lugar y fecha:
Logroño, 20 de julio de 2012
Plataforma de experimentación para prototipado de diseños mediante Arduino
Santiago Reig Chiva
Índice
Índice
Memoria ............................................................................................. 3
Anexos ..............................................................................................85
Pliego de condiciones ............................................................... 166
Planos ............................................................................................ 183
Presupuesto ................................................................................. 185
Bibliografía .................................................................................. 195
Página 2
MEMORIA
DOCUMENTO Nº 1
Santiago Reig Chiva
Memoria
Índice de la memoria
1.
Antecedentes............................................................................................ 13
2.
Objetivo del proyecto ............................................................................... 14
3.
Definiciones .............................................................................................. 17
4.
Introducción ............................................................................................. 19
4.1.
El polímetro .............................................................................................. 19
4.2.
Osciloscopio .............................................................................................. 20
4.3.
Analizador lógico ...................................................................................... 21
4.4.
Actualidad ................................................................................................. 22
5.
Estudios previos al diseño ........................................................................ 23
5.1.
Estudio de ArduLab................................................................................... 23
5.2.
Estudio de Bus Pirate ................................................................................ 25
5.3.
Estudio de Little Wire ............................................................................... 28
6.
Análisis de soluciones ............................................................................... 30
6.1.
Comparativa de soluciones para la placa de interfaz ............................... 31
6.1.1.
Análisis de la plataforma Atmel AVR................................................. 32
6.1.1.1. Análisis de Arduino ...................................................................... 32
6.1.2.
Análisis de la plataforma Microchip PIC............................................ 33
Página 4
Santiago Reig Chiva
Memoria
6.1.2.1. Análisis de Pingüino ..................................................................... 33
6.1.2.2. Análisis chipKIT ............................................................................ 34
6.1.3.
Análisis de la plataforma ARM .......................................................... 35
6.1.3.1. Análisis de ST Micro ..................................................................... 36
6.1.3.2. Análisis de NXP ............................................................................ 37
6.1.4.
Análisis de la plataforma de Texas Instruments MSP430 ................. 38
6.1.4.1. Análisis de Launchpad ................................................................. 38
6.2.
Comparativa de soluciones para el medio de comunicación ................... 40
6.2.1.
Análisis del puerto paralelo............................................................... 40
6.2.2.
Análisis del puerto serie .................................................................... 41
6.2.3.
Análisis del USB ................................................................................. 42
6.2.4.
Análisis del Bluetooth........................................................................ 42
6.2.5.
Análisis del XBee................................................................................ 43
6.2.6.
Otras soluciones ................................................................................ 44
6.3.
Comparativa de soluciones para el protocolo de comunicaciones .......... 45
6.3.1.
Análisis de Firmata ............................................................................ 45
6.3.2.
Análisis del protocolo de ArduLab .................................................... 47
6.3.3.
Análisis para la creación de un protocolo propio ............................. 47
6.4.
Comparativa de soluciones para el lenguaje de programación ............... 48
Página 5
Santiago Reig Chiva
Memoria
6.4.1.
Análisis de Java .................................................................................. 48
6.4.2.
Análisis de Qt ..................................................................................... 49
6.4.3.
Análisis de Python ............................................................................. 50
7.
Descripción de la solución adoptada ........................................................ 52
7.1.
Descripción de la placa de interfaz adoptada .......................................... 52
7.2.
Descripción del medio de comunicación adoptado ................................. 52
7.3.
Descripción del protocolo de comunicación adoptado ........................... 53
7.4.
Descripción del lenguaje adoptado .......................................................... 53
8.
Desarrollo ................................................................................................. 55
8.1.
Diseño general .......................................................................................... 55
8.2.
Análisis del protocolo Firmata .................................................................. 56
8.2.1.
Introducción ...................................................................................... 56
8.2.2.
Descripción del protocolo ................................................................. 57
8.2.2.1. Mensajes ...................................................................................... 57
8.2.3.
Descripción de la comunicación ........................................................ 58
8.2.4.
Mejoras en la implementación del protocolo ................................... 60
8.2.5.
Descripción de la capa física.............................................................. 61
8.2.6.
Descripción de los conectores........................................................... 61
8.2.7.
Descripción del cableado .................................................................. 63
Página 6
Santiago Reig Chiva
8.2.8.
8.3.
Memoria
Distancias y terminaciones................................................................ 63
Análisis de la aplicación software ............................................................. 64
8.3.1.
Introducción ...................................................................................... 64
8.3.2.
Entorno de trabajo utilizado para el desarrollo ................................ 66
8.3.3.
Descripción del código fuente........................................................... 67
8.3.3.1. Inicialización de los módulos ....................................................... 67
8.3.3.2. Selección del puerto serie ........................................................... 69
8.3.3.3. Programación del Arduino ........................................................... 70
8.3.3.4. Comunicación con Firmata .......................................................... 71
8.4.
Análisis de la placa de interfaz ................................................................. 74
8.4.1.
Introducción ...................................................................................... 74
8.4.2.
Características principales ................................................................. 76
8.4.3.
Formas de alimentación eléctrica ..................................................... 77
8.4.4.
Análisis de la memoria ...................................................................... 78
8.4.5.
Análisis de las entradas y salidas....................................................... 78
8.4.6.
Análisis de la Interfaz USB-Serie........................................................ 79
8.4.6.1. Chip FTDI ...................................................................................... 80
8.4.6.2. Chip Atmel ................................................................................... 80
8.4.6.3. Sin chip......................................................................................... 81
Página 7
Santiago Reig Chiva
Memoria
8.4.7.
Análisis de los métodos de programación ........................................ 82
8.4.8.
Análisis del entorno de trabajo ......................................................... 82
Página 8
Santiago Reig Chiva
Memoria
Índice de ilustraciones
Ilustración 1 | Polímetro analógico .................................................................... 20
Ilustración 2 | Polímetro digital .......................................................................... 20
Ilustración 3 | Osciloscopio analógico ................................................................ 21
Ilustración 4 | Osciloscopio digital ..................................................................... 21
Ilustración 5 | Analizador lógico ......................................................................... 21
Ilustración 6 | Captura de ArduLab .................................................................... 24
Ilustración 7 | Bus Pirate v3.6............................................................................. 26
Ilustración 8 | Usando el Bus Pirate con Putty ................................................... 28
Ilustración 9 | Little Wire .................................................................................... 29
Ilustración 10 | Arduino UNO ............................................................................. 33
Ilustración 11 | Placa Pingüino ........................................................................... 34
Ilustración 12 | chipKIT Uno32 ........................................................................... 35
Ilustración 13 | STM32 Discovery ....................................................................... 37
Ilustración 14 | LPCXPRESSO con ARM Cortex-M0 ............................................ 38
Ilustración 15 | TI Launchpad ............................................................................. 39
Ilustración 16 | Módulo Bluetooth ..................................................................... 42
Ilustración 17 | XBee Serie 1 .............................................................................. 43
Página 9
Santiago Reig Chiva
Memoria
Ilustración 18 | Diagrama de conexiones ........................................................... 56
Ilustración 19 | Conectores USB ......................................................................... 62
Ilustración 20 | Líneas de datos.......................................................................... 63
Ilustración 21 | Cable USB A-B............................................................................ 63
Ilustración 22 | Proyecto ejecutado en Windows 7 ........................................... 64
Ilustración 23 | Proyecto ejecutado en Linux Ubuntu 12.04 ............................. 65
Ilustración 24 | Proyecto ejecutado en Mac OS X Lion ...................................... 65
Ilustración 25 | Eric IDE ...................................................................................... 66
Ilustración 26 | Logo Arduino ............................................................................. 74
Ilustración 27 | Arduino UNO R2 ........................................................................ 75
Ilustración 28 | ATmega328P ............................................................................. 76
Ilustración 29 | Interfaz USB-Serie ..................................................................... 79
Ilustración 30 | Arduino Duemilanove ............................................................... 80
Ilustración 31 | Arduino UNO ............................................................................. 81
Ilustración 32 | Arduino Leonardo ..................................................................... 81
Ilustración 33 | Software Arduino en Windows 7 .............................................. 83
Ilustración 34 | Botones de verificación y carga ................................................ 83
Página 10
Santiago Reig Chiva
Memoria
Índice de tablas
Tabla 1 | Análisis Arduino UNO ......................................................................... 33
Tabla 2 | Análisis de Pingüino ............................................................................. 34
Tabla 3 | Análisis chipKIT .................................................................................... 35
Tabla 4 | Análisis de ST Micro ............................................................................. 37
Tabla 5 | Análisis de NXP .................................................................................... 38
Tabla 6 | Análisis de Launchpad ......................................................................... 39
Tabla 7 | Análisis del puerto paralelo ................................................................. 41
Tabla 8 | Análisis del puerto serie ...................................................................... 41
Tabla 9 | Análisis del USB ................................................................................... 42
Tabla 10 | Análisis del Bluetooth ........................................................................ 43
Tabla 11 | Análisis del XBee ................................................................................ 44
Tabla 12 | Análisis de Firmata ............................................................................ 46
Tabla 13 | Análisis del protocolo de ArduLab .................................................... 47
Tabla 14 | Análisis de protocolo propio ............................................................. 48
Tabla 15 | Análisis de Java .................................................................................. 49
Tabla 16 | Análisis de Qt ..................................................................................... 50
Tabla 17 | Análisis de Python ............................................................................. 51
Página 11
Santiago Reig Chiva
Memoria
Tabla 18 | Comparación mensajes MIDI y Firmata ............................................ 58
Tabla 19 | Características del Arduino UNO ....................................................... 76
Página 12
Santiago Reig Chiva
Memoria
1. Antecedentes
El presente proyecto, titulado “Plataforma de experimentación para
prototipado de diseños mediante Arduino”, surge de las conversaciones mantenidas
entre D. Eduardo Gallego, principal desarrollador de ArduLab y orientador del aula de
robótica del C.P. Miguel Hernández de Madrid; D. Carlos Alberto Rodríguez González,
profesor perteneciente al departamento de Ingeniería Eléctrica de la Universidad de La
Rioja y D. Santiago Reig Chiva, alumno de Ingeniería Técnica Industrial especialidad en
Electrónica Industrial de la Universidad de La Rioja, con motivo de la realización del
proyecto final de carrera de dicho alumno.
El nombre en clave utilizado para el proyecto es Platex, por lo que en las
ocasiones en las que aparezca esta palabra, se referirá al proyecto en si.
Este documento es el resultado de la elaboración del proyecto y se presenta a
efectos de reconocimiento académico para la obtención del título de Ingeniero Técnico
Industrial especialidad en Electrónica Industrial.
Página 13
Santiago Reig Chiva
Memoria
2. Objetivo del proyecto
El objetivo de este proyecto es el desarrollo de una solución formada por
aplicación multiplataforma, garantizando su funcionamiento en Windows, Linux y Mac
OS, con la que poder manejar la información desde y hacia la placa de interfaz; un
protocolo de comunicación y una placa de interfaz con el mundo físico.
Hace dos años apareció ArduLab, un software que combinado con una placa
Arduino permitía controlar manualmente los periféricos del chip integrado en la placa
Arduino, por lo que facilitaba las tareas de prototipado al poder cambiar los valores
lógicos en los pines, leer dichos valores o tensiones de forma analógica, sacar ondas
PWM y todo esto sin tener que cambiar cables ni programar una línea de código por
parte del usuario. El problema de este programa es que es de código cerrado y
programado sobre LabView, por lo que depende también depende de las librerías
cerradas de éste. La idea inicial fue la de que el programa llegara a la mayor cantidad
de personas, pero para ello se necesitaba soporte para Windows, Linux y Mac, y
aunque LabView en las especificaciones proveía ese soporte, a la hora de la realidad no
se podía preparar el compilar el programa para los sistemas operativos Linux y Mac,
quedando sólo disponible la versión de Windows. Las actualizaciones de las librerías
han ido arreglando problemas existentes en el pasado, pero llegan muy lentamente y
no solucionan el problema de forma completa, por lo que no es viable la dependencia
que existe sobre éste paquete de software.
El proyecto surge como respuesta a estos problemas, crear un programa similar
en funcionamiento para solucionar este problema de dependencia, por lo que se vio la
necesidad evidente de crear un framework desde cero, implementando desde el
comienzo el soporte multiplataforma, a partir del cual ir incorporando tanto módulos
similares a los ya existentes como otros nuevos. También era requisito indispensable
que fuera de código abierto, para permitir que cualquier persona pudiera modificar,
adaptar o añadir los cambios que crea necesarios sin tener que depender del
desarrollador principal en caso de que se tengan los conocimientos necesarios para
ello.
Las características
especificaciones:
del
framework
deberán
cumplir
las
siguientes
Página 14
Santiago Reig Chiva
Memoria

Placa de interfaz con el mundo físico accesible a todo el mundo y de bajo
coste.

Los periféricos de la placa de interfaz deben incluir al menos los siguientes:
entradas y salidas digitales, entradas analógicas, salidas de PWM y USART
para la comunicación con el ordenador.

Fácil montaje de la placa de interfaz de manera casera y con componentes
comunes.

Protocolo de comunicaciones simple pero estable.

Programa de la interfaz de usuario en el ordenador intuitiva.

Fácil inclusión de nuevos módulos al programa.

Todas las partes estén bajo licencias libres y sean de código abierto.

Multiplataforma: Windows, Linux, Mac OS.
Por todo ello se consideran importantes las siguientes tareas:

Estudio del estado del arte sobre sistemas de prototipado similares ya
existentes.

Aprendizaje y uso del entorno de desarrollo integrado Eric, así como del
lenguaje de programación Python.

Análisis del protocolo de comunicaciones Firmata.

Aprendizaje y uso tanto entorno de desarrollo integrado Arduino como su
ecosistema y los lenguajes de programación C y C++.

Estudio de la plataforma y programación de los AVR de Atmel.
Página 15
Santiago Reig Chiva
Memoria
Página 16
Santiago Reig Chiva
Memoria
3. Definiciones
El vocabulario técnico utilizado a lo largo de este documento es definido para
su correcta comprensión:

Microcontrolador: es un circuito integrado programable, capaz de ejecutar
órdenes grabadas en su memoria. Está formado por la unidad central de
procesamiento, memoria y periféricos de entrada y salida.

Framework: es un conjunto estandarizado de conceptos, prácticas y
criterios para enfocar un tipo de problemática particular, que sirve como
referencia para enfrentar y resolver nuevos problemas de índole similar.

Bit: es la unidad mínima de información empleada en informática, capaz de
representar dos estados, verdadero o falso, activado o desactivado.

Byte: unidad de información formada por 8 bits.

Core: (núcleo) parte principal de los microcontroladores y
microprocesadores que se encarga de todo el procesamiento. Está formado
por los registros, la unidad de control, la unidad aritmético lógica y los
buses.

Compilador: programa informático que traduce el código fuente escrito en
un lenguaje de programación a otro lenguaje de programación de menor
nivel, generando un programa equivalente que la máquina sea capaz de
interpretar. Normalmente al lenguaje al que se compila suele ser a lenguaje
máquina.

Toolchain: (cadena de herramientas) conjunto de herramientas de
compilación y enlazado, necesarias para transformar el código fuente en un
programa ejecutable compatible con la plataforma con la que se desarrolla.
Página 17
Santiago Reig Chiva
Memoria

DIP: empaquetado en el que se pueden fabricar los chips, consistente en
dos filas paralelas de pines distribuidas a lo largo del empaquetado y con
una separación de 0,1 pulgadas entre ellos.

Shield: en el mundo relacionado con Arduino, se refiere a la placa que se
conecta encima de éste para ampliar sus capacidades tanto de
procesamiento, como de control o interfaz.

Bootloader: porción de código almacenado en una zona especial de la flash
del microcontrolador que le permite ejecutarse en cada inicio.
Normalmente es utilizado para poder programar el microcontrolador a
través del puerto serie en vez de con un programador especializado.
Página 18
Santiago Reig Chiva
Memoria
4. Íntroduccion
Las herramientas para prototipado han ido apareciendo en el tiempo según se
iba aumentado el conocimiento existente sobre la física, especialmente en los campos
de la electricidad y magnetismo. Estas herramientas son vitales tanto para el desarrollo
de nuevas aplicaciones como para la reparación y revisión del funcionamiento de las ya
existentes.
Las herramientas más importantes y versátiles para análisis en la historia han
sido el voltímetro, procedente del desarrollo de los galvanómetros y el osciloscopio.
La tecnología ha ido mejorando a lo largo de los años y esto ha permitido crear
analizadores para magnitudes físicas que no se podían verificar con exactitud o hacerlo
de una manera más barata, sencilla o cómoda.
El analizador lógico apareció como el sustituto de los osciloscopios para el
análisis de circuitos digitales, que permitía tener un gran número de entradas en
comparación con el primero.
4.1. El polímetro
El polímetro es un instrumento eléctrico portátil para medir directamente
magnitudes eléctricas como pudieran ser tensiones, corrientes o pasivas como
resistencias, continuidad y otras. Las medidas pueden realizarse para corriente
continua o alterna.
Los modelos más avanzados pueden incluir mediciones más avanzadas tales
como temperatura, normalmente con el uso de termopares, capacidades,
inductancias, etc.
Página 19
Santiago Reig Chiva
Ilustración 1 | Polímetro analógico
Memoria
Ilustración 2 | Polímetro digital
Los polímetros han sido tradicionalmente analógicos, basados en la tecnología
del galvanómetro, aunque en las últimas décadas ha desaparecido totalmente del
mercado en favor de los modelos digitales.
4.2. Osciloscopio
Un osciloscopio es un instrumento de medición electrónico para la
representación gráfica de señales eléctricas que pueden variar en el tiempo. Dada su
gran versatilidad, se utiliza con asiduidad en electrónica y telecomunicaciones.
Están clasificados según su funcionamiento interno en analógicos o digitales,
siendo el resultado mostrado prácticamente iguales, teniendo cada uno sus ventajas y
desventajas, aunque la tendencia actual es la de adoptar la digital, ya que suelen
incorporar una mayor cantidad de características comparados con sus similares
analógicos.
Página 20
Santiago Reig Chiva
Memoria
Ilustración 3 | Osciloscopio analógico
Ilustración 4 | Osciloscopio digital
4.3. Analizador lógico
Es un instrumento de medida que captura los datos de un circuito digital y los
muestra para su análisis, de un modo similar a un osciloscopio, como un diagrama de
tiempos. Pero también existen otras representaciones que pueden ser de más utilidad
como decodificación de un protocolo que se esté usando, lenguaje ensamblador o
relacionar el código ensamblador con el código fuente.
Un analizador lógico, al igual que el osciloscopio, inicia la captura cuando en el
circuito a analizar se da una determinada condición lógica (entre todos los canales). En
ese momento se realiza una gran captura de datos del sistema que se está observando,
para más tarde poder observarlos.
Ilustración 5 | Analizador lógico
Página 21
Santiago Reig Chiva
Memoria
Estos analizadores pueden existir como dispositivos independientes, con sus
controles, pantallas y demás hardware necesario; como basados en PC, normalmente
conectados a través de USB o Ethernet y mostrando los datos en el software del
ordenador, por lo que son más baratos al sólo necesitar el hardware de captura; o
como está empezando a aparecer, integrados en osciloscopio digitales de alto
rendimiento, teniendo ambos dispositivos en uno solo.
4.4. Actualidad
Actualmente se utilizan todas las herramientas mencionadas anteriormente y la
práctica totalidad de ellas en las versiones digitales o electrónicas, que poseen una
funcionalidad mucho mayor a la de sus homólogos analógicos, aunque cuenta con las
limitaciones de la propia conversión de analógico a digital y al revés, como pueden ser,
velocidad, resolución, etc.
Página 22
Santiago Reig Chiva
Memoria
5. Estudios previos al diseno
Para definir las características del proyecto final, se han realizado estudios
previos de las soluciones ya existentes para poder mejorarlas.
5.1. Estudio de ArduLab
La única solución similar existente hasta la fecha, ha sido el paquete de
software ArduLab, también en combinación con una placa Arduino.
ArduLab ha sido desarrollado por la asociación de robótica educativa
Complubot, localizada en el C.P. Miguel Hernández de la ciudad de Alcalá de Henares
en la comunidad autónoma de Madrid. Se puede descargar sin limitaciones desde la
página del grupo.
ArduLab es un software similar, salvando las distancias, al realizado en éste
proyecto. Permite interactuar con una placa Arduino para crear un laboratorio virtual y
de esta manera, realizar actividades y experimentos.
Es un programa realizado en LabView, por lo que es necesaria la adquisición de
una licencia de éste para poder realizar su distribución, también se depende completa
y únicamente de la empresa desarrolladora para solucionar los fallos existentes en las
librerías y procesos.
Página 23
Santiago Reig Chiva
Memoria
Ilustración 6 | Captura de ArduLab
Pretendía ser un programa gratuito multiplataforma y se consiguió el primer
objetivo, pero el segundo no fue todavía terminado, ya sea por fallos en las librerías
que no permitían que el software funcionara como debiera o en los procesos de
compilación, por lo que no se podía conseguir siquiera el paquete para distribuir.
El programa está distribuido bajo una licencia freeware, es decir, se puede
descargar el programa de forma gratuita y con acceso a toda su funcionalidad de
forma ilimitada. El código fuente del Arduino fue liberado (aunque sin especificar bajo
que licencia) y está disponible a cualquiera que se baje su paquete de software,
mientras que el del propio software nunca ha sido liberado para que la comunidad
pudiera solucionar posibles fallos existentes o se facilitara la conversión del software a
una plataforma que permita sin licencias que restrinjan su desarrollo o distribución y
garanticen en mayor medida la compatibilidad multiplataforma, tal y como se
pretende en el proyecto de que trata este documento.
Página 24
Santiago Reig Chiva
Memoria
La transmisión entre la placa Arduino y el software se realiza a través del puerto
serie virtual sobre el protocolo USB y se utiliza un protocolo de comunicación de
creación propia, que es simple y eficaz, aunque de limitada escalabilidad, no muy
optimizado y difícil de rescribir para ser utilizado por otras vías de comunicación como
podría ser Ethernet.
5.2. Estudio de Bus Pirate
Bus Pirate es una herramienta que comparte la misma filosofía que este
proyecto, descubrir el funcionamiento de un dispositivo sin tener que llegar a
programar una sola línea de código.
Fue creada por Ian Lesnet mientras era escritor en el blog de noticias de
electrónica Hackaday, que debido al éxito del proyecto creó la empresa Dangerous
Prototypes, la cual se ocupa del actual desarrollo de éste proyecto entre otros tantos
que han ido apareciendo. La evolución del proyecto no es realizada sólo por Ian, si no
que al tratarse de un proyecto de software y hardware libre, mucha gente colabora
con su tiempo y código para la mejora de la herramienta en beneficio de toda la
comunidad de usuarios.
El hardware de Bus Pirate es un diseño propio basado en la familia de
microcontroladores PIC, utilizando un chip de la empresa FTDI para realizar la
conversión de serie a USB y poder conectarlo al PC de una manera sencilla una vez los
drivers estén instalados correctamente. En futuras revisiones se va a eliminar este chip
conversor e implementar el stack USB dentro del propio PIC, gracias a unas librerías
USB que se han desarrollado recientemente y de software libre, que permiten la
distribución libre del código fuente del proyecto, al contrario de lo que ocurría con las
librerías propietarias de Microchip.
Página 25
Santiago Reig Chiva
Memoria
Ilustración 7 | Bus Pirate v3.6
BusPirate está más orientado a desarrolladores, ya que sus funcionalidades son
las siguientes:

Interfaz con buses de comunicación
o 1-Wire
o I2C
o SPI
o Serie
o JTAG
o MIDI
o Teclados de PC
o Y más

Programar microcontroladores
o PIC
Página 26
Santiago Reig Chiva
Memoria
o AVR

Herramienta de depuración de chips ARM

Programador de CPLDs

Flasheador de ROMs serie

Medidor de frecuencia y generador de onda cuadrada

Analizador lógico de bajo coste

Medidor de voltaje

Otras muchas
Como se podrá apreciar más adelante, comparte muchas funcionalidades con el
proyecto del que trata este documento, pero el proyecto Bus Pirate está orientado
más hacia el desarrollador, ya que la interfaz se realiza a través de una consola a través
del puerto serie, aunque recientemente han ido saliendo interfaces de usuario que
realizan la comunicación con el Bus Pirate y facilitan el uso de éste.
Página 27
Santiago Reig Chiva
Memoria
Ilustración 8 | Usando el Bus Pirate con Putty
5.3. Estudio de Little Wire
Little Wire es un proyecto basado en el programador de microcontroladores
AVR vusbtiny, al que se le añadieron características extras, quedando su funcionalidad
en:

Programación de microcontroladores Atmel AVR

Control de pines digitales

Control de pines con PWM

Manejo de servos

Control del módulo I2C

Control del módulo SPI
Página 28
Santiago Reig Chiva

Memoria
Control del módulo UART
Como se puede ver, es muy similar al Bus Pirate en cuanto a funcionalidad,
pero su principal diferencia es que la comunicación se realiza a través del protocolo
USB puro, sin emulación de puerto serie u otras técnicas, y junto con el proyecto se
desarrollaron librerías con una API basadas en la librería multiplataforma de
comunicación por USB LibUSB. Estas librerías fueron realizadas en varios lenguajes de
comunicación tales como C, C++, C#, etc. por lo que le permite a una gran masa de
desarrolladores utilizar dicha placa sin mayores complicaciones.
Ilustración 9 | Little Wire
Página 29
Santiago Reig Chiva
Memoria
6. Analisis de soluciones
La solución ideal será una combinación de placa de interfaz, protocolo de
comunicaciones y software que congenien de forma que permita realizar el proyecto
sin una gran inversión de tiempo.
Al ser un proyecto de software libre, podremos utilizar el trabajo pasado y
actual de la comunidad de software libre sobre el que construir nuestro proyecto.
Página 30
Santiago Reig Chiva
Memoria
6.1. Comparativa de soluciones para la placa de
interfaz
Para realizar la interacción entre el software y el mundo físico, lo más sencillo
es utilizar una placa con un microcontrolador con una cantidad aceptable de pines
disponibles para nuestro uso, salidas de PWM, temporizadores y entradas analógicas,
con lo que poder tener un gran abanico de posibilidades de uso.
Las características que deberán reunir estos componentes para ser objetos del
estudio, serán las siguientes:

Alta disponibilidad en los distribuidores de componentes electrónicos más
conocidos y presentes alrededor del mundo.

Larga vida útil, es decir, que no estén en proceso de ser descatalogados en
corto plazo, para evitar tener que rescribir o portar el código de la parte de
hardware a otra plataforma.

Precio reducido, incluso en bajas cantidades, con una alta relación
funcionalidad/precio.

Baja cantidad de electrónica adicional necesaria para el funcionamiento del
microcontrolador, así como su precio, facilitando de esta manera poder se
replicada de forma a partir de los planos de la placa recomendada. Esto
facilita el acceso al proyecto en lugares y países en los que el acceso a la
electrónica está muy limitado.

Existencia de placas de desarrollo basadas en el microcontrolador
analizado, que permitan ser utilizadas junto al proyecto sin realizar grandes
modificaciones. De esta manera se facilita el acceso al hardware por parte
de los usuarios finales, ya que no se dependerá de una placa propia
exclusiva para el proyecto y probablemente tengan mejores precios al estar
algunas de ellas subvencionadas en parte por los fabricantes. Se valorará su
alta disponibilidad, precio y diseño abierto.
Página 31
Santiago Reig Chiva
Memoria
6.1.1. Análisis de la plataforma Atmel AVR
La arquitectura AVR, perteneciente a Atmel, es de 8 bits y fue diseñado desde
el comienzo para una eficiente ejecución de código C compilado.
Esta arquitectura ha sufrido un aumento importante en popularidad y
desarrollos durante estos últimos años debido al lanzamiento de la plataforma
Arduino, que ha logrado una popularidad sin precedentes. Como consecuencia de
esto, existen una gran cantidad de documentación, ejemplos de código y comunidad
de usuarios.
6.1.1.1. Análisis de Arduino
Arduino es un conjunto de librerías que facilitan en gran medida el desarrollo
en la plataforma AVR, que aunque no muy extensamente documentadas debido a su
simpleza y facilidad de uso, existen innumerables proyectos realizados por sus
usuarios.
Arduino también es una sencilla placa de desarrollo, que está actualmente muy
extendida y puede encontrarse en prácticamente cualquier distribuidor de electrónica
del mundo, a un precio que ronda los 18 a 26 euros según modelo y distribuidor y
cuenta además con un diseño libre. La sencillez de esta placa también es uno de sus
puntos fuertes, ya que permite replicar de forma artesanal la placa con componentes
disponibles en las tiendas de electrónica.
Página 32
Santiago Reig Chiva
Memoria
Ilustración 10 | Arduino UNO
Una de las ventajas, y la razón por la que Arduino eligió la plataforma AVR, es la
existencia del compilador libre basado en GCC denominado avr-gcc.
Tabla 1 | Análisis Arduino UNO
Ventajas
 Toolchain libre y gratuito
 Gran comunidad de usuarios
 Cantidad de documentación y ejemplos
Desventajas
 Precio
6.1.2. Análisis de la plataforma Microchip PIC
Microchip con su familia de microcontroladores PIC ha estado durante años
liderando el mercado del desarrollo de proyectos personales gracias al programa de
muestras de Microchip. Sus compiladores y librerías, aunque gratuitos o con límite de
compilación poseen licencias con cláusulas que dificultan la distribución del código
fuente en según que casos.
6.1.2.1. Análisis de Pingüino
Dado que Arduino está basado en la arquitectura AVR, un grupo de
desarrolladores se propuso portar las librerías a la arquitectura del PIC, de donde nació
el proyecto Pingüino. Aunque funcionales, dichas librerías no están totalmente a la
par, ni tan desarrolladas y probadas como las de Arduino. La plataforma consiguió una
sólida base de usuarios debido al programa de muestras de Microchip, ya que con
unos pocos componentes de bajo precio y fácil adquisición era posible montarse una
placa compatible.
Página 33
Santiago Reig Chiva
Memoria
Ilustración 11 | Placa Pingüino
Tabla 2 | Análisis de Pingüino
Ventajas
 Toolchain gratuito
Desventajas
 Toolchain no libre
 Librerías poco desarrolladas
6.1.2.2. Análisis chipKIT
chipKit apareció más tarde como una seria alternativa a Arduino en la
plataforma PIC, en una colaboración entre la propia Microchip y Digilent, portando con
fiabilidad las librerías de Arduino e intentando mantenerlas a la par con respecto a
estas. El principal problema es que aunque el entorno de desarrollo, que es el mismo
que el de Arduino, es libre, el compilador no lo era, ya que seguía usando los
propietarios ya existentes. Más tarde se liberó parte del compilador para su uso con las
placas chipKIT, pero algunas librerías seguían siendo propietarias. La gran ventaja es
que utiliza un microcontrolador de 32 bits, por lo que se nota una gran mejoría en
trabajos que requieren una gran cantidad de procesamiento con respecto al
microcontrolador de 8 bits de Arduino.
Página 34
Santiago Reig Chiva
Memoria
Ilustración 12 | chipKIT Uno32
Tabla 3 | Análisis chipKIT
Ventajas
 Toolchain gratuito
 API exactamente igual que la de Arduino
 Se mantiene la API lo más actualizada posible
Desventajas
 Toolchain no libre
 Pequeña comunidad de usuarios
6.1.3. Análisis de la plataforma ARM
Los procesadores de ARM han venido siendo muy competitivos desde siempre
tanto en precio como en rendimiento, llegando a hacer frente a los existentes
fabricantes tanto microcontroladores como de microprocesadores que lideran el
mercado actual.
Página 35
Santiago Reig Chiva
Memoria
La arquitectura Cortex-M ha sido la apuesta de ARM en el segmento de los
microcontroladores de baja potencia, siendo mucho más potente y eficiente que los ya
existentes y con un precio muy competitivo. El modelo más adecuado para el proyecto
sería el ARM Cortex-M0, ya que es el de menor capacidad de procesamiento, que no se
va a necesitar, pero también el de menor coste. Esta familia dispone de una gran
cantidad de pines, módulos de comunicación, etc.
Dicha arquitectura es prácticamente nueva y esto sumando a que ARM licencia
los cores a distintas empresas fabricantes de electrónica (Texas Instruments, NXP, ST
Electronics, etc.), crea una gran segmentación, ya que cada fabricante añade los
periféricos que más les interesa, crea sus propias librerías, etc., siendo la
documentación de la programación en esta arquitectura y de las librerías de los
fabricantes algo escasa. También existe una gran variedad de compiladores tanto
propietarios como de código abierto y todo esto hace que se tenga que estar bastante
familiarizado tanto como con la arquitectura ARM como con las librerías y periféricos
propios de cada fabricante.
Otro problema es que los chips con este núcleo casi siempre están a la venta
con empaquetado de montaje superficial, por lo que dificulta su montaje si no se tiene
los conocimientos necesarios, aunque actualmente están empezando a aparecer las
primeras versiones con empaquetado en tipo DIP.
6.1.3.1. Análisis de ST Micro
ST Micro tiene disponible una gama de placas de evaluación de los
microcontroladores ARM que ellos fabrican, es llamada Discovery. Son placas de bajo
coste que incluyen un microcontrolador, un programador y algún periférico extra, todo
en una misma placa, con los pines fácilmente accesibles y programable por USB. Se
disponen de varios de modelos con la familia Cortex-M de ARM, que sería la más
indicada para el proyecto.
Página 36
Santiago Reig Chiva
Memoria
Ilustración 13 | STM32 Discovery
Se dispone tanto de compilador propietario como la versión gratuita y de
código abierto de GCC.
Tabla 4 | Análisis de ST Micro
Ventajas
 Toolchain gratuito y libre
 Programador compatible con opciones libres
 Alta velocidad de procesamiento
Desventajas

Pines de conexión por el lado inferior de la placa
6.1.3.2. Análisis de NXP
NXP es la Antigua división de electrónica de Philips, que también se introdujo
en el mercado de los microcontroladores de bajo coste y consumo y alto rendimiento
con una familia basada en ARM. Dispone de placas de evaluación de bajo coste basada
en microcontroladores de la familia ARM Cortex-M con el programador y
microcontrolador en una misma placa y comunicación con el entorno de desarrollo a
través de USB o JTAG, según se prefiera.
Página 37
Santiago Reig Chiva
Memoria
Ilustración 14 | LPCXPRESSO con ARM Cortex-M0
Tabla 5 | Análisis de NXP
Ventajas
 Alta velocidad de procesamiento
Desventajas

Precio
Se dispone tanto de compilador propietario como la versión gratuita y de
código abierto de GCC.
6.1.4. Análisis de la plataforma de Texas Instruments
MSP430
El MSP430 es una familia de controladores producidos por Texas Instruments
con una arquitectura de 16 bits, pero con un precio a la par con sus competidores de 8
bits.
También existe un grupo de usuarios en esta plataforma para portar las
librerías de Arduino o una simplificación/aproximación de ellas, pero debido al bajo
número de desarrolladores implicados en el proyecto, no están muy completas.
6.1.4.1. Análisis de Launchpad
Esta familia es interesante debido a que tiene una placa de desarrollo
denominada Launchpad, realizada por la misma TI, que cumpliría con los requisitos del
proyecto y a un precio extremadamente competitivo.
Página 38
Santiago Reig Chiva
Memoria
La principal desventaja es que los chips básicos de esta familia no suelen tener
módulo hardware de UART, por lo que habría que implementarlo por software.
Ilustración 15 | TI Launchpad
Aunque el fabricante nos recomienda utilizar unos compiladores propietarios,
también existe una versión libre basada en GCC denominada mspgcc.
Tabla 6 | Análisis de Launchpad
Ventajas
 Precio
Desventajas
 Pocas librerías
 Dificultad de desarrollo
 Ausencia de USART en el microcontrolador provisto
Página 39
Santiago Reig Chiva
Memoria
6.2. Comparativa de soluciones para el medio de
comunicación
Para realizar el intercambio de información y datos entre el software en el
ordenador y la placa de interfaz con el mundo físico, es necesario realizarlo a través de
un medio de comunicación.
La velocidad de transmisión, así como su ancho de banda, no serán altos, que
aunque esto viene determinado principalmente por el protocolo, suele estar
directamente relacionado con el medio de transmisión. Esto nos permite poder
seleccionar un amplio abanico de soluciones simples, muy maduras y altamente
compatibles con los ordenadores.
Los que se han estudiado para su posible implantación en el proyecto, han sido
los siguientes:
6.2.1. Análisis del puerto paralelo
El puerto paralelo nos podría servir de interfaz entre el mundo virtual y real, ya
que podemos controlar las tensiones en los pines de éste y tenemos pines que pueden
ser configurados como salida pero también como entrada.
La desventaja es que no existe manera de realizar lecturas de tensiones de
forma analógica y debido a que los sistemas operativos comunes no son en tiempo
real, tampoco se podría realizar PWM en los pines de forma eficaz y consistente a lo
largo del tiempo. Estas deficiencias pueden ser suplidas con la ayuda de circuitería
externa, pero debiendo de poner casi obligatoriamente un microcontrolador, es
mucho más eficiente y cómodo trabajar por el puerto serie.
Otro problema existente es que cada vez es más difícil que un ordenador que
disponga de un puerto paralelo, siendo hoy en día casi imposible encontrar uno.
Página 40
Santiago Reig Chiva
Memoria
Tabla 7 | Análisis del puerto paralelo
Ventajas
 Posibilidad de usarlo directamente para realizar la interfaz con el mundo físico
Desventajas
 Los sistemas operativos no suelen trabajar en tiempo real
 Difícil de encontrar en equipos nuevos
6.2.2. Análisis del puerto serie
El puerto serie es un estándar de comunicación simple y con una gran madurez,
por lo que no suele ser difícil realizar una comunicación a través de éste. También
tiene la ventaja de que un gran abanico de microcontroladores, incluso los de bajo
precio y prestaciones, suelen tener un módulo hardware, que trabaja
independientemente del núcleo, dedicado a las comunicaciones por este medio,
facilitando en gran medida el funcionamiento de cara al implementador.
Aunque al igual que el puerto paralelo cada vez es más difícil encontrar dicha
interfaz en ordenadores nuevos, aunque debido a su gran versatilidad y utilidad
todavía siguen apareciendo en ordenadores de sobremesa, pero prácticamente
desaparecido en los ordenadores portátiles. De todas maneras, debido a esta
desaparición, fomentada en gran medida por la aparición del puerto USB, se han
creado chips que traducen el protocolo serie desde el microcontrolador y lo
empaquetan a través del USB, mostrando luego al ordenador un puerto serie virtual a
través del cual se realiza la conexión.
Tabla 8 | Análisis del puerto serie
Ventajas
 Suficientemente rápido
 Buena inmunidad al ruido
 Barato de implementar
 Muy utilizado y sencillo de trabajar
Desventajas

Difícil de encontrar en nuevos equipos
Página 41
Santiago Reig Chiva
Memoria
6.2.3. Análisis del USB
Cada vez es más común ver pequeños microcontroladores de bajo coste con
módulos hardware de comunicación por USB, aunque suelen duplicar su precio con
respecto a sus homólogos sin este módulo. También han ido apareciendo librerías que
implementan la funcionalidad USB en software mediante bit banging, pero a costa de
largos tiempos de procesamiento e interrupciones que deben ser atendidas lo más
rápido posible.
Tabla 9 | Análisis del USB
Ventajas
 Muy rápido
 Buena inmunidad al ruido
 Muy versátil
 Corrección de errores
Desventajas

Encarece el microcontrolador
6.2.4. Análisis del Bluetooth
Es un canal de comunicación inalámbrico de corto alcance (menos a 100 metros
en el mejor de los casos), pero con velocidades similares a la del puerto serie, que
permite realizar una conexión entre dos dispositivos. Su bajo coste y orientación al uso
por el consumidor, le ha permitido situarse como el medio de comunicación entre
dispositivos móviles.
Ilustración 16 | Módulo Bluetooth
Página 42
Santiago Reig Chiva
Memoria
Durante los últimos años se ha producido una reducción enorme del coste de
implantación de este protocolo, siendo incluido cada vez más en proyectos de bajo
coste y comercialización.
Los módems Bluetooth tienen una interfaz por la que configurarlos y
comunicarse a través de ellos basada en el puerto serie, por lo que podrían reemplazar
el cable del puerto serie sin grandes modificaciones del código.
Tabla 10 | Análisis del Bluetooth
Ventajas
 Inalámbrico
 Velocidad similar al puerto serie
 Fácil de implementar
Desventajas
 Poca potencia de transmisión
 No muy fiable y consistente a largo plazo
6.2.5. Análisis del XBee
Los dispositivos XBee, basados en la tecnología ZigBee, disponen de un stack
con añadidos que les permite realizar una función similar a la del bluetooth pero con
algunas diferencias: un menor consumo, la posibilidad de realizar redes de conexión
avanzadas como en malla y una mayor distancia, aunque a una velocidad menor.
Ilustración 17 | XBee Serie 1
Página 43
Santiago Reig Chiva
Memoria
Dependiendo del modelo escogido, podríamos llegar a alcanzar incluso decenas
de kilómetros.
Tabla 11 | Análisis del XBee
Ventajas
 Largas distancias de comunicación
 Corrección de errores
 Fácil de implementar
Desventajas

Precio
6.2.6. Otras soluciones
Existen otros muchos protocolos por los que se podría realizar la comunicación
entre la placa de interfaz física y el ordenador con el software, tales como
radiofrecuencia, WiFi, Ethernet, GSM y cualquier otro para el que exista una puerta de
enlace que haga de traductora entre ambos protocolos.
Página 44
Santiago Reig Chiva
Memoria
6.3. Comparativa de soluciones para el protocolo
de comunicaciones
El protocolo de comunicaciones será el encargado de definir como se transmite
toda la información relativa a la configuración de la placa y el estado de ésta entre ésta
y el ordenador con el software.
La cantidad de información va a ser muy baja durante la mayor parte del
tiempo, por lo que un protocolo sencillo de implementar, que funcione a través de un
medio de bajo coste y sea de bajo ancho de banda para facilitar su portabilidad e
implantación. Además que cuanto menor sean estos requerimientos, menor coste
tendrá la placa de interfaz que se necesite para utilizar junto al software del proyecto.
6.3.1. Análisis de Firmata
Firmata es un protocolo de comunicación genérico para controlar los
periféricos de un microcontrolador desde un software en un ordenador. Está diseñado
para ser incluido en cualquier software, ya que es de sencilla implementación.
Firmata está centrado principalmente en realizar el intercambio de información
a través del puerto serie y codificado en binario en vez de en ASCII como puede ocurrir
con otros, por lo que se aumenta bastante la cantidad de información posible de
transmitir en un solo paquete.
Éste protocolo esta desarrollado alrededor del ecosistema de Arduino,
pensando en las capacidades de estas placas. De hecho, junto a las distribuciones del
software de Arduino viene el firmware con la versión más actualizada del protocolo
listo para ser incorporado en las placas. Este firmware soporta las placas Arduino tanto
Uno, Duemilanove, Diecimila como las Mega.
El protocolo guarda una estrecha relación con el protocolo MIDI, ya que ha sido
su referencia desde casi la primera versión, cuando se rescribió el código para hacerse
compatible con éste.
Las principales funciones que están implementadas en el protocolo en la actual
versión 2.2, son las siguientes:
Página 45
Santiago Reig Chiva
Memoria

Configurar los pines: entrada, salida.

Lectura estado de los pines: alto, bajo.

Lectura entradas analógicas (con control de velocidad de muestreo).

PWM.

Control de servomotores.

I2C.
La licencia de las librerías de Firmata, así como de su implementación en el
firmware en la versión de Arduino, son libres, por lo que se podrán utilizar sin
problemas para el proyecto y al disponer del código fuente, se pueden realizar
modificaciones a éste para arreglar fallos de programación o añadir funcionalidades
que no existían.
Al estar incluido en el software de Arduino, el protocolo es usado por infinidad
de personas en cantidad de aplicaciones distintas, que demuestran la diversidad de
aplicaciones que puede tener el protocolo y confirman su estabilidad. Su desarrollo
también es continuo, con un flujo constante de ideas y mejoras que poco a poco se van
implementando.
Tabla 12 | Análisis de Firmata
Ventajas
 Ya implementado
 Comunidad de usuarios
 Desarrolladores activos
 Protocolo libre y gratuito
Desventajas

Ninguna
Página 46
Santiago Reig Chiva
Memoria
6.3.2. Análisis del protocolo de ArduLab
El paquete de software de ArduLab viene implementado con un protocolo de
comunicaciones propio, que en el fondo no difiere mucho de Firmata y con unas
funciones muy similares a éste último.
No es el más adecuado, ya que aunque es muy simple en su implementación,
limita su escalabilidad y no es lo suficientemente conocido en la comunidad tanto de
usuario como de desarrolladores para que siga el desarrollo del protocolo por su
propia inercia.
Tabla 13 | Análisis del protocolo de ArduLab
Ventajas
 Ya implementado
 Sencillo
Desventajas

No muy escalable
6.3.3. Análisis para la creación de un protocolo propio
La alternativa a utilizar los protocolos ya existentes, sería realizar un protocolo
propio, en el que se implementaran las capacidades exactas que se vayan a utilizar y
según se vayan necesitando.
Teniendo en cuenta que Firmata es un protocolo muy similar a lo que se
acabaría diseñando una vez avance el protocolo y ya dispone de muchas de las
optimizaciones que se le pueden realizar para mejorar su desempeño. Por lo que lo
más razonable en el caso de querer implementar un protocolo propio sería, tomar
como base el protocolo de Firmata, eliminar lo que no se necesite o interfiera en lo
planificado y desarrollar a partir de ahí.
Página 47
Santiago Reig Chiva
Memoria
Tabla 14 | Análisis de protocolo propio
Ventajas
 Totalmente adaptado a las necesidades
Desventajas

Tiempo de desarrollo
6.4. Comparativa de soluciones para el lenguaje
de programación
La elección del lenguaje de programación es posiblemente la que va a influir en
mayor medida durante el desarrollo del proyecto, por lo que habrá que seleccionarlo
tras un buen análisis de las opciones existentes.
En este análisis solo se tendrán en cuenta los lenguajes de programación para
la parte de software que funcionará en el lado del ordenador, la parte de
programación en la placa de interfaz será con una muy alta probabilidad C o C++,
debido a la capacidad de proceso y almacenamiento de estos dispositivos.
El lenguaje deberá ser multiplataforma, sin tener que realizar grandes cambios
en el código para tener que conseguirlo, ser un lenguaje conocido y estable y que el
desarrollo con él sea simple y versátil, con el que poder realizar todas las
funcionalidades del proyecto que se nos ocurran. Al deber ser multiplataforma la parte
de software, se descartarán de entrada la familia de lenguajes Visual y .NET de
Microsoft.
6.4.1. Análisis de Java
Es un lenguaje orientado a objetos, toma mucha de la sintaxis de C++, pero con
un modelo de objetos más simples, eliminando las herramientas de bajo nivel tales
como la manipulación directa de punteros y memoria, que solían inducir a error.
Al contrario de muchos lenguajes, Java se compila a bytecode pudiéndose
también compilar también a código máquina, pero estos suele realizarse por el
Página 48
Santiago Reig Chiva
Memoria
intérprete en tiempo real desde el código en bytecode, que permite ejecutarse en
cualquier plataforma que tenga el intérprete adecuado.
La principal desventaja es la antigüedad de la interfaz de usuario disponible con
y prácticamente sin actualizaciones en los últimos años, siendo esta además un
compleja para el desarrollo, que sigue los estilos de programación del momento en el
que se lanzó.
Tabla 15 | Análisis de Java
Ventajas
 Gran comunidad de usuarios
 Gran cantidad de ejemplos
 Elimina las complejidades de C++
Desventajas

Librería para interfaces de usuario incluida muy antigua
6.4.2. Análisis de Qt
Está basado en C++ y su punto fuerte es la capa de abstracción que han creado
encima de este para añadir características multiplataforma, tanto de escritorio como
móviles (Windows, Linux, Mac OS, Symbian, and Maemo), incluye librerías para
desarrollar interfaces de usuario con ventanas y está acompañado por una gran
cantidad de herramientas potentes y una extensa y bien organizada documentación.
Hace una temporada tuvo un futuro incierto, ya que éste lenguaje de
programación pertenece a Nokia, que no pasó por unos años muy buenos y su
existencia peligraba, pero hace poco decidieron liberar el lenguaje de programación
con sus librerías, por lo que se asienta su futuro; habiendo aparecido durante el
desarrollo de este proyecto de una revisión menor y la casi finalización de una revisión
mayor.
Página 49
Santiago Reig Chiva
Memoria
Tabla 16 | Análisis de Qt
Ventajas
 Basado en C++
 Gran calidad de la documentación
 Herramientas de desarrollo muy completas e integradas
 Librerías para interfaces de usuario de gran calidad
Desventajas

Futuro algo incierto
6.4.3. Análisis de Python
Es un lenguaje de alto nivel y de propósito general, cuya filosofía se centra en la
legibilidad, notable potencia y una muy clara sintaxis, con una biblioteca estándar
grande y completa.
Python es un lenguaje ideal tanto para realizar programas prototipo como para
programas finales, ya que aunque es interpretado, los ordenadores hoy en día son lo
suficientemente potentes como para poder con esta sobrecarga. La ventaja es que se
pueden probar trozos de código directamente en la consola de ejecución para su
prueba, pero con la desventaja de que los fallos de programación no aparecen hasta
que el intérprete ejecuta la instrucción errónea, pudiendo pasarse por alto en las
revisiones de código.
Al igual que Java, Python es interpretado y también puede ser compilado a
bytecode, aunque no a código máquina, pero si que puede ser ejecutado con el código
fuente, realizando el propio intérprete la compilación a bytecode antes de ejecutarlo.
Python viene por defecto con la librería de Tk para realizar interfaces de
ventanas, aunque su uso es complicado y su apariencia deja bastante de desear. Este
problema se compensa debido a la existencia de librerías que enlazan con proyectos
como Qt, wxWidgets o GTK+, con una excelente apariencia y mayor facilidad de uso.
Uno de los problemas es que la creación de paquetes de distribución en Python
no está muy documentada, por lo que en principio se hace casi imprescindible el uso
de librerías que facilitan su uso, pero no son todo lo completas que se desearían.
Página 50
Santiago Reig Chiva
Memoria
Tabla 17 | Análisis de Python
Ventajas
 Sencillez de desarrollo
 Cantidad de librerías
 Gran comunidad de usurarios
Desventajas

Librería para interfaces de usuario incluida muy antigua
Página 51
Santiago Reig Chiva
7. Descripcion
adoptada
Memoria
de
la
solucion
7.1. Descripción de la placa de interfaz adoptada
En el proyecto utilizaremos la placa Arduino, por su alta disponibilidad y
cantidad de documentación disponible. Es una placa con entradas y salidas digitales y
salidas de PWM, entradas analógicas, pudiendo conectarla a una gran cantidad de
periféricos como leds, sensores resistivos o de voltaje, servomotores, dimmers, etc.
Al estar todo lo que necesitamos de esa plataforma (hardware, librerías,
compilador y protocolo) bajo una licencia libre, se podrá utilizar sin problemas en el
desarrollo del proyecto.
Una de las principales ventajas es que el firmware del protocolo Firmata viene
ya implementado y probado, por lo que se puede centrar todo el esfuerzo en el
desarrollo de la parte de la interfaz de usuario.
7.2. Descripción del medio de comunicación
adoptado
Debido a que la placa Arduino posee un puerto USB por el que es posible
realizar una comunicación serie, se utilizará este medio de comunicación. Además el
USB es un estándar implementado en prácticamente cualquier ordenador en su
versión 2.0 desde hace más de una década, por lo que se asegura una compatibilidad
prácticamente total.
Al estar la comunicación serie encapsulada en el protocolo USB, se pueden
llegar a utilizar velocidades mucho mayores que a través del tradicional puerto serie.
La única desventaja es la necesidad de instalar los drivers USB en la plataforma
Windows al conectar por primera vez una placa Arduino para realizar la comunicación,
Página 52
Santiago Reig Chiva
Memoria
pero debido a la gran cantidad de documentación existente sobre este tema y su
sencillez no se tendrá en cuenta como un problema mayor.
De todas maneras, se podrá utilizar cualquier solución de comunicación que sea
invisible para el Arduino, tales como Bluetooth, XBee, puerto serie y otros muchos con
el hardware y software adecuado, sin necesidad de cambiar una sola línea de código
del firmware contenido en el Arduino.
7.3. Descripción del protocolo de comunicación
adoptado
El protocolo utilizado para la comunicación será Firmata, ya que al estar
bastante asentado y probado para este tipo de uso, con una base de datos y lista de
correo para solucionar los problemas durante su uso o implementación, no tiene
sentido implementar un protocolo dedicado para este proyecto cuando su
funcionamiento sería similar en un 90%.
Su evolución es constante y con visos a dar compatibilidad a los nuevos
modelos de Arduino, también a hacer las adaptaciones correspondientes para permitir
ser utilizado a través de Ethernet u otros medios de comunicación.
7.4. Descripción del lenguaje adoptado
Python ha sido el lenguaje escogido para la programación de la interfaz de
usuario, ya que es multiplataforma y permite un desarrollo rápido de aplicaciones.
Para suplir las deficiencias de la librería estándar de Python se hará uso de las
siguientes librerías adicionales:

PyQt: para la parte de interfaz de usuario se usarán las librerías de Qt para
Python, por lo que también se tendrá a disposición todo el poder de este
lenguaje, tanto con los tipos de datos como la creación de interfaces de
usuario, todo ello también compatible con cualquier plataforma. Qt tiene
una interfaz de usuario multiplataforma que imita muy bien la apariencia de
Página 53
Santiago Reig Chiva
Memoria
las aplicaciones nativas, por lo que el usuario se sentirá familiar con la
forma de ésta, dejando también la opción al desarrollador de modificarlo a
su gusto.

PyQwt: es una librería que añade elementos gráficos científicos tales como
gráficas, sliders con medida, etc. Se basa en la librería Qwt desarrollada
para Qt.

PySerial: librería que se ocupa de las comunicaciones desde Python con el
puerto serie, ya sea real o virtual (a través de USB). Su interfaz es muy
simple y de fácil uso.

PyFirmata: se encarga del protocolo de comunicación y en conjunción con
PySerial, realiza la transmisión de datos con la placa de interfaz mediante el
protocolo Firmata a través del puerto serie. No es una librería muy común,
por lo que presenta algunos fallos que tuvieron que ser solucionados.

cx_Freeze: una vez terminado el proyecto debe ser empaquetado para su
distribución de forma sencilla por los usuarios. Al ser la interfaz de
empaquetamiento de Python un poco compleja, esta librería hace de
intermediario facilitando su uso. Nos permite crear instaladores para
cualquiera de las plataformas más conocidas.
Tanto el lenguaje de programación, como las librerías listadas anteriormente
son de uso sin restricciones para proyectos de código abierto, por lo que no se tendrá
ningún problema en este sentido.
Página 54
Santiago Reig Chiva
Memoria
8. Desarrollo
8.1. Diseño general
Una vez ya conocidas las tecnologías a utilizar en el proyecto, conocemos
cuales van a ser las características y límites que nos vamos a encontrar. El proyecto va
a constar de cuatro partes diferenciadas, las cuales son:

Aplicación software: es el centro de control de los periféricos de la placa a
la que está conectado. Se comunica con la placa para configurarla según se
ha indicado por el usuario y muestra la información recibida de la placa de
forma visual en la pantalla. Se desarrollará en Python y Qt con
compatibilidad multiplataforma.

Interfaz USB-serie: es el encargado de convertir la señal USB procedente
del PC a serie estándar. Este conversor existe en la propia placa Arduino,
que en las placas antiguas es un FTDI FT2332 y en las nuevas versiones un
ATmega 16u2. Como se ha comentado anteriormente, la comunicación
también puede realizarse por muchos otros medios adecuados para el uso.

Arduino: interpreta los comandos recibidos por el puerto serie, realizando
las tareas adecuadas e informando al PC de los cambios que se han
producido en la placa.

Alimentación: si no se van a conectar grandes cargas al Arduino que
superen los 500mA, se podrá usar la alimentación procedente del USB (en
el caso que lo tengamos conectado a éste), si no, se utilizará un
transformador conectado a la toma de red que nos provea de una tensión
continua de 5 a 9V y se enchufará al conector provisto para esto.
Página 55
Santiago Reig Chiva
Memoria
Ilustración 18 | Diagrama de conexiones
8.2. Análisis del protocolo Firmata
8.2.1. Introducción
Firmata es un protocolo de comunicación entre un ordenador y un
microcontrolador que apareció en los inicios de la historia de Arduino, por lo que las
características de este protocolo están muy centradas en las capacidades del Arduino.
Es un protocolo de comunicación genérico para controlar los periféricos de un
microcontrolador desde un software en un ordenador. Está diseñado para ser incluido
en cualquier software y hardware, ya que es de sencilla implementación.
Éste protocolo soporta las placas Arduino tanto Uno, Duemilanove, Diecimila
como las Mega, aunque en el proyecto se ha decidido soportar la placa más común y
utilizada que es la Uno.
Firmata realiza el intercambio de información a través del puerto serie y
codificado en binario en vez de en ASCII como puede ocurrir con otros, por lo que se
Página 56
Santiago Reig Chiva
Memoria
aumenta bastante la cantidad de información posible de transmitir en un solo
paquete.
Con las distribuciones del software de Arduino, se adjunta una copia del
firmware de Firmata para las placas Arduino, que implementa el protocolo y nos
permite realizar las siguientes acciones:

Configurar los pines: entrada, salida

Lectura estado de los pines: alto, bajo

Lectura entradas analógicas (con control de velocidad de muestreo)

PWM

Control de servomotores

I2C
8.2.2. Descripción del protocolo
Durante la realización del protocolo, los creadores vieron que era similar al
existente MIDI, por lo que lo modificaron para hacerlo totalmente compatible con
este, que aunque no es directamente usable con controladores MIDI, puede coexistir
con MIDI sin problemas y ser tratado por intérpretes MIDI sin problemas, aunque
algunos datos de los mensajes son utilizados de forma diferente al estándar.
8.2.2.1. Mensajes
El protocolo está formado por mensajes, que consisten en una serie de 8 bits.
Cada mensaje tiene su función asignada. Algunos mensajes consisten en un solo byte,
mientras que otros pueden llegar a tener 2 ó 3 bytes. También existe un mensaje con
el que poder enviar un número ilimitado de bytes. Algo que todos los mensajes tienen
en común es que el primer byte del mensaje es el de estado, que es especial ya que es
el único que tiene el bit 7 activado, mientras que los siguientes bytes del mensaje no lo
tienen activado, de ésta manera se puede detectar siempre el inicio de un mensaje. Se
Página 57
Santiago Reig Chiva
Memoria
puede deducir entonces que los bytes de estado están en el rango 0x80÷0xFF, por lo
que el número de éstos está limitado a 127 y el resto de los bytes del mensaje, los de
datos si es que existen, estarán en el rango 0x00÷0x7F.
Tabla 18 | Comparación mensajes MIDI y Firmata
Comando
Significado
0x90
Activar nota
0x90
I/O digital
Parámetros
Parámetro 1
MIDI
2
nota
Firmata
2
LSB (bits 0÷6)
Parámetro 2
fuerza
MSB (bits 7÷13)
8.2.3. Descripción de la comunicación
El firmware de Firmata para las placas Arduino, realiza la comunicación por la
USART de éste, por lo que abre un gran abanico de posibilidades de comunicación a
través de diversos medios.
En el caso más común, se realizaría la conexión al PC utilizando el propio
conversor serie-USB disponible en la propia placa Arduino, también podría conectarse
al puerto serie del PC usando un adaptador de niveles serie de TTL a RS-232, que
permitiría distanciar la placa del PC decenas de metros gracias a la robustez del medio
de transmisión. En caso de disponer de los conversores adecuados y desear la
comunicación de esta manera, puede realizarse a través de redes XBee, Bluetooth,
radiofrecuencia, Ethernet, Internet y otros muchos.
La comunicación es bidireccional ya que la placa necesita enviar al PC su estado
(lecturas digitales y analógicas, estado de los pines, etc.) y el PC enviar los comandos
necesarios para configurar la placa según requiera el usuario del software; y si el
medio lo permite (en la implementación en Arduino se puede) será una comunicación
totalmente full-duplex.
Las transferencias se realizan en paquetes de 1 byte, utilizándose los 7 bits de
menos peso para datos y el octavo para indicar si es un comando. Los mensajes están
formados por una cantidad de 1 a 3 bytes según sea, pero en el caso de que
necesitemos enviar una mayor cantidad de información puede extenderse a cualquier
longitud utilizando el comando SysEx.
Página 58
Santiago Reig Chiva
Memoria
La configuración de la comunicación serie por defecto se realiza a 57600
baudios, con 8 bits de trama, 1 bit de parada y sin control de paridad o flujo, aunque al
realizarse la transmisión por USB puede llegarse a sobrepasar el millón de baudios en
el caso de ser estrictamente necesario.
El paquete de transmisión se compone de:
1. Idle: en ausencia de comunicación, la línea tendrá una señal mantenida a
nivel alto (break).
2. Inicio: antes de recibir la trama de información, se transmitirá un bit a nivel
bajo (space) para indicar la transmisión de la trama.
3. Trama: información que recibirá la placa o el PC (suponemos que se recibe
primero el bit de mayor nivel). Está compuesta por 8 bits, divididos en dos
partes.
1. Bit de comando: si el bit está activo (break), indica que el byte
recibido es un comando y deberá ser tratado como tal, si no, será
información. Este bit debe estar siempre activo en el primer byte de
un mensaje.
2. Información: los 7 bits restantes son el comando o los datos
transferidos, según se haya recibido el bit de comando.
4. Bit de stop: al finalizar la trama se transmitirá un bit de stop a nivel alto
(break).
Después de esto pueden ocurrir dos cosas, o se deja de recibir/transmitir y la
línea se deja a nivel alto (break) o se vuelve a transmitir otro byte en el caso de
mensajes de 2 o más bytes, por lo que se volverá a comenzar en el punto número 1.
Página 59
Santiago Reig Chiva
Memoria
La plantilla para interpretar una transmisión sería la siguiente:
Bits de datos
Idle o
segundo byte
Trama
Mensaje
8.2.4. Mejoras en la implementación del protocolo
El firmware de Firmata para Arduino (en su actual versión 2.2 en el momento
de realizar éste documento) al inicializar los pines de éste, los configura como salida y
a nivel alto, cosa que puede ser peligrosa para mantener la integridad de la placa
Arduino a largo plazo, ya que si se conecta el cable de salida de un sensor o ya se tiene
conectado uno a la hora de encender la placa, probablemente este sensor no tenga la
salida a 5V, por lo que se producirá un cortocircuito, estresando el pin provocando una
degradación prematura del silicio que en el caso extremo podría llegar a su
inutilización, pudiendo también afectar al sensor o circuito conectado.
Gracias a que este firmware es de código abierto, se procedió a añadir un
nuevo modo en el que los pines estuvieran como entrada y a nivel bajo y se hizo que
todos los pines se configuraran a este modo al inicio del programa o cuando se deje de
utilizar un pin, dando una solución adecuada al anterior problema.
Página 60
Santiago Reig Chiva
Memoria
También se modificó el orden de inicio de las funciones de Firmata, ya que
según estaba implementado, se necesitaba alrededor de dos segundos como mínimo
de espera hasta poder realizar la conexión de la placa.
8.2.5. Descripción de la capa física
La capa física no viene definida por el protocolo, aunque indirectamente se
prevé que por su campo de aplicación en microcontroladores sea la transmisión
mediante transmisión serie asíncrona (USART) a niveles de tensión TTL a 5V en la
mayoría de los casos y a 3.3V en una minoría, que es como viene diseñado el protocolo
por defecto. Aunque como se ha comentado anteriormente, el protocolo puede ser
transmitido por cualquier medio siempre que se tengan las herramientas y
conocimientos necesarios para ello, ya que en el caso de la implementación en
Arduino, la capa de procesamiento del protocolo está completamente desacoplada de
la de transmisión, facilitando inmensamente esta tarea.
8.2.6. Descripción de los conectores
Desde el punto de vista del usuario, el medio de transmisión va a ser el USB,
por lo que será este el que se analizará en este apartado.
Las conexiones son extremadamente simples, ya que debido a la forma que
poseen los conectores, es prácticamente imposible conectarlos de forma errónea. Se
recomienda el uso de cables de al menos 1m. de largo y apantallados.
El conector tipo A será el que se conecte al ordenador y el tipo B a la placa
Arduino, aunque los nuevos modelos están siendo lanzados con el conector micro-B y
otras placas compatibles con la Arduino UNO realizadas por otros fabricantes suelen
llevar el conector mini-B.
Página 61
Santiago Reig Chiva
Memoria
Ilustración 19 | Conectores USB
La asignación de pines para el estándar USB, es el siguiente:

Pin 1: Vcc, línea de alimentación para los dispositivos conectados, la tensión
es de 5V y 0,5A de corriente máxima. El color habitual es el rojo.

Pin 2: Data-, señal de transmisión invertida a -3,3V a nivel bajo, polo
negativo. El color habitual es el blanco.

Pin 3: Data+, señal de transmisión no invertida a 3,3V a nivel alto. El color
habitual es el verde.

Pin 4: referencia, retorno de la alimentación y conexión al mallado del
cable. El color habitual es el negro.
El quinto pin existente en las versiones de los conectores micro y mini puede
estar desconectado o referenciado a masa.
Página 62
Santiago Reig Chiva
Memoria
8.2.7. Descripción del cableado
El estándar USB utiliza un cable de 4 conductores, uno para alimentación, otro
para la tensión de referencia y otros dos para transmisión de datos. Éstos últimos son
diferenciales y los cables están trenzados, por lo que poseen una gran inmunidad al
ruido.
Ilustración 20 | Líneas de datos
El cable debe tener una cobertura exterior de
policloruro de vinilo (PVC), una protección contra
ruido externo que conste de una malla de cobre
estañado entrelazado, una capa de protección
interna de poliéster metalizado de aluminio, los
cables de datos con una sección mínima 28 AWG,
que según el estándar al que hace referencia,
equivaldría a un diámetro de 0,38 mm y 23,20
ohmios máximo por 100 m y de 28 a 20 AWG para la
línea de alimentación que sería de 0,32 mm a 0,89
mm y de 23,20 a 3,58 ohmios máximo por 100 m.
Ilustración 21 | Cable USB A-B
La capacitancia del bus con un dispositivo esclavo conectado a un cable USB, no
debe ser menor a 200 pF o mayor a 450 pF en las líneas D- o D+.
8.2.8. Distancias y terminaciones
La terminación de los buses, es decir, las resistencias de terminación para evitar
la reflexión de la señal en el final del cable y que rebote volviendo a aparecer en el bus,
no es necesario añadirlas, ya que está diseñado de forma transparente al usuario,
estando ya incluidas en el driver.
La longitud máxima de transmisión viene dada por la atenuación de la señal y el
tiempo de propagación, aunque como regla general se recomienda no exceder los 5
metros de cable
Página 63
Santiago Reig Chiva
Memoria
8.3. Análisis de la aplicación software
Considerando lo anteriormente citado sobre software ya disponible, se procede
a la realización de un software de control visual de la placa de interfaz.
Para dicho efecto, se va a realizar una aplicación multiplataforma compatible
con Windows, Linux y Mac con un único código fuente, sin necesidad de rescribir la
aplicación para cada uno de ellos.
Ilustración 22 | Proyecto ejecutado en Windows 7
Página 64
Santiago Reig Chiva
Memoria
Ilustración 23 | Proyecto ejecutado en Linux Ubuntu 12.04
Ilustración 24 | Proyecto ejecutado en Mac OS X Lion
Página 65
Santiago Reig Chiva
Memoria
Uno de los requisitos que se va a tener en cuenta a la hora de su elaboración,
es que se trate de un programa sencillo e intuitivo, de modo que personas no
especializadas en la electrónica puedan ser capaces de aprovechar todas sus
posibilidades. También se diseñará de forma que sea sencillo añadir, por parte de
cualquier usuario o desarrollador, nuevos módulos al programa que extiendan su
funcionalidad.
La aplicación mandará por el cable USB las modificaciones de los valores que
realicemos y mostrará la información del estado de la placa de interfaz.
8.3.2. Entorno de trabajo utilizado para el desarrollo
Para el desarrollo de la aplicación se ha escogido Eric IDE, el cual es un entorno
de desarrollo integrado.
El entorno de desarrollo contiene múltiples ventanas y da acceso a variada
funcionalidad, por lo es denominado como entorno de desarrollo integrado (integrated
development enviroment, IDE).
Ilustración 25 | Eric IDE
Página 66
Santiago Reig Chiva
Memoria
Soporta los lenguajes de programación Ruby y Python, siendo éste último el
elegido para la programación de la parte de software del proyecto. Se ha escogido este
entorno de desarrollo, aparte de por ser compatible con el desarrollo en Python, por
estar centrado principalmente en el desarrollo con PyQt, que es una de las librerías
que más se utilizarán durante la programación. Las principales características son,
coloreado de código, depurador, visualizador de variables, ejecución paso a paso, muy
integrado con PyQt, lo que permite realizar de forma automática tareas que de otra
forma se deberían realizar de forma manual y es multiplataforma, por lo que se podrá
desarrollar el software tanto en Windows como en Linux o Mac, aunque la principal
plataforma de este desarrollo será Windows.
Para que la aplicación se ejecute correctamente, es necesario que las librerías
que se han detallado anteriormente (PyQt, pySerial, pyFirmata y PyQwt) estén
instaladas. Si se ejecuta el programa usando el instalador provisto en el CD adjunto, no
será necesaria ninguna acción adicional, ya que se instalan automáticamente, dejando
el programa listo para utilizar.
8.3.3. Descripción del código fuente
El código fuente está programado en Python como se ha mencionado
anteriormente, es un lenguaje sencillo, potente, interpretado y multiplataforma.
Debido a la extensión del código, se van a describir sólo las partes más
importantes de éste. Una versión más extendida del código puede encontrarse en los
anexos y la totalidad de éste en el CD que se adjunta con este documento.
8.3.3.1. Inicialización de los módulos
Como se ha comentado a lo largo del documento, el programa está formado
por distintos módulos que realizan cada uno una función distinta.
Una vez se ha terminado de arrancar el subsistema que dé el soporte a la
aplicación para ejecutarse, se importarán las clases de los módulos indicados para
poder ser luego inicializados y accedidos.
from selectportdlg import SelectPortDlg
Página 67
Santiago Reig Chiva
from
from
from
from
from
from
from
Memoria
mode import ModeTab
analog import AnalogTab
digital import DigitalTab
pwm import PWMTab
servo import ServoTab
motor import MotorTab
sequencer import SequencerTab
Estas líneas cargan los archivos .py existentes en la carpeta ui y dan acceso a las
clases que controlan la interfaz de usuario de cada módulo.
Se puede observar que también se carga la ventana de selección del puerto
serie, que será lo primero que le aparezca al usuario.
Una vez se haya seleccionado el puerto serie, se inicializarán los módulos
llamando a los constructores de las clases que hemos importado. De esta manera se
acelera el arranque del programa, en vez de cargarlos desde el primer momento,
cuando incluso puede que el usuario cierre el programa directamente y no llegue a
usarlo.
self.tabs
=
(ModeTab(self),
DigitalTab(self),
AnalogTab(self),
PWMTab(self), ServoTab(self), MotorTab(self), SequencerTab(self))
De esta forma se inicializa la interfaz de usuario con los valores por defecto y
configuración adecuada.
Para añadir o quitar módulos sólo hace falta hacer modificaciones en los dos
grupos de código anteriores, por lo que es muy sencillo y rápido.
Las clases tienen que tener dos métodos que se llamarán cuando se entre o se
salga de la pestaña a la que corresponde esa clase, de esta forma se pueden liberar
pines, iniciar la captura de datos, etc. de forma automática al cambiar de pestaña y sin
tener que realizar continuamente transmisiones de datos para representar
información que se dibuja en una pestaña oculta.
self.tabs[self.lastIndex].exitTab()
Página 68
Santiago Reig Chiva
Memoria
self.tabs[index].enterTab()
8.3.3.2. Selección del puerto serie
En el diálogo de selección del puerto serie, se muestran los puertos serie
disponibles en el sistema. Es el conjunto de los disponibles en hardware, es decir, con
conector hembra DB-9 y protocolo RS-232 y los virtuales a través de USB.
La estrategia seguida para encontrar los puertos disponibles en Linux y Mac
varía con la de Windows:
ports = list()
if POSIX:
ports
+=
glob.glob("/dev/ttyACM*")
glob.glob("/dev/ttyUSB*")
+
glob.glob("/dev/tty.usb*")
glob.glob("/dev/tty.serial*")
for i in xrange(256):
try:
s = serial.Serial(i)
ports.append(s.portstr)
s.close()
except serial.SerialException:
pass
+
+
En Windows sólo se miran uno a uno cada puerto serie del 1 al 256 si existen y
son accesibles y también en Linux y Mac, pero los puerto series virtuales a través de
USB, se deben buscar en la ruta /dev.
Una vez se haya seleccionado un puerto serie, se crea un objeto que representa
el Arduino, y se comunica con el a través del protocolo Firmata por el puerto serie.
board = Board(self.portsCmb.currentText(), BOARDS['arduino'])
Una vez comprobada que la placa Arduino se comunica correctamente con el
software, se inician las pestañas como se ha indicado en el punto anterior.
Página 69
Santiago Reig Chiva
Memoria
8.3.3.3. Programación del Arduino
Para comunicarse con la placa Arduino mediante Firmata, debe estar
programada con el firmware adecuado que pueda realizar dicha comunicación. Debido
a que es común que una placa Arduino sea reprogramada para otros usos, la inclusión
de un programador del firmware en la pantalla de bienvenida era una característica
obligatoria.
Para descargar el firmware en la placa Arduino se utiliza el programador
avrdude, un proyecto de código abierto que programa infinidad de microcontroladores
de Atmel en conjunto con un programador compatible con ellos, en este caso el
programador va incluido en el bootloader del Arduino, por lo que no hace falta un
programador externo.
La llamada al programador fue una parte problemática ya que cada sistema
operativo tiene una forma distinta de llamar a los ejecutables y de tratar las rutas de
archivos con espacios entre medios, por lo que para no ensuciar el código con partes
distintas para cada S.O., se buscó una solución compatible a todos ellos.
executable = os.path.join(appdir, "avrdude", "avrdude")
configuration = os.path.join(appdir, "avrdude", "avrdude.conf")
hexadecimal = os.path.join(appdir, "avrdude", "PlatexFirmata.hex")
command = "\""+executable+"\" -q -V -C \""+configuration+"\" -p
atmega328p -c arduino -P "+self.portsCmb.currentText()+" -b 115200 -D -U
flash:w:\""+hexadecimal+"\":i"
Una vez lista la llamada al ejecutable del programador con todos los
parámetros listos, se iniciaba la programación.
self.program.start(command)
Una vez terminada la programación se comprueba el resultado de esta y se
informa el usuario, apareciendo una ventana de aviso si se ha producido algún fallo.
Otra parte muy problemática fue la de encontrar la ruta de los archivos del
proyecto, ya que es una tarea relativamente sencilla si se ejecuta desde el código
Página 70
Santiago Reig Chiva
Memoria
fuente, pero una vez es empaquetado en forma de instalador, la estructura del
programa cambia completamente, habiendo casos en los que el ejecutable y los
archivos del proyecto se instalan en rutas distintas, por lo que el algoritmo para
encontrar dichos ficheros se complicó en gran medida debiendo tener en cuenta todas
las posibles combinaciones de empaquetado que se realizan para cada uno de los
sistemas operativos.
isfrozen = getattr(sys, 'frozen', False)
if isfrozen:
if not sys.path or not sys.path[0]:
raise
RuntimeError('Cannot
determine
sys.path[0] is empty!')
else:
entry = sys.path[0]
else:
if not sys.argv or not sys.argv[0]:
entry = '<interpreter>'
else:
entry = sys.argv[0]
app
path
because
entry = os.path.realpath(entry)
appdir = os.path.dirname(entry)
8.3.3.4. Comunicación con Firmata
El proyecto hace uso de una librería para la comunicación siguiendo el
protocolo Firmata a través del puerto serie. Esta librería fue desarrollada por Tino de
Bruijn, desarrollador residente en los Países Bajos y que liberó su código fuente para
uso no comercial.
Es una librería que aunque funcional, se le han realizado una serie de
modificaciones para mejorar la velocidad de respuesta, arreglar una serie de bugs,
aumentar la funcionalidad e integrarla con la estructura del proyecto.
La configuración de pines para limitar las funciones que podemos asignar a
cada pin pueden está definido en un archivo de configuración.
BOARDS = {
'arduino' : {
Página 71
Santiago Reig Chiva
Memoria
'digital' : tuple(x for x in range(24)),
'analog' : tuple(x for x in range(14, 20)),
'pwm' : (3, 5, 6, 9, 10, 11),
'use_ports' : True,
'disabled' : (0, 1, 20, 21, 22, 23) # Rx, Tx, Crystal
},
'arduino_mega' : {
'digital' : tuple(x for x in range(54)),
'analog' : tuple(x for x in range(16)),
'pwm' : tuple(x for x in range(2,14)),
'use_ports' : True,
'disabled' : (0, 1, 14, 15) # Rx, Tx, Crystal
}
}
Cada función tiene asignados determinados pines tanto de forma paramétrica
como individualmente. En el proyecto sólo se hará uso de la placa Arduino normal, por
lo que la configuración de la versión Mega no se utilizará.
El archivo de configuración ha sido modificado con respecto al original debido a
que no permitía utilizar las características digitales que los pines analógicos también
poseen. También se modificó la numeración de los pines analógicos para hacerla
correlativa con respecto a los digitales y poder hacer uso de ellos tanto de forma
digital como analógica.
Una vez se ha seleccionado el puerto serie como se ha indicado en el apartado
anterior, se inicia un iterador que mira continuamente si ha llegado algún byte a través
del puerto serie para procesarlo y esto se realiza de forma paralela al programa en
otro hilo de ejecución.
self.it = util.Iterator(self.board)
self.it.start()
Una vez recibida una trama se procederá a comprobar si se trata de una trama
válida. Para ello se comprobarán que las transmisiones que se están recibiendo siguen
las especificaciones del protocolo que se han marcado.
byte = self.sp.read()
Página 72
Santiago Reig Chiva
Memoria
if not byte:
return
data = ord(byte)
received_data = []
handler = None
if data < START_SYSEX:
try:
handler = self._command_handlers[data & 0xF0]
except KeyError:
return
received_data.append(data & 0x0F)
while len(received_data) < handler.bytes_needed:
received_data.append(ord(self.sp.read()))
elif data == START_SYSEX:
data = ord(self.sp.read())
handler = self._command_handlers.get(data)
if not handler:
return
while data != END_SYSEX:
received_data.append(data)
else:
try:
handler = self._command_handlers[data]
except KeyError:
return
while len(received_data) < handler.bytes_needed:
received_data.append(ord(self.sp.read()))
try:
handler(*received_data)
except ValueError:
pass
Se discrimina según el tipo de dato que se haya recibido para ser procesado de
la forma que se debe hacer, una vez identificado el tipo de dato, y separado el
comando de los datos, se llama a la función que debe procesarlos pasándole una
referencia de los datos recibidos.
El envío de tramas se realiza de forma individual para cada caso, por ejemplo si
se desea cambiar el tiempo de muestreo de los pines analógicos se utiliza la siguiente
función para mandar los tiempos a la placa Arduino:
def sampling_interval(self, interval=19):
Página 73
Santiago Reig Chiva
Memoria
if interval < 19: inteval = 19
elif interval > 16383: interval = 16383
self.send_sysex(SAMPLING_INTERVAL, to_two_bytes(interval))
El dato de tiempo de muestreo se envía a través del mensaje extendido SysEx,
ya que no tiene asignado un comando directamente. En la transmisión van incluidas el
identificador de tiempo de muestreo y el propio tiempo de muestreo que en este caso
se ha decidido mandarlo en un máximo de 14 bits, que equivalen a dos bytes de
transmisión a través de Firmata.
En los casos en los que existe un comando para la acción a realizar, por
ejemplo, para cambiar el modo de funcionamiento de un pin, el código sería algo
distinto:
command = chr(SET_PIN_MODE)
command += chr(self.pin_number)
command += chr(mode)
self.board.sp.write(command)
8.4. Análisis de la placa de interfaz
Como se ha estipulado anteriormente, la placa de interfaz estará basada en la
plataforma Arduino.
Ilustración 26 | Logo Arduino
Página 74
Santiago Reig Chiva
Memoria
Arduino es una plataforma de electrónica abierta, centrada en la creación de
prototipos, basada en hardware y software libre fáciles de usar, ya que el usuario final
para el que se diseñó eran artistas, diseñadores y aficionados.
Arduino toma información del entorno a través de sus pines de entrada por los
que se puede conectar una gran variedad de sensores y puede interactuar con lo que
le rodea a través de actuadores tales como luces, motores, etc.
El microcontrolador existente en la placa Arduino se programa en C/C++
haciendo uso de las librerías de Arduino, aunque también es posible programar sin
utilizarlas utilizando sólo las librerías estándares de avrlibc o haciéndolo directamente
en ensamblador.
Los proyectos hechos con Arduino pueden ejecutarse sin necesidad de estar
conectados a un ordenador, el código es grabado en la memoria flash de la placa y su
ejecución comienza automáticamente al alimentar la placa.
El proyecto Arduino está basado en otros proyectos de código abierto y libres
tales como Wiring para las librerías del microcontrolador y Processing para el entorno
de desarrollo. El propio proyecto Arduino también es de código abierto y libre, tanto
para la parte de hardware como para la de software, por lo que las placas pueden ser
fabricadas a mano o compradas a través de los distribuidores existentes, pudiendo
descargar los ficheros de diseño con la posibilidad de modificarlos para adaptarlos a la
aplicación que se desee.
Ilustración 27 | Arduino UNO R2
Página 75
Santiago Reig Chiva
Memoria
El proyecto se ha desarrollado utilizando la placa Arduino UNO R2, aunque es
compatible tanto con las revisiones 1 y 3 de la misma placa como con la Arduino
Duemilanove y Diecimila. La compatibilidad con la Arduino Leonardo debería ser total
una vez se asiente la recién salida placa.
8.4.2. Características principales
El Arduino UNO es una placa electrónica basada en el Atmega328 de Atmel.
Este integrado se intenta en la medida de lo posible que sea en la versión PDIP para
poder cambiar el chip fácilmente y sin herramientas por cualquier usuario, en caso de
que falle o se rompa, aunque este tipo de empaquetado está tendiendo a desparecer,
en favor del montaje superficial mucho más difícil de sustituir, pero más barato de
fabricar y montar.
Ilustración 28 | ATmega328P
Dicho microcontrolador cuenta con 20 entradas/salidas digitales, de los cuales
6 pueden ser utilizados como salidas PWM y otros 6 como entradas analógicas, un
cristal de 16Mhz, una conexión serie a la que se puede acceder también por puerto
serie como se explicará en el siguiente apartado, un conector ICSP para conectar un
programador, un botón de reseteo, un conector jack para alimentación externa y un
conversor USB-Serie.
Tabla 19 | Características del Arduino UNO
Característica
Microcontrolador
Voltaje de funcionamiento
Voltaje de entrada (recomendado)
Nombre
ATmega328
5V
7-12V
Página 76
Santiago Reig Chiva
Voltaje de entrada (límites)
Pines digitales I/O
Pines de entrada analógica
Corriente continua de los pines I/O
Corriente continua del pin de 3,3 V
Memoria Flash
SRAM
EEPROM
Velocidad de reloj
Memoria
6-20V
14 (6 de las cuales proporcionan
una salida PWM)
6
40 mA
50 mA
32 KB (ATmega328) de los
cuales 0,5 KB utilizado por
gestor de arranque
2 KB (ATmega328)
1 KB (ATmega328)
16 MHz
8.4.3. Formas de alimentación eléctrica
La placa puede ser alimentada a través de la conexión USB o con una fuente de
alimentación externa. La fuente de la alimentación es escogida automáticamente
mediante la electrónica integrada en la placa, dando prioridad a la alimentación
externa que probablemente tenga una capacidad mucho mayor a la del USB.
La alimentación externa puede ser introducida a la placa por el conector jack de
2,1mm existente en la placa o mediante cables sueltos conectándolos a GND y Vin.
La tensión mínima recomendada para alimentar la placa de forma externa es de
7V, ya que hay caídas de tensión tanto en el regulador de tensión para obtener los 5V
como en las distintas protecciones eléctricas como la de conexión inversa, que crean
pequeñas caídas de tensión. Como máximo se recomienda utilizar 9V, aunque es
posible alimentar con 12V, el regulador de tensión se sobrecalentará excesivamente,
pudiendo llegar a apagarse por sobrepasar la temperatura máxima de funcionamiento.
Los pines relativos a la alimentación que podemos encontrar en la placa son:

Vin: es la entrada de voltaje no regulado a la placa de alimentación, está
conectado a la entrada de alimentación externa por el jack. Este pin puede
Página 77
Santiago Reig Chiva
Memoria
ser usado tanto como entrada como salida de alimentación, pero sólo si se
está alimentando externamente.

5V: este pin está conectado a la salida del regulador de tensión que
transforma la tensión de Vin en 5V, también está conectado al pin de 5V del
conector USB. La máxima intensidad que se puede obtener de este pin es
de 500mA. En caso de alimentarlo por USB, en caso de alimentación
externa es difícil de determinar ya que depende en gran medida de la
tensión de entrada, cuanto mayor sea la tensión, menor será la intensidad
máxima que se pueda obtener.

3V3: es una tensión de 3.3V obtenida por un regulador de tensión a partir
de raíl de 5V. La máxima intensidad que se puede obtener de este pin es de
120mA en las nuevas versiones y 50mA en las antiguas.

GND: tensión de referencia, masa.
8.4.4. Análisis de la memoria
El Atmega328 tiene 32KB de memoria flash, que permite una rápida descarga
del programa en el microcontrolador. De los 32KB, 0,5KB son utilizados por el
bootloader.
También posee 2KB de memoria RAM estática y 1KB de memoria EEPROM, que
a esta última no se le dará uso en el proyecto, aunque en el plan de ruta del protocolo
Firmata se usará para guardar el estado de la placa entre usos aunque esta haya sido
desconectada de la alimentación.
8.4.5. Análisis de las entradas y salidas
Cada una de los 20 pines digitales del Arduino puede ser usado como entrada o
salida, usando las funciones adecuadas. Todos los pines funcionan a 5V, por lo que si
se les conecta a una tensión mayor puede que dejen de funcionar permanentemente.
Cada pin tiene una salida de intensidad de 40mA máximo y una resistencia de pull-up
integrada de unos 20-50 kOhms.
Página 78
Santiago Reig Chiva
Memoria
Además, algunos pines tienen alguna función adicional:

Serie: 0 (RX) y 1 (TX). Se usan para recibir y transmitir datos serializados con
niveles TTL. Estos pines están conectados al conversor USB-Serie para
comunicarse con el ordenador. En el proyecto se utilizará esta
comunicación por lo que su uso como pines digitales no estará disponible.

Interrupciones externas: 2 y 3, pueden ser configurados para interrumpir la
ejecución del código y realizar otra tarea. Pueden ser configurados para
interrumpir por nivel, por flanco o por cambio de valor.

PWM: seis pines marcados en la placa con el símbolo ~, pueden proveer
una salida de PWM con una precisión de 8 bits y con una frecuencia en el
orden de kilohercios.

SPI: protocolo de comunicación serie mediante 4 hilos muy utilizado para
comunicación de corto alcance entre microcontroladores. Suele ser
utilizado también para programar el microcontrolador Atmel mediante un
programador compatible.

I2C: protocolo de comunicación serie mediante 2 hilos muy utilizado para la
comunicación de corto alcance con sensores inteligentes.
8.4.6. Análisis de la Interfaz USB-Serie
La comunicación de la placa de interfaz con el software se realizará a través de
USB, pero el microcontrolador con el que se comunica sólo tiene interfaz serie, por lo
que habrá que realizar dicha conversión externamente, utilizando para ello un circuito
integrado que haga de conversor entre ambos protocolos.
PC
Conversor USB-Serie
Micro
Ilustración 29 | Interfaz USB-Serie
Página 79
Santiago Reig Chiva
Memoria
8.4.6.1. Chip FTDI
Los primeros modelos de placas Arduino contenían un chip denominado
FT232R fabricado por Future Technology Devices International (FTDI) que está hecho a
medida y está centrado en la conversión del protocolo serie a USB, emulando un
puerto serie en el lado del ordenador al que se ha conectado.
Ilustración 30 | Arduino Duemilanove
El nivel de soporte de drivers existente es bastante bueno y se han desarrollado
tanto para los principales sistemas operativos como para otros no tan conocidos,
existiendo también versiones para 32 y 64 bits.
La principal ventaja de esta alternativa es que el chip no necesita configuración
y no se tiene que tener conocimiento alguno del protocolo USB para realizar dicha
conversión.
El precio no es excesivamente alto y la cantidad de componentes externos se
limita a unos pocos condensadores y a unos leds en el caso de que se desee una
visualización de la actividad del puerto serie.
8.4.6.2. Chip Atmel
Las siguientes revisiones de las placas Arduino, cambiaron el chip conversor
USB-Serie FTDI por un chip de Atmel (el Atmega16u2) con un módulo USB, de esta
manera se mantenía el chip principal de Arduino intacto sin tener que desarrollar
nuevas librerías y el chip FTDI, de un precio algo elevado, era sustituido por el Atmel.
Página 80
Santiago Reig Chiva
Memoria
Se desarrolló un firmware que hiciera
exactamente la misma función que l FTDI al
que reemplaza. Para ello se utilizó la
especificación Communication Device Class
(CDC), que entre los varios tipos de interfaces
existentes, permite emular un puerto serie
siguiendo las especificaciones del protocolo
Ilustración 31 | Arduino UNO
USB. Al estar en las especificaciones y tratarse
el USB de un estándar de comunicaciones
bastante extendido, no se necesita la instalación de drivers en los sistemas operativos
Linux y Mac OS, aunque en Windows si que siguen siendo necesarios.
Como defecto, se necesita más espacio en placa, ya que el microcontrolador
necesita de un cristal externo para mantener la precisión en la comunicación USB,
aparte del conector ICSP de programación.
Una ventaja de estos chips es que reprogramándolos se puede emular otros
tipos de dispositivos USB, tales como teclados, ratones, etc.
8.4.6.3. Sin chip
El último modelo de la placa Arduino,
denominada Leonardo, no necesita este chip conversor
de USB a serie ya que el nuevo chip de Atmel que incluye
(el Atmega32u4) contiene un módulo USB, por lo que
permite eliminar el conversor intermedio al poder recibir
el mismo la trama USB, procesarla y comunicarse.
Ilustración 32 | Arduino
Leonardo
En el paquete de software de Arduino, se
incluyen las librerías necesarias para configurar dicho
módulo de la forma adecuada, de manera que emule un puerto serie tanto para el
sistema operativo al que se conecta como para el programador de la placa.
La principal ventaja de esta solución es que no es necesaria la instalación de
drivers en las plataformas Linux y Mac OS y elimina el chip conversor que tenía un peso
importante en el precio de venta final.
Página 81
Santiago Reig Chiva
Memoria
Cualquier solución, de las citadas anteriormente, utilizada en las placas es
compatible con la parte de software del proyecto.
8.4.7. Análisis de los métodos de programación
El Arduino UNO puede ser programado desde el software de Arduino,
seleccionando el modelo adecuado de la placa y el puerto serie al que está conectado.
El Atmega328 incluido en las placas Arduino, viene pregrabado con un
bootloader que emula el protocolo del programador STK500, por lo que es compatible
con variedad de software de programación además del software de Arduino.
También existe la posibilidad de programar el Atmega328 a través del conector
ICSP de seis pines, mediante el uso de un programador ICSP. Habrá que utilizar uno de
los modelos soportados por el software Arduino o utilizar un software externo para
realizar la operación de descarga del software.
8.4.8. Análisis del entorno de trabajo
El software de Arduino está basado en Java, por lo que posee compatibilidad
multiplataforma.
Página 82
Santiago Reig Chiva
Memoria
Ilustración 33 | Software Arduino en Windows 7
Es un entorno de desarrollo muy simple, aunque esa es su principal baza, que lo
hace muy fácil de usar al no tener nada que configurar. Tiene una ventana principal
donde se edita el código con coloreado de funciones y una inferior en la que aparecen
los mensajes de error de los procesos de compilado y programación del
microcontrolador.
Ilustración 34 | Botones de verificación y carga
Tiene dos botones principales, que son los que realizan la tarea de verificar el
código escrito mediante la compilación de éste y el segundo el de compilación y carga
del código en la placa Arduino a través del puerto serie.
También lleva integrado un simple monitor serie, con el que poder depurar el
código mandando mensajes a través del puerto serie, o directamente interactuar con
un programa que tenga su interfaz de usuario a través de este protocolo.
Página 83
Santiago Reig Chiva
Memoria
Lleva incluida una toolchain para los AVR basada en avr-gcc, que es compilador
que toma código en lenguaje C/C++ de alto nivel o ensamblador y crea un archivo
binario que se pueda programar en un AVR. Técnicamente avr-gcc es sólo un
compilador, portado de GCC (GNU Compiler Collection) para la familia de AVR de
Atmel, pero las mayorías de referencias a avr-gcc se refieren a todo el toolchain.
El paquete de software también lleva incluido un programador para los AVR
llamado avrdude, que es un programa de línea de comandos, ideal para automatizar.
Es compatible con el programador STK500 a través del puerto serie, que es el
programador que emulan los chips con el bootloader de Arduino para grabar en la
flash el archivo binario del programa desde el propio microcontrolador.
Tanto la toolchain de compilación para los AVR, como el programado, son de
código abierto y libres y además están incluidos en el paquete de software, por lo que
está listo para ser ejecutado en cualquier ordenador con sólo necesitar la instalación
de la máquina virtual de Java. De esta manera se elimina la dependencia de librerías
externas que solían traer problemas debido a la gran variedad de versiones que los
usuarios podían tener instaladas, tanto muy nuevas y con fallos de código no
descubiertos como muy antiguas con características no implementadas.
Página 84
ANEXOS
DOCUMENTO Nº 2
Santiago Reig Chiva
Anexos
Índice de los anexos
9.
Anexo I: Diseño y programación de la aplicación..................................... 91
9.1.
Código inicialización aplicación: platex.pyw ............................................ 91
9.2.
Código de la pantalla principal: mainwindow.py ..................................... 92
9.3.
Código ventana selección puerto serie: selectportdlg.py ........................ 94
9.4.
Módulo configuración pines: mode.py .................................................... 99
9.5.
Módulo control pines digitales: digital.py .............................................. 101
9.6.
Módulo lectura analógica: analog.py ..................................................... 103
9.7.
Módulo control de PWM: pwm.py ......................................................... 107
9.8.
Módulo control de servomotores: servo.py ........................................... 109
9.9.
Módulo control de motores DC: motor.py ............................................. 113
9.10.
Módulo secuenciador: sequencer.py ................................................. 117
9.11.
Código para crear instalador: setup.py............................................... 122
9.12.
Script de compilación para Linux: build-linux.sh ................................ 123
9.13.
Script de compilación para Mac: build-mac.sh ................................... 127
10.
Anexo II: Instalación del dispositivo USB ................................................ 132
11.
Anexo III: Manual de usuario de Platex .................................................. 137
11.1.
Instalación ........................................................................................... 137
11.1.1. Microsoft Windows ........................................................................ 137
Página 86
Santiago Reig Chiva
Anexos
11.1.2. Linux Ubuntu .................................................................................. 139
11.1.3. Mac OS X ........................................................................................ 141
11.2.
Ventana inicial..................................................................................... 142
11.3.
Ventana principal ................................................................................ 143
11.3.1. Configuración ................................................................................. 144
11.3.2. Digital.............................................................................................. 146
11.3.3. Analógico ........................................................................................ 147
11.3.4. PWM ............................................................................................... 149
11.3.5. Servo ............................................................................................... 150
11.3.6. Motores .......................................................................................... 152
11.3.7. Secuenciador .................................................................................. 154
12.
Anexo IV: Compilación y distribución del software................................ 157
12.1.
Windows ............................................................................................. 157
12.2.
Linux .................................................................................................... 160
12.3.
Mac OS ................................................................................................ 162
Página 87
Santiago Reig Chiva
Anexos
Ilustración 35 | Nuevo hardware encontrado ................................................. 132
Ilustración 36 | Selección de método de búsqueda alternativa ...................... 133
Ilustración 37 | Ubicación donde buscar los controladores............................. 134
Ilustración 38 | Instalando los controladores .................................................. 135
Ilustración 39 | Los controladores no están firmados ..................................... 135
Ilustración 40 | El controlador se instaló correctamente ................................ 136
Ilustración 41 | Ruta de instalación por defecto .............................................. 138
Ilustración 42 | Aviso de modificación del equipo ........................................... 138
Ilustración 43 | Centro de Software de Ubuntu ............................................... 139
Ilustración 44 | Se proporcionan los permisos de administrador .................... 140
Ilustración 45 | Instalación finalizada correctamente ...................................... 140
Ilustración 46 | Permisos insuficientes............................................................. 141
Ilustración 47 | Ventana inicial ......................................................................... 142
Ilustración 48 | Módulo de configuración ........................................................ 144
Ilustración 49 | Lista de modos ........................................................................ 145
Ilustración 50 | Algunos pines configurados .................................................... 145
Ilustración 51 | Módulo digital ......................................................................... 146
Ilustración 52 | Estado de activación ............................................................... 147
Página 88
Santiago Reig Chiva
Anexos
Ilustración 53 | Módulo analógico ................................................................... 148
Ilustración 54 | Traza analógica oculta ............................................................. 149
Ilustración 55 | Módulo PWM .......................................................................... 150
Ilustración 56 | Servomotor de hobby ............................................................. 151
Ilustración 57 | Módulo servos......................................................................... 151
Ilustración 58 | Activación de servos................................................................ 152
Ilustración 59 | Módulo motores ..................................................................... 153
Ilustración 60 | Motor Shield 3.0...................................................................... 154
Ilustración 61 | Motor Shield R3 ...................................................................... 154
Ilustración 62 | Módulo secuenciador ............................................................. 155
Ilustración 63 | Controles específicos .............................................................. 156
Ilustración 64 | Activar salida del compilador .................................................. 159
Ilustración 65 | Botón de verificar código ........................................................ 159
Ilustración 66 | Localización del firmware ....................................................... 160
Ilustración 67 | Comando en una terminal de Linux Ubuntu ........................... 161
Ilustración 68 | Comando en una terminal de Mac OS X Lion ......................... 163
Página 89
Santiago Reig Chiva
Anexos
Índice de tablas
Tabla 20 | Asignación de pines ......................................................................... 154
Página 90
Santiago Reig Chiva
Anexos
9. Anexo Í: Diseno y programacion
de la aplicacion
9.1. Código inicialización aplicación: platex.pyw
#!/usr/bin/env python
# -*- coding: utf-8 -*import sip
sip.setapi('QString', 2)
from PyQt4 import QtCore, QtGui
import sys, logging, os
from ui.mainwindow import MainWindow
import resources_rc
if __name__ == "__main__":
logging.basicConfig(format="%(levelname)-8s %(asctime)s %(module)12s %(message)s", level=logging.DEBUG)
logger = logging.getLogger(__name__)
app = QtGui.QApplication(sys.argv)
app.setOrganizationName("Universidad de La Rioja")
app.setOrganizationDomain("unirioja.es")
app.setApplicationName("Platex")
main = MainWindow()
main.show()
sys.exit(app.exec_())
Página 91
Santiago Reig Chiva
Anexos
9.2. Código de la pantalla principal:
mainwindow.py
# -*- coding: utf-8 -*"""
This module contains the class MainWindow.
"""
import logging
from PyQt4.QtGui import QMainWindow, QPushButton, QMenu, QActionGroup
from PyQt4.QtCore import QTimer, pyqtSlot
from pyfirmata import Arduino, util
from
from
from
from
from
from
from
from
from
Ui_mainwindow import Ui_mainWindow
selectportdlg import SelectPortDlg
mode import ModeTab
analog import AnalogTab
digital import DigitalTab
pwm import PWMTab
servo import ServoTab
motor import MotorTab
sequencer import SequencerTab
class MainWindow(QMainWindow, Ui_mainWindow):
"""
MainWindow: this is the class that manages all the funcionality of
receiving input from the user.
"""
def __init__(self, parent=None):
"""
Default Constructor. It can receive a top window as parent.
"""
QMainWindow.__init__(self, parent)
logger.debug("Created MainWindow")
self.setupUi(self)
for x in xrange(2, 20):
eval("self.pin%02d"
{padding:0px}")
self.board = None
self.lastIndex = 0
%
(x)).setStyleSheet("*
QTimer.singleShot(0, self.selectPort)
Página 92
Santiago Reig Chiva
Anexos
def selectPort(self):
dialog = SelectPortDlg(self)
dialog.exec_()
# If empty object is returned, we exit
self.board = dialog.getBoard()
if not self.board:
self.close()
else:
self.tabs
=
(ModeTab(self),
AnalogTab(self),
PWMTab(self),
ServoTab(self),
SequencerTab(self))
self.tabs[0].enterTab()
DigitalTab(self),
MotorTab(self),
self.it = util.Iterator(self.board)
self.it.start()
@pyqtSlot(int)
def on_tabWidget_currentChanged(self, index):
"""
Slot documentation goes here.
"""
self.tabs[self.lastIndex].exitTab()
self.tabs[index].enterTab()
self.lastIndex = index
def closeEvent(self, event):
if hasattr(self.board, "exit"):
self.board.exit()
event.accept()
Página 93
Santiago Reig Chiva
Anexos
9.3. Código ventana selección puerto serie:
selectportdlg.py
# -*- coding: utf-8 -*import logging, serial, os, sys
from PyQt4.QtGui import QDialog, QPushButton, QComboBox,
QStackedWidget, QHBoxLayout, QVBoxLayout, QWidget, QMessageBox
from PyQt4.QtCore import QTimer, pyqtSlot, QProcess
QLabel,
from pyfirmata import Board
from pyfirmata.boards import BOARDS
POSIX = False
if os.name == "posix":
import glob
POSIX = True
# Code for getting app folder
if isfrozen:
raise
determine
else:
entry = sys.path[0]
else:
else:
entry = sys.argv[0]
app
path
because
class SelectPortDlg(QDialog):
QDialog.__init__(self, parent)
logger.debug("Port selection dialog created")
statusLbl = QLabel("Programando el Arduino...")
self.connectBtn = QPushButton("&Conectar")
self.programBtn = QPushButton("&Programar")
exitBtn = QPushButton("Salir")
multiLbl = QLabel("&Selecciona la placa:")
self.portsCmb = QComboBox()
Página 94
Santiago Reig Chiva
Anexos
multiLbl.setBuddy(self.portsCmb)
self.stackedWidget = QStackedWidget()
mainWidget = QWidget()
mainLayout = QHBoxLayout()
mainLayout.addWidget(multiLbl)
mainLayout.addWidget(self.portsCmb)
mainWidget.setLayout(mainLayout)
self.stackedWidget.addWidget(mainWidget)
progWidget = QWidget()
progLayout = QHBoxLayout()
progLayout.addWidget(statusLbl)
progLayout.addStretch()
progWidget.setLayout(progLayout)
self.stackedWidget.addWidget(progWidget)
buttonLayout = QHBoxLayout()
buttonLayout.addWidget(self.connectBtn)
buttonLayout.addWidget(self.programBtn)
buttonLayout.addStretch()
buttonLayout.addWidget(exitBtn)
layout = QVBoxLayout()
layout.addWidget(self.stackedWidget)
layout.addLayout(buttonLayout)
self.setLayout(layout)
self.boards = list()
self.board = None
self.programBtn.clicked.connect(self.programBoard)
self.portsCmb.currentIndexChanged[int].connect(self.updatePorts)
self.connectBtn.clicked.connect(self.connectBoard)
exitBtn.clicked.connect(self.reject)
self.setWindowTitle(u"Iniciando comunicación")
self.updatePorts(True)
logger.debug("Working dir: "+appdir)
@pyqtSlot()
def updatePorts(self, force=False):
# FIXME: Program button gets focus when opening QComboBox
if self.portsCmb.currentText() != "Actualizar" and not force:
return
logger.debug("Searching available serial ports")
self.connectBtn.setEnabled(False)
self.programBtn.setEnabled(False)
ports = list()
if POSIX:
Página 95
Santiago Reig Chiva
Anexos
ports
+=
+
+
+
try:
s.close()
pass
logger.debug("Found %d serial port(s): %s", len(ports), ports)
if not len(ports):
ports = [""]
self.portsCmb.clear()
self.portsCmb.addItems(ports)
self.portsCmb.addItem("Actualizar")
if self.portsCmb.currentText() != "":
self.connectBtn.setEnabled(True)
self.programBtn.setEnabled(True)
self.connectBtn.setFocus()
@pyqtSlot()
def connectBoard(self):
try:
logger.debug("Connecting
to
Arduino
board
on
port
"+self.portsCmb.currentText())
board
=
Board(self.portsCmb.currentText(),
BOARDS['arduino'])
except ValueError, e:
logger.warning(e)
QMessageBox.warning(self, u"!Atención¡", unicode(e))
except TypeError, e:
logger.debug(e)
except serial.serialutil.SerialException, e:
logger.warning(e)
else:
logger.debug("Using
Arduino
board
on
port
"+board.sp.portstr)
self.board = board
self.accept()
@pyqtSlot()
def programBoard(self):
if
not
os.path.exists(os.path.join(appdir,
"PlatexFirmata.hex")):
"avrdude",
Página 96
Santiago Reig Chiva
Anexos
logger.error("Hexadecimal file not found")
QMessageBox.warning(self, u"¡Atención!", u"No se pudo
encontrar el fichero a programar")
return
self.stackedWidget.setCurrentIndex(1)
logger.debug("Programming
Arduino
board
on
configuration
=
os.path.join(appdir,
"avrdude",
"avrdude.conf")
hexadecimal
=
"avrdude",
"PlatexFirmata.hex")
self.program = QProcess()
#
avrdude
reference:
http://www.ladyada.net/learn/avr/avrdude.html
command = "\""+executable+"\" -q -V -C \""+configuration+"\" p atmega328p -c arduino -P "+self.portsCmb.currentText()+" -b 115200 -D -U
logger.debug("avrdude call: "+command)
self.program.finished.connect(self.programFinished)
@pyqtSlot()
def programFinished(self):
output = str(self.program.readAllStandardError())
if output.find("flash written") == -1: # avrdude: xxxx bytes
of flash written
if output.find("Expected signature") != -1: # avrdude:
Expected signature for ATMEGA328P is 1E 95 0F
error = u"La placa conectada no tiene un chip
compatible."
elif output.find("not in sync: resp=0x00") != -1: #
avrdude: stk500_getsync(): not in sync: resp=0x00
error = u"No parece que haya ninguna placa conectada
al puerto."
elif output.find("ser_send()") != -1: # ser_send(): write
error: sorry no info avail
error = u"Se produjo un error durante la comunicación
con la placa.\nAsegúrate de que está correctamente conectada."
elif output.find("ser_open()") != -1: # ser_open(): ....
error = u"El puerto no se pudo abrir.\nAsegúrate de
que ningún programa lo está usando."
else:
error = u"Se produjo un error al programar la
placa.\nComprueba el conexionado."
logger.warning("avrdude output: "+output)
logger.warning("An error ocurred: "+error)
QMessageBox.warning(self, u"¡Atención!", error)
Página 97
Santiago Reig Chiva
Anexos
else:
logger.debug("Programmed successfully")
def getBoard(self):
return self.board
Página 98
Santiago Reig Chiva
Anexos
9.4. Módulo configuración pines: mode.py
# -*- coding: utf-8 -*import logging
from PyQt4.QtCore import pyqtSlot
from PyQt4.QtGui import QMenu, QActionGroup
class ModeTab(object):
def __init__(self, mwHandle):
self.mw = mwHandle
pin = eval("self.mw.pin%02d" % (x))
menu = QMenu(pin)
modeGroup = QActionGroup(self.mw)
modeGroup.setExclusive(True)
none = menu.addAction("&None")
modeGroup.addAction(none)
none.triggered.connect(self.clickNone)
none.setCheckable(True)
none.setChecked(True)
input = menu.addAction("&Input")
modeGroup.addAction(input)
input.triggered.connect(self.clickInput)
input.setCheckable(True)
output = menu.addAction("&Output")
modeGroup.addAction(output)
output.triggered.connect(self.clickOutput)
output.setCheckable(True)
if self.mw.board.pins[x].PWM_CAPABLE:
pwm = menu.addAction("&PWM")
modeGroup.addAction(pwm)
pwm.triggered.connect(self.clickPWM)
pwm.setCheckable(True)
if self.mw.board.pins[x].type == 2:
analogic = menu.addAction(u"&Analógico")
modeGroup.addAction(analogic)
analogic.triggered.connect(self.clickAnalog)
analogic.setCheckable(True)
pin.setMenu(menu)
pin.setStyleSheet("/* */") # force stylesheet update
def enterTab(self):
logger.debug("Entering mode tab")
Página 99
Santiago Reig Chiva
Anexos
def exitTab(self):
logger.debug("Exiting mode tab")
@pyqtSlot()
def clickNone(self):
self._changeMode(self.mw.sender(), 7)
@pyqtSlot()
def clickInput(self):
@pyqtSlot()
def clickOutput(self):
@pyqtSlot()
def clickPWM(self):
@pyqtSlot()
def clickAnalog(self):
def _changeMode(self, action, mode):
pin = action.parentWidget().parentWidget()
text = ['I', 'O', 'A', 'P', '', '', '', 'N']
pin.setText(text[mode])
pin.setStyleSheet("/* */") # force stylesheet update
number = int(pin.property("objectName").toString()[-2:])
self.mw.board.pins[number].mode = mode
if mode == 2:
self.mw.board.pins[number].disable_reporting()
logger.debug("Changed
pin
%d
mode
to
'%s'",
number,
pin.text())
Página 100
Santiago Reig Chiva
Anexos
9.5. Módulo control pines digitales: digital.py
class DigitalTab(object):
self.mw = mwHandle
for x in self.mw.board.ports:
x.pinChanged.connect(self.updatePin)
@pyqtSlot(int, bool)
def updatePin(self, number, state):
logger.debug("Input pin "+str(number)+" changed its state to
"+str(state))
eval("self.mw.di%02d" % (number)).setChecked(state)
def enterTab(self):
logger.debug("Entering digital tab")
digPin = eval("self.mw.d%02d" % (x))
digInPin = eval("self.mw.di%02d" % (x))
digPin.setVisible(False)
digInPin.setVisible(False)
mode = self.mw.board.pins[x].mode
if mode == 1:
digPin.clicked.connect(self.digPinClicked)
digPin.setVisible(True)
digPin.setChecked(self.mw.board.pins[x].read())
elif mode == 0:
digInPin.setVisible(True)
digInPin.setChecked(self.mw.board.pins[x].read())
self.mw.board.pins[x].enable_reporting()
def exitTab(self):
logger.debug("Exiting digital tab")
self.mw.board.pins[x].disable_reporting()
@pyqtSlot()
def digPinClicked(self):
pin = self.mw.sender()
Página 101
Santiago Reig Chiva
Anexos
number = int(pin.property("objectName").toString()[-2:])
if pin.isChecked():
self.mw.board.pins[number].write(1)
logger.debug("Changed output pin "+str(number)+" state to
True")
else:
self.mw.board.pins[number].write(0)
logger.debug("Changed output pin "+str(number)+" state to
False")
Página 102
Santiago Reig Chiva
Anexos
9.6. Módulo lectura analógica: analog.py
from functools import partial
from PyQt4.Qwt5 import QwtPlotGrid, QwtPlotCurve, QwtPlot, QwtPlotItem
from PyQt4.Qt import Qt, QPen
HISTORY = 60
class AnalogTab(object):
self.mw = mwHandle
self.curves = list()
self.data = list()
self.bars = list()
for i in xrange(0, 6):
self.bars.append({ 'group' : eval("self.mw.gbAnalog%d" %
(i)),
'bar'
:
eval("self.mw.analogBar%d"
%
eval("self.mw.lbAnalog%d"
%
(i)),
'label'
:
(i)),
'active'
:
eval("self.mw.analogShow%d"
% (i)) })
eval("self.mw.analogShow%d"
(i)).stateChanged.connect(partial(self._channelVisible, i))
%
self.mw.analogPlot.setAutoReplot(False)
self.mw.analogPlot.plotLayout().setAlignCanvasToScales(True)
grid = QwtPlotGrid()
grid.enableXMin(True)
grid.enableYMin(True)
grid.attach(self.mw.analogPlot)
grid.setPen(QPen(Qt.black, 0, Qt.DotLine))
grid.setMinPen(QPen(Qt.lightGray, 0, Qt.DotLine))
self.mw.analogPlot.setAxisScale(QwtPlot.xBottom, 0, HISTORY)
self.mw.analogPlot.setAxisScale(QwtPlot.yLeft, 0, 5)
self.mw.analogUnits.insertItems(0, ("Voltios", "Cuentas"))
self.mw.board.updateAnalog.connect(self._newSample)
self.mw.analogUnits.currentIndexChanged.connect(self._changedUnits)
Página 103
Santiago Reig Chiva
Anexos
self.mw.analogUnitsTime.currentIndexChanged.connect(self._changedUnitsTime)
self.mw.analogTime.valueChanged[int].connect(self._changedTime)
colors
=
(Qt.blue,
Qt.red,
Qt.black,
Qt.darkCyan, Qt.magenta)
for i in xrange(0, 6):
curve = QwtPlotCurve()
curve.setPen(QPen(colors[i], 2))
curve.attach(self.mw.analogPlot)
self.curves.append(curve)
self.data.append(self._zeros(HISTORY+1))
self.bars[i]['bar'].setFillBrush(colors[i])
Qt.darkGreen,
self.mw.analogPlot.replot()
@pyqtSlot(int, int)
def _newSample(self, channel, value):
if self.mw.analogUnits.currentIndex() is 0:
value = round(float(value*5) / 1023, 2)
self.data[channel] = self.data[channel][1:]
self.data[channel].append(value)
self.curves[channel].setData(range(0,
self.data[channel])
self._updatePlot(channel)
HISTORY+1),
def _updatePlot(self, channel):
if self.mw.analogUnits.currentIndex() is 0:
self.bars[channel]['bar'].setValue(round(self.data[channel][HISTORY], 1))
self.bars[channel]['label'].setText(str(round(self.data[channel][HISTORY],
1)))
else:
self.bars[channel]['bar'].setValue(int(self.data[channel][HISTORY]))
self.bars[channel]['label'].setText(str(int(self.data[channel][HISTORY])))
def enterTab(self):
logger.debug("Entering analog tab")
self._changedTime(self.mw.analogTime.value())
for pin in self.mw.board.pins:
if pin.type is 2:
channel = pin.pin_number-14
if pin.mode is 2:
pin.enable_reporting()
Página 104
Santiago Reig Chiva
Anexos
logger.debug("Enabled analog reporting of analog
pin "+str(channel))
self.curves[channel].setVisible(self.bars[channel]['active'].isChecked())
self.bars[channel]['group'].setEnabled(True)
else:
self.curves[channel].setVisible(False)
self.bars[channel]['group'].setEnabled(False)
self.bars[channel]['bar'].setValue(0)
self.bars[channel]['label'].setText(str(0))
self.data[channel] = self._zeros(HISTORY+1)
HISTORY+1),
self.data[channel])
def exitTab(self):
logger.debug("Exiting analog tab")
for pin in self.mw.board.pins:
if pin.type is 2 and pin.mode is 2:
channel = pin.pin_number-14
logger.debug("Disabled analog reporting of analog pin
"+str(channel))
pin.disable_reporting()
self.data[channel] = self._zeros(HISTORY+1)
self.mw.board.sampling_interval()
def _zeros(self, length):
x = list()
for i in xrange(0, length):
x.append(0)
return x
def _resizeHistory(self, factor):
for channel in xrange(0, len(self.data)):
for sample in xrange(0, len(self.data[channel])):
self.data[channel][sample] *= factor
HISTORY+1),
self.data[channel])
@pyqtSlot(int)
def _changedUnits(self, index):
if index is 0:
logger.debug("Changed analog units to volts")
self._resizeHistory(5.0/1024)
for bar in self.bars:
bar['bar'].setRange(0, 5)
else:
Página 105
Santiago Reig Chiva
Anexos
logger.debug("Changed analog units to counts")
self._resizeHistory(1024.0/5)
for bar in self.bars:
bar['bar'].setRange(0, 1024)
@pyqtSlot(int, int)
def _channelVisible(self, channel, state):
self.curves[channel].setVisible(state)
@pyqtSlot(int)
def _changedUnitsTime(self, index):
value = self.mw.analogTime.value()
self.mw.analogTime.blockSignals(True)
if index is 0:
self.mw.analogTime.setRange(19, 16383)
self.mw.analogTime.setValue(value*1000)
else:
self.mw.analogTime.setRange(0, 16)
self.mw.analogTime.setValue(value/1000)
self.mw.analogTime.blockSignals(False)
@pyqtSlot(int)
def _changedTime(self, time):
if self.mw.analogUnitsTime.currentIndex() is 0:
self.mw.board.sampling_interval(time)
else:
self.mw.board.sampling_interval(time*1000)
Página 106
Santiago Reig Chiva
Anexos
9.7. Módulo control de PWM: pwm.py
class PWMTab(object):
self.mw = mwHandle
self.sliders = list()
for x in self.mw.board.pins:
if x.PWM_CAPABLE:
slider = eval("self.mw.pwmBar%02d" % x.pin_number)
slider.valueChanged.connect(self.updatePwm)
self.sliders.append(slider)
self.mw.cbPwmUnit.insertItems(0, ("Porcentaje", "Cuentas"))
self.mw.cbPwmUnit.currentIndexChanged.connect(self.changedUnits)
@pyqtSlot(int)
def updatePwm(self, value):
if self.mw.cbPwmUnit.currentIndex() is 0:
number
int(self.mw.sender().property("objectName").toString()[-2:])
logger.debug("PWM
value
pin
"+str(number)+"
set
"+str(int(value))+"%")
self.mw.board.pins[number].write(value/100)
else:
number
int(self.mw.sender().property("objectName").toString()[-2:])
logger.debug("PWM
value
pin
"+str(number)+"
set
"+str(int(value)))
self.mw.board.pins[number].write(round(value/1023, 2))
def enterTab(self):
logger.debug("Entering PWM tab")
if x.PWM_CAPABLE:
slider = eval("self.mw.pwmBar%02d" % x.pin_number)
slider.blockSignals(True)
eval("self.mw.gbPwm%02d"
x.pin_number).setEnabled(x.mode is 3)
=
to
=
to
%
Página 107
Santiago Reig Chiva
Anexos
slider.setValid(x.mode is 3)
slider.blockSignals(False)
def exitTab(self):
logger.debug("Exiting PWM tab")
@pyqtSlot(int)
def changedUnits(self, index):
if index is 0:
logger.debug("Changed PWM units to percentage")
for slider in self.sliders:
value = slider.value()
slider.setRange(0, 100, 1)
slider.setValue(round(value*100/1023))
else:
logger.debug("Changed PWM units to counts")
for slider in self.sliders:
value = slider.value()
slider.setValue(round(value*1023/100))
Página 108
Santiago Reig Chiva
Anexos
9.8. Módulo control de servomotores: servo.py
class ServoTab(object):
self.mw = mwHandle
self.sliders = list()
self.selected = [0 for x in range(0, 6)]
slider = eval("self.mw.servoBar%d" % x)
spinBox = eval("self.mw.servoBox%d" % x)
self.sliders.append(slider)
self._groupEnabled(x, False)
self._disableCheckBox(x)
slider.valueChanged.connect(spinBox.setValue)
spinBox.valueChanged[int].connect(slider.setValue)
spinBox.valueChanged[int].connect(partial(self._updateServo, x))
eval("self.mw.servoCmb%d"
x).currentIndexChanged[str].connect(partial(self._pinSelected, x))
eval("self.mw.servoCb%d"
x).stateChanged[int].connect(partial(self._activated, x))
eval("self.mw.servoBut%d"
x).clicked.connect(partial(self._zero, x-1))
self.mw.servoBut0.clicked.connect(self._allZero)
%
%
%
def enterTab(self):
logger.debug("Entering servo tab")
self._updateAvailable()
def exitTab(self):
logger.debug("Exiting servo tab")
@pyqtSlot(int)
def _zero(self, slider):
if self.sliders[slider].isValid():
self.sliders[slider].setValue(0)
Página 109
Santiago Reig Chiva
Anexos
@pyqtSlot()
def _allZero(self):
for x in xrange(0, len(self.sliders)):
self._zero(x)
@pyqtSlot(int, int)
def _activated(self, group, status):
if status:
self._groupEnabled(group, True)
pin
=
int(eval("self.mw.servoCmb%d"
group).currentText())
logger.debug("Pin "+str(pin)+" set to Servo mode")
self.selected[group-1] = pin
self.mw.board.pins[pin].mode = 4
else:
self._groupEnabled(group, False)
pin = self.selected[group-1]
logger.debug("Pin "+str(pin)+" restored to Output mode")
self.selected[group-1] = 0
self.mw.board.pins[pin].mode = 1
self.mw.board.pins[pin].write(0)
%
def _groupEnabled(self, group, state):
eval("self.mw.servoBar%d" % group).setEnabled(state)
eval("self.mw.servoBar%d" % group).setValid(state)
eval("self.mw.servoBox%d" % group).setEnabled(state)
eval("self.mw.servoBut%d" % group).setEnabled(state)
def _disableCheckBox(self, group):
eval("self.mw.servoCb%d" % group).setChecked(False)
eval("self.mw.servoCb%d" % group).setEnabled(False)
@pyqtSlot(str)
def _pinSelected(self, group, pin):
if pin:
try:
self.suitables.remove(int(pin))
eval("self.mw.servoCb%d" % group).setEnabled(True)
except ValueError:
pass
else:
eval("self.mw.servoBox%d" % group).blockSignals(True)
eval("self.mw.servoBar%d" % group).setValue(0)
eval("self.mw.servoBox%d" % group).blockSignals(False)
self._groupEnabled(group, False)
self._disableCheckBox(group)
def _updateAvailable(self):
Página 110
Santiago Reig Chiva
Anexos
self.suitables = list()
# Search for pins set as output or servo modes
if x.mode in (1, 4):
self.suitables.append(x.pin_number)
# Search for non used pins
combo = eval("self.mw.servoCmb%d" % x)
try:
number = int(combo.currentText())
if number in self.suitables:
# If pin is on available list, remove it, we are
already using it
self.suitables.remove(number)
continue
except ValueError:
# If combobox content is not a number, is empty,
ignore
pass
# Create custom list for each combobox
# Made from available pin list plus the selected pin in the
combobox
combo = eval("self.mw.servoCmb%d" % x)
items = self.suitables[:]
number = 0
try:
number = int(combo.currentText())
items.append(number)
# copy list
# no pin selected
# add pin selected
in combobox
items.sort()
except ValueError:
pass
combo.blockSignals(True)
combo.clear()
combo.addItem("")
if len(items):
for pin in items:
combo.addItem(str(pin))
if number:
combo.setCurrentIndex(items.index(number)+1)
#eval("self.mw.servoCb%d" % x).setChecked(True)
combo.blockSignals(False)
@pyqtSlot(int, int)
def _updateServo(self, group, angle):
pin = int(eval("self.mw.servoCmb%d" % group).currentText())
Página 111
Santiago Reig Chiva
logger.debug("Moved
servo
on
"+str(angle)+"º")
self.mw.board.pins[pin].write(angle)
Anexos
pin
"+str(pin)+"
to
Página 112
Santiago Reig Chiva
Anexos
9.9. Módulo control de motores DC: motor.py
class MotorTab(object):
self.mw = mwHandle
for page in xrange(0, 3):
eval("self.mw.motorBut%d"
%
page).clicked.connect(partial(self.mw.motorSw.setCurrentIndex, page))
eval("self.mw.motorSAll%d"
%
page).clicked.connect(partial(self._allZero, page))
eval("self.mw.motorBut%d"
%
page).clicked.connect(partial(self._changedPage, page))
for section in ("A", "B"):
eval("self.mw.motorStop%s%d"
%
(section,
page)).clicked.connect(partial(self._zero, section, page))
eval("self.mw.motorPer%s%d"
%
(section,
page)).valueChanged[int].connect(partial(self._updateMotor, section, page))
eval("self.mw.motorAct%s%d"
%
(section,
page)).clicked.connect(partial(self._activated, section, page))
self._groupEnabled(section, page, False)
if page is 3:
eval("self.mw.motorPwm%s%d"
%
(section,
page)).currentIndexChanged[str].connect(partial(self._pinSelected, section))
eval("self.mw.motorDir%s%d" % (section, page))
def enterTab(self):
logger.debug("Entering motor tab")
for page in xrange(0, 3):
try:
pin1 = int(eval("self.mw.motorPwm%s%d" % (section,
page)).currentText())
pin2 = int(eval("self.mw.motorDir%s%d" % (section,
state = self.mw.board.pins[pin1].mode is 3 and
self.mw.board.pins[pin2].mode is 1
except ValueError:
Página 113
Santiago Reig Chiva
state = False
page)).setEnabled(state)
Anexos
%
(section,
def exitTab(self):
logger.debug("Exiting motor tab")
@pyqtSlot(int)
def _zero(self, section, page):
if eval("self.mw.motorAct"+section+str(page)).isChecked():
eval("self.mw.motorPer"+section+str(page)).setValue(0)
@pyqtSlot()
def _allZero(self, page):
self._zero(section, page)
@pyqtSlot(str, int, bool)
def _activated(self, section, page, status):
pin
=
int(eval("self.mw.motorPwm%s%d"
%
(section,
self._groupEnabled(section, page, status)
if status:
logger.debug("Activating
motor
"+section+"
in
pin
"+str(pin))
else:
logger.debug("Deactivating
motor
"+section+"
in
pin
"+str(pin))
eval("self.mw.motorPer%s%d" % (section, page)).setValue(0)
def _groupEnabled(self, section, page, state):
eval("self.mw.motorSli%s%d"
%
eval("self.mw.motorPer%s%d"
%
eval("self.mw.motorStop%s%d"
%
(section,
(section,
(section,
@pyqtSlot(str, str)
def _pinSelected(self, section, pin):
try:
pwm = eval("self.mw.motorPwm%s2" % section).currentText()
dir = eval("self.mw.motorDir%s2" % section).currentText()
eval("self.mw.servoCb%d" % group).setEnabled(True)
except ValueError:
pass
def _updateAvailable(self):
Página 114
Santiago Reig Chiva
Anexos
self.suitableDir = list()
self.suitablePwm = list()
# Search for pins set as output or servo modes
if x.mode is 1:
self.suitableDir.append(x.pin_number)
elif x.mode is 3:
self.suitablePwm.append(x.pin_number)
# Remove used pins in active configurations of page 2
try:
pwm
=
int(eval("self.mw.motorPwm%s2"
%
section).currentText())
dir
=
int(eval("self.mw.motorDir%s2"
%
section).currentText())
if eval("self.mw.motorAct%s2" % section).isChecked():
if pwm in self.suitablePwm:
self.suitablePwm.remove(pwm)
if dir in self.suitableDir:
self.suitableDir.remove(dir)
except ValueError:
pass
# Create custom list for each combobox
for type in ("Pwm", "Dir"):
combo = eval("self.mw.motor%s%s2" % (type, section))
if
not
eval("self.mw.motorAct%s2"
%
section).isChecked():
items = eval("self.suitable%s" % type)[:]
else:
items = [int(eval("self.mw.motor%s%s2" % (type,
section)).currentText())]
combo.blockSignals(True)
combo.clear()
if len(items):
for pin in items:
combo.addItem(str(pin))
combo.blockSignals(False)
@pyqtSlot(str, int, int)
def _updateMotor(self, section, page, speed):
pin
=
int(eval("self.mw.motorDir%s%d"
pwm
=
int(eval("self.mw.motorPwm%s%d"
logger.debug("Changed
motor
"+section+"
"+str(speed)+"%")
%
(section,
%
(section,
speed
to
Página 115
Santiago Reig Chiva
Anexos
self.mw.board.pins[pin].write(1 if speed > 0 else 0)
self.mw.board.pins[pwm].write(abs(speed)/100.0)
@pyqtSlot(int)
def _changedPage(self, page):
eval("self.mw.motorBut%d" % page).setChecked(True)
for x in [y for y in range(0,3) if y is not page]:
eval("self.mw.motorBut%d" % x).setChecked(False)
if
%
x)).isChecked():
%
x)).setChecked(False)
self._activated(section, page, False)
(section,
(section,
Página 116
Santiago Reig Chiva
Anexos
9.10. Módulo secuenciador: sequencer.py
# -*- coding: utf-8 -*import logging, serial, os, sys
from PyQt4.QtGui import QDialog, QPushButton, QComboBox,
QStackedWidget, QHBoxLayout, QVBoxLayout, QWidget, QMessageBox
from PyQt4.QtCore import QTimer, pyqtSlot, QProcess
QLabel,
from pyfirmata import Board
from pyfirmata.boards import BOARDS
POSIX = False
if os.name == "posix":
import glob
POSIX = True
# Code for getting app folder
if isfrozen:
raise
determine
else:
entry = sys.path[0]
else:
else:
entry = sys.argv[0]
app
path
because
class SelectPortDlg(QDialog):
QDialog.__init__(self, parent)
logger.debug("Port selection dialog created")
statusLbl = QLabel("Programando el Arduino...")
self.connectBtn = QPushButton("&Conectar")
self.programBtn = QPushButton("&Programar")
exitBtn = QPushButton("Salir")
multiLbl = QLabel("&Selecciona la placa:")
self.portsCmb = QComboBox()
multiLbl.setBuddy(self.portsCmb)
Página 117
Santiago Reig Chiva
Anexos
self.stackedWidget = QStackedWidget()
mainWidget = QWidget()
mainLayout = QHBoxLayout()
mainLayout.addWidget(multiLbl)
mainLayout.addWidget(self.portsCmb)
mainWidget.setLayout(mainLayout)
self.stackedWidget.addWidget(mainWidget)
progWidget = QWidget()
progLayout = QHBoxLayout()
progLayout.addWidget(statusLbl)
progLayout.addStretch()
progWidget.setLayout(progLayout)
self.stackedWidget.addWidget(progWidget)
buttonLayout = QHBoxLayout()
buttonLayout.addWidget(self.connectBtn)
buttonLayout.addWidget(self.programBtn)
buttonLayout.addStretch()
buttonLayout.addWidget(exitBtn)
layout = QVBoxLayout()
layout.addWidget(self.stackedWidget)
layout.addLayout(buttonLayout)
self.setLayout(layout)
self.boards = list()
self.board = None
self.programBtn.clicked.connect(self.programBoard)
self.portsCmb.currentIndexChanged[int].connect(self.updatePorts)
self.connectBtn.clicked.connect(self.connectBoard)
exitBtn.clicked.connect(self.reject)
self.setWindowTitle(u"Iniciando comunicación")
logger.debug("Working dir: "+appdir)
@pyqtSlot()
def updatePorts(self, force=False):
# FIXME: Program button gets focus when opening QComboBox
if self.portsCmb.currentText() != "Actualizar" and not force:
return
logger.debug("Searching available serial ports")
ports = list()
if POSIX:
ports
+=
+
+
+
Página 118
Santiago Reig Chiva
Anexos
try:
s.close()
pass
logger.debug("Found %d serial port(s): %s", len(ports), ports)
if not len(ports):
ports = [""]
self.portsCmb.clear()
self.portsCmb.addItems(ports)
self.portsCmb.addItem("Actualizar")
if self.portsCmb.currentText() != "":
@pyqtSlot()
def connectBoard(self):
try:
logger.debug("Connecting
to
Arduino
board
on
port
board
=
Board(self.portsCmb.currentText(),
BOARDS['arduino'])
except ValueError, e:
logger.warning(e)
except TypeError, e:
logger.debug(e)
except serial.serialutil.SerialException, e:
logger.warning(e)
else:
logger.debug("Using
Arduino
board
on
port
"+board.sp.portstr)
self.board = board
self.accept()
@pyqtSlot()
def programBoard(self):
if
not
os.path.exists(os.path.join(appdir,
"avrdude",
"PlatexFirmata.hex")):
logger.error("Hexadecimal file not found")
QMessageBox.warning(self, u"¡Atención!", u"No se pudo
encontrar el fichero a programar")
Página 119
Santiago Reig Chiva
Anexos
return
logger.debug("Programming
Arduino
board
on
configuration
=
"avrdude",
"avrdude.conf")
hexadecimal
=
"avrdude",
"PlatexFirmata.hex")
self.program = QProcess()
#
avrdude
reference:
http://www.ladyada.net/learn/avr/avrdude.html
command = "\""+executable+"\" -q -V -C \""+configuration+"\" p atmega328p -c arduino -P "+self.portsCmb.currentText()+" -b 57600 -D -U
logger.debug("avrdude call: "+command)
self.program.finished.connect(self.programFinished)
@pyqtSlot()
def programFinished(self):
output = str(self.program.readAllStandardError())
if output.find("flash written") == -1: # avrdude: xxxx bytes
of flash written
if output.find("Expected signature") != -1: # avrdude:
Expected signature for ATMEGA328P is 1E 95 0F
error = u"La placa conectada no tiene un chip
compatible."
elif output.find("not in sync: resp=0x00") != -1: #
avrdude: stk500_getsync(): not in sync: resp=0x00
error = u"No parece que haya ninguna placa conectada
al puerto."
elif output.find("ser_send()") != -1: # ser_send(): write
error: sorry no info avail
error = u"Se produjo un error durante la comunicación
con la placa.\nAsegúrate de que está correctamente conectada."
elif output.find("ser_open()") != -1: # ser_open(): ....
error = u"El puerto no se pudo abrir.\nAsegúrate de
que ningún programa lo está usando."
else:
error = u"Se produjo un error al programar la
placa.\nComprueba el conexionado."
logger.warning("avrdude output: "+output)
logger.warning("An error ocurred: "+error)
QMessageBox.warning(self, u"¡Atención!", error)
else:
logger.debug("Programmed successfully")
Página 120
Santiago Reig Chiva
Anexos
def getBoard(self):
return self.board
Página 121
Santiago Reig Chiva
Anexos
9.11. Código para crear instalador: setup.py
# http://cx_freeze.readthedocs.org/en/latest/distutils.html#distutils
import sys, os
from cx_Freeze import setup, Executable
base = None
targetName = "platex"
includes = []
if sys.platform == "win32":
base = "Win32GUI"
targetName = "platex.exe"
includes.extend(['numpy.core.multiarray', 'serial.win32'])
Platex_Target = Executable( script = "platex.pyw",
initScript = None,
base = base,
targetName = targetName,
compress = True,
copyDependentFiles = True,
appendScriptToExe = False,
appendScriptToLibrary = False,
shortcutName = "Platex",
shortcutDir = "ProgramMenuFolder")
include_files = ['avrdude/']
build_exe_options = {"packages": [],
"includes": includes,
"excludes": [],
"include_files": include_files}
setup(
name = "Platex",
version = "0.1",
description = "Control Arduino from your computer",
options = {"build_exe": build_exe_options},
executables = [Platex_Target])
Página 122
Santiago Reig Chiva
Anexos
9.12. Script de compilación para Linux: buildlinux.sh
#!/bin/bash
asterisks ()
{
echo "*********************************************"
}
header ()
{
echo
asterisks
echo "$1"
asterisks
echo
}
remove()
{
if [ -d $1 ]; then
rm -rf $1
fi
}
create()
{
if [ ! -d $1 ]; then
mkdir -p $1
fi
}
remove_and_create()
{
remove $1
create $1
}
copy()
{
echo "COPYING [$1] TO [$2]"
cp $1 $2
}
PYQWT=5.2.0
ARDUINO=1.0
PROJECT=Platex
Página 123
Santiago Reig Chiva
Anexos
CXFREEZE=4.2.3
# Comprobar si tenemos permisos
if [ "$(id -u)" != "0" ]; then
echo "Uso: sudo $0"
exit 6
fi
#######
header \
"DO NOT RUN THIS SCRIPT ON A PRODUCTION COMPUTER
IT MAY END UP BREAKING THINGS
Press Ctrl+C to exit"
for i in {15..1}; do echo -ne "$i.." && sleep 1; done; echo
#######
#######
header "Creating build folder"
#######
remove_and_create build
cd build
#######
header "Installing libraries available in repositories"
#######
apt-get update
apt-get -y install git avrdude python-qt4 pyqt4-dev-tools python-pip
qt4-qmake g++ libqt4-dev python-sip-dev python-qt4-dev arduino-core alien rpm
pip install pyserial --upgrade
#######
header "Installing cx_Freeze $CXFREEZE"
#######
wget
--trust-server-name
http://prdownloads.sourceforge.net/cxfreeze/cx_Freeze-$CXFREEZE.tar.gz || exit 1
tar -zxvf cx_Freeze-$CXFREEZE.tar.gz
pushd cx_Freeze-$CXFREEZE
python setup.py install
popd
#######
header "Installing PyQwt $PYQWT"
#######
wget
--trust-server-name
http://prdownloads.sourceforge.net/pyqwt/PyQwt-$PYQWT.tar.gz || exit 1
tar -zxvf PyQwt-$PYQWT.tar.gz
Página 124
Santiago Reig Chiva
pushd PyQwt-$PYQWT/configure
python configure.py -Q
disable-numeric --disable-numpy
make
make install
popd
Anexos
../qwt-5.2
--qt4
--disable-numarray
--
#######
header "Downloading Arduino IDE $ARDUINO"
#######
wget http://arduino.googlecode.com/files/arduino-$ARDUINO-linux.tgz ||
exit 1
tar -zxvf arduino-$ARDUINO-linux.tgz
#######
header "Downloading and compiling $PROJECT source code"
#######
git clone https://github.com/chiva/$PROJECT.git
pushd $PROJECT
python mkpyqt.py -b -r
mkdir avrdude
pushd avrdude
cp `which avrdude` .
cp /etc/avrdude.conf .
popd
pushd firmware
pushd ${PROJECT}Firmata
make -f Makefile-linux
mv applet/${PROJECT}Firmata.hex ../../avrdude/
popd
popd
popd
#######
header "Creating distribution files"
#######
pushd $PROJECT
python setup.py bdist_rpm
pushd dist
alien -d $PROJECT-*.i386.rpm
popd
popd
#######
header "Cleaning workspace"
#######
Página 125
Santiago Reig Chiva
Anexos
mv $PROJECT/dist ../$PROJECT-dist
cd ..
remove build
rm "$0"
#######
header "Done!"
#######
Página 126
Santiago Reig Chiva
Anexos
9.13. Script de compilación para Mac: buildmac.sh
#!/bin/bash
asterisks ()
{
echo "*********************************************"
}
header ()
{
echo
asterisks
echo "$1"
asterisks
echo
}
remove()
{
if [ -d $1 ]; then
rm -rfv $1
fi
}
create()
{
if [ ! -d $1 ]; then
mkdir -p $1
fi
}
remove_and_create()
{
remove $1
create $1
}
copy()
{
echo "COPYING [$1] TO [$2]"
cp $1 $2
}
PROJECT=Platex
GCC=10.7-v2
GIT=1.7.8.3
Página 127
Santiago Reig Chiva
Anexos
PYTHON=2.7.2
QT=4.7.4
SIP=4.13.2
PYQT=4.9.1
PYQWT=5.2.0
AVRDUDE=5.11.1
ARDUINO=1.0
CXFREEZE=4.2.3
#######
header \
"DO NOT RUN THIS SCRIPT ON A PRODUCTION COMPUTER
IT MAY END UP BREAKING THINGS
RUN WITH SUDO
Press Ctrl+C to exit"
for i in {15..1}; do echo -ne "$i.." && sleep 1; done; echo
#######
#######
header "Creating build folder"
#######
remove_and_create build
cd build
#######
header "Installing GCC $GCC"
#######
curl -fLO --retry 20 https://github.com/downloads/kennethreitz/osxgcc-installer/GCC-$GCC.pkg || exit 1
installer -pkg GCC-$GCC.pkg -target "/"
#######
header "Installing Git $GIT"
#######
curl -fO --retry 20 http://git-osx-installer.googlecode.com/files/git$GIT-intel-universal-snow-leopard.dmg || exit 1
hdiutil attach git-$GIT-intel-universal-snow-leopard.dmg
installer
-pkg
/Volumes/Git\
$GIT\
Snow\
Leopard\
Intel\
Universal/git-$GIT-intel-universal-snow-leopard.pkg -target "/"
hdiutil detach /Volumes/Git\ $GIT\ Snow\ Leopard\ Intel\ Universal
#######
header "Installing Python $PYTHON"
#######
Página 128
Santiago Reig Chiva
Anexos
curl
-fO
--retry
20
http://python.org/ftp/python/$PYTHON/python$PYTHON-macosx10.6.dmg || exit 1
hdiutil attach python-$PYTHON-macosx10.6.dmg
installer -pkg /Volumes/Python\ $PYTHON/Python.mpkg -target "/"
hdiutil detach /Volumes/Python\ $PYTHON/
PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH
}"
export PATH
#######
header "Installing Qt $QT"
#######
curl
-fO
--retry
20
http://get.qt.nokia.com/qt/source/qt-macopensource-$QT.dmg || exit 1
hdiutil attach qt-mac-opensource-$QT.dmg
installer -pkg /Volumes/Qt\ $QT/Qt.mpkg -target "/"
hdiutil detach /Volumes/Qt\ $QT
#######
header "Installing SIP $SIP"
#######
curl
-fO
--retry
http://www.riverbankcomputing.co.uk/static/Downloads/sip4/sip-$SIP.tar.gz
exit 1
tar -zxvf sip-$SIP.tar.gz
pushd sip-$SIP
python configure.py
make
make install
popd
20
||
#######
header "Installing PyQt $PYQT"
#######
curl
-fO
--retry
http://www.riverbankcomputing.co.uk/static/Downloads/PyQt4/PyQt-mac-gpl$PYQT.tar.gz || exit 1
tar -zxvf PyQt-mac-gpl-$PYQT.tar.gz
pushd PyQt-mac-gpl-$PYQT
echo "yes" | python configure.py
make
make install
popd
20
#######
header "Installing PyQwt $PYQWT"
#######
Página 129
Santiago Reig Chiva
Anexos
MIN_PYQWT=`echo "$PYQWT" | cut -d. -f 1-2`
curl -fLO --retry 20 http://prdownloads.sourceforge.net/pyqwt/PyQwt$PYQWT.tar.gz || exit 1
ln /usr/bin/qmake /bin/qmake
tar -zxvf PyQwt-$PYQWT.tar.gz
pushd PyQwt-$PYQWT/configure
python configure.py -Q ../qwt-$MIN_PYQWT --qt4 --disable-numarray
--disable-numeric --disable-numpy
make
make install
popd
#######
header "Installing pySerial"
#######
easy_install pip
pip install pyserial
#######
header "Installing cx_Freeze $CXFREEZE"
#######
curl
-fLO
--retry
20
http://prdownloads.sourceforge.net/cxfreeze/cx_Freeze-$CXFREEZE.tar.gz || exit 1
tar -zxvf cx_Freeze-$CXFREEZE.tar.gz
pushd cx_Freeze-$CXFREEZE
python setup.py install
popd
#######
header "Installing avrdude $AVRDUDE"
#######
curl
-fLO
--retry
http://download.savannah.gnu.org/releases/avrdude/avrdude-$AVRDUDE.tar.gz
exit 1
tar -zxvf avrdude-$AVRDUDE.tar.gz
pushd avrdude-$AVRDUDE
./configure
make
make install
popd
20
||
#######
header "Downloading Arduino IDE $ARDUINO"
#######
Página 130
Santiago Reig Chiva
Anexos
curl
-fO
--retry
20
http://arduino.googlecode.com/files/arduino$ARDUINO-macosx.zip || exit 1
unzip arduino-$ARDUINO-macosx.zip
#######
header "Downloading and compiling $PROJECT source code"
#######
git clone https://github.com/chiva/$PROJECT.git
pushd $PROJECT
python mkpyqt.py -b -r
mkdir avrdude
pushd avrdude
cp `which avrdude` .
cp /usr/local/etc/avrdude.conf .
popd
pushd firmware
pushd ${PROJECT}Firmata
make -f Makefile-mac
mv applet/${PROJECT}Firmata.hex ../../avrdude/
popd
popd
popd
#######
header "Creating distribution files"
#######
pushd $PROJECT
python setup.py bdist_dmg
popd
#######
header "Cleaning workspace"
#######
mv $PROJECT/dist ../$PROJECT-dist
cd ..
remove build
rm "$0"
#######
header "Done!"
#######
Página 131
Santiago Reig Chiva
Anexos
10. Anexo ÍÍ: Ínstalacion del
dispositivo USB
Al ser el medio de comunicación escogido a través del Arduino y el ordenador,
el puerto serie emulado a través de USB, puede que debamos instalar los drivers
adecuados para que el sistema operativo reconozca este periférico y se pueda utilizar
con el proyecto.
En las plataformas Linux y Mac OS X se instalarán los drivers automáticamente
pasados unos segundos tras conectar la placa, por lo que no hay que realizar ninguna
acción más.
En Linux el puerto serie aparecerá listado como ‘ttyACMxx’, mientras que en
Mac OS X aparecerá como ‘tty.usbserialxxxx’.
Si por el contrario, se desea trabajar bajo una plataforma Windows, se
requieren realizar unos pasos adicionales.
El primer paso es descargar el software de Arduino, que trae consigo los
controladores necesarios para la correcta identificación de la placa por el sistema
operativo. Se puede obtener de la sección ‘Downloads’ de la página oficial de Arduino
(www.arduino.cc), archivo que deberá descomprimirse para permitir el acceso a su
contenido.
Al realizar la conexión de la placa de interfaz Arduino al ordenador por primera
vez, aparecerá el siguiente aviso en la barra de tareas, indicando que se están
buscando los drivers adecuados.
Ilustración 35 | Nuevo hardware encontrado
Página 132
Santiago Reig Chiva
Anexos
Transcurridos unos segundos, nos aparecerá una nueva ventana para
seleccionar la localización driver manualmente, ya que el asistente no pudo
encontrarlos por si mismo. Hacemos clic en 'Buscar software de controlador en el
equipo' para continuar con el proceso de instalación.
Ilustración 36 | Selección de método de búsqueda alternativa
Le indicamos la ubicación donde están los drivers de Arduino, que será la
carpeta 'drivers' dentro de la carpeta del software de Arduino que nos hemos
descargado anteriormente. Es importante que la opción de buscar en subcarpetas esté
activada. Hacemos clic en 'Siguiente' para que inicie la búsqueda.
Página 133
Santiago Reig Chiva
Anexos
Ilustración 37 | Ubicación donde buscar los controladores
El asistente comprobará si existen los drivers adecuados para el Arduino dentro
de las carpetas indicadas.
Página 134
Santiago Reig Chiva
Anexos
Ilustración 38 | Instalando los controladores
Puede que durante el proceso se te pida autorizar a Windows el instalar unos
drivers no firmados, selecciona la segunda opción para poder continuar con la
instalación. Este aviso solo sale con las placas de la última generación, por lo que es
posible que no te aparezca.
Ilustración 39 | Los controladores no están firmados
La placa Arduino ya está lista para ser usada con Platex.
Página 135
Santiago Reig Chiva
Anexos
Ilustración 40 | El controlador se instaló correctamente
El puerto serie aparecerá listado como cualquier otro, siguiendo la
nomenclatura de ‘COMxx’.
Página 136
Santiago Reig Chiva
Anexos
11. Anexo ÍÍÍ: Manual de usuario
de Platex
11.1. Instalación
Debido a que los usuarios a los que va dirigidos el proyecto, probablemente no
dispongan de conocimientos avanzados sobre Python, sus librerías y la compatibilidad
con los principales sistemas operativos, se ha decidido crear una serie de instaladores
para la mayoría de los sistemas operativos que un usuario normal use.
El instalador posee los ficheros del proyecto, las librerías de las que éste hace
uso y el intérprete de Python sobre el que se haya creado el instalador, por lo que para
el usuario, no tiene diferencia alguna la instalación de este software a otros muchos de
los que hayan pasado por sus manos, dejando todo listo para su uso y sin requisitos
previos de software algunos.
11.1.1. Microsoft Windows
El desarrollo del programa fue realizado sobre este sistema operativo,
concretamente sobre Windows 7, por lo que es el que se recomienda para disfrutar de
la mejor experiencia de usuario posible. La compatibilidad del programa sobre
Windows XP también fue tenida en cuenta, añadiendo los ficheros necesarios para la
correcta ejecución del proyecto sobre dicho sistema operativo.
El instalador disponible para la plataforma Windows es compatible tanto con
XP, como con Vista y 7 (y probablemente con las siguientes versiones mientras se
mantenga la interfaz).
Al abrir el instalador, tras configurarse, nos mostrará la ruta por defecto para la
instalación. Se aconseja dejar esta ruta por defecto. La instalación requiere de
permisos de administrador, para realizar las modificaciones necesarias al sistema.
Página 137
Santiago Reig Chiva
Anexos
Ilustración 41 | Ruta de instalación por defecto
Una vez iniciada la instalación, nos aparecerá la ventana pidiendo permisos de
administrador para continuar con la instalación.
Ilustración 42 | Aviso de modificación del equipo
Una vez finalizada la instalación y cerrado el asistente, podremos entrar a la
aplicación a través del acceso directo creado en el menú de inicio.
Página 138
Santiago Reig Chiva
Anexos
11.1.2. Linux Ubuntu
Las pruebas de compatibilidad y el paquete de instalación fueron creados sobre
Linux Ubuntu 11.10, asegurando, como mínimo, la completa funcionalidad del
proyecto bajo esta versión. Aunque según las pruebas realizadas también se puede
realizar la instalación en Linux Ubuntu 12.04 sin problema alguno.
También se han incluido los paquetes de instalación para otras distribuciones,
aunque no se garantiza su funcionamiento debido a la gran diversidad de
configuraciones que pueden existir.
Para instalar el proyecto en Linux Ubuntu 11.10, se deberá utilizar el paquete
de instalación con la extensión de archivo ‘.deb’. Una vez se disponga de este archivo
en el sistema, se ejecutará haciendo doble clic sobre él, abriendo el ‘Centro de
Software de Ubuntu’ que asistirá la instalación.
Ilustración 43 | Centro de Software de Ubuntu
Para iniciar la instalación se pinchará sobre ‘Instalar’, que ejecutará la
instalación del paquete en segundo plano.
Antes de iniciar la instalación se nos requerirá dar permisos de administrador,
para que así el instalador pueda realizar todas las tareas satisfactoriamente.
Página 139
Santiago Reig Chiva
Anexos
Ilustración 44 | Se proporcionan los permisos de administrador
Una vez se haya instalado correctamente el software, se nos darán las
instrucciones de como ejecutar el programa instalado.
Ilustración 45 | Instalación finalizada correctamente
Como se puede observar, se debe ejecutar ‘platex’ en la terminal de Ubuntu.
Si al ejecutar el programa nos aparece una ventana de error, que nos avisa de
que ha sido imposible abrir el puerto serie, significa que no tenemos los permisos
suficientes par ello, por lo que deberemos añadir nuestro usuario al grupo adecuado
para poder realizar esta operación.
Página 140
Santiago Reig Chiva
Anexos
Ilustración 46 | Permisos insuficientes
Para solucionar este problema se deberá ejecutar en una terminal:
$ usermod –a –G dialout USUARIO
Donde USUARIO es el nombre del usuario con el que se haya iniciado sesión en
el sistema. Para que se hagan efectivos los cambios, se deberá cerrar la sesión y volver
a entrar.
11.1.3. Mac OS X
Durante el desarrollo del proyecto, la compatibilidad de la librería encargada de
realizar el empaquetamiento e instalador no estaba completada, por lo que ha sido
imposible realizar el paquete de instalación de este proyecto para la plataforma Mac.
Una vez se solucione este problema, la instalación se realizará de la misma
forma que cualquier otra aplicación.
Como solución para correr el software bajo este sistema operativo, se deberá
realizar con la ayuda del script de compilación del proyecto para Mac, que aunque está
preparado para no interferir con el normal funcionamiento del ordenador en su uso
diario, no es recomendable realizarlo sin conocimiento del funcionamiento. La guía
para la utilización de este script viene adjuntada en el siguiente anexo.
Página 141
Santiago Reig Chiva
Anexos
11.2. Ventana inicial
El resto del manual de uso, al ser un programa multiplataforma que se muestra
y funciona de forma similar en todas ellas, sólo se realizará la explicación en una de
ellas. En esta explicación se utilizará la ejecución en Windows, al haber sido la
plataforma donde se ha realizado la mayor parte del desarrollo.
Al ejecutar el programa se nos mostrará una ventana con la que podemos
realizar varias operaciones.
Ilustración 47 | Ventana inicial
Primero deberemos seleccionar el puerto serie al que está conectada la placa
Arduino que se desea utilizar con el programa. Si todavía no está conectada, se puede
realizar la conexión y luego repetir la búsqueda de puertos serie activos desplegando la
lista y seleccionando Actualizar. Si no aparece la placa en la lista, se deberá comprobar
que los drivers estén correctamente instalados y el puerto serie aparezca en los
recursos del sistema.
Una vez seleccionado el puerto serie, podemos realizar tres operaciones:

Conectar: se inicia la comunicación con la placa que se haya indicado y si
está con el firmware adecuado y no hay problemas de comunicación, se
podrá empezar a usar el programa en todo su potencial.

Programar: las placas Arduino son reprogramables, por lo que no siempre
tendrán el firmware adecuado para realizar la comunicación con el
software. Por ello se da la opción de descargar el firmware adecuado a la
placa con un único clic de ratón.
Página 142
Santiago Reig Chiva

Anexos
Salir: se cierra el programa, para esta opción no es necesario tener
seleccionado un puerto serie.
Para poder acceder a la ventana principal del programa deberemos
conectarnos a la placa una vez tenga el firmware adecuado.
11.3. Ventana principal
En la ventana principal del programa podremos ver los distintos módulos de los
que se compone éste. Cada módulo corresponde a una pestaña y en el momento de la
realización de este documento, existen los siete siguientes:

Configuración

Digital

Analógico

PWM

Servo

Motores

Secuenciador
El programa se abrirá por defecto con el módulo de configuración en primer
plano, ya que no es posible realizar ninguna acción sin primero configurar alguno de
los pines.
A continuación se explicarán el motivo por el que se han incluido y su
funcionamiento.
Página 143
Santiago Reig Chiva
Anexos
11.3.1. Configuración
Este módulo nos muestra una representación del Arduino en pantalla,
pudiendo seleccionar individualmente en cada pin de la placa el modo en el que
queremos hacerlo funcionar. Cada modo tiene un color asignado, que facilitará la
comprobación del modo seleccionado por el usuario.
Ilustración 48 | Módulo de configuración
Existen los siguientes modos de funcionamiento:

None: el pin no tiene ninguna función, se configura como entrada y se
desactivan las resistencias internas de pull-up.

Input: el pin se utilizará para realizar lecturas digitales (1 ó 0).

Output: el pin se utilizará como salida con niveles lógicos (1 ó 0). Bajo este
modo se podrá hacer también control de servomotores de radiocontrol.
Página 144
Santiago Reig Chiva
Anexos

PWM: el pin se utilizará como salida de ancho de pulso modulado, útil para
reguladores, dimmers y otros elementos que necesiten una forma de
control más precisa que el todo o nada de la lógica digital.

Analógico: el pin se utilizará como entrada analógica con una resolución de
lectura de 10 bits.
Para cambiar el modo de un pin se deberá pinchar sobre el que queremos
realizar la operación, desplegándose una lista con todos los posibles modos de
funcionamiento compatibles con el pin seleccionado, para realizar el cambio sólo se
deberá seleccionar de entre los modos disponibles. Los cambios de modo realizados
son aplicados instantáneamente tras realizar la selección.
Ilustración 49 | Lista de modos
Ilustración 50 | Algunos pines configurados
Los pines analógicos también pueden ser usados tanto como entradas como salidas
digitales, por lo que se ha dado la opción de configurarlos como tales en el software.
Página 145
Santiago Reig Chiva
Anexos
Los pines 0 y 1 no están disponibles para su uso ya que se utilizan para realizar
la comunicación entre el software y la propia placa, son los encargados de realizar la
comunicación por el puerto serie.
11.3.2. Digital
Este módulo también muestra la representación de un Arduino en pantalla y
sólo se muestran los pines que se hayan configurado anteriormente como entrada o
salidas.
Ilustración 51 | Módulo digital
Las entradas vienen designadas por un círculo verde oscuro encima del pin,
intentando asemejarse a un led verde, y de color más claro al detectar un nivel alto en
él.
Las salidas se muestran como un cuadrado, similar a los existentes en el
módulo de configuración, de un color azul grisáceo cuando la salida esté desactivada y
Página 146
Santiago Reig Chiva
Anexos
un amarillo dorado cuando se haya activado. Para cambiar de estado la salida sólo hay
que pinchar con el ratón encima de él.
Ilustración 52 | Estado de activación
Si la entrada parpadea rápidamente, probablemente signifique que el pin
correspondiente esta al aire leyendo ruido, sin ninguna tensión aplicada.
11.3.3. Analógico
La finalidad de éste módulo es la de mostrar la tensión existente en los pines
analógicos que se hayan configurado como tales.
Página 147
Santiago Reig Chiva
Anexos
Ilustración 53 | Módulo analógico
El valor de la tensión analógica en el pin se muestra en forma de texto y
gráficamente en forma de barra, de forma individual de cada pin. También se muestra
en una gráfica a través del tiempo de forma que se puede ver la evolución de la
tensión. Esta gráfica es común a todos los pines, por lo que se puede realizar
comparaciones de tensiones de forma sencilla y rápida y mediante los selectores en
cada uno de los pines, se puede indicar si se desea o no que se grafique la tensión de
dicho pin en la gráfica general. Cada pin analógico tiene asignado un color, por lo que
es fácil relacionar el pin con la tensión que se dibuja en la gráfica común a todos ellos.
Página 148
Santiago Reig Chiva
Anexos
Ilustración 54 | Traza analógica oculta
Hay que tener en cuenta que el voltaje se muestra mediante una simple regla
de 3 desde el valor en cuentas, es decir, de 0 a 1023 se convierte de 0 a 5V. Esto
técnica de conversión, aunque sencilla, tiene un problema, ya que las cuentas son el
valor del voltaje con respecto a la tensión de alimentación, por lo que una lectura de
1023, no es la misma a 3V que a 5V, representando 3V y 5V respectivamente. En el
software se ha supuesto que se utiliza el Arduino tal y como es recomendado, a 5V,
aunque pueden existir pequeñas desviaciones de la tensión del orden de unos pocos
cientos de milivoltios, que se suman a los errores de conversión de los ADC del
Arduino.
11.3.4. PWM
Con este módulo podremos sacar una señal de PWM en los pines que tengan
capacidad para ello, los cuales tienen el texto PWM junto a ellos en el módulo de
configuración.
Página 149
Santiago Reig Chiva
Anexos
Los deslizadores solo se activarán si el pin correspondiente está configurado
como PWM y permiten modificar el ancho de pulso tanto en porcentaje (0÷100%)
como en cuentas de 8 bits (0÷256). Siendo el 0% una salida continua a nivel bajo y al
100% una salida a nivel alto, que en este caso serían los 5V de alimentación.
Ilustración 55 | Módulo PWM
11.3.5. Servo
Este módulo está creado para controlar la posición de servomotores de hobby,
que pueden ser controlados para moverse a una determinada posición en grados de 0°
a 180°.
Página 150
Santiago Reig Chiva
Anexos
Ilustración 56 | Servomotor de hobby
Se pueden controlar hasta un máximo de seis servos simultáneamente,
pudiendo activarse, desactivarse y cambiar la asignación de pines en cualquier
momento.
Ilustración 57 | Módulo servos
Página 151
Santiago Reig Chiva
Anexos
En la lista podremos seleccionar uno de los pines que estén configurados como
entradas (Input) y al seleccionar Activar se configurará en modo servo, por lo que
estará listo para controlar dichos motores.
Ilustración 58 | Activación de servos
El ángulo de giro de los servos puede ser controlado tanto con la barra
deslizadora como introduciendo manualmente el valor en grados en la caja numérica.
Se han incluido botones para devolver al origen los motores tanto individualmente
como de forma general a todos ellos.
Si se desea volver a utilizar ese pin para otras funciones, se deberá desmarcar la
casilla de Activar, volviendo a configurarse el pin como entrada, listo para poder ser
usado en otros módulos.
11.3.6. Motores
Con este módulo se podrá realizar el control de motores de continua, tanto
pequeños como grandes; la limitación vendrá dada por el hardware, en concreto, por
el límite tanto de tensión como de intensidad del driver de motores utilizado.
Página 152
Santiago Reig Chiva
Anexos
Ilustración 59 | Módulo motores
Por defecto se incluyen la configuración para las shields de control de motores
oficiales de Arduino, que son la Motor Shield 3.0 y la Motor Shield R3. La shield de
Sparkfun Ardumoto, que aunque no es oficial, es compatible con la configuración de la
Motor Shield R3, ya que está diseñada con el mismo hardware y la misma asignación
de pines.
Página 153
Santiago Reig Chiva
Anexos
Ilustración 60 | Motor Shield 3.0
Ilustración 61 | Motor Shield R3
Tabla 20 | Asignación de pines
Motor Shield 3.0
Motor Shield R3
Canal A
Canal B
Canal A
Canal B
Dirección
12
13
12
13
Velocidad
10
11
3
11
También se incluye la posibilidad de definir manualmente los pines en el modo
Personalizado para poder utilizar placas creadas por otros fabricantes o por el mismo
usuario. El control está pensado para los drivers L293D y L298 de Texas Instruments,
pero también podría utilizarse con otros drivers de otros fabricantes que tengan una
interfaz de control similar o con un puente en H discreto con la circuitería de interfaz
adecuada.
Para comenzar el control se deberá activar cada canal de la placa marcando la
casilla de Activar y para empezar a mover el motor, se podrá deslizar la barra a la
izquierda para moverlo en un sentido o hacia la derecha para moverlo en el contrario
(el control de sentido de giro se hace automáticamente). También se podrá realizar el
control introduciendo el valor en porcentaje de velocidad del motor de 0 a 100 y con el
signo adecuado para el sentido de giro que se desee. En este módulo también se han
incluido botones de paro tanto individuales para cada canal, como globales.
11.3.7. Secuenciador
Se podría decir que este es el módulo más complejo, completo y útil de todos
los incluidos hasta el momento, ya que contiene una parte de casi todos los módulos,
permitiendo además preparar una secuencia de pasos en los que se realizarán las
acciones indicadas por el usuario.
Página 154
Santiago Reig Chiva
Anexos
Ilustración 62 | Módulo secuenciador
Debido al limitado espacio existente en pantalla, se han limitado las opciones
para que la usabilidad del mismo no se reduzca considerablemente.
Se han incluido en este módulo, seis salidas digitales, tres pines para controlar
servos y 3 salidas de PWM. Los pines a los que están asignados cada función son fijos y
no modificables, estando indicados por el número encima de cada control. Los
controles solo estarán activos si el pin al que están asignados está configurado de
forma que sea compatible con la función que desempeñan en este módulo.
La utilización de los controles es similar a la que se encuentra en cada uno de
los módulos por separado, por lo que no es necesaria repetir su explicación, siendo
más importante centrarse en los nuevos y específicos encontrados sólo en este
módulo.
Página 155
Santiago Reig Chiva
Anexos
Ilustración 63 | Controles específicos
La primera caja numérica controla los pasos del secuenciador, los cambios que
se realicen en los controles se aplicarán al paso que aparezca en esta caja. Al cambiar
el número de paso se guardaran los valores de los controles y se cargarán los del paso
que se haya elegido. Por defecto se inicia con un solo paso y se podrán añadir más
como se explica más adelante.
En la segunda caja, se podrá indicar el tiempo en milisegundos durante que
estará activo el paso actual. Se puede introducir los valores manualmente o usando las
flechas en el borde derecho y puede tomar valores desde 1 ms a 10000 ms (10
segundos).
Los botones con los símbolos + y – sirven para añadir un paso a continuación
del actual o para eliminar el paso actual, respectivamente.
El botón Iniciar, comenzará con la ejecución en secuencia de los pasos,
realizando las acciones que se hayan indicado en cada uno de ellos y durante el tiempo
establecido. Una vez iniciada la secuencia no es posible pararla ni realizar ninguna otra
acción en el programa, hasta que no se haya finalizado el último paso.
Página 156
Santiago Reig Chiva
Anexos
12. Anexo ÍV: Compilacion y
distribucion del software
Al estar todo el software del proyecto licenciado bajo GPL, el acceso y la
redistribución del código fuente de este proyecto es libre, por lo que no sería extraño
que se diera el caso de que una persona necesitara rehacer el instalador desde el
código fuente tras haber realizado una serie de cambios, ya sea para mejorar, adaptar
o cualquier otra razón. Para ello se indicarán los pasos a realizar en cada plataforma
con los que pasar del código fuente al instalador, listo para distribuir e instalar de
manera sencilla para el usuario final.
El código fuente al completo puede encontrarse en el CD que acompaña este
documento, aunque las herramientas de creación del instalador están preparadas para
obtenerlo desde la copia que se mantiene actualizada en un servidor de control de
versiones: https://github.com/chiva/Platex
12.1. Windows
Debido al bajo número de herramientas de automatización de tareas existentes
o su alta dificultad de uso o poca difusión, se ha optado por realizar una parte de ella
manualmente.
La primera tarea a realizar será instalar una versión del intérprete de Python, el
proyecto se ha desarrollado usando la versión 2.7.2, por lo que es la que se
recomienda instalar, también hay una alta probabilidad de que sea compatible con las
siguientes revisiones de esta versión, tales como 2.7.3 (que ya está lanzada y es
compatible), la futura 2.7.4, etc. mientras que la subversión siga siendo la 2.7. Como
también se deben instalar otras librerías necesarias para el proyecto y existe un
instalador de Python enfocado desarrollo por científicos e ingenieros con una gran
cantidad de librerías numéricas y análisis y visualización de datos llamada Python(x,y),
se recomienda el uso de esta, ya que contiene todas las librerías que se necesitarán y
permite instalarlas de una manera sencilla y cómoda, evitando así realizar compilación
Página 157
Santiago Reig Chiva
Anexos
alguna. Para ello se realizará la descarga del paquete de instalación desde la sección de
descargas de su página web.
Una vez descargado el paquete se procederá a su instalación siguiendo el
asistente, cuando se alcance la sección de selección de componentes se deberán
seleccionar como mínimo los siguientes:

Python 2.7.X

Python
o PyQt
o PyQwt
o PySerial
Obtener el código fuente, del CD que acompaña a este documento
(probablemente no sea la última versión existente a la fecha de lectura de este
documento), del repositorio (puede contener código inestable) o de la sección de
descargas de la página del proyecto (recomendado, sería descargar el fichero con
extensión .tar.gz). Este paso no sería necesario si ya se tiene o se han realizado
modificaciones a éste.
Seguidamente se procederá a convertir los ficheros de Qt a PyQt, ejecutando
en una terminal de comandos dentro de la carpeta del código fuente:
> mkpyqt.py -b -r
Se realizará la descarga del paquete de software de Arduino, que se encuentra
en la sección de descargas de su página oficial. Una vez descargado se descomprimirá
para poder acceder a su contenido. Este paquete de software nos permitirá realizar la
compilación del firmware de Firmata, para poder luego descargarlo en una placa
Arduino con el programador que lleva incorporado.
Se deberá crear una carpeta nueva llamada avrdude, donde se copiarán los
ficheros avrdude.exe y avrdude.conf, existentes en la descarga de Arduino que hemos
descargado anteriormente. Para aumentar la fiabilidad del programador (avrdude) en
Página 158
Santiago Reig Chiva
Anexos
todos los ordenadores y hacerlo compatible con Windows XP, se deberá añadir
también el fichero libusb0.dll, también existente en la descarga de Arduino.
Para crear el firmware de la placa Arduino es necesario compilarlo desde el
software, por lo que abriremos el fichero firmware/PlatexFirmata/PlatexFIrmata.ino,
existente en la carpeta del código fuente. Arduino almacena los programas compilados
en una carpeta temporal, por lo que se deberá conocer su localización, para ello se
activará la salida del compilador en la ventana de depuración. Esta opción se activa en
la ventana de preferencias, accesible en el menú de herramientas Archivo>Preferencias.
Ilustración 64 | Activar salida del compilador
Ahora se compilará el código pulsando el botón de verificar.
Ilustración 65 | Botón de verificar código
Una vez terminada la compilación, aparecerá la localización del fichero .hex en
la parte inferior del programa. Hay que tener en cuenta que es posible que la ruta pase
por carpetas ocultas, por lo que se deberá activar la visibilidad de éstas en la
configuración de Windows.
Página 159
Santiago Reig Chiva
Anexos
Ilustración 66 | Localización del firmware
El archivo PlatexFirmata.cpp.hex resultante, se deberá copiar en la carpeta
avrdude con nombre PlatexFirmata.hex.
Finalmente se creará el instalador:
> python setup.py bdist_rpm
Una vez finalizado el proceso, dentro de la carpeta del código fuente, aparecerá
una nueva carpeta llamada dist, donde estará el instalador con extensión .msi listo
para usar y distribuir.
12.2. Linux
La creación del instalador en Linux está totalmente automatizada, por lo que
para iniciar la creación del instalador sólo es necesario ejecutar la siguiente línea en
una terminal:
$ sudo bash -c "wget https://raw.github.com/gist/1427486/buildlinux.sh && bash build-linux.sh"
Página 160
Santiago Reig Chiva
Anexos
Ilustración 67 | Comando en una terminal de Linux Ubuntu
Durante el proceso, se va mostrando la salida de los comandos que se van
ejecutando, apareciendo al finalizar la tarea Done!, cuando aparecerá la carpeta
Platex-dist, donde dentro de ella aparecerán los instaladores .deb y .rpm para los
distintas distribuciones de Linux. Hay que tener en cuenta que las librerías cambian de
una distribución Linux a otra, es probable que el instalador no sea compatible, por lo
que habría que crearlo en la propia distribución sobre la que se va a usar para asegurar
totalmente su compatibilidad.
El script se va actualizando para mantener al día las versiones de los paquetes a
descargar, ya que las versiones antiguas se suelen borrar y no son accesibles para la
descarga y suelen aparecer nuevas versiones con cierta asiduidad, por lo que es
posible que el script falle al descargar alguna de las librerías, debiendo fijarse en cual
ha sido y comprobar la versión que se ha intentado bajar con la que aparece en la
página oficial de la librería, si es distinta se deberá actualizar el script con dicha versión
en las definiciones al principio de éste y ejecutando de nuevo el script como se indica a
más adelante.
El comando anterior, sirve para realizar el instalador con el código original, si se
desea crear el instalador con un código que haya sido modificado por otra persona, se
deberá descargar manualmente el archivo build-linux.sh y modificar las rutas para
tomar la que se desea. Una vez realizado esto se ejecutará el script:
$ sudo bash build-linux.sh
El proceso que realiza el script de creación del instalador es el siguiente:

Se crea la carpeta temporal build donde guardar los ficheros necesarios en
el proceso.
Página 161
Santiago Reig Chiva
Anexos

Se instalan y actualizan las librerías existentes en los repositorios.

Se descargan, compilan e instalan las librerías no existentes en los
repositorios.

Se descargar el IDE de Arduino.

Se compila el firmware para la placa Arduino.

Se descarga y compila el código fuente del proyecto.

Se crean los archivos de distribución (instaladores).

Se borra la carpeta temporal y el propio script.
El script de creación del instalador se recomienda ejecutarlo en un entorno de
desarrollo para evitar problemas tanto cara al script como para el usuario al modificar
e instalar nuevos paquetes de software. De todas maneras, el script está pensado para
minimizar su impacto, manteniendo la configuración del entorno intacta.
12.3. Mac OS
El script para crear el instalador en Mac OS es muy similar al de Linux, debido a
su similar naturaleza, aunque como es lógico difiere bastante en algunos puntos.
La creación del script en Mac OS también está completamente automatizada,
por lo que para iniciar la creación del instalador sólo es necesario ejecutar la siguiente
línea en una terminal:
$ sudo bash -c "curl -O
https://raw.github.com/gist/1427486/build-mac.sh && bash buildmac.sh"
Página 162
Santiago Reig Chiva
Anexos
Ilustración 68 | Comando en una terminal de Mac OS X Lion
Durante el proceso, se va mostrando la salida de los comandos que se van
ejecutando, apareciendo al finalizar la tarea Done!, cuando aparecerá la carpeta
Platex-dist, donde dentro de ella aparecerá el instalador .dmg. El script sólo está
preparado para crear instaladores para ordenadores Mac con arquitectura Intel.
La compatibilidad del instalador con las distintas versiones de Mac es probable
que sea alta, ya que el instalador contiene dentro de él todas las librerías que necesita
el software para funcionar, dependiendo de la compatibilidad de las propias librerías.
El script se va actualizando para mantener al día las versiones de los paquetes a
descargar, ya que las versiones antiguas se suelen borrar y no son accesibles para la
descarga y suelen aparecer nuevas versiones con cierta asiduidad, por lo que es
posible que el script falle al descargar alguna de las librerías, debiendo fijarse en cual
ha sido y comprobar la versión que se ha intentado bajar con la que aparece en la
página oficial de la librería, si es distinta se deberá actualizar el script con dicha versión
en las definiciones al principio de éste y ejecutando de nuevo el script como se indica a
más adelante.
El comando anterior, sirve para realizar el instalador con el código original, si se
desea crear el instalador con un código que haya sido modificado por otra persona, se
deberá descargar manualmente el archivo build-mac.sh y modificar las rutas para
tomar la que se desea. Una vez realizado esto se ejecutará el script:
$ sudo bash build-mac.sh
En el momento de la realización del documento, la compatibilidad del software
de creación del instalador con Mac OS estaba rota, por lo que el último paso de
creación del script dará error, pero se ha dejado para que cuando se solucione el
Página 163
Santiago Reig Chiva
Anexos
problema funcione de manera correcta. Aunque el script falle en ese punto se podrá
ejecutar el programa, ya que todas las librerías están ya instaladas, para ello y para
ejecutar el programa desde la línea de comandos, habrá que ejecutar la siguiente línea
dentro de la carpeta build/Platex que existirá en la carpeta donde ejecutaste el
script:
$
/Library/Frameworks/Python.framework/Versions/Current/bin/python
platex.pyw
El proceso que realiza el script de creación del instalador es el siguiente:

Se crea la carpeta temporal build donde guardar los ficheros necesarios
en el proceso.

Se descargan, compilan e instalan las librerías no existentes en los
repositorios.

Se descargar el IDE de Arduino.

Se compila el firmware para la placa Arduino.

Se descarga y compila el código fuente del proyecto.

Se crean los archivos de distribución (instaladores).

Se borra la carpeta temporal y el propio script.
Página 164
PLIEGO DE CONDICIONES
DOCUMENTO Nº 3
Santiago Reig Chiva
Pliego de condiciones
Índice del pliego de condiciones
13.
Introducción al pliego de condiciones .................................................... 169
14.
Condiciones generales ............................................................................ 169
15.
Normas, leyes y reglamentos ................................................................. 170
16.
Condiciones facultativas ......................................................................... 172
16.1.
Dirección ............................................................................................. 172
16.2.
Libro de órdenes ................................................................................. 173
17.
Condiciones de ejecución y montaje ...................................................... 173
17.1.
Condiciones de fabricación del circuito impreso ................................ 173
17.2.
Pruebas y ensayos del montaje de la placa ........................................ 173
17.2.1. Prueba de alimentación ................................................................. 174
17.2.2. Prueba de la placa .......................................................................... 174
17.2.3. Conexionado de los circuitos ......................................................... 175
17.3.
Instalación y uso de las aplicaciones .................................................. 175
17.4.
Conservación....................................................................................... 176
17.5.
Funcionamiento normal del equipo ................................................... 176
18.
Condiciones de materiales y equipo ...................................................... 176
18.1.
Condiciones técnicas de los materiales .............................................. 176
18.2.
Condiciones técnicas del material informático .................................. 177
Página 166
Santiago Reig Chiva
18.3.
Condiciones técnicas de los circuitos impresos .................................. 178
18.4.
Condiciones técnicas de los elementos pasivos ................................. 179
19.
Condiciones económicas ........................................................................ 179
19.1.
Errores en el proyecto ........................................................................ 179
19.2.
Jornadas y salarios .............................................................................. 179
19.3.
Liquidación .......................................................................................... 180
20.
Disposición final ...................................................................................... 181
Página 167
Santiago Reig Chiva
Ilustración 69 | Localización del ejemplo Blink ................................................ 175
Ilustración 70 | Led L ........................................................................................ 175
Página 168
Santiago Reig Chiva
13. Íntroduccion al pliego de
condiciones
Las características y la descripción del diseño del proyecto “Plataforma de
experimentación para prototipado de diseños mediante Arduino”, los componentes
que intervienen, el cableado y conexionado eléctrico y control del funcionamiento del
mismo se detallan en el documento de la memoria y en los correspondientes planos
del documento.
En este documento se exponen todas las condiciones técnicas de montaje,
especificaciones a cumplir por los elementos y materiales normalizados y comerciales
que se deben considerar a la hora de llevar a cabo la realización del proyecto.
En caso de no realizarse según las condiciones tal y como se presentan en este
documento, el proyectista no se responsabilizará de los posibles fallos y averías
propios del funcionamiento, repercutiéndose todo el peso del problema sobre terceras
personas.
Todas las modificaciones de las que pueda ser susceptible el proyecto, deberán
ser aprobadas por el ingeniero o proyectista.
14.
Condiciones generales
La realización del presente proyecto titulado “Plataforma de experimentación
para prototipado de diseños mediante Arduino”, se enmarca bajo la designación del
proyecto final de carrera, y tiene como propósito terminar con éxito los estudios de
Ingeniería Técnica Industrial en la especialidad de Electrónica.
El autor del proyecto ha cursado los estudios en la Universidad de La Rioja,
cumpliendo en su elaboración con las directrices especificadas por dicho centro, en la
normativa del proyecto de fin de carrera, aprobada por el Consejo de Gobierno el 15
de abril de 2005.
Página 169
Santiago Reig Chiva
Este proyecto se ajusta en su desarrollo a los reglamentos y disposiciones
electrónicas vigentes.
Atendiendo a esto, una vez se haya aprobado por el Ministerio de Industria,
tendrá carácter de obligado cumplimiento.
Una vez realizado el proyecto, se podrán realizar diversas modificaciones
siempre bajo la supervisión del ingeniero o proyectista.
En caso de efectuarse alguna modificación, el correspondiente proyecto
modificado se considera como parte integrante del proyecto definitivo y como tal,
sujeto a las condiciones y especificaciones citadas y aprobadas por el Ministerio.
La empresa adjudicataria suscribirá contrato ante notario donde se hará
constar, a parte de términos legales obligatorios, plazos de entrega y la conformidad
con la sanción cuyo incumplimiento pueda acarrear consigo.
15.
Normas, leyes y reglamentos
La realización del proyecto se regirá por la Ordenanza General de Seguridad e
Higiene en el Trabajo del 7 de abril de 1970 y posteriores revisiones.
Así mismo, se regirá por el Reglamento Electrotécnico de Baja Tensión, en el
que se tendrá en cuenta las siguientes normativas:

M.I. B.T.029, la cual se refiere a instalaciones de pequeñas tensiones,
menores de 50 voltios.

M.I. B.T.031, la cual se refiere a las condiciones generales de
instalación, de utilización, así como de los requisitos a cumplir a la hora
del diseño.
El proyecto cumple también con las siguientes normativas DIN y UNE:
Página 170
Santiago Reig Chiva

Los materiales que pueden ser utilizados para la realización de placas de
circuito impreso UNE 20-621-85/3.

Los espesores de los materiales con recubrimiento metálico y sus
tolerancias especificadas en la norma UNE 20-621-84/3.

La norma UNE 20552 especifica las tolerancias sobre el espesor total en
la zona de contactos.

En cuanto a la anchura de las pistas, según la intensidad que circule por
el material conductor, se referirá a la norma UNE 20-621.

Los diámetros de los taladros están especificados en la norma UNE 20621-84/3.

La norma UNE 20-612/2 recoge varios tipos de ensayos que pueden
realizarse y los materiales, como pueden ser los ensayos de espesor,
adherencia, porosidad, etc.

En las distancias entre taladros para la colocación de componentes, se
seguirá lo indicado en la norma UNE 20-524/1, UNE 20-524/2 y UNE 20524/3.

Reglas de seguridad para los aparatos electrónicos de norma UNE 20514-82.

DIN 40801, referente a circuitos impresos, fundamentos, orificios y
espesores.

DIN 40803, referente a circuitos impresos, placas y documentación.

DIN 40804, referente a circuitos impresos, conceptos.

DIN41494, referente a las formas de construcción para dispositivos
electrónicos.
Página 171
Santiago Reig Chiva

Reglas para el diseño y utilización de placas de circuito impresas UNE
20-621-3.

Especificación para la realización de placas de simple o doble cara con
agujeros no metalizados y metalizados UNE 20-621-4 y UNE 20-621-5.

Especificación para las placas impresas multicapas UNE 20-621-6.

UNE 20902 que hace referencia a la técnica de circuitos impresos,
terminología.

UNE-EN 60249 en la cual se citan los materiales base para circuitos
impresos.
Este proyecto debido a sus características se encuentra recogido dentro del
reglamento eléctrico de baja tensión.
“Se calificará como instalación eléctrica de baja tensión todo conjunto de
aparatos y circuitos asociados en previsión de un fin particular, producción,
conversión, transformación, distribución, o utilización de la energía eléctrica,
cuyas tensiones nominales sean iguales o inferiores a 1000 voltios para
corriente alterna y 1500 voltios para corrientes continuas.”
16.
Condiciones facultativas
16.1. Dirección
La dirección del montaje estará realizada en su totalidad por el ingeniero o
proyectista o por otra persona que ésta delegue atendiendo a la capacidad de dicha
persona para realizar este trabajo.
Una vez realizado el montaje, su utilización podrá ser realizada por cualquier
persona con conocimientos suficientes demostrables sobre el proyecto, la tecnología
Página 172
Santiago Reig Chiva
en él implicada y su funcionamiento. En caso de avería o pérdida de datos por
incorrecta utilización, el proyectista queda exento de culpa.
16.2. Libro de órdenes
El montaje de los elementos del proyecto se realizará atendiendo a los
documentos y planos del mismo.
Si es necesario realizar una modificación, se realizará bajo el pertinente
consentimiento del propio ingeniero o proyectista.
17. Condiciones de ejecucion y
montaje
17.1. Condiciones de fabricación del circuito
impreso
Si se decide por la fabricación de una placa de interfaz Arduino propia, a partir
de los diseños de referencia disponibles en la página web de Arduino, la fabricación del
circuito impreso deberá regirse por la norma UNE-621-80, en la cual se especifican los
ensayos a los que debe ser sometido el circuito impreso, así como los métodos para la
ejecución de dichos ensayos.
17.2. Pruebas y ensayos del montaje de la placa
Una vez montados todos los componentes y estén soldados correctamente a la
placa, se procederá a efectuar los siguientes ensayos:
Página 173
Santiago Reig Chiva
17.2.1. Prueba de alimentación
Para verificar el correcto funcionamiento de cada placa, se debe alimentar con
un transformador de 230V a 7÷12V o a través de los 5V del USB.
Se deberá comprobar que al conectar ambas tensiones no se produzca ningún
tipo de fallo tal y como un cortocircuito entre las alimentaciones.
Si se ha conectado la alimentación externa, se comprobará que en el pin
marcado como Vin, se tiene la misma tensión que la que saca el transformador.
Independientemente del modo en el que esté alimentado, deben aparecer 5V en el pin
marcado como 5V y 3,3V en el pin marcado como 3V3.
Las placas disponen de un LED de color verde el cual se ilumina cuando la placa
está siendo alimentada correctamente. Si este LED se desvanece lentamente al realizar
alguna conexión es el principal indicativo de que se está produciendo un cortocircuito
y el limitador de corriente está realizando su trabajo.
17.2.2. Prueba de la placa
Para realizar el ensayo de la puesta en marcha de la placa, se deberá utilizar el
IDE de Arduino.
Se hará uso del programa de ejemplo denominado “Blink” que hace parpadear
intermitentemente cada segundo el LED que la placa de interfaz tiene conectada al pin
13, que se puede identificar en la placa por estar marcado con una L. Este ejemplo es
el más simple de todos, ideal para asegurar que si se produce algún fallo sea de
hardware y no esté siendo enmascarado por un fallo de software.
Página 174
Santiago Reig Chiva
Ilustración 69 | Localización del ejemplo Blink
Ilustración 70 | Led L
Una vez probada la placa, puede ser probada con más
17.2.3. Conexionado de los circuitos
El conexionado de los circuitos que intervienen en el sistema se realiza
siguiendo las instrucciones provistas por el fabricante del hardware.
17.3. Instalación y uso de las aplicaciones
Para el correcto funcionamiento de todo el sistema, se debe instalar el
controlador de la placa de interfaz en el caso de que sea necesario para su
funcionamiento y la aplicación siguiendo las instrucciones que se encuentran en los
anexos.
Página 175
Santiago Reig Chiva
Para el manejo de la aplicación se puede consultar el Manual de Usuario, Anexo
IV y para la instalación de los controladores en el caso de que fuera necesario se puede
consultar el manual correspondiente en el Anexo III.
17.4. Conservación
Si para el montaje y puesta en marcha de los equipos y materiales que
componen la placa de interfaz se siguen todas las indicaciones, recomendaciones y se
cumplen las especificaciones que se dan en el pliego de condiciones, anexos y
memoria, la vida útil de los elementos estará supeditada a aquella que de el fabricante
siguiendo sus recomendaciones de mantenimiento.
17.5. Funcionamiento normal del equipo
Una vez realizados todos los pasos anteriores, el equipo estará listo para
funcionar permanentemente.
El equipo no necesita de un mantenimiento riguroso, siempre que su uso se
realice dentro de los límites especificados para cada componente.
El deterioro de los materiales puede ser debido al propio envejecimiento del
material con el paso del tiempo.
18. Condiciones de materiales y
equipo
18.1. Condiciones técnicas de los materiales
Lo materiales a emplear en este proyecto deberán cumplimentar todas y cada
una de las normas descritas en el presente documento y podrán ser sometidos a
diferentes pruebas y ensayos para asegurarse así de su correcto funcionamiento. En
Página 176
Santiago Reig Chiva
caso de no realizarse dichas pruebas y ensayos, el proyectista quedará exento de
responsabilidad en el posible deterioro de los elementos durante su utilización.
Estos materiales deben cumplir las especificaciones citadas para cada uno de
ellos. Si son reemplazados por unos nuevos, estos deben tener las mismas
características que los que reemplazan, inhibiéndose de cualquier responsabilidad por
fallo si estos requisitos no son cumplidos.
18.2. Condiciones técnicas del material
informático
Los requisitos mínimos del sistema informático necesario para poder ejecutar el
software diseñado, son los siguientes:

Ordenador personal con procesador Intel Pentium IV a 2.0 GHz o
equivalente.

512 MB de memoria RAM DDR.

Un puerto USB libre para la conexión de la placa de interfaz.

100 MB de espacio en disco duro para la instalación del software.

Microsoft Windows XP, Linux Ubuntu 11.10, Mac OS X Snow Leopard o
posterior.
Para la realización del presente proyecto se ha utilizado la siguiente
configuración de hardware y software:

Ordenador personal con procesador Intel i5 520M a 2,4 GHz, 4096MB
de memoria RAM DDR2, disco duro de 500 GB, tarjeta de sonido
integrada y conexión a Internet.

Sistema operativo Microsoft Windows 7 Home Premium, Linux Ubuntu
12.04 LTS y Mac OS X Lion.
Página 177
Santiago Reig Chiva

Navegador de Internet Google Chrome

Eric 4 IDE

Adobe Acrobat Reader X

Paint .NET

TinyGrab

Microsoft Word 2011

Microsoft Visio 2011

IDE de Arduino

Intérprete de Python

VMware Workstation 8
18.3. Condiciones técnicas de los circuitos
impresos
Las placas de los circuitos impresos serán de fibra de vidrio y tendrán un
espesor no inferior a 750 μm. Siendo una vez atacadas con ácido las placas para crear
las pistas, cubiertas con un barniz protector fotosensible de manera que el proceso no
oculte las zonas donde se deberán realizar la soldadura de los componentes.
Se deberá tener especial cuidado en el proceso de soldadura de ciertos
componentes tales como los semiconductores, tratando de reducir en la medida de lo
posible el tiempo del proceso, ya que debido a la sensibilidad de éstos a la
temperatura se podrían producir daños por sobrecalentamiento.
Página 178
Santiago Reig Chiva
18.4. Condiciones técnicas de los elementos
pasivos
Las resistencias y condensadores tendrán unas tolerancias o márgenes de error
permisibles.
En el caso de las resistencias se considerará aceptable un error de hasta el 5%,
siendo tolerable para los condensadores un valor del 20%.
19.
Condiciones economicas
19.1. Errores en el proyecto
En el caso de existir errores materiales o de cualquier otra índole en el
proyecto, se dará cuenta de ello lo más rápidamente posible al proyectista. De no
realizar este protocolo de seguimiento del desarrollo, el proyectista quedará libre de
culpa o sanción por los posibles errores.
19.2. Jornadas y salarios
Las jornadas y salarios correrán a cargo de la empresa contratista del proyecto,
así como de los gastos producidos durante el proceso de montaje hasta que se realice
la entrega del proyecto finalizado.
Correrán a cargo de la empresa los derechos de alta del proyecto en la
delegación provincial del Ministerio de Industria y organismo competente en el lugar
donde se desarrolle el proyecto.
Para llevar a cabo la ejecución del proyecto, deberán estar abonados lo
honorarios del proyectista, pudiendo recaer cargos sobre ello si esta parte no es
cumplimentada para su desarrollo.
Página 179
Santiago Reig Chiva
19.3. Liquidación
Terminada la elaboración del proyecto se procederá a la liquidación final en la
que se incluye el importe de las unidades de realización, así como las posibles
modificaciones del proyecto que hayan sido aprobadas por la dirección técnica.
Al suscribir el contrato, el contratante habrá de abonar al adjudicatario el 80%
del total del presupuesto. El 20% quedará como garantía durante los seis primeros
mese a partir de la fecha de puesta en marcha o de ejecución del mismo.
Si transcurrido ese plazo no se ha puesto en evidencia ningún defecto, se
abonará la cantidad que faltaba por entregar, y a partir de ese momento, se
considerarán completamente concluidos los compromisos entre ambas partes, a
excepción del periodo de garantía que cubrirá todo lo citado anteriormente.
Página 180
Santiago Reig Chiva
20.
Disposicion final
Las partes contratantes, dirección técnica y empresa, se ratifican en el
contenido del siguiente pliego de condiciones, el cual tiene igual validez, a todos los
efectos, que una escritura pública, prometiendo el fiel cumplimiento.
Fdo: Santiago Reig Chiva
Página 181
PLANOS
DOCUMENTO Nº 4
Santiago Reig Chiva
Planos
El presente proyecto no necesita de planos para su realización, por lo que está
sección no contiene información.
Página 183
PRESUPUESTO
DOCUMENTO Nº 5
Santiago Reig Chiva
Presupuesto
Índice del presupuesto
21.
21.1.
Presupuesto parcial ................................................................................ 187
Materiales ........................................................................................... 187
21.1.1. Hardware del sistema..................................................................... 187
21.1.2. Placa de interfaz ............................................................................. 188
21.1.3. Alimentación .................................................................................. 188
21.2.
Software del sistema........................................................................... 189
21.3.
Mano de obra...................................................................................... 190
22.
Presupuesto total ................................................................................... 192
Página 185
Santiago Reig Chiva
Presupuesto
Índice de tablas
Tabla 21 | Presupuesto de hardware del sistema ............................................ 187
Tabla 22 | Presupuesto de la placa de interfaz ................................................ 188
Tabla 23 | Presupuesto de alimentación.......................................................... 188
Tabla 24 | Presupuesto de materiales.............................................................. 189
Tabla 25 | Presupuesto de software del sistema ............................................. 190
Tabla 26 | Presupuesto de mano de obra ........................................................ 191
Tabla 27 | Presupuesto total ............................................................................ 192
Página 186
Santiago Reig Chiva
21.
Presupuesto
Presupuesto parcial
21.1. Materiales
21.1.1. Hardware del sistema
Siguiendo las especificaciones que han sido descritas en el apartado de
condiciones técnicas en el pliego de condiciones, se puede seleccionar cualquier
ordenador que cumpla los requisitos, ya sea sobremesa o portátil.
Debido a la facilidad de transporte se ha seleccionado un ordenador portátil
Tabla 21 | Presupuesto de hardware del sistema
Descripción
HP g6-1214es
Subtotal 1.1
Unidades
Coste unitario
Precio total
1
485 €
485 €
485 €
Página 187
Santiago Reig Chiva
Presupuesto
21.1.2. Placa de interfaz
Tabla 22 | Presupuesto de la placa de interfaz
Descripción
Unidades
Coste unitario
Precio total
Arduino UNO
1
20,63 €
20,63 €
Cable USB A-B
1
2,43 €
2,43 €
Subtotal 1.2
23,06 €
21.1.3. Alimentación
Tabla 23 | Presupuesto de alimentación
Descripción
Fuente de alimentación
Subtotal 1.3
Unidades
Coste unitario
Precio total
1
16,5 €
16,5 €
16,5 €
Página 188
Santiago Reig Chiva
Presupuesto
El presupuesto total de materiales es el siguiente:
Tabla 24 | Presupuesto de materiales
Descripción
Precio total
Subtotal 1.1
485 €
Subtotal 1.2
23,06 €
Subtotal 1.3
16,5 €
Subtotal 1
524,56 €
El precio total de la partida de materiales asciende a los 524,56 € (quinientos
veinticuatro euros con cincuenta y seis céntimos).
21.2. Software del sistema
En este apartado se desglosa el valor de las licencias de los programas
utilizados para la realización del proyecto.
Página 189
Santiago Reig Chiva
Presupuesto
Tabla 25 | Presupuesto de software del sistema
Descripción
Unidades
Coste unitario
Precio total
1
87,95 €
87,95 €
Microsoft Office 2010
1
699 €
699 €
VMware Workstation 8
1
177,68 €
177,68 €
Mac OS X Lion
1
59 €
59 €
Windows 7 Home
Premium
Subtotal 2
1.023,63 €
El precio total de la partida de software asciende a 1.123,63 € (mil veintitrés
con sesenta euros y tres céntimos).
21.3. Mano de obra
En este apartado se detallan los costes de mano de obra. Se desglosa en horas
requeridas, tarea realizada, precio por hora y precio total.
Página 190
Santiago Reig Chiva
Presupuesto
Tabla 26 | Presupuesto de mano de obra
Descripción
Horas
Precio por hora
Precio total
Estudios previos
10
10 €
100 €
Programación aplicación
250
30 €
7.500 €
Programación Arduino
15
50 €
750 €
20
30 €
600 €
40
15 e
600 €
Montaje y puesta en
marcha
Documentación
Subtotal 3
9.550 €
El precio total de la partida de mano de obra asciende a 9.550€ (nueve mil
quinientos cincuenta euros).
Página 191
Santiago Reig Chiva
22.
Presupuesto
Presupuesto total
Tabla 27 | Presupuesto total
Descripción
Precio total
Subtotal 1
524,56 €
Subtotal 2
1.023,63 €
Subtotal 3
9.550 €
Total
IVA (18%)
Total (IVA incluido)
11.098,19 €
1997,67 €
13.095,86 €
Página 192
Santiago Reig Chiva
Presupuesto
El presupuesto total del sistema, incluyendo costes, honorarios e impuestos
asciende a TRECE MIL NOVEINTA Y CINCO EUROS CON OCHENTA Y SEIS CÉNTIMOS.
Fdo: Santiago Reig Chiva
Página 193
BIBLIOGRAFÍA
DOCUMENTO Nº 6
Santiago Reig Chiva
Bibliografía
Índice de la bibliografía
Índice de la bibliografía..................................................................................... 195
23.
Protocolo Firmata ................................................................................... 196
24.
Programación software .......................................................................... 196
24.1.
C/C++ ................................................................................................... 196
24.2.
Python ................................................................................................. 196
25.
Arquitectura Atmel ................................................................................. 197
26.
Distribuidores ......................................................................................... 197
Página 195
Santiago Reig Chiva
Bibliografía
23. Protocolo Firmata

Detalles del protocolo:
http://firmata.org/wiki/Protocol

Limitaciones de diseño:
http://firmata.org/wiki/Design_Issues

Protocolo Midi:
https://ccrma.stanford.edu/~craig/articles/linuxmidi/misc/essenmidi.html
http://es.wikipedia.org/wiki/MIDI
24.
Programacion software
24.1. C/C++

Referencia de las librerías de Arduino.
http://arduino.cc/en/Reference/HomePage

Guías de C++
http://www.cplusplus.com/
24.2. Python


Rapid GUI Programming with Python and Qt, Mark Summerfield,
Prentice Hall, 2007.
Documentación de Python:
Página 196
Santiago Reig Chiva
Bibliografía
http://docs.python.org/

Documentación de Qt:
http://doc.qt.nokia.com/4.7/index.html
25.
Arquitectura Atmel

Documentación ATmega328P:
http://www.atmel.com/devices/atmega328p.aspx?tab=documents

Página de Arduino:
http://arduino.cc
26.
Distribuidores

Tienda de componentes informáticos:
http://www.pccomponentes.com

Distribuidor de componentes informáticos Mouser:
http://www.mouser.com

Distribuidor de componentes informáticos RS Amidata:
http://es.rs-online.com/web/
Página 197

Plataforma de experimentación para prototipado de diseños

Transcripción

Documentos relacionados

Equipamiento y software Parte Computadora: netbook, notebook

Manual de instalación software ModkIt

Temario taller de Electrónica Aplicada a la creación en arte