Algunos consejos para usar TFT´s

International Español Hardware
21

En lo que llega el shield sobre el que instalaré todos los componentes del controlador, he estado experimentando algunas variantes en las que podría usar el FT843 o la pantalla ILI9341 que usaré como pantalla secundaria.

FT800 en arduino MEGA
La versión mas reciente de la librería para el gameduino 2 funciona sin problemas en el arduino Due, también funciona en el MEGA, en el Teensy 3.2 y me parece que en el Rasberri Pi.

Por consiguiente el FT843 podría funcionar en esas placas mediante la librería GD2, con los ajustes adecuados para que los parámetros de inicialización correspondan a los del gameduino 2.

El diseño del gameduino 2 corresponde a un shield para arduino UNO. La librería tiene algunos ajustes para funcionar directamente sobre el arduino Due, para que funcione en el MEGA hay que hacer algunos ajustes en el hardware, se deben unir los pines 51 a 11 (MOSI), 50 a 12 (MISO) y 52 a 13 (SCK). Hay dos posibilidades para conseguirlo: unirlos mediante cableado o bien construir un shield, intercalando un dip switch-3, con la finalidad de desconectar las uniones cuando no se use la pantalla FT800.

742×450 49.5 KB

742×450 50.8 KB

Dos pantallas ILI9341 en Teensy 3.2
Aparentemente el Due, el Mega o el Uno, pueden manejar dos pantallas ILI9341 al mismo tiempo, mostrando información distinta en cada una de ellas. En las pruebas que hice experimenté en el arduino UNO, pero estaba el problema de la memoria, tenía muy poca disponible y no me permitió avanzar. En el MEGA resultó muy lento el control de las dos pantallas, las entradas táctiles no funcionan correctamente

El Due lo quiero para controlar el gameduino 2, si instalo una segunda pantalla como la ILI9341 de 2.4", el GD2 deja de funcionar.

Construí un shield para experimentar con el teensy 3.2 que llegó hace un par de semanas. En una de las caras, el shield permite conectar directamente el gameduino 2; en la otra cara, permite instalar una pantalla ILI9341 de 2.2", 2.4" o de 2.8".

766×468 51.1 KB

804×475 47.3 KB

El árbol de conexionado que usé es el siguiente:

ILI9341            Teensy 3.2
VCC                   VIN
GND                   GND
CS                     10
RESET                3.3V
D/C                     9
SDI (MOSI)             11
SCK                    13
LED                   VIN    (resistencia de 100 ohms)
SD0(MISO)              12
T_CLK                   6
T_CS                    5
T_DIN                   4
T_DO                    3
T_IRQ                   2

La librería para usar el panel táctil es la Utouch.

El problema que encontré es que el lector SD de la pantalla ILI9341 no funciona al usarlo en el teensy. Aparentemente hay que modificar el circuito puenteando las resistencias smd que se ubican bajo la carcasa del lector SD, hice algunas pruebas y no conseguí hacerlo funcionar.

Decidí instalar uno de los lectores micro SD que conseguí para el FT843, funcionan de forma nativa a 3.3V. Conecté el lector al bus SPI, tanto la librería SD como la SDfat responden.

815×472 66.4 KB

Hasta aquí todo parece funcionar con el shield, decidí complicar las cosas y conecté la segunda pantalla ILI9341. Si se conecta en forma paralela pin a pin respecto a la primer pantalla, se consigue que ambas pantallas muestren la misma información.

Si se define una segunda instancia de configuración y se conecta el pin CS a otro pin digital (20 o 21), se consigue controlar cada pantalla de forma independiente.

761×461 58.2 KB

Con algunas modificaciones en la rutina de lectura de archivos bmp, es posible enviar imágenes diferentes en cada pantalla

833×461 61.4 KB

22

Conseguí una pantalla ILI9341 de 3.2" que se conecta a 16 bits. Se requieren 33 hilos para conectar el lector SD (6), el panel táctil (5) y el TFT (22). Era la pantalla que quería desde que migré de los LCD´s gráficos a TFT´s, pero por falta de presupuesto no la había podido conseguir.

Hace unos días conseguí un par de protoboards para mega que ajustan muy bien en el due, por lo que decidí armar una placa de pruebas para la pantalla, logré insertar en la libreria UTFT un iniciador basado en el ILI9341 5SPI. También funciona con el constructor del ILI9327, pero hay que modificar la resolución en el archivo UTFT.ccp.


El shield permite conectar directamente la pantalla en un zócalo de 34 pines, o bien se puede construir una extensión para conseguir una mayor flexibilidad al usar la pantalla en un proyecto. Adicioné un zócalo de 6 pines en el que se puede instalar un lector microSD.

Acá está la base de expansión del FT843 hecha con la otra protoboard:

743×428 68.2 KB

Ya puedo concentrarme en otros aspectos del controlador como el diseño de los registros de avance de los proyectos del trabajo:

736×430 72.9 KB

Por fin puedo dedicarle tiempo al manejo de imágenes con la librería GD2, razón por la que tuve que pausar el diseño del controlador.
Video: desplazamiento de iconos

23

ehh excelente post

24

Gracias, espero que a alguien por allá fuera le sirva de algo.

Dibujo de indicadores analógicos en el FT843

Estoy instalando los sensores de temperatura NTC en el proto-shield. En lo que consigo algunas resistencias SMD en el rango de 6 a 8 K, le dediqué un tiempo al diseño de la función que permitirá dibujar gauges, diales o indicadores de aguja.

Hasta ayer los intentos me habían llevado al limite de la horizontal, acotado por el rango de ángulos entre 0 y 180. El enfoque era convertir el valor de la variable, el valor máximo de la escala del dial y el ángulo máximo. En ese concepto el ángulo inicial siempre es 0. Como los indicadores de aguja tienen su valor máximo hacia el extremo derecho del dial, me topé con el limite de 180 grados.

Tetha = (180 * Variable/ValorMaximo);

Si recordamos algunos conceptos matemáticos del circulo unitario, bajo el cuadrante I, el cuadrante que sigue es el cuadrante IV, allí el ángulo que seguiría de 180 (si lo vemos al revés), es el ángulo 359, no el 181.

Por esta razón al dibujar en el TFT obtenía agujas o marcas fuera de lugar donde esperaría que estuvieran, encima no hay que olvidar que las coordenadas del eje y están invertidas. Decidí dejar los diales en el rango de 0 a 180 grados.

Estoy poco familiarizado con las funciones heredadas de C que tiene el IDE de arduino y de poco a poco he aprendido a usar. Toca el turno a la función map().

Al usar esa función para calcular el ángulo equivalente a una lectura, se puede conseguir superar la barrera de la horizontal y curiosamente, la orientación invertida del eje y. Por ejemplo, la instrucción:

Tetha = map(Variable, 0, ValorMaximo, -30, 210);

Permite dibujar un dial horizontal que inicia en el ángulo -20 (corresponde a 200 en coordenadas normales) y termina en el ángulo 210 (340 en coordenadas normales)

Llevada al extremo, la función permite dibujar diales verticales o de rango corto como el que tienen algunos indicadores de presión. Este es un ejemplo con tres indicadores:

Video: indicadores analogicos

25

Hola, estoy trabajando con una pantalla LCD Touch TFT_320QVT, ella trae una memoria SD para cargar las imágenes en .RAW y montarlas asi en la LCD, hasta ahí todo normal, el problema es que quiero guardar datos de la lectura de sensores en la misma SD pero no lo he logrado, en la libreria TinyFAT dice que se pueden leer y escribir datos en ella pero he probado con los ejemplos y ninguno me funciona, crea los archivos pero no escribe nada en ellos, los deja vacios. Estoy pensando en utilizar el modulo aparte de memorias SD solo para guardar los datos y dejar la SD de la pantalla solo para montar las imagenes, es lo unico que se me ocurre. Me seria de gran ayuda que si sabes como guardar datos en la misma memoria me colabores, Gracias

26

GDCR:
Hola, estoy trabajando con una pantalla LCD Touch TFT_320QVT, ella trae una memoria SD para cargar las imágenes en .RAW y montarlas asi en la LCD, hasta ahí todo normal, el problema es que quiero guardar datos de la lectura de sensores en la misma SD pero no lo he logrado, en la libreria TinyFAT dice que se pueden leer y escribir datos en ella pero he probado con los ejemplos y ninguno me funciona, crea los archivos pero no escribe nada en ellos, los deja vacios. Estoy pensando en utilizar el modulo aparte de memorias SD solo para guardar los datos y dejar la SD de la pantalla solo para montar las imagenes, es lo unico que se me ocurre. Me seria de gran ayuda que si sabes como guardar datos en la misma memoria me colabores, Gracias

Para la gestión de datos e imagenes RAW, debes definir dos instancias de acceso a la libreria:

UTFT_tinyFAT myFilesB(&myGLCD);  
SdFat sd;      //Carga de imagenes RAW  

SdFat sd1;     //Gestión de datos
SdFile myFile;

Dentro del setup te sugiero que uses estas lineas, para activar cada una de las instancias de acceso al lector SD:

  if (!sd.begin(chipSelect, SPI_FULL_SPEED)) {sd.begin(chipSelect, SPI_HALF_SPEED);}
 if (!sd1.begin(chipSelect, SPI_FULL_SPEED)) {sd1.begin(chipSelect, SPI_HALF_SPEED);}

Separa por funciones los procesos de gestión de datos, por ejemplo:

1 Crear archivo/guardar datos
2 Leer datos
3 Eliminar archivo
27

Indicadores analógicos: uso de CPU y uso de RAM en el TFT

He estado recopilando los programas individuales para hacer funcionar cada uno de los componentes del controlador. En este proceso, retomé un aspecto que me hubiese gustado poder desarrollar personalmente, pero por cuestiones de tiempo y de poco dominio de C, Phyton o similares, no he podido profundizar: la comunicación a por el puerto serie de arduino con la PC. Me refiero a enviar datos de la PC al arduino como por ejemplo, temperaturas, uso del CPU o uso de la RAM.

Hace un tiempo encontré un proyecto con indicadores analógicos que me pareció bastante completo:

http://www.lungstruck.com/projects/pc-meter/

Video: indicadores de uso de CPU/RAM analógicos

En aquel momento no pude replicar el proyecto ya que no alcanzaba a entender como es que funcionaba el software de apoyo y mucho menos las funciones clave que permiten conseguir los dos valores: %CPU y %RAM.

Nuevamente revisé el código y por fin pude extraer los elementos que permiten leer los valores de uso del CPU y uso de la RAM. Estas son las funciones núcleo del programa:

//Inicia CPU array/total con ceros
void initCpuValues()
{
  for (int counter = 0; counter < CPU_READINGS; counter++)
    cpuReadings[counter] = 0;
    cpuTotal = 0;
}


void LeeCPURAM()
{
  while (Serial.available() > 0)
   {
   Serial.readBytesUntil('\r', buffer, 5);
   //Thought this might be needed based on example I studied, seems okay without
   //buffer[4] = '\0';
   switch (buffer[0])
   {
    case 'C':
     cpuTotal = cpuTotal - cpuReadings[cpuIndex];
     cpuReadings[cpuIndex] = min(atoi(&buffer[1]), 100);
     cpuTotal = cpuTotal + cpuReadings[cpuIndex];
 // Uso de CPU
     UsoCorei73770 = cpuTotal / CPU_READINGS;  //desmarcar luego de las pruebas
     
     //Advance index
     cpuIndex = cpuIndex + 1;
     if (cpuIndex >= CPU_READINGS)
       cpuIndex = 0;
     break;

    case 'M':
//Uso de RAM
    UsoRAM = min(atoi(&buffer[1]), 100);

     break;
     }
   
   //Reset for next measurement
   perc = 0;
   memset(buffer, ' ', 5);
   //Update last serial received
   lastSerialRecd = millis();
  }
}

Estas variables deben ser globales:

//Constantes para PC Meter
const long SERIAL_TIMEOUT = 0;  //How long to wait until serial "times out"
const int CPU_READINGS = 3;        //Number of readings to avg. for CPU load%

//Variables
unsigned long lastSerialRecd = 0;     //Time last serial read
float cpuReadings[CPU_READINGS];        //array of cpu load% readings
float cpuTotal = 0;                     //CPU load running total
int cpuIndex = 0;                     //current position in array for cpu load%

  char buffer[5];                //buffer
  int perc = 0;                  //reading
  
  float  UsoCorei73770;  //tengo un core i7 3370, de allí el nombre de la variable
  float UsoRAM;

Estas lineas van dentro del setup:

 Serial.begin(9600);
  initCpuValues();
  lastSerialRecd = millis();  //Give meter some time to start receiving data

El programa que permite obtener los datos y enviarlos por usb hasta el arduino se llama PC Meter, lo creó el autor del proyecto en Visual C#. Tiene algunos inconvenientes, que no creo se hayan resuelto todavía:

  • Bloquea la carga de sketchs al arduino, desconectando la captura todo funciona normalmente
  • Impide la hibernación de windows, cerrándolo se evita el problema
  • Impide el reinicio de la PC, cerrándolo se acaba el problema

Hay algunas otras complicaciones con los medidores analógicos usados en el proyecto original, pero que no se tendrán en el TFT, ya que acá no hay una conversión digital a voltaje, todo es digital.

Tomé como base el sketch de indicadores analógicos, y adicioné algunos textos.

Video: uso CPU y RAM

La velocidad de actualización me parece algo lenta, y le falta algo de fluidez, parece ser que dentro del programa PC Meter hay algunos delays que inciden en la velocidad de refresco, sin embargo ya tengo acceso a los datos comportamiento de la PC.

851×581 38.1 KB

28

He estado tratando de comprender mejor el funcionamiento del FT800. Se agradece la tasa de refresco de la pantalla y eso reduce mucho del esfuerzo de programación, pero a veces pueden diseñarse pantallas algo confusas, cargadas de "velocidad", que dificultan su uso dentro de un sketch.

Se pueden usar atajos como delays, pero soy enemigo de ese recurso, desde que aprendí a usar el ejemplo Blink without Delay. Aunque arduino no está diseñado para ejecutar multifunciones, es posible combinar varios contadores basados en millis() que nos permiten saltar de alguna forma esa barrera.

Optimización del movimiento de las agujas de los indicadores analógicos

Cuando diseñé el lector analógico para monitorear el uso de CPU/RAM de la PC, me dí cuenta de que al usar valores aleatorios en los indicadores, se hace presente la abrumadora velocidad de la pantalla. Es poco apreciable en rangos de entre 4 hasta 10 unidades, sin embargo en rangos de 15 o mas unidades entre lecturas, se observan saltos en las agujas.

Para conseguir que el desplazamiento de la aguja tenga una respuesta mas definida, es necesario incluir una componente que proporcione una velocidad gradual de desplazamiento, dando la impresión de que la agua o (una lectura) tiene la inercia que confiere un resorte o una respuesta gradual. La secuencia de análisis tiene estos pasos:

  1. Adquisición de la primer lectura para tomarla como base.
void LecturaSensor1(){
   T1 = random(100);
}

T1a = T1, T1g = T1
  1. Se asigna un intervalo de lectura: 1 s (1000 ms), 2 seg (2000 ms), etc. Controlado por millis(), en lugar de delay()
  2. Se toma una segunda lectura del sensor.
  3. Se determina si se trata de un incremento (velocidad positiva), decremento (velocidad negativa), o que no hay cambios en la lectura (velocidad= 0)
  unsigned long currentMillis1 = millis();        
  if(currentMillis1 - previousMillis1 > interval1)
  {
    previousMillis1 = currentMillis1;       

    LecturaSensor1();
    T1b = T1;
    DT1 = T1b - T1a;
    if (DT1>0){DT1g=1;}else{if (DT1<0){DT1g=-1;}else{DT1g=0;}} 
  }

Como resultado podemos conseguir el signo de valor del cambio: +(si hay un incremento), -(si hay una reducción) o 0 (si no hay cambios)

  1. Se aplica la velocidad al valor base. Lo forma mas simple es aumentar gradualmente el valor de la lectura base, hasta igualar el valor de la segunda lectura.
   if (T1g==T1b){T1g=T1b;}else{T1g = T1g + DT1g;}
  1. Gráficar el cambio gradual de la lectura base. Este paso es el que nos permite mostrar los cambios de la lectura de un sensor de forma atenuada, tal como lo hace un velocímetro o el mercurio dentro de un termómetro.

Vídeo: indicadores analógicos optimizados

Al llegar al valor objetivo, (es decir la segunda lectura, T1b), la variable (T1g) final, se convierte en el nuevo valor base (T1a), repitiendo el ciclo de tratamiento de la lectura. El menor intervalo entre la adquisición de lecturas, lo recomiendo establecer entre 500 y 700 ms.

PD: no podemos escaparnos de los códigos complejos, llega un momento en el que hay que codificar acciones tan simples como evaluar una variable, cuyo valor puede tomar tres o mas caminos y eso nos lleva a escribir lineas y lineas. Trataré de depurar el código para hacerlo mas comprensible.

29

Recientemente llegaron los conversores de Riverdi para cable plano a zócalo de pines. Este tipo de adaptador permite conectar de forma directa las pantallas de la serie FT80x y FT81x. Mi idea es poder construir un shield que me permita conectar cualquier tipo de pantalla de Riverdi, basada en los chips de FTDI, sin tener que lidiar con rollos de cables de prototipado.

Espero en los próximos días armar el rompecabezas para por fin conectar la pantalla capacitiva de 4.3" FT801, que tengo de pisapapeles desde hace meses. Ya les compartiré los avances. Me temo que tendré que modificar una vez mas la librería GD2, esperemos que de forma nativa funcione correctamente.

PD: como he dicho siempre, no soy vendedor ni distribuidor, simplemente me di a la tarea de filtrar las especificaciones que ofrecen los constructores de este tipo de pantallas, y me he inclinado por ese proveedor. Tampoco voy a construir algo para vender, simplemente quiero contar con buenas piezas para el hobbie.

30

El principio de funcionamiento de la pantalla FT801 está considerado dentro de las librerias para el gameduino 2: (la gameduino2 y la GD2, que corresponde a la versión multifuncional FT80x/FT81x)

Las lineas de conexión para cualquier pantalla FT80x a un arduino Due son:

FT80x    Due
GND      GND
VCC      3V3
MOSI     MOSI
MISO     MISO
SCK      SCK
CS       pin digital disponible

Las lineas extra que tiene cualquier pantalla FT80x: INT y PD, no se usan en las librerias para gameduino 2.

Adicionalmente, la mayoría de pantallas FT80x no tienen un lector SD, y pocas tienen instalado el amplificador en la salida de audio.

Para adicionar un lector SD, se puede usar un lector microSD. En los experimentos previos para anexar un lector, me di cuenta que debe estar diseñado para 3.3V, y no debe tener instalado un regulador de voltaje 5V/3.3V. Para minimizar las fallas, cada linea debe unirse a las lineas MOSI/MISO/SCK de la pantalla

La memoria micro SD recomiendo que sea de 4Gb, clase 4, preferentemente kingston, formateada en FAT32.

¿Por qué usar las librerias del gameduino 2, en lugar de las diseñadas por FTDI?. Es bastante simple.

Veamos el ejemplo hello world que viene en la libreria FTDI para el FT843

/* This application demonstrates the usage of FT800 library on FT_ADAM_4DLCD_FT843 platform */

/* Arduino standard includes */
#include "SPI.h"
#include "Wire.h"

/* Platform specific includes */
#include "FT_ADAM_4DLCD_FT843.h"

/* Global object for FT800 Implementation */
FT800IMPL_SPI FTImpl(FT_CS_PIN,FT_PDN_PIN,FT_INT_PIN);

/* Api to bootup ft800, verify FT800 hardware and configure display/audio pins */
/* Returns 0 in case of success and 1 in case of failure */
int16_t BootupConfigure()
{
	uint32_t chipid = 0;
	FTImpl.Init(FT_DISPLAY_WQVGA_480x272);//configure the display to the WQVGA

	delay(20);//for safer side
	chipid = FTImpl.Read32(FT_ROM_CHIPID);
	
	/* Identify the chip */
	if(FT800_CHIPID != chipid)
	{
		Serial.print("Error in chip id read ");
		Serial.println(chipid,HEX);
		return 1;
	}
	
	/* Set the Display & audio pins */
	FTImpl.SetDisplayEnablePin(FT_DISPENABLE_PIN);
    FTImpl.SetAudioEnablePin(FT_AUDIOENABLE_PIN); 
	FTImpl.DisplayOn(); 
	FTImpl.AudioOn();  	
	return 0;
}

/* API to display Hello World string on the screen */
void HelloWorld()
{
	/* Change the below string for experimentation */
	const char Display_string[12] = "Hello World";
	
	/* Display list to display "Hello World" at the centre of display area */
	FTImpl.DLStart();//start the display list. Note DLStart and DLEnd are helper apis, Cmd_DLStart() and Display() can also be utilized.
	FTImpl.ColorRGB(0xFF,0xFF,0xFF);//set the color of the string to while color
	FTImpl.Cmd_Text(FT_DISPLAYWIDTH/2, FT_DISPLAYHEIGHT/2, 29, FT_OPT_CENTER, Display_string);//display "Hello World at the center of the screen using inbuilt font handle 29 "
	FTImpl.DLEnd();//end the display list
	FTImpl.Finish();//render the display list and wait for the completion of the DL
}

/* bootup the module and display "Hello World" on screen */
void setup()
{
	/* Initialize serial print related functionality */
	Serial.begin(9600);
	
	/* Set the Display Enable pin*/   
	Serial.println("--Start Application--");
	if(BootupConfigure())
	{
		//error case - do not do any thing
	}
  	else
	{
		HelloWorld();
	}
	Serial.println("--End Application--");
}

/* Nothing in loop api */
void loop()
{
}

Sketch uses 26,800 bytes (5%) of program storage space. Maximum is 524,288 bytes.

Al familiarizarme con la libreria FTDI, me di cuenta que se puede prescindir de muchas lineas de código, pero otras deben usarse todo el tiempo, ya que se comunican directamente con el micro FT80x, y al no usarlas se producen errores de procesamiento (pantallazos azules XD).

Este es el ejemplo hello world de la libreria GD2:

#include <SPI.h>
#include <GD2.h>

void setup(){ Serial.begin(1000000); // JCB
  GD.begin(0);}

void loop(){GD.ClearColorRGB(0x103000);
  GD.Clear();
  GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "Hello world");
  GD.swap();}

Sketch uses 13,664 bytes (2%) of program storage space. Maximum is 524,288 bytes.

Creo que las diferencias son mas que evidentes.

No es solo conectar la nueva pantalla, hay que hacer algunos ajustes en la libreria GD2 para que las pantallas FT80x se comporten como lo hace la pantalla del gameduino 2.

31

Librerias para gameduino 2

Gameduino 2 (y FT80x):
http://excamera.com/files/Gameduino2.zip

Libreria en desarrollo para gameduino 2, con soporte para FT8xx: GitHub - jamesbowman/gd2-lib: Gameduino 2/3/3X library sources

Ajuste de la libreria GD2

Me centraré en los pasos para modificar la libreria GD2 y dejarla a punto para cualquier tipo de pantalla FT80x. Con el FT813 tendré que invertir mucho mas tiempo...

Luego de descargar el zip, hay que limpiar un poco el directorio, ya que prácticamente "estamos entrando a una parte del taller de James"

857×1065 101 KB

Ubicamos la libreria en la carpeta correspondiente para que se active en el IDE de arduino:

845×524 80.1 KB

Estas son las lineas que se encuentran en el archivo GD2.ccp original

#define SD_PIN        9    // pin used for the microSD enable signal

#define BOARD_FTDI_80x    0
#define BOARD_GAMEDUINO23 1
#define BOARD_EVITA_0     2

#define BOARD         BOARD_GAMEDUINO23 // board, from above
#define STORAGE       1                 // Want SD storage?
#define CALIBRATION   1                 // Want touchscreen?

// FTDI boards do not have storage
#if (BOARD == BOARD_FTDI_80x)
#undef STORAGE
#define STORAGE 0
#endif

Ésta es la versión personalizada para ajustarse al shield de Riverdi para arduino (pantallas FT80x y FT81x), con soporte para lector micro SD externo

#define SD_PIN               5   //5--->SD-Riverdi shield,  9--->para gameduino 2

#define BOARD_FTDI_80x       0
#define BOARD_GAMEDUINO23    1
#define PROTO                0   //0-->FT843, FT80x; 1--> MEGA, UNO, gameduino 2
#define BOARD_EVITA_0        2

#define BOARD                0         // board, from above
#define STORAGE              1   // Want SD storage?
#define CALIBRATION          1   // Want touchscreen?

// FTDI boards do not have storage
#if (BOARD == BOARD_FTDI_80x)
#undef STORAGE
#define STORAGE              1
#endif

La instrucción PROTO en GD2

PROTO, definida en la linea siguiente:

#define PROTO                0

Permite controlar la disposición de la tabla de colores, orientación de pixeles y orientación del panel táctil de las pantallas FT80x. El gameduino 2 tiene una disposición "invertida", respecto al diseño original de FTDI, la razón posiblemente se deba al ángulo de visión de la pantalla del shield gameduino 2.

En la libreria nueva (GD2), esa linea ha sido suprimida, es importante rescatarla, ya que resulta mucho mas fácil manipular el cableado, con la orientación que tiene el gameduino 2, que con la disposición que tiene de fábrica el FT80x.

En el archivo GD2.ccp original, las lineas en las que debemos insertar la instrucción están dispuestas de esta forma:

#if (BOARD == BOARD_FTDI_80x)
  GDTR.wr(REG_PCLK_POL, 1);
  GDTR.wr(REG_PCLK, 5);
#endif
  GDTR.wr(REG_PWM_DUTY, 0);
  GDTR.wr(REG_GPIO_DIR, 0x83);
  GDTR.wr(REG_GPIO, GDTR.rd(REG_GPIO) | 0x80);

#if (BOARD == BOARD_GAMEDUINO23)
  ConfigRam cr;
  byte v8[128] = {0};
  cr.read(v8);
  if ((v8[1] == 0xff) && (v8[2] == 0x01)) {
    options &= ~(GD_TRIM | GD_CALIBRATE);
    if (v8[3] & 2) {
      GDTR.__end();
      GDTR.hostcmd(0x44); // switch to external crystal
      GDTR.resume();
    }
    copyram(v8 + 4, 124);
    finish();
  } else {
    GDTR.wr(REG_PCLK_POL, 1);
    GDTR.wr(REG_PCLK, 5);
    GDTR.wr(REG_ROTATE, 1);
    GDTR.wr(REG_SWIZZLE, 3);
  }
#endif

La secuencia de instrucciones que permite modificar la rotación de colores, panel táctil y pixeles en las pantallas FT80x queda así:

#if (BOARD == BOARD_FTDI_80x)
  GDTR.wr(REG_PCLK_POL, 1);
  GDTR.wr(REG_PCLK, 5);

// Avoid inverted colours on alternative-FT800 boards
#if PROTO == 1
  GDTR.wr(REG_ROTATE, 1);
  GDTR.wr(REG_SWIZZLE, 3);
#endif
    GDTR.wr(REG_ROTATE, 1);   
// Avoid inverted colours on alternative-FT800 boards

#endif
  GDTR.wr(REG_PWM_DUTY, 0);
  GDTR.wr(REG_GPIO_DIR, 0x83);
  GDTR.wr(REG_GPIO, GDTR.rd(REG_GPIO) | 0x80);

#if (BOARD == BOARD_GAMEDUINO23)
  ConfigRam cr;
  byte v8[128] = {0};
  cr.read(v8);
  if ((v8[1] == 0xff) && (v8[2] == 0x01)) {
    options &= ~(GD_TRIM | GD_CALIBRATE);
    if (v8[3] & 2) {
      GDTR.__end();
      GDTR.hostcmd(0x44); // switch to external crystal
      GDTR.resume();
    }
    copyram(v8 + 4, 124);
    finish();
  } else {
    GDTR.wr(REG_PCLK_POL, 1);
    GDTR.wr(REG_PCLK, 5);

// Avoid inverted colours on alternative-FT800 boards
#if PROTO == 1
  GDTR.wr(REG_ROTATE, 1);
  GDTR.wr(REG_SWIZZLE, 3);
#endif
    GDTR.wr(REG_ROTATE, 1);   
// Avoid inverted colours on alternative-FT800 boards
  }
#endif
32

Resta modificar el archivo wiring.h, para ajustar el cableado a la disposición del shield-arduino de Riverdi.

Primeras lineas del archivo wiring.h original:

#ifndef CS
#define CS 8
#endif

class GDTransport {
private:
  byte model;
public:
  void ios() {
    pinMode(CS, OUTPUT);
    digitalWrite(CS, HIGH);
    pinMode(9, OUTPUT);
    digitalWrite(9, HIGH);

Archivo wiring.h ajustado:

#ifndef CS
#define CS 10
#endif

class GDTransport {
private:
  byte model;
public:
  void ios() {
    pinMode(CS, OUTPUT);
    digitalWrite(CS, HIGH);
    pinMode(5, OUTPUT);
    digitalWrite(5, HIGH);

Adjunto los archivos modificados. Funcionan para pantallas FT80x, gameduino2 en placas arduino como el Due, UNO, MEGA(hay que soldar algunas lineas externas entre MOSI, MISO y SCK a los pines correspondientes 11, 12 y 13). También funciona para el teensy 3.2.

Hardware de pruebas:

1024×590 62.8 KB

wiring.h (6.77 KB)

GD2.cpp (35 KB)

33

TFTLCDCyg:
El principio de funcionamiento de la pantalla FT801 está considerado dentro de las librerias para el gameduino 2: (la gameduino2 y la GD2, que corresponde a la versión multifuncional FT80x/FT81x)

Las lineas de conexión para cualquier pantalla FT80x a un arduino Due son:

FT80x    Due

GND      GND
VCC      3V3
MOSI     MOSI
MISO     MISO
SCK      SCK
CS       pin digital disponible





Este es el ejemplo *hello world* de la libreria GD2:

#include <SPI.h>
#include <GD2.h>

void setup(){ Serial.begin(1000000); // JCB
 GD.begin(0);}

void loop(){GD.ClearColorRGB(0x103000);
 GD.Clear();
 GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "Hello world");
 GD.swap();}



Sketch uses 13,664 bytes (2%) of program storage space. Maximum is 524,288 bytes.

*Creo que las diferencias son mas que evidentes.*

No es solo conectar la nueva pantalla, hay que hacer algunos ajustes en la libreria GD2 para que las pantallas FT80x se comporten como lo hace la pantalla del gameduino 2.

TFTLCDCyg:
El principio de funcionamiento de la pantalla FT801 está considerado dentro de las librerias para el gameduino 2: (la gameduino2 y la GD2, que corresponde a la versión multifuncional FT80x/FT81x)

Las lineas de conexión para cualquier pantalla FT80x a un arduino Due son:

FT80x    Due

GND      GND
VCC      3V3
MOSI     MOSI
MISO     MISO
SCK      SCK
CS       pin digital disponible




Las lineas extra que tiene cualquier pantalla FT80x: INT y PD, no se usan en las librerias para gameduino 2.

Adicionalmente, la mayoría de pantallas FT80x no tienen un lector SD, y pocas tienen instalado el amplificador en la salida de audio.

Para adicionar un lector SD, se puede usar un lector microSD. En los experimentos previos para anexar un lector, me di cuenta que debe estar diseñado para 3.3V, y no debe tener instalado un regulador de voltaje 5V/3.3V. Para minimizar las fallas, cada linea debe unirse a las lineas MOSI/MISO/SCK de la pantalla

La memoria micro SD recomiendo que sea de 4Gb, clase 4, preferentemente kingston, formateada en FAT32.

¿Por qué usar las librerias del gameduino 2, en lugar de las diseñadas por FTDI?. Es bastante simple.

Veamos el ejemplo *hello world* que viene en la libreria FTDI para el FT843

#include <SPI.h>
#include <GD2.h>

void setup(){ Serial.begin(1000000); // JCB
 GD.begin(0);}

void loop(){GD.ClearColorRGB(0x103000);
 GD.Clear();
 GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "Hello world");
 GD.swap();}



Sketch uses 13,664 bytes (2%) of program storage space. Maximum is 524,288 bytes.

*Creo que las diferencias son mas que evidentes.*

No es solo conectar la nueva pantalla, hay que hacer algunos ajustes en la libreria GD2 para que las pantallas FT80x se comporten como lo hace la pantalla del gameduino 2.

Gracias por la información TFTLCDCyg. Esto he estado buscando todo el fin de semana y lo tenía delante de mis ojos (este mensaje tuyo)

Hoy me has alegrado el día.

Como bien sabes tengo la FT800 y después de leer tu post, creo que me he vuelto a animar, estaba totalmente aburrido y desilusionado. Te explico, he llegado a pensar que "no es tan difícil", pues si, ya que la librería procedente de FTDI es extremadamente complicada, ademas he leído los interminables PDF de la pagina oficial, en cuyos ejemplos, no me ha funcionado casi nada. Solo los ejemplos de las librerías.

Voy esta tarde a repasar todo tu post, le voy a poner mi DUE y conectar la pantalla que solo muestre el "Hola mundo".

Lo mas curioso es que veo esta pantalla (FT800) le da 100.000 vueltas a todas las que he probado, pero cachis, que va costar un rato hacerla andar. Bueno ya comentaré mi experiencia.

Saludos de nuevo y gracias! :slight_smile:

34

Me olvidé de lo mas importante para ir trabajando;

Las lineas de conexión para cualquier pantalla FT80x a un arduino Due son:

FT80x    Due
GND      GND
VCC      3V3
MOSI     MOSI
MISO     MISO
SCK      SCK
CS       pin digital disponible


Las lineas extra que tiene cualquier pantalla FT80x: INT y PD, no se usan en las librerias para gameduino 2.

Donde dices CS pin digital disponible, a que pin a de ir? no me quedó claro.
Y otra cosa, sobre que IDE de Arduino funciona correcto, he leído que la versión 1.5.4, puede ser?
A ver si me puedes ayudar.
Gracias.

35

Espero que te sirva y te evites la pena de sumergirte en el lenguaje complejo de las librerías de FTDI. Creo que iremos al paso aprendiendo a usar la libreria.

Estoy usando el IDE 1.6.3, y creo que me quedaré en esa versión. No tengo la versión 154, pero tengo la 156-r2, la librería de gameduino 2 funciona sin problemas. Habrá que experimentar.

Respecto al cableado: CS, puede ser cualquier pin digital disponible, te recomiendo que sea 8, 9 o 10. Pero creo que se puede usar cualquier otro (habrá que experimentar con este punto).

Por cierto, la libreria para gameduino 2 tiene una particularidad que debo reiterar:

Por código, tiene transportada la señal SPI del conector del arduino Due, a los pines SPI correspondientes al arduino UNO, es decir que puedes conectar la señal SPI de cualquier pantalla FT80x, a los pìnes 11, 12 y 13.

Es por esto que se puede conectar el shield gameduino 2 directamente sobre un arduino Due, tal como se conecta en el arduino UNO, sin cableado conectado al conector SPI del arduino Due.

784×524 54.9 KB

En el arduino MEGA hay que conectar los pines SPI a los pines correspondientes 11, 12 y 13, (creo que se podrían sustituir "los nombres de pila" de los puertos SPI del MEGA en lugar de los correspondientes del arduino Due) y con eso se consigue instalar el shield gameduino 2 directamente:

742×450 49.5 KB

742×450 50.8 KB

Puedes usar el cabezal SPI del arduino con otros dispositivos, como una pantalla Oled, ILI9341 o un lector micro SD adicional. Si los conectas a 11, 12, 13 pensando en usar "el porteo" o transferencia por código, se apaga la pantalla FT80x.

El único dispositivo SPI que ha funcionado sin afectar la pantalla, afortunadamente fue uno de los lectores microSD de 3V3, y con él es posible acceder a todo el potencial gráfico del FT801.

La longitud del cableado entre el arduino y la pantalla FT80x, debe estar entre 14 y 20 cm, mas allá de esa longitud la pantalla se apaga.

(Una queja "oculta")

Desafortunadamente conforme salen nuevos ide's, en lugar de mejorarlos, y corregir errores, empeoran la compatibilidad con las librerias que funcionan bien con versiones previas. Encima no ha habido una corrección de fondo que elimine esta "joyita", si usas y0 ("ye cero"), seguido de un y1 ("ye uno"), obtienes:

int y0, y1;

GD2_due_lecturas_5.ino:11:5: error: 'int y0' redeclared as different kind of symbol
In file included from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\cores\arduino/Arduino.h:26:0,
                 from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\variants\arduino_due_x/variant.h:36,
                 from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\libraries\SPI/SPI.h:15,
                 from GD2_due_lecturas_5.ino:1:
c:\users\starx\appdata\roaming\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\math.h:468:15: error: previous declaration of 'double y0(double)'
 extern double y0 _PARAMS((double));
               ^
GD2_due_lecturas_5.ino:11:9: error: 'int y1' redeclared as different kind of symbol
In file included from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\cores\arduino/Arduino.h:26:0,
                 from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\variants\arduino_due_x/variant.h:36,
                 from C:\Users\StarX\AppData\Roaming\Arduino15\packages\arduino\hardware\sam\1.6.4\libraries\SPI/SPI.h:15,
                 from GD2_due_lecturas_5.ino:1:
c:\users\starx\appdata\roaming\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\math.h:469:15: error: previous declaration of 'double y1(double)'
 extern double y1 _PARAMS((double));
               ^
Error compiling.

¿Es en serio?

La siguiente linea, (en lugar de la que describo):

int x0, x1

Compila sin problemas... quiero tener la mente abierta y que es un error mío al escribir "y0 y y1"...

Digo esto porque luego de ver "hello world" en la FT801, inmediatamente me puse a trabajar en el entorno del controlador, y zas!, a la primer compilación con "int y0, y1", saltó el error que refiero.

Solo por seguir con el ejercicio, el IDE 1.5.6-r2, da este error:

int y0, y1;

sketch_jun21a:2: error: 'int y0' redeclared as different kind of symbol
c:\arduino-1.5.6-r2\hardware\tools\g++_arm_none_eabi\bin\../lib/gcc/arm-none-eabi/4.4.1/include-fixed/math.h:364: error: previous declaration of 'double y0(double)'
sketch_jun21a:2: error: 'int y1' redeclared as different kind of symbol
c:\arduino-1.5.6-r2\hardware\tools\g++_arm_none_eabi\bin\../lib/gcc/arm-none-eabi/4.4.1/include-fixed/math.h:365: error: previous declaration of 'double y1(double)'

:o :o :o :o

Luego de esta "pecata minuta", mejor usaré

int y00, y01;

y todos felices!

A estas alturas, espero que ya veas el ejemplo hello world. Sube algunas fotos de tu pantalla FT, para curiosear los avances, sería bueno ver que los esfuerzos los puede replicar alguien más, ayudaría bastante en la retroalimentación, nunca está demás una vuelta de timón hacia la dirección correcta.

36

Buenas noticias!!!! , pero de las buenas.

He conseguido hacer funcionar mi pantalla comprada en esta tienda. Llevo peleando con ella 3 días enteros (con sus noches incluidas, que no me han dejado dormir casi...) y como dije solo funcionaba con la librería de FTDI.

Pues bien también funciona con la librería GD2
Va le a todo esto sé que no tiene audio, acelerometro ni microSD, todo a su tiempo...

Esta pantalla tiene tiene una placa (shield) básica sin nada mas que operar solo con la librería FTDI, pues hay que realizar tan solo un circuito de POR (Power On Reset) al pin PD_N del chip FT800, resultado: FUNCIONANDO.

Cuando leí este mensaje de Gameduino me desanime por completo, ya que el usuario tiene el mismo problema que yo. He tirado de la DataSheet del FT800 a nivel del hardware FT800 DATA y aquí he logrado la solución.

Lo mismo se va a vender esta pantalla como rosquillas, lo digo por el precio y para iniciarse como yo, pues va bien para empezar.

@TFTLCDCyg creo, la pantalla ahora si que empieza a prometer.

Mas tarde escribo la solución, que me voy a tomar unas cervezas para celebrarlo. :slight_smile: :slight_smile: :slight_smile:

37

Que ya veas que sirva con la librería para gameduino 2, es un enorme avance. :art:

Te sugiero que el siguiente paso lo apliques en encontrar un lector micro SD, que te dé el soporte para manejo de imágenes.

La librería puede manejar grupos de hasta 15 imagenes pequeñas, y lo mejor de todo: en formato png, con lo que puedes tener iconos o imagenes con transparencias!!!.

Esta pantalla puede funcionar con las librerías gráficas de phyton27, sin embargo no he podido hacer que funcionen. Quizás con una instalación limpia del sistema operativo lo pueda conseguir. Con esas herramientas activadas, es posible crear sprites en celdas de hasta 8 imagenes cada una. Por ejemplo se podrían construir archivos de imagen con digamos 5 imagenes png, con 8 celdas cada una, consiguiendo 5x8 = 40 imagenes con un solo archivo sprite. Espero un día instalar correctamente las librerias. Claro siempre estaremos limitados a los 256 kb del FT80x.

Aparentemente no es mucha memoria, pero eso no es una límitante que debilite la plataforma.

Video: iconos png

38

Buenas.

Como dije las pantallas chinas de bajo coste de esta tienda de China funcionan correctamente en la librería GD2 del cual, le doy las gracias por este post a TFTLCDCyg.

No hubiesen funcionado jamas si no, después de releer mas de 20 veces el post completo.
Como tengo varios proyectos en mente acabo de realizar un pedido para no quedarme sin stoks cosa que ocurre cuando se escribe algo y todo el mundo pide...

He aquí la solución.

Las lineas extra que tiene cualquier pantalla FT80x: INT y PD, no se usan en las librerias para gameduino 2.
Adicionalmente, la mayoría de pantallas FT80x no tienen un lector SD, y pocas tienen instalado el amplificador en la salida de audio.

Para esta pantalla no es valido.

Esto anterior es lo que ha escrito @TFTLCDCyg en el caso de estas "pantallas Chinas de bajo coste" como la que yo he comprado supongo porque es asi, TFTLCDCyg las usa con shiels personalizadas como Gameduino, ADAM, y otras mas, por la red están sin stock, y entonces me puse a investigar este ultimo sábado de mes (día 18 del corriente) y sin conexion alguna.

Hoy he recuperado mi Arduino DUE y conectado el SPI de la pantalla. Totalmente negra... Sin nada.
Volvi a mi Arduino MEGA. Al menos sabía que funcionaba la librería FTDI y funcionando, la pantalla, seguía a la vida.

Pero por "arte de magia" o casualidad al intentar subir la hoja de ejemplo de la librería FTDI y luego seguido a los dos segundos el ejemplo de la librería GD2 con el consejo de TFTLCDCyg, visualice en unas fraciones de milisegundos que la pantalla ponia " HELLO WORLD" , entonces dije EUREKA!!!

solo unos milisegundos y funcionó, por lo tanto la pantalla funcionaría con la librería GD2.
Como lo adiviné?

Sencillo. Al principio de luchar con la pantalla descubrí que el pin llamado PD_N del circuito integrado grafico FT800 es no mas que un reset al chip anterior citado. Con esto funcionó cuando lo pusé en el pin correcto de la placa Arduino ( en modelo UNO y MEGA), vale entonces hoy el pin PD_N es MUY IMPORTANTE si no se tiene una shield adecuada como ha escrito TFTLCDCyg.

La solución es esta, hay que montar una red R+C al pin PD_N (o bien hacerlo exteriormente, como lo he realizado yo) como pone la DataSheet del circuito integrado FT800;

Donde VCCIO es 3,3V (MUY IMPORTANTE !!!) no conectar a +5VCC, hay que hacerlo a 3,3VCC

Resultado;

Montar la red R+C exterior;

Como quedo compilado con IDE de Arduino 1.6.5;

y otra mas;

Al revés... bueno anteriormente TFTLCDCyg comento de modificar las librería...
Mañana lo pruebo ya definitivamente en mi Arduino DUE y pondré mas capturas. A todo ello voy a incluir esta información de "peso en oro" a mi mensaje ne Documentos de este foro para la pantalla china que es este enlace pantalla FT800 china

Saludos! :slight_smile:

39

En la pantalla FT843 (FT800) de 4D systems, el propio gameduino 2 y en la FT801 de Riverdi, no he usado las lineas INT ni PD.

Como indicas es posible que el FT800 en tu pantalla, esté conectado de forma muy austera.

Esperemos que tengas funcionando correctamente tu pantalla en el arduino Due. Gracias por compartir los avances.

40

Buenas.
Doy hoy por decir esto;

La pantalla FT800 de este modelo;

800×600 67.4 KB

comprada en esta tienda de Hong-Kong funciona correctamente con la librería GD2.

Ayer tube problemas...
La monté sobre mi Arduino DUE y no funciono... la volví a poner sobre mi Arduino MEGA y funcionaba( tal y como la tenía), pero solo una cosa, solo funcionaba con el codígo del ejemplo del "Hello World" ( a partir de ahora "HELLOWORD"

Este es el código que funcionaba con realizar el POR (Power On Reset);

#include <EEPROM.h> 
#include <SPI.h>
#include <GD2.h>


void setup(){

  GD.begin(0);

}

void loop()
{
  
  GD.ClearColorRGB(0xff0000);
 
  GD.Clear();
  GD.cmd_text(GD.w / 1, GD.h / 2, 31, OPT_CENTER, "HOLA TOMAS F.");
  GD.swap();
}

Todo bien, pero al cargar desde la librería un ejemplo de código como este;

#include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>

void setup()
{
  GD.begin();
}

void loop()
{
  GD.Clear();
  GD.Begin(POINTS);
  for (int i = 0; i < 100; i++) {
    GD.PointSize(GD.random(16 * 50));
    GD.ColorRGB(GD.random(256),
                GD.random(256),
                GD.random(256));
    GD.ColorA(GD.random(256));
    GD.Vertex2ii(GD.random(480), GD.random(272));
  }
  GD.swap();
}

Este último se queda la pantalla en fade (desvanecimiento), resetear y/o volver a conectar el cable de alimentación.. lo mismo pantalla blanca y desvanecimiento... Esto toda la tarde ayer me frusto de lo GRANDE...

Hoy he recuperado la ilusión. La única diferencia de un código a otro esta en setuo donde el código "bueno" pone;

GD.begin(0);

y en el segundo pone;

GD.begin();

y este es el problema el GD.begin (sin numero);... he ido probando mas ejemplos como los de las librerias y ya funcionando todas (algunas no por el IDE de Arduino, como no.. jejeje), estoy usando la 1.6.5

a todo esto en el setup de cualquier código para subir he investigado esto:

GD.begin();   ---> PANTALLA BLANCA y no funciona nada en pantalla. Desvanecimiento y rayas.
GD.begin(1) funcional, pero baja resolución
GD.begin(2) funcional y Táctil
GD.begin(3) funciona, Táctil y gráficos a máxima resolución
No he probado mas por falta de tiempo...

Y otra buena noticia

he conseguido por software realizar el POR (Power On Reset) de la pantalla realizando este código:

#define PDNPin 8
...

En el setup:
  pinMode(PDNPin, OUTPUT);
  digitalWrite(PDNPin, HIGH);  
   delay(20);
  digitalWrite(PDNPin, LOW);
  delay(20);
  digitalWrite(PDNPin, HIGH);
  delay(20);

Consultando las DataSheet del IC FT800, necesita unos 5ms desde el inicio de pantalla que paje a nivel bajo y vulta a nivel alto, lo he recogido de la pagina oficial y ponía estos delay, lo mismo se trata de substituir por delayMicroseconds.

De momento y a esta pantalla también he averiguado que los colores parpadean y/o son inverson del rojo al azul. La solución es poner en el setup este código después del GD.begin(x);

GD.wr(REG_SWIZZLE, 0);

No he leído la extensa y grandísimo PDF de la librería GD2 pero, no acabo de ver por el cual el GD.begin(x) era el problema.... Seguiré investigando pero ya digo que la pantalla en totalmente funcional. Lo siguiente y tengo los componentes le voy a poner el audio y una SD, realizada por mi.

Dejo el código tipo INICIAL (luego ustedes programan lo que sean...) de como queda la pantalla para Arduino UNO y MEGA;

#include <EEPROM.h> 
#include <SPI.h>
#include <GD2.h>

#define PDNPin 8                   // PIN DONDE VA EL PIN_DN

void setup(){

 
   pinMode(PDNPin, OUTPUT);
   digitalWrite(PDNPin, HIGH);  // INICIALMENTE EN ALTO
  
   delay(20);
   digitalWrite(PDNPin, LOW);  // REALIZAMOS EL POR EN BAJO AL PIN DN
   delay(20);                        // ESPAREMOS 20 MICROSEGUNDOS (Data pone 5ms)
   digitalWrite(PDNPin, HIGH);  // LO VOLVEMOS A PONER EN ALTO
   delay(20);
   GD.begin(3);
   GD.wr(REG_SWIZZLE, 0);   // PARA NO INVERTIR EL ROJO POR AZUL DE LA PANTALLA


}

void loop()
{
  
   GD.ClearColorRGB(0xff0000);   // LA PANTALLA DE FONDO ROJO
   GD.Clear();
   GD.cmd_text(GD.w / 1, GD.h / 2, 31, OPT_CENTER, "HOLA TOMAS F.");
   GD.swap();
}

@TFTLCDCyg no quiero desorientar este tema tuyo, pero tenía que explicar, luego lo realizo en mi tema que puse en "DOCUMENTACIÓN" de esta pantalla para consultas. A todo ello me respondió el Admin de Gameduino. Le pondré la solución por software al pin PD. Y repito sin tus mensajes esta pantalla no hubiese jamas funcionando en GD2, esto se le llama "team" no?

Saludos.
P.D. Mañana voy a probar con el DUE, ahora que sé que es todo correcto.