Entries for empotrados

Una vez que tenemos listo todo el tema de gráficos . y automatizado el proceso de arranque, toca empezar con detalles estéticos. Para ello, debemos evitar situaciones cómo un salvapantallas o que el monitor se apague.

Recordad que estamos en un entorno en el que no tenemos teclado ni ratón, por lo que en seguida, el sistema operativo pensará que no hay actividad en el equipo.

Hace unas semanas empecé a trabajar en una librería MQTT, con dispositivos empotrados en mente. La idea es que esta librería provea de las funciones de MQTT y así los clientes puedan encargarse de la gestión de la red. Con esto se puede reutilizar este código para distintas plataformas, cómo pueden ser Arduino ó LPC1768, pero también desde Linux.

Todo empezó cuando estaba evaluando distintas alternativas. Por casualidad me encontré con liblwmqtt en Google Code, desarrollada por Filipe Varela. Tras hablar con él, decidí hacer un fork y así nace libemqtt.

El código está disponible en Github:

https://github.com/menudoproblema/libemqtt

Vamos a seguir preparando nuestra Alix. En la última entrega explicamos cómo instalar un servidor gráfico y un escritorio.

Ahora, lo siguiente es ver cómo automatizar ciertas tareas. Recordad que el objetivo es tener este dispositivo de cara al público, por lo que es muy importante que todo esté automatizado. La mayor restricción es que no habrá teclado ni ratón disponible, sólo una pantalla.

Estos días he posteado acerca de cómo instalar y configurar Debian en cualquier Alix. Hoy me voy a centrar en un modelo particular Alix.1D, el cuál trae salida VGA, lo cuál lo hace especialmente atractivo para realizar pequeñas exposiciones, pases de diapositivas, museos, etc.

Para ello, partiendo de una instalación básica como la que ya se ha comentado, en esta serie de artículos trataré de describir muchos de los aspectos que se pueden tener en cuenta.

Ayer contaba como podemos hacer una instalación básica de Debian sobre Alix. En concreto, faltó la instalación de un kernel y un gestor de arranque para tener un sistema operativo funcional. Cada uno puede elegir el software y las versiones que quiera. Yo en mi caso particular voy a utilizar la versión estable de linux para 486 y Grub2.

Alix es un pequeño PC empotrado que utiliza procesadores AMD Geode LX. Estos equipos son muy pequeños y no se calientan, por lo que no es necesaria refrigeración externa (ni siquiera un ventilador). La limitación de la mayoría de los dispositivos Alix es la falta de salida VGA y el dispositivo de almacenamiento: CompactFlash. Por tanto, la instalación típica se hace desde un PC en la tarjeta de memoria y luego Debian arrancará desde la tarjeta de memoria una vez colocada en Alix.

Hace unos días conseguí una placa de evaluación LPC1343 de NXP, descargué LPCXpresso y todo iba bien. Tras trabajar algunos días con ella, me he encontrado el siguiente error al intentar flashear:

Error launching Debug\blinky.axf
02:Failed on connect: Ee(07). Bad ACK returned from status - wire error.

Durante estos días, en el trabajo, estamos buscando un sistema operativo para sistemas empotrados que se adapte bien a nuestras necesidades. A lo largo de los próximos días iré contando acerca de las experiencias con Contiki. Este sistema operativo es un proyecto relativamente joven, con buen soporte para algunos dispositivos de radio que estamos barajando y listo para rodar IPv6.

Hace pocos días escribía acerca de como crear un toolchain para compilar para una arquitectura distinta: MIPS. Ahora voy brevemente a contar como podemos compilar un intéprete de Python para un dispositivo integrado.

El principal problema que hay es que para compilar para arquitecturas como MIPS o ARM es necesario un parche, por lo que la compilación directa no es posible. Yo he seguido este tutorial y he usado la misma versión, Python 2.7.1, y el mismo parche y todo ha funcionado perfectamente.

Ayer terminaba un artículo acerca de cómo construir un toolchain con crosstool-ng, pero ahora voy a explicar como utilizar uno de los ejemplos disponibles para partir desde una base concreta. Como ya comentaba, en la página de croostool-ng hay disponible una serie de ejemplos desde los cuales podemos partir.

Hace un rato explicaba en qué consiste la compilación cruzada y ahora vamos a ver como montar un toolchain para poder hacer esto. Para ello he elegido la herramienta crosstool-ng ya que nos permite automatizar el proceso.

En mi caso voy a generar una toolchain para generar código en una arquitectura MIPS, ya que voy a implementar algunos programitas para un router. Además, he elegido Debian Squeeze como plataforma de trabajo, pero también lo he probado sobre Ubuntu 10.04 con el mismo resultado.

Ayer hablaba brevemente acerca de newlib. Hoy voy a analizar otras dos librerías importantes: uClibc y EGLIBC. Ambas son compatibles con GLIBC, la biblioteca C de GNU.

¿Qué es newlib? Es una implementación de la librería C pensada para dispositivos empotrados y desarrollada por RedHat. Esta es la librería que algunos utilizan para dispositivos empotrados, ya hablaré más adelante de ella.

Estos días estoy trabajando bastante con el tema, y voy a explicar brevemente qué es y por qué se utiliza la compilación cruzada. Por lo general, los programadores, estamos acostumbrados a compilar para la arquitectura sobre la que se ejecutará el binario. Es decir, programamos en la misma máquina en la que se ejecutará la aplicación. Esto no siempre es posible.

La compilación cruzada o cross-compiling consiste, por tanto, en generar binarios para una arquitectura distinta a la que estamos utilizando para compilar. Por ejemplo, generar un ejecutable para un procesador ARM desde una arquitectura IA-32 o AMD64.