Autotools (3): Integración de libtool en autotools para la creación de una biblioteca a instalar en el sistema.

En otros post anteriores vimos la escencia de las bibliotecas así como de libtool, si además haz realizado aunque sea un “hello world” con autotools entonces ahora veamos como integramos a libtool con autotool para la creación de una biblioteca.

#configure.ac

LT_INIT: Es la forma en que actualmente se define LIBTOOL.

# Checks for programs.

AC_PROG_CXX: Chequea por un compilador para c++.

AC_PROG_AWK: Chequea gawk, mawk, nawk, and awk, en ese orden y lo establece como variable.

AC_PROG_CC: Chequea por un compilador para c.

AC_PROG_CPP: Muetra el valor de la variable CPP que contiene el preprocesador.

AC_PROG_INSTALL: Muetra el valor de la variable INSTALL para instalación.

AC_PROG_LN_S: Chequea que ls sistema en que te encuentras soporta links simbólicos(ln -s), en caso que este no esté disponible lo establece a ln, en otro caso a cp -pR.

AC_PROG_MAKE_SET: Establece el comando make.

#lib/Makefile.am:

CLEANFILES: Para que make clean borre los archivos que coincidan.

AM_CPPFLAGS: El contenido de esta variable es pasado a todas las reglas de compilación que invoquen el preprocesador de C.

Definiciones para el uso de pkg-config una vez creada la lib.

pkgconfigdir = @libdir@/pkgconfig

pkgconfig_DATA = libmatX.pc

A diferencia del primer ejemplo donde poniamos bin_PROGRMAS para crear ejecutables aquí usamos esta macro a la cual le decimo el nombre de la lib a crear y en el source debe transformar el nombre a su forma canónica.

lib_LTLIBRARIES = libmatX.la

libmatX_la_SOURCES = \

matX.cc

libmatX_la_LDFLAGS: Flags para el elnlazador.

“#Headers/Makefie.am

includedir: Referencia al directorio include donde se pondran los headers

nobase_include_HEADERS: Para que no se instale dos veces con una invocación del programa.

Una vez configurado el proyecto procedemos a la contrucción:

1. mkdir -p m4

2. libtoolize --copy –force

3. aclocal -I m4

4. autoheader

5. autoconf

6. automake -a

7. ./configure

.8 make

Ya podrás ver que se ha creado lib/libmatX.la, incluso lo podrías leer(cat lib/libmatX.la) ya que es texto plano, en este punto la biblioteca ya es usable, esto sería en nuestro progrma usar la macro LDADD (tambien con el nombre del ejecutable como prefijo y con _ al final) para esto puedes consultar GNU Automake aunque este ejemplo cuneta con su *.pc.

9. sudo make install

Ya deberías poder verificar como instalada la biblioteca en tu sistema

10. pkg-config --list-all | grep hello_libtool

Ya teniendo esta infraestructura básica del proyecto veamos como crear las bibliotecas estática y dinámica correspondiente.

Biblioteca estática:

make clean

./configure --disable-shared

make

Biblioteca dinámica:

make clean

./configure --disable-static

make

NOTA: En caso de no especificar se crea la dinámica y la estática.

Desde aquí puedes descargar el ejemplo:

git clone https://github.com/denisacostaq/EmbeLinux --branch hello-libtool

Creación de bibliotecas mediante el uso de libtool (Parte 2).

Si ya revisaste el post anterior sobre construcción de bibliotecas podremos proseguir con el hecho de que ya tenemos algunos conceptos básicos de nuestro lado, esta vez relizaremos el mismo ejemplo lo que cambia es las herramientas. Primero construiremos la lib estática, después compartida y por último de ejecución (que no es más que la misma biblioteca compartida lo que se carga en tiempo de ejecución).

Libtool:

Según su propia documentación (apt-get install libtool-doc) fue diseñado desde sus inicios para soportar un número arbitrario de tipos de bibliotecas, más tarde se ha ido portando a otras plataformas y gradualmente se han ido desarrollando nuevos paradigmas que describen la relación entre las bibliotecas y los programas.

Consideremos el sigiente código con el cual crearemos la biblioteca estática y compartida:

//module.c

float mult (float fac1, float fac2)

{

return fac1 * fac2;

}

Biblioteca estática:

1. Creamos un directorio donde “instalaremos” la lib.

mkdir -p /tmp/install

2. Compiamos el código.

libtool --verbose --mode=compile gcc -g -O -c module.c -static

3. Enlazamos el código, si no ponemos -rpath /tmp/install al comando anterior tendremos que ejecutar

libtool --finish /usr/local/lib después para que se complete la instalación correctamente.

libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -static

4. Instalamos

libtool --mode=install install module.la /tmp/install

Ya tenemos lista la lib en /tmp/install que puedes usar como en el post anteriorque mencionaba al inicio y además notar que se encuentra en el direcorio oculto (ls .libs/).

Biblioteca dinámica:

Recomendable eliminar los archivos anteriores para ver el nuevo resultado y repitiendo los pasos para este caso tenemos:

1. mkdir -p /tmp/install

2. libtool --verbose --mode=compile gcc -g -O -c module.c -shared

3. libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -shared

4. libtool --mode=install install module.la /tmp/install

Biblioteca de ejecución:

Para ver como usamos una lib en tiempo de ejecución usaremos el siguiente código:

#include <stdio.h>

#include <ltdl.h>

#include <stdlib.h>

//declaramos una variable(puntero a la función así que

//debe coincidir en los tipos)

float (*mult)(float fac1, float fac2);

int main (int argc, char *argv[])

{

lt_dlhandle handle;

lt_dlinit ();

lt_dladdsearchdir ("./");

handle=lt_dlopenext ("module");

if (!handle)

{

printf ("Error, módulo no cargado: %s\n",

                   lt_dlerror());

exit (EXIT_FAILURE);

}

const lt_dlinfo *info;

info = lt_dlgetinfo (handle);

if (!info)

{

fprintf (stderr, "No se pudo obtener la información  del módulo: %s\n", lt_dlerror());

lt_dlclose (handle);

exit (EXIT_FAILURE);

}

if (info->name)

{

printf ("Nombre del módulo: %s\n", info->name);

}

else

{

printf ("No es un módulo libtool\n");

}

//casteo al tipo de la función

mult = (float(*)(float, float))lt_dlsym(handle, "mult");  

if (mult)

{

printf ("Resultado desde el módulo: %f\n", mult(5.0, 10.0));

}

else

{

perror ("No se pudo cargar la función\n");

lt_dlclose (handle);

exit (EXIT_FAILURE);

}

lt_dlclose (handle);

return 0;

}

Recomendable eliminar los archivos anteriores para ver el nuevo resultado y repitiendo los pasos para este caso tenemos:

1. libtool --verbose --mode=compile gcc -g -O -c module.c -shared

2. libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -shared

3. libtool --mode=link gcc -export-dynamic -o programdl program.c -lltdl

Un detalle importante es notar que la lib se contruye de la misma manera que la compartida, el programa es el que se contruye de forma diferente a la convencional y además con ldd como en el post anterior puedes ver como program no depende de module por lo que los pasos 2 y 3 se pueden cambiar de orden ya que program no necesita saber nada acerca de module en tiempo de compilación.

NOTA: Para tener más referencia consulte man libtool o /usr-sha-doc-libtool-doc.

Implementando mi propio shell usando una gramática LL1.

Lo primero que veremos, qué es un shell; después, qué es una gramática, cuando una gramática se clasifica como LL1 (y si no lo es como llevarla) y por último veremos una pequeña implementación en C de un shell.

Shell: Shell (del inglés cascarón, coraza, concha, etc) toma este nombre por ser el shell una interfáz entre el nucleo del Sistema Operativo y el usuario, es un intérprete a través del cual este le da órdenes(ver Fig 1).

Fig 1.

El shell es un programa capaz de interpretar comandos, hacer una petición al sistema y devolver un resultado. Exixsten varias implementaciones: sh, bash, csh, Tcsh, …, etc... Cada usuario tiene una shell predeterminada ej: adacosta:x:1008:1008:PEPSI,,,:/home/adacosta:/bin/bash el cual es ejcutado al autenticarse el usuario en una terminal, o al abrir una emulador de terminal en una sesión X11, lo primero que hace el shell es leer sus configuración de sistema (/etc) y después leer la configuración del usuario (/home/user-name/.*) pudiendo llegar a ser uno o varios archivos, en mi caso:

( /home/adacosta/.bashrc, /home/adacosta/.profile /home/adacosta/.bash_*)

Gramática: Intuitivamente, una gramática es un conjunto de reglas para formar correctamente las frases de un lenguaje; así ́ tenemos la gramática del español, del francés, etc. Según N. Chomsky existen 4 tipos fundamentales de gramáticas:

1. Gramáticas regulares, o de tipo 3: Las reglas son de la forma A → α B o bien A → α, donde A y B son variables (no terminales) y α es una constante (terminal). Estas gramáticas son capaces de describir los lenguajes regulares.

́

2. Gramáticas Libres de Contexto (GLC), o de tipo 2: Las reglas son de la forma X → α, donde X es una variable y α es una cadena que puede contener variables y constantes. Estas gramáticas producen los lenguajes Libres de Contexto.

́

3. Gramáticas sensitivas al contexto (dependientes del contexto) o de tipo 1: Las reglas son de la forma αAβ → αΓβ, donde A es una variable y α, β y Γ son cadenas cualesquiera que pueden contener variables y constantes.

4. Gramáticas no restringidas, o de tipo 0: Con reglas de la forma α → β, donde α no a puede ser vacío, que generan los lenguajes llamados “recursivamente enumerables”.

Los objetivos de una gramática son: definir las sentencias que pertenece a un lenguaje, así como describir estructuralmente dichas sentencias. Las gramáticas generan sentencias mediante secuencias de derivaciónes directas

Como ejemplo veamos una gramática subconjunto del idioma español:

G = ( {<frase>, <sujeto>, <predicado>, <artículo>, <sustantivo>, <verbo>},

{el, la, perro, luna, brilla, corre}, P, <frase>)

P:

<frase> → <sujeto> <predicado>

<sujeto> → <artículo> <sustantivo>

<artículo> → el | la

<sustantivo> → perro | luna

<predicado> → <verbo>

<verbo> → brilla | corre

En correspondencia con esta gramática podriamos generar frases como las que siguen.

{el perro corre , el perro brilla, la perro brilla, ...} estando todas ellas correctas sintácticamente aunque haciendo un análisis semántico (en otra etapa) podriamos detectar que algunas de las frases carecen de sentido.

Gramáticas LL1:

Un analizador LL es llamado un analizador LL (k) si usa k tokens cuando el analizador ve hacia delante de la sentencia. Si existe tal analizador para cierta gramática y puede analizar sentencias de esta gramática sin marcha atrás, entonces es llamada una gramática LL (k). De estas gramáticas, la gramática LL(1), aunque es bastante restrictiva, esta es muy popular (principalmente en actividades docentes) porque los analizadores LL correspondientes sólo necesitan ver el siguiente token para hacer el análisis de sus decisiones. Lenguajes mal diseñados usualmente suelen tener gramáticas con un alto nivel de k, y requieren un esfuerzo considerable al analizar.

Una gramática ambigua es aquella que produce más de una derivación más a la izquierda o más de una derivación más a la derecha para la misma sentencia. En general existen tres estrategias iniciales para eliminar la ambiguedad de las gramáticas, ellas son:

1. Definir la precedencia y asociatividad de los operadores.

2. Eliminar la recursividad izquierda o derecha.

3. Factorizar.

Veamos un ejemplo:

G = ({<Expresión>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

(1) <Expresión> → <Expresión> + <Expresión> | <Expresión> - <Expresión>

(2) <Expresión> → <Expresión> * <Expresión> | <Expresión> / <Expresión>

(3) <Expresión> → id | ( <Expresión> )

Precedencia y asociatividad:

Definamos un nivel de prioridad para cada operador como sigue:

1. (), id

2. *, /

3. +, -

Nivel 1 Se introduce un nuevo símbolo No Terminal, que llamaremos <Factor> para describir una expresión indivisible y con máxima precedencia.

<Factor> → id | ( <Expresión> ) .

Nivel 2 Se introduce un nuevo símbolo No Terminal, que llamaremos <Término>, que generará una secuencia de uno o más términos generados por el No Terminal <Factor>, conectados con los operadores de nivel precedencia 2.

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

Nivel 3 Se mantiene el símbolo No Terminal <Expresión> para describir secuencias de uno o más términos generados por el No Terminal <Término>, conectados con los operadores de nivel precedencia 3.

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

Aplicando las reglas anteriores la gramática definida anteriormente queda re definida como sigue:

G = ({<Expresión>, <Término>, <Factor>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

<Factor> → id | ( <Expresión> )

Recursividad Izquierda :

Una producción de la forma A → Aβ se dice que es recursiva inmediata. Para eliminar las recursividades inmediatas podemos seguir el procedimiento siguiente:

1. Se agrupan las A-producciones:

A→ Aα1 | Aα2 | . . .| Aαm | β1 | β2 . . .| βn

donde ningún βi comienza con A.

2. Se reemplazan las A-producciones por:

A→ β1 A’| β2 A’| . . .| βn A’

A’→ α1 A’| α2 A’| . . .| αm A’| ǫ

Aplicamos el procedimiento anterior para eliminar la recursividad directa en la gramática:

G = ({<Expresión>, <Término>, <Factor>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

<Factor> → id | ( <Expresión> )

Para ellos seleccionamos las reglas que son recursivas directa a la izquierda estas son:

(I) <Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

(II) <Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

Aplicando la regla para la eliminación de ambiguedad 2 sobre (I) y (II) nos queda:

<Expresión> → <Término> <MasExpresión>

<MasExpresión> → + <Término> <MasExpresión> | - <Término> <MasExpresión> | E

<Término> → <Factor> <MasTérmino>

<MasTérmino> → * <Factor> <MasTérmino> | / <Factor> <MasTérmino> | E

Factorización por la izquierda.

La Factorización por la izquierda tiene el objetivo de reescribir las producciones de la gramática con igual comienzo para retrasar la decisión hasta haber visto lo suficiente de la entrada como para elegir la opción correcta. El procedimiento es simple. Si tenemos una regla de producción de la forma:

́ A → αβ1 | αβ2 | . . . | αβn | δi

esta se transforma en las regla.

A → α A′ | δi

A ′ → β1 | . . . | βn

A manera de ejemplo consideremos la regla de producción siguiente:

<Instruciones > → <Instrucción> ; <Instruciones > | <Instrución>

Aplicando la Factorización por la izquierda nos quedan las reglas equivalentes:

<Instruciones > → <Instrucción> <MasInstrucciones >

<MasInstrucciones > → ; <Instruciones > | E

A modo de conclusión podemos decir que las gramáticas constituyen la mejor vía para la descripción sintáctica de los lenguajes de programación. Existen diversas razones que justifican tal afirmación:

Las gramáticas brindan una especificacion sintáctica precisa de los lenguajes de programación.

Para ciertas clases de gramáticas pueden construirse analizadores sintácticos eficientes que determinan si el programa fuente está bien escrito. El proceso de construcción del parser puede además, revelar ambiguedades sintácticas no detectadas en la fase de diseño del lenguaje .

Una gramática bien diseñada puede ayudar a la traducción del programa fuente en código objeto y a la detección de errores.

Se pueden añadir nuevas construcciones al lenguaje de forma fácil.

Un ejemplo de implementación:

Un ejemplo de implementación de un intérprete basado en un gramática LL1 lo puede tomar clonando denishell(git clone https://github.com/denisacostaq/denishell), toda la documentación relevante forma parte del código fuente y/o de la documentación(valga la redundancia) generada con doxygen, en especial fijarse en el comando cd, en la manera que se “simula” la implementació de un pipe (char** run_pipe_on_node (struct ast_node *ast);), en la pesatña examples de dicha documentación puedes aprender cómo comunicar dos procesos con un pipe real, y además puedes ver algunos de los comandos a ejecutar, tambié revisar char** cat_args(); y char** ls_args (); para tener detalles sobre la internacionalización (deni-sh_i18n.h).

Autotools(2): Integracíon de getttext con autotools para internacionalizar aplicaciones (intltool).

Cuando deceamos que nuestra aplicación esté disponible bajo varios idiomas tenemos varias opciones, una de ellas es el conjunto de funciones gettext (glibc-reference-manual). En este pos veremos como inttool se integra de manera natural a autotools(see Autotools(1))., gettext es quien extrae las cadenas para su traducción pero inttool extiende sus funcionalidades permitiendo:

• -Detectar las herramientas necesarias para la configuración y contrucción del proyecto.
• -Extraer las cadenas a traducir.
• -Mezclar las cadenas en la app final.

A partir de este punto nos basaremos en nuesto “hola mundo” inicial (git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo, puedes probar ahora ejecutar autoscan en el directorio del proyecto y después cat configure.scan ), agregaremos el directorio po en la raiz de nustro proyecto, aquí irán hubicados 3 archivos esenciales.

1. POTFILES.in: Listado de archivos que contienen cadenas a traducir. Si se crea vacio ejecutando
   make update-po dentro del directorio po tendrás las cadenas marcadas a trducir.
2. POTFILES.skip: Listado de archivos que contienen cadenas traducibles pero aún se trabaja en ellos(los programadores) por lo que los traductores no deben desgatarse en ellos.
3. ChangeLog: Lleva un control de los cambios efectuados en el proceso i18n, 110n (para ver más detalles sobre esto revise un exelente artículo publicado por la señorita Milagros Alessandra en el número 1 de la revista HD).

Además de estos 3 archivos se hubican el archivo con todas las cadenas traducibles(*.pot) y los archivos con todas las cadenas traducidas en los diferentes idiomas(*.po).

Debemos cambiar nuestro archivo configure.ac de manera que quede como en nuestro hola mundo internacionalizado(por lo que ha cambiado a la verción 0.0.2) pero es recomendable que usando las piezas de la primera verción llegues hasta la segunda siguiendo los pasos desde para que entiendas bien todo por ti mismo. Una forma cómoda de ver los cambios es usando una herramienta difftool(ej:meld), los cambio son menores y los comento a continucaión:

• AC_PROG_INTLTOOL ( [ 0.50.2-2 ] ): Para que ./configure chequee que esta intltool en la verción especificada(como minimo).
• GETTEXT_PACKAGE: Esta variable es usada para nombrar el paquete.
• AC_SUBST: Publica la variable pasada como parámetro para ser usada de manera gloval en el proyecto(en cualquier Makefile.am se podrá aceder a su valor), en este caso es útil para po/Makefile.in.in.
• AC_DEFINE_UNQUOTED: Esta macro se usa para declarar sus “parámetros” en config.h(para este caso ya que así le nombramos en AM_CONFIG_HEADER), si lo escribieramos en “C” sería: #define GETTEXT_PACKAGE “hola−mundo” que de hecho se puede observar en config.h que este es su resultado.
• ALL_LINGUAS: Contendría los idiomas que tenemos disponibles.
• AM_GNU_GETTEXT: Verifica que tengamos disponible gettext en nuestro sistema, además de agregar algunas entradas en config.h de manera automática.

En el archivo Makefile.am se han efectuado cambios en 3 variable de las que solo es nueva CLEANFILES en la que ponemos archivos que queremos eliminar con “make clean”. En src/Makefile.am solo es nueva INCLUDES que especifica donde estaran las cadenas traducidas. EL archivo src/hello_world_i18n.h es usado para garantizar que nuestra aplicación “siempre” compile aunque no esté disponible el soporte para internacionalización, basicamente si está _ (str) se sustituye en tiempo de preprocesamiento por ( const char ∗) gettext ( str), si no está se sustituye por si misma, o sea no es el resultado de gettext, si no el mismo parámetro lo que se optiene.

En src/main.c los únicos cambios destacables son:

• setlocale (LC_ALL, “”); al pasarle “” nuesto progrma uasará el “locale” definido por el sistema.
• bindtextdomain ( GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR ); :Aquí usamos el valor establecido en src/Makefile.am.
• bind_textdomain_codeset ( GETTEXT_PACKAGE, “UTF-8″ ); : Aquí decimos la codificaciín de caracteres que vamos a usar.
• textdomain ( GETTEXT_PACKAGE ); define el dominio o ámbito de traducciones, normalmente reducido al dominio del programa y que se encuentra definido en GET- TEXT_PACKAGE.

La secuencia de comandos se ha modificado ligeramente:

mkdir m4 ; aclocal -I m4

autoheader

glib-gettextize --copy --force

intltoolize --copy --force --automake

autoconf

automake --add-missing

En el directorio “po” falta determinar el contenido del archivo POTFILES.in. Para ello, dentro

de dicho directorio basta invocar el comando:

cd po ; touch POTFILES.in ; intltool-update --maintain ; cd ../

esto mostrará los archivos que tienen cadenas a traducir y que no se encuentran en el archivo POTFILES.in. Para facilitar el trabajo, también se genera un archivo llamado missing(puede ser añadido al final de POTFILES.in).

./configure

cd po

make update-po

cp hola-mundo.pot es.po (Para estos archivos puedes usar Gtranslatro como explican en HD)

cp hola-mundo.pot fr.po (El francés lo dejaré sin traducir para que compruebes que la aplicación se ejecuta lo que solo en inglés)

cd ../

Traducir con Gtranslator(recomendación). Finalmente, tras ejecuta make dist, se tendrá la versión 0.2 del programa hola-mundo.

NOTA:

Para probar el prgrama debes tener los “locales” instalados (apt-get install locales-all), además la variable de entorno en el idioma que quieres, ej: export LANG=”es_ES.UTF-8″, deberás tener en cuenta que para este caso deberás instalar el progrmaa (sudo make install) por el lugar donde se ha especificado buscar los *.mo además debes establecer la codificacion de caracteres ej:UTF-8, si usas Gtranslator esto parecería tribial pero es muy importante. Por último la descarga de este ejemplo para que te guies y no te suene ambiuguo lo que he explicado, una tecnica puede ser usr una herramienta diff si ya habias entendido bien el ejmplo anterior.

git clone https://github.com/denisacostaq/EmbeLinux --branch hello-intltool

Autotools(1). Hola mundo a la autotools.

En lo que sique(incluido este como el primero) estaré publicando una serie de posts relacionados con la creación y configuración de proyectos basados en el grupo de herramientas de autotools(antes es aconsejable revisar el directorio /usr/share/doc/gnu-standards, de este no existir ejecuta apt-get install gnu-standards y además ver también este enlace a wikipedia) y algunas otras que se le integran muy bien, además mencionar que me basaré en los lenguajes C/C++ pero que bien se adapta a otro tipo de lenguajes como son C, C++, Java, Python, Fortran, Yacc, awk, etc.

Primero que todo veamos la estructura básica de un proyecto, los directorios y archivos principales que lo componen y después veremos como editamos estos últimos para lograr un proyecto muy básico, nuetro “hola mundo”.

Estructura básica:

Escojemos un directorio en el cual relizaremos nuestro trabajo y ejecutamos la siguiente secuencia de comandos para crear las bases del proyecto.

mkdir -p hola_mundo/src
cd hola_mundo/
touch Makefile.am configure.ac src/Makefile.am src/hello-world.c NEWS AUTHORS ChangeLog README MAINTAINERS HACKING VERSION THANKS TODO

Ejecutando el comando tree -v(man tree) ya visualizamos la estructura actual del proyecto (Fig 1) donde tenemos los archivos principales de información, (compuesto por 2 grupos, los obligatorios Fig 2 (aquí faltan COPYING e INSTALL lo que no los pondré ya que autotools te propone los correspondientes que deberás editar para adptarlo a las necesidades de tu proyecto) y los opcionales (Fig 3)), los archivos inherentes a las herramientas de autotools también llamados de configuración (Fig 4), y por su puesto los archivos/directorios donde estará el código fuente(en este caso solo uno).

Como contenido de estos archivos (los de información) se tiene una explicación sobre si mismos que se puede ver en un link que dejo al final con un ejemplo.

Edición de los archivos de configuración de autotools:

#configure.ac
AC_PREREQ([2.69])
AC_INIT([hola-mundo],[0.0.0], [denisacostaq@gmail.com], [hola_mundo], [blogspoot.com/embelinux])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([1.10.1])
AC_PROG_CC
AC_OUTPUT([Makefile src/Makefile])

Comentaré superficialmente el contenido de este archivo, para una información más detallada ver /usr/share/doc/autoconf-doc/ (apt-get install autoconf-doc), este archivo se escribe en M4.

- AC_PREREQ advierte sobre la verción mínima de autoconf con que debe contar tu sistema (autoconf –version, para saber que valor poner en tu caso).

- AC_INIT tiene como parámetros el paquete, la verción, el e-mail de reporte de bugs, el nombre de empaquetamiento y la url del proyecto en ese orden y no siendo obligatorios todos estos parámetros.

- AC_CONFIG_HEADERS dice donde poner el archivo config.h(que puede tener otro nombre) el cual puede ser usado en el código de nuestro proyecto.

- AM_INIT_AUTOMAKE automake y especificamos que verción (automake –version). Se pueden escribir macros para automake, estas comienzan con el prefijo AM_ .

- AC_PROG_CC especificamos que usaremos el compilador de c y se le pudiera pasar un lista de comprobación, sino la pasamos autoconf comprueba usando una que tiene internamente.

- AC_OUTPUT especificamos los lugares en que queremos un Makefile(también se pueden obtener otros ficheros) como salida.

#Makefile.am
SUBDIRS = src
EXTRA_DIST =  README THANKS TODO HACKING MAINTAINERS

Para este archivo se puede leer el manual GNU Automake.

- SUBDIRS especifica los directorios por los que se debe mover make, es aproximadamente el orden que sequirá el “topological sort”.

- EXTRA_DIST es para incluir en el empaquetado archivos que no son indispensables en el proyecto.

#src/Makefile.am
bin_PROGRAMS = hola-mundo
hola_mundo_SOURCES = hello-world.c

En la variable bin_PROGRAMS especificamos el o los programas binarios que se van a crear. Después como muestra hello_world_SOURCES especificamos el código fuente a partir del cual se creará cada binario fijandote en tranformar el nombre del binario a su forma canónica, ej:hola-mundo -> hola_mundo y agregandole el sufijo _SOURCES.

Una vez editados estos archivos de configuración de proyecto ponemos el código, ej: printf (“hello world\n”); y por último coenzamos a invocar a las herramientas de autoconstrucción.

aclocal
autoheader
autoconf
automake -a (con la opcion -a no pone el archivo COPYING(enlace a /usr/share/automake-1.13/COPYING) e INSTALL(enlace a /usr/share/automake-1.13/INSTALL) como ya había mencionado)
./configure (en este punto se chequea si nuesto sistema está preparado para compilar el programa, por ejemplo desintala el compilador y verás lo que sucede).
make (ya podemos ejecutar nuestro programa que se llama hello_world y está en src).

La llamada a aclocal busca todas las macros m4 en todos los archivos *.m4 en el directorio donde se ejecuta y finalmente en configure.ac poniendolas todas juntas en el archivo aclocal.m4 que genera. El comando autoheader crea el archivo.h.in, autoconf es el responsable de crear el archivo(scrip) configure, automake genera los archivos Makefile.in ,y por ultimo ./configure es quien genera los Makefile a partir de Makefile.in y config.h a partir de config.h.in. A modo de resumen, se muestra en el siguiente diagrama el flujo del funcionamiento de las herramientas (Fig 5).

Fig 5

Adicionalmente podemos ejecutar como root make install que instala nuestro programa en el sistema, por defecto en /usr/local, podemos modificar esto volviendo a ejecutar ./configure pero esta vez con el parametro –prefix=PATH. También podemos ejecutar make dist y nos empaqueta el proyecto.
Como nota adicional comentar que debes tener todas estas herramientas en tu sistema para trabajar con autotools pero una vez que tengas el empaquetado solo necesitas los compiladores, bibliotecas, frameworks y todo de lo que dependa tu programa para compilarse pero no las herramientas con las cuales creates el paquete, o sea ya podrás ejecutar el clásico (./configure ; make ; sudo make install).

git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo

Entendiendo la escencia de las bibliotecas mediante ejemplos de su creación y utilización.

Como ejemplo tomaremos la creación de una biblioteca para cálculos matemáticos, primero la haremos y usaremos estática y después compartida.

Biblioteca estática:

En una biblioteca estática tenemos una serie de procedimientos que son comunes pero cada programa que compilemos a partir de ella incluirá los archivos de los que use cualquier cosa dentro de su propio código atentando contra el tamaño del archivo binario final, no será necesario tener la biblioteca en el entorno en que va a correr el programa.

//plus.c
int plus (int sum1, int sum2)
{ 
    return (sum1 + sum2); 
}

//mult.c
int mult (int fact1, int fact2)
{
    return (fact1 * fact2);
} 

Para obtener el código objeto de estas dos funciones y/o archivos ejecutamos: gcc plus.c mult.c -c, con la opción -c le decimos a gcc que compile o ensamble nuestro código pero que no lo elnace (gcc se refiere a GNU Collection Compilers y/o a GNU C Compiler, pero en este último caso aclarar que no es en realidad gcc quien compila sino que es más bién un driver, o sea encarga a otros programas a hacer el trabajo). Para crear la bibliteca ejecutamos ar -r libmat.a plus.o mult.o, con esto libmat.a queda lista para ser usada como una biblioteca estática (rm *.o *.c).

//main .c
#include <stdio.h>
int plus (int, int);
int mult (int, int);
int main (int argc, char *argv[])
{
    int val1 = 2;
    int val2 = 5;
    printf (“%d + %d = %d\n”, val1, val2, plus (val1, val2));
    printf (“%d * %d = %d\n”, val1, val2, mult (val1, val2));
    return 0;
}
gcc main.c -lmat -o program (produce el siguiente error)
/usr/bin/ld: cannot find -lmat
collect2: error: ld returned 1 exit status 

Ahora ejecutamos gcc main.c libmat.a -o program que sí compila correctamente pero le estamos pasando la ruta de la lib de forma explícita, la manera elegante sería diciendole a gcc enlazate a mat(-lmat) para que él solo la busque pero no lo hemos conseguido porque el enlazador(ld) ha buscado en los directorios que tiene por defecto normalmente(/lib y /usr/lib más cat /etc/ld.so.conf.d/*) así que podemos agregar nustro directorio actual a las rutas de búsqueda con gcc main.c -L. -lmat -o program. Una forma más elegante de compilar es usando la variable de entorno LIBRARY_PATH, que sería así:

export LIBRARY_PATH=$LIBRARY_PATH:.
gcc main.c -lmat -o program

Además para ver lo que decía sobre que gcc es un driver podrias ejecutar gcc -### -lmat main.c -o program con lo que gcc te dice lo que haría si le quitas -### pero no lo hace.

Biblioteca compartida:

A diferencia de una biblioteca estática los programas que se compilan con bibliotecas compartidas (shared object, extención .so) no incluyen el código de estas dentro de sí, sino información de con que lib ha sido enlazado el programa de manera que cuando el programa se va a ejecutar el linkeador (ld-linux, no el que se usa para compilar) determina de qué bibliotecas depende nuestro programa para estar en RAM y de faltar alguna la carga, por ejemplo para el programa que habiamos compilado hasta ahora podemos saber de que depende usando ldd program, deberás notar que no depende de libmat.

Para crear una biblioteca comartida solo tenemos que especificarle esto a gcc con shared, usando todo el codigo que hasta ahora teniamos solo cambiaremos la manera en que creamos la lib y el programa y veremos el impacto:

gcc -c -fPIC mult.c plus.c
gcc -shared mult.o plus.o -o libmat.so
gcc main.c -lmat -o program (que tendrás un error, así que resuelvelo...  )

./prgram (te generará el siguiente error, ./program: error while loading shared libraries: libmat.so: cannot open shared object file: No such file or directory, si ejecutamos ldd program verás que a diferencia de el caso pasado este si depende de libmat y que además “not found”, para resolver esto tenemos que agregar como ruta de busqueda al elnlazador ld-linux(no el de compilar insisto), la ruta donde esté nuestra lib o mejor una solución más pacífica export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. , con lo que puedes volver a ejecutar ldd para ver el cambio y además ya puedes ejecutar a ./program).

Bibliotecas dinámicas:

En este punto solo mencianaré que las bibliotecas dinámicas son una “forma” de las bibliotecas compartidas la diferencia es que en ahora el SO no autodetecta las bibliotecas de que depende el programa y las carga de forma automática, es el programador quien tiene esta responsabilidad, básicamente se cargan bajo demanda, tiene la ventaja de que la aplicación se carga en RAM más rápidamente y el inconveniente de que es el programador quien tiene la responsabilidad de hacer entonces ese trabajo, pudiera ser por ejemplo usando la lib ltdl que cuenta con funciones como dlopen.

En algún que otro post relacionado con autotools+libtool veremos como los humanOS hacemos esto, ya que hasta ahora solo vimos el método de los  “dinosauriOS” .

Domótica.

Fig 1.

 “La tecnología aplicada al hogar”(Fig 1), conocida como Domótica, integra  automatización, informática y nuevas tecnologías de comunicación; todas ellas dirigidas a mejorar la comodidad, la seguridad y, en definitiva, el bienestar dentro de los hogares. Esta contribuye principalmente  en aspectos cotidianos como: iluminación, climatización, seguridad, comunicación, etc.

Tal vez por error, es usual que algunas personas usen indistintamente otros términos en lugar de Domótica, ejemplos de esto son; “Hogar Inteligente” (término que se empleaba antes de surgir la Domótica, el término “Hogar Inteligente” suele ser más interpretado por las personas como la soluciones futuristas que como las novedades tecnológicas del momento), “Hogar Digital” (ya que es, gracias a la digitalización, que son posibles los nuevos equipos y/o servicios, aunque este está más estrechamente relacionado con las telecomunicaciones), “Inmótica”(que hace referencia a la coordinación y gestión de las instalaciones con que se equipan las edificaciones, así  como a su capacidad de comunicación, regulación y control, aunque “Inmótica” es de uso común, todavía no ha sido recogido por el diccionario de la Real Academia. Mientras la palabra Domótica se aplica al hogar, por Inmótica se entiende la incorporación de sistemas de gestión técnica automatizada a las instalaciones del sector terciario como son plantas industriales, hoteles, hospitales, aeropuertos, edificios de oficinas, parques tecnológicos, grandes superficies, universidades, instalaciones comunitarias en edificios de viviendas, etc. En realidad, los sistemas y aplicaciones Inmóticas son muy similares a los de la Domótica y, por ello, a menudo se emplea el concepto de sistemas Domóticos referidos también a este sector). La palabra Domótica tiene varios significados, según el diccionario de la Real Academia es “el conjunto de sistemas que automatizan las diferentes instalaciones de una vivienda”, pero se debe tener en cuenta que esto está en continuo cambio y bajo constantes discuciones y aunque todos estos son términos diferentes se encuentran estrechamente relacionados. Además, la Domótica no es aplicada solo a los hogares, también puede aplicarse a una oficina por citar un ejemplo.

Ya presentadas las diferencias entre cada uno de cada uno de estos términos tomaremos todo esto como una sola idea y lo trataremos más apmpliamente usando solo la palabra Domótica. Hoy no concebimos una vivienda que no tenga a gua corriente o electricidad, así mismo tal vez algún “día” podriamos no concebir una vivienda que no esté aunque sea minimamente “Domotizada”, el principal problema que ha afrontado la Domótica es que muy pocas personas han estado de acuerdo con incurrir en los costes adicionales pero el abaratamiento de las tecnologias ha hecho que ese “día” se parezca cada vez más al de hoy. En los últimos años el desarrollo vertiginoso de la ciencia y tecnología a traido con sigo un impacto directo en toda nuestra vida cotidiana, ya sea donde recidimos, donde trabajamos, o donde nos recreamos, de una forma u otra donde quiera que estés coincidirás en esto, te encontrarás con que la Domótica es algo de futuro pero en algún grado ya está presente en nuetra vida diaria. La aplicacion de la Domótica depende de las necesidades particulares de cada usuario final, pero de manera general el interés por la Domótica es una realidad palpable en la sociedad. Según los expertos, la infraestructura básica para domotizar una vivienda, sólo encarece el precio entre un 1-2 % de media; algo ínfimo si se pondera lo mucho que mejora el atractivo de cara al público.

Pero… ¿Qué significa vivir en un hogar digital y conectado?:
Algunas de las ventajas de vivir en un hogar digital y conectado, se ven en la siguiente imagen (Fig 2).

Fig 2. Aplicaciones de la Domótica.

Fig 3. Terminal de monitoreo/control

La terminal central(en caso de los sistemas con arquitectura centralizada según su tipología ver Fig 5 y el libro que aparece al final en “NOTA:” para más detalles) de supervición/control puede estar fija en un lugar de la casa(Fig 3-5), en una PC del propietario de la casa, en un servidor remoto accesible via internet, en un teléfono movil, en una agencia privada de seguridad(Fig 4), etc.

Fig 4. Agencia privada de seguridad.

Fig . Sistema de supervivió/control centralizado.

Como es de suponer en todo este sistema intervienen una serie de sensores(de radioondas, vibraciones, temperatura, presión, etc), actuadores (acciones de control para cierre de válvulas, desconección de equipos, activación de alarmas, etc), y equipos de uso domésticos que necesitan comunicarse entre ellos y con el exterior. La siquiente imagen muestra una red de Domótica cuyo componente principal (para esta topología) es la pasarela residencial que es la que media en la comunicación entre todos los equipos y el exterior.

Fig 6. HAN (Home Area Network).

Bibliografía:
Domótica. Edificios inteligentes. Ediciones Copyright. Madrid.(2004)
Domótica y hogar digital. Editorial Thomson-Paraninfo. Madrid.(2004)
Domótica e inmótica. Edificios inteligentes. Editorial Ra-Ma. Madrid.(2005)

NOTA:

Este post se basa (intenta ser un resumen de los conceptos más básicos) en una exelente publicación lanzada en España (La Domótica como Solución de Futuro. Guía descargable en formato pdf desde la sección de publicaciones de la página web), guía, en cuya elaboración han intervenido profesionales con una amplia experiencia en este campo, se abordan distintos temas, de una manera sencilla pero a la vez rigurosa, en algunos casos con ejemplos prácticos de cómo se puede llevar a la práctica las soluciones que se van comentando. Además la bibliografía mencionada aparce en esta y ha sido consultada ligeramente.

El mito de la desconexión

En los últimos años, el florecimiento de las comunicaciones ha creado una cultura “on-line” en la que miles de personas trabajan, viven, se comunican y relacionan entre sí. Redes sociales como Facebook borran la barrera de las fronteras permitiendo que seres humanos de distintas latitudes se conozcan, se enamoren, etc.

Junto a esto a surgido la llamada “cultura de la desconexión”.  Personas que abogan por lo “ficticio” de ese mundo “online” y se niegan a reconocer como “verdadero” todo lo que ocurre en el, catalogando de adictos , enfermos y enajenados a todos los que digan lo contrario.

Pero, ¿quien tiene la razón? ¿Acaso existe la llamada realidad 2.0?.  Cada facción, grupo o person tiene su conjunto de opiniones al respecto. Aquí van las mías.

Qué es reál y que no lo es.

La alegoría de la caverna (de el filósofo griego Platón)  nos cuenta de  un espacio cavernoso que alberga un grupo prisioneros, sujetados desde su nacimiento por el cuello y las piernas mediante cadenas de forma que únicamente pueden mirar hacia la pared del fondo de la caverna sin poder nunca girar la cabeza. Detrás de ellos, se encuentra un muro con un pasillo y, seguidamente y por orden de cercanía respecto de los hombres, una hoguera y la entrada de la cueva que da al exterior. Por el pasillo del muro circulan hombres portando todo tipo de objetos cuyas sombras, gracias a  la hoguera, se proyectan en la pared que los prisioneros pueden ver.

Estos hombres encadenados consideran como reales las sombras de los objetos. Debido a las características de su prisión toman unicamente por ciertas las proyecciones de las personas que cruzan sobre el muro. Esto constituye su realidad.

Se plantea entonces la hipótesis. ¿Qué pasaría si uno de estos prisioneros fuese liberado y obligado a volverse hacia la hoguera,  contemplando, de este modo, una nueva realidad?  Una realidad más ricay completa donde ya no solo contempla las sombras, sino su origen y comprende que todo lo que conocía estaba limitado por su percepción. Pero no se detienen ahí, de nuevo el ex-prisionero es obligado a salir de su entorno habitual y marchar  fuera de la caverna apreciando una nueva realidad exterior (hombres, montañas, lagos, astros, etc. identificados con el mundo inteligible), conociendo nuevas formas, aumentando su concepto de lo real.

La alegoría acaba cuando el prisionero regresa de nuevo a la caverna para “liberar” a sus antiguos compañeros de cadenas y estos se burlan de él, le dicen que  sus ojos se han estropeado, que ha perdido la razón. Al tratar de liberarlos, sus compañeros se resisten y eventualmente terminan por asesinarlo y quedarse en la caverna, rechazando la nueva realidad.

Otros escritores y filósofos han planteado situaciones parecidas. Asimov en su cuento “Las Estrellas”, crea un planeta que orbita alrededor de un sistema binario  y que tiene la particularidad que solo oscurece cada miles de años. Las sociedades que florecen en el período “diurno” de la historia del planeta, toman a “Las Estrellas” como un mito y al llegar el período nocturno enloquecen al no poder aceptar su existencia y destrullen la sociedad, dejando para de nuevo escritos acerca de las terribles luces que aparecen en el cielo para acabar con la humanidad.

Entonces, ¿quien decide que es lo real y que no?. ¿Es la realidad lo que podemos experimentar con todos nuestros sentidos?. ¿Y las personas con discapacidad sensorial, no experimentan lo real? ¿Y los que sufren de algún tipo de alteración de la percepción como sinestesia, daltonismo, etc?

..todo es mejor si es cara a cara.

Desde aquellos tiempos en que el hombre de Cromagnon, decidió que eso pelirrojo que caminaba frente a su guarida (un Neanderthal) no le caía bien y se dió cuenta de que uno a uno no podía machacarle la cabeza así que reunió a la tribu y entre gestos y alaridos logro que le prestaran ayuda (aquí también empezaron las pandillas pero eso es para otro post), los seres humanos hemos establecido la comunicación personal como paradigma. Pero: ¿eso significa que es mejor que el resto? ¿Qué hay de las maravillosas cartas que se han escrito entre sí cientos de personajes históricos? ¿De la capacidad que le brindó hace miles de años la palabra escrita a un señor desconocido en Asia Menor para hacerme llegar a través del tiempo y el espacio las historias del rey Nabucodonosor o la epopeya de Gilgamesh?. En algún momento de la historia los seres humanos sobrepasamos la necesidad de comunicarnos y comenzamos a tener la de informarnos y poder expresar nuestra opinión más allá de nuestro círculo cercano de conocidos (también conocido como tribu) por lo que primero caminamos hasta el foro en Atenas, después escribimos extensas cartas y cuando Guttemberg invento la imprenta empezamos a hacer periódicos… así hasta la televisión y ahora internet (gracias a lo cual están ustedes se están enajenando en este blog).

¿Alcanza entonces la palabra hablada para comunicar todo lo que sentimos?. ¿Una sesión privada de IRC cuenta como conversación personal? ¿Un videochat cuenta?

Quiero hablarte en este momento

El telégrafo, el teléfono, Internet, la telefonía móvil, los SMS. La comunicación instantánea ha sido perseguida de muchas modos y a llegado incluso a sustituir a las formas anteriores, ha ido evolucionando de letras impersonales a su propio l3nguaje k h4ce + fcil a akllos k lo practican entenderse, unirse, convertirse en una cultura universal guiada solo por la necesidad de conversar. Si el lenguaje es base para la cultura y la sociedad, ¿puede alguien decir que no estamos experimentando el nacimiento de un nuevo tipo de sociedad?

Terminando

Queda mucho por decir, aún no he hablado de la realidad aumentada, de Youtube, de la Wikipedia, de la cultura de IRC, pero creo que ya he cumplido el propósito de plantear preguntas donde otros ven solo respuestas. ¿Estamos frente a la muerte de la palabra hablada? ¿Es la desconexión una necesidad o una aberración? ¿Es enajenación o evolución lo que sufrimos?. Respóndanse ustedes mismos.

Saludos.

Tomado de: CodeNinja (un blog en una subred privada) .

firmware-stm3210fx3 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Con esta plantilla tienes la oportunidad de trabajar con la biblioteca de periféricos STM32F10x_StdPeriph_Lib y el kernel FreeRTOS.

 git clone https://github.com/denisacostaq/firmware-stm3210fx3.git

Ver además: Un proyecto plantilla en autotools para STM32EVAL10X.

firmware-stm3210fx2 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Con esta plantilla tienes la oportunidad de trabajar con la biblioteca de periféricos STM32F10x_StdPeriph_Lib.

git clone https://github.com/denisacostaq/firmware-stm3210fx2.git

Ver además: Un proyecto plantilla en autotools para STM32EVAL10X.

firmware-stm3210fx1 "SEE" Un proyecto plantilla en autotools para STM32EVAL10X

Esta plantilla es la más básica de todas, solo te garantizo que compila pero el resto deberás agregarlo tú.

git clone https://github.com/denisacostaq/firmware-stm3210fx1.git

Ver además: Un proyecto plantilla en autotools para STM32EVAL10X.

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

Invitación - Defensa de tesis de grado sobre Diseño de una Computadora de Vuelo para UAVs - Martes 11/6 19hs

Invitación a la defensa de la tesis de grado del Sr. Alan Kharsansky, sobre "Diseño e implementación de un sistema embebido de control de actitud para aeronaves no tripuladas", que tendrá lugar el día martes 11/6 a las 19hs en el aula 211-A del segundo piso de la Facultad de Ingeniería de la UBA, Av. Paseo Colón 850, Buenos Aires, Argentina.

El trabajo incluye el diseño, implementación y validación de una computadora de vuelo para un cuadricóptero basada en el LPC1769 (Cortex-M3) y el FreeRTOS, y todo el proceso de modelado, identificación y diseño a partir del cual mediante un conjunto de controladores PID elementales se logra el control en vuelo libre de la aeronave. Para ver un vídeo del Quad en vuelo y obtener más información, así como para acceder a una memoria de la tesis, visitar la página web: