Como todos los años cuando se acercan las fechas navideñas siempre trato de revisitar el concepto de luces del Belén aprovechando los conocimientos adquiridos en el último año. En este caso, entendiendo que el concepto de luces a secas ya hay que superarlo :-), se ha introducido una componente móvil en el Belén de este año: un cielo artificial con ciclo día-noche.

La rueda del cielo

Para simular un cielo que cambia entre día y noche se ha optado por una solución muy sencilla basada en un disco de cartón de medio metro de diámetro, aproximadamente, a cuyo eje se conecta directamente un motor paso a paso con una reductora. El motor girará lentamente a razón de una vuelta cada día.

Colocando el motor encima del mueble sobre el que se va a colocar el belén, con el eje apuntando a la pared, se puede colocar el disco de cartón de tal manera que sólo sea visible la mitad superior del mismo. De esta manera se puede pintar medio disco de cartón como si fuese de día (azul celeste, por ejemplo) y la otra mitad del disco de negro con el firmamento y la estrella de Belén, por ejemplo.



Electrónica de control de la rueda del cielo

El motor elegido para acoplar la rueda del cielo es el conocido y asequible 28BYJ-48 (que venden en AliExpress junto con la placa controladora a unos 2 ¤ en el momento de escribir estas líneas). Se trata de un motor paso a paso de 4 bobinas (4 pasos enteros u 8 medios pasos) y con una reductora interna que nos da una resolución teórica de 4096 medios pasos por vuelta (por cuestiones mecánicas, en realidad son medios 4076 pasos por vuelta, según comenta Luis Llamas en su blog).

La placa controladora tiene cuatro entradas digitales correspondientes cada una a una de las 4 bobinas del motor. Activando alternativamente las entradas 1, 2, 3, 4, 1, 2, 3, 4... hacemos girar el motor en un sentido, mientras que activando alternativamente las entradas 4, 3, 2, 1, 4, 3, 2, 1... hacemos girar el motor en el sentido opuesto. A aquellas personas que no estén familiarizadas con los motores paso a paso o con este motor paso a paso en particular les recomiendo esta entrada del blog de Luis Llamas, donde está magníficamente explicado.

La idea es hacer un circuito que haga que el motor paso a paso se mueva lentamente de manera que de una vuelta entera cada 24 horas (para simular el ciclo día-noche en el disco de cartón). Al diseño hay que añadirle botones de avance y retroceso rápido para que el disco pueda "calibrarse" o "sincronizarse" manualmente de forma sencilla (hay que recordar que no es necesaria una precisión milimétrica, es para un Belén). A continuación un diagrama del circuito a implementar en el CPLD:



El circuito consta de tres registros:

- Uno que actúa como latch de salida.

- Otro que actúa de registro de rotación.

- Otro que actúa como contador.

El multiplexor que controla el valor del latch de salida (MUXo) permite elegir entre la salida del registro de rotación o todo ceros, el multiplexor que controla el valor del registro de rotación (MUXs)permite elegir entre mantener el valor (realimentación directa), cargar un valor "0001" (para cuando se inicializa el circuito) o cargar una versión rotada de la salida actual del registro de rotación (en un sentido u otro dependiento de otro multiplexor, MUXd). El multiplexor que controla el registro contador (MUXc) permite elegir entre cargar el valor de reset del contador (T) o cargar el valor decrementado. La constante con la que se decrementa el registro contador debe variar en función de la velocidad a la que queramos que se mueva el disco y está controlada por otro multiplexor (MUXic).

El resto de bloques que aparecen en el esquema son circuitos combinacionales:

- El bloque "<=0" genera un 1 si el valor del contador (con signo) es menor o igual a cero.

- El bloque "DIC" (Dentro Intervalo Cuenta) genera un 1 a su salida si el valor del registro contador está dentro de un intervalo de valores. Esto se utiliza para evitar que las bobinas del motor paso a paso consuman mucho ya que para girar el rotor un paso basta con generar un pulso lo suficientemente ancho en la bobina correspondiente y luego dejar el motor en reposo (la reductora hace que el motor rotor esté prácticamente frenado en ausencia de pulsos).

- El bloque ">=1" es una puerta OR. Cuando se está haciendo avance o retroceso rápido, el multiplexor de salida hace de buffer del registro de rotación, pero cuando no estamos girando rápido, hay que activar las bobinas el motor sólo el tiempo necesario para evitar que el circuito consuma mucha corriente. De esta forma aunque el registro de rotación tenga el valor "0100" el registro de salida sólo tendrá el valor "0100" el tiempo necesario para excitar la bobina correspondiente y, a continuación, emitirá un "0000" aunque en el registro de rotación siga estando el valor "0100".

- El bloque "+" es un bloque sumador estándar. El encargado de ir decrementando el registro contador.

Funcionamiento

Los otros dos bloques combinacionales (abajo a izquierda y derecha) son los encargados de controlar todo el conjunto. Veamos primero el bloque combinacional de abajo a la izquierda:

Entradas			Salidas
DIC	/RESET	<=0	MUXs	MUXc	MUXo
X	0	X	1	1	0
0	1	0	0	0	0
1	1	0	0	0	1
X	1	1	2	1	0

Cuando la entrada /RESET se pone a 0, MUXs selecciona la entrada "0001", MUXc selecciona la entrada del valor de reset del contador (T) y MUXo selecciona la entrada "0000", por lo que en el siguiente ciclo de reloj el registro de salida se pondrá a cero, el registro contador se cargará con el valor T y el registro de rotación se cargará con el valor "0001".

Una vez que /RESET se pone a 1, como el registro contador vale T (se trata de un contador decremental), tanto las entradas C como DIC están a cero por lo que MUXs selecciona la entrada de realimentación (para mantener el valor actual del registro de rotación), MUXc selecciona la entrada procedente del sumador y MUXo sigue seleccionando la entrada con el valor "0000" (la salida del latch que va al motor sigue siendo "0000") por ahora.

Hay que tener en cuenta que, como el MUXc está selecionando la entrada procedente del sumador, cada ciclo de reloj que pasa, el valor del contador se decrementa. En algún momento el valor del contador entrará dentro del intervalo configurado para el bloque combinacional DIC y este bloque empezará a emitir un 1. Esto provoca que el MUXo seleccione la entrada procedente del registro de rotación por lo que se emitirá el valor almacenado en dicho registro hacia el motor durante el tiempo que el valor del contador genere un 1 a la salida del bloque DIC. Cuando el contador baje por debajo del umbral inferior del bloque comparador DIC, la salida de este bloque será de nuevo 0 y la salida del registro de salida volverá a ser "0000" de nuevo. El tiempo que el bloque comparador DIC emite un 1 debe ser suficiente como para que se exciten adecuadamente las bobina del motor (en mi caso lo he puesto para que las active durante un segundo, más que suficiente).

Una vez que el registro de salida ha vuelto a "0000" el registro contador continúa su camino hacia el cero. Cuando llega a cero (o lo sobrepasa hacia el negativo), el bloque "<=0" emite un 1. Esta condición hace que el MUXs seleccione la entrada de rotación (para que se active la siguiente bobina del motor y el rotor gire un poquito), que el MUXc seleccione la entrada del valor iniciar T (para que se cargue el contador con el valor inicial) y que el MUXo seleccione la entrada "0000" (para seguir emitiendo ceros).

Esto provoca que todo el ciclo empiece de nuevo por lo que tendremos que, calculando bien el valor de T y los valores umbral del bloque comparador DIC conseguiremos un disco dia-noche que de una vuelta entera una vez cada 24 horas.

Si el motor paso a paso da una vuelta completa cada 4076 medios pasos y nosotros vamos a utilizarlo con pasos enteros, cará una vuelta cada ${4076 \over 2} = 2038$ pasos enteros. Por tanto si queremos que de una vuelta entera cada día tendrán que pasar:

$${{24 \times 60 \times 60} \over 2038} = 42.3945 \ \ segundos/paso$$

Como el reloj va a 50 MHz el valor de T será de:

$${{24 \times 60 \times 60} \over 2038} \times 50000000 \approx 2119725221 \ \ ciclos/paso$$

Con este valor de T podemos hacer que el bloque DIC emita un 1 cuando:

$$2119725000 > contador > 2069725220$$

50000000 de ciclos de diferencia (1 segundo). Y un 0 en el resto de los casos.

El bloque combinacional de abajo a la derecha es el encargado de controlar el avance y retroceso rápidos.

Entradas		Salidas
Avance rápido	Retroceso rápido	MUXd	Rápido
0	0	0	0
0	1	1	1
1	X	0	1

En función de los valores de las entradas de avance rápido y retroceso rápido, el multiplexor MUXd seleccionará un sentido de rotación u otro. Además, en caso de que se pulse cualquiera de los dos botones, el registro latch de salida selecciona siempre la entrada proveniente del registro de rotación: cuando estamos haciendo avance y retroceso rápido los pulsos de activación serán tan cortos que no será necesario usar el mecanismo del bloque DIC para controlar la anchura de los pulsos de activación de las bobinas.



Luces para el cielo nocturno

Para rizar el rizo y aprovechando que tenía por aquí un CPLD chico de 64 macroceldas (el EPM3064A de Altera, unos 6 ¤ por aliexpress) me aventuré a colocar unas luces en la parte "nocturna" del disco giratorio. Una pila de botón de tipo CR2032 es más que suficiente para alimentar el CPLD y los 5 leds que se usan para simular las estrellas.



En este caso se ha realizado una implementación simplificada del diseño publicado en este post. En lugar de incluir un comparador y un latch se ha optado por emitir directamente hacia los leds, cinco de los bits del registro LFSR de 10 bits.



Si el reloj del CPLD va a 50 MHz (como en nuestro caso) y queremos que las luces cambien cada segundo, T debe valer 50000000. La descripción del resto de bloques combinacionales es la siguiente:

- El bloque "P" es el bloque que aplica el polinomio de realimentación maximal para 10 bits al valor actual del registro LFSR (una puerta XOR más un desplazamiento). Al ser un polinomio maximal de 10 bits el registro LFSR generará una secuencia de números pseudoaleatoria comprendida entre los valores 1 y 1023 (el valor 0 está fuera de la secuencia y en caso de que se alcance dicho valor, el LFSR se "para").

- El bloque "X" es un bloque que, en caso de que la entrada valga "0000000000" en la salida emite "0000000001", en caso contrario emite la entrada sin cambiar. Este bloque se coloca para garantizar que si el LFSR se pone totalmente a 0 (por ruido, reinicio, encendido, etc.) vaya a un valor que sí esté dentro de la secuencia pseudoaleatoria de números y pueda así seguir generando números dentro de dicha secuencia.

- El bloque "=0" es un bloque que emite un 1 si el valor del registro contador es 0 y un 0 en caso contrario.

Como se puede observar el comportamiento del generador de destellos para el firmamento nocturno es muy sencillo:

Si asumimos que el momento del arranque los registros están todos a cero, la salida del bloque "=0" será 1 por lo que se seleccionará la entrada T del multiplexor del contador y la entrada P del multiplexor del LFSR. Aunque el registro LFSR está a 0, la salida del bloque X será "0000000001" por lo que la salida de P será el siguiente valor de la secuencia maximal de P después del valor "0000000001". En el momento que llega el siguiente flanco de subida del reloj se carga el registro LFSR con el nuevo valor de la secuencia pseudoaleatoria y se carga el registro contador con el valor T (50000000).

A partir de ahora, como el registro contador contiene un valor diferente de 0, la salida del bloque "=0" será un 0 por lo que el multiplexor del registro LFSR mantendrá el valor actual del registro LFSR y el multiplexor del contador seleccionará la entrada que proviene del sumador. Esta condición se mantendrá durante el tiempo que el contador sea mayor que cero (para T = 50000000 a 50 MHz, tenemos un segundo de tiempo) y en el momento que el contador llegue a cero, el bloque combinacional "=0" emitirá de nuevo un uno y el proceso se reanudará de nuevo (carga del LFSR con el siguiente valor de la secuencia pseudoaleatoria y carga del contador con el valor T).

Si sacamos hacia fuera 5 de los 10 bits del registro LFSR (no tienen por qué ser consecutivos) obtendremos un razonable efecto de "cielo estrellado aleatorio" que cambia cada segundo. Ahora podemos colocar todo el montaje en la parte trasera del disco de cartón dejando que se asomen hacia adelante sólo los leds y poniendo en la cara no visible la plaquita con el CLPD y la pila de botón.

Todo el código VHDL está disponible en la sección soft.

A continuación puede verse una foto de todo el conjunto pintado y montado simulando el cielo nocturno:



Y simulando el clieno diurno ("amaneciendo"):



¡Feliz Navidad a todos! :-)

[ añadir comentario ] ( 4396 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 4023 )

---

Hace tiempo publiqué las instrucciones para compilar la toolchain de GNU para ARM "bare metal" (sin sistema operativo, arm-none-eabi) basada en GCC 5.1 y newlib. Dichas instrucciones no son aplicables para las versiones actuales de GCC (7.2 a día de hoy) por lo que a continuación indico las instrucciones actualizadas a las nuevas versiones de binutils, gcc y newlib.

Se trata de una toolchain para sistemas "bare metal", sin sistema operativo, por lo que no tiene soporte para multihilos ni para librerías dinámicas.

binutils 2.29

mkdir -p /opt/baremetalarm/src
mkdir -p /opt/baremetalarm/build
cd /opt/baremetalarm/src
wget https://ftp.gnu.org/gnu/binutils/binutils-2.29.tar.bz2
tar xf binutils-2.29.tar.bz2
chown -R root:root binutils-2.29
cd ../build
mkdir binutils-2.29
cd binutils-2.29/
../../src/binutils-2.29/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --disable-nls --disable-multilib
make
make install

gcc 7.2.0 (stage 1)

cd /opt/baremetalarm/src
wget https://ftp.gnu.org/gnu/gcc/gcc-7.2.0/gcc-7.2.0.tar.gz
wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.bz2
wget https://ftp.gnu.org/gnu/mpc/mpc-1.0.3.tar.gz
wget https://ftp.gnu.org/gnu/mpfr/mpfr-3.1.6.tar.gz
tar xf gcc-7.2.0.tar.gz 
tar xf gmp-6.1.2.tar.bz2 
tar xf mpc-1.0.3.tar.gz
tar xf mpfr-3.1.6.tar.gz
mv gmp-6.1.2 gcc-7.2.0/gmp
mv mpc-1.0.3 gcc-7.2.0/mpc
mv mpfr-3.1.6 gcc-7.2.0/mpfr
chown -R root:root gcc-7.2.0
cd ../build/
mkdir gcc-7.2.0-stage-1
cd gcc-7.2.0-stage-1/
export PATH=/opt/baremetalarm/bin:${PATH}
../../src/gcc-7.2.0/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --enable-languages=c --without-headers --disable-nls --disable-multilib --disable-threads --disable-shared --disable-libssp --with-newlib
make all-gcc all-target-libgcc
make install-gcc install-target-libgcc

newlib

cd /opt/baremetalarm/src
git clone git://sourceware.org/git/newlib-cygwin.git
cd ../build
mkdir newlib
cd newlib
../../src/newlib-cygwin/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --disable-multilib 
make
make install

gcc 7.2.0 (stage 2)

cd /opt/baremetalarm/build
mkdir gcc-7.2.0-stage-2
cd gcc-7.2.0-stage-2/
../../src/gcc-7.2.0/configure --prefix=/opt/baremetalarm --target=arm-none-eabi --enable-languages="c,c++" --disable-nls --disable-multilib --disable-threads --disable-shared --disable-libssp --with-newlib
make
make install

El compilador de C++ de GCC 7.2 compila por defecto en modo C++14 y soporta prácticamente todo el estándar C++17.

[ añadir comentario ] ( 2090 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 3893 )

---

A lo largo de este post se abordará el diseño y la implementación en VHDL de una interfaz de salida VGA para FPGA. La interfaz lee una imagen de 64x48 pixels de una memoria (por ahora una ROM) interna y la renderiza usando el modo VGA estándar de 640x480 a 60Hz.

Señal VGA

Las señales más importantes que viajan por un cable VGA son:

- R (nivel de rojo, mínimo 0 voltios, máximo 0.7 voltios)

- G (nivel de verde, mínimo 0 voltios, máximo 0.7 voltios)

- B (nivel de azul, mínimo 0 voltios, máximo 0.7 voltios)

- Sincronismo horizontal (HSync, señal digital TTL que puede ser de 3.3 voltios)

- Sincronismo vertical (VSync, señal digital TTL que puede ser de 3.3 voltios)

Un flanco de bajada en HSync determina el fin de una línea horizontal de imagen y un flanco de bajada en VSync determina el fin de un fotograma, o de un cuadro). Hay unos "márgenes de seguridad" antes y después (front y back porch) de cada flanco de bajada de HSync de la misma forma que hay unos "márgenes de seguridad" (en forma de líneas en negro) antes y después (front y back porch) de cada flanco de bajada de VSync.

A continuación puede verse un diagrama de tiempos sobre cómo funcionan las señales de color y de sincronismo en un cable VGA:

(imagen copyright © 2017 Scott Larson, extraida de este artículo)


Si asumimos una resolución VGA estándar de 640 x 480 pixels a 60 Hz, tendremos los siguientes valores:

Pixel clock	Anchura (pixels)				Altura (líneas)
	Visibles	No visibles			Visibles	No visibles
		Front porch	HSync	Back porch		Front porch	HSync	Back porch
25.175 MHz	640	16	96	48	480	10	2	33

Con estos valores vemos que, en efecto tenemos una tasa de refresco de:

$${1 \over {{{640+16+96+48} \over {25175000}} \times {\left(480+10+2+33\right)}}}=59.940\ Hz \approx 60\ Hz$$

Como los valores RGB son analógicos (entre 0 y 0.7 voltios), será necesario implementar un DAC (aunque sea de forma rudimentaria) por cada componente de color. Asumiremos una imagen de 8 colores con un bit por cada componente:

000	001	010	011	100	101	110	111
negro	azul	verde	cyan	rojo	rosa	amarillo	blanco

De esta forma tendremos un DAC de 1 bit por cada color. Si la impedancia de entrada de las entradas RGB es de 75 Ohm vemos que con una sencilla resistencia de 270 Ohm en serie construimos un divisor de tensión que genera 0 voltios con un valor lógico 0 (0 voltios de salida digital) y 0.7 voltios con un valor lógico 1 (3.3 voltios de salida digital):

$${0 \times {75 \over {270+75}}}=0\ voltios$$
$${3.3 \times {75 \over {270+75}}}=0.71739\ voltios$$

Por cada píxel hay que almacenar 3 bits pero como las anchuras de bus de 3 bits son raras asumimos que cada pixel ocupa un byte del cual (por ahora) sólo se usan los 3 bits menos significativos.

Como el reloj de nuestra FPGA va a 50 MHz y el pixel clock es de 25.175 MHz se ha optado por asumir una imagen de 64 x 48 pixels. Esto es: cada pixel de la imagen en la memoria se corresponde con un cuadrado de 10 x 10 pixels en la pantalla. Usando esta aproximación, una imagen de 64 x 48 pixels necesita 64 x 48 = 3072 bytes de almacenamiento y el pixel clock se reduce de 25.175 MHz a 2.5175 MHz, que es una frecuencia más fácil de manejar por la FPGA.

Tenemos, por tanto, una memoria de 64 x 48 = 3072 bytes en la que cada byte posee los valores RGB en sus tres bits menos significativos. En cada línea de imagen se deben pintar 64 pixels (con un pixel clock de 2.5175 MHz en lugar de 25.175 MHz para que cada pixel de la memoria ocupe 10 pixels VGA de ancho) y cada línea debe ser pintada 10 veces de idéntica manera.

Ruta de datos y máquina de estados

A continuación puede verse una propuesta de ruta de datos a implementar para la interfaz VGA:


Leyenda:

PW = Pixel width
FP = Front porch (tiempo "en negro" antes del pulso HSync)
BP = Back porch (tiempo "en negro" después del puslto HSync)
LS = Line size, anchura total en pulsos de una línea en blanco de 640 pixels

El registro LineAddr almacena la dirección de comienzo de la línea actual. Es un registro que se incrementa de 64 en 64 y que ayuda a hacer el repetido de líneas (cada una de las 48 líneas de la imagen debe ser repetida 10 veces para renderizar las 480 líneas VGA).

El registro PixelAddr almacena la dirección de memoria del píxel actual que está siendo pintado. Este registro se inicializa siempre con el valor del registro LineAddr y es incrementado de uno en uno, 64 veces por cada línea (64 * 10 pixels = 640 pixels de anchura de la señal VGA).

El registro Pixel almacena el byte de cuyos tres bits más bajos se sacan las señales RGB de forma directa. Está gobernado por un multiplexor que decide si carga datos de la memoria o de la constante 0. Nótese que durante los márgenes de seguridad (front y back porch), durante los intervalos de sincronismo (tanto vertical como horizontal) y durante las lineas de retrazo (las que no se ven, de la 480 a la 524, 45 en total) debe emitirse una señal en negro por los pines RGB.

Se han habilitado además 3 contadores de propósito general que son utilizados por la máquina de estados para controlar los tiempos de cada fase de la señal VGA. La máquina de estados puede verse a continuación:

Los diferentes valores que se aplican a los contadores para controlar los tiempos del protocolo VGA se calculan teniendo en cuenta la frecuencia de reloj usada (50 MHz) y la frecuencia de pixel VGA (25.175 MHz). Por ejemplo el valor de PW (PIXEL_WIDTH) se usa para esperar un tiempo equivalente a 10 pixels:

$$PW={{1 \over 25175000} \times 50000000 \times 10}=20\ pulsos$$

De la misma forma se calcula el resto de valores:

$$FP={{1 \over 25175000} \times 50000000 \times 16}=32\ pulsos$$
$$HSYNC={{1 \over 25175000} \times 50000000 \times 96}=191\ pulsos$$
$$BP={{1 \over 25175000} \times 50000000 \times 48}=95\ pulsos$$
$$LS+BP={{1 \over 25175000} \times 50000000 \times \left(640+16\right)}=1303\ pulsos$$

Estos valores teóricos son luego ajustados ya que en esas ecuaciones sólo se tienen en cuenta los estados de espera y no se contabiliza el resto de estados, que también consumen ciclos de reloj.

Una técnica muy usada para compensar los tiempos de espera en las máquinas de estado es incluir estados que no hacen nada con transiciones vacías (épsilon). Como se puede ver en la imagen anterior, el estado 14 se alcanza siempre al final del renderizado de una línea horizontal VGA. Si Contador3 = 0 entonces se ha terminado una repetición de 10 líneas consecutivas y toca avanzar de línea, pero si Contador3 <> 0 entonces hay que volver a pintar la línea actual (la que está apuntada por el registro LA, LineAddress). En este último caso, la máquina de estados pasa por tres estados que no hacen nada (26, 27 y 28) pero que se han colocado ahí para que no haya diferencia entre la cantidad de ciclos que tarda una línea repetida y la cantidad de ciclos que tarda una línea nueva.

Buffers de salida para los sincronismos

Aunque la máquina de estados ya genera directamente las señales HSync y VSync, es necesario hacerlas pasar por un latch (biestable D) para garantizar que quedan libres de gitches.



Si no se colocasen estos latches y se cableasen directamente las salidas HSync y VSync a los pines de la PFGA podría ocurrir que transiciones intermedias espúreas entre estados generasen pulsos "fantasma" en dichas salidas. Haciendo pasar a estas señales por un latch se garantiza una carga atrasada y limpia que disminuye la probabilidad de que se produzcan estos glitches.

Por claridad, estos latches no se muestran en el diagrama con la ruta de datos mostrado anteriormente.

Código fuente e implementación

La máquina de estados se ha implementado, como otras veces, siguiendo el modelo estándar de máquina de Moore:



El resto de la implementación consiste en codificar lo registros y los multiplexores:



La imagen se aloja en una ROM cuyos datos se especifican directamente en el código fuente de Rom.vhd. Para generar la imagen en formato VHDL usando el GIMP se hicieron los siguientes pasos:

- Se creó una nueva imagen de 64 x 48 pixels.

- Menú Ventanas -- Diálogos empotrables -- Paletas -- Botón derecho dentro del listado de paletas -- Importar paleta -- En "Seleccionar origen" se marcó "Archivo de la paleta" y se seleccionó el fichero "vga_fpga.gpl" que se ha incluido dentro del proyecto. Esto creó dentro del GIMP una nueva paleta de 8 colores que se correspondía con los 8 colores que genera nuestra FPGA.

- Se trabajó la imagen de 64x48 con esa paleta.

- Cuando se terminó de trabajar con la imagen, menú Imagen -- Modo -- Indexado -- En "Mapa de colores" se marcó la opción "Usar paleta personal", se seleccionó la paleta acabante de crear a partir del fichero "vga_fpga.gpl", se desmarcó la opción "Eliminar los colores sin usar de la paleta final" y "Aceptar".

- Menú Archivo -- Exportar como -- Se seleccionó como tipo de archivo "Cabecera de código fuente en C (.h)" -- Exportar

Esto creó un fichero .h con un array con el mapa de color (la paleta) y otro array de 3072 bytes con la imagen completa. Afortunadamente el formato de datos de array de C y VHDL es relativamente similar por lo que simplemente hubo que trabajar un poco con el comando "sed" para adaptar los datos. Por ejemplo, un bloque de texto de esta forma:

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,
7,0,0,0,0,0,0,0,0,0,0,0,0,0,3,3,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,
7,0,0,0,0,0,0,0,0,0,0,0,0,3,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,3,3,3,
3,0,0,3,3,3,0,0,0,0,3,3,3,0,0,0,

Puede convertirse a formato de datos VHDL de esta forma:

$ cat datos.txt | sed -e 's/0/x"00"/g' | sed -e 's/1/x"01"/g' | sed -e 's/2/x"02"/g' | sed -e 's/3/x"03"/g' | sed -e 's/4/x"04"/g' | sed -e 's/5/x"05"/g' | sed -e 's/6/x"06"/g' | sed -e 's/7/x"07"/g'

Generando la salida:

x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",
x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"07",
x"07",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"03",x"03",
x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",
x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",
x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"07",
x"07",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"03",x"00",x"00",
x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"00",x"03",x"03",x"03",
x"03",x"00",x"00",x"03",x"03",x"03",x"00",x"00",x"00",x"00",x"03",x"03",x"03",x"00",x"00",x"00",

Que es fácilmente incluible en un fichero VHDL como un array (ver Rom.vhd).

Circuito

El circuito externo a la FPGA sólo requiere las líneas de reset, de reloj y de sincronismo conectadas directamente y cada una de las tres líneas de componentes de color (RGB) conectada con una resistencia en serie de 270 Ohm.



El resultado:





Como siempre, todo el código fuente está disponible en la sección soft.

[ añadir comentario ] ( 1876 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 3750 )

---

El STM32F103 es un microcontrolador muy asequible que incluye interfaz USB 2.0. La mayoría de desarrollos USB realizados para esta serie de microcontroladores utiliza la librería STM32Cube, desarrollada por el propio fabricante, de libre uso y que abstrae de los entresijos del protocolo al programador. Abordar, sin embargo, el desarrollo de esta funcionalidad desde cero en este o en otros microcontroladores permite profundizar y mejorar en el conocimiento del propio protocolo USB.



Un repaso rápido del protocolo USB

Aunque aquí intentaré desgranar a grandes rasgos el protocolo, recomiendo siempre las dos grandes y mejores fuentes de información sobre el mismo:

USB made simple
USB in a nutshell

Es de lo mejorcito que hay al respecto por la red ya que el documento oficial es un poco infumable. A nivel eléctrico, se trata de un protocolo serie asíncrono que utiliza dos hilos de señal balanceada. El protocolo consiste en una serie de "endpoints" multiplexados en tiempo y enumerados. Hay tres tipos de endpoint:

Control: usado para transferencias de control del dispositivo. Identificación, configuración, etc.

Bulk: usado para transferencias masivas de datos con control de errores (menos ancho de banda).

Interrupt: usado para transferencias pequeñas de datos pero con tiempo mínimo de entrega garantizado.

Isochronous: usado para transferencias masivas de datos sin control de errores (máximo ancho de banda).

Cada endpoint tiene un número asociado y un tipo. El estándar USB reserva el endpoint 0 como un endpoint de control sobre el que el host (ordenador) envía los mensajes de configuración iniciales al dispositivo que acaba de conectarse.

La secuencia ya se describió en un post anterior en el que se abordó el mismo proyecto pero utilizando el microcontrolador ATmega32u4 de AVR pero la volvemos a indicar a continuación:

1. El host detecta que hay un dispositivo conectado (detecta una resistencia pull up en D+ o en D-)

2. El host inicia una secuencia de reset poniendo a nivel bajo las líneas D- y D+ durante al menos 2.5 us.

3. El host envía un paquete de SETUP para pedir el descriptor de dispositivo al dispositivo. Este descriptor indica el tipo de dispositivo, el código de fabricante, código de producto, etc. Esta primera petición se realiza siempre indicando en el campo longitud la longitud máxima y en la respuesta proveniente del dispositivo, el host es capaz de deducir el tamaño máximo de buffer con el que trabaja el dispositivo. Hay que tener en cuenta que en el caso de dospisitivos low-speed los paquetes son siempre de 8 bytes de datos mientras que en dispositivos full-speed los paquetes pueden ser de 8, 16, 32 o 64 bytes.

4. Tras esta primera petición de descripción de dispositivo el host suele iniciar de nuevo una condición de reset y, a continuación vuelve a pedir el descriptor de dispositivo pero con el tamaño ajustado al tamaño indicado por el dispositivo en la primera petición.

5. Cada dispositivo tiene asignada una dirección en el bus que, tras es reset, es siempre 0. En este instante lo habitual es que el host envíe un paquete de SETUP de tipo SET_ADDRESS para indicarle al dispositivo que a partir de ahora el host se va a comunicar con el dispositivo usando una dirección concreta diferente a 0 y que el dispositivo debe recordar para posteriores paquetes que se transmitan.

6. Ya con la nueva dirección de bus configurada, el host envía otro paquete de SETUP para solicitar el descriptor de configuración. Este descriptor es más grande que el anterior e incluye información sobre la clase de dipositivo y los endpoints que utiliza. El descriptor de dispositivo indica en un campo cuántas configuraciones posee el dispositivo, que suele ser siempre 1, por lo que el host normalmente sólo pide un descriptor de configuración.

7. El host (normalmente el driver instalado en el host) decide qué configuración quiere activar (que suele ser la única) en el dispositivo enviando un paquete de SETUP de tipo SET_CONFIGURATION. A partir de este instante el dispositivo queda conectado y con sus endpoints preparados para recibir y enviar datos propios de la funcionalidad del dispositivo.

La secuencia puede variar ligeramente en función del sistema operativo del host. Hay que recordar que en el protocolo USB el host es siempre el que envía "tokens" al dispositivo, incluso para traer datos desde el dispositivo. Cuando el host quiere enviar datos a un dispositivo hace transferencias de tipo SETUP y OUT mientras que cuando quiere recibir datos del dispositivo, el host hace transferencias de tipo IN pero siempre es el host el que pregunta. Un dispositivo no puede enviar datos a un host hasta que el host mande un token de tipo IN al dispositivo.

Implementación en el STM32F103

La serie STM32F103 es la serie más sencilla y baratita de toda la familia STM32 con soporte USB 2.0 full-speed (en el momento que escribo esto se puede conseguir una placa mínima de desarrollo con STM32F103 por menos de 3 ¤ en AliExpress). La documentación de referencia para programar el módulo USB es algo oscura y no está pensada para que te sumerjas mucho en ella, sino para que utilices la librería STM32Cube que, aunque es open source y permite un uso sin restricciones, su uso le quita toda la gracia al concepto de programar un microcontrolador desde cero :-).

A continuación puede verse la implementación de un dispositivo USB consistente en dos endpoints sencillos de tipo bulk (uno de entrada y otro de salida). La razón para implementar un dispositivo así es el hecho de que desde Linux el driver "usbserial" permite intercambiar datos con cualquier dispositivo USB que cumpla que tenga un endpoint bulk de salida y otro de entrada sin importar su clase, ni el código de fabricante ni de producto. Es un driver ideal para depurar dispositivos USB y que instancia un "/dev/ttyUSB0". Escribiendo en "/dev/ttyUSB0" se envían bytes a través del endpoint de salida mediante paquetes OUT mientras que leyendo de "/dev/ttyUSB0" se reciben bytes desde el dispositivo a través del endpoint de entrada mediante paquetes IN que envía el host.

La función usbDeviceInit se encarga de inicializar los tranceptores y de activar la interrupción de "USB Reset":


A continuación definimos los diferentes descriptores del dispositivo (descriptor de dispositivo, descriptor de configuración y descriptor de cadena 0 que indica los idiomas disponibles en el dispositivo):


Los buffers de recepción y transmisión USB en el caso de STM32 deben ser direccionados y accedidos de forma particular. Desde el punto de vista del subsistema USB, la anchura del bus de datos es de 16 bits, en lugar de 32 bits aunque los datos están alineados a 32 bits. Gráficamente se ve mejor:

Offset desde el punto de     Offset desde el punto de
vista del controlador USB    vista del programa (CPU)
0                            0
1                            1
2                            4
3                            5
4                            8
5                            9
6                            12

Como se puede ver, por cada palabra de 32 bits direccionada desde la CPU sólo se puede acceder a los 16 bits menos significativos. Para leer los 2 primeros bytes de la memoria USB desde la CPU hay que acceder a los 4 primeros bytes de dicha memoria (como si fuese un entero de 32 bits) y quedarnos con los 16 bits menos significativos. Los siguientes 2 bytes no están en los 16 bits más significativos de la primera palabra de 32 bits, sino en los 16 bits menos significativos de la siguiente palabra de 32 bits y así sucesivamente. Teniendo en cuenta esta particularidad se implementan dos funciones de acceso a esta memoria USB para copiar hacia y desde ella:


A continuación definimos las rutinas de interrupción correspondientes. Primero escribimos la rutina usbDeviceISRReset, que se ejecuta en caso de que se genere una interrupción de "USB Reset" provocada por una condición de reset en el bus USB. Dicha condición de reset es iniciada por el host en cuanto detecta un nuevo dispositivo conectado a una de sus bocas USB (es el paso 2 de la secuencia descrita anteriormente):


A continuación se define la rutina principal que atiende las interrupciones USB, usbDeviceISR. Esta función llama, en caso de darse una condición de reset a la función usbDeviceISRReset definida arriba:


Lo primero que hace la rutina es identificar el endpoint por el que se ha producido la transacción. En caso de que la transacción se haya producido a través del endpoint 0 se comprueba si es un token SETUP u OUT y, si es un token SETUP, se parsea y se mira a ver si el host está mandando algo (configuraciones) o si lo está pidiendo (descriptores). Si el host está pidiendo algo, hay que rellenar el buffer de transmisión con los datos que necesita, pues la siguiente transacción que realizará el host a través del endpoint 0 será utilizando uno o varios tokens IN y para entonces los datos tienen que estar ya preparados en dicho búffer.

Recordemos algunos elementos básicos sobre cómo son las transferencias USB a través del endpoint 0:

Control: Es un endpoint que debe ser siempre configurado como de tipo "Control" y es bidireccional. Un dispositivo puede definir endpoints de control adicionales pero el endpoint 0 de control siempre debe estar disponible.

Transacciones SETUP: Los endpoints configurados como de control permiten transferir un tipo especial de token denominado SETUP. Este token puede ser de entrada o de salida (siempre desde el punto de vista del host).

Transacciones SETUP de salida: El host manda un token SETUP, a continuación envía cero o más tokens OUT con datos anexos y por último manda un token IN para que el dispositivo mande 0 bytes a modo de ACK.

Transacciones SETUP de entrada: El host manda un token SETUP, a continuación envía cero o más tokens IN para recibir datos del dispositivo y al final el host manda un token OUT con 0 bytes anexos a modo de ACK hacia el dispositivo.

Si la transacción se ha producido en el endpoint 1 o 2, se asume que es una transacción simple de tipo bulk:

Endpoint 1: Es un endpoint configurado como de tipo IN y en esta implementación no hace nada, pues el STM32 no manda ningún dato cuando es leido a través del USB.
Endpoint 2: Es un endpoint configurado como de tipo OUT. Por lo tanto, el STM32 recibe por aquí los datos que son enviados desde el host y los manda formateados a través de la USART.

Nos limitamos a mandar por la USART1 todo lo que entra a través del endpoint de tipo "bulk out", mientras que las lecturas desde el host al endpoint de tipo "bulk in" devuelven siempre 0 bytes.

Para cargar el módulo "usbserial" en el kernel simplemente hay que hacer:

modprobe usbserial vendor=0xf055 product=0x0001

Esto nos permite comunicarnos con el dispositivo desde la misma shell:

echo "Hola, caracola" > /dev/ttyUSB1

Partiendo de este código se pueden implementar multitud de dispositivos USB en este microcontrolador (Mass storage, HID, DFU, etc.). Todo el código fuente puede descargarse desde la sección soft.

Quiero agradecer a Jian Jiao (mculabs.net) la ayuda prestada a la hora de comprender algunos entresijos en la programación del módulo USB del microcontrolador STM32.

[ añadir comentario ] ( 2456 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 4686 )

---

El efecto "shuffle" o "swing" es un efecto muy utilizado en producción musical para humanizar y meter mas "groove" a canciones reproducidas por un secuenciador. El efecto consiste básicamente en adelantar o atrasar el disparo de determinadas notas durante algunos milisegundos para dar sensación de "humanidad" a la cadencia de la música. A lo largo de este post se abordará la implementación en C++ sobre Arduino de un "shuffler" MIDI para secuencias 4/4.

La forma más estándar de "shuffle" en secuencias musicales de 4/4 es la que consiste en retrasar una cantidad de tiempo determinada (milisegundos) la segunda y la cuarta semicorchea después de cada negra:

*----.----.----.----*----.----.----.----*----.----.----.----*----.----.----.---- Compás 4/4 estándar
*------.--.------.--*------.--.------.--*------.--.------.--*------.--.------.-- Compás de 4/4 con "shuffle"

Los asteriscos determinan las negras (4 negras por cada compás de 4/4) y los puntos determinan las semicorcheas (4 semicorcheas por cada negra). El concepto es muy sencillo, aunque a la hora de implementarlo en MIDI hay que tener en cuenta algunos aspectos importantes.

Protocolo MIDI

El protocolo MIDI es un protocolo muy sencillo por el que se envían eventos e información musical. No es objetivo de este post el explicar el protocolo ni los mensajes MIDI (cualquier búsqueda sobre "midi protocol" en la red nos dará acceso a centenares de páginas donde lo explican muy bien) aunque sí nos centraremos en los mensajes que más nos interesan de cara a implementar nuestro shuffler.

Dentro de los mensajes MIDI hay unos especiales denominados de tiempo real que son transmitidos por los secuenciadores cuando están reproduciendo una secuencia MIDI pregrabada:

0xF8: "timing clock" se envía 24 veces por cada negra.
0xFA: "start" indica que se va a iniciar la reproducción de una secuencia. Este mensaje es seguido de forma inmediata por el primer 0xF8.
0xFB: "continue" indica que se reanuda la secuencia por donde se paró.
0xFC: "stop" indica que se para la secuencia.

Por tanto, si en nuestro secuenciador musical tenemos una canción con un tempo de 120 negras por minuto, al emitir dicha secuencia por un cable MIDI, de forma intercalada con los mensaje de activación y desactivación de las notas y demás, irán entremezclados mensajes 0xF8 a razón de 24 por cada negra, es decir:

$${{120 \times 24} \over 60} = 48\;mensajes/segundo$$

Nótese que la cantidad de mensajes 0xF8 enviados por unidad de tiempo no depende de la velocidad de transmisión MIDI, sino del tempo de la secuencia musical que se esté reproduciendo. Si cada vez que nos llegue un mensaje 0xF8 desde el secuenciador vamos contando de 0 a 23 dando la vuelta de nuevo a 0 cada vez que llegamos a 24 tenemos que los mensaje 0xF8 coinciden en el tiempo con las negras y semicorcheas de la forma que indica la siguiente tabla:

n                 s                 s                 s
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23

En esta tabla se puede ver que la negra (el beat) coincide con el contador de mensajes 0xF8 recibidos a 0 mientras que las tres semicorcheas siguientes coinciden con ese mismo contador a 6, a 12 y a 18. Ahora tenemos una base de tiempo sólida que podemos aprovechar para implementar nuestro efecto shuffle: Lo que hay que hacer es atrasar en el tiempo los mensajes de "note on" y "note off" que lleguen entre el instante 6 y el 12 y entre el instante 18 y 0 de la siguiente negra.

n                 s                 s                 s
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23
                  +--------> atrasar                  +--------> atrasar

Dicho atraso no puede ser tal que nuestro shuffler emita notas fuera de orden por lo que el retraso en el tiempo debe ser proporcional (una nota que llegue entre los instantes 6 y el 7 será atrasada más que una que llegue entre los instantes 9 y 10 pero la primera nunca debe emitirse depués de la segunda, debemos garantizar el orden de llegada de los eventos "note on" y "note off").

Algoritmo propuesto

El MIDI shuffler se plantea como un filtro MIDI, un dispositivo con una entrada MIDI y una salida MIDI que se intercala entre el secuenciador y los sintetizadores. La salida MIDI del secuenciador irá conectada a la entrada MIDI del shuffler y la salida MIDI del shuffler irá conectada a la entrada MIDI de los secuenciadores. A continuación se plantea una propuesta de pseudocódigo para el MIDI shuffler:

iniciarShuffler
    estado := ESPERAR_START_MIDI
fin iniciarShuffler
 
getInstanteAtrasado(t)
    ret := (tamSemicorchea - tamReducido) + ((t + tamReducido) / tamSemicorchea)
    devolver ret
fin getInstanteAtrasado
 
byteMIDIRecibido(byte)
    enviar := SÍ
    si (estado = ESPERAR_START_MIDI) entonces
        si (byte = 0xFA) entonces
            colaRetraso.borrar()
            estado := ESPERAR_PRIMER_CLOCK_MIDI
        fin sin
    en otro caso, si (estado = ESPERAR_PRIMER_CLOCK_MIDI) entonces
        si (byte = 0xF8) entonces
            estado := ESPERAR_CLOCK_MIDI
            contadorReloj := 6
            indiceSemicorchea := 0
            timer.iniciar()
        fin si
    en otro caso, si (estado = ESPERAR_CLOCK_MIDI) entonces
        si (byte = 0xF8) entonces
            contadorReloj := contadorReloj - 1
            si (contadorReloj = 0) entonces
                si ((indiceSemicorchea = 0) ó (indiceSemicorchea = 2)) entonces
                    tamSemicorchea = timer.getValor()
                    tamReducido = (temSemicorchea * (100 - PERCENT)) / 100
                fin si
                contadorReloj := 6
                indiceSemicorchea := (indiceSemicorchea + 1) mod 4
                timer.parar()
                timer.iniciar()
            fin si
        en otro caso, si (esEventoNota(byte) y ((indiceSemicorchea = 1) ó (indiceSemicorchea = 3)) entonces
            t := getInstanteAtrasado(timer.getValor())
            colaRetraso.meter({byte, t})
            enviar := NO
        en otro caso, si (byte = 0xFC)
            estado := ESPERAR_START_MIDI
        fin si
    fin si
    si (enviar = SÍ) entonces
        enviar(byte)
    fin si
fin byteMIDIRecibido
 
principal
    siempre hacer
        si ((indiceSemicorchea = 1) ó (indiceSemicorchea = 3)) entonces
            t := timer.getValor()
            mientras (colaRetraso.hayAlgo()) hacer
                d := colaRetraso.getCabeza()
                si (d.t <= t) entonces
                    colaRetraso.sacar()
                    enviar(d.byte)
                en otro caso
                    salir del bucle
                fin si
            fin mientras
        fin si
    fin siempre
fin principal

Lo que hace el algoritmo es aprovechar el intervalo entre el midi clock 0 y el 5 para calcular el tiempo en unidades de timer que dura una semicorchea. El objeto "timer" es un timer de bastante resolución que se arranca en el instante 0 y se para en el instante 6. En ese instante 6, una vez parado el timer, se anota la cuenta del mismo como tamSemicorchea (para indicar que es el tamaño en ticks de nuestro contador de lo que dura una semicorchea) y se calcula tamReducido a partir del porcentaje de "shuffle" que queramos (un shuffle del 0% da un tamReducido = tamSemicorchea, mientras que un shuffle del 100% da un tamReducido = 0).

instante  semicorchea   acción
0         0             Iniciar timer de alta resolución
1
2
3
4
5
6         1             Anotar cuenta del timer, pararlo
7                       y volver a iniciarlo. Encolar cualquier
8                       evento "note on" o "note off" que llegue
9                       en este intervalo calculando su instante
10                      de emisión con una regla de tres.
11
12        2             La misma que la semicorchea 0
13
14
15
16
17
18        3             La misma que la semicorchea 1
19
20
21
22
23

Entre los instantes 6 y el 11 lo que se hace es encolar los eventos de "note on" y "note off" que vayan llegando calculándoles en el momento que llegan, en qué instante del tick del timer deben ser transmitidos haciendo una regla de tres (en getInstanteAtrasado) y metiendo cada una de estas parejas de valores (byte e instante que debe ser transmitido) en la cola "colaRetraso".

Lo mismo se hace para los instantes de tiempo 12 al 17 y 18 al 23, respectivamente.

Ya tenemos los eventos atrasados metidos en una cola (para garantizar que el orden de emisión sea el mismo que el de recepción), ahora lo que hay que hacer es emitirlos en el instante que corresponda. y de esto se encarga el procedimiento principal en su bucle infinito. Este procedimiento principal ejecuta un bucle infinito que lo que hace es inspeccionar si hay algo que enviar en la cola "colaRetraso", si hay algo que debe ser enviado (su instante de envío es menor o igual al valor actual del timer) lo envía y lo quita de la cola. El procedimiente byteMIDIRecibido es invocado cada vez que llega un byte por el puerto MIDI.

El circuito

El MIDI shuffler, como se comentó antes, hace de filtro MIDI con una entrada y una salida. La cantidad de efecto shuffle se controla mediante un potenciómetro conectado a una de las entradas analógicas del Arduino.

Con el potenciómetro al mínimo se aplica un efecto shuffle del 0% (sin efecto shuffle) mientras que con el potenciómetro al máximo se aplica un efecto shuffle del 50% (valores superiores al 50% genera unos resultados muy extremos).

Implementación en C++

A pesar de que en el algoritmo propuesto el procedimiento byteMIDIRecibido se supone que es invocado de forma asíncrona por el sistema cada vez que llega un byte por el puerto MIDI, lo cierto es que es más sencillo si en la rutina de interrupción de la UART encolamos los bytes MIDI que van llegando por la entrada MIDI y luego los vamos sirviendo en el bucle principal antes de comprobar el estado de la colaRetraso, haciéndolo de esta forma evitamos colisiones y la necesidad de hacer que colaRetraso sea reentrante.


A continuación puede verse un vídeo con el MIDI shuffler en acción (obviamente, hay que poner el audio para que se oiga :-) )



Todo el código fuente puede descargarse de la sección soft.

[ añadir comentario ] ( 2214 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 14047 )

---

<< <Anterior | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | Siguiente> >>

- Página generada en 0.2413 segundos | Site Views: 172793