jueves, 19 de julio de 2012

Energia: Un MiniArduino por 4 Euros

Como ya es bien sabido por toda la comunidad que trabaja con proyectos sencillos basados en microcontrolador, Arduino es una plataforma que permite acercarse de manera muy sencilla al mundo de los microcontroladores sin saber prácticamente nada de electrónica. El precio del Arduino más sencillo es de 20 Euros para el Arduino UNO. Bastante barato. Uno se puede comprar el procesador Atmega con el bootloader de Arduino por unos 6 Euros y montarse la placa si va justo de dinero. Parece que es el precio mínimo de desarrollo para no iniciados en microcontroladores, ¿no?

¡Pues NO!  La gente del proyecto Energía ha reventado el precio de los proyectos sencillos desarrollando un entorno tipo Arduino para el Launchpad de Texas Instruments. El software y las instrucciones de uso del proyecto Energía las teneis aquí:


Las instrucciones son muy fáciles de seguir y, una vez arrancado el programa, lo único que se ha de configurar es el puerto en el que se halla conectado el Launchpad y el modelo de microcontrolador que lleva.

Como ejemplo os muestro un programa que he desarrollado en unos minutos a partir del típico ejemplo Blink que hace parpadear un led. Mi modificación hace parpadear dos leds en lugar de uno. No es gran cosa pero demuestra lo fácil que es hacer un programa. Nada que extrañe a alguien que haya usado Arduino.

Sketch Blink2 que hace parpadear dos leds

Escribiendo el Sketch y pulsando el segundo botón desde la izquierda (Upload) el programa se compila y se carga en el launchpad si está conectado al cable USB. En un momento tenemos dos leds parpadeando a distinto ritmo.

Para poder desarrollar programas es necesario conocer la correspondencia entre los pines del microcontrolador identificados como P1.0 a P1.7 y P2.0 a P2.5 (en microcontroladores de 20 pines) y los números de pin que usa el entorno que van del 2 al 15. En realidad el Launchpad puede usar los pines P2.6 y P2.7 si no usa cristal de cuarzo, pero, por lo que veo, esta opción no está actualmente implementada en Energía. En todo caso, la correspondencia de pines está en el fichero pins_energia.h que se halla en el subdirectorio:

hardware\msp430\variants\launchpad

dentro del directorio de instalación de Energía. En todo caso, para simplificar, la correspondencia es esta:

P1_0 = 2;     // LED 1 Rojo (Activo alto)
P1_1 = 3;
P1_2 = 4;
P1_3 = 5;    // Pulsador S2 (Activo bajo)
P1_4 = 6;
P1_5 = 7;
P2_0 = 8;
P2_1 = 9;
P2_2 = 10;
P2_3 = 11;
P2_4 = 12;
P2_5 = 13;
P1_6 = 14;   // LED 2 Verde (Activo alto)
P1_7 = 15;


Con esto y, con un poco de dedicación, cualquiera puede desarrollar proyectos sencillos con microcontrolador por lo que vale un bocadillo.













martes, 22 de mayo de 2012

La infame versión Z

En diseño de circuitos uno espera que los componentes se comporten siempre de la misma manera, que cuando compras un recambio de un componente por otro que tiene exactamente el mismo nombre, el funcionamiento sea el mismo. Lamentablemente eso no siempre es así, y en ocasiones, el fabricante no se toma muchas molestias en avisarlo.

Explicaré un caso concreto con la placa STM32F4 Discovery. La mejor y más potente placa de la familia Discovery.

Placa STM32F4 Discovery

El problema


Hace ya un tiempo compré una placa de éstas y empecé a trabajar en el software. El entorno de trabajo, algún dia hablaré del él, está basado en Eclipse y usa compiladores GCC. Hasta el momento he probado con Code Sourcery y Yagarto. Para depurar empleo el servidor GDB que veía con la versión gratuita de Atollic True Studio for STM32.

Como todo iba bién con la placa compré una placa nueva, igualita a a la otra que ya tenía. Mi sorpresa fué que el debugger se colgaba al intentar comunicarse con el microcontrolador.
Para descartar que fuera una placa defectuosa intenté programar en la placa usando el software STLink Utility que proporciona gratuitamente ST para programar sus microcontroladores.

Nada más arrancar ya se veía que algo iba mal.

Aplicación STLink Utility

El software era capaz de comunicar con el microcontrolador, pero no era capaz de averiguar de que micro se trata tal como se desprende de la frase "Unknown Device" arriba a la derecha de la pantalla. Fijémonos, luego diré porqué, en la identificación de la CPU que es 0x413

Al intentar programar el dispositivo las cosas se complican.


Es extraño, nunca habia visto este mensaje, le digo que adelante.


El programa es incapaz de programar el micro. Por lo visto está activada la protección que deshabitlita el bus JTAG para que no pueda extraerse el código del micro. Es extraño porque la placa es nueva.
La protección se configura con los llamados option bytes. Voy a la ventana pertinente y sale algo como ésto:


Parece que la protección de lectura está activada y la flash está protegida contra escritura. No se puede programar el micro y no se puede quitar la protección. No se puede usar el micro para nada que no sea usar el software de demostración que ya venía en la placa.

¡¡ Y la placa era nueva !!


La solución

Después de mucho buscar por internet a alguien que le hubiera pasado algo similar encontré esta referencia.

Por lo visto la gente tenía problemas con la versión "Z" de la CPU. Las placas STM32F4 Discovery, por lo visto, llevaban antes CPUs de versión "A". El último batch de placas usa CPUs de versión "Z".

La siguiente figura muestra una CPU de versión A.

STM32F407 Version A


A continuación se muestra una CPU de versión Z.

STM32F407 VersionZ


Parece ser que en el paso de la versión A  a la versión Z, la identificación de la CPU ha pasado de 0x411 a 0x413. A continuación se muestra el programa STLink Utility conectado a una CPU de versión "A" donde se vé como se identifica como 0x411 a diferencia de la identificación 0x413 de la versión "Z".

STLink Utility con STM32F4 versión "A"
 

Misterio solucionado. Pero en esta historia hay algunos puntos muy molestos:

  • Que ST envie placas STM32F4 Discovery incompatibles con versiones anteriores del software sin avisar de los posibles problemas de compatibilidad.
  • Que ST no actualice la aplicación STLink cuando cambia los MCUs que soporta.
  • Que la aplicación STLink no sea capaz de decir que no sabe como trabajar con el micro en lugar de hacernos creer que se ha habilitado la protección contra escritura.

Suerte que en la misma referencia que cité anteriormente se proporcionaba el link a una versión parcheada de STLink Utility para poder programar la placa.

Como información adicional de los cambios de la versión "A" a la versión "Z", parece que no hay más versiones intermedias. Éstos están documentados en el la Errata Sheet del microcontrolador. Lo que no se dice en este documento es la incompatibilidad que produce con las propias aplicaciones de ST.

Finalmente me alegra decir que la versión actual del servidor GDB de ATollic True Studio es capaz también de comunicarse con la CPU "Z" maldita.























lunes, 7 de mayo de 2012

Calibrando el DCO

En este artículo explicaré por encima el funcionamiento del oscilador controlado digitalmente DCO de la familia MSP430 y explicaré un procedimiento, software incluido, para calibrar este oscilador para un conjunto de frecuencias elegido.

Para empezar, hablaremos del DCO...

Descripción del DCO

Los microcontroladores MSP430 de Texas Instruments, por ejemplo los compatibles con la placa Launchpad, disponen de un oscilador RC interno controlado digitalmente (DCO). El DCO se controla con 3 valores digitales:

  • RSELx  (0..15) Selecciona un rango de frecuencia de funcionamiento
  • DCOx   (0..7)   Selección fina de frecuencia dentro del rango elegido
  • MODx  (0..31) Modulación de frecuencia entre DCO elegido y el siguiente DCO+1
Los valores RSELx y DCOx, por tanto seleccionan la frecuencia del oscilador interno tal y como se muestra en la siguiente figura de la familia MSP430x2xx (slau144i).

Frecuencia vs RSEL,DCO
Se ha de tener en cuenta que los rangos que cubren los distintos valores de RSEL se pueden solapar entre si, por tanto, es posible que RSEL=7 DCO=7 de una frecuencia mayor que RSEL=8 DCO=0.

El valor de MODx permite un ajuste más fino de la frecuencia media del oscilador. Básicamente, cada 32 ciclos, (32-MOD) ciclos se harán con la frecuencia DCO y MOD ciclos se harán con la frecuencia DCO+1. Para que esto funcione el valor de DCO elegido ha de ser inferior a 7 ya que no existe DCO+1 cuando DCO=7. Ls siguiente figura muestra el patrón de modulación para distintos valores de MOD.

Modulación del oscilador DCO
Es importante notar que el uso de la modulación introduce Jitter en la señal de reloj. Eso puede ser o no importante para una aplicación concreta pero es importante tenerlo en cuenta si necesitamos instantes de captura completamente periódicos.
  

Calibración del DCO en producción

El problema general es que las relaciones entre RSEL y DCO y la frecuencia generada tienen una tolerancia muy elevada por lo que para tener frecuencias de operación mínimamente exactas es necesario calibrar el oscilador. A modo de ejemplo, para la familia MSP430G2x21 (slas694i) con RSELx = 7, DCOx = 3 y MODx = 0 que es el valor con el que arranca el microcontrolador, pueden dar valores de frecuencia entre 0,8 y 1,5 MHz. Esto es, el error puede ser de 0,35MHz (un 23%) respecto de un valor central de 1,15MHz.

Calibrar el oscilador es determinar que valores de RSEL, DCO y MOD se han de programar para generar una determinada frecuencia. Aún usando valores calibrados el oscilador tiene una cierta tolerancia que puede ser de hasta +/- 6% para todo el rango de temperaturas y tensiones de alimentación, pero, aun así, es mucha menos tolerancia que un DCO no calibrado. Sin embargo, si calibramos el oscilador cuando el circuito opera a la tensión y temperatura de operación, la deriva será mucho menor.

Todos los microcontroladores de la familia MSP430 se calibran en el momento de producirlos, al menos a la frecuencia de 1MHz. Los valores de RSEL, DCO, y MOD que han de programarse en los registros  DCOCTL (DCO y MOD) y BCSCTL1 (RSEL) se guardan en la memoria flash del microcontrolador.

Usar los valores calibrados en factoría está bien, pero tiene algunos inconvenientes:
  • Sólo podemos usar las frecuencias elegidas por Texas Instruments para nuestro microcontrolador. El MSPG2211 sólo tiene la de 1MHz, el MSPG2553 tiene lass de 1, 8, 12 y 16MHz. Si nos interesa una calibración a 4MHz, mala suerte.
  • Texas Instruments realiza sus calibraciones a 30ºC y 3V. Si nuestro sistema ha de operar lejos de estos valores la calibración no será buena.
Para solventar estos problemas podemos hacer la calibración nosotros mismos.


Calibración de usuario del DCO

Para realizar la calibración debemos de contrastar la frecuencia que genera el DCO con una referencia más exacta. Podemos entonces variar los valores de RSEL, DCO y MOD para lograr la frecuencia deseada.
Un buen patrón para realizar la calibración es el oscilador de cristal externo de 32768 Hz. Hay varios motivos para ello:

  • Un cristal de este tipo puede tener una precisión de 10 a 20ppm
  • Todos los microcontroladores de la serie MSP430 pueden usar un oscilador externo de 32768Hz
  • El Launchpad viene con un un cristal de este tipo, aunque sin soldar. En otro artículo hablo de como instalar un cristal de 32768Hz de manera temporal o permanente en el launchpad.
Buscando en internet se ve que hay varias personas que ya han llegado a esta conclusión como se demuestra aqui y aqui. Incluso existe una libreria de Texas Instruments al respecto.

En general, la mayor parte de soluciones reescriben la Sección A de Information Area de la flash del micrcontrolador que es donde Texas Instruments guarda la información de calibración del oscilador y otros elementos durante la producción. Es por eso que este área está especialmente protegida por un flag de seguridad (LOCKA).

Reescribir este área es potencialmente peligroso porque podemos perder información de calibración importante de otros elementos como el ADC y porque este área está protegida por un checksum que algunas aplicación podrían revisar. Es cierto que se puede recalcular el checksum, pero, igualmente corremos riesgos de borrar información importante.

 Los microcontroladores MSP430 tienen 3 áreas más de información (B,C,D) en la flash, todas ellas de 64 bytes igual que el área A, pero, a diferencia del área A, están vacían en los microcontoladores que salen de la factoría de Texas Instruments. En mi caso he pensado que sería mejor guardar la nueva información de calibración en la Sección B y no tocar la sección A para nada.

Dentro de esta área guardaré 9 valores de calibración para las frecuencias de 500Hz, 1MHz, 2MHz, 4MHz, 6MHz, 8MHz, 10MHz, 12MHz y 16MHz. La posición donde guardaré los valores de calibración las he incluido en un fichero NewDCOCal.h para tener una mejor referencia de sus posiciones. Si hace falta, se pueden cambiar o añadir nuevos valores de calibración si hace falta.


Programa de Calibración

Para realizar la calibración he realizado un programa DCO Calibration. Este program depende, a parte de NewDCOCal.h, del fichero io430masks.h. El programa se ha compilado con el compilador MSPGCC bajo Eclipse y, optimizado en tamaño, cabe en cualquier microcontrolador con al menos 2kB de flash.

El programa está pensado para hacerse correr en la placa Launchpad, por ello se emplean los siguientes pines:

         Xin/Xout : Cristal de 32768Hz
         P1.0 : Led Verde
         P1.3 : Pulsador a tierra
         P1.6 : Led Rojo

Adicionalmente se emplean dos pines para verificar los osciladores:
         P1.4 : Salida de cuadrada a la frecuencia del DCO
         P1.5 : Salida de 256Hz generada por el oscilador de 32768Hz
  
 Cuando el programa arranca, verifica si hay información en la sección de información B. Si hay información, pasa al modo de generación de frecuencia descrito más delante. Si no hay datos, se realiza la calibración, se guarda en la sección de información B de la flash y se pasa al modo de generación de frecuencia.
Durante la calibración el pin P1.4 muestra la frecuencia actualmente generada. Cada vez que se pasa a calibrar una nueva frecuencia, el led verde parpadea una vez. Si la calibración de una frecuencia se ha de repetir por no cumplir con la tolerancia deseada, parpadean los dos leds rojo y verde. 

En modo de generación de frecuencia el sistema programa la primera frecuencia de la lista de frecuencias calibradas (500kHz). Cada vez que se pulsa el pulsador que se halla en P1.3 se salta a la siguiente frecuencia de la lista para pasarse otra vez a la primera (500kHz) después de la última (16MHz). En este modo P1.4 tiene la frecuencia generada y el led verde parpadea a la frecuencia generada dividida por 20*65536 (20 desbordamientos del Timer A0).

En caso de error, el programa se bloquea mostrando un código de error mediante un número de parpadeos:

       (1)  Fallo del oscilador de 32768 Hz
       (2)  Problemas al calibrar una frecuencia
       (4)  No existe calibración de fábrica para 1MHz (necesaria para programar la flash)
       (5)  No puede lograrse la cota de error deseada (por defecto menos del 5%) 
       (Led Continuo) Problemas al arrancar el oscilador de 32768 Hz


Funcionamiento del programa

Para calibrar el oscilador el Watchdog se programa en modo temporizador con un período de unos 1,9ms (64/32768Hz) usando el oscilador de cuarzo. El timer A0 se configura en modo contínuo con el DCO como entrada. Se genera una captura del timer A0 cada vez que se da la interrupción del Watchdog. Calculando el número de ciclos del DCO entre dos capturas podemos inferir la frecuencia del DCO.

                    Frecuencia DCO = 512 * Ciclos entre capturas

Para aumentar la precisión, se promedia el intervalo de 50 capturas.

El programa comienza eligiendo el valor de RSEL, a continuación se elige el valor de DCO que se halla justo por debajo de la frecuencia deseada. Finalmente se ajusta la modulación MOD entre esta frecuencia de DCO y la siguiente.


Compilación condicional

El programa contiene 3 defines que permiten compilación condicional.

Si se activa el define DEBUG, el programa guarda los valores de RSEL, DCO y MOD junto con el error de calibración en cada frecuencia. De esta manera se puede verificar con el debugger.

Si se activa el define FLASH_OVERRIDE el programa reescribirá la información de la Sección B aunque no se halle vacía.

Si se activa el define TEST_MODE, toda la calibración se realizará en RAM para verificar el funcionamientod e la calibración sin tocar la memoria flash.


Video del funcionamiento

A continuación se muestra un video del funcionamiento del sistema de calibración en un Launchpad version 1.5 con el procesador MSP430G2553 que lleva por defecto. Junto al Launchpad tenemos un osciloscopio que muestra la frecuencia generada y un multimetro que trabaja como frecuencímetro.





miércoles, 2 de mayo de 2012

Instalación del Cristal en el Launchpad

 En este artículo hablaré de la instalación del cristal de cuarzo de 32768Hz en el Launchpad.  Un cristal de 32768Hz es fundamental para disponer de un reloj de tiempo real. En efecto 2^15 ciclos de este oscilador corresponden a un segundo. En el caso de la familia MSP430, en concreto, podemos usar el Watchdog en modo timer para generar una interrupción exactamente cada segundo usando como base este cristal de cuarzo.

Launchpad y bolsa con el cristal

 Este cristal de cuarzo viene incluido en la caja del Launchpad, pero no se halla soldado en la placa. El motivo por el que no viene soldado es porque el cuarzo ocupa 2 pines del microcontrolador que podrían ser usado como líneas de I/O. Dependiendo de la aplicación, por tanto, nos puede interesar no soldar este cristal para poder disponer de estas líneas. 

 En la siguiente figura se muestra la localización del cristal de cuarzo.

Localización del cristal

 El problema a la hora de poner el cristal es que el que se proporciona con el Launchpad es muy pequeño y cuesta de soldar. Para hacer las cosas más fáciles lo mejor es sujetar el cristal en su sitio con cinta adhesiva. Se ha de andar con ojo porque el cristal tiene delante y detrás. En la posición correcta los dos pines deben quedan apoyados sobre los pads de soldadura.



Cristal sujeto con cinta adhesiva
Para soldar el cristal conviene tener una lupa y un soldador de punta fina, pero con paciencia al final queda bien soldado. Si se cortocircuitan los pads, se retira el estaño con cinta de desoldar y vuelta a empezar.


Cristal soldado
Una vez soldados los dos terminales del cristal, podemos retirar la cinta adhesiva con cuidado de no arrancar el cristal y, a continuación, soldamos el cuerpo del cristal en el pad que tiene debajo.

Soldadura del cuerpo del cristal
Una vez soldado el cristal, se debe probar que funciona correctamente. Para ello he realizado un programa de test bajo Eclipse basado en dos ficheros main.c y io430masks.h.
El programa intenta poner en marcha el reloj basado en el cristal externo de 32768Hz. Si funciona correctamente, el led verde parpadea cambiando cada segundo. Si el oscilador falla, se enciende el led rojo.


Solución a problemas

Si el oscilador no funciona, lo primero es revisar las soldaduras.

El oscilador es muy sensible a cualquier interferencia. Los pines del oscilador, dado que pueden ser usados como I/O, están conectados a los pines de salida de la placa Launchpad. Para minimizar las interferencias se puede desconectar el oscilador de estos pines retirando las dos resistencais de cero ohmios que unen el oscilador con los pines. En la siguiente figura se muestra la localización de estas resistencias. Esta figura se puede comparar con la anterior que aún tenía las resistencias soldadas.

Resistencias eliminadas

Alternativa al la soldadura

Finalmente, para la gente a la que esta soldadura le resulte muy complicada o, para quienes no quieran sacrificar de manera permanente los dos pines de I/O, existe la posibilidad de poner el cristal de cuarzo conectado a los pines externos de la placa.

El procedimiento se puede hacer con el cristal que viene con el launchpad, pero, debido a su tamaño,no es la solución más cómoda.  Los osciladores de 32768Hz son fáciles de conseguir y baratos. Es importante, no obstante, comprarlos con una capacidad soportada por la familia MSP430 como 12,5pF o 6pF para no tener que añadir capacidades externas. A modo de ejemplo está este de Farnell que es el que he empleado.

En la siguiente figura se muestra un cristal de 32768Hz soldado a dos pines hembra.

Cristal soldado a pines hembra
Para emplear el cristal basta con conectarlo en la placa en los pines correspondientes.

Cristal sobre los pines de la placa

Con ello acaba este artículo sobre el cristal externo del Launchpad. Con un cristal como éste es fácil desarrollar aplicaciones que requieran una temporización precisa como sistemas basados en reloj de tiempo real, frecuencímetros, etc...


viernes, 27 de abril de 2012

Programación ISP con Launchpad

Una de las grandes ventajas de los microcontroladores MSP430 de la serie value line G2xxx es que, a parte de ser baratos, están disponibles en encapsulado DIP de 14 o 20 pines. Eso los hace muy interesantes para cualquier proyecto sencillo desarrollado en una placa de topos e, incluso, en una protoboard.

Usando el Launchpad podemos programar cualquier microcontrolador de la serie value line para luego insertarlo en nuestro circuito. Sin embargo, a parte del engorro de quitar y poner chips, dado que los zócalos no son ZIF, nos arriesgamos a dañar los chips cada vez que los sacamos e insertamos del zócalo.

Dado el bajo precio de la placa Launchpad, siempre podemos insertar toda la placa en nuestro sistema y así, poder programarla mediante USB, no obstante, esta no es la solución más compacta.

En este artículo explicaré el procedimiento para programar In System (ISP) sistemas desarrolados con microcontroladores MSP430 value line.

Para que el microcontrolador sea programable In System  es necesario que se cumplan las siguientes condiciones:

  • Tener disponibles los pines TEST y RESET del microcontrolador. Estas dos señales, durante la programación ISP llevan el reloj y los datos, respectivamente, del canal de comunicación usado en la programación.
 
  • Que la señal RESET no se halle directamente conectada a alimentación. Dejar RESET conectado a la alimentación no perjudica el funcionamiento normal del microcontrolador, pero evita que pueda ser programada In System.

La siguiente figura muestra un esquema de un sistema sencillo basado en el microcontrolador MSP430G2452 que se halla incluido como segundo chip en la versión 1.5 del Launchpad.

Esquema de sistema sencillo basado en MSP430G2452

 El sistema tiene lo necesario para ser programado In System y un led conectado a P1.0 para poder verficar que el programa cargado corre correctamente. La línea TEST se lleva directamente al conector de programación. La línea RST (Reset), a parte de ir al conector, incluye una conexión a Vdd con una resistencia de 47k y un condensador de 1nF a masa. Si deseamos añadir al sistema un pulsador de Reset, éste se puede añadir entre RST y masa en paralelo con el condensador.

Importante: El condensador que se halla en la línea RST puede ser algo mayor de 1nF pero no mucho mayor. Si el valor es excesivo, el programador no será capaz de establecer la comunicación.

La siguiente imagen muestra el esquema anterior implementado en una placa protoboard.

Implementación en Protoboard


Para realizar conexión de programación se ha elegido una tira de 5 pines, macho en la placa y hembra en el cable de programación. Para evitar que se pueda conectar al revés, uno de los pines está cortado en el lado de la placa y cegado en el cable.

Disponer de Vdd en el conector de programación no es estríctamente necesario, pero permite alimentar la placa desde el Launchpad y evitar gastar pilas cuando se depura. Si se desea tener siempre alimentaciones independientes, se puede eliminar Vdd del conector de la placa. En todo caso, el sistema sólo puede tener una fuente de alimentación al mismo tiempo, bien sea propia o bien sea a través de conector de programación. Por tanto, mientras se depura con Vdd conectado, se han de quitar las pilas o cualquier otra fuente alternativa de la placa.

Para conectar la placa al Launchpad he montado un cable de algo menos de 20 cm que lleva las 4 señales de interés Vdd, TEST, RST y GND. El cable  tiene un conector hembra de 5 pines en el lado de la placa y 4 conectores hembra independientes en el lado del Launchpad. A la hora de diseñar el cable conviene que, al menos, TEST y RST sean de la misma longitud. Del mismo modo conviene mantener la longitud de los cables lo más corta posible.

Cable de conexión con sus colores



Cable construido


Para realizar las conexiones en el launchpad, deben quitarse los 5 jumpers que unen la zona de emulación con el resto de la placa.

Jumpers a quitar
Una vez quitados los Jumpers, se conectan las líneas Vdd, TEST y RST al lado del emulador de los Jumpers correspondientes y la línea GND al pin de  arriba de la tira derecha de la placa. Se ha de vigilar porque el orden de los Jumpers no es mismo en todas las placas Launchpad. En todo caso no hay pérdida porque todas las señales se hallan correctamente serigrafiadas.
No hace falta retirar el microcontrolador del zócalo que hay en el Launchpad ya que, al quitar todos los Jumpers, el chip queda completamente aislado del emulador.

Conexión Protoboard - Launchpad para ISP


Conectamos el cable de programación que une el Launchpad a la placa que deseamos programar en modo ISP y ya sólo queda desacargar el programa para probarlo.

El código del programa que hace parpadear el LED en P1.0 se halla en este enlace. Basta crear un nuevo proyecto con la herramienta elegida para programar el chip y descargarlo en la placa igual que se haría con el chip contenido en el Launchpad.
En mi caso empleo mspgcc bajo eclipse tal y como describo en un artículo anterior.

Una vez descargado y depurado el programa, se puede usar la placa de manera autónoma con su propia alimentación después de desconectar el cable de programación.

Protoboard corriendo autónomamente

Con esto acaba este articulo. Sólo se trata de un pequeño sistema que hace parpadear un LED, pero es ampliable a cualquier sistema que deseemos programar en modo ISP.


AMPLIACIÓN PARA EL USO DEL CANAL SERIE

Es posible ampliar el sistema incorporando el canal serie a través de USB que proporciona el emulador. Para ello se han de añador dos lineas adicionales conectadas a los Jumpers correspondientes TXD y RXD. No obstante se ha de hacer con cuidado para placas Launchpad de versión 1.5 o posteriores. A parte del hecho de que el orden de señales se ha cambiado en los Jumpers, las conexiones del emulador no se hallan todas en el mismo lado.

La siguiente figura muestra un detalle del esquema de la Placa Launchpad v1.5 del documento slau318b.
Esquema de Jumpers en Launchpad v1.5

Cuidado que BTXD es la transmisión del emulador, que conecta con recepción del microcontrolador (RXD). Por su parte BRXD es la recepción del emulador, que conecta con la emisión del microcontrolador (TXD). Los valores rotulados en la placa RXD y TXD corresponden a Recepción y Transmisión respectivamente desde el punto de vista del microcontrolador.

En concreto, Vcc, TEST y RST se hallan todas en el lado del emulador, iguar que la línea RXD (BTXD del emulador). La línea TXD (BRXD del emuilador) del último Jumper, sin embargo, se halla en el lado de la placa correspondiente al microcontrolador, no en el lado del emulador. Este cambio se hizo para que, cambiando la orientación de los Jumpers asociados a BRXD y BTXD se puedan cambiar las conexiones establecidas:

  • Jumpers Verticales (Igual que los otros) TXD en P1.1 y RXD en P1.2
  • Jumpers Horizontales (Perpendiculares a los otros) TXD en P1.2 y RXD en P1.1
Esto era necesario para poder usar la conexión serie por Hardware que facilita la UART de los microcontroladores más avanzados de la seríe MSP430G2xxx



miércoles, 11 de abril de 2012

Aquarium: Version Final

Con este artículo acaba la serie del proyecto Aquarium.

Una vez comprobado que el prototipo funciona correctamente, es el momento de pasar a la versión final del sistema. El primer paso es realizar una placa que integre la mayor parte del hardware que no es la placa STM8L Discovery.
La placa contiene el driver L923D y el regulador de 5V 7805. Esta placa se acompaña de una placa más pequeña que incorpora los 3 pulsadores que permiten configurar el sistema.

Placa principal y Pulsadores
En la figura de arriba se aprecia la placa principal junto con la de pulsadores. En la placa también se obervan los conectores hembra que se unirán a las conexiones de alimentación, masa y GPIO de la placa STM8L Discovery.
A la derecha de la placa principal tenemos 4 puertos de conexiones con conexiones macho en ángulo recto. De arriba a abajo son:
  • Conector para el motor del alimentador de comida
  • Conector de salida para los relés
  • Conector con +5V regulados
  • Conector de entrada de alimentación no regulada de 9V a 12V
La salida de +5V regulados se ha añadido para conectar un led verde (con resistencia en serie), que no está en el esquema principal, y que sirve para indicar visualmente que el sistema se halla en marcha.

Encima de la placa principal se conecta la placa STM8L Discóvery tal y como se muestra en la figura.

Placa STM8L Discovery conectada



Con ello ya tenemos la mayor parte del sistema. Para montar el conjunto se ha empleado una caja de madera ya que es un material muy fácil de mecanizar. La siguiente figura muestra el interior de la caja con todos los componentes. La placa Discovery se ha fijado con el infalible método de la goma elástica y dos tornillos. No es la solución más elegante, pero funciona.


Se observan los siguientes elementos:

  1. Placa principal
  2. Placa de pulsadores
  3. Relés
  4. Interruptor general S4
  5. Alimentador de 12V
  6. Entrada de alimentación de 220V
  7. Salida para la luz del acuario a 220V
  8. Salida para la boba de filtrado a 220V
  9. Conector RCA para conectar el motor del alimentador de comida
Delante del conector USB de la placa Discovery se ha practicado un orificio en la caja para poder programar el sistema sin necesidad de desmontarlo. Eso si, para evitar conflictos, no conviene tener alimentado el sistema cuando se programa por USB.


La siguiente figura muestra la caja cerrada con sus conexiones externas: Entrada de 220V, enchufes de la luz y la bomba de filtrado y sistema de alimentación de comida.

Sistema con sus conexiones

La última figura muestra la parte frontal de la caja con todos sus elementos de interacción con el usuario.

Frontal del sistema
Los elementos son:

  1. Interruptor general S4
  2. Led que indica que el sistema está en marcha
  3. Display LCD
  4. Los 3 pulsadores, de arriba a abajo:  (+) (OK) (-)
Cuando el sistema está en marcha, el display muestra la hora actual y tres indicaciones usando las barras que se hallan a la derecha del LCD. En concreto se indica si está operando en modo manual o automático y si se hallan en marcha la bomba y/o la luz.

En este preciso momento el sistema está en marcha controlando el acuario.

Actualización 15/4/2012

Añado un video del alimentador en funcionamiento







martes, 10 de abril de 2012

Aquarium: Prototipo

Una vez diseñada la electrónica toca implementarla para poder ponerla a prueba. Para ello he montado el circuito con lo que se conoce como "Spread Table Integration". Esto es, juntar todos los elementos esparcidos por la mesa y con un montón de cables. Para hacer el prototipo portátil lo he puesto dentro de una maleta de plástico tal y como se muestra en la siguiente figura:

Spread table integration

Como se observa, se han fabricado diferentes módulos que pueden emplearse en distintos proyectos y se han conectado entre sí siguiendo el esquema del artículo anterior. Despues de acabar de probar el prototipo, los módulos se guardan para un uso futuro en otro proyecto.

En la figura se aprecia:

  1 - Placa STM8L Discovery
  2 - Módulo con un regulador 7805
  3 - Modulo con un driver H L923D
  4 - Módulo de pulsadores y leds (sólo se usan 3 pulsadores)
  5 - Relés

Una vez que tenemos la parte eléctrica resuelta, queda la programación.


Programando el prototipo

El documento UM0991 explica como descargar el entorno de desarrollo STVD y el compilador Cosmic Compiler.

Actualización
Actualmente tengo instaladas las versiones de evaluación, limitadas a 32k tanto del Compilador Cosmic como el de Raisonance. Ambos funcionan correctamente bajo STVD. No obstante, la versión del código indicada en esta proyecta únicamente compila sin errores bajo Raisonance.


Una vez tenemos ambas herramientas instaladas, podemos descargar el fichero:


Este fichero contiene tres proyectos, uno de ellos, denominado "Discover" contiene el código fuente del software que viene preprogramado en la placa. Ya contiene el enlace a todas las librerias necesarias para trabajar con todos los periféricos, incluido el LCD. Por tanto, para desarrollar un nuevo proyecto, basta con modificar el código contenido en main.c

El proyecto Aquarium es, desde el punto de vista del software, bastante sencillo. El software se desarrollará al estilo Arduino, lo más simple posible y sin emplear interrupciones.

Básicamente tendremos:

  1. Una rutina de inicialización que inicia los puertos de I/O y otros periféricos como el oscilador de 32kHz y el reloj de tiempo real. También leerá la configuración previa guardada en memoria no volátil.
  2. Un bucle de dentro de main ( ) que irá comprobando que no se pulse el botón OK ni tampoco se de la hora a la que se tenga que hacer alguna acción como encender o apagar la luz o la bomba o dar de comer a los peces.
  3. Diferentes rutinas que son llamadas cuando se da algún evento de interacción con el usuario o con el acuario.

Dado que el sistema no emplea interrupciones, se deberá cuidar la programación para evitar que nos saltemos algún evento cuando se está procesando otro.

El fichero "main.c" es el único fichero modificado dentro del proyecto Discovery. El contenido del fichero main modificado es accesible desde este enlace:



Desde un punto de vista funcional el sistema, cuando está en marcha, muestra la hora actual en el LCD. Por defecto la bomba de filtrado está siempre en marcha. En cada instante se verifica si la luz debe estar encendida dependiendo de la hora de encendido y apagado de la luz.
Cuando llega la hora de dar comida a los peces, el sistema  para la bomba y hace un número programable de ciclos de giro en el alimentador de comida. A continuación se programa el sistema para que la bomba se encienda un cierto tiempo mas tarde (15 minutos por defecto).

En cualquier momento, mientras se muestra la hora, se puede pulsar el botón (OK). Ello invoca el menú de configuración, el cual permite realizar las siguientes acciones:
  • Dar de comer a los peces sin esperar la hora programada
  • Cambiar entre los modos manual y automático de funcionamiento
  • Fijar la hora actual
  • Fijar la hora de encendido de la luz
  • Fijar la hora de apagado de la luz
  • Fijar la hora en que han de comer los peces
  • Fijar el número de giros que debe hacer el alimentador
  • Guardar la configuración en la memoria EEPROM del microcontrolador
El sistema arranca en modo automático y controla la luz, la bomba y la alimentación de los peces. Si se pasa a modo manual, la bomba y la luz quedan en marcha y se pueden controlar con los interruptores S5 y S6 (ver esquema). En modo manual, para alimentar los peces se puede emplear la primera opción del menú.

Cada vez que arranca el sistema, se mira si hay información de configuración en la memoria EEPROM del microcontrolador. Por tanto, cuando se apaga el sistema por completo, lo único que se pierde es la información de la hora actual.


Probando el prototipo

Una vez programado todo el sistema sólo queda ponerlo a prueba, para ello se pone sobre el acuario tal y como se muestra en la figura y se deja unos dias funcionando.

Prototipo en funcionamiento

Una vez verificado el funcionamiento del prototipo, lo último que queda es desarrollar la versión final del sistema.

Continua con la versión final


lunes, 9 de abril de 2012

Aquarium: Diseño de la Electrónica

Una vez fabricado el alimentador de comida del acuario, todo el resto del sistema es electrónica. Para empezar realizaremos las especificaciones generales del sistema. Para poder elegir el microcontrolador a emplear.

El sistema deberá poder controlar 3 elementos. El control del motor del alimentador debe ser bidireccional por lo que emplearemos un driver en H. Para controlarlo necesitaremos 2 líneas digitales.
El control de la bomba y la luz se realizará con relés y requerirá una línea de I/O cada uno.
El sistema debe sincronizar las diferentes acciones con la hora del dia por tanto, nos convendría disponer de un reloj de tiempo real. Para mostrar la hora actual y programar el sistema necesitamos un display. Con un display LCD de 6 dígitos tenemos bastante. Si puede ser alfanumérico, mejor.
Para programar el sistema se ha elegido emplear un control con 3 botones, un botón (+) un botón (-) y un botón (OK). Para ello necesitaremos 3 líneas de I/O que, sumadas a las 4 anteriores dan un total de 7.

En definitiva necesitamos:

  • 7 Líneas de I/O
    • 2 Para el control del alimentador de comida
    • 2 Para los relés de control de la bomba de filtrado y la luz
    • 3 Para los botones de control
  • Reloj de tiempo Real
  • Display LCD
La placa STM8L Discovery, de la familia de placas Discovery de bajo coste es perfecta para esta aplicación. Dispone de un LCD alfanumérico de 6 dígitos con algunos segmentos extra adicionales. Dispone también de un cristal de cuarzo de 32768 Hz y el hardware necesario para el reloj de tiempo real. Además el precio está muy bien (Menos de 11 Euros en Farnell).

La placa STM8L Discovery
La página web de ST contiene mucha información sobre esta placa, pero lo principal para trabajar con ella a nivel de hardware es el manual de usuario.


Consiguiendo las I/Os necesarias

El único problema de la placa STM8L Discovery es que, debido a la gran cantidad de líneas de I/O que emplea el LCD, quedan pocas lineas disponibles para uso externo. En concreto sólo hay 3 líneas de I/O completamente disponibles: PA2, PA3 y PC0. La placa emplea las líneas PE7 y PC7 para controlar dos leds de usuario. Podemos emplear estas dos líneas al mismo tiempo para controlar los relés de la luz y la bomba de filtrado. Adicionalmente la línea  PC1 se emplea para el botón de usuario que lleva la placa. Dado que necesitamos 3 botones, asignaremos uno de ellos a la línea PC1 y los otros dos a las dos líneas disponibles PA2 y PA3. Con ello nos queda únicamente la línea PC0 disponible pero necesitamos dos lineas todavía para controlar el motor del alimentador.

Para obtener más líneas de I/O, podemos eliminar el sistema de medida de corriente de alimentación que incorpora la placa. Este sistema emplea las líneas de I/O PE6, PC4 y PF0. Si eliminamos los puentes de soldadura SB11, SB12 y SB14 y ponemos el jumper JP1 en posición OFF, tal y como se indica en el manual, tendremos esas 3 líneas de I/O disponibles para cualquier uso externo.

Con ello las líneas de I/O empleadas serán:

  • PA2 : Botón (+)
  • PC1 : Botón (OK)
  • PA3 : Botón (-)
  • PC0, PC4 : Control del motor del alimentador
  • PE7 : Relé de la luz
  • PC7 : Relé de la bomba
Todavia nos quedan libres las líneas PE6 y PF0 para ampliaciones futuras si hace falta.


H Drivers

Ni el motor del alimentador ni los relés pueden ser directamente accionados por un microcontrolador. Para actuar sobre ellos se requiere algún tipo de driver.
Dado que el motor ha de poder ser actuado bidireccionalmente, lo mejor es emplear un driver en H. Uno de los integrados más típicos de este tipo es el L293D que incorpora 2 drivers en H completos. Por simplicidad de soldadura, emplearemos la versión DIL de 16 pines.
Tal y como muestra su datasheet, el driver puede controlar 2 motores de manera bidireccional o 4 motores en un único sentido. En nuestro diseño emplearemos un driver H para el motor del alimentador y las otras dos mitades del driver restante para controlar los 2 relés de la luz y la bomba de filtrado.
Debido a que el driver L293D ya incorpora diodos de protección flyback, no es necesario añadirlos al esquema.


Esquema completo

Juntando todo lo anterior se llega al esquema que se muestra en la figura siguiente.

Esquema eléctrico


Las conexiones en color rojo y azul son las únicas peligrosas al estar a 220V. El resto de señales trabaja por debajo de los 5V.
En el esquema se han indicado los puertos del microcontrolador empleados y la posición en la que se halla el terminal empleado. Así, por ejemplo, el pulsador (+) S1 se halla conectado a PA2 que está disponible en el quinto terminal de la fila izquierda de conexiones de la placa. En todo caso no hay pérdida porque las señales se hallan perfectamente rotuladas sobre la placa.

También se indican los pines del encapsulado DIL16 del driver L293D. Los pines 1, 8, 9 y 16 se hallan conectados a alimentación. Los pines 1 y 9 corresponden a los Enables de los 2 drivers en H que dejaremos permanentemente activos. Los pines 8 y 16 corresponden, respectivamente, a las alimentaciones de los motores y la circuitería digital, que dejaremos a +5V.

Para abaratar costes, la alimentación eléctrica del sistema se ha construido en torno a un viejo alimentador de 12V que tenía por ahí tirado. Añadiéndole un regulador 7805 disponemos de la tensión requerida por la placa STM8L Discovery. Cualquier alimentador entre 9V y 12V habría valido mientras de la corriente suficiente para alimentar el motor y los relés.

El motor del alimentador de comida se ha conectado a los pines 3 y 6 del L293D que son la salida del primer driver H. Para girar en un sentido se ha de poner PC0 alto y PC4 bajo. Para girar en el sentido contrario se ha de poner PC0 bajo y PC4 alto, para parar el motor basta poner PC0 y PC4 en el mismo nivel lógico.



Como se observa, las conexiones de la luz y la bomba se toman de las salidas NC (Normally Closed) de los relés. Eso significa que ambos elementos se hallan activos cuando los relés están apagados. La conexión se ha realizado así para que cuando el sistema está apagado (con S4 abierto) tanto la luz como la bomba se puedan controlar manualmente con los interruptores S5 y S6. Lógicamente cuando es sistema funciona tanto S5 como S6 deben permanecer cerrados para que el sistema pueda controlar la luz y la bomba.


Los relés empleados son de tipo G5LA. La elección de estos relés se ha hecho porque son muy baratos, a menos de 1€ cada uno. En encendido de cada relé provoca el apagado del sistema que alimenta (luz o bomba de filtrado). Debido a que uno de los terminales de la bobina del relé se halla a +5V, los relés se encenderán con un nivel bajo de las salidas que lo controlan (PE7 o PC7). Por tanto, los leds de la placa LD3 y LD4 asociados, respectivamente, a PE7 y PC7, se encenderán al mismo tiempo que lo haga la luz o la bomba. A modo de ejemplo, para el control de la luz:

  • Nivel alto en PE7: Apagado de RL1 y encendido de la Luz y del LED LD3 (Verde)
  • Nivel bajo en PE7: Encendido de RL1 y apagado de la Luz y del LED LD3 (Verde)

Y para la bomba de filtrado:
  • Nivel alto en PC7: Apagado de RL2 y encendido de la Bomba y del LED LD4 (Azul)
  • Nivel bajo en PC7: Encendido de RL2 y apagado de la Bomba y del LED LD4 (Azul)

Con ello acaba la descripción del esquema eléctrico. En el proximo artículo hablaré del primer prototipo y del programa que controla el microcontrolador.

Continua con el prototipo

El proyecto Aquarium

Con este artículo empiezo la explicación del proyecto Aquarium. Se trata de un proyecto relativamente sencillo que permite automatizar los cuidados diarios de un acuario usando un microcontrolador de 8 bits.

Acuario a automatizar



El acuario al que hacer referencia el proyecto es el de la figura de arriba. Un pequeño acuario de agua dulce caliente de unos 20 litros. El acuario cuenta con un sistema de control de la temperatura del agua, una bomba de aire para oxigenar el agua, una luz fluorescente y una bomba para el filtrado del agua.

El sistema de control de temperatura está permanentemente en marcha para mantener a los peces en la zona de confort entre los 26 ºC. Igualmente la bomba de aire está también permanentemente en marcha para garantizar a los peces un suministro continuo de oxígeno.

El cuidado diario del acuario consisten en:

  • Apagar la luz por la noche y encenderla por el dia
  • Dar de comer a los peces una vez al dia
  • Apagar la bomba mientras los peces comen para evitar ensuciar el filtro con comida

Lo que se pretende en este proyecto es automatizar los tres puntos anteriores de manera que se pueda gestionar el acuario automáticamente durante unos dias de viaje o vacaciones. Eso no evita tener que limpiar el filtro o cambiar parte del agua de vez en cuando, pero automatiza el trabajo del dia a dia.

La siguiente figura muestra un esquema general del sistema a diseñar:

Esquema general

El sistema contará con un LCD y algunos botones para controlar sus funciones.
La bomba de aire y el control de temperatura se dejarán siempre en marcha, por lo que nuestro sistema únicamente tendrá que gestionar la luz, la bomba de filtrado y la alimentación de los peces.
Como tanto la bomba de filtrado como la luz son sistemas eléctricos, bastará un relé para controlar cada uno. El principal problema es la alimentación de los peces, dado que esta se hace actualmente de manera completamente manual, por lo que se ha de diseñar un sistema completo.


Dando de comida a los peces

Existen en el mercado sistemas para dar de comer a los peces de manera automática. En general se trata de sistemas que tienen un depósito más o menos grande de comida que se va dosificando poco a poco en tomas controladas por un temporizador horario.

Uno de los sistemas típicos, esquematizado en la figura siguiente, se basa en emplear un depósito grande "A" de comida unido a otro pequeño "B" en el que cabe sólo una dosis.


Dando un giro completo al depósito grande, se transfiere una pequeña cantidad de comida al depósito pequeño, la cual cae dentro del acuario al acabar una vuelta completa. Tal y como se muestra en la siguiente figura.

Funcionamiento de un alimentador típico

La rotación del depósito normalmente es contínua y lenta por lo que cada vez que el depósito pequeño "B" queda en la parte de abajo del depósito grande "A", cae una dosis de comida.

Para implementar esta solución se requeriría de:

  • Un depósito
  • Un motor
  • Un desmultiplicador
  • Un sistema de detección de origen

El motor hace girar el depósito, pero dado que los motores eléctricos normales giran demasiado rápidamente, es necesario desmultiplicarlos mediante engranajes para lograr la lenta velocidad de rotación que requiere el sistema. Adicionalmente, para saber cuantas vueltas se han dado y para dejar siempre el sistema en la misma posición de reposo, será necesario un sistema que permita indicar cuando el depósito pasa por una determinada posición.

Como deseamos un sistema lo mas sencillo posible, vamos a eliminar el desmultiplicador y el sistema de detección de origen. La propuesta es la mostrada en la siguiente figura:

Alimentador a implementar
Con la solución propuesta el depósito grande "A" ya no puede dar vueltas completas porque tienen un tope. En la posición de reposo "Stop 1" el depósito se halla contra el tope que limita el giro en la dirección horaria. A partir de ese punto se hace girar el depósito en dirección antihoraria hasta que llegue al tope en sentido contrario y se detenga en la posición "Stop 2". Después de que se alcance esta posición, se puede volver a mover el depósito, esta vez en sentido horario, para volver a la posición "Stop 1". Cada vez que el motor gira y pasa de una posición "Stop" a la otra, cae algo de comida en el acuario.

Con esta solución simplificada únicamente necesitamos:

  • Un depósito
  • Un motor

 Lo cual es realmente sencillo.

Para implementar el depósito "A" se ha elegido un bote cilíndrico de los que antes se empleaban para película fotográfica de 35mm. Para el depósito dosificador "B" pequeño se ha elegido un recorte de un blister de comprimidos de ibuprofeno. La siguiente figura muestra  el detalle del posicionamiento del depósito "B".

Detalle del depósito "B"

 Al depósito le insertaremos un eje que lo atraviesa para poder girarlo. La siguiente figura muestra el depósito con el eje y el tope que evita que pueda dar vueltas completas.

Depósito alimentador

Para garantizar que la comida llega siempre al depósito pequeño, situaremos el eje inclinado con el orificio de salida en la parte mas baja.
La siguiente figura muestra el soporte para el depósito de comida con el motor montado. El motor se ha recuperado de un radiocasette desmontado hace ya bastante tiempo.
El soporte se ha realizado sobre una plancha de aluminio. El motor (1) se ha pegado con cola de impacto. La pieza (2) es el tope que limita el giro del depósito. Las guías (3 ) y (4) encajan con el eje del depósito. Finalmente, el orificio triangular de la parte inferior (5) es por donde cae la comida.

Elementos del soporte del alimentador


En la siguiente figura se muestra un detalle del encaje del eje del depósito. El uso de una goma elástica para la transmisión del motor obliga al eje a apoyarse en el lado izquierdo del soporte.


Detalle del soporte del eje

La siguiente figura muestra el sistema alimentador completo. La transmisión entre el motor y el depósito se realiza mediante una goma elástica. Al motor se ha añadido un pequeño disco de madera que evita que la goma se salga del eje del motor.

Alimentador completo


Una vez diseñado el sistema alimentador, que es la única parte con una cierta complejidad mecánica, el resto es prácticamente todo electrónica.

En el siguiente artículo de sobre el acuario explicaré el esquema eléctrico empleado para el sistema.

Sigue con el diseño de la electrónica


lunes, 26 de marzo de 2012

Desarrollo Portable con Launchpad

Hace poco que hablé sobre el Launchpad. Una pequeña placa de desarrollo que Texas Instruments vende, yo diría que por debajo del precio de coste, para demostrar la serie de Microcontroladores Value Line de la familia MSP430.

Launchpad v1.4

No me extenderé a hablar sobre la placa en sí, ya que para eso está mi anterior artículo. Lo que explicaré es la manera de poner en marcha un entorno de desarrollo bajo Windows, portable y tan open source como es posible, que nos permita programar el launchpad.
Existen entornos de desarrollo profesionales que disponen de licencias gratuitas, limitadas en tamaño de código, que permiten trabajar con el Launchpad. Entre ellas, el Code Composer Studio dispone de una licencia gratuita que llega justo a los 16 kBytes de Flash del microcontrolador MSP430G2553 incluido en los últimos Launchpad de versión 1.5. De hecho, actualmente, no hay ningún microcontrolador dentro de la serie value line de la familia MSP430 que tenga más de 16kBytes de Flash.
Por tanto, en rigor, no es necesario hacer nada de lo que viene a continuación para trabajar con el Launchpad. No obstante la opción propuesta tiene otras ventajas:

  • Pude emplearse para compilar programas para otros microcontroladores de la familia MSP430 que soportan más de 16kB de Flash.
  • Se trata de un entorno basado en Eclipse, lo cual es muy práctico para los que ya conocen este entorno de programación, a parte de la calidad que tiene el entorno Eclipse en si mismo. Usar el entorno Eclipse para todos los procesadores con que uno trabaja evita la necesidad de aprender distintos entornos de programación propietarios.
  • Se trata de un entorno portable. Esto es, se puede mover de un ordenador a otro en un pendrive o en un disco duro portátil.
Desgraciadamente también hay un par de inconvenientes:

  • Los ejemplos que proporciona Texas Instruments, y muchos ejemplos disponibles en internet, se han realizado para los dos entornos preferidos IAR Embedded Workbench o Code Composer Studio. Es por ello que normalmente tendrán que hacerse algunas modificaciones en el código para que compile usando las herramientas propuestas. Eso incluye, especialmente, el procedimiento de definición de las Rutinas de Servicio de Interrupcion.
  • Para depurar programas, o cargarlos en la placa Launchpad, son necesarios los drivers USB de la placa y un par de ficheros DLL se soporte. Estos elementos no son en absoluto de código libre, si bien se pueden obtener gratuitamente tal y como se explicará más adelante.

Sin más preámbulos, pasemos a la acción:


Material Necesario


Para empezar necesitamos el entorno Eclipse Indigo. Se puede descargar de la página de descargas de Eclipse http://www.eclipse.org/downloads/


En mi caso el fichero es eclipse-cpp-indigo-SR2-incubation-win32.zip

Luego necesitamos el compilador gnu para msp430, lo encontraremos en la página de Sourceforge para el proyecto mspgcc http://sourceforge.net/projects/mspgcc/



Pulsamos el boton donwload y con ello descargamos el fichero zip que en mi caso es
mspgcc-20110716-p20120311.zip

Desgraciadamente esta distribución no contiene las utilidades make y rm que necesitamos para compilar los programas. Estas las obtendremos de Unxutils. El vínculo de descarga es:

De ello obtenemos el fichero UnxUtils.zip

Para poder depurar los programas necesitamos un servidor GDB y drivers USB para la placa Launchpad. Una parte del servidor GDB es de código libre y la otra parte, y los drivers USB, son propietarios.

La parte libre es el fichero msp430-gdbproxy.exe que podemos obtener de:

http://sourceforge.net/projects/mspgcc/files/Outdated/msp430-gdbproxy/2006-11-14/


No me consta ningún servidor GDB completo de código libre que pueda depurar aplicaciones sobre el Launchpad bajo Windows. Por tanto, tendremos que recurrir a algunos ficheros que se incluye en alguna aplicación comercial con licencia limitada gratuita.

La opción más sencilla es instalar IAR Embedded Workbench KickStart. Esta aplicación puede bajarse de http://www.ti.com/lit/zip/slac050. Una vez instalado necesitamos 2 cosas:

  • Drivers que permiten a Windows reconocer la placa Launchpad cuando se conecta al puerto USB. Estos drivers se hallan, después de instalar IAR Embedded Workbench, en 
        C:\Archivos de programa\IAR Systems\Embedded Workbench 6.0 Kickstart\430\drivers\TIUSBFET 
  
  • Ficheros msp430.dll y hil.dll que permiten la carga y depuración de código. Estos ficheros se hallan, después de instalar IAR Embedded Workbench, en 
         C:\Archivos de programa\IAR Systems\Embedded Workbench 6.0 Kickstart\430\bin

Actualización a 25/4/2012

Los ficheros  msp430.dll y hil.dll pueden obtenerse del fichero slac435b.zip de Texas Instruments.
Este fichero contiene la apliación Demo que viene preprogramada en el Launchopad.
Los ficheros de interés se hallan en el siguiente directorio dentro del fichero ZIP:

\MSP-EXP430G2-Launchpad User Experience\bin\MSP-EXP430G2-LaunchPad

Una vez tenemos estos ficheros, podemos dejar instalador IAR Embedded Workbench, si deseamos usar este entorno, o podemos desinstalarlo si sólo deseamos usar un entorno basado en Eclipse.

Existe una manera alternativa de obtener estos ficheros pero me parece demasiado complicada. Para los curiosos se puede obtener siguiendo los pasos que se explican aqui

Despues de todo el proceso tenemos que tener los siguientes elementos:

  • eclipse-cpp-indigo-SR2-incubation-win32.zip
  •  mspgcc-20110716-p20120311.zip
  • UnxUtils.zip
  •  msp430-gdbproxy.exe
  • Ficheros msp430.dll y hil.dll
  • Carpeta de drivers TIUSBFET de la placa Lauchpad 
Ya podemos empezar, pues, a instalar todo esto.


Preparando el disco externo

Como comenté anteriormente, la idea es disponer de un entorno portable de programación. Para ello resulta conveniente que el disco duro o pendrive que lo contiene se identifique siempre ante el sistema operativo con la misma letra de unidad. En mi caso he elegido emplear la letra "M", de manera que el disco se identificará siempre como M:

Si se desea instalar el entorno de programación de manera no portable, basta con saltar el resto de este apartado y emplear C: en todos los sitios donde diga M: del resto de este artículo.

Para cambiar la letra de una unidad, hemos de emplear el administrador de discos. Para acceder a él, en Windows XP, pulsamos el botón derecho sobre el icono Mi PC y seleccionamos Administrar.



Pulsamos sobre Administración de discos y, a continuación, pulsamos el botón derecho sobre el disco externo que queremos emplear para instalar el entorno de trabajo. Elegiremos Cambiar la letra y rutas de acceso de unidad...


Cambiaremos la letra a la que deseemos. Si se elige una letra que no sea "M", se tendrán que cambiar en consecuencia todas las referencias de directorios del resto de esta explicación.

En adelante, si no pasa nada extraño, el disco siempre se identificará en ese ordenador con la misma letra elegida. Este procedimiento se ha de repetir en cada ordenador donde se dese usar el entorno de programación portable.


Preparando los directorios

 Actualmente tengo en mi disco portátil 4 entornos de programación. Un entorno para Arduino, un entorno para PIC32-Pinguino, un entorno para STM32 bajo Eclipse y el entorno para MSP430 bajo Eclipse que es objeto de este artículo. Con objeto de evitar tener muchos directorios colgando de la raiz del disco, todos los entornos están dentro de M:\MCU

Dentro de M:\MCU crearemos un directorio msp, y dentro de éste pondremos la carpeta eclipse que se halla dentro del fichero eclipse-cpp-indigo-SR2-incubation-win32.zip.
A continuación crearemos 3 directorios dentro de M:\MCU\msp con nombres gdb proxy , mspgcc y workspace.
Dentro del directorio gdb proxy pondremos los ficheros msp430-gdbproxy.exe, msp430.dll y hil.dll
Dentro del directorio mspgcc pondremos el contenido de mspgcc-20110716-p20120311.zip
A continuación abriremos el fichero UnxUtils.zip y buscaremos la carpeta usr\local\wbin\ y tomaremos los ficheros make.exe y rm.exe y los pondremos dentro de M:\MCU\msp\mspgcc\bin
El directorio workspace, de momento, lo dejamos vacío.

Finalmente abriremos la carpeta M:\MCU\eclipse y pondremos un acceso directo del fichero eclipse.exe sobre la carpeta M:\MCU y lo renombraremos eclipse-msp430

Al final nos ha de quedar una estructura de directorios como la que sigue:


Probando Drivers y servidor GDB

Antes de comenzar a configurar Eclipse conviene comprobar que la instalación de los drivers y del Servidor GDB es correcta. Si no lo hemos hecho ya, instalaremos los drivers TIUSBFET que permiten acceder a la placa Launchpad. Si se ha probado exitosamente la programación de algún ejemplo de los que vienen con IAR Embedded Workbench KickStart, significa que los drivers se han instalado correctamente.

En todo caso, la mejor manera de comprobarlo es enchufar la placa Launchpad a uno de los puertos USB disponibles y abrir el Administrador de dispositivos de Windows.

En Windows XP: MiPC -> Administrar -> Administrador de dispositivos
o en Panele de Control -> Herramientas Administrativas -> Administrador de equipos

En Windows 7 lo podemos hallar dentro del panel de control



Debería aparecer MSP430 dentro Puertos (Com & LPT)




Una vez que vemos que se reconoce correctamente, abrimos una ventana de comandos, nos vamos a
M:\MCU\msp\gdb proxy 
y ejecutamos
msp430-gdbproxy msp430 --spy-bi-wire TIUSB

debería aparecer una pantalla como la siguiente:




Una vez verificado que funciona el servidor GDB, lo apagaremos con Ctrl+C

Configurando Eclipse

Una vez que sabemos que el debugger funciona, podemos empezar a configurar eclipse. Abrimos eclipse con el acceso directo que creamos anteriormente en M:/MCU y nos aparecerá una ventana solicitando el workspace que deseamos usar. Emplearemos el directorio:
M:\MCU\msp\workspace
Si no deseamos que nos vuelva a preguntar sobre ello, podemos seleccionar la casilla "Use this as the default folder for this session"


Nos aparecerá la ventana principal de eclipse. Antes de continuar hemos de instalar en eclipse el soporte para Debug GDB, para ello seleccionaremos Install New Software... dentro del menú Help.
Dentro de "Work with" elegiremos la opción desplegable --All Available Sites--
En la casilla de búsqueda que hay debajo podremos GDB Hardware debugging
Nos saldrá la opción C/C++ GDB Hardware Debugging y la seleccionaremos con el cuadro que hay a su izquierda. A continuación pulsamos Next.


Aceptamos la licencia y pulsamos Finish


A continuación permitiremos que eclipse vuelva a arrancar antes de continuar


Con ello volvemos otra vez a la pantalla principal de eclipse. Si nos aparece la pantalla que se muestra a continuación, pulsaremos sobre la X recuadrada en rojo.


Con ello tendremos la vista normal para desarrollo C/C++ en eclipse.



Creando un proyecto

 Para hacer el resto de configuraciones, crearemos un nuevo proyecto sencillo que hará parpadear un led en la placa Launchpad. Para ello Elegimos New->C Project


En "Project name" pondremos Blinky
Seleccionaremos Cross-Compile Project y Cross GCC y pulsaremos Next


En "Tool Command prefix" pondremos msp430-
En "Tool Command path" pondremos M:\MCU\msp\mspgcc\bin


Con ello tendremos un nuevo proyecto Blinky tal y como se muestra en la figura.


Deseamos crear una carpeta para los ficheros fuentes dentro del proyecto. No es estrictamente necesario pero ayuda a tener las cosas ordenadas. Para ello seleccionaremos el proyecto Blinky y, apretando el botón derecho del ratón abriremos el menú contextual con el que seleccionaremos New->Folder


Pondremos src en "Folder name" y pulsaremos Finish


Ahora crearemos el fichero main.c, para ello abriremos el menú contextual sobre la carpeta src y elegiremos New->File


Con ello aparecerá una pantalla como la que se muestra a continuación.


Pondremos main.c en "File name" y pulsaremos Finish

Con doble click abriremos el fichero main.c recien creado y copiaremos dentro el siguiente texto:


/* main.c */

// Include the register definitions. Note that we do not
// use a device specific include file, the compiler handles
// that based on the -mmcu option

#include <msp430.h>
#include <msp430g2231.h>

int main()    // The main function
 {          
 //volatile unsigned int i = 0;
 unsigned int i = 0;

 // Disable the watchdog.
 // The watchdog is on by default on an     * MSP430,
 // if we do not disable it it will reset the CPU
 // after * 32k cycles in the standard configuration. */

 WDTCTL = WDTPW + WDTHOLD;

 // set P1.0 as output
 P1DIR = BIT0;

 // do forever:
 while (1)
     {
     i++;
     if (i == 0)
          {
          // Flip the value of P1.0's output register
          // when i * overflows to zero
          P1OUT ^= BIT0;
          }
     }
  }

La ventana debería quedar más o menos así:




Configurando el proyecto

Ya tenemos el proyecto con todo su código. Lo que resta, que no es poco, es configurar eclipse para que sepa como compilarlo.

Comenzaremos eligiendo Properties en el menu contextual del proyecto Blinky
Abriremos el desplegable C/C++ Build de la subventana izquierda y seleccionaremos Includes bajo Cross GCC Compiler. Pulsaremos la casilla "+" y añadiremos el path:
M:\MCU\msp\mspgcc\msp430\include


A continuación seleccionaremos Miscellaneous dentro de Cross GCC Compiler y escribiremos la información sobre el procesador para el que se desea que trabaje el Compilador dentro de "Other flag"

-c -fmessage-length=0 -mmcu=msp430g2231

La línea anterior corresponde al procesador que viene en el Launchpad v1.4. Existen un total de 4 procesadores distintos en la plataforma launchpad dependiendo de si es la versión 1.5 o anterior y dependiendo de si es el procesador que viene montado en la placa o el otro que viene en una bolsita antiestática. En la línea anterior se ha de ponder el que pertoque:

-mmcu=msp430g2231  MCU montado en launchpad v1.4 y anteriores
-mmcu=msp430g2211  MCU en bolsita en launchpad v1.4 y anteriores

-mmcu=msp430g2553  MCU montado en launchpad v1.5
-mmcu=msp430g2452  MCU en bolsita en launchpad v1.5

En todo caso el fichero main.c, dado que tiene una línea:
#include <msp430g2231.h>
hace referencia a la primera opción. Caso de emplearse otro procesador, también se ha de cambiar la línea #include


El Linker también se debe configurar. Se hará eligiendo Miscelaneous bajo Cross GCC Linker.

Elegiremos el mismo procesador elegido para el compilador y, añadiremos también un flag que hará que se genere el fichero linker.map. Este fichero es opcionaly nos permite saber como queda el código dentro del mapa de memoria del microcontrolador.
Para el caso del MSP430G2231 los flags quedan así:

-mmcu=msp430g2231 -Wl,-Map=linker.map,--cref


A continuación fijaremos la configuración del Ensamblador de manera similar a la realizada para el Compilador. Seleccionaremos General bajo Cross GCC Assembler y pondremos:

Flags: -mmcu=msp430g2231 (u otro Microcontrolador si hace falta)
include: "M:\MCU\msp430\mspgcc\msp430\include"



A continuación hemos de añadir algun path para los includes. Para el proyecto Blinky no es necesario, ya que no tiene includes en el directorio src, pero es buena idea hacerlo para no olvidarlo en otros proyectos más complejos. Seleccionaremos el la subventana izquierda C/C++ General -> Paths and Symbols.
Seleccionamos GNU y miramos que aparezca el path
M:\MCU\msp430\mspgcc\msp430\include
tal y como se muestra en la siguiente ventana.
Es posible que aparezcan mas directorios pero no os preocupeis por ellos.



A continuación pulsamos el botón Add... para añadir otro path.
Escribiremos  /${ProjName}/src y nos aseguramos de que is a workspace path esté seleccionado
A continuacion pulsaremos OK


A continuación hemos de indicar en que directorios se hallarán los ficheros C que se deben compilar. Para ello seleccionaremos la pestaña "Source Location" y verificaremos que se hallen los directorios /Blinky y /Blinky/src. Si falta alguno, lo añadiremos con el botón Add Folder...


El siguiente paso es opcional. En la pestaña "Build Steps" dentro de C/C++ Build -> Settings es posible indicar programas que se han de ejecutar antes y después de Compilar. En la figura siguiente se muestra que se ha añadido un comando Post-build, esto es, que se ejecutará después de compilar.
Command: msp430-size  "${ProjName}
Description: Project Size
Este comando hará que después de compilar se muestre en la cónsola el espacio ocupado por el código. De esta manera es fácil saber si se está alcanzando el límite disponible en el microcontrolador elegido.


Pulsamos OK y con ello acaba la configuración del proyecto Blinky.

Compilando el proyecto

Una vez acabada la configuración del proyecto, podemos pasar a compilarlo. Para ello Elegiremos Build Project dentro del menú Project.


Si todo va bien debería acabar la compilación correctamente y mostrarse el tamaño del binario generado que en nuestro caso es de 142 bytes.



Carga y depuración del programa

Para cargar y depurar el programa en la placa Launchpad emplearemos el Servidor GDB que probamos previamente. Lo arrancaremos desde la interfaz de usuario de Eclipse, para ello seleccionaremos External Tools Configurations... dentro del menú de herramientas (Un triángulo y una maleta).


Seleccionaremos Program y pulsaremos el botón "+"



Rellenaremos las siguientes casillas:

En "Name" pondremos GDB Server
En "Location" buscaremos con Browse File System... el lugar donde se halla instalado el servidor GDB
M:\MCU\msp\gdb proxy\msp430-gdbproxy.exe
En Arguments pondremos: msp430 --spy-bi-wire TIUSB


Despues de ello pulsaremos Run y debería aparecer un mensaje como el que sigue indicando que el servidor GDB está en marcha.


Una vez que tenemos el servidor GDB, hemos de de crear una sesión de debug para el proyecto Blinky

Seleccionaremos Debug Configurations... dentro del menú de Debug (Un Escarabajo)



Allí seleccionaremos GDB Hardware Debugging y pulsaremos "+"


Rellenaremos los campos:

Name: Blinky Debug
Project: Seleccionaremos Blinky con Browse...
C/C++ Application: Seleccionaremos Debug/Blinky con Browse...


Seleccionaremos ahora la pestaña "Debugger" y rellenaremos los campos:

GDB Command: msp430-gdb
Port Number: 2000


Seleccionamos la pestaña "Startup" y añadimos la siguiente linea a la ventana de comandos:
monitor erase main
Seguidamente pulsamos el botón Debug


El programa se cargará en la placa y Eclipse nos recomendará cambiar a la perspectiva de Debug. Pulsaremos Yes para aceptar.


Aparecerá la perspectiva de Debug. Usando esta perspectiva es posible depurar el programa mediante ejecución paso a paso, visualización de variables y establecimiento de breakpoints.
De momento arrancaremos el programa con el botón de ejecución que se muestra en la siguiente ventana.
El led de la placa launchpad debería empezar a parpadear.


Mientra corre el programa están disponibles los distintos botones de control de depuración y podemos observar el valor de las variables y el punto donde se ha detenido el programa debido a un breakpoint o a la pulsación del botón de pausa. La explicación sobre como hacer la depuración lo dejaremos para otro artículo.


Cuando acabemos de ejecutar el programa, podemos pararlo mediante el botón de parada (Rectángulo rojo). No nos olvidemos de parar también el servidor GDB cuando acabe el proceso de depuración.


Hasta aquí todo lo necesario para compilar y depurar programas. Lo que queda del artículo es completamente opcional.


Comandos adicionales (Opcional)

 Es posible añadir herramientas adicionales a eclipse. A continuación explicaré como añadir herramientas para ver el tamaño de todo un proyecto o uno de sus componentes.

Crearemos una nueva herramienta externa igual que lo hicimos con el servidor GDB, pero en este caso pondremos los siguientes valores:

Name: Project Size
Location: M:\MCU\msp\mspgcc\bin\msp430-size.exe
Working Directory: ${project_loc}/Debug
Arguments: ${project_name}
 


Ejecutaremos este comando seleccionando previamente uno de los proyectos. Blinky, por ejemplo.


El resultado aparecerá en la consola.


El comando anterior es para saber el espacio total asociado a un proyecto. Para saber el espacio ocupado por uno de los ficheros objeto, podemos crear otra herramienta.

Name: Resource Size
Location: M:\MCU\msp\mspgcc\bin\msp430.size.exe
Working Directory: ${container_loc}
Arguments: ${resource_loc}



Este comando lo podemos usar seleccionando previamente cualquier fichero objeto.


El resultado aparecerá en la consola


Las dos aplicaciones que hemos añadido son accesibles, después de su primera ejecución, en el menú contextual de aplicaciones externas.



Creación de otros proyectos

Para crear otro proyecto, la opción más sencilla es seleccinar el proyecto Blinky y pulsar Ctrl+C seguido de Ctrl+V. Con ello aparecerá una ventana que nos permitirá dar nombre al nuevo proyecto que será un clon del proyecto Blinky. Por tanto, no será necesario volver a configurarlo y bastará modificarlo para las nuevas necesidades del proyecto.

Para dejar limpio el nuevo proyecto haremos los siguientes pasos:

Deseleccionaremos Build Automatically del menú Project
Elegiremos Clean... en el menú Project, comprobaremos que se halla seleccionado el nuevo proyecto y pulsaremos OK.

Adicionalmente podemos borrar los ficheros adicionales del directorio Debug como linker.map

Con ello tendremos un proyecto vacío y configurado con el que empezar una nueva apliacación.

Referencias

La siguiente página me ha sido de mucha utilidad para desarrollar todo lo explicado en este artículo