Archive for Otras cosas

BeagleBoard hacking (I)

(Si a esto se le puede llamar “hacking”)

Introducción y todo eso

La historia va más o menos así: Hasta hace poco no he tenido contacto con microcontroladores ni con la programación a nivel de máquina de verdad. Yo le echo la culpa al plan de estudios, ya que no se ve casi casi nada sobre estas cosas. Parece que entrenan a la gente ya directamente para que trabaje en consultorías, pero esto es otro tema.

Como ha resultado gustarme un montón este tema y parece que mi carrera profesional va a ir tirando por ese campo, es hora de que aproveche cada rato libre que tenga para hacer chapucillas y experimentos con micros, para recuperar el tiempo perdido. Es una lástima también que sea un terreno menos accesible que otros como la construcción de software de escritorio, aplicaciones web o bases de datos, ya que para aprender realmente a manejar un micro necesitas cierto material hardware, que en muchos casos no es ni siquiera asequible para un pobretico estudiante.

El caso es que ahora sí que dispongo de material, ganas y tiempo (más o menos). Tengo una placa de evaluación AT91EB40A que me dejó Jesús y que viene de lujo para aprender a hacer cosas sobre el ARM7TDMI y a manejar dispositivos y todas esas cosas. También estoy en medio de un proyecto sencillito con un PIC para controlar una matriz de 8×8 leds como si fuera una pantalla. Es una chulería porque así aprendo también a hacer mis propias placas de circuito impreso, entre otras cosas.

El cacharro

Y luego tengo la Beagle, que tiene el inconveniente de que no es una placa orientada al aprendizaje de estos chanchullos a bajo nivel, sino que está hecha para meterle un sistema operativo como Linux y programar sobre eso. Para empezar, el OMAP3 es una bestia de micro (el manual ronda las 3500 páginas), y los dispositivos de la placa no son tan fáciles de manejar como los de las placas de evaluación porque se controlan muchos de ellos a través de otros chips de apoyo, como el TPS65950. Pero algo se puede hacer, y todo es ponerse con un poco de paciencia. Además estoy aprendiendo un montón.

Metiéndonos en harina

Bien, lo que pretendo es ir escribiendo en el blog los experimentillos que voy haciendo, porque si no se me acabarán olvidando. Y si le sirven a alguien, pues mejor todavía. De todas formas, muchas de las cosas que pondré están sacadas del trabajo de otras personas que he encontrado por ahí.

Si dios quiere y tengo tiempo, la idea es hacer un experimento sencillo en la Beagle (por ejemplo, encender leds de la placa y recoger el estado de un botón) de varias formas, desde el nivel más bajo posible, en ensamblador y sin sistema operativo, hasta llegar al nivel de usuario en Linux.

Así que esta primera parte tratará lo más sencillo de todo: Cacharrear con los leds y el botón USER de la placa desde linux y al nivel más alto posible.

Ingredientes

Antes de nada, vamos a suponer que tenemos todas las cosas siguientes:

  • Una BeagleBoard
  • Un Linux instalado en ella. Yo estoy utilizando Debian
  • Alguna forma de acceder a una shell en el Linux de la placa. Yo conecto a través del puerto serie con el PC, pero se puede utilizar un teclado y un monitor en la placa directamente.
  • Manual de la BeagleBoard:  BeagleBoard System Reference Manual (se puede encontrar en beagleboard.org)
  • Manual del OMAP3530 (ojo, bicharraco de manual):  SPRUF98D (se puede encontrar en la web de Texas Instruments)

Detalles a tener en cuenta

Para poder hacer este experimento en concreto es necesario activar una opción del kernel llamada “CONFIG_GPIO_SYSFS”. Mirad a ver si la teneis activada. Si no lo está, habrá que compilar un kernel con esa opción. Cosas de la vida.

El meollo

Bien, cumplidos los requisitos anteiores vamos a ver qué podemos cacharrear con la placa. Como he dicho antes, hay unos cuantos dispositivos de la placa conectados directamente a GPIOs del micro. Entre ellos están los leds 0 y 1, y el botón USER. El puerto de expansión es todo gpios, pero para ver los resultados de activarlos y desactivarlos ahí habría que pinchar algo (un led nos vale).

Empezamos por los leds. Con el SO que le tengo yo instalada a la placa, una vez que este está en marcha, uno de los leds se pone a parpadear constantemente. Como molesta, vamos a ver cómo se puede apagar.

Como esta primera parte es para explicar cómo hacer estas cosas en espacio de usuario sin mancharse mucho, vamos a hacer uso del sysfs. El kernel de linux, si está configurado para ello, nos exporta amablemente a este sistema de archivos virtual muchas de las interfaces necesarias para toquetear el hardware. En nuestro caso, hay unos directorios que son /sys/class/led/beagleboard::usr0 y /sys/class/led/beagleboard::usr1 a través de los cuales podemos manejar esos dos leds a través de unos pseudoarchivos.

Por ejemplo, queremos apagar el led0 o, al menos, cambiar el modo de conmutación. Pues si miramos en un archivo llamado trigger dentro del directorio del led0 y vemos que la salida es algo así:

none mmc0 [heartbeat]

Es decir, que tiene 3 modos de encendido: “None” se supone que es para que no se encienda, “mmc0” para que se encienda cuando se hacen transferencias desde o hacia la tarjeta de memoria, y “heartbeat” que es el que está seleccionado, pues para que parpadee como los latidos de un corazón.

Así que si queremos apagarlo lo único que hay que hacer es cambiar el modo de encendido (en este caso a “none”). Lo podemos hacer así de simple:

echo “none” > trigger

La abstracción que nos proporciona el kernel nos permite olvidarnos de los detalles del hardware y hacer este tipo de operaciones así de sencillo, como escribir o leer en un archivo.

¿Y el directorio del botón USER dónde está? Esto es otra cosa. Los gpio de los leds 0 y 1 (gpio 149 y 150 respectivamente) están, por decirlo de algún modo, “reclamados” por el kernel. Pero el gpio 7, que es el del botón, no se está usando de momento. Sin embargo, podemos pedirle al kernel que nos exporte una interfaz en el sysfs para manejarlo.

Esto se hace en el directorio /sys/class/gpio. Entre otras cosas, hay allí un par de archivos llamados “export” y “unexport” que sirven precisamente para eso. Nosotros queremos acceder al gpio7, así que hacemos lo siguiente:

echo 7 > export

Y el kernel nos dará un nuevo directorio llamado gpio7 a través del cual podemos configurar y consultar el botón USER. Por ejemplo, podemos ver que dentro de ese directorio hay un archivo “value”. Si este archivo lo consultamos sin pulsar el botón:

cat value

nos devolverá 0, pero si repetimos la operación con el botón pulsado nos devolverá 1. Así, sin tener que meternos a programar módulos del kernel ni drivers, podemos utilizar esto para utilizar el estado del botón en una aplicación sencilla (mediante polling):

#include <stdio.h>
#include <unistd.h>

int main(void)
{
        int state = '0';
        FILE *fd;
        int read;
        unsigned int usecs = 100000;

        while(1) {
                fd = fopen("/sys/class/gpio/gpio7/value", "r");
                read = fgetc(fd);
                fclose(fd);
                if(read != state) {
                        if(read == '1') {
                                printf("Boton pulsado\n");
                                state = '1';
                        }
                        else {
                                printf("Boton soltado\n");
                                state = '0';
                        }
                }
                usleep(usecs);
        }
}

Lógicamente, el polling no es la técnica más eficaz. Pero en otras entregas del minicurso este veremos si dios quiere, cómo hacer estas cosas como los hombres. Es decir, con interrupciones a nivel de kernel. Un saludete

Anuncios

Comments (1)

Resumen de la primera jornada del Hackaton

Bueno, por fin llegó el día y por fin de vuelta a la normalidad. Va a resultar que ese era el motivo por el que andaba tan inquieto estos últimos días. Me lo intenté tomar con naturalidad, pero es que nunca he presentado nada delante de la gente.

En resumen ha ido todo genial. La asistencia ha estado bien, no tantos como había apuntados, pero hay que tener en cuenta que es un evento en el que te van a mandar trabajar por amor al arte. La gente que había iba con muy buena voluntad y con ganas de aprender, y eso es lo mejor.

En primer lugar quiero agradecer a todos los de la OSL por la organización, que se lo han currado un montón y son una gente muy apañá. Nos han ayudado mucho.

La parte de las presentaciones (la mía, Kora, ReMa y Visuse) estuvo mu chula, yo por lo menos me lo pasé muy bien. Sobre todo por el ambiente que había. Todos íbamos un poco en plan “mirad, esto es lo que tengo de momento, no os riais”, pero vamos, a mí me gustaron todas. Por la temática me gustó más Kora, porque me parece muy bonito que un proyecto surja con el objetivo de ayudar a personas con dificultades. Sólo por el tema de investigar acerca de la interacción hombre-máquina para personas discapacitadas ya me parece que el proyecto merece la pena de verdad. Mu chulo.

Kaos nos dio después una charla acerca de subversion, que el pobre se la estuvo preparando la noche de antes para explicarlo todo bien y al final, cómo no, tuvo que haber problemas. Va a resultar verdad lo que decía Linus Torvalds de que es bastante mejor como sistema de control de versiones utilizar tarballs y parches que subversion.

En la parte individual de cada uno pude dar rienda suelta por fin a mi vena de profesor frustrado y para mí fue lo mejor del día, porque la gente que se vino conmigo me sorprendió de verdad con todo lo que saben. Para empezar, creía que por el tema que elegí para la charla no vendría casi nadie a verla, porque las otras trataban de temas bastante más populares: Android, python, php, etc. Pero los que vinieron conmigo ya tenían experiencia de sobra en Java y venían con ganas de aprender OSGi (lo poco que yo podía enseñar). Vamos, que casi me tienen que enseñar ellos a mí.

Desde aquí, si lo estais leyendo, muchas gracias equipo por venir, y porque sois unos cracks. Ya visteis que no tengo casi nada que enseñaros, pero si por lo menos os pude ayudar a introduciros al tema de OSGi, pues con eso estoy más que satisfecho.

La primera hora y media de trabajo (de 12:30 a 14) me dio tiempo a soltar la segunda presentación entera y a enseñar cómo iba la aplicación y poco más. Luego por la tarde les expliqué en detalle cómo se aplicaban las tecnologías que vimos por la mañana a Oolong, resolvimos dudas, hablamos de unas cuantas cosas técnicas y repasamos todo el código de la aplicación para que todos estuviéramos familiarizamos y para que ellos le perdieran el miedo y vieran que, en realidad, el código es una chorrada. Además cada uno probó la aplicación en su propio portátil y es genial cuando te das cuenta de que a todos les funciona sin problemas.

Me sorprendió también ver las ganas de trabajar que tienen todos, vamos, que venían a aprender de verdad. Yo me conformaba con tener un plugin más para Oolong y a lo mejor este fin de semana sale la aplicación ya bastante completa. De nuevo gracias a todos.

Ah, mil gracias también al equipo de traducción. Nunca había conocido a nadie con tantas ganas de colaborar, más si es por el software libre. Me dejasteis flipado también con vuestra profesionalidad y vuestros conocimientos. Un 10 para vosotros, de verdad.

En resumen, un día mu bueno. No sabía que podía hablar tanto en un solo día. He conocido a unos auténticos máquinas y me vengo a casa con la sensación de que el proyecto le ha gustado a la gente. Lo único negativo es que me gustaría haber visto más en detalle algunos de los otros proyectos y trabajar en alguno de ellos (si tuviera tiempo, claro), porque ya digo, me han parecido muy chulos.

Ya que el equipo que se vino conmigo va a desarrollar cosas para Oolong, a lo mejor este fin de semana me dedico yo a otras cosas como arreglar el kernel que hice para la placa, porque cuando compilé aquel kernel específico para ella no configuré la compilación para que se crearan unos módulos que hacían falta, como el de ethernet para el hub que utilizo. Así que arreglaré eso y a ver si apaño unos scripts para configurar fácilmente la red de la placa. A ver si el lunes puedo llegar allí y enseñar el funcionamiento de todo el sistema, con el pc y la placa al mismo tiempo.

Comments (1)

¡Se acerca el Hackatón!

Como ya comenté hace un tiempo, voy a participar en el Hackatón que se va a realizar en la ETSIIT de Granada para presentar el proyecto y ver si se une alguien, aunque sea por entretenimiento (y un crédito de libre).

Ya se ha abierto la participación, aquí está toda la planificación y aquí el formulario de registro para confirmar la asistencia.

Así que si vas a estar por allí los días 5 y 8 de Marzo apúntate y aunque sea ves lo que hay por ahí. De momento estamos sólo cuatro gatos presentando proyectos, pero bueno, así da más tiempo a explicar las ideas y las técnicas que se utilizarán. Además, por mi parte intentaré hacerlo todo muy didáctico y muy sencillo, para que pueda participar cualquiera.

Gracias desde aquí a JJ Melero por organizar estas cosillas.

Dejar un comentario

Experimentos en ensamblador

Tradicionalmente siempre he preferido las cosas relacionadas con el software que las de hardware, siempre he preferido la programación a alto nivel. Pero desde que cursé la asignatura de Arquitecturas Especializadas me viene picando cada vez un poco más el gusanillo de la programación de sistemas. Eso de conocer al detalle cómo se programa un micro y hacer cosas que son imposibles en un lenguaje de alto nivel, o programar para máquinas con muy pocos recursos a ver cuánto se puede sacar de ellas cada vez me gusta más.

Últimamente vengo mirando cantidad de información en Internet acerca de cosas que siempre quise aprender, y aquí estoy interesándome a nivel técnico por el Z80, la Master System, el MSX y todas esas cosas que me gustaban de pequeño (y que nunca me han dejado de gustar), 20 años después.

En fin, que ando haciendo algunos experimentos en ensamblador porque me servirán para aplicarlos a la placa del proyecto y conocer mejor su hardware y sus posibilidades. Además así tendré más material para incluir, por ejemplo, en el primer informe técnico

Dejar un comentario

Hackaton en Granada

JJ Merelo, el encargado de la Oficina de Software Libre de la Universidad de Granada, ha reservado aulas para un par de días a mitad del concurso para organizar un seminario sobre los proyectos de software libre que se están desarrollando en la universidad.

Constará de dos días:

  • El primero (viernes) se hará una presentación de los proyectos, con lo que cada uno lleve hecho y todo así llamativo para que la gente se apunte. Los asistentes podrán apuntarse para colaborar con uno de los proyectos presentados. Durante el fin de semana de hará un pequeño desarrollo en equipo para el proyecto
  • El segundo día (lunes) se presentarán las mejoras hechas en grupo.

Las fechas son el 5 y el 8 de Marzo. Se convalidará la asistencia por un crédito de libre configuración (a buenas horas, que ya los tengo todos cubiertos con asignaturas) y se harán certificados y todo eso.

La verdad es que es una idea muy chula y me hace bastante ilusión porque nunca he presentado ninguna propuesta de…nada. Además creo que el proyecto le gustará a la gente. Ojalá para esas fechas pueda tener algo casi terminado y preparado para hacer un desarrollo fácil en grupo que se pueda explicar incluso a gente con conocimientos muy básicos. Por ejemplo, un plugin para Oolong o para el servidor Tea estaría chulo.

Ya iré comentando cómo va marchando la idea.

Un saludo.

Comments (2)