Autor Tema: POV esferico Terrestre  (Leído 5372 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
POV esferico Terrestre
« en: 18 de Febrero de 2015, 08:56:28 »
Buenas, llevo poco en el foro y voy poniendo algunas contribuciones, así que voy a colgar uno de mis primeros proyectos que hice hace ya tiempo cuando era bastante novatillo jeje, es un POV esferico, espero que les guste

un saludo.

El parpadeo que se aprecia es cosa de la cámara que se uso para grabarlo, en realidad no parpadea.


« Última modificación: 07 de Abril de 2015, 03:38:43 por juaperser1 »
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
Re: POV esferico Terrestre
« Respuesta #1 en: 20 de Febrero de 2015, 02:15:12 »
Chulísimo  ((:-))

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: POV esferico Terrestre
« Respuesta #2 en: 20 de Febrero de 2015, 16:52:32 »
Gracias me alegro que te guste
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado rafaelrg06

  • PIC12
  • **
  • Mensajes: 54
Re: POV esferico Terrestre
« Respuesta #3 en: 06 de Abril de 2015, 18:40:03 »
Hola amigo juaperser1 y cualquiera que me pueda ayudar (elgarbe):
Estoy construyendo un display POV y verdaderamente necesito ayuda. El problema que tengo es a la hora de controlar el tiempo que debe de estar encendido o apagado los leds, pienso que el resto, aunque no está terminado, no creo que sea un gran problema. Tengo el software bastante adelantado ya que tengo listas las funciones que cuentan el tiempo, que grafican dependiendo de la posición y la hora entre otros detalles.
La idea de mi reloj pov es la siguiente:
Lo inicié con un 16f628a porque era lo que tenía en las manos y creía que me iba a resultar suficiente, pero cuando empecé a programar el código me ha llenado toda la rom y aún faltan cosas, por lo que he decidido emigrar a un 16f887 que también tengo a mano, sin embargo, como empecé el código en un 628a y necesitaba ROM, solo cambié a un 648A con la intención de terminar la fase en que el software sincroniza adecuadamente el tiempo de encendido y apagado y con este punto resuelto emigrar definitivamente.
La idea es usar un sensor infrarrojo como sensor de posición de referencia que indique la "posición 0" y a partir de ahí comienzan a medirse los 60 "sectores" que dividen el reloj (o las 60 líneas )usando la interrupción por RB0. El asunto es que me he decidido crear un algoritmo que se ajuste a la velocidad del motor, contando el tiempo que demora en dar cada vuelta y a partir de ahí calcular el tiempo que debe demorar la interrupción que controla el encendido del display POV. Este cálculo lo establezco con una función que configura el timer2 que interrumpa, primero el tiempo de encendido, y dentro de la interrupción configuro el timer2 (cargo el valor precalculado en el registro PR2) para que se interrumpa el tiempo que debe estar apagado el display, luego, en la interrupción de apagado vuelvo a cargar el timer2 con el tiempo de encendido, y así sucesivamente.
Pero no se que pasa, este algoritmo no me funciona adecuadamente y eventualmente se ejecuta varias veces seguidas el timer2 y en fin...
¿Me podrías decir como resolviste este asunto? lo ideal sería fijar la velocidad del motor, pero si en algún momento su velocidad varía, el cartel empezaría a graficar mal, por lo que creo que lo ideal sería un algoritmo que se adapte a la velocidad del motor.

¿me podrías ayudar en este asunto?


Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: POV esferico Terrestre
« Respuesta #4 en: 07 de Abril de 2015, 03:38:23 »
Hola rafaelrg06, vas por buen camino, el estudio que has hecho me parece el adecuado, el micro me parece un poco cortillo para operaciones matematicas y creo que lo que te puede estar pasando:

Citar
Pero no se que pasa, este algoritmo no me funciona adecuadamente y eventualmente se ejecuta varias veces seguidas el timer2 y en fin...

podría ser incluso que en tu sistema salte mas de una vez la interrupción externa antes de que haya realizado las operaciones matemáticas, de carga, limpieza...etc.

deberías ir por partes, como en la mayoría de las cosas, asegúrate que tu paso por 0 funciona pintando un punto una linea o cualquier cosa sencilla siempre en el mismo tiempo ( cuando pase por 0 o un poco desfasado), esto hará que se pinte siempre en el mismo lugar, si te lo pinta en el mismo sitio siempre, enorabuena tu paso por 0 funciona. una vez tengas esto, comienza a pintar algo mas complejo.
cuando esto te funcione, entonces comienza a implementar la velocidad variable, asi partiras desde la base de que todo lo demás funciona.

esto es valido si quieres que se mantenga el mensaje fijo. si quieres que gire como hace el mio debes hacer algunas cosas mas.

un saludo y ya me contaras como te va.

por cierto ahora han salido unos perifericos para microchip que vienen muy pero que muy bien para hacer pov, ya que te resuelven el problema del posicionamiento.

http://www.microchip.com/pagehandler/en-us/family/8bit/peripherals/coreindependent/angtmr.html
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: POV esferico Terrestre
« Respuesta #5 en: 07 de Abril de 2015, 08:38:52 »
Hola, en esta carpeta de dropbox vas a encontrar todos los archivos del primer POV que hicimos con los alumnos en la escuela. Lamentablemente todo el desarrollo estaba en el foro de neoteo, el cual parece no funcionar más.
https://www.dropbox.com/sh/hyh4ir0xvav361k/AAC7Qkuwhf5J1plf3C56Kx3Va?dl=0

Estan los proyectos en CCS con los avances paso por paso como indica juaperser, primero encendiendo un punto, luego una linea, luego un numero, etc.
Esto es lo que tiene google en caché sobre ese post que te hablo:

http://webcache.googleusercontent.com/search?q=cache:tbxjeQ-t8eYJ:www.neoteo.com/foros/reply/proyecto-reloj-pov-otro-mas-67-39/+&cd=11&hl=es-419&ct=clnk&gl=ar

si en algun momento vuelve el foro, o si puedes rastrear en la cache encontrarás toda la explicacion...

sino, bueno, pregunta y veremos que podemos hacer.

En principio te comento que necesitas 2 timer. El primer es para calcular las RPM actuales del motor. Al valor del ese timer, lo divides por la cantidad de pixeles que queres de resolucion (en tu caso 60) y obtienes cuantos ticks deven transcurrir entre cambio y cambio. Con eso configuras un segundo timer y en ese timer metes el código de actualizacion de informacion.

Tratá de encender una linea en un lugar fijo y luego ve avanzando. Si te parece, comparte el código para que veamos por donde vas y el esquemático del circuito para saber que estas haciendo, igual si tenes alguna foto o algo. De paso quedará para otro que pueda tener dudas en el futuro.

Saludos!
-
Leonardo Garberoglio

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: POV esferico Terrestre
« Respuesta #6 en: 07 de Abril de 2015, 14:04:23 »
Citar
Tratá de encender una linea en un lugar fijo y luego ve avanzando. Si te parece, comparte el código para que veamos por donde vas y el esquemático del circuito para saber que estas haciendo, igual si tenes alguna foto o algo. De paso quedará para otro que pueda tener dudas en el futuro.

+1
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado rafaelrg06

  • PIC12
  • **
  • Mensajes: 54
Re: POV esferico Terrestre
« Respuesta #7 en: 07 de Abril de 2015, 19:54:14 »
Hola amigos, en especial mis agradecimientos a juaperser1 y elgarber:
Les agradezco sus recomendaciones y consejos, les aseguro que ya he rediseñado la “hoja de ruta” de mi proyecto para hacer exactamente lo que ustedes me recomiendan: ir más paso a paso e ir probando las cosas una tras otra.
Bueno, inicialmente probé algunos módulos de software individualmente, pero al integrar todo empezaron los dolores de cabeza mayores…
Bueno, les voy a describir el circuito para que lo comprendan, de cualquier manera voy a adjuntar el código en .c (uso CCS 5.007 y proteus 7.8 sp2) y una imagen de la simulación en proteus, pero con la descripción pienso que se puede entender al menos la idea.
De manera general quiero hacer un reloj POV con 11 leds, que se alimente con un transformador rotatorio, es decir, sin contacto. Además, me gustaría implementar la posibilidad de que se alimente con una batería (en el propio reloj) que permita seguir contando el tiempo si falla la alimentación o si se desconecta por cualquier razón. Por último quisiera implementarle la configuración por infrarrojos, usando un control remoto de un televisor o cualquier otro. Creo que aunque se ve un poco “amplio” (por no decir ambicioso) es perfectamente posible implementarlo.
Tengo en mis manos un par de 16f628a y un 16f887, aunque ahora lo estoy simulando con un 16f648a (empecé con un 628a pero por falta de memoria ROM emigré temporalmente a un 648a para probar los módulos básicos hasta que grafique adecuadamente, y luego emigrar al 887 donde quiero hacer la implementación final). Un detalle es que estoy usando una velocidad de 8MHz, que es lo que brinda el 887 internamente sin necesidad de cuarzo. Para el control del reloj tengo pensado usar un cuarzo externo de 32768 Hz que también tengo a mano.
Los leds que uso son en general 11 de ellos uso los primeros 5 para el horario, hasta el #9 el minutero, el led #10 es el segundero (el segundero  enciende solo un led) y en la posición 11 pudiera ir uno o dos leds controlados por el mismo pin, cuya función sería dibujar un círculo alrededor del reloj.
Uso básicamente los 3 timers del PIC, el timer0 inicialmente quería usarlo con el watchdog, pero estoy pensando en cambiar su uso para controlar la señal del control remoto que configuraría el reloj (cambiar la hora, etc), pero verdaderamente la idea del control remoto llegó después que ya tenía el diseño un poco avanzado y aún no tengo muy clara la idea de cómo controlarlo ni que pin o mecanismo usar.
El timer1 lo uso básicamente como contador del cuarzo externo de 32768Hz para contar el tiempo y de esta manera controlar el tiempo, este timer de momento lo tengo configurado para que funcione como contador síncrono, pero en la versión final debería funcionar como contador asíncrono para que pueda seguir contando en modo sleep, en el caso en el que se desconecte la alimentación. Este timer también la uso como base de tiempo para calcular el tiempo que demora en dar una vuelta el motor del reloj –la velocidad- que es la base para calcular el tiempo de encendido/apagado de los leds en su recorrido circular.
El timer2 es el que uso para controlar el tiempo de encendido y apagado de los leds, además del tiempo de estabilización del reloj cuando se enciende el equipo y aún el motor no ha llegado  a una velocidad que permita graficar.
La programación la desarrollé por modos de funcionamiento, el modo 1 sería el modo de arranque, el 2 el de funcionamiento “normal”, es decir, graficado automático y continuo del tiempo. Hasta ahora he llegado hasta el modo 2, pero tengo pensado implementar de esta manera otros modos que sean el de configuración, el modo sleep (cuando funciona con baterías, solo contando el tiempo), entre otros.
La idea que he implementado para el algoritmo es: usar la interrupción por RB0 para detectar el cruce por el valor de referencia (usando un sensor infrarrojo) este sensor se mediría al menos 2 veces –la primera vez, luego con una sola medición sería suficiente, ya que se compararía con el penúltimo valor medido-  y a partir de ahí se desarrollan todos los cálculos que permitirían obtener al final el tiempo que deben estar encendidos los leds (el equivalente al diámetro de los leds), y el tiempo que deben estar apagados (que sería el tiempo de 1 segmento –el reloj contiene 60 segmentos y son por lo general mayores que 3 ó 5mm que es el diámetro del los leds que pienso emplear-).
Las fórmulas para el graficado que empleo son:
•   Perímetro: 2 * pi * radio en micrómetros
•   Tiempo de una vuelta (Tv): medición directa que hago usando el timer1
•   Tiempo de 1 segmento (Ts):  Tv/60
•   Velocidad del motor (v): perímetro/Tv
•   Tiempo de encendido de leds: diámetro de leds en micrómetros –equivalente a la distancia que debe recorrer dicho led-/velocidad (en microsegundos)
•   Tiempo de apagado de leds (Toff):  Ts-Ton
El tiempo de una vuelta lo hago leyendo y guardando el valor del timer1 y comparándolo con el valor del próximo pulso de RB0 y multiplicándolo por 30 (tiempo aproximado en microsegundos que tarda entre un valor y el siguiente del cuarzo externo a 32768 Hz).
En el algoritmo, el timer1 “correría libremente” y lo leería “eventualmente al menos una vez por vuelta para revisar si ha transcurrido o no un segundo (de 0 a 32767 sería un segundo, y de 32768 a 35563 el otro segundo). Según los cálculos, 1 segundo transcurriría cada varias vueltas.
Para optimizar al máximo la velocidad de la cpu (que sería 8 MHz) estoy implementando un algoritmo en el cual el pic está calculando el valor de Ton y Toff desde que se obtiene el último valor medido por el sensor de posición de referencia (sensor infrarrojo) y este cálculo es interrumpido por el timer2, el cual en cada interrupción primero enciende los leds –si debe encender alguno- y en su propia interrupción cambia el valor de carga del timer 2 (registro PR2) para que interrumpa ahora durante el tiempo Toff. Luego interrumpe en el nuevo valor cargado (Toff) y la función apaga los leds y carga el registro PR2 con el valor Ton y así sucesivamente. De este modo el cálculo de los valores Ton y Toff estaría en “segundo plano”  y la interrupción del graficado de los leds estaría en “primer plano” ejecutándose cada cierto tiempo.
 De esta manera, cuando se termina de hacer el cálculo del nuevo Ton y Toff correspondiente a la última lectura se guardan los valores en variables temporales hasta que se active la interrupción por Rb0 nuevamente. Una vez activa la interrupción por RB0 se asignan los valores temporales de Ton y Toff a sus variables definitivas, y comienza un nuevo ciclo –correspondiente a una nueva vuelta-. Todo lo anterior sería lo que debe hacer el  PIC en 1 vuelta, en el modo “normal” de trabajo.
El cálculo incluye “filtrar” los pulsos para verificar si el motor está girando dentro de las velocidades precalculadas que debería permitir graficar adecuadamente. La idea es que los leds no enciendan si el motor está por debajo de 12 fps o por encima de 70 fps, aunque la velocidad máxima del motor que el sistema pueda graficar habría que medirla en la práctica y depende de la velocidad a la que esté corriendo el pic, con 8MHz estoy simulando unos 41.6667 fps, lo que serían unas 2500 RPM del motor y creo que alcanza perfectamente.
Voy a adjuntar el código y una imagen del proteus junto a la simulación. Cabe notar que use un generador de señales para simular el cuarzo externo de 32768 Hz (puse un cuarzo y no funcionó), y lo mismo hice para simular la interrupción por RB0, en este segundo caso la frecuencia es la misma que debería interrumpir si el motor gira a una velocidad de 2500 RPm ó 41.667 Hz.
Espero sus sugerencias.
« Última modificación: 08 de Abril de 2015, 09:16:06 por rafaelrg06 »

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: POV esferico Terrestre
« Respuesta #8 en: 08 de Abril de 2015, 04:10:11 »
Creo que quieres abarcar demasiado, sin ir probando, es solo un consejo.

creo que deberías guardar todo lo que tienes, que es mucho y bastante complejo por lo que veo y empezar, de 0 pero con los problemas mucho mas divididos, ir solucionandolos 1 a 1 y luego sumarlos.
Ahora mismo los tienes todo, y encontrar lo que no te funciona correctamente o lo que quieres que funcione mejor va a ser misión imposible, por que al tocar una cosa estaras cambiando otra.

de todas formas, te aconsejo que dejes un poco de lado proteus y te pongas antes de ponerte con el software que te pongas con el hardware. una cosa importante que hay que recordar es:

EL HARDWARE NUNCA DEBE ADAPTARSE AL SOFTWARE SI NO AL CONTRARIO, otra cosa es que hagas el hardware pensando en que la programación sea mas fácil después.

¿por que te digo que empieces por el hardware? vas a tener problemas que no esperas, por ejemplo en la mecánica, vas a tener muchos problemas de que te vibre el aparato entero ya que estas metiendo la masa de los led y descompensando el peso del disco que gira. por eso te lo recomiendo una vez que tengas el sistema y el hardware depurado, puedes empezar a trabajar en el softwara totalmente tranquilo y probando las cosas de verdad y no en el proteus (no me gusta nada emular las cosas sinceramente). aqui te podemos ayudar con el hardware y el rutado aprovecha  ;-) ;-).

por otro lado, por si tienes pensado ponerle un reloj en tiempo real la batería es obligada o tendras que actualizar el reloj cada vez que quieras encenderlo, ten en cuenta tambien que si tu pov va a tener un uso continuado y de muchas horas de funcionamiento, debes buscar un motor Brushless ya que si no las escobillas se desgastaran pronto. y si quieres ponerle comunicaciones, por que no te vas a un micro un poco mas potente un 18 por ejemplo de precio son similares y alcanzaras mayores frecuencias, por otro lado yo le pondría un cuarzo, te da una frecuencia mas estable y tu hardware sera mucho mas preciso.

y por ultimo y como consejo te recomiendo que vayas migrando de ccs, precisamente el POV me dio muchisimos problemas por culpa de los bug de ccs y me ocupaba muchas mas memoria a raiz de este proyecto( que fue uno de mis primeros ) me olvide de ccs.

un saludo
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw

Desconectado elgarbe

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 2178
Re: POV esferico Terrestre
« Respuesta #9 en: 08 de Abril de 2015, 07:32:42 »
Tengo que leer bien todo lo que pusiste, pero en principio no me cierra usar el uC a 8MHz para poner un xtal de 32.728 y tener buen control de la hora. Yo pondría un xtal de 20MHz para tener toda la velocidad del micro disponible y para llevar la hora tenes que usar un RTC tipo BQ32000, con él y una pilita podes llevar la hora y fecha sin problemas. El POV del ante año pasado, que hicimos con otro grupo de alumnos, era del tipo circular como el que tu quieres hacer y para llevar la hora lo hacía internamente, sin preocuparme por los mseg que se desfasaba con el paso del tiempo...

sds.
-
Leonardo Garberoglio

Desconectado rafaelrg06

  • PIC12
  • **
  • Mensajes: 54
Re: POV esferico Terrestre
« Respuesta #10 en: 08 de Abril de 2015, 15:14:43 »
Hola amigos:
Muchísimas gracias a elgarbe por cederme su librería para revisar su proyecto, estoy revisando el código y la verdad me ha gustado mucho su forma de trabajo. Gracias nuevamente.
Bueno, ya empecé el diseño del hardware para montarlo antes posible en el 887. Voy a hacer todo el hardware físico, y después depuraré el software. El software yo lo comencé por pequeños bloque que fui probando aparte y después lo integré todo, creo que sería una buena idea volver a revisar los diferentes bloques de software y actualizarlos para detectar posibles errores.
Revisando las sugerencias que me han dado encontré algunas dificultades: emigrar a un pic 18 creo que no me va a ser posible en este momento, lo mejor que puedo hacer para aumentar la potencia es optar por un cuarzo externo de 20MHz pero siempre en el 16f887 que es el micro que tengo a disposición, aún así creo que este uC  podría implementar adecuadamente este proyecto.
Lo otro que me resulta imposible es el RTC externo, porque no tengo el RTC ni posibilidades de obtenerlo a corto plazo. Pero creo que no es mala idea usar un segundo cuarzo externo para contar el tiempo. Lo que no entiendo es ¿por qué es necesario subir la velocidad del uC para leer el cuarzo externo? Leí en un post que un amigo incluso había calibrado el reloj interno del PIC y construyó un reloj sin usar siquiera el cuarzo externo y el retraso era de 1 segundo cada 3 días, aunque estuve buscando y no lo he hallado para referenciarlo (el post).
En cuanto al CCS y proteus, bueno, los he usado desde siempre, pero me gustaría saber que programas me recomiendas  para sustituirlos (juaperser1).
Por otro lado la batería va obligatoriamente, tengo en mente usar una CR2030 que es de 3v (las que usan las computadoras), y usar un pin que detecta automáticamente cuando se pierda la energía en la fuente y automáticamente cambiar al modo sleep y quedarse en ese modo hasta que retorne la alimentación. Cuando se usa en el modo de baterías obviamente es porque el motor está detenido, y el circuito solamente se mantiene contando el tiempo (no enciende leds ni atiende otra cosa que no sea el timer1 en modo sleep).
Un detalle muy importante y que estoy listo para compartir: he resuelto el asunto de la alimentación inalámbrica del circuito en movimiento usando un motor brushless (de los que usan las PC en el chasis). Si les interesa (elgarbe) solo avisa!!!!
Montaré todo y les seguiré comentando que tal me va.
Un saludo grande!!!!... y cualquier otra sugerencia estará bien recibida

Desconectado juaperser1

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 2979
Re: POV esferico Terrestre
« Respuesta #11 en: 08 de Abril de 2015, 17:10:19 »
Citar
Pero creo que no es mala idea usar un segundo cuarzo externo para contar el tiempo. Lo que no entiendo es ¿por qué es necesario subir la velocidad del uC para leer el cuarzo externo?

No es que lo necesites obligatoriamente, pero un cuarzo externo te da una frecuencia mucho mas estable que uno interno, es por esta razón por ejemplo que cuando tienes un USB  en el micro necesitas un cuarzo externo, por lo tanto cambiar el cuarzo ya no es por aumentar la potencia si no la estabilidad en tu frecuencia.

Citar
o otro que me resulta imposible es el RTC externo, porque no tengo el RTC ni posibilidades de obtenerlo a corto plazo.

Sabes que hay microcontroladores con RTC interno, reduciendo así tus componentes externos, microchips tiene entre sus filas algunos de estos, yo trabajo mucho por ejemplo con el PIC32MX250 que trae RTC interno.

el 16F887 seguro te sirve para la aplicación, no quiero decir lo contrario, ¿pero por que no puedes cambiarlo?

Citar
En cuanto al CCS y proteus, bueno, los he usado desde siempre, pero me gustaría saber que programas me recomiendas  para sustituirlos (juaperser1).

Pues mira claramente para sustituir al CCS, el IDE MPLAB X y el compilador XC8, te permite programar el micro que quieres en C y tendrás un control muchísimo mayor que con CCS, ademas de que si le sumas la pickit3 por ejemplo tienes el debug bastante barato. Se que es una pereza cambiar CCS por otra cosa, pero no te vas a arrepentir.

para proteus, como simulador y para hacerte una idea esta bien, pero la realidad dicta mucho de lo que es un emulador. Por eso te aconseje que hicieras el hardware y la mecanica, ya que no hay mejor emulador que el hardware en si.

Si tienes algún problema con el hardware, el rutado o algún componente a usar postealo y te intentare ayudar.
Visita mi canal para aprender sobre electrónica y programación:

https://www.youtube.com/channel/UCxOYHcAMLCVEtZEvGgPQ6Vw


 

anything