Estuve revisando el código generado por el editor EVE para el manejo de slots de memoria en FT8XX. Para cargar dos imágenes jpg de 64x64 px, ésta es la secuencia:
El editor EVE exporta las imágenes para que se puedan cargar sin usar un lector externo, tomando como base la librería base del gameduino 2 (GD2, FT80X); cabe destacar que podemos usar el código resultante en las librerías para FT81X: GD3 o GD3_SDIO.
Para que el sketch previo funcione hay que incluir en su carpeta los archivos exportados L00.h y L01.h.
El código equivalente para cargar las imágenes desde el lector SD es:
Dado que en el @equipo_FT81X, hemos versado mucho en el tema del manejo del lector SDIO incluido en el Teensy 3.X, opté por ampliar provisionalmente una linea paralela de ejemplos enfocados a Teensy 3.X.
Gracias RndMnkIII por todo el soporte que nos has brindado con el tema del Teensy.
Debo confesar que me faltan horas de estudio para el manejo de las prestaciones de SDIO del teensy 3.6; que se han incorporado a GD3; es por ello que incluí en la familia a GD3_SDIO, con la idea de agregar poco a poco ejemplos particulares para estas excelentes placas.
Mas adelante ya que tengamos una buena compilación de ejemplos, creo que será factible unificar ambas lineas de experimentación.
Versión mas reciente
9 de Febrero 2017: adición de la libreria GD3_SDIO enfocada al uso del lector SDIO del Teensy 3.X
Adición de un logo de alerta en la pantalla de error (sin que se tenga instalado un lector SD)
Se incluyen nuevamente las librerías gameduino 2 y GD2, ajustadas para el shield-Arduino de RIverdi.
PD: es posible que existan errores en los ejemplos incluidos, he estado muy ocupado con el trabajo, en cuanto disponga de un tiempo libre razonable, daré una revisión a los ejemplos: paciencia.
Tube problemas a la hora de compilar tu ejemplo dos imagenes JPG en array y encontré la solución
El problema es al exportar el script del editor FTDI EVE en la librería GD2, el IDE de Arduino 1.0.5 o superior no usa el termino;
static const PROGMEM prog_uchar
Sino este;
const unsigned char
Por lo tanto el código resultante es este adaptado a mi pantalla de HotMCU;
A todo esto, adjunto el código completo y por cierto en este mismo foro, le posó tambien a un usuario este enlace
Me interesa muchisimo esta forma de representar varias imagenes sin usar el lector microSD para mi proyecto MDC v1.0
Voy a tratar de modificar el script ditado para cuando exporte no de problemas. Luego lo adjuntaré por si alguno le hace falta.
Solucionado el script de Python modificado por mi donde ya se exporta correctamente el array de las imagenes.
En la carpeta donde se instaló el FTDI EVE Editor, se tiene que borrar el fichero llamado; Export GameDuino2 Project.pyc y sobreescribir el fichero que adjunto.
EDITO
Este "parche" es solo para la version del Editor FTDI EVE Screen Editor v 1.17 . Si TFTLCDCyc lo desea compartir, porque el fue quien me paso el mismo. No se si esta en la pagina ofical, de lo contrario que mi amigo determine el mismo si lo comparte.
Vendrá bien esa corrección para quien tenga ese detalle con la definición. Pensé que había guardado el proyecto EVE con dos logos, pero al parecer no lo hice, solo extraje los archivos h y copié el código directamente en el IDE de arduino y allí guardé el ejemplo. Sin embargo te dejo un proyecto con tres imágenes, semejante al del ejemplo, sin usar el lector SD.
TFTLCDCyg:
PD: ¿por cierto esa falla se presenta en el ejemplo del pantallazo de error con logo de la última versión de GD3?
No. Porque el error da al compilar el código y no lo sube a la placa.
Con el editor EVE me he dado cuenta y se confirma despues de algunas pruebas realizadas, al menos por mi e inclusive en un mensaje anterior mio de este hilo puse que se podría poner muchas imagenes. Es una realidad. Me explico.
Si tenemos una imagen en una posición GD.Vertex2ii(416, 206); siempre que usemosla misma posición podremos poner cientos de ellas, nunca se veran juntas si no cuando lo deseemos, Ahora de esta forma incluso se podrá hacer una pequeña animación...
Es mas sencillo usar la carga de una imagen directamente desde la microSD, sin embargo es tambien muy interesante dependiendo de nuestro proyecto y codigo usar la flash de la MCU para almacenar iconos pequeños en esta ultima. Si usamos el modelo Arduino MEGA opviamente en adelante. No recomiendo para nada modelo UNO el cual ya lo he descartado totalmente para estas pantallas.
Estas semanas han sido alucinantes con el tema del teensy 3.6 y su lector SDIO.
Además, la herramienta FTDI EVE screen editor (en su versión 1.17) ha resultado de gran ayuda para generar imágenes que podemos usar dentro de la librería sin hacer uso de un lector SD.
Este aspecto abre muchas posibilidades para quienes no se deseen aventurar con la instalación de un lector externo en sus arreglos, reduciendo cableado y "fallas inoportunas" causadas por un hilo defectuoso, un shield difícil de encontrar o bien una memoria SD dañada.
Claramente estamos limitados a placas que se pueden programar con el IDE de arduino que cuenten con el suficiente espacio de memoria de programación. Como ha señalado ligthcalamar, las placas como el UNO, NANO, MINI se van a quedar cortas de espacio de programación.
Definitivamente para diseños con espacios muy reducidos, sugiero usar MCU como la teensy 3.5 o la 3.6, ya que estamos en posibilidad de extraer todo el potencial de las pantallas FT8XX y disponemos de un extra: el lector SDIO que tienen estas placas.
Las adiciones en la versión consisten en:
La inserción de imágenes en las pantallas de error y de calibración de la pantalla táctil, sin hacer uso de un lector SD. Estas mejoras se han incorporado a las librerías base gameduino2 y GD2, así como en GD3 y la versión especializada para placas teensy 3.5/3.6: GD3_SDIO.
Reorganización de ejemplos e inserción de nuevos (trabajo en proceso...).
La librería gameduino2 llama a las cabeceras como GMD2, en lugar de GD2, con esto podemos usar ambas librerías sin que interfieran entre sí en el IDE de arduino.
En las librerías GD3 y GD3_SDIO, los avisos de error y de calibración se ajustan a la rotación base de trabajo seleccionada en el archivo .ccp correspondiente.
Aviso de calibración en GD3/GD3_SDIO (rotación 0):
Inclusión de una instrucción que permite ajustar manualmente en GD3_SDIO.ccp, la frecuencia de trabajo SPI, dependiendo de la longitud del cable plano usado como interface para la pantalla (LFFC):
En los experimentos realizados por RndMnkIII él optó por usar un cable plano de 5 cm de largo, armando un sistema que puede funcionar al tope de velocidad (FT813 de 7" con un teensy 3.6). El cable que acompaña al shield de Riverdi o a las pantallas FT8XX de Riverdi, es de 15 cms, alcanzando un 86.6% de la tasa de transferencia SPI.
Como hemos visto, la longitud del cableado afecta la señales SPI, a menor longitud, mayores frecuencias podrán emplearse para comunicar al MCU con la pantalla. Hay que vigilar este aspecto siempre para descartar fallas aleatorias.
El usar el GD.BITMAP_LAYOUT no es otra que se puede desde una imagen, inclusive en array tomar "celdas" de diferentes imagenes dentro de una misma.
Aqui adjuntado el nuevo Script para Python del EVE Editor.
Saludos.
Tenemos una límitante con el número de imágenes que podemos manejar de forma simultánea en la memoria de los chips FT8XX, podemos usar varias técnicas para superar esta condición, pero en ocasiones tendremos mas de 16 imágenes con las que desearíamos contar, sin tener que cargar nuevos grupos en cada ocasión.
Adicionalmente lo podemos conseguir sin usar el lector SD.
Partiendo de la respuesta que nos compartió James en el foro del gameduino 2, en la que indica como cargar los assets luego de procesarlos con la herramienta gd2asset.exe
La usé como punto de partida para extender su aplicación de 2 a 20 iconos de 64x64. Los pasos a seguir son:
1 Crear un archivo base con las imágenes en arreglo vertical. Los iconos que vamos a anexar son de 64x64 px, por lo que el ancho de la imagen base debe ser de 64 px. La altura es un múltiplo de 64, dependiendo del numero de iconos a insertar en la fila.
En el experimento logré insertar 20 iconos, dando una altura de 20 x 64 = 1280 px. El archivo lo llamé I20.jpg
2 Crear el archivo con extensión .h con ayuda de la herramienta gd2asset.exe, desde la linea de comandos (CMD.exe), en el ejemplo lo llamé icx.h
En total el asset dispone de 20 celdas dentro de la primer posición de manejo de imagenes (0), queda experimentar la posibilidad de almacenar en los slots de memoria restantes, imagenes normales.
He intentado cargar un segundo grupo de sprites en el slot 1, pero parece que afecta slot 0 y al usar GD.Vertex2ii(325, 410, 0, 19); GD.Vertex2ii(325, 410, 1, 19); el resultado en pantalla no es el correcto.
Ésta técnica de manejo de múltiples imágenes en un solo archivo, se le llama "manejo de sprites"
Pues se de tu esfuerzo TFTLCDCyg, pero cuando veas mi nuevo mensaje en el foro de James ya te puedes morir ...
esto es lo que buscaba yo y creo que hasta tu...
Es decir, ya lo tenemos TODO.
Lllevo con este tema muy atascado, otra cosa es pasar el fichero a gd2 en microSD que será lo mas importante y esto lo mas encillo
Es decir definir los Handles de las imagenes convertidas ...
Comprobado y funciona.
Es decir en el fichero cabecera .h nos pone los diferentes "XXX_HANDLE" ...
Otra cosa es experiementar desde 16 Handles por 16 imagenes que son 256 ....
Saludos Tomas.
/* EDITO */
Por ejemplo no se si crear dentro del fichero .h otro de iconos de 32x32, seria otra imagen dentro y luego hacer esto por ejemplo;
Vaya así de simple!. Te digo: mas secretos..., eso no aparece en la librería GD2 y vaya que la he leído infinidad de veces.
Gracias por abrir el post en el foro de James. Me da gusto que por fin hayas solucionado ese "detallito", lo digo así, puesto que la solución estaba allí, y es muy simple... estaba en las mismas instrucciones que tantas vueltas les hemos dado.
Parece entonces que la herramienta para windows en efecto si tiene ese potencial. Experimentaré con mas arreglos de imágenes.
La duda que me queda es si es posible usar una imagen de fondo en conjunto con los sprites, tal como está el ejemplo "nightstrike" que viene en la librería.
Creo que con el tema de pasar al lector SDIO (felicidades por tu Teensy 3.5, pero... ya debes dormir menos que antes jejejeje), RndMnkIII nos podría dar una orientación ya que el domina el tema.
Trataré de crear un ejemplo con la respuesta que nos ha brindado James, estará incluido en la siguiente revisión de las librerías.
TFTLCDCyg:
Vaya así de simple!. Te digo: mas secretos..., eso no aparece en la librería GD2 y vaya que la he leído infinidad de veces.
jejejeje ,pues aunque no lo creas despues de leerme bastantes veces el book de James he realizado un curso intensivo de Ingles, ahora me voy enterando mas.
Bueno he realizado las pruebas, y escribo que es totalmente funcional. He usado iconos del tamaño 32x32, 64x64, 70x50 el problema no son las dimensiones sino de como se tiene que lograr realizar el "split" (dividir) las celdas de los mismo. En esta ocasión he usado 27 iconos. Con gd2asset:
Osea que sobra y estoy a menos del 50% de la RAM para FT800 !!!! Genial entonces...
Las pruebas las he realizado con mi FT811 averiada del tactil por esto.
He de comentar que lo he realizado para un fichero .gd2 ( opción -f y no -o ) para no engordar la skets de trabajo y dejar el codigo mas limpio. En fin se puede hacerde ambas formas y no influiria el resultado, salvo que entonces inflamos la flash de la MCU. A libre elección.
Tambien en mensajes anterior escribí que con una condicional if en una zona de la pantalla (yo le llamo zona de batalla) se pueden subir con GD.cmd_loadimage() las que se desee porque estas siempre modificaran la misma zona. Para una imagen de 64x64 son unos 8k de RAM (bien!!!) hay espacio mas que suficiente.
Resumiendo y lo mas importante: usando esta tecnica de sprites las FT(xx cobran una vida tridimensional con imagenes ..
Adjunto las imagenes del mismo.
Saludos!
Sin embargo, despues de pruebas lo he realizado a la funcion GD.cmd_number para el mismo efecto.
Donde le llamo blockNum2() por tener dos pixels alrededor del numero, se puede hacer otra por ejemplo llamada blockNum1(), para solo un pixel ...
Vean el código para dos pixels ( blockNum2() );
static void blockNum2(int x, int y, byte font, int a)
{
GD.SaveContext();
GD.ColorRGB(BLACK);
GD.cmd_number(x-2, y-2, font, 0, a);
GD.cmd_number(x+2, y-2, font, 0, a);
GD.cmd_number(x-2, y+2, font, 0, a);
GD.cmd_number(x+2, y+2, font, 0, a);
GD.RestoreContext();
GD.cmd_number(x, y, font, 0, a);
}
PD: éstos días si que han estado movidos con el trabajo, espero ya pronto disponer de algún tiempo libre para corregir fallos en los ejemplos y adicionar más.
Metaconta:
¿No es más fácil y barato usar una tablet con Android y comunicarlo por USB con Arduino UNO?
Wow no, es totalmente diferente.
Usamos un MCU nativo con su pantalla y librería, donde se puede programar cualquier dispositivo dentro de los rangos sea Arduino MEGA o Teensy, etc ... Con Android tienes un sistema operativo Linux, aunque pueda controlar a traves de Arduino, luego vendría la aplicación del mismo. Sería otro mundo
El usar este tipo de pantallas, a mi modo de ver es porque son las mejores al día de este mensaje mio de programar en esta plataforma. No hay otras que las superen. No solo por su enorme potencial, ademas siempre te sorprende su voracidaz de hacer muchas cosas. Sin embargo son algo problematicas en un primer contacto. Lo mas importante es tener mas funciones en librería para que realice infinidad de comandos visuales.
Y es cierto, un hobby y proyectos caros con estas pantallas FT8xx, pero a veces, el precio no es en sí, es mas sin duda un factor secundario cuando las tienes en tus manos realizando sofisticadas recreaciciones, y esto no tiene precio alguno.
Al recurrir a una R-Pi dentro de la ecuación, estaríamos introduciendo una segunda PC para programar lo que ya podemos programar con la primer PC.
Pronto nos quedaríamos limitados al soporte que podría darnos la R-Pi con el tema de hardware y software, sin olvidar las librerías tan escasas y el poco soporte que han dado los fabricantes a estas increíbles pantallas.
Hemos batallado mucho para compartir una librería 100% funcional partiendo de GD2 (la librería para el gameduino 2), por lo visto a medida que hemos caminado con ella, no alcanzamos a conocerla por completo.
Los chips FT81X son bastante quisquillosos con el tema de SPI y su programación es bastante caprichosa.
Estas pantallas son lo mas eficiente que he visto para trabajar en el IDE de arduino y por lo que hemos visto con plataformas mas veloces como el Teensy 3.2, Teensy 3.5 o Teensy 3.6, disponemos de prestaciones inigualables.
Conseguí un segundo Teensy 3.6, habilité la librería GD3_SDIO para experimentar con el lector SDIO con la pantalla FT801, de acuerdo a las pruebas que he podido hacer, la velocidad de carga de imágenes está limitada por el propio chip FT801.
Por cierto este chip en particular no puede manejar imágenes png, quizás por algún tema de construcción de la propia pantalla. La pantalla gameduino 2 si que puede manejar este tipo de imágenes. Trataré de averiguar mas al respecto, quizás estoy pasando por alto alguna configuración de hardware dentro de librería GD3_SDIO.
Importante: eliminar las librerías GDX previas, con el fin de evitar errores de compilación por duplicidad de librerías.
Es un proyecto en proceso y como tal, aún pueden estar colados algunos errores, si los detectan en sus pruebas, por favor repórtenlos en el presente hilo con el fin de corregirlos y mejorar la calidad de la librería.
Modificaciones relevantes
Ajustes en los archivos núcleo de la librería: wiring.h, GDX.h y en GDX.ccp para que la asignación de pines de control, modelo de chip FT8XX, orientación de la pantalla sea lo mas simple posible y se controle desde la propia librería.
Ya no es necesario usar una instrucción en el setup del sketch para establecer la orientación de la pantalla, aunque para efectos de diseño se puede incluir. En el archivo GDX.h de cada variante de librería, dentro del encabezado, está definida la variable que controla la orientación de la pantalla
Para FT80X, con GD2 y GD2_SDIO:
#define ORIENTACION 0 //0, 1
Para FT81X, con GD3 y GD3_SDIO:
#define ORIENTACION 0 //0, 1, 3, 4
Reorganización de los ejemplos de manejo de cada variante con el fin de que sea mas sencillo aprender a usar la librería en sus diferentes versiones.
Esta versión GDX incluye dos variantes (GD2_SDIO y GD3_SDIO) que permiten el uso del lector SDIO de las placas teensy 3.5 y 3.6, con la idea de aprovechar las prestaciones de ese lector microSD.
Las versiones para arduino, que dicho sea de paso funcionan sin problemas en las placas teensy 3.X, son GD2 y GD3, funcionan con un lector externo de 3.3V. Se reestructuraron en su apartado de ejemplos con el fin de eliminar errores de compilación y facilitar adiciones futuras de demos y extras.
PD: lightcalamar, saludos amigo, he estado bastante liado con el trabajo; en la siguiente versión trataré de incluir los ajustes que se necesitan para activar las pantallas de HotMCU, con el fin de que ese ajuste se pueda conseguir desde la librería considerando los modelos específicos de ese fabricante.
