El próximo día 25 de Enero de 2008 se celebrará en la Escuela Superior de Informática de Ciudad Real una Jornada Técnica sobre Software Libre en torno a la presentación de la nueva Molinux 3.2 “Hidalgo”. No olvides inscribirte
La Junta de Comunidades de Castilla-La Mancha a través del Centro de Excelencia de Software Libre de Castilla-La Mancha, perteneciente al Parque Científico y Tecnológico de Albacete, organiza, con la colaboración de la Escuela Politécnica Superior de Albacete de la UCLM, la II Edición del Curso Online de Java.
Cómo tracear un programa en C para AVR en GNU/Linux con avarice “in circuit”
Introducción
Bueno, como lo prometido es deuda he conseguido tracear un programa escrito en C para un ATMEGA128 en la propia placa de desarrollo utilizando solamente software libre. Aquí explicaré como lo he hecho y además, como extensión a la receta anterior sobre simulación de código para AVR explicaré como depurar con la herramienta libre ddd, que es básicamente un front-end para gdb muy fácil y cómodo de utilizar.
Así pues, sin mas preámbulos ¡¡¡¡Al turrónnnnn!!!! :-P
Preparando el terreno
Bueno, para nuestros propósitos neceistaremos un AVRJTAGICE. Se trata de un programador/emulador para AVR y soporta muchísimos de los micros de ésta familia.
En lo referente al software, utilizaremos avarice que no es ni mas ni menos que nuestro interface con el JTAG. También haremos uso del ya conocido avr-gdb y de ddd como front-end de avr-gdb.
Bueno, pues suponiendo que seguisteis con atención la receta anterior en la que hablé de cómo simular los AVR, tan solo tendremos que instalar ddd y avarice en nuestra máquina para empezar…
Bueno, para la compilación del código necesitamos exactamente las mismas opciones que para la simulación. De hecho, el proceso es el mismo, ya que en ambos casos usamos avr-gdb. La única diferencia es que avarice no necesita para nada el archivo .bin que creamos. En su lugar utilizaremos el .hex, que será el que carguemos en el microcontrolador para tracear. Por lo tanto podemos seguir utilizando el Makefile de la receta anterior y supondré que, de hecho, estamos trabajando con el mismo proyecto.
Simulando con ddd
Bueno, antes de empezar a tracear, voy a contar como utilizar ddd para simular. En realidad es muy sencillo. De hecho, hay que seguir exactamente todos los pasos de la receta anterior, salvo que en lugar de llamar a avr-gdbtui, se llama a ddd diciéndole que use por debajo a avr-gdb. Resumiendo, tenemos que hacer algo como esto:
Antes de ponernos manos a la obra, explicaré un poco el uso de avarice. Bueno, avarice permite borrar, programar, cambiar los valores de los fusibles, leer el contenido de la memoria del chip, verificar el código del chip y, por supuesto, tracear. Para todo ello necesitaremos, como es de suponer, el JTAG antes mencionado.
Si queremos hacer cosas como por ejemplo borrar un chip, haríamos lo siguiente:
javieralso@avalon:~$avarice -2--erase--jtag usb
la opción -2 se utiliza para decirle a avarice que estamos trabajando con el JTAG mkII, que es algo así como la segunda versión. —jtag usb indica que estamos utilizando la conexión USB del dispositivo. Si quisiéramos utilizar un puerto seríe, habría que sustituir usb por la ruta del archivo de dispositivo del puerto a utilizar.
Para programar un micro:
javieralso@avalon:~$avarice -2--erase--program--file archivo.hex --jtag usb
Después de pasar la opción —program, tenemos que decir qué archivo queremos utilizar. Para se utiliza la opción —file seguida del archivo que queremos transferir.
Si se utiliza la opción —P seguido de un modelo de micro podemos decirle a avarice que estaremos utilizando ése micro. Lo normal es que avarice sea capaz de leer la información de identificación del micro sin problemas.
Siempre que queramos programar un micro, deberemos borrarlo antes de manera explícita, ya que el borrado no se hace de forma automática al iniciar la programación, como si pasa con otros entornos.
Al meollo del asunto: TRACEANDO
Ahora ha llegado la hora de la verdad. Con todo listo, nuestro JTAG conectado al usb del ordenador y a la tarjeta a tracear nos disponemos a empezar. La forma en que se ejecutan las aplicaciones es la misma que en la receta anterior. De hecho, para avr-gdb, avarice cumple exactamente el mismo papel que simulavr y lo ve de la misma manera.
Lanzamos primero avarice, diciéndole que programe el micro si esque no lo habíamos hecho nosotros antes:
Ésto es exactamenet lo que hicimos antes, pero con el añadido de que además, le hemos dicho que se quede escuchando conexiones entrantes por el puerto 1212
Ahora tenemos que lanzar ddd, pero antes necesitamos un archivo de comandos para que los ejecute al comienzo. Éste archivo es casi igual que el de la receta anterior, solo que cambian un par de cosillas, así que lo pongo tal y como lo tengo yo:
set debug remote 1
file rs232toRS485.out
target remote 192.168.0.19:1212
break main
continue
Bueno, podemos ver que el archivo es casi igual. Solo se ha eliminado el load, que aquí lo que hacía era cargar el código del micro en el simulador, cosa que no nos interesaba. También activamos la simulación remota (set debug remote 1).
Una vez hecho ésto, solo nos queda llamar al simulador:
y ¡¡YA ESTÁ!! a partir de ahora, lo que hagamos en ddd se verá reflejado en nuestra placa de desarrollo. Podremos leer variables, asignarles otros valores, etc etc etc. Eso si, existen algunas limitaciones, como por ejemplo que solo podemos tener 3 breakpoints como mucho, pero vamos, menudencias ;-)
Pues nada més. Espero que lo disfrutéis como lo estoy disfrutando yo y que os sea tan útil para vuestros proyectos como lo está siendo para mi ;-)
Cómo depurar un programa en C para AVR en GNU/Linux con avr-gdb
Introducción
Después de haberlo intentado varias veces, habiéndome dado por vencido siempre, he vuelto a las andadas, ésta vez para no parar hasta conseguir depurar un programa escrito que utiliza avr-libc (se puede consultar la receta sobre instalar la toolchain para AVR en éste mismo blog).
Para la depuración he utilizado avr-gdb y simulavr desde distintas máquinas, consiguiendo de ese modo ver en una la ejecución del programa objeto de la prueba y en otra el contenido de los registros y de la memoria del micro.
A partir de ahora, explico cómo lo he hecho todo, desde la compilación (se necesitan parámetros específicos para el enlazador) hasta la puesta en funcionamiento del simulador. Doy por sentando que se conoce el uso de gdb para depurar.
Praparándolo todo
Bueno, para que podamos funcionar tan solo necesitamos simulavr y avr-gdb. En nuestro querido Debian ya sabeis:
Para poder simular el código, debemos pasar la opción -g a avr-gcc. Además, de eso, debemos decirle al enlazador que utilice la opción -gstabs. Os paso directamente el Makefile del proyecto que utilicé como prueba para que lo veais mas claro. Está un poco “guarro”, pero servirá para ilustrar el ejemplo ;-):
Además de lo comentado anteriormente, también se ha marcado una regla que se encarga de la creación de una imagen binaria del código de salida. Ésta imagen es importante, ya que es la que cargará simulavr para poder llevar a cabo la simulación del micro.
NOTA: Para que se pueda ver el contenido de las variables locales dentro del entorno de simulación, es muy importante que el flag de optimización esté puesto a 0. ($(CC) $(CFLAGS) -O0 -c $^).
Simulando
Bueno, una vez que ya tenemos nuestro programita compilado toca simularlo. Supondremos que vamos a correr simulavr y avr-gdb en la misma máquina, aunque ésto no tiene por qué ser así, de hecho yo lo hago en máquinas separadas para poder ver la traza y el estado de los registros. Pero ésto ya va a gusto del consumidor :-P.
Para nuestros propósitos simulavr funcionará como un gdbserver, es decir, le dirá a avr-gdb cómo debe comportarse. Por ello tenemos que arrancarlo primero. Para ello lo lanzamos de la siguiente manera:
¿Qué hemos hecho? pues hemos llamado a simulavr diciéndole que vamos a simular un atmega128. Como queremos ver el contenido de los registros hemos llamado tambíen a simulavr-disp ya que simulavr solo dice a avr-gdb cómo comportarse, pero no muestra información alguna. simualvr-disp es el frontend que nos permite ver el contenido de los registros internos de la máquina que estamos simulando.
Para lanzar avr-gdb crearemos antes un archivo de comandos a ejecutar para “automatizar” un poco el uso. Éste archivo tiene algo como ésto:
file rs232toRS485.out
target remote localhost:1212
load
break main
continue
En él decimos a gdb que cargue el archivo a simular, se conecte con en esta mísma máquina (localhost) y escuchando en el puerto 1212 que es donde por defecto escucha simulavr.
Lanzamos avr-gdb (a mi en especial me gusta mas avr-gdbtui) de la siguiente manera:
javieralso@avalon:~$avr-gdbtui -x comandos.gdb
siendo comandos.gdb el archivo en el que guardamos los comandos anteriores.
Podremos ver como inmediatamente cambian los valores de los registros mostrados en simulavr y avr-gdb queda parado en el main de nuestro programa. Ésto sucede porque nuestro programa empieza a simularse inmediatamente después de lanzar el depurador y para en el primer breakpoint que encuentra, que se encuentra en main (breakpoint por defecto). Cómo antes de eso se tiene que ejecutar código (arranque del micro, configuración de la pila, registros de configuración iniciales, inicialización de memoria, etc….) vemos los cambios en los registros de la máquina reflejados en simulavr. Ahora ya podremos simular/depurar como se hace usualmente con gdb.
¡¡Ale, a disfrutarlo :-D!!
En el futuro…
Actualmente también me estoy peleando con avarice que permite borrar, programar, leer, verificar y depurar “on board” muchos dispositivos de la familia AVR utilizando un AVRJTAGICE y avr-gdb o insight. En cuanto sea capaz de terminar de hacerlo funcionar, prometo explicarlo en otra recetilla. Mientras tanto a esperar pacientemente jugueteando con todo lo que ya tenemos sobre AVR….
GNOMEVFS es una librería para realizar todo tipo de operaciones sobre ficheros independientemente del método de acceso necesario para llegar a ellos (FTP, HTTP, WebDAV, SMB, etc). Esta receta muestra ejemplos de lo sencilla y potente que puede llegar a ser esta pequeña maravilla.
Alguna vez puede darse el caso de que necesitemos proyectar una película o jugar a algunos juegos en un monitor secundario (o proyector) que conectemos a un portátil. Puede haberos pasado (como a mi) que la ventana en el monitor secundario aparezca en negro. Veremos como solucionar el problema en esta micro-receta.
En este tiempo, el Centro de Excelencia de Software Libre de Castilla-La Mancha (CESLCAM) se ha centrado en la organización de jornadas de difusión; talleres; puesta en marcha del primer concurso universitario de software libre en Castilla-La Mancha; creación de un portal web y observatorio tecnológico en fuentes abiertas; participación activa en comunidades relacionadas con estas tecnologías como el proyecto Morfeo de telefónica I+D; acciones sociales con equipamientos hardware reutilizables; puesta en marcha de su plataforma de teleformación y en otro conjunto de actividades que han intentado acercar el software libre a todos los ciudadanos para aprovechar todas las ventajas que supone el uso de estos aplicativos.
Correo que me han mandado los de Hassefroch, supongo que os habrá llegado también, si tenéis cuenta en hotmail.
Razones de peso por las que necesitas Windows Live!
1. Porque si tienes una cámara digital, la Galería fotográfica de Windows Live te permite importar, administrar y compartir fotos fácilmente en Windows Live Spaces y en otros servicios.
