martes, 22 de julio de 2014

msp430 toolchain en Ubuntu 14.04 - parte IV: proyecto Blinker

Finalmente!!!, ya estamos listos para usar nuestro flamantes eclipse, mspgcc, y mspdebug.

Actualización (con presentación queda más bonito):



Dejo para referencia la entrada original:


Dentro de eclipse tenemos que instalar el paquete que permite usar gdb con hardware:
Help-> Install New Software...


Verificar tener los siguientes repositorios instalados:
http://download.eclipse.org/tools/cdt/releases/8.4
http://download.eclipse.org/releases/luna
http://download.eclipse.org/eclipse/updates/4.4



Damos Ok, volvemos a la pantalla anterior, y en el campo Work with elegimos
CDT luna o All Available Sites
En el cuadro de busqueda escribir: gdb hardware
Y chequear el C/C++ GDB Hardware Debugging  debajo de CDT Optional Features.


Continuar con la instalación, (next, aceptar licencia, etc).

Configuración del compilador

File-> New -> C Project
Project name: Blinker
Project type: Empty Project
Toolchains: cross gcc


Next, Next,


Finish

File -> New -> Source File
Source file: main.c
Finish 


Copiar y pegar en la página de código:

#include <msp430.h>

int main(void)
{
    WDTCTL = WDTPW + WDTHOLD;
    P1DIR |= BIT0;
    while(1)
    {
        P1OUT ^= BIT0;
        __delay_cycles(1000000);
        __nop();

    }

    return 0;
}


En la ventana Project Explorer click derecho sobre Blinker -> Properties
Ir a C/C++ Build -> Settings
En el otro marco: pestaña Tool Settings -> Cross Settings
Path: /usr/local/msp430


Dentro de Cross GCC compiler agregar definición de símbolo __MSP430G2452__ (micro que tengo puesto en el Launchpad en este momento, si esa puesto el msp430g2553 -> __MSP430G2553__ ). Este paso no es estrictamente necesario (alcanza con los flags de compilación que se definen a continuación), pero viene bien para que el índice reconozca los nombres de registro, bits, etc (P1OUT, BIT0, WDTCTL...):



 En Miscellaneous agregar el flag: -mmcu=msp430g2452


Idem anterior en Cross GCC Linker-> Miscellaneous.
Los flags -Wl, -Map=memory.map hacen que el linker genere un mapa de memoria. Para este proyecto no tiene sentido, pero es útil para proyectos reales donde queremos saber segmentos de memoria, librerías incluídas, direcciones de funciones y variables, etc.


Idem en Cross GCC Assembler -> General


Opcionalmente, en la pestaña Build Steps podemos usar Post-build Steps para ejecutar algún programa o script. En este caso hacemos que al terminar de compilar nos muestre el uso de memoria del proyecto:
Command -> msp430-size ${ProjName}
Description: Uso de memoria


Listo, damos al botón de Ok y menu Project -> Build Project.
En la consola nos debería salir que salió todo bien:


Configuración mspdebug

En la ventana Project Explorer->click derecho sobre Blinker -> Debug As -> Debug Configurations
Seleccionar GDB Hardware Debugging y click sobre el ícono nuevo arriba a la izquierda:


Dejamos la pestaña Main sin modificar.
Pestaña Debugger: poner en GDB Command: msp430-gdb y en cuadro Port Number: 2000 (es el que utiliza por default el mspdebug)


Pestaña de Startup:
Esto ya es una cuestión de gustos. Personalmente no quiero que al iniciar una sesión de depuración se grabe un programa nuevo, por eso desmarco la casilla Load Image. Muchas veces corto la depuración o se cuelga y necesito empezar desde el principio con el mismo programa que estaba grabado antes (es decir, sin cambios de código entre sesiones de depuración).
Cuando tengo que cargar un programa o imagen nueva lo hago desde el mspdebug. No presionar el botón Debug todavía nos falta ejecutar mspdebug.


Enchufar el launchpad, abrimos un terminal (Ctrl-Alt-T) y ejecutamos:
mspdebug rf2500


Ya dentro de mspdebug:
prog Blinker
gdb

Listo, ahora mspdebug deja un servidor gdb abierto en el puerto 2000. Volvemos a eclipse y ahora sí hacemos click sobre el botón Debug, nos aparece esta ventana:


Opcional: eclipse se queja de que no encuentra el código fuente crt0.s
Si hay interes en depurar el código de inicialización (que es el encargado de inicializar constantes en RAM, la pila, librerías estandar, y demás código que utiliza C para funcionar), el archivo crt0.s se encuentra en la carpeta de instalación:
~/Install/mspgcc/gcc-4.7.0/libgcc/config/msp430/crt0.S
Si no interesa ver ese código, podemos hacer caso omiso.
Así queda la configuración si incluimos crt0.S:

 
Ir a la pestaña de código main.c, pararse con el cursor en la línea siguiente a
WDTCTL = WDTPW + WDTHOLD;
en este caso la línea:
P1DIR |= BIT0;
Y presionar CTRL + R. Con esto ejecutamos código hasta el cursor.
¿Por qué la línea siguiente?, porque con esa instrucción detenemos el watchdog, caso contrario si no la ejecutamos rápido el watchdog va a resetear el micro y vuelta al principio. Ignorar la flecha roja:


En este punto ya podemos depurar paso a paso, insertar breakpoints, ver valores de variables, etc.
Una vez terminada la sesión de depuración, presionamos sobre el cuadrado rojo arriba a la izquierda, y volvemos a la vista de programación clickeando en el botón C/C++ arriba a la derecha:

 
 
En la ventana de terminal ya nos aparece el prompt (mspdebug) listo para aceptar comandos:



Normalmente solo uso los comandos:
prog para cargar una nueva imagen,
gdb para aceptar la conexión de eclipse,
reset cuando reinicio una sesión de depuración con eclipse,
y claro, exit para salir del mspdebug.

No desenchufar el Launchpad hasta haber salido del mspdebug.

Al depurar con eclipse puede pasar que el programa se cuelgue, y no tengamos respuesta al ejecutar paso a paso, ni podamos ejecutar comandos en el terminal con mspdebug. En tal caso terminar la sesión de depuración en eclipse, y en el terminal mspdebug presionar Ctrl-C para interrupir la ejecución de código.
Conviene reiniciar mspdebug con el comando reset y luego empezar a depurar desde el principio.

Listo, ojalá sirva para ahorrarles dolores de cabeza (con que le pase a una persona ya alcanza) y puedan tener un comienzo más feliz con los msp430 utilizando herramientas libres.

Proxima entrada:
Las instrucciones paso a paso libres de palabrerío, para no tener que leer los 4 artículos para tener todo funcionando.

lunes, 21 de julio de 2014

msp430 toolchain en Ubuntu 14.04 - parte III: eclipse CDT luna

Actualización: hice un resumen para ejecutar todo desde la consola utilizando comandos, si quieren ahorrarse el palabrerío: Eclipse

Instalación


La última versión de eclipse disponible en los repositorios de Ubuntu (3.8) no es la última (4.4) como suele pasar.

Siguiendo la guía:
http://tutorialforlinux.com/2014/04/14/how-to-install-eclipse-4-4-luna-standard-on-ubuntu-14-04-trusty-lts-32-64bit-easy-visual-guide/

Descargamos el paquete CDT para linux 64 bits (creo que no mencioné eso antes: todo esta compilado/instalado sobre 64 bits):
http://www.eclipse.org/downloads/index-developer.php?Luna


Extraer en /tmp:


Desde el terminal, instalar:

sudo su -c "chown -R root:root /tmp/eclipse && mv /tmp/eclipse /opt/eclipse"
sudo su -c "ln -s /opt/eclipse/eclipse /usr/local/bin/eclipse"

Y ya debería poder ejecutarse ejecutando desde el terminal:
eclipse

Si - como me pasó a mí - sale un error diciendo que no encuentra una instalación de JVM, o la versión instalada es anterior a la requerida, o preferimos usar una versión específica para el eclipse Luna (quizás distinta a la instalada por default), entonces precisamos instalar JDK.
Si funciona entonces no se compliquen la vida y salteen este paso, que complicaciones nunca faltan.

JDK


A continuación instalamos el JDK, hay 3 variantes: OpenJDK, IBM JDK, Oracle JDK.
Eclipse Luna está testeado y desarrollado sobre plataformas predefinidas, y para ubuntu 14.04 amd64 figuran las versiones:
http://www.eclipse.org/eclipse/development/readme_eclipse_4.4.html#TargetOperatingEnvironments



Cuando hice la instalación la ultima versión disponible en la página de Oracle era la 8u5, ahora es la 8u11:



Link de descarga:
http://download.oracle.com/otn-pub/java/jdk/8u11-b12/jdk-8u11-linux-x64.tar.gz
Para instalar seguimos la guía:
http://tutorialforlinux.com/2014/03/15/how-to-install-oracle-jdk-8-on-ubuntu-14-04-trusty-32-64bit-easy-guide/

Una vez bajado abrir un terminal en la carpeta de descarga:
tar xvzf jdk-8*.tar.gz -C /tmp/
sudo su
if [ ! -d '/usr/lib/jvm' ]; then mkdir /usr/lib/jvm; fi
chown -R root:root /tmp/jdk1.8* && mv /tmp/jdk1.8* /usr/lib/jvm/

update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8*/bin/java 1065
update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/jdk1.8*/bin/javac 1065
update-alternatives --install /usr/bin/jar jar /usr/lib/jvm/jdk1.8*/bin/jar 1065
update-alternatives --install /usr/bin/javaws javaws /usr/lib/jvm/jdk1.8*/bin/javaws 1065

Con eso termina la instalación, verificar con el comando
update-alternatives --config java


En mi máquina tengo varias jvm instaladas, porque hice un lío para que funcione y ahora tengo 4 JVM :P
Allí se puede marcar la opción que utiliza Ubuntu por default como máquina virtual de Java (no solo para Eclipse, para cualquier programa que ejecute java).

Por último salimos de su con el comando:
exit

JVM alternativa para Eclipse (opcional)


Una alternativa que puede ser útil por si queremos usar una versión de JVM específica para eclipse Luna y una versión distinta para el resto del sistema, es editar el archivo:
/opt/eclipse/eclipse.ini
Como se indica en:

Verificar primero que funcione con la máquina virtual candidata, por ejemplo:
eclipse -vm /usr/lib/jvm/jdk1.8.0_05/bin/java

Y que NO nos salga una pantalla como;  sino elegir o instalar otra máquina virtual.:

Una vez que vemos que eclipse arranca sin problemas, entonces ya podemos editar:
daniel@daniel-desktop:~$ sudo gedit /opt/eclipse/eclipse.ini 

Agregamos las líneas:
-vm
/usr/lib/jvm/jdk1.8.0_05/bin/java


justo encima de la línea -vmargs:


Launcher en Unity

Sí, es una sección aparte porque Unity nos complica la vida.
Hay innumerables formas de crear un acceso directo para unity, :
https://help.ubuntu.com/community/UnityLaunchersAndDesktopFiles

Lo que yo hice fue abrir el gedit y escribir:
[Desktop Entry]
Version=4.4
Name=Eclipse Luna
Comment= JVM: JDK1.8.0_05
Exec=/opt/eclipse/eclipse
Icon=/opt/eclipse/icon.xpm
Terminal=false
Type=Application
Categories=Utility;Application;


Guardar en el escritorio como eclipse.desktop.
En el escritorio hacer click derecho -> propiedades, hoja de permisos y chequear casilla de permiso de ejecución.
Hecho eso ya nos aparece un icono como:


Para agregarlo al launcher ejecutar con el acceso directo del escritorio, nos aparece en la barra del launcher a la izquierda, donde podemos hacerle click con el botón derecho y seleccionar "lock to launcher".

Para que el acceso directo quede disponible a todos los usuarios de la máquina es conveniente mover el acceso directo del escritorio a /usr/share/applications:
daniel@daniel-desktop:~/Desktop$ sudo cp eclipse.desktop /usr/share/applications/

Proyecto de prueba


Dentro de eclipse: menu File -> New -> C Project:

Project name: a elección
Project type: Hello World ANSI C Project
Toolchains: Linux GCC
botón Finish

Para compilar el proyecto

Menu: Project -> Build Project

En la consola de compilación debería aparecer algo como (sin errores):

Luego podemos correr el programa con el icono run y aparecer Hello World en la consola:



FIN!!!.

  1. En el próximo artículo integramos el eclipse Luna con mspgcc, y hacemos parpadear un led con el launchpad.
  2. Y en el artículo siguiente un resumen de todos los pasos sin palabrerío, solo con instrucciones de descarga, configuración e instalación.

domingo, 20 de julio de 2014

msp430 toolchain en Ubuntu 14.04 - parte II: mspdebug

Actualización: hice un resumen para ejecutar todo desde la consola utilizando comandos, si quieren ahorrarse el palabrerío: mspdebug

Con mspdebug vamos a poder programar y depurar prácticamente cualquier herramienta de desarrollo y microcontrolador msp430. El reloj Chronos (ez430), launchpad, fet target boards, placas de Olimex, programador/depurador FET etc, etc.
Antes del proyecto mspgcc había otro proyecto llamado mspgcc4 que trabajaba con un programa gdb-proxy.

Pero el mspdebug realiza las funciones del gdb-proxy, además de la interfaz con el depurador o el microcontrolador.

El sitio es:
http://mspdebug.sourceforge.net/
La última versión se encuentra en:
http://sourceforge.net/projects/mspdebug/files/

La última versión a la fecha es la 0.22:
http://sourceforge.net/projects/mspdebug/files/mspdebug-0.22.tar.gz/download
Descomprimir, make, sudo make install y listo.
Puede ser necesario compilar con
make WITHOUT_READLINE=1
si no está instalado el paquete libreadline-dev (verificar con synaptic).
make 2>&1 | tee mo
sudo make install 2>&1 | tee moi

Agregado 2 de Julio de 2014:
Si sale error:
In file included from util/usbutil.c:22:0:
util/usbutil.h:22:17: fatal error: usb.h: No such file or directory

Es porque falta instalar el paquete libusb-dev (que no es lo mismo que libusb-1.0.0-dev !!!):
sudo apt-get install libusb-dev

Vamos a comprobar si mspdebug funciona:
Al enchufar el launchpad deberíamos poder comunicarnos con él ejecutando
sudo mspdebug rf2500
Nos va a aparecer algo como esto:

Desde allí ya podemos escribir/leer programas al msp430. Generalmente en este punto lo único que hago es ejecutar el comando gdb y comandarlo a través del eclipse.
Podemos salir con exit y ya podemos desenchufar el launchpad.

No queremos estar llamando a mspdebug con sudo todo el tiempo, por eso agregamos reglas a udev para que nuestro usuario de ubuntu tenga permisos de lectura y escritura.

udev


/etc/udev/rules.d$ sudo gedit 61-TI.rules

udev se encarga entre otras cosas de manejar lo que enchufamos al puerto usb y decidir los permisos de acceso que tiene nuestro usuario. Las reglas se aplican secuencialmente y una puede anular a la otra. El orden de aplicación de la regla viene dado por el número al principio del nombre de archivo. Elegí 61 arbitrariamente, he visto que algunos usan 40, otros 90... en fin; no deberíamos tener problema con ninguna de esas opciones.
El resto del nombre de archivo también es a elección.
Mi archivo contiene las siguientes líneas:
ATTRS{idVendor}=="0451", ATTRS{idProduct}=="f432", MODE="0660", GROUP="plugdev" #Launchpad v1.5
ATTRS{idVendor}=="2047", ATTRS{idProduct}=="0010", MODE="0660", GROUP="plugdev" #msp-fet430uif


Para más información sobre udev hay buena información en hackaday:
http://hackaday.com/2010/08/11/how-to-launchpad-programming-with-linux/
http://hackaday.com/2009/09/18/how-to-write-udev-rules/

¿Y de donde obtengo idVendor y idProduct?.
Al enchufar el launchpad (o el FET, o el reloj Chronos...), podemos verlo con:
lsusb


En la línea resaltada aparece la entrada del launchpad, 0451 es el VID (vendor ID) y f432 el PID (product ID).
Si queremos ver información adicional del dispositivo (interfaces, endpoints...), podemos hacer
lsusb -s 004:003 -v

Agregamos una línea por herramienta de desarrollo.
Luego de eso debemos agregarnos al grupo groupdev:
sudo addgroup tu_nombre_de_usuario plugdev.

Y reiniciamos el servicio udev:
sudo service udev restart

TILIB v3

Guía:
https://rtime.felk.cvut.cz/hw/index.php/MSP430F5529_Launchpad#MSP430.DLLv3

Si queremos usar la librería tilib que provee TI para depurar:
http://processors.wiki.ti.com/index.php/MSP_Debug_Stack
Debemos bajar el archivo slac460 (actualmente versión "i"):
http://processors.wiki.ti.com/index.php/MSPDS_Open_Source_Package
http://www-s.ti.com/sc/techzip/slac460.zip

Descomprimir e ir a la carpeta MSPDebugStack_OS_Package.
Según README-BUILD es necesario bajar/compilar/instalar libboost, yo instalé el paquete libboost-all-dev con synaptic para ahorrarme la espera (versión 1.54.0.1ubuntu1). Y aprovechando el synaptic abierto, instalamos dependencias:
libudev-dev (agrega una parva de paquetes para instalar), libfox-1.6-0 (debería estar dentro del conjunto anterior), autotools-dev, autoconf, automake, libtool.

Luego bajamos
https://github.com/signal11/hidapi/downloads
La versión actual es la 0.7.0. Descomprimir y editar el archivo
/hidapi-0.7.0/linux/Makefile
Reemplazar
CFLAGS   ?= -Wall -g
por
CFLAGS   ?= -Wall -g -fPIC

CXXFLAGS ?= -Wall -g
por
CXXFLAGS ?= -Wall -g -fPIC

LIBS      = `pkg-config libusb-1.0 libudev --libs`
por
LIBS      = `pkg-config libusb-1.0 libudev --libs` -lpthread

Guardar y compilar:
/hidapi-0.7.0/linux$ make

Copiar /hidapi-0.7.0/linux/hid-libusb.o
a /MSPDebugStack_OS_Package/ThirdParty/lib/

y /hidapi-0.7.0/hidapi/hidapi.h
a /MSPDebugStack_OS_Package/ThirdParty/include/

Ahora sí podemos compilar tilib con make:
daniel@daniel-desktop:~/Install/mspgcc/tilib/MSPDebugStack_OS_Package$ make

Copiar libmsp430.so a /usr/local/lib:
daniel@daniel-desktop:/usr/local/lib$ sudo cp /home/daniel/Install/mspgcc/tilib/MSPDebugStack_OS_Package/libmsp430.so


Vamos a probarlo. Enchufar el msp-fet430uif y ejecutar
mspdebug tilib --allow-fw-update
para actualizar el firmware.

Entonces ahora sí debería funcionar al ejecutar
mspdebug tilib

O casi... usualmente tengo que ejecutar 3 o 4 veces antes de que el mspdebug pueda conectarse:



Bueno... quizás más veces :(
Desconozco si se debe a algún error de instalación o estoy haciendo algo mal.
El último error es porque no nay nada enchufado al depurador.



Fuentes:
  1. Instalación mspdebug-0.20:
    http://energy.eecs.umich.edu/wiki/doku.php?id=msp430:mspgcc:start
  2. msdebug-0.21:
    http://richardnaud.wordpress.com/2013/10/02/installation-of-eclipse-cdt-msp430-gcc-4-7-0-mspdebug-0-21-and-more-on-ubuntu/
  3. https://rtime.felk.cvut.cz/hw/index.php/MSP430F5529_Launchpad

msp430 toolchain en Ubuntu 14.04 - parte I: mspgcc

Preliminar

Primero: es doloroso instalar el toolchain desde los fuentes. La primera pregunta debe ser ¿por qué molestarse en instalar desde los fuentes en vez de usar los paquetes de los repositorios de Ubuntu?.
La versión estable anterior no soporta direccionamiento/registros de 20 bits, esto significa que si tenemos un micro con 128 KB de memoria flash solo vamos a poder usar 64 KB porque el compilador no permite manejar direcciones más allá.
http://forum.43oh.com/topic/5444-msp430-gcc-does-it-support-20-bit-addressing/

Pero al final termina siendo más una cuestión de aprendizaje (y orgullo) que de utilidad. Porque estoy seguro de que al ser una rama de desarrollo van a surgir multitud de problemas al compilar programas, librerías, etc.
¿Cual es el futuro?, empezar a usar la versión de mspgcc ofrecida por TI, porque mspgcc no seguirá siendo desarrollado por pabigot y le da la posta:
http://www.ti.com/tool/MSP430-GCC-OPENSOURCE
Traté de instalarlo pero no salió a la primera (al ejecutar el .run no pasa nada), así que supongo será una futura (o inexistente) entrada del blog.

Podría haber escrito un script de instalación que automatice todo, pero los scripts no funcionan a menos que tengo la misma distribución de linux, la misma versión de todos los paquetes, etc. Lo más probable es que al ejecutar el script haya errores y no se termine de ejecutar, y queden librerías a medio compilar desparramadas en el home y en /usr

Hechas las consideraciones metafísicas pasemos al proceso de instalación. Voy a tratar de cubrir instalación del toolchain, mspdebug, eclipse-cdt luna y su configuración para trabajar con mspgcc.
En otros palabras, llegar a tener un proyecto de led parpadeando y poder depurarlo desde eclipse.

Actualización: hice un resumen para ejecutar todo desde la consola utilizando comandos, si quieren ahorrarse el palabrerío: mspgcc

Instalación del toolchain

Dependencias y descargas


sudo apt-get install patch ncurses-dev build-essential bison flex libgmp3-dev libmpfr-dev libmpc-dev zlib1g-dev

Siguiendo [3], desinstalar texinfo si ya está de antemano, e instalar los siguientes paquetes (dependencias):
sed (>=4.2.1-9), bison (>=1:2.4.1), automake (>=1.11.1), gawk (>=3.1.8),mawk (>=3.1.8), libusb-1.0.0, libusb-1.0.0-dev, libreadline6-dev, dos2unix, srecord
Descargar e instalar:
https://packages.debian.org/wheezy/amd64/texinfo/download
En lo personal solo tuve problemas con texinfo al construir gdb, no con binutils ni gcc

Descarga fuentes:
En mi caso lo instalo en Install/mspgcc
http://sourceforge.net/projects/mspgcc/files/mspgcc/DEVEL-4.7.x/mspgcc-20120911.tar.bz2/download
ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.22.tar.bz2
ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.7.0/gcc-4.7.0.tar.bz2
ftp://ftp.gnu.org/pub/gnu/gdb/gdb-7.2a.tar.bz2

Notas: las versiones de gcc/gdb/binutils son las indicadas en los archivos .patch que contienen no solo eso sino también instrucciones de compilación e instalación. No dejar de leerlos, como también el README de mspgcc.

Parches adicionales por bugs (guía contiki):
http://sourceforge.net/p/mspgcc/bugs/_discuss/thread/fd929b9e/db43/attachment/0001-SF-357-Shift-operations-may-produce-incorrect-result.patch
http://sourceforge.net/p/mspgcc/bugs/352/attachment/0001-SF-352-Bad-code-generated-pushing-a20-from-stack.patch

Descomprimir binutils, gcc, gdb y crear una nueva carpeta build -> Install/mspgcc/build.

Binutils

Abrir el terminal e ir a la carpeta binutils:
cd ~/Install/mspgcc/binutils-2.22
patch -p1 < ../msp430-binutils-2.22-20120911.patch

cd ../build
mkdir binutils
cd binutils
../../binutils-2.22/configure --target=msp430 --prefix=/usr/local/msp430 2>&1 | tee co
make 2>&1 | tee mo
sudo make install 2>&1 | tee moi


Todo se instalará en /usr/local/msp430. Quizás hubiera sido mejor en /usr/local/msp430x para tenerlo instalado a la par de la versión estable.
No soy un gran conocedor de linux, se que el comando configure prepara el archivo makefile, que el comando make hace la compilación, y que make install hace la instalación. El archivo makefile contiene las instrucciones para compilar (fuentes, archivos objeto a generar, dependencias, comandos de compilación e instalación...)
Pero no sabía que significa 2>&1 ni que significa esto de |tee co/mo/moi.
http://stackoverflow.com/questions/818255/in-the-shell-what-is-21
2 se refiere a salida stderr, 1 es salida stdout (como archivos).
> es comando de redirección, por ejemplo, si queremos guardar el árbol de una carpeta a un archivo de nombre haríamos:
ls -R >tree
Estamos redirigiendo lo que normalmente saldría por stdout (la consola) al archivo tree.
Entonces 2>&1 esta redirigiendo stderr a stdout (el & creo que es para referirse a stdout luego de >, de lo contrario crea un archivo llamado 1 en vez de enviar los datos a stdout).
El operador | (pipe) sirve para conectar la salida de un comando con la entrada de otro (en este caso la salida de make con la entrada de tee).
Tee es un programa que copia la entrada a (la salida de make) a un archivo (en nuestro co/mo/moi) y a stdout.

Eso es util trabajar de esa forma, nos queda el resultado de configure en co, el de make, en mo, y el de make install en moi; y a la vez vemos el resultado por pantalla.
Quizás sería mejor solo ver los errores por pantalla, y que guarde stdout y stderr en el archivo.

Binutils fue el menos problemático para mí (no para otras personas), gcc fue un dolor de cabeza. Revisar los archivos co, mo, moi para ver si hubo algún error; si los hubo lo siento no los puedo ayudar porque no me paso a mí.
Mis archivos co, mo, moi de binutils.

GCC


Hay algunos lugares donde usan la versión 4.7.2 o 4.7.4 de gcc. Cuando hice los parches con esas versiones tenía errores del tipo
patching file gcc/convert.c
Hunk #1 FAILED at 774.
Hunk #2 FAILED at 811.
2 out of 2 hunks FAILED -- saving rejects to file gcc/convert.c.rej


Y también aún en parches exitosos, el resultado es del tipo:
patching file gcc/emit-rtl.c
patching file gcc/emit-rtl.h
patching file gcc/except.c
patching file gcc/explow.c
patching file gcc/expmed.c
Hunk #1 succeeded at 1474 (offset 20 lines).
Hunk #2 succeeded at 1708 (offset 20 lines).
Hunk #3 succeeded at 2213 (offset 20 lines).

Me preocupa el offset, supongo que quiere decir que el código parcheado estaba desplazado 20 líneas del lugar esperado.

Por eso decidí utilizar la versión 4.7.0 que es la indicada en el parche del mspgcc msp430-gcc-4.7.0-20120911.patch.
Los archivos .patch contiene instrucciones para buscar cierta porción de código y agregar/eliminar/modificar las instrucciones de c, en 1 o más archivos.
La idea es bajar el código versión X, usar los parches para esa versión (que pueden corregir bugs o agregar funcionalidad), y luego compilar e instalar la versión parcheada.


Continuando desde la carpeta /build/binutils:
cd ../../gcc-4.7.0
#Ahora estamos en ~/Install/mspgcc/gcc-4.7.0, aplicamos parches
patch -p1 < ../msp430-gcc-4.7.0-20120911.patch
patch -p1< ../0001-SF-352-Bad-code-generated-pushing-a20-from-stack.patch
patch -p1< ../0001-SF-357-Shift-operations-may-produce-incorrect-result.patch


La diferencia es que al aplicar los patch ahora no hay mensajes de offset, ni fail, ni nada. La salida es como:

patching file gcc/tree-ssa-ccp.c
patching file gcc/tree-ssa-forwprop.c
patching file gcc/tree-ssa-loop-ivopts.c
patching file gcc/tree.c
patching file gcc/var-tracking.c
patching file gcc/varasm.c
patching file gcc/varpool.c
patching file libgcc/config.host
patching file libgcc/config/msp430/crt0.S


Debemos bajar los pre-requisitos del gcc:mpfr, gmp, mpc. Algunos bajan estas librerías a mano y las construyen por comandos como hicimos con binutils, pero el problema es que hay que bajar la versión correcta, por eso usamos el script que ya nos provee gcc:
./contrib/download_prerequisites

Ahora vamos al configure, desde la carpeta build:


cd ../build
mkdir gcc-4.7.0-msp430
cd gcc-4.7.0-msp430
../../gcc-4.7.0/configure --target=msp430 --enable-languages=c,c++ --prefix=/usr/local/msp430 2>&1 | tee co

Sin problemas, y acá empieza la odisea, va a estar compilando un rato largo y va a tirar error:
make 2>&1 | tee mo

Error:
/home/daniel/Install/mspgcc/build/gcc/./gcc/xgcc -B/home/daniel/Install/mspgcc/build/gcc/./gcc/ -B/usr/local/msp430/msp430/bin/ -B/usr/local/msp430/msp430/lib/ -isystem /usr/local/msp430/msp430/include -isystem /usr/local/msp430/msp430/sys-include    -g -O2 -mcpu=430x -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../../gcc-4.7.0/libgcc -I../../../../../gcc-4.7.0/libgcc/. -I../../../../../gcc-4.7.0/libgcc/../gcc -I../../../../../gcc-4.7.0/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c ../../../../../gcc-4.7.0/libgcc/libgcc2.c
../../../../../gcc-4.7.0/libgcc/libgcc2.c: In function ‘__negdi2’:
../../../../../gcc-4.7.0/libgcc/libgcc2.c:73:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [_negdi2.o] Error 1
make[4]: Leaving directory `/home/daniel/Install/mspgcc/build/gcc/msp430/mcpu-430x/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/daniel/Install/mspgcc/build/gcc/msp430/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/home/daniel/Install/mspgcc/build/gcc/msp430/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/daniel/Install/mspgcc/build/gcc'
make: *** [all] Error 2



Se ve que hay un error con la función __negdi2 en el archivo libgcc2.c

Encontrar a que se debía este error llevó muchísimo tiempo, porque no estaba seguro de que era lo que fallaba: faltaba algún pre-requisito?, había parcheado mal?, hacía falta algún argumento de make?.
Después de mucho buscar llego a que el error surge al compilar gcc-4.7 con gcc-4.8 (versión que usa Ubuntu 14.04), y hay que modificar el archivo ira-int.h:
http://permalink.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/11667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56308
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=191605


Información de la revisión:

Bajar el nuevo ira-int.h de:
https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/ira-int.h?view=markup&pathrev=191605

Y reemplazar:
/Install/mspgcc/gcc-4.7.0/gcc/ira-int.h

Ahora al volver a construir ya no hay errores y podemos continuar, esto tarda un rato:
make 2>&1 | tee mo
sudo make install 2>&1 | tee moi

Archivos co/mo/moi del gcc.

Exportamos
export PATH=/usr/local/msp430/bin/:$PATH
Pero esto solo sirve para la sesión de consola actual, para hacer los cambios permanentes se puede agregar al usuario actual editando /etc/profile, o a todos los usuarios editando /etc/environment.
Yo elegí editar /etc/environment, por si agrego usuarios a mi máquina y poder usar mspgcc desde cualquier cuenta.
sudo gedit /etc/environment

Agregar /usr/local/msp430/bin a la variable path, queda así:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/msp430/bin"

Ahora hay que reiniciar para que tome los cambios en /etc/environment, lo que viene bien para la máquina después de hacerla trabajar tanto.

Si no agregamos esa ruta al path, el próximo paso nos dirá msp430-gcc no encontrado, o algo así.

GDB


Vamos a los fuentes:
cd ../../gdb-7.2
#Estamos en ~/Install/mspgcc/gdb-7.2
patch -p1 < ../msp430-gdb-7.2a-20111205.patch
cd ../build
mkdir gdb
cd gdb
../../gdb-7.2/configure --target=msp430 --prefix=/usr/local/msp430 2>&1 | tee co
make 2>&1 | tee mo

A esta altura si tenemos el texinfo 5.x nos tira el error:
../../../../gdb-7.2/bfd/doc/bfd.texinfo:326: unknown command `colophon'
../../../../gdb-7.2/bfd/doc/bfd.texinfo:337: unknown command `cygnus'


Lo que no quiere decir que haber instalado texinfo 4 nos solucione el problema, porque ahora make da el error:

../../../gdb-7.2/bfd/bfdio.c: In function ‘memory_bstat’:
../../../gdb-7.2/bfd/bfdio.c:580:30: error: argument to ‘sizeof’ in ‘memset’ call is the same expression as the destination; did you mean to dereference it? [-Werror=sizeof-pointer-memaccess]
   memset (statbuf, 0, sizeof (statbuf));
                              ^
cc1: all warnings being treated as errors
make[4]: *** [bfdio.lo] Error 1
make[4]: Leaving directory `/home/daniel/Install/mspgcc/build/gdb/bfd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/daniel/Install/mspgcc/build/gdb/bfd'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/daniel/Install/mspgcc/build/gdb/bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory `/home/daniel/Install/mspgcc/build/gdb'
make: *** [all] Error 2


Aparentemente se trata de un error debido a que compilamos con gcc 4.8 (versión que viene con Ubuntu):
https://aur.archlinux.org/packages/msp430-gdb/
Se puede bajar un patch desde:
https://sourceware.org/git/?p=gdb.git;a=commitdiff;h=7f62f13c2b535c6a23035407f1c8a36ad7993dec





Click en patch, guardar en ~/Install/mspgcc
Y luego desde /Install/mspgcc/gdb-7.2
patch -p1 <../gdb.git-7f62f13c2b535c6a23035407f1c8a36ad7993dec.patch

O siendo un error tan simple, podemos editar directamente el archivo bfdio.c y buscar la línea 580, dentro de la función memory_bstat (bfd *abfd, struct stat *statbuf):
memset (statbuf, 0, sizeof (statbuf));
y reemplazarla por
memset (statbuf, 0, sizeof (*statbuf));

En este punto borré /build/gdb y empecé de vuelta omitiendo los parches que ya están hechos:

mkdir gdb
cd gdb
#Ahora estamos en ~/Install/mspgcc/build/gdb
../../gdb-7.2/configure --target=msp430 --prefix=/usr/local/msp430 2>&1 | tee co
make 2>&1 | tee mo
sudo make install 2>&1 | tee moi

Podemos verificar que se instaló con msp430-gdb --version:
daniel@daniel-desktop:~/Install/mspgcc/build/gdb$ msp430-gdb --version
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=msp430".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.


Archivos co, mo, moi.

msp430mcu


cd ../msp430mcu-20130321/
#Estamos en  ~/Install/mspgcc/build/msp430mcu-20130321
sudo MSP430MCU_ROOT=`pwd` ./scripts/install.sh /usr/local/msp430 | tee so

El más fácil de todos!!!!
De hecho no se genera ninguna salida, el archivo so está vacío.

msp430-libc


Este no es tan fácil como el anterior :(
Bah, es fácil para alguien que entiende lo que está haciendo, no puedo decir que haya sido mi caso :P
La cuestión es que seguir fielmente las indicaciones dadas en
/msp430-libc-20120716/README
No resulta en nada. Estando en
~/Install/mspgcc/build/msp430-libc-20120716
Hacemos
./configure --prefix=/usr/local/msp430
cd src
make | tee mo

Tarda un buen rato, notar que se compila usando msp430-gcc que instalamos anteriormente, es necesario que ese paso haya salido sin fallas, y que /usr/local/msp430/bin esté agregado a la variable PATH del sistema.
sudo make prefix=/usr/local/msp430 install | tee moi

No da error, pero el resultado de esto debería ser que las librerías libc.a, libm.a, libfp.a estén copiadas en /usr/local/msp430/msp430/lib en una estructura como:






Nuevamente perdí muchas horas revisando el archivo makefile, buscando información, tiempo tirado a la basura.
Ya mientras estaba en la cama seguí buscando información y di con:
http://www.bradcampbell.com/installing-msp430-gcc-from-source/
http://energy.eecs.umich.edu/wiki/doku.php?id=msp430:mspgcc:start

Donde el comando de make install usado es:
sudo PATH=$PATH make PREFIX=/usr/local/msp430 install
desde ~/Install/mspgcc/build/msp430-libc-20120716/src

Y listo!!!!, con eso funciona. Faltaba poner PATH al principio, @!!#~@%!!!

Dejo un pseudo-moi (porque lo hice copiando y pegando desde el terminal y no con tee) para ver como debería ser la salida si las cosas salen bien:
https://drive.google.com/file/d/0B76ECNesbfvLNzY3X2ZldGJaWEU/edit?usp=sharing

Suficiente por ahora...
Vamos a dejar la instalación de mspdebug y eclipse para futuras entradas, y voy a tener que hacer una versión sin todo el blablaba para el que no quiera torturarse leyendo.
Primera entrada al fin!!!!.

Referencias

  1. Guía general para compilar el toolchain y aplicar parches
    https://github.com/contiki-os/contiki/wiki/MSP430X
  2.  Pautas para construir el toolchain e integrarlo en eclipse:
    http://richardnaud.wordpress.com/2013/10/02/installation-of-eclipse-cdt-msp430-gcc-4-7-0-mspdebug-0-21-and-more-on-ubuntu/
  3. Menciona el problema con texinfo, desinstalar versión 5.x e instalar el paquete sugerido:
    http://ubuntuandsecurity.blogspot.com.ar/2014/04/compiling-and-building-your-own-latest.html
  4. MSPGCC de texas v1.0.0:
    http://www.ti.com/tool/MSP430-GCC-OPENSOURCE
  5. http://m8051.blogspot.in/2014/03/beta-version-of-msp430gcc-supported.html 
  6. http://energy.eecs.umich.edu/wiki/doku.php?id=msp430:mspgcc:start
  7. http://www.bradcampbell.com/installing-msp430-gcc-from-source