Introducción

Emdebian es una distribución Debian especialmente diseñada para dispositivos empotrados. Su principal característica radica en el poco espacio que ocupa la distribución.

Emdebian ofrece una Toolchain, un conjunto de herramientas de compilación cruzadas para crear paquetes para nuestra plataforma y repositorios con paquetes que ofrecen soporte a arquitecturas arm, ia64, m68k, mips, mipsel, powerpc y sparc. La instalación puede realizarse desde una máquina Debian con una arquitectura distinta a la arquitectura destino sin ningún tipo de problema utilizando debootstrap o, como se hará en ésta receta, utilizando multistrap, que permite crear un sistema nuevo utilizando varios repositorios y echando mano de apt y dpkg para solucionar posibles conflictos.

Qué necesitamos

Pues como he dicho anteriormente, utilizaremos multistrap, así que nos lo instalamos en nuestra máquina (ya sabeís, apt-get o aptitude bla, bla, bla…).

Además, supondremos que seguimos las recetas anteriores sobre cómo compilar Linux para mini2440 y sobre cómo configurar u-boot para arrancar el sistema desde una micro-sd.

Deberemos tener una tarjeta microSD con dos particiones, una para el núcleo y otra que dejaremos para el sistema (como se explicó en la receta sobre la compilación de Linux). Tendremos el árbol de directorios resultante de la compilación de Linux, pues lo necesitaremos para instalar los módulos del núcleo.

Creación de la imagen

Como se comentó anteriormente, utilizaremos multistrap para crear la imagen de emdebian. Para ejecutar multistrap antes deberemos crear un archivo de configuración en el que especificaremos los repositorios desde los que descargaremos los paquetes, la arquitectura destino y el directorio que se utilizará como destino para la instalación, entre otras cosas. El archivo que he utilizado yo es el siguiente:

La clave arch especifica la arquitectura destino de la distribución, en éste caso armel y la clave directory especifica el directorio destino en el que se desplegará la instalación. En nuestro caso, lo hará dentro del directorio multistrap, subdirectorio del directorio en el que se encuentra nuestro archivo de configuración.

Es importante que la clave cleanup esté comentada (o puesta a false). Ésto hará que la caché de apt no se limpie tras la instalación, pues necesitaremos los paquetes para reinstalarlos en el último paso desde la plataforma destino. El resto de opciones del archivo se pueden ver en la página sobre emdebian, así que no las comentaré aquí.

Guardamos el fichero con el nombre multistrap.conf (por darle algún nombre). Después, podemos instalar:

Podemos ver que el directorio multistrap en el que quedará instalado emdebian y el archivo de configuración están bajo el mismo directorio. Tras invocar a multistrap podremos ver como se descargan los paquetes y se desempaquetan dentro del directorio multistrap.

Ahora tendremos un sistema muy básico que todavía no es funcional del todo. Tendremos que reinstalar todos los paquetes en el sistema destino, para lo cual deberemos poder logearnos. Como la distribución que tenemos es muy básica, no podremos hacerlo, puesto que /etc/passwd aún no existe, así que nos lo creamos nosotros:

Como podemos ver, también hemos creado el archivo /etc/group. Recordad tener cuidado con no sobreescribir los archivos de VUESTRA máquina, no la vayais a liar….

Lo que hemos hecho ha sido asignar la contraseña password al usuario root utilizando el formato de contraseña salt/password, aunque para finalizar, aún debemos hacer mas cosas:

Después de ésto, empaquetamos el directorio.

Ahora, suponiendo que hemos montado la partición 2 de la tarjeta microSD (donde se supone que vamos a instalar el sistema) en el directorio /media/rootfs, podemos cargar ahí el sistema recién creado:

Instalamos los módulos del núcleo que compilamos en su momento, para eso, nos vamos al directorio mini2440 que creamos en su día y ejecutamos lo siguiente:

Desmontamos la tarjeta, la insertamos en nuestra MINI2440 y arrancamos (conectando el puerto serie de la tarjeta a nuestro PC y arrancando minicom).

Cuando el sistema termine de arrancar, veremos que se para porque no encuentra el archivo /etc/inittab:

Introducimos ‘s’ (single user) y cuando nos pida contraseña introducimos: “password“. De ésta forma tendremos una Shell con permisos de root muy básica, pero con la que podremos terminar de instalar el sistema.

A continuación remontamos el sistema de archivos como sistema de lectura/escritura:

y después montamos el sistema de archivos /proc:

Ahora debemos reinstalar todos los paquetes. Aunque los paquetes ya “están” en el disco, debemos “reinstalarlos” para que se genere la base de datos del sistema:

Una vez que tenemos instalado apt, reinstalamos todos los paquetes configurando la lista selections de dpkg:

Aquí es muy probable que se produzcan errores durante la reinstalación. cuando ésto suceda se vuelve a ejecutar apt-get dselect-upgrade hasta que se termine. Para algunos paquetes es posible incluso que tengas que tocar algo a mano, como por ejemplo para que el paquete base-files pueda instalarse correctamente, que en mi caso me fue necesario eliminar el directorio /var/mail a mano.

En éste punto ya casi hemos terminado. Ahora solo falta activar la consola a través de puerto serie:

¡Y ya está! Reinicia el sistema y ya tendrás una Debian flamante corriendo en tu MINI2440. ¡¡A disfrutarla!!

Y después…

Lo próximo es la creación de una imagen opie utilizando openembedded.

Referencias

• Página oficial de Emdebian
• Manual de instalación utilizando debootstrap
• Configuración de Multistrap
• Lista de correo de debian-embedded
• DebianWiki

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL.

Introducción

Actualmente me estoy preparando el que espero sea el último examen de la carrera (que bien suena, pensé que nunca llegaría a decirlo ), que oficialmente es mañana. El caso es que a éstas alturas del verano y tras haber pasado, pongamos (por poner), 24 meses en los que se puede decir que me ha pasado de todo, ahora estoy que no me entra nada en la cabeza ni soy capaz de estar mas de cinco minutos concentrado con nada, así que me he dicho “pues escribe a ver si así te concentras mas”, y aquí estoy.

Sobre lo que voy a escribir ahora es acerca de algunos conceptos sobre planificación en Sistemas Críticos, que es el tema que me ocupa ahora (y que, para qué engañarnos, el que mas me preocupa). Hay montones de ecuaciones que en principio son sencillas, pero numerosas, y además varios tipos de protocolos y de tipos de asignaciones de prioridad, así que lo mejor que puedo hacer es resumirlas y ya de paso tenerlas a mano, pues me parecen tan útiles como interesantes. Empecemos….

Asignación de prioridades

Bueno, para empezar diré que asumo que todos sabemos lo que es un Ejecutivo Cíclico y en qué consiste un Hiperciclo. También asumo que se tienen claros conceptos como Concurrencia, Período de Activación, Tiempo de Ejecución Máximo, Plazo de Respuesta y un largo etcétera.

Dicho todo lo anterior, prosigamos. Formas de asignar prioridades a las distintas tareas de un ejecutivo cíclico puede haber muchas: según el preriodo de activación de las tareas, el tiempo de cómputo, el número de recursos que se utilizan o la cantidad de procesos con los que se comparten ciertos recursos, por poner unos ejemplos.

Do de éstas formas de asignación son la Asignación de mayor prioridad a las tareas de menor período (Rate monotonic scheduling) y la Asignación de mayor prioridad a las tareas de menor plazo de respuesta (Deadline monotonic sheduling). Las características de éstos sistemas de asignación son las siguientes:

• Rate monotonic scheduling
• Asigna mayor prioridad a las tareas cuyo período de activación (T) es menor.
• Asignación óptima para el modelo de tareas simple: Tareas periódicas, independientes y con plazos iguales a los períodos.
• Si se pueden garantizar los plazos de un sistema de tareas con otra asignación de prioridades, se pueden garantizar con la asignación monónota en frecuencia.
• Deadline monotonic scheduling
• Asigna mayor prioridad a las tareas con menor plazo de ejecución.
• Es válido para modelos en los que existen tareas esporádicas.
• Si los plazos son menores o iguales que los períodos, la asignación de mayor prioridad a las tareas de menor plazo de respuesta es óptima.

Factor de utlización

En un sistema crítico una medida muy importante es el Factor de Utilización del procesador. Éste factor muestra la relación existente entre el tiempo de cómputo de una tarea dada y su periodo de activación, dando una idea del uso total del procesador. El factor de utilización (U) siempre tiene que ser menor o igual a 1.

La ecuación para el cálculo de U en un sistema es la siguiente: siendo N el número de tareas en ejecución, C es el tiempo de cómputo de una tarea dada y T es el periodo de activación.

En el modelo simple de ejecución con prioridades monótonas en frecuencia, los plazos se garantizan si siendo

la Utilización mínima garantizada del sistema para N tareas. Un sistema cumplirá con los plazos siempre que, como se ha comentado anteriormente, . Aunque ésta no es condición necesaria, si que es suficiente.

Mas cosas

Iré añadiendo mas cosillas poco a poco, ya después del examen…

Referencias

Básicamente mis apuntes de clase

Introducción

Snippets de código en C++ muy simples pero que suelo olvidar con frecuencia y me hacen perder tiempo buscando.

de int a string

Generar un fichero (de texto)

Referencias

• http://www.wlug.org.nz/ConvertingAnIntegerToaStringInCpp
• http://www.cpp-home.com/archives/67.htm

A continuación de dicha glorieta hay un bonito paso de peatones sin semáforo y al lado un Insituto, que a la hora de los hechos estaba, como es de suponer, rebosante de hormonas entrando en él….

Pues a esto que voy yo, como todos los días a TRABAJAR (es lo que tenemos las personas honradas, que como no estafamos, tenemos que trabajar nos guste o no) y me veo que dirigiendo el tráfico había un policía local. Ciertamente he de decir, que cuando lo ví no supe exactamente que estaba indicando, así que como había bastante tráfico (esa glorieta y la de la Estación de Autobuses dan verdadero miedo a ciertas horas de la mañana) pues me dije “Bueno, lo que haga el de delante, como vamos en primera….”. Y así fue, yo en primera, paso la glorieta, como el que venía delante de mi, que cruza el paso de peatones mientras la gente está esperando en la acera. Yo, incauto de mi, decido pasar también (no sé, puede que tuviera algo que ver el hecho de que no me dijeron alto ni el policía cambió de actitud…) y mientras estoy pasando, el buen hombre me da la señal de alto.

Frenazo que te crió (en la autoescuela parece ser que no enseñan que un policía puede decirte “alto” mientras ya estás cruzando). El caso es que paro, pero en la segunda mitad del paso de peatones, ya saliendo. Se me acerca el buen hombre y me dice con semblante serio:

Poli: -“¿Qué pasa con usted?”
Yo: -“Ehmmmmm, lo siento, ya estaba cruzando cuando dió la señal de STOP, no me ha dado tiempo a parar antes…”
Poli: -“Bueno, no se preocupe, continúe, pero tenga mas cuidado la próxima vez…”

Se vé que en la jerga de los hombres encargados de velar por el bien “No se preocupe” significa 4 puntos, Retirada temporal del permiso de conducción y 200 euros por las molestias.

Si señores si, eso fue lo que me llegó en una bonita notificación el día 28 de Diciembre de 2009 (y no, no era broma muy a mi pesar). ¿El motivo? “No obedecer las órdenes o señales de los agentes de la autoridad, sin peligro para otros”. Pues si. El buen hombre dice que no le obedecí (lo que da a entender que no paré y que me fui). Claro, como “no pasaba nada” y no me dió denuncia, yo ahora no puedo demostrar que esa denuncia es totalmente falsa. ¡¡Qué bien!!

El caso es que un amigo que conoce el funcionamiento de la policía local bastante bien (creo recordar que fue él quien me lo dijo, pero puede que me equivoque) me dijo: “Recurre, como ésta gente solo quiere tu dinero lo mas probable es que te perdonen la retirada. Te tienen que poner la denuncia completa para que no se note que van a lo que van….”.

Así lo hice, recurrí, y hoy al llegar al pueblo me encuentro una bonita notificación (siempre son buenas noticias, SIEMPRE) diciéndome que pague los 200 euros que me piden y me deje de gilipolleces (pero edulcorado con jerga judicial, que aquí te llaman Gilipollas con clase y estilo…). Eso si, ME HAN PERDONADO EL CARNET DE CONDUCIR. Ohhhh, no puedo mas que llorar ante tal muestra de compasión y benevolencia…

Pues nada, ésto es lo que me ha pasado. Tenía que contarlo, ya que siento una sensación de indefensión y de impotencia que muy pocas veces antes había sentido. Si señor, ahora siento seguridad cada vez que veo un coche de los locales por Ciudad Real, o cada vez que voy andando por el centro una mañana y me los encuentro paseando el tipito por la Plaza Mayor y aledaños a ver que se puede rascar…

He de decir, sin embargo, que de los 10 años que llevo viviendo en Ciudad Real, hasta hace algo menos de un año no sabía ni que teníamos policía local. Bueno, si que lo sabía, evidentemente, pero no porque los viese paseando o patrullando. Y es que la crisis está haciendo estragos, ya lo dicen en TeleMadrid…

Pues nada, un hurra por nuestra Alcaldesa, que ha encontrado la forma de solucionar los problemas económicos del ayuntamiento de tan insigne ciudad y otro hurra por el Agente 200-098, seguro que se llevó una palmadita en la espalda y todo…

Yo mientras tanto, como persona honrada que soy, seguiré durmiendo una media de cuatro horas al día para llegar a tiempo al trabajo y a mis estudios, que para que nos puedan robar con tanta impunidad, antes tenemos que tener algo…

Introducción

Algunos snipplets útiles para manejo de bases de datos SQLite desde Python.

Qué instalar

Lo primero, por supuesto, es instalar el wrapper:

Cargando la base de datos

La base de datos que hemos cargado se llama db1. db es una instancia de la clase sqlite.Connection, con la que podremos acceder a la base de datos.

Obteniendo un cursor y generando una consulta

Obtiene una instancia de Cursor, a través de la cual se pueden realizar consultas. En el ejemplo se realiza una consulta parametrizada y después se muestran todos los resultados obtenidos.

Introducción

El Teorema de Bayes ofrece un método matemático que nos permite contestar a preguntas relacionadas con la probabilidad condicional inversa en ciertas situaciones. Por ejemplo, si tenemos dos eventos y y se conocen y , podemos deducir con relativa facilidad . Ésto, que a simple vista puede parecer carente de significado, resume aspectos tan cotidianos de nuestra vida como nuestra forma de tomar ciertas decisiones.

Algunos conceptos

Antes de empezar de lleno a hablar de la Regla de Bayes no estarían mal un par de definiciones. A mi al menos me fueron de ayuda cuando empecé en ésto del cálculo probabilístico…
Básicamente lo que tenemos que saber es que cuando nos encontramos algo como , lo que estaremos viendo es simplemente ésto:

“La probabilidad de que habiendo sucedido , suceda .”

Es decir, la probabilidad condicional de dado .

La Regla de Bayes hace un planteamiento “inverso” de la probabilidad condicional. Básicamente supondremos que ha sucedido y en base a ello nos interesaremos por la probabilidad de que halla sido el desencadenante de . Es decir, ahora calcularemos .

Para aclarar todo ésto un poco, supongamos que la acción es estar resfriado y la acción es tener fiebre. Sabemos que existe una probabilidad dada (y de hecho relativamente alta) de tener fiebre si estamos resfriados (). Por tanto, si vamos a un médico a que nos diagnostique y ve que tenemos fiebre () determinará las probabilidades de que dicha fiebre halla sido causada por un resfriado ().

Regla de Bayes

Generalizando el ejemplo anterior, la Regla de Bayes nos ayudará en el caso de que tengamos un conjunto de causas excluyentes entre si, un efecto que ha sucedido, un conjunto de probabilidades y necesitemos saber la probabilidad de que hallan sucedido cada una de las posibles causas (vamos, lo que hace House metiéndose con el escote de Cuddy, pero matemáticamente).

Para determinar la probabilidad que han tenido cada una de las causas de suceder partimos de lo siguiente:

y del mismo modo sabemos que

con lo cual es fácil deducir que , de donde obtenemos la probabilidad de que halla sido causante de :

Pero además sabemos que es debida a alguna de las causas del conjunto que definimos anteriormente, es decir

Como éstas causas son excluyentes entre si, al aplicar las Reglas de la adición obtenemos

Si ahora sustituimos el denominador en la ecuación con la que calculamos anteriormente, obtendremos la Regla de Bayes generalizada:

A las probabilidades se las conoce como probabilidades sin corregir o probabilidades a “priori”.

Un ejemplo

Ahora veámoslo todo con un ejemplo. Supongamos que la probabilidad de encontrar una mujer morena en Sudámerica sea , la probabilidad de encontrar una mujer morena en Centroamérica es de y la probabilidad de encontrar una mujer morena en Norteamércia es de .

Si se realiza un concurso de belleza para elegir Miss América y el 30% de las participantes son sudaméricanas, el 20% centroaméricanas y el 50% norteaméricanas y nos presentan a una mujer morena ¿de qué parte de América viene?

Analizando los datos dados podemos obtener las siguientes probabilidades “a priori”:

Probabilidad de que la mujer sea una concursante centroaméricana: .
Probabilidad de que la mujer sea una concursante sudaméricana: .
Probabilidad de que la mujer sea una concursante norteaméricana:

La probabilidad de hallar una morena según la región es:

Probabilidad de encontrar una morena estando en Sudamérica: .
Probabilidad de encontrar una morena estando en Centroamérica: .
Probabilidad de encontrar una morena estando en Norteamérica: .

Nuestro objetivo es determinar la probabilidad de que la morena que acabamos de conocer sea de una u otra parte del continente, es decir, buscamos y sabiendo que el suceso sucedió:

Para el cálculo de dichos valores se ha utilizado la siguiente tabla:

	Sudamericana	Centroamericana	Norteamericana	P(Morena)
Mujer Morena	0.21	0.18	0.20	0.59
Mujer no morena	0.09	0.02	0.30	0.41
P(origen)	0.30	0.20	0.50	1

En la tabla, las probabilidades marginales informan de la probabilidad del color de piel independientemente de la región geográfica y viceversa.

Referencias

La práctica totalidad de ésta entrada se ha obtenido de unos apuntes online de la Facultad de Ciencias Económicas – Sede Trelew de la Universidad Nacional de la Patagonia.

Éste documento no pretende ser una guía para la utilización de la Regla de Bayes, sino que se trata de un resumen a título personal para asentar mejor los conocimientos adquiridos.

Introducción

Hace poco, en el trabajo, me encontraba realizando la implementación del protocolo descrito en la RFC 908 para usarla en un pequeño microcontrolador de Atmel.

Una vez implementado y compilado todo, me dispuse a realizar las correspondientes pruebas y vi que en ciertas funciones sucedían cosas muy extrañas. En concreto, tenía definidas varias estructuras en las que se almacenaba toda la información de estado y control del protocolo y descubrí que al intentar recorrer todos sus miembros con un puntero a char las cosas no cuadraban. Leía valores que se suponía que no estaban ahí o al calcular el tamaño de los mensajes basándome en el tamaño de las estructuras (calculadas usando sizeof) estos no eran los que tenían que ser….

¿Qué estaba sucediendo?

El problema: Padding

Pues si. Enseguida imaginé cual podría ser el problema: el Padding. La verdad es que es un error un poco de novatos, pero yo caí. Generalmente los programadores en lenguajes como C raramente suelen tener en cuenta el tema del padding a diseñar sus programas, puesto que suponen que el compilador se encargará de optimizar nuestro código y además, rara vez se trabaja a un nivel tan bajo como para que ésto sea un problema.

La cosa cambia si estás diseñando código para correr en un dispositivo empotrado con poca memoria o tienes que hacer manipulaciones a muy bajo nivel sobre las estructuras. En mi caso, se daban las dos situaciones, así que me puse a investigar un poco y ésto fue lo que aprendí.

¿Qué es exactamente el padding? Bueno, empecemos por el principio:

El Alineamiento

¿Y ésto qué es?. Bueno, dependiendo del tipo de máquina que estemos utilizando y del tipo de dato con el que estemos trabajando, el rango de direcciones en las que se puede almacenar dicho dato debe cumplir una u otra característica. Me explico: supongamos que estamos trabajando en una máquina de 32 bits. En éste caso, tendremos una máquina con una alineación de memoria de 4 bytes. Es decir, cualquier lectura de memoria se hace de cuatro en cuatro bytes y todas las posibles direcciones de memoria que se leen serán múltiplo de 4. Por tanto, una lectura, supongamos en la dirección 0x00abcd0034 sería correcta, mientras que si intentásemos leer de la dirección 0x00abcd0031 no podríamos, pues esa dirección no está alineada a 4 bytes (no es múltiplo de 4). Si queremos leer ese byte en concreto, deberemos leer la dirección 0x00abcd0030 y después acceder a los bits <8:15>
Hay que hacer una pequeña aclaración y comentar que ésto es para el caso de que nuestra máquina sea de 32 bits pero use una memoria de 8 bits. También podemos tener máquinas con un bus de memoria de igual longitud que los datos que utiliza, en cuyo caso, el alineamiento de las posiciones de memoria sería 1, es decir, se puede leer y escribir en cualquier dirección, pero se leerán 32 bits (o los que tenga el ancho del bus) de cada vez. Para lo que voy a explicar, me parece mas conveniente el modelo de máquina de 32 bits con un bus de 8, aunque esto es aplicable a cualquier tipo de arquitectura.

Si en la máquina de la que estamos hablando queremos guardar un char, dicha variable la podremos guardar, como podemos imaginar, en cualquier dirección (un char, como todos sabemos, ocupa 8 bits). Decimos que el alineamiento de éste tipo de variables es de un byte. Ésto sucede porque, en nuestra máquina de 32 bits, para leer un char, leeremos 32 bits (4 bytes) de una vez, y entre esos 4 bytes, estará el que buscamos.
La cosa cambia si ahora en lugar de querer almacenar un simple char queremos guardar un short (típicamente 16 bits). En éste caso solo podremos almacenarlo en direcciones múltiplo de 2. ¿Y ésto a cuento de qué?. Pues como algunos habréis imaginado (y si no lo habéis imaginado yo os lo cuento), si en cada lectura que realiza nuestro procesador leemos 4 bytes y un short son 2 bytes, tendremos que colocar dicha variable bien en los dos primeros bytes o bien en los dos últimos. Por supuesto también podríamos colocarlo en los bytes 2 y 3, pero si permitimos ese tipo de cosas nada impediría que el primer byte de un short cayese en el último byte de una palabra leída y el segundo en el primer byte de la palabra siguiente. Mas claramente: nuestra máquina lee las direcciones 0×0000, 0×0004, 0×0008, etc…. Nuestro short correría el riesgo de caer entre las direcciones 0×0003 y 0×0004. ¿Cual es la pega de ésto? Obviamente que el procesador debería realizar dos lecturas a memoria: una a la dirección 0×0000 y otra a la dirección 0×0004 para recuperar los dos “trozos” de short. Ahora se ve claro por qué hace falta definir ésto del alineamiento de los tipos de datos: Ahorra trabajo y tiempo al procesador.
Decimos entonces que un short está alineado a dos bytes.

Como podremos imaginar, para el caso de un int o incluso de un double, la alineación tiene que ser forzosamente a 4 bytes, es decir, deben de estar almacenados en direcciones múltiplos de 4.

Ahora si, el Padding

Muy bien, ahora que ya hemos entendido en qué consiste la alineación, podemos hablar del Padding, que no es ni mas ni menos que bytes de “relleno” que se utilizan para forzar el alineamiento de los miembros de una estructura, en el caso del lenguaje C. Veamoslo con un ejemplo:
En el siguiente código podemos ver que tenemos definida una estructura formada por un char y un int:

Antes de compilar ni ejecutar nada podemos suponer que el tamaño de nuestra estructura (en una máquina de 32 bits) debería ser de 5 bytes: 4 bytes del int y 1 del char. El código simplemente imprime la longitud de la estructura, los datos originalmente almacenados en ella y después, a través de un puntero char recorre dicha estructura y modifica los datos. Finalmente, vuelve a imprimir los datos guardados en la estructura.
Ahora ya podemos compilarlo y ejecutarlo obteniendo la siguiente salida:

¿qué ha pasado? ¿y esa longitud 8 en lugar de 5? Sencillo: nuestra máquina es de 32 bits. Para poder forzar el alineamiento correcto de las variables que componen la estructura tiene “rellenar” el hueco ocupado entre el char y el int para que éste último comience en una dirección múltiplo de 4 (o en el caso de un PC de 32 bits, se lea en la siguiente dirección de memoria, porque en éste caso, el bus de la memoria coincide con el del micro). Es decir, es como si hubiésemos declaro padding de ésta otra forma:

de modo que dummy? son solo para rellenar (padding) y hacer que b empiece donde debe, respetando así el alineamiento. Si no fuese así y quisiéramos acceder a a, seguiríamos usando una lectura, mientras que para acceder a b la cosa cambiaría, ya que necesitaríamos una lectura para acceder a los tres primeros bytes y una segunda lectura mas para acceder al último. Después habría que realizar desplazamientos y ajustes para obtener el valor final.
De ahí que veamos otro efecto colateral a la salida de la ejecución del código: El último valor leído de b no coincide con el esperado. De hecho solo hemos modificado el primer byte. Los otros tres bytes que hemos recorrido han sido los del padding.

Ésto abre la veda para hacer pequeños “experimentos”. Por ejemplo, si cambiamos a y b de posiciones relativas veremos que el tamaño sigue siendo 8. ¿De verdad sigue haciendo falta relleno? Ahora se supone que leemos primero el int y que por tanto b lo podremos leer sin problemas…. Pues la respuesta es si y no. En realidad ahora no hay padding, pero si que es cierto que la estructura sigue ocupando 8 bytes en memoria, pues tendremos que hacer dos lecturas para acceder a todos sus miembros.

Pero podemos hacer mas cosillas: Por ejemplo, podemos declarar otro miembro de tipo short entre a y b y ver qué pasa con el tamaño. ¿Ha cambiado? ¡¡NO!! ¿y eso?. Pues porque al encontrarse el short entre un char y un int, puede utilizar tres de los bytes de padding para almacenarse, por lo que ahora habrá un padding de un solo byte. Si en lugar de eso declaramos el short después de b, veremos que la cosa cambia bastante. Ahora estaremos usando 12 bytes. Queda bastante claro todo ésto ¿no?.

Evitando el padding con GCC

Una pregunta bastante obvia que puede asaltar a cualquier lector es: ¿y si no quiero que haya padding porque me hace desperdiciar memoria o me viene fatal para recorrer mi estructura?. Bueno, GCC permite forzar el padding que nosotros queramos usando pragmas. En concreto se usa el pragma pack. Veámoslo con un ejemplo sobre nuestro código anterior:

El primer pragma establece que se fuerce un padding de 1 byte y lo “apila” en una pila que usa el compilador. De ésta forma podemos ir forzando varios paddings y cuando se use pragma pack(pop) sacaremos el último padding que hayamos usado y volveremos al anterior. En nuestro caso, volveremos al padding por defecto de nuestra máquia, puesto que solo hemos hecho un push.

Si ahora ejecutamos el código veremos que si que sucede lo esperado: padding ocupa 5 bytes y recorriendo la estructura con un puntero a char conseguimos modificar todos los datos como esperábamos.

Yo personalmente opto por no “forzar” las cosas. Un consejo para definir estructuras es ir declarando sus componentes por orden de menor a mayor tamaño. De ésta forma, quedarán organizados de una forma bastante óptima. También habrá que cuidar los recorridos por los miembros de la estructura, utilizando funciones específicas para ello.

Claro que también puede haber situaciones en las que no quede mas remedio. Por ejemplo, otra cosa en la que actualmente ando liado es la implementanción de un pequeño driver para un sistema de archivos FAT32 que deberá correr en microcontroladores AVR con muy pocas capacidades. Para poder interpretar las tablas de asignación de archivos he de leer bloques del medio en el que tengo almacenados los datos y después interpretar esa información acorde a la estructura que define a dicha tabla. El problema me viene, al igual que comenté al comienzo de ésta entrada, en que si bien en el caso del microcontrolador (con un bus de 8 bits) los datos leídos casan perfectamente con las estructuras necesarias, para el caso de los tests en el PC esto no es así, ya que las estructuras utilizan muchos tipos de 8 y 16 bits y el padding generado para forzar el alineamiento hace que los datos leídos no concuerden con los campos a los que tienen que ir a parar. En éste caso, tengo dos opciones: o una vez leído el bloque (y guardado temporalmente en un array de char) voy rellenando todas las estructuras campo a campo (algo muy muy lento para un microcontrolador y que necesita gran cantidad de código) o bien fuerzo el alineamiento a un byte para evitarme el padding y genero un puntero a la estructura que me interesa guardando en él la dirección de comienzo de mi array a char. De ésta manera podré recorrer mas fácilmente la estructura, sabiendo que para el micro no supondrá coste alguno y que para el PC generaré algo de código extra (al tener que forzar el alineamiento), pero realmente como mi intención es usar el PC sólo para validar los algorítmos, no importa que sea algo ineficiente si con ello consigo el efecto deseado.

Bajo mi punto de vista (y por lo que acabamos de ver también), creo que forzar paddings puede suponer que en algunas arquitecturas el procesador tenga que realizar mas trabajo. En un PC puede que sea (o no) despreciable, pero desde luego en un sistema empotrado ello supone pérdida de tiempo, consumo de energía y consumo de memoria de código (necesitaremos mas código para codificar las operaciones, como es lógico suponer). Ya es decisión de cada uno optar por una u otra forma de implementar.

Referencias

Pues como siempre, navegando por Internet uno encuentra muchas cosas. En http://bytes.com/topic/c/answers/543879-what-structure-padding encontré una explicación bastante clara de todo ésto del alineamiento y del padding. ]]> http://elvioladordesegmentos.net/index.php/2010/03/31/gcc-y-el-padding/feed/ 0 http://elvioladordesegmentos.net/index.php/2010/02/22/actualizando-googlemaps-en-android-con-cyanogenmod-2-4-5/ http://elvioladordesegmentos.net/index.php/2010/02/22/actualizando-googlemaps-en-android-con-cyanogenmod-2-4-5/#comments Mon, 22 Feb 2010 14:00:50 +0000 javieralso http://jalsoez.dyndns.org/blog/?p=132

Actualización

A todos los que tengais instalado en vuestro HTC Magic la versión CyanogenMod-2.4.5 os habrá pasado que no podeis actualizar la aplicación GoogleMaps debido a no sé que problema (exactamente creo que lo que sucede es que se encuentra instalado en una partición motada como de solo lectura). Buscando por ahí encontré como poder actualizar: El proceso pasa por desinstalar la versión vieja un poco “a lo bestia” e instalar encima otra nueva.

Utilizando adb los comandos a introducir son los siguientes:

Una vez desinstalada la aplicación, buscamos un apk de GoogleMaps y los instalamos, bien copiándolo a la tarjeta SD y ejecutando ahí o bien usando el propio adb.

Referencias

• GoogleMaps navigation para todos

Introducción

Después de haber compilado e instalado uBoot en nuestra tarjeta de desarrollo mini2440 y de haberle compilado una imágen Linux ahora nos proponemos configurar uBoot para el arranque de dicho kernel.
uBoot permite mucha flexibilidad a la hora de instalar y arrancar imágenes desde la memoria. Aún así, aquí sólo explicaré el procedimiento que he utilizado yo para poder cargar y ejecutar Linux desde una tarjeta SD, ya que además de parecerme los mas fácil y cómodo a la hora de actualizar (tan solo hay que copiar la nueva imagen a la SD), mantendremos intacta la NAND interna de nuestra tarjeta, que sabemos que tiene vida limitada, y aunque muy larga, no deja de ser eso, limitada.

Qué necesitamos

Pues como dije antes, se supone que debemos de haber leído, comprendido y ejecutado las dos recetas que se mencionan mas arriba.
De la segunda receta obtenemos la imagen del núcleo que vamos a utilizar en nuestra tarjeta, uImage.
A continuación, hay que preparar la tarjeta de memoria. Yo en mi caso tengo una partición ext3 de unos 128MB que utilizo para tal fin. Lo del tamaño no importa mucho (ejem), pero nunca por mucho trigo fue mal año (ejem, ejem), así que si nos sobra espacio, podremos utilizarlo para guardar ahí backups y cosas de esas (es lo que yo hago).
También es aconsejable que dicha partición se la primera particion de la unidad (primaria, claro está), ésto no es muy crítico, pero mi configuración tiene ésto en cuenta, con lo cual si situas la partición en otro sitio, deberás especificarlo en la configuración.
Evidentemente no me voy a poner a explicar cómo hacer dicha partición, ya somos todos muy grandecitos para hacerlo solitos, así que cuando termines, te espero mas abajo…

Configurando uBoot

Una vez que tienes la partición hecha, copias la imagen uImage que compilaste en su día a dicha partición e insertas la tarjeta en el lector de tu mini2440. Conectas el puerto serie, abres minicom con la configuración que usaste para instalar uBoot y arrancas. Cuando salga el mensaje de que pulses una tecla para cancelar el arranque procedes:

Lo primero que vamos a hacer, para asegurarnos de que todo va sobre ruedas, es hacer el arranque “a mano”, de modo que sepamos exactamente qué parámetros tenemos que dar a uBoot para que cargue correctamente nuestro núcleo. Una vez que ya sepamos estos parámetros, configuraremos uBoot correctamente para que se haga todo de forma automática cada vez que encendamos nuestra tarjeta. Algunos de los comandos que se mostrarán ahora ya nos sonarán de la receta en la que instalamos uBoot, aún así los volveré a explicar ahora.
Lo primero es inicializar la tarjeta SD:

Una vez que la tarjeta ha sido detectada e inicializada correctamente, se carga la imagen:

Lo que hemos hecho ha sido decirle a uBoot que cargue el archivo uImage que se encuentra en la partición 1 de la tarjeta 0 (0:1) cuyo tipo es extX (ext2load) a partir de la dirección de memoria 0×32000000. Recordemos que en ésta imagen ya definimos el entrypoint, entre otras cosas, por lo que no necesitaremos definirlo mas.
Ahora ya solo queda arrancar:

Como podemos observar, el núcleo ha arrancado correctamente aunque veamos un nunca bienvenido kernel panic. Éste es debido a que no tenemos sistema alguno instalado, con lo cual, cuando el kernel termina de cargar e inicializar el sistema no es capaz de lanzar el proceso Init, con lo que se detiene.
De momento no lo necesitamos, éso será el contenido de una próxima receta. Con que arranque el núcleo nos daremos por satisfechos .
Puesto que ya hemos visto que nuestra configuración funciona, la guardamos:

El comando setenv sirve para asignar valores a las variables de entorno de uBoot. En éste caso configuramos la variable bootcmd que es la que contiene los comandos que se ejecutarán en el arranque. Dichas instrucciones son las que probamos anteriormente para la carga del núcleo.
saveenv como su nombre indica, sirve para hacer persistente el contenido de las variables de entorno, de forma que esten ahí cada vez que arranquemos la tarjeta.
Con ésto ya debería ser suficiente para que tu núcleo arranque correctamente, pero ya que estamos metidos con uBoot vamos a hacer algo mas: Vamos a configurarlo para decirle en qué partición de la tarjeta tenemos instalado el sistema, así como con qué parámetros debe de arrancar el núcleo, ya que con los que arranca por defecto probablemente no tengamos acceso a un terminal desde el puerto serie (cosa que a veces puede ser muy útil).
Para esto deberemos tocar otra variable de entorno, en éste caso bootargs que contiene los parámetros que son pasados al kernel:

Lo que hemos hecho ha sido decirle que tenemos el sistema instalado en la partición 2 de la tarjeta SD (boot=/dev/mmcblk0p2), la ruta de init, y desde donde se puede acceder a la consola y a qué velocidad.
La partición que se ha indicado como partición del sistema deberá ser forzosamente ext3, así que recomiendo que el espacio que te sobró en tu SD lo dediques a una partición para el sistema (cuando haga la preceptiva receta ).
Ahora podemos ver el contenido de nuestras variables de entorno:

Ahí podremos ver el contenido de todas las variables de entorno de uBoot. Aparte de las explicadas hay algunas interesantes como por ejemplo ifconfig que sirve para configurar si queremos que ejecute un cliente dhcp al arranque o si queremos darle una ip estática, bootdelay , que sirve para configurar el retardo en el arranque o baudrate, que como podemos imaginar, sirve para configurar la velocidad del puerto serie.
Si reiniciamos ahora nuestra mini2440, podremos ver que arranca el núcleo perfectamente, aunque sin sistema poco podemos hacer… Paciencia….

Referencias

• Entrada en el wiki del mini2440 en googlecode
• Otro wiki sobre la compilación e instalación del núcleo
• Manual de uBoot

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL. ]]> http://elvioladordesegmentos.net/index.php/2009/12/31/arm-mini2440-configurando-uboot-para-arranque-desde-sd-para-friendlyarm/feed/ 0 http://elvioladordesegmentos.net/index.php/2009/12/31/arm-mini2440-compilando-linux/ http://elvioladordesegmentos.net/index.php/2009/12/31/arm-mini2440-compilando-linux/#comments Thu, 31 Dec 2009 13:34:50 +0000 javieralso http://jalsoez.dyndns.org/blog/?p=124 cómo compilar e instalar u-boot en una tarjeta mini2440. Ahora voy a explicar cómo compilar un núcleo Linux para ésta misma plataforma. En una próxima receta tengo intención de explicar los pasos para configurar u-boot y hacer arrancable éste núcleo en nuestra amada tarjeta. De momento, vamos lo que interesa: El núcleo.]]>

Introducción

En una entrada anterior escribí sobre cómo compilar e instalar u-boot en una tarjeta mini2440. Ahora voy a explicar cómo compilar un núcleo Linux para ésta misma plataforma. En una próxima receta tengo intención de explicar los pasos para configurar u-boot y hacer arrancable éste núcleo en nuestra amada tarjeta. De momento, vamos lo que interesa: El núcleo.

Descargando los fuentes

Los fuentes del núcleo ya parcheados para su uso en nuestra arquitectura los descargamos de su repositorio git:

Con ésto ya tendremos creada la jerarquía de directorios necesaria y los fuentes descargados.
Para la compilación, usaré la misma toolchain que utilicé en la receta sobre u-boot, así que después de leerla y configurar la toolchain contiuaremos.

Lo primero que necesitaremos es crear el archivo de configuración (.config) con las opciones del núcleo. Suponiendo que estamos en el directorio mini2440 creado anteriormente, ejecutamos

Ésto generará la configuración a partir de una template existente en los propios fuentes y prácticamente no tendremos que tocar nada mas.

Configuración del display

En el código descargado existe un bug que hace que la imagen mostrada en el display aparezca desplazada 13 pixeles hacia la derecha. Preguntándo a Google encontré cómo arreglarlo. La solución pasa por editar en uno de los fuentes los parámetros de configuración del display. Sé que hubiese resultado mas cómodo generar el parche y ponerlo aquí sin mas para que se aplique, pero así explico con un poco mas de detalle que es lo que hay que hacer, no sea que alguien utilice otro tipo de display y tenga que editar de forma distinta los fuentes.

El archivo a editar es mini2440/arch/arm/mach-s3c2440/mach-mini2440.c. Aquí, entre otras cosas, se inicializan muchas de las estructuras utilizadas por el núcleo con parámetros específicos de nuestra arquitectura. En nuestro caso habrá que modificar los parámetros del display TFT de 3’5″ con touchscreen, que es el que tengo yo. En otro caso y dependiendo del display que tengas tu, puede que tengas que modificar o no dicho archivo con distintos parámetros.

Buscamos el siguiente código (a partir de la línea 227):

Cómo podemos observar, este fragmento corresponde al display de 3’5″ con touchscreen del mini2440 (seleccionado por defecto en la configuración que creamos anteriormente). Dentro de los parámetros x timing, cambiamos el valor 38 por 25, restando así el offset de 13 pixels que hay en el eje X del display.
El código entonces deberá quedar tal que así:

Repito, ésto está probado para mi display, si tu display es distinto, deberás buscar la sección correspondiente en el archivo y “ajustarlo” según tus necesidades.

Una vez editado, proseguimos con la compilación.

Compilando

Después de generada la configuración y arreglado el pequeño bug del que hablé antes, ya podemos compilar:

Y a esperar (no mucho, un café mientras ves el youtube ).

Suponiendo que ya has terminado de compilar y todo ha ido a las mil maravillas, ahora toca crear la imagen que u-boot cargará y arrancará. Para ello utilizamos la herramienta mkimage que podemos encontrar en el directorio tools de la distribución u-boot que compilamos en su momento.

el comando a introducir será el siguiente:

Deberemos usar el path completo a mkimage si no lo tenemos en nuestro path.

Éste comando crea una imagen para arm (-A arm), sistema operativo linux y tipo de imagen un núcleo. Además, no se usará compresión (-O linux -T kernel -C none). La imagen creada será cargada por u-boot a partir de la dirección 0×30008000 y el punto de entrada (dirección a partir de la cual arranca la imagen) será la misma dirección (-a 0×30008000 -e 0×30008000).
La imagen se llamará uImage y quedará almacenada en el directorio actual.

Lo próximo…

En una próxima receta explicaré la configuración de u-boot poniendo como ejemplo la instalación de nuestra imagen para que sea cargada desde una tarjeta microSD (o desde donde queramos).
Después explicaré como compilar desde cero una imagen de opie utilizando la toolchain de openembedded e instalarla, junto con las librerías generadas durante la compilación de éste núcleo.
Finalmente hablaré sobre como compilar una aplicación para opie utilizando bitbake, el script de compilación automatizado de openembedded.

Referencias

Como siempre muchísimas, pero la principal, de la que lo he seguido todo, ha sido el siguiente enlace:

• http://wiki.linuxmce.org/index.php/Mini2440
• Hilo sobre el bug del display en el foro del mini2440

Un saludo

NOTA: Entrada extraída de otra antigua entrada publicada por mi en CrySoL. ]]> http://elvioladordesegmentos.net/index.php/2009/12/31/arm-mini2440-compilando-linux/feed/ 0