Dudas con diseño de sistema Persistencia de la Vision

[elgarbe]

Hace ya 2 años que con mis alumnos diseñamos y armamos distintos relojes POV.
El del año pasado fue este "reloj analógico"
http://www.todopic.com.ar/foros/index.php?topic=42236.msg350469#msg350469

que si bien no es muy lindo, sirvió para que entiendan la idea y puedan armar una base para que los nuevos alumnos usen y mejoren.

Este año vamos a usar el mismo soporte y motor (1500RPM) pero queremos poder mostrar una secuencia de imagenes (en 1 color) bien simples, por ejemplo una carita que pase de estar seria a sonrreir, quizá con una secuencia de 4 o 5 imágenes.

Pero este sistema me presenta un reto que aún no me he sentado a pensar bien y necesito ayuda para resolver.
El problema es como pasar de rectangular a polar. O sea, yo puedo mapear la carita en forma rectangular, pero la barrera de LED va girando... entonces tengo 2 opciones, una es dibujar las imagenes en la PC, convertir a polar y obtener la secuencia de datos que se deben mostrar en cada posicion angular de la barra y luego almacenar esa info en el uC. La otra es almacenar en memoria, en forma rectangular la imagen e ir convirtiendo a polar en cada momento...
El problema es que no me imagino como resolver esa parte, la de crear la imagen "circular" en la PC o la de pasar de rectangular a polar en el uC...

Alguien tiene una idea como para poder empezar a estudiar/trabajar?

Saludos!

[nico]

Hola elgarbe, en este proyecto

usan memoria externa para almacenar la imagen según muestran, y en el video dicen que hacen justamente conversion de cartesiano a polar en tiempo real con un micro. Espero te sirva como punto de partida.

Una consulta, como hicieron la alimentación de la placa?, o tiene alimentación propia?,

Slds.

[elgarbe]

Hola elgarbe, en este proyecto

usan memoria externa para almacenar la imagen según muestran, y en el video dicen que hacen justamente conversion de cartesiano a polar en tiempo real con un micro. Espero te sirva como punto de partida.

Una consulta, como hicieron la alimentación de la placa?, o tiene alimentación propia?,

Slds.

Gracias por el video!
Lo que sigo sin darme cuenta es como se realizaría la conversión de cartesiano a polar... no me lo imagino...

En nuestro caso tiene una batería de lipo en la parte giratoria. El reloj es facil porque se enciende la barra completa en funcion del ángulo actual de la misma...

Saludos

[willynovi]

se me ocurre bien simple, no se si te serviria usar trigonometria
el valor de xi e yi lo tienes de tu diseño,
el valor del angulo a lo tienes en como va girando la hélice
luego obtienes el valor li

[elgarbe]

Excelente, es el empujón que necesitaba. Ya estoy viendo como pasar eso a discreto para trabaja en el micro. También estoy viendo de hacer un programita  para convertir la imagen y almacenar lo que debo cargar en la tira de LED en cada momento.
 
Alguien tiene info sobre como leer un BMP con VB.net?

Saludos y gracias!

[elgarbe]

Bueno, finalmente me decidí por hacer el procesamiento de los Sprite en la PC, obtener las secuencias de imágenes, pasarlas a Polar y finalmente el resultado almacenarlo en alguna memoria. De ese modo lo unico que debería hacer el micro es leer la memoria y llenar la barra de leds en cada momento.

Para los LED vamos a utilizar registros de desplazamiento manejados por el SPI (solo la salida del bus y la señal de CLK se usarán).

Haciendo un poco de números:

La barra de LEDs tiene una longitud de 250mm, los led son de 3mm (3.2mm), por lo que si suponemos un espaciado de 3.5mm entre ellos podríamos meter 71 LED. Tomemos como punto de partida 64LEDs. Con esa tira, al girar podremos hacer una imagen de 128x128 pixeles.
El perímetro del círculo descripto por el led mas alejado del centro es pi * 500 = 1570mm. Si quisieramos que poder tener un pitch de 3.5mm en el extremo deberíamos poder hacer todo el procesamiento en lo que tarda en girar 3.5mm * 360° / 1570mm = 0.8°

El motor gira a mas o menos 1300RPM (queria un motor de 1450 pero no consegui) o sea 21.66 rev por segundo. Por lo que una vuelta completa le tomará 46mseg. Si queremos poder distinguir 0.8°, el tiempo entre cada pixel será 46mseg * 0.8°/360° = 102useg.

Como uC estoy pensando en un LPC1114 (ARM Cortex M0 a 50MHz), un LPC1347 (ARM Cortex M3 a 72MHz) o algún 18F a 48MHz. Creo que ninguno tiene dma en el spi, va, en realidad no sé si hay algun 18f con dma. Tengo eso micros porque no he usado nunca un 24f o un 33f o dspic.

Para manejar los led usaremos 8 74hc595 los que pueden funcionar a 20MHz, creo, sin problemas. Nunca trabaje a esa frecuencia, es conseguible sin problemas?
Si tomamos esa velocidad, entonces llenar los registros nos tomará 0.05useg x 64 = 3.2 useg. Si suponemos que no llegamos a 20 y trabajamos a 5MHz necesitaremos 12.8useg. Con ese tiempo nos quedan 90useg para cálculos... creo que sería suficiente ya que no hay mucho que calcular ya que las imagenes estaran en memoria. Si estuviesen en una memoria externa entnces habria que hacer bien los cálculos ya que se nos agrega el tiempo de lectura de las mismas...

En principio parecería que puede funcionar de esta forma...

Saludos!

[elgarbe]

se me ocurre bien simple, no se si te serviria usar trigonometria
el valor de xi e yi lo tienes de tu diseño,
el valor del angulo a lo tienes en como va girando la hélice
luego obtienes el valor li

bueno, estuve trabajando la ide de Willy y finalmente pude conseguir, usando trigonometría, pasar una imagen a "Circular".

Dejo algunas muestras:

https://www.dropbox.com/s/uygw1hjurpbv06w/Captura%20de%20pantalla%202014-09-07%2000.31.52.png?dl=0

https://www.dropbox.com/s/i2r7fxgsaog8hk6/Captura%20de%20pantalla%202014-09-07%2000.38.08.png?dl=0

En la primer imagen se ve que aparece un efecto indeseado en las cercanías del centro, lo que me lleva a pensar que quizá no debamos poner led en el centro o evitar tener cambios de imágenes en esa zona... Ya seguiremos estudiando ese problema.

Saludos!

[BrunoF]

Hola Leo,

el problema de los LEDs en el centro se deben a la supersposición de puntos debido al bajo desplazamiento lineal con respecto a radios más grandes. Es decir, cerca del centro, los pixeles van a tender a superponerse. Es normal no llegar hasta el centro con LEDs debido a ese fenómeno, o bien sacrificar resolución en esa zona y dibujar puntos más espaciadamente entre ángulos, aunque por el contrario, es donde mejor densidad de puntos tenés (mejor resolución/dpi).

En cuanto al SPI, si no hay DMA al menos los LPC que mencionaste tienen un FIFO de 8 elementos. Conviene configurar el SPI en modo 16 bit. De esa manera podés cargar al SPI con 8 tramas de 16 bit cada una. Tal vez convenga hacer por interr. el "angularSync" (que sólo debería efectivizar los datos del latch cargados previamente) y pollear el estado del buffer de salida del SPI desde el bucle principal para ir cargando los datos necesarios.

Saludos.

[elgarbe]

Hola Leo,

el problema de los LEDs en el centro se deben a la supersposición de puntos debido al bajo desplazamiento lineal con respecto a radios más grandes. Es decir, cerca del centro, los pixeles van a tender a superponerse. Es normal no llegar hasta el centro con LEDs debido a ese fenómeno, o bien sacrificar resolución en esa zona y dibujar puntos más espaciadamente entre ángulos, aunque por el contrario, es donde mejor densidad de puntos tenés (mejor resolución/dpi).

Si, eso me di cuenta en el programita .net que hice para traducir las imágenes (al final me senté a pensar hasta que lo saqué funcionando). Aún no me decido a sacar la zona central he visto proyectos que pintan imagenes rectangulares usando el centro casi sin desformacion... voy a ver si podemos solucionar algo por software.

En cuanto al SPI, si no hay DMA al menos los LPC que mencionaste tienen un FIFO de 8 elementos. Conviene configurar el SPI en modo 16 bit. De esa manera podés cargar al SPI con 8 tramas de 16 bit cada una. Tal vez convenga hacer por interr. el "angularSync" (que sólo debería efectivizar los datos del latch cargados previamente) y pollear el estado del buffer de salida del SPI desde el bucle principal para ir cargando los datos necesarios.
Saludos.

Habí pensado justamente eso, en la interrupcion solo activar el latch y en el bucle principal, primero llenar los registros haciendo pooling en el buffer (creo que hacerlo por interrupcion ahorra poco tiempo ya que los saltos meten bastante retardo y configurando el SPI a 5 o 10MHz no es mucho el tiempo a esperar para que salgan los 16bits).

Ahora, no es una pena que el 1347 no traiga DMA aunque sea en el SPI? yo me desepcione un poco cuando vi eso, daba por descontado que tenia DMA...

Saludos!

[BrunoF]

Lamentablemente por lo que vi tampoco tienen interrupción asociada al buffer SPI vacío. Sólo a cuando está medio vacío creo.

Un micro por el que se me caen las babas, y del cual hay también una placa LPCXPresso, es el LPC11U68. Ese puede que sea mi futuro con los LPC.

Saludos!

[elgarbe]

Bueno, el esquemático que estoy trabajando, parte uC:

Captura de pantalla 2014-09-14 17.03.04 by leonardogarberoglio, on Flickr

Estoy leyendo sobre el conector SWD ya que pienso programar/debuguear con una placa LPCLink y como no tengo conector hembra para el JTAG usaremos el conector que queda al borde de la placa al separar el Stick.

Saludos!

[BrunoF]

Yo uso ese conector también porque el conector del JTAG que viene tiene un paso con el que resulta dificil conseguirle el conector porque es de .05"

Saludos!