Hola disculpen la demora, pero estoy a full con el laburo.
Carlos, podrá ser debido a que cambiaste de familia el microcontrolador? Un 16F @ 20Mhz es bastante mas lento que un 18F @ 48Mhz. Igualmente creo que el programa es bastante sencillo como para que se devore los mS entre desbordamientos del Timer0.
No llego bien a detectar el problema por lo que me comentas. Por lo que mencionás parecería que hay un desfasaje en el valor que se carga en el registro de desplazamiento asociado a las filas de tu circuito. A veces hay problemas con las demoras que necesitan los registros. Bien hiciste en agregar un delay al strobe. Podrías agregrle un delay entre la subida del clock y la bajada del mísmo también, por las dudas.
Hace muchos años que trabajo con matrices y LEDs. Hace unos meses tuve un problema desarrollando un prototipo para unos paneles RGB que comercializamos, que puede ser el que se te está presentando. La distancia entre las salidas del uC y el primer 74HC595 era bastante grande(mayor a 1 metro). A esa distancia, teniamos el problema de que alguno de los 595 se robaba un dato. Algo muy loco, pero real. Si ese es también tu caso, entonces el comportamiento sería algo como lo que mencionás según lo que imagino. Obviamente la pérdida de ese dato haria no solo que se te desfase todo una fila, sino también en una columna, lo que puede pasar desapercibido porque un error de sólo una columna puede no ser visible excepto pongas algo que controles muy bien en la matriz y sepas exáctamente dónde debe aparecer y dónde no. Recordemos también que las señales de CLOCK y STROBE se comparten entre todos los 595, por lo que el PIC debe suministrar suficiente corriente para alimentar a todos, por lo que siempre hay que intentar mantener al mínimo la distancia total de esas líneas, y además, minimizar la cantidad de soldaduras en las mísmas.
Podrías adjuntar las modificaciones que hiciste para solucionarlo?
Menta, el primer cartel comercial que hice hace varios años trabajaba directamente sobre un puñado de mapas de bits, que eran generados directamente en un software que hice de PC.... Estaba todo bárbaro, pero el tamaño de los archivos generados se incrementaba significativamente. Si bien este código sólo posee implementación para trabajar con caracteres de texto, nada impide que un comando, a futuro, cambie su comportamiento a un modo gráfico, que permita directamente dibujar una trama de bits. En realidad la diferencia, si bien es algo técnica, puede que termine siendo más sobre gustos y diseño que otra cosa...
Por otro lado, a lo largo de estos meses existen varias personas que ya han fabricado matrices con este aporte, incluso le han agregado cosas y mejoras pero siempre se han comunicado por privado conmigo por algun que otro detalle que les fallaba y los ayudé a solucionarlos, y pese a mis reiterados intentos(y sus reiteradas promesas) de que compartieran los aportes, no lo han hecho.
Así que te agradezco doblemente: primero por interesarte y tomarte el tiempo de leer el hilo y mi código(+ los elogios
), y segundo por compartir una mejora que puede servir a otros.
P.D: No te elegiste un efecto realmente sencillo para empezar...Igualmente, hacer efectos en una matriz realmente no es de lo más sencillo. Hay que manipular muy bien el tema de trabajar con bits, rotaciones y operaciones lógicas para lograr efectos complejos en poco tiempo de ejecución. El tema de escribir la cadena a mostrar de derecha a izquierda al reves no me parece realmente incorrecto. Me parece una implementación sencilla de realizar para un programa de PC que debería ser el encargado de acomodar un mensaje al lenguaje que el uC entienda. De fondo a todo esto, la verdadera complejidad surje cuando querés dotar a un pasamensajes de propiedades un poco más avanzadas, y tener que revisar hacia adelante dónde termina la cadena para poder invertirla, puede ser imposible de implementar en ciertos casos donde los datos no estén disponibles todos juntos, sin que llegan a medida que van siendo necesarios.
Un saludo.
