Librería gameduino 2 modificada para pantallas FT81X

Por cierto hace tiempo que llevo siguiendo LUNA sobre las FT800, ya sé que no viene al caso de este hilo pero me parece interesante.

Hola, he estado mirando el codigo de ejemplo para el EVE 2 y lo del video usa avi como formato contenedor de fotogramas jpg muy al estilo de las secuencias de video dr la PSX original q utilizaba motion jpeg. Estoy mirando a ver que formato utiliza exactamente y a partir de ahi ver como funciona el ejemplo de ellos por ejemplo en visual studio.

Leyendo codigo fuente de FT_App_PlayVideo.c parece ser q el formato es motion jpeg:

char *info[] = { "FT800 Play Video Application",

				"APP to demonstrate video playback,",
				"using mpjeg decode feature",
				"& fifo buffer."

En dicho archivo hay numerosos #if defined(ARDUINO_PLATFORM) para compilar codigo especifico como este fragmento:

/* Testing avi parser */
#if defined MSVC_PLATFORM | defined FT900_PLATFORM
/* Main entry point */
ft_int32_t main(ft_int32_t argc,ft_char8_t *argv[])
#endif
#if defined(ARDUINO_PLATFORM)||defined(MSVC_FT800EMU)
ft_void_t setup()
#endif
{

Esto lo estoy mirando desde el movil, mañana intentare ver si puedo compilar codigo del emulador en visual studio

En la Application Note AN_391 EVE Platform Guide, dice explicitamente que el ejemplo del reproductor de video solo esta disponible para la plataforma FT90x

Primeras pruebas funcionales de FT813 con Teensy 3.2

Todavia tengo problemas de estabilidad y me da error al intentar cargar assets de la tarjeta SD.

error al cargar assets con demo de la pecera

Antes que nada me alegra que por fin puedas ver que la pantalla está en linea!!!. Me agrada ese soporte hecho con piezas de lego.

Vayamos a las sugerencias:

Procura formatear la tarjeta SD cuando veas que salte un error que tenga que ver con carga de imágenes o de assets.

En el video de desplazamiento de texto saltan errores aleatorios, es una falla de estabilidad posiblemente asociada con la fuente de energía, tal parece que la pantalla de 7" demanda mas corriente de la que demanda la de 5".

Revisa nuevamente los puentes que usaste para hacer las conexiones entre el breakout-20 y el teensy 32.

PD: aunque hice pruebas con el teensy 32 y pensé que aun funcionaba, alguna de las lineas que usé como puente entre el lector SD y el teensy debe estar desoldado, la revisaré y trataré de ponerlo a punto nuevamente.

Hola, gracias x las sugerencias. La cuestion de la alimentación creo tenerla resuelta con la fuente de alimentación conmutada de 3.3v y 6A, de hecho cuando la conecto por USB unicamente para reprogramar la teensy y SIEMPRE desconectando antes de la fuente de alimentación, la pantalla si acaso se enciende x unos segundos y se apaga. Las dudas me surgen por el tema de las divisiones del cableado para comunicar tanto con la sd card como con la pantalla, no se si la asimetria en las longitudes del cableado puedan estar jugando una mala pasada, o simplemente sea como comentas una soldadura en falso, pues tampoco me considero un experto en el tema y puede q haya soldado en frio alguna. Tengo mis dudas respecto al lector sd casero, tendre q testearlo x separado a ver si puedo leer del mismo.

Saludos!

Recuerda que el lector externo debe ir a las mismas lineas SPI del TFT. Trata que las distancias de los puentes o cableado, sean lo mas corto posible.

Te sugiero que reconectes todo, hilo por hilo, no tendría que haber parpadeos extraños en las imágenes o texto. Empieza por el Hello world extremo: GD3_Logo_2.

Intenta con el demo FT81X_cicloJPG, lo diseñe justamente para estresar de forma segura el sistema MCU-FT81X. También FT81X_Rotacion puede servir para estresar al lector SD.

Es posible que algún asset no cargue y se generen fallos en pantalla, basta con cargar el sketch nuevamente.

Video: ejemplo de la pecera

Intenta conseguir algún lector comercial que funcione a 3.3 V, son bastante económicos y algunos tienden a fallar, te sugiero adquieras por lo menos unos 4 o 6 para entre ellos por lo menos esté uno que funcione al 100%. Recuerda que son de bajo presupuesto por lo que la calidad no será uniforme.

Por cierto, una de las desventajas del teensy es que al usar las lineas SDA/SCL, el chip principal no reinicia como debe al restablecer la energía de alimentación, tal parece que el dispositivo se "desincroniza" y afecta al procesador cortex.

En el proyecto tengo instalado un DS3231 en SDA/SCL, si dejo de alimentar el teensy y mantengo instalado el reloj, el conjunto no reinicia. Si desinstalo el DS3231, y reactivo la alimentación, el sistema carga el sketch normalmente.

Javier, le has puesto unos divisores de tensión en los pin´s SCK, MOSI Y CS?
esto concretamente,

https://drive.google.com/file/d/0By5wADoEOJ9fbHQ2WnVIaWZ4ekE/view?usp=sharing

https://drive.google.com/file/d/0By5wADoEOJ9fbHQ2WnVIaWZ4ekE/view?usp=sharing

Pantalla funcional al completo usando vertex2f:

Podrías subir el código para representar en Arduino MEGA?

Saludos.

Codigo demo plasma teensy 3.5/3.6:

Codigo demo plasma Arduino:

P.D.: sustituir llamada a vertex2ii por vertex2f((int)(x16), (int) (y16)) en la función draw()

Estoy pensando hacer otra version que utilice una libreria matematica de coma fija y de aproximación de funcion seno y raiz cuadrada para acelerar un poco la presentación en arduino mega, ya que la libreria matemática estandar utiliza datos con precisión double qie funciona más lento en dicha placa.

Wow!. Gracias por compartir el código, con ejemplos así, creo que GD4 está mas cerca de lo que pensaba XD.

Para conseguir que los círculos ocupen la pantalla completa, ¿que linea hay que modificar?

PD: espero algún día comprender las instrucciones escritas en esa función XD.

void draw(void)
{
  GD.Begin(POINTS);
 
  for(float32_t y = 0; y < SCREEN_HEIGHT; y+=32.0)//speed up by drawing interlaced half width screen
    for(float32_t x = 0; x < SCREEN_WIDTH; x+=32.0) //speed up by drawing interlaced half width screen
    {
      arm_sqrt_f32((x*x+y*y+timeAnim+1), &sqrtsums);
      color=int(128.0 + (128.0 * arm_sin_f32((x+timeAnim) * inv32)) +
                128.0 + (128.0 * arm_sin_f32((y-timeAnim) * inv8))  + 
                128.0 + (128.0 * arm_sin_f32((x+y+timeAnim) * inv16)) +
                128.0 + (128.0 * arm_sin_f32(sqrtsums * inv7)) )>>2; 
       GD.ColorRGB(color+color*256);
      //if ( (color > 120) && (color < 136))u8g2.drawPixel(x, y);
      GD.PointSize(color);
      GD.Vertex2ii((int)x,(int)y);
  }
}

Incluido en la siguiente actualización de la librería XD.

si sabes como funciona la funcion seno y como calcular la distancia entre dos puntos no tiene mucho misterio, lo demás es tener algo de sentido estético.

Yo todavía estoy en proceso de comprender la 'GD0' para ver como idearon la 'GD2', no estoy a ese nivel XD.

Simple y conciso, pero algún día me gustaría programar así de estético como le dices jejejeje, gracias por compartir el código.

PD: yo sigo liado con la optimización de las gráficas lineales y el trazo de elipses, tomaré ese ejemplo para reducir las lineas de código, por ahora mis recursos considero que son mas bien algo toscos.

la cuestion es que la FT esta limitada por el numero de comandos q puede ejecutar por linea de pantalla o eso he creido entender. Con esa limitación en mente por ejemplo si quiero dibujar un modelo 3d en malla de alambre tengo q ver como maximizar el numero de lineas q puedo dibujar en un momento dado, ya q voy a estar mas limitado x esto y no por la capacidad de la T3.5/3.6 para realizar los calculos