sábado, 15 de junio de 2013

Un proyecto plantilla en autotools para STM32EVAL10X.

Bueno, bueno, ya con el título tienen “el gran trabajo” en este post, simplemente una plantilla que me cansé de escribir por decenas de veces que lo había hecho. El tema consiste en que por acá usamos las normas de gnu para el desarrollo de aplicaciones y esto incluye la configuración del proyecto por su puesto(see GNU Coding Standards). Como IDE puedes usar el de tu preferencia (el que tenga soporte para autotools o sea casi todos), como compilador usas igual el que quieras lo que tendrías que realizar cambios menores en la configuración del proyecto(AC_PROG_CC([arm-none-eabi-gcc]) ;) ). Bueno si este post forma parte de tus intereses para el trabajo que estás realizando te dejo algunos detalles de como usar las plantillas; si no manejas la herramientas autotools probablemente no te sea útil.
Primero que todo veamos como compilar y “flashar” en memoria estas plantillas que no hacen nada pero bueno por lo menos se ejecutan jeje.
  1. tar -xvzf firmware-stm3210fx#.tar.gz
  2. cd firmware-stm3210fx#-0.0.0
  3. export PATH=$PATH:/path/a/tu/toolchain
  4. ./configure –host=arm-none-eabi
  5. make
  6. make flash_firmware
Fácil verdad!,  ahora veamos algunos truquillos incluidos que te pueden facilitar la vida…
  1. doc: make doxygen-doc Te construye la documentación basada en el código si escribistes para doxygen además.
  2. “browse”: ./show_sources.sh Cada vez que en tu proyecto incluyas un nuevo archivo deberás hacerlo también en la configuración de autotool, si es un archivo de código propio lo harías en las variables “SOURCE” y “HEADER” respectivamente además por organización sería bueno que lo mantuvieras bajo “$(top_builddir)/src/Source” solo por organización, en realidad puedes ponerlo donde quieras, el otro caso sería el que incluyas código freeRTOS, lwIP, STM32Peripheral, o el que sea que incluyas con el scrip mencionado puedes tener una vista inmediata de donde se encuentra exactamente para agregarlo a su correspondiente variable (FREERTOS_SOURCE, ST_LIB_SOURCE, …), y tener en cuenta que si el compilador no está buscando cabeceras en el directorio recién incluido, incluirlo! en la variable AM_CPPFLAGS.
  3. Flashar: make flash_firmware Flashea la memoria usando una interfaz JTAG y openocd.
  4. Tablas de símbolos: cd src ; make log ; cd ../ , en src estarán los ficheros (*.txt) con tablas de símbolo, espacio de memoria, … que tal vez en algún momento necesites mirar.
  5. Detalles de compilación: make details Esto te muestra la compilación que estás realizando, para este caso específico la salida sería; Building from:
    build_cpu = i686, build_os = linux-gnu, build_vendor = pc
    To:
    host_cpu = arm, host_os = eabi, host_vendor = none
  6. Por último ten en cuenta que de una manera u otra terminarás modificando las reglas de compilación por lo que he copiado en doc/file.txt algunos de los parámetros utilizados, por ejemplo el proyecto está configurado en modo debug (-g), cuando hagas liberación esta bandera debería ser deshabilitada. Más información al respecto la buscas en la especificación de tu compilador.
Espero te sea de ayuda y si bien no sirve para cualquier proyecto, tengas una buena idea de como usar autotools :)

Ver además:
firmware-stm3210fx1
firmware-stm3210fx2
firmware-stm3210fx3

2 comentarios:

  1. Estimado sería útil hacer un tuto de como desarrollar bajo GNU para plataformas ARM... me parece un buen artículo pero trataría de hacer uno más genérico y más amplio, ya que tienes experiencia en ARM... hay varios que trabajan bajo linux para desarrollo.

    Saludos y gracias por el artículo.

    ResponderEliminar
  2. Realmente tienes razón, por acá estoy "solo" jeje todos mis compañeros usan eclipse + el plugin arm lo que los ata a un IDE, yo por ejemplo uso netbenas, no porque sea mejor o peor lo uso solo porque así lo prefiero, pero me gusta la formalidad en el código y la configuración del proyecto, he trabajado además algún tiempo como integrador... por eso autotools.
    Acato la recomendación que haces pero ahora mismo no lo voy a hacer ya que estoy terminando el curso (pruebas finales, tareas de curso, ...), es que soy estudiante aún de todos modos si ya tienes algo hecho hazle el fork en github para revisarlo y hacerle megue, el principal objetivo es ese que mencionas la genericidad pero si se mantiene la estructura del proyecto no veo que haya que hacerle mucho, solo los cambios en el código y los de autotool que serían el compilador(AC_PROG_CC([arm-none-eabi-gcc])) y las flags (LINKER_FLAGS, uC_CFLAGS) a este que ya eso si sería del compilador específico que uses, yo he usado siempre gcc.
    Proximamente compartiré uno para sumarle lwip a la plantilla.
    Salu2s.

    ResponderEliminar

Deje su comentario..., 0 palabras obscenas...