Bueno, despues de ir eliminando dudas sobre el pasaje de imágenes de rectangular a coordenadas polares (
http://www.todopic.com.ar/foros/index.php?topic=43367.0) y luego de resolver dudas para el almacenamiento externo de las imágenes y la velocidad de transferencia de datos (
http://www.todopic.com.ar/foros/index.php?topic=43384.0) estamos en condiciones de ir publicado los avances del proyecto.
Resumiendo tenemos:
Motor: 1/8 HP 1300RPM (aproximadamente, lo tenemos que medir). Con este motor conseguimos 21fps. Estamos al límite inferior para que no haya parpadeo, pero no hemos conseguido otro motor. Igual tenemos que medirlo, quizá sea de 1450 y no me doy cuenta a simple vista.
Tira LED: 250mm de radio y unos 64LED para conseguir 128pixeles de resolucion. Son LED de 3mm de alta intencidad, de 20° de apertura (los mas cerrados que conseguimos para obtener puntos bien definidos) verdes. Será un POV monocromo, pero la idea es que tenga buena resolucion.
Imágenes: Con 64 LED si queremos dividir al círculo en 360 partes cada imagen pesaría 23040 bits. Si vamos por 256 divisiones pesarían 16384 bits. Creo que menos que eso no sirve por ser un POV largo. Con estos pesos queda excluida la memoria interna de cualquier micro si queremos generar 4 o 5 imágenes. Hay que tener en cuenta que ciertas cosas conviene tenerlas almacenadas y otras generarlas en runtime. Por ejemplo, el Reloj analógico es mucho más facil generarlo en runtime ya que es una imagen netamente Polar. En el caso de imágenes comunes, que a simple vista son cartesianas, conviene transformarlas en la PC y almacenarlas ya polarizadas.
Otra cuenta que podemos sacar para las imágenes es la siguiente. Una imagen cartesiana de 128x128px (que es lo que podemos mostrar con nuestra barra de 64 leds) pesaría 16384bits, pero en la circunsferencia del POV no podemos mostrar todos esos bits, ya que es el círculo inscripto en el cuadrado de 128x128. Si tomamos proporcionalidad de superficie, el círculo de 64bits de radio tiene una superficie de 12868 bits, por lo que ocupando esa cantida de bits deberiamos estar bien. En ese caso 12868/64 = 201. O sea 200 posiciones circulares.
uC: Tanto a los chicos como a mi nos entusiasmó la idea de poner un ARM. A ellos (que no conocen nada de arquitecturas) les interesó por usar la misma arquitectura de uC que tienen en sus celulares
, a mi me interesó porque sería mi primer placa completa con uno de estos micros. Funciona a 72MHz, posee 2 SPI, no tiene DMA, tenemos 64Kbyte de FLASH, 8Kbyte de RAM, USB con toda la API incluida para CDC, HID y MSC. Tambien permite Device Firmware Upgrade.
Almacenamiento Externo: Usaremos una vieja y reciclada AM29F010-120 en formato DIP. Tenemos alguna en formato SMD, pero con el encapsulado DIP se nos facilita muchísimo el ruteo. Esta memoria es de 1Mbit con lo que podríamos almacenar 64 imágenes, más que suficiente para una pequeña animacion. Tomando 12868 podemos almacenar 80 imágenes completas.
Resumiendo los tiempos:
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. Tomemos como partida de caso líite 360 posiciones en el círculo.
El motor gira a mas o menos 1300RPM o sea 21.66 rev por segundo. Por lo que una vuelta completa le tomará 46mseg. Si queremos poder distinguir 1°, el tiempo entre cada pixel será 46mseg * 1°/360° = 127useg. Para obtener una imagen estable lo ideal a mi modo de ver es que en la interrupcion se haga lo menos posible para asegurar que cada 127useg se actualicen los led. Esos 127useg dependeran de la velocidad real de motor en cada revolucion y hay que ir actualizando constantemente.
En lospróximos días iremos poniendo los avances en el diseño.
Saludos!
