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í:

https://github.com/energia/Energia/wiki/Getting-Started

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.

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.

Codigo en Github (11/02/2018)

El código está ahora disponible en Github:

https://github.com/R6500/MSP430-DCO-Calibration

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

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

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:

http://sourceforge.net/projects/unxutils/files/latest/download?source=files

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

http://springuin.nl/en/articles/launchpadwindows

También me ha sido de utilidad una descripción similar para la placa STM32 VL DISCOVERY

http://sites.google.com/site/stm32discovery/open-source-development-with-the-stm32-discovery/setting-up-eclipse-for-stm32-discovery-development