Algunos consejos para usar TFT´s

[TFTLCDCyg]

Definitivamente en AVR tenemos varias limitaciones en la optimización de la librería SPI, además de que la velocidad del bus es baja, menos de la mitad está disponible. El arreglo en el arduino Due me ha dado bastantes problemas, quizás algunos pines de sus cabezales ya no hacen buen contacto, no cuento con otro due para hacer pruebas con el shield para el ILI9488.

Para ganar más velocidad en la carga de imágenes lo mejor será que uses una placa más rápida, podrían ser una black STM32F411, black STM32F407VG, teensy 3.5, teensy 3.6, teensy 4 o teensy 4.1.

En las STM32 los tiempos de carga de imágenes bmp, podrían rondar entre 1100 y 1300 ms.

Los mejores rendimientos los conseguirán con las placas que tienen un lector incorporado SDIO: teensy 3.5, teensy 3.6 o teensy 4.1. La teensy 4 no incluye un lector, sin embargo, es posible conectar uno con un conversor SD-microSD, mediante varios hilos, la ventaja es que el lector resultante estará en modo SDIO.

Dependiendo del tamaño, las imágenes bmp 480x320 px, podrían cargarse entre 700 y 1000 ms, en una teensy 3.6, para imágenes jpg podrían ser entre 250 y 450 ms

En una teensy 4 o en una 4.1 es posible utilizar imágenes jpg en lugar de bmp, los tiempos de carga podrían rondar entre 100 y 200 ms o quizás menos.

[jmoreraa]

Y en un Arduino mega con una interfaz de 16bit y la SD en SPI?
Si me pudieses decir de alguna libreria para controlar la tft ili 9488 de 480x320 atraves de la interfaz paralela de 16 bits, y como seria el cableado te lo agradeceria. Ahora mismo lo tengo asi:

Con convertidores logicos:

[TFTLCDCyg]

Llegué a ver opciones de ILI9341 con 34 pines para STM32 con bus paralelo, pero no me he topado con su equivalente para ILI9488. Pude instalar una de esas en un arduino Due, con un bus paralelo, pensando que ganaría velocidad, pero siempre fue mejor la librería ILI9341_due.

Si se trata de mejorar la carga de imágenes, optaría por un teensy 3.5, existe una librería mejorada que se llama ILI9488_t3, como viene con su lector SDIO nativo, tendrías un plus de velocidad para el manejo de imágenes.

En estas etapas tempranas de tu proyecto podrías contar con alternativas que involucren ponderar el costo vs desempeño. Desafortunadamente los mejores TFT en el entorno de Arduino no son tan asequibles como los destinados a proyectos simples.

Los que he podido tener oportunidad de estudiar y de implementar en los proyectos personales, implican controladores gráficos que prácticamente son el equivalente de una GPU para PC en el entorno arduino.

Ha sido un recorrido largo para llegar al momento actual: análisis de señales de audio en mediante FFT tiempo real, presentación de datos de posición GPS sobre un mapa en tiempo real, reproducción de videos con audio para los momentos de ocio; y, sobre todo, librerías disponibles sencillas de usar, eran todo lo que buscaba, pero no ha sido gratis, y debo decirlo, ha tomado su buena inversión tanto en tiempo y materiales.

[jmoreraa]

Y no has visto alguna biblioteca para cualquier pantalla de 4" con interfaz paralela de 16bits? Yo he encontrado la tft_hx8357, que permite controlar, atreves de los 16bits, ili9486 y ili9481, pero estos solo se comercializan con pantallas de 3,5". Si pudiese encontrar alguna librería compatible para un controlador usado en 4" o pudiese modificar la tft_hx8357 para hacerla compatible para ili9488 seria perfecto, no creo que sea muy complicado, ya que funciona con ili9488 y ili9481, pero no he visto ningún ejemplo y por mi mismo no se como hacerla compatible. Gracias

[TFTLCDCyg]

Las variantes que he visto en 4" para ILI9488 tienen interfaz SPI. Considero que el rendimiento del TFT con bus de 16 bits no será mejor que con SPI, ya que las bases de las posibles librerías tienen como referencia la UrTFT.

En algún momento conseguí una pantalla ILI9341 con interfaz de 16 bits, pero su contraparte SPI siempre funcionó mejor.

Se podría explorar con una STM32 económica como la black F411CE o la black F407VG, incluso una black F446RET6, darán una mejor velocidad al lector microSD con el TFT ILI9488-SPI.

Ya entrados en temas de rendimiento, una teensy 3.5 creo que sería una buena base de microcontrolador precio-rendimiento, incluye un lector SDIO con el que no tendrás que lidiar con cableado extra, además que tiene pines Ax/Digitales de sobra, con un formato físico bastante reducido, además la librería ILI9488_t3 está muy bien optimizada para ILI9488-spi.

Con versiones más rápidas, el posible PCB se puede escalar sin cambiar nada, se sustituye la 3.5 por una teensy 3.6 o por una teensy 4.1 que tienen el mismo formato y distribución general del bus SPI

Otra posibilidad es utilizar una teensy 4, solo hay que agregar un lector que quedará en modo SDIO, como sus contrapartes que ya lo incluyen de serie: formato pequeño y con unos 600 Mhz de frecuencia

[TFTLCDCyg]

Llevo estudiando la manera de utilizar la placa R-Pi Pico desde que salió al mercado. He estado tratando de usarla con la librería GDSTx para conectar una pantalla de 4.3" . Dos aspectos me preocupan luego de conseguir que la pantalla funcione: la carencia de memoria eeprom en la placa y poder usar la librería SdFat para el manejo de multimedia.

En su momento me ha costado conseguir que la soldadura de los pines se quede en su lugar, me parece que no limpié bien el PCB cuando llegó y me da la impresión de que no hay una buena unión entre los pines y el PCB. LE he dado una repasada a las soldaduras con flux, retiré lo más que pude el excedente de soldadura. La destreza con el cautín que tenía en ese momento era por demás básica, no digo que hoy día sea lo mejor, pero hasta el momento, los artilugios siguen funcionando.

Estos son los elementos que quiero combinar:

• R-Pi Pico
• NHD FT813 5"
• Lector externo microSD, 3.3V
• Eeprom 24LC512
• Librería GDSTx
• Librería SdFat V2

Salió en la foto el gameduino 3, consideré utilizarlo en las pruebas, pero su formato de pines en forma de shield para placas tipo arduino UNO, no es compatible con las otras pantallas EVEx que tengo a la mano, así que tomaré el camino más largo, pero que me permitirá hacer mejores pruebas, ya que la salida de audio del gameduino es bastante quisquillosa y la mayor parte del tiempo falla al menor movimiento.

Lector microSD
El primer paso es conectar el lector microSD. La MCU tiene 2 canales SPI

Fuente de la imagen: raspberrypi.com/documentation/microcontrollers/images/pico-pinout.svg

Ambos canales tienen funciones repartidas en gran parte del pinout. En STM32 esta distribución se puede definir claramente en los archivos de pinout, para evitar conflictos con el hardware, sin embargo, como en ESP32, esta potencial configuración es bastante limitada a la forma en la que se define la variante.

Hasta el momento no he conseguido de lea y escriba en la eeprom 24LC512, las librerías convencionales (AT24Cxx, EEPROM) no las he podido hacer funcionar. Creo que de momento no la contaré en el arreglo.

Los ejemplos básicos de la librería Eeprom que vienen en el setup de la R-Pi Pico, permiten emular en la memoria flash, una pequeña memora eeprom, con ella creo que será posible utilizar los primeros 25 registros para almacenar el vector táctil de la pantalla.

Para borrar el vector-táctil de 25 registros

/*
   EEPROM Write

   Stores values read from analog input 0 into the EEPROM.
   These values will stay in the EEPROM when the board is
   turned off and may be retrieved later by another sketch.
*/

#include <EEPROM.h>

// the current address in the EEPROM (i.e. which byte
// we're going to write to next)
int addr = 0;

void setup() {
  Serial.begin(115200);
  EEPROM.begin(512);
}

void loop() {
  // need to divide by 4 because analog inputs range from
  // 0 to 1023 and each byte of the EEPROM can only hold a
  // value from 0 to 255.
  //int val = analogRead(A0) / 4;
  int val = 0;

  // write the value to the appropriate byte of the EEPROM.
  // these values will remain there when the board is
  // turned off.
  EEPROM.write(addr, val);

  // advance to the next address.  there are 512 bytes in
  // the EEPROM, so go back to 0 when we hit 512.
  // save all changes to the flash.
  addr = addr + 1;
  if (addr == 26) {
    addr = 0;
    if (EEPROM.commit()) {
      Serial.println("EEPROM successfully committed");
    } else {
      Serial.println("ERROR! EEPROM commit failed");
    }
  }

  delay(100);
}

Para lectura del vector-táctil con 25 registros

/*
   EEPROM Read

   Reads the value of each byte of the EEPROM and prints it
   to the computer.
   This example code is in the public domain.
*/

#include <EEPROM.h>

// start reading from the first byte (address 0) of the EEPROM
int address = 0;
byte value;

void setup() {
  // initialize serial and wait for port to open:
  Serial.begin(115200);
  EEPROM.begin(512);
  Serial.println("Eeprom-Flash Test");
}

void loop() {
  // read a byte from the current address of the EEPROM
  value = EEPROM.read(address);

  Serial.print(address);
  Serial.print("\t");
  Serial.print(value, DEC);
  Serial.println();

  // advance to the next address of the EEPROM
  address = address + 1;

  // there are only 512 bytes of EEPROM, from 0 to 511, so if we're
  // on address 512, wrap around to address 0
  if (address == 25) {
    address = 0;
  }

  delay(500);
}

He comprobado que ambos sketches funcionan. Servirán para la calibración del panel táctil de la pantalla. De momento está en la MCU, el que permite borrar el vector táctil, así que el primer registro tiene almacenado el valor "0". Teóricamente al conseguir que la pantalla funcione con GDSTx, lo primero que mostrará será la rutina de calibración del panel. (¡Vaya aun no sé si funcionará y ya me estoy imaginando lo que veré primero en la pantalla, XD!)

Este día lo dedicaré a modificar la librería para conseguir insertar los parámetros de la placa R-Pi Pico, que, dicho sea de paso, se puede identificar con la siguiente línea:

#if defined(ARDUINO_ARCH_RP2040)

Con ella en mente ya veo el camino que debo seguir. Conforme obtenga avances los iré reportando.

[TFTLCDCyg]

Lector MicroSD en el segundo bus de la placa R-Pi Pico

Usar un solo bus SPI no funciona en la Pico, como lo plantea la librería original para Gameduino 3, de la que parte GDSTx. En algunas placas de control como en las STM32, no hay respuesta de la pantalla cuando se conectan el TFT y el lector microSD al mismo bus SPI.

La placa rPi-pico cuenta con dos puertos SPI, el pinout por default es:

SPI0 : MISO-GP16, MOSI-GP19, SCK- GP18, CS-GP17
SPI1 : MISO-GP12, MOSI-GP15, SCK- GP14, CS-GP13

(Fuente: archivo pins_arduino.h que viene en la variante rpipico del paquete principal para rp2040)

Para conectar el TFT usaré el bus SPI0, mientras que para conectar el lector microSD lo haré en el bus SPI1. SPI0 es el bus al que refiere directamente la biblioteca SPI.h, por lo que no hay que modificar las rutinas de control en la librería GDSTx.

En el archivo wiring se puede conservar el inicio del bus de control del TFT con estas dos líneas

    SPI.begin();
    SPI.beginTransaction(SPISettings(SetSPISpeed, MSBFIRST, SPI_MODE0));

Afortunadamente ese llamado es común para teensy, ESP32, ESP8266, arduino y STM32

En el caso del bus SPI1, debemos especificarlo para que a librería SdFat se configure correctamente.

Por experiencia previa en STM32, la librería SdFat requiere que se especifique el bus en el que está conectado el lector:

#define SD_CONFIG SdSpiConfig(SD_PIN, DEDICATED_SPI, SD_SCK_MHZ(SetSDSpeed), &SPI1)
SdFs SD;

Cuando la librería GDSTx activa el soporte para el lector, r-Pi Pico lo puede hacer con la misma instrucción para STM32:

SD.begin(SD_CONFIG);

Para verificar el funcionamiento del lector microSD con una memoria de 64 Gb, se puede usar el siguiente ejemplo (SdInfo) que viene en la librería SdFat, ajustando las lineas de configuración para el bus SPI1:

// SDCARD_SS_PIN is defined for the built-in SD on some boards.
#ifndef SDCARD_SS_PIN
const uint8_t SD_CS_PIN = 13;       //CS del bus SPI1 en R-Pi Pico
#else   // SDCARD_SS_PIN
const uint8_t SD_CS_PIN = SDCARD_SS_PIN;
#endif  // SDCARD_SS_PIN

// Try to select the best SD card configuration.
#if HAS_SDIO_CLASS
#define SD_CONFIG SdioConfig(FIFO_SDIO)
#elif ENABLE_DEDICATED_SPI
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SD_SCK_MHZ(16), &SPI1)   //bus SPI1
#else  // HAS_SDIO_CLASS
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, SHARED_SPI, SD_SCK_MHZ(16), &SPI1)
#endif  // HAS_SDIO_CLASS

De otra forma, las instrucciones que usa GDSTx de la biblioteca SPI serán para SPI0, afortunadamente la librería administra el TFT y el lector microSD de forma paralela, solo hay que definir el llamado de cada uno con las instrucciones correctas. Ya he conectado el lector microSD al bus SPI1, cruzando los dedos....

¡Realmente funciona!. Detectó la memoria de 64 Gb en el lector conectado en el segundo bus SPI de la placa

Toca conectar el TFT en SPI0 y verificar el almacenamiento del vector táctil en la eeprom emulada, claro, luego de conseguir que el TFT responda.

[TFTLCDCyg]

Ajustes en GDSTx

Toca el turno al TFT. Pretendo que la librería pueda controlar tanto la pantalla NHD de 4.3" (y de forma general chips FT81X), como al propio gameduino 3.

Hace tiempo logré aislar los parámetros de configuración del TFT del shield:

//Gameduino3 shield
if (GameduinoX==1){
	GD.wr32(REG_HCYCLE,        548);
	GD.wr32(REG_VCYCLE,        292);    
    cmd_regwrite(REG_OUTBITS,  666);
    cmd_regwrite(REG_DITHER,     1);
    cmd_regwrite(REG_ROTATE,     ROTACION);
    cmd_regwrite(REG_PCLK_POL,   1); //1 gameduino 23X   0 FT801/FT800/FT81x
    cmd_regwrite(REG_PCLK,       5);
   }

Es posible aplicar los tiempos de la pantalla NHD de 4.3" (NHD43) a los tiempos del TFT del gameduino 3, pero todavía tengo pendiente agregar un parámetro a la configuración (config.h): REG_SWIZZLE. En el TFT NHD43, esta es la configuración:

//TFT NHD FT813   4.3"
if (SizeEVE==43)
  {
	cmd_setrotate(ORIENTACION);
	GD.wr32(REG_HSIZE,  480);//480
	GD.wr32(REG_HCYCLE, 548);//548
	GD.wr32(REG_HOFFSET, 43);//43
	GD.wr32(REG_HSYNC0,   0);//0
	GD.wr32(REG_HSYNC1,  41);//41

	GD.wr32(REG_VSIZE,  272);//272
	GD.wr32(REG_VCYCLE, 292);//292
	GD.wr32(REG_VOFFSET, 12);//12
	GD.wr32(REG_VSYNC0,   0);//0
	GD.wr32(REG_VSYNC1,  10);//10

	GD.wr32(REG_PCLK,     5);//5
        GD.wr32(REG_SWIZZLE,  0);
	 
	GD.wr32(REG_PCLK_POL, 1);//1
	GD.wr32(REG_CSPREAD,  1);//1
	GD.wr32(REG_DITHER,   1);//1
	//GD.wr(REG_ROTATE, 0);
  }

Me parece que para el shield el valor de REG_SWIZZLE es 3. Para tener en cuenta si está conectado o no el gameduino 3, considero conveniente agregar una variable en el archivo config.h, y otra variable más que permita realizar o no la carga de la rutina de calibración. También exploraré hasta dónde es posible llevar la frecuencia del bus SPI0. Esta es la primera secuencia que voy a trabajar para la r-Pi Pico:

#if defined(ARDUINO_ARCH_RP2040)

	#define SizeEVE             43   
	
	#define ORIENTACION     	 0   // 0, 1, 2, 3, FT81X/BT81X   0 normal  
	#define ROTACION        	 0   // 0,1         FT80x

    #define CS 			        17   // SPI0 rPi-Pico
	
	#define NHDTouch 		     1   // 1 cargar rutinas panel táctil    0 para NHD: aparentemente no lo requiere?¿  Revisar funcionamiento de EEPROM en Pi-Pico, para ajustar vector táctil
	#define GameduinoX           0   // 1 gameduinoX shield instalado  0 otros como NHD43

#endif

En el archivo GDSTx.h, únicamente agregaré la siguiente secuencia para ajustar las frecuencias de SPI0 y SPI1:

#if defined(ARDUINO_ARCH_RP2040)                              //*******************************************************RP2040-Pico
  #if (SizeEVE==43)
   #define SetSPISpeed   		  24000000   //SPI0
  #endif

  #define SD_PIN 			      13         //SPI1
  #define SetSDSpeed       	 	  24
#endif                                                        //*******************************************************RP2040-Pico

No es necesario modificar nada más.

En GDSTx.ccp es necesario configurar SPI1 para permitir el acceso al lector microSD, para que funcione con SdFat con lo aprendido en el ejemplo SdInfo. Al inicio agregaré estas líneas:

#if defined(ARDUINO_ARCH_RP2040)                              //*******************************************************RP2040-Pico
   #include "EEPROM.h"
   #define SD_CONFIG SdSpiConfig(SD_PIN, DEDICATED_SPI, SD_SCK_MHZ(SetSDSpeed), &SPI1)     //Bus SPI-1
   SdFs SD;                                                              //type 3   
#endif                                                        //*******************************************************RP2040-Pico

La función GD.begin, debe permitir el acceso al lector microSD, agregando la línea:

#if defined(ARDUINO_ARCH_RP2040)                              //*******************************************************RP2040-Pico
	SD.begin(SD_CONFIG);
#endif                                                        //*******************************************************RP2040-Pico

Luego debe poder cargarse la tabla de tiempos de NHD43 o bien la correspondiente al gameduino 3, tomando en cuenta la diferencia en REG_SWIZZLE que permite ajustar la secuencia RGB para cada TFT, ya que tienen un orden diferente

//TFT NHD FT813   4.3"
if (SizeEVE==43)
  {
	cmd_setrotate(ORIENTACION);
	GD.wr32(REG_HSIZE,  480);//480
	GD.wr32(REG_HCYCLE, 548);//548
	GD.wr32(REG_HOFFSET, 43);//43
	GD.wr32(REG_HSYNC0,   0);//0
	GD.wr32(REG_HSYNC1,  41);//41

	GD.wr32(REG_VSIZE,  272);//272
	GD.wr32(REG_VCYCLE, 292);//292
	GD.wr32(REG_VOFFSET, 12);//12
	GD.wr32(REG_VSYNC0,   0);//0
	GD.wr32(REG_VSYNC1,  10);//10

	GD.wr32(REG_PCLK,     5);//5
	if (GameduinoX==0)
     {
 	    GD.wr32(REG_SWIZZLE,  0);// NHD43
	 }
	if (GameduinoX==1)
     {
 	    GD.wr32(REG_SWIZZLE,  3);//gameduino 3
	 }	 
	 
	GD.wr32(REG_PCLK_POL, 1);//1
	GD.wr32(REG_CSPREAD,  1);//1
	GD.wr32(REG_DITHER,   1);//1
	//GD.wr(REG_ROTATE, 0);
  }

Toca el turno al vector táctil. Este vector de una dimensión tiene 25 registros. El primero se consulta para determinar si se debe cargar la rutina de calibración o no. Si el vector está vacío tendrá el valor de 0. Durante la rutina de calibración, cada parámetro debe almacenarse en secuencia en alguno de los registros de memoria designados en el chip EVEx, en este caso es en el registro: REG_TOUCH_TRANSFORM_A. Al finalizar la calibración, el primer registro tomará el valor 1.

De esta forma no es necesario calibrar la pantalla cada vez que se conecta o cada vez que se sube un sketch al MCU.

Generalmente este vector se puede almacenar en una eeprom, aprovechando que los valores se ubican entre 0 y 255. La r-Pi Pico no tiene una eeprom física, se puede agregar una externa, pero hasta ahora no he conseguido que funcione la 24LC512 que pretendía conectar.

Afortunadamente es posible una emular eeprom en la memoria flash. Como el vector solo se crea una vez, no hay problema con la frecuencia de sobreescritura, la librería puede consultar el primer registro del vector para obtener el estatus. La secuencia de consulta queda así:

#if defined(ARDUINO_ARCH_RP2040)
 EEPROM.begin(512);   //eeprom emulada en r-Pi Pico
 if (NHDTouch==1)
 {  	  	
  if (EEPROM.read(0) == 0) 
   {
      self_calibrate();
      for (int i = 0; i < 24; i++)
        {
         EEPROM.write(1 + i, GDTR.rd(REG_TOUCH_TRANSFORM_A + i));
        }
      EEPROM.write(0, 1);
	  EEPROM.commit();       //finaliza y guarda cambios en la eeprom emulada
    } else {
      for (int i = 0; i < 24; i++)
        {
         GDTR.wr(REG_TOUCH_TRANSFORM_A + i, EEPROM.read(1 + i));
        }
           }	
  }
#endif

En el archivo wiring.h solo hay que agregar estas líneas al inicio:

#if defined(ARDUINO_ARCH_RP2040)
	pinMode(SD_PIN, OUTPUT);
    digitalWrite(SD_PIN, HIGH);
  #endif

Creo que son todos los ajustes en GDSTx, en cuanto tenga un tiempo, cablearé el bus SPI0 al cabezal de 20 pines en que conectaré el TFT. Como el vector de memoria está vacío lo primero que debería mostrar la pantalla es la rutina de calibración del panel táctil y luego el skecth de bech de carga de imágenes jpg que diseñé para probar panel táctil, funcionamiento de la microSD y rendimiento del MCU, otra vez a cruzar los dedos...

[TFTLCDCyg]

ILI9341+ R-Pi Pico con SdFat

En el proceso para agregar nuevas placas para usar con la librería GDSTx, siempre me aseguro de que funcionen bien con SdFat, como esta librería ha sido muy útil junto con GFX (para ILI9341, ILI9488, ST7735, etc), para la carga de imágenes bmp desde una microSD, decidí dar una pausa.

Hoy conecté en SPI0 una ILI9341 de 3.2" en el PCB con la Rpi-pico y la microSD conectada a SPI1...

Y vaya que responde muy bien. Solo resta terminar de conectar el cabezal para la NHD43.

Por cierto, junto con los cambios hechos en la librería GFX a funciones como writePixel, writeFillRect, writeFastVLine, writeFastHLine y writeLine se les debe iniciar con startWrite() y finalizar con endWrite()

Por alguna razón también la función setAddrWindow debe seguir esa estructura para funcionar correctamente, así es como se ven las imágenes sin esa corrección:

Esta es la secuencia que se debe utilizar para que el desplazamiento de imágenes y que el cambio de rotación de la pantalla responda correctamente

        tft.startWrite();
          tft.setAddrWindow(x, y, w, h);
        tft.endWrite();

Pico_spitftbitmap_SdFat_desplazamiento_correctoXD.zip (883.6 KB)

SPI0    ili9341
SCK      18
MISO     16
MOSI     19
CS       17
RST      21
DC       20

SPI1    microSD
SCK      14
MISO     12
MOSI     15
CS       13

3V3, GND

[TFTLCDCyg]

Hice pruebas con una oled SSD1331, responde a la librería SdFat y con el uso de las instrucciones start/end Write para setAdrrWindow, el desplazamiento de las imágenes bmp es correcto:

[TFTLCDCyg]

He estado algo ocupado con el trabajo. Recién retomo el proyecto, pero mi placa Pi pico, sufrió algún desperfecto en estos días, se le cayó el botón de plástico del reset. Viene en camino una placa de repuesto, a ver si la lluvia permite la llegada de la paquetería en los siguientes días.

Los que acaban de llegar son un par de sensores de temperatura con conexión G 1/4", uno lo voy a instalar en el bloque de agua para la tarjeta gráfica, que está por llegar. El otro lo colocaré en el depósito de agua de la refrigeración líquida.

El fabricante solo indica que es un sensor tipo termistor NTC de 10K a 25ºC. No indica más información, ni proporciona otros datos. Con ayuda de un multímetro medí la resistencia a diferentes temperaturas, para saber cómo se deben manejar los datos obtenidos del sensor en la placa teensy 4.1.

Habilité un divisor de voltaje resistivo con una resistencia SMD de 10K en el PCB del controlador, con la finalidad de leer el dato del punto de unión del sensor NTC con la resistencia unido al un pin analógico de la teensy 4.1. La otra terminal de la resistencia va conectada a 3.3V y la otra terminal del sensor NTC a GND. Estos son los resultados:

Dado que el rango de lectura oscilará entre 17 y 50 ºC, creo que bastará con una interpolación lineal. No obstante, realizaré más mediciones dentro del rango de lectura para afinar la ecuación de correlación

[TFTLCDCyg]

Estuve construyendo un nuevo soporte para la pantalla NHD de 5" FT813 recién llegada a la mesa de pruebas. Por fin lo he terminado.

La adquirí porque el fabricante renovó su línea de pantallas EVE, utilizando paneles IPS, que presentan un mejor ángulo de visión, lo que me viene muy bien para el nuevo panel de control de ventiladores en el que estoy trabajando, con el que realizaré la gestión de la refrigeración líquida de la PC.

De todas las pantallas de este tipo que he testeado, esta variante FT813, es la mejor, ya que el circuito de salida de audio es el que menor ruido tiene.

Manejo de celdas

He estado realizando más pruebas para el manejo de íconos en arreglos de celdas verticales en formato png, mediante la herramienta de conversión de assets creada por James para la librería del gameduino. Es posible usar imágenes con trasparencias.

Empecé las pruebas con íconos de 128x128 px pero ocuparon demasiada memoria GRAM y resultan ser demasiado grandes para presentarlos en pantalla.

La plantilla tendrá 22 íconos, con las celdas de 128x128, solo se pueden mostrar bien 10 íconos.

Al reducir las dimensiones de la plantilla a celdas de 80x80, se pueden mostrar correctamente los 22 íconos, si afectar el espacio en GRAM de la imagen de fondo:

Para usar la herramienta de creación de assets hay que utilizar la linea de comandos del sistema, accediendo a la carpeta donde se encuentra la herramienta gd3asset, mediante una linea similar a esta:

gd3asset -o IC80.h IC80.png

En esta línea IC80.h, es el archivo de salida, IC80.png es el arreglo vertical de celdas de 80x80 px.

Dejo el ejemplo para pruebas posteriores
Cells_80x80.zip (417.1 KB)

[TFTLCDCyg]

Llegó el primer ventilador PWM que habilitaré en el radiador 360: NF-F12 industrialPPC-3000. Tiene unas especificaciones tremendas, que apenas si se puede detener con las manos sin estar conectado:

121x120x25 mm, a prueba de agua, PWM, 750 a 3000 RPM, caudal máximo de 317 CFM, con apenas 3.6W de consumo, ni la mitad de lo que consume una bomba de alto desempeño como la MCP35X.

Instalaré los componentes necesarios para poder controlarlo con la pantalla NHD-FT813 de 5" recién conectada al teensy 4.1

[Surbyte]

Eso para tu PC?

[TFTLCDCyg]

Si es para la PC, para mejorar el radiador de enfriamiento. Es el primer ventilador de 3. La alimentación será desde la fuente de la PC. Usaré un rele mecánico como medio de suministro del voltaje al ventilador.

Adapté de forma rápida el programa de encendido/apagado y control PWM para la pantalla

¡¡¡Funciona muy bien!!!

Se pueden definir puntos fijos PWM y en todo momento es posible realizar el control manual. La interfaz es muy simple, más adelante mejoraré los gráficos

[TFTLCDCyg]

Finalmente pude conseguir que la placa R-Pi Pico responda para controlar la pantalla NHD de 3.5" FT813

La pantalla está conectada a SPI0 y el lector microSD a SPI1. Aunque Pi-Pico no está soportada oficialmente por SdFat, funciona perfectamente en GDSTx para manejar los archivos multimedia desde el lector microSD. Pueden utilizarse memorias microSD formateadas en exFAT o en FAT32

[Surbyte]

Que gran trabajo @TFTLCDCyg !!

[MaximoEsfuerzo]

¡Sos un monstruo!

[TFTLCDCyg]

Gracias, espero que algún entusiasta que nos visite, le sea de utilidad en sus proyectos.

Me tomó algún tiempo hacer que funcione esta parte de la librería, ya que actualicé algunos componentes de la PC y me ocupé en el trabajo.

Me dio muchos problemas de estabilidad, y alguno que otro conflicto con la librería Audio.h del teensyduino, pensé que la Pico y la teensy 4.1 no se llevarían bien en la misma librería, sin embargo, logré compaginar ambas MCU para que las dos funcionen sin ningún ajuste extra, tanto con SdFat instalado en la carpeta de librerías del IDE de Arduino, como con la versión SdFat que viene en el teensyduino.

La clave es separar los puertos SPI como en las placas STM32. El bus SPI1 de la placa Pico está limitado a 24 MHz, más allá de esa velocidad, el lector microSD externo deja de responder. SPI0 puede funcionar a 36 MHz.

Acá dejo el link al repositorio de Github de GDSTx, con los cambios 100% funcionales para FT81X y BT81X. No he probado con FT80x, específicamente el FT801 de Riverdi o la FT843 (FT800, de 4DSystems). Son dos pruebas que tengo pendientes con la Pico

[TFTLCDCyg]

Luego de varias pruebas de rendimiento, me ha sorprendido lo rápida que resultó ser la R-Pi Pico. Supuse erróneamente que al usar el segundo bus SPI (SPI1) para conectar un lector microSD externo, tendría en las manos un bus recortado, como ha ocurrido en las STM32 que podido probar. Parece que ambos buses SPI son rápidos. La carga de imágenes jpg siempre es complicada, sobre todo cuando las dimensiones entre imágenes no son idénticas. GDSTx cuenta con un ejemplo para medir la capacidad de carga de imágenes consecutivas. Estos son algunos resultados, agregue la prueba con la Pico

MCU: teensy 3.2
TFT: NHD 5" FT813
MicroSD: SanDisk 8 Gb

MCU: R-Pi Pico
TFT: NHD 3.5" FT813
MicroSD: Canvas Select Plus 64 Gb

MCU: Nucleo F767
TFT: NHD 5" FT813
MicroSD: Canvas Select Plus 64 Gb

MCU: teensy 4.1
TFT: NHD 5" FT813
MicroSD: Canvas Go Plus 256 Gb