Shield TFT LCD de 3,5 pulgadas: una pantalla de 480 × 320 en un bus rápido de 8 bits

La mayoría de las pantallas pequeñas para aficionados hablan SPI: una línea de reloj, una de datos y cada byte obligado a colarse por ella bit a bit. El shield rojo de 3,5 pulgadas de este artículo funciona de otra manera. Dale la vuelta y, en lugar de MOSI y SCK, encontrarás ocho líneas de datos, de LCD_D0 a LCD_D7, así que cada ciclo de reloj lleva un byte entero. Súmale 480 × 320 píxeles, una capa táctil resistiva y una ranura microSD, y tienes una de las pantallas más grandes que se enchufan directamente a un Arduino Uno sin un solo cable.

Merece la pena mirarlo de cerca aunque nunca hayas tenido un Uno. Lo conectamos a un ESP32-S3 con un periférico 8080 por hardware, pusimos el bus a 20 MHz y reprodujimos vídeo a pantalla completa, 480 × 320, desde una tarjeta microSD a 25 fotogramas por segundo; puedes verlo en el apartado sobre la velocidad. A continuación: qué hay en la placa, cómo funciona su bus y cómo programarlo, de dónde sale la velocidad y dónde se pierde, y qué construir con él, desde una estación meteorológica hasta un marco de fotos y un panel de pared.

De qué placa se habla exactamente

Las tiendas lo venden como «3.5 inch TFT LCD Shield for Arduino UNO/Mega», y varias fábricas hacen placas que se parecen, pero cuyos componentes difieren. El ejemplar de este artículo tiene una PCB roja con la serigrafía 3.5″ TFT LCD Shield y el código de fecha 2026-01-27. Su detalle más revelador está en una esquina: dos casillas impresas con ILI9488 e ILI9486, y ninguna de las dos marcada. El controlador en sí es de tipo chip-on-glass y queda oculto bajo el panel, así que la placa no te dice cuál de los dos lleva.

Nuestro ejemplar muestra una imagen correcta y estable con la secuencia de inicialización del ILI9488, así que lo más probable es que lleve un ILI9488. Es una hipótesis de trabajo, no una identificación: los dos controladores comparten los comandos básicos, y con la secuencia equivocada a menudo también sale imagen, solo que con poco contraste o con parpadeo. Otra placa de la misma tienda puede llevar el otro chip. En el anverso hay una capa táctil resistiva de 4 hilos, con una cinta flexible de cuatro contactos a lo largo del borde superior y el cristal marcado H1454 7-3. En ninguna parte de la placa hay un chip controlador táctil.

Características técnicas

Primero, un poco de aritmética. Un fotograma son 480 × 320 = 153 600 píxeles: 460 800 bytes a tres bytes por píxel y 307 200 a dos. El bus de 8 bits mueve un byte por cada pulso de escritura, así que a 20 MHz transporta 20 millones de bytes por segundo y un fotograma completo tarda 23 ms, o 15,4 ms a dos bytes por píxel. El SPI mueve un bit por ciclo de reloj. A 20 MHz, el límite que fija la hoja de datos del ILI9488 para su interfaz SPI, el mismo fotograma tarda 184 ms, e incluso con overclock a 40 MHz tarda 92 ms.

Los pines: conecta según la etiqueta

El shield sigue la disposición del Arduino Uno, pero las etiquetas importan más que los números del Uno. El byte de datos está repartido de una forma que sorprende a muchos: de LCD_D2 a LCD_D7 van en los pines D2 a D7 del Uno, mientras que LCD_D0 y LCD_D1 se han movido a D8 y D9 para que D0 y D1 queden libres para el puerto serie del Uno.

Hay dos trampas en las que cae mucha gente. Las etiquetas solo están impresas en el reverso, así que, con la pantalla hacia ti, las filas izquierda y derecha se intercambian: conecta estrictamente según la etiqueta, nunca según la posición. Y en un Uno el shield lo ocupa casi todo. Lo que queda son D0 y D1, que son el puerto serie, el A5 sin etiqueta y los pines SPI compartidos con la tarjeta de memoria. El I²C desaparece, porque A4, el SDA del Uno, es LCD_RST. Por eso una estación meteorológica con un par de sensores pide un Mega o, mejor aún, una placa de 32 bits con cables de puente.

Cómo se comunica el bus de 8 bits

El bus es de tipo Intel 8080, el que la hoja de datos del ILI9488 llama DBI Type B. No tiene reloj en el sentido del SPI: el host pone un byte en D0–D7 y da un pulso en WR, y el panel toma el byte en el flanco de subida. RS indica qué es ese byte: 0 para un comando y 1 para un parámetro o datos de píxel. CS delimita la transacción, RST reinicia el controlador y RD es el pulso de lectura.

Ese es todo el protocolo. Un comando sale con RS en bajo y sus parámetros le siguen con RS en alto. Los píxeles no se distinguen de los parámetros: tras el comando RAMWR, 0x2C, cada byte enviado con RS en alto va a parar a la memoria del panel, y el flujo puede durar todo lo que el host quiera.

Dibujar: una ventana y un flujo

El controlador guarda toda la imagen en su propia memoria y refresca el cristal a partir de ella por sí solo, así que el host solo envía lo que cambia. Para dibujar, abre una ventana: CASET, 0x2A, fija la primera y la última columna, y PASET, 0x2B, la primera y la última fila. Después de RAMWR, los píxeles llenan esa ventana de izquierda a derecha y de arriba abajo, sin coordenadas de por medio. Dos funciones de bus, una para un byte de comando y otra para bytes de datos, son todo lo que hace falta para portar este código:

static void set_window(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1) {
    uint8_t ca[4] = { (uint8_t)(x0 >> 8), (uint8_t)x0,
                      (uint8_t)(x1 >> 8), (uint8_t)x1 };
    uint8_t pa[4] = { (uint8_t)(y0 >> 8), (uint8_t)y0,
                      (uint8_t)(y1 >> 8), (uint8_t)y1 };
    lcd_write_cmd(0x2A); lcd_write_data(ca, 4);   // CASET: columns
    lcd_write_cmd(0x2B); lcd_write_data(pa, 4);   // PASET: rows
}

// A solid rectangle in RGB666: 3 bytes per pixel, one window
static void fill_rect(uint16_t x, uint16_t y, uint16_t w, uint16_t h,
                      uint8_t r, uint8_t g, uint8_t b) {
    const uint8_t px[3] = { r, g, b };
    set_window(x, y, x + w - 1, y + h - 1);
    lcd_write_cmd(0x2C);                           // RAMWR
    for (uint32_t i = 0; i < (uint32_t)w * h; i++) {
        lcd_write_data(px, 3);
    }
}

En la ventana es donde se gana o se pierde la velocidad. Envía tantos píxeles seguidos como puedas dentro de una misma ventana: una ventana por píxel cuesta once bytes de comandos y coordenadas por cada tres bytes de color.

Formatos de píxel y orientación

Dos registros deciden el aspecto de la imagen. COLMOD, 0x3A, fija el formato de píxel. 0x66 es RGB666, tres bytes por píxel con el color en los seis bits altos de cada byte, y es lo que funciona en nuestra placa. 0x55 es RGB565, dos bytes por píxel: las dos hojas de datos lo recogen para el bus paralelo y las bibliotecas más populares lo usan ahí, pero todavía no lo hemos probado en esta unidad. Si los bytes que envías por píxel no coinciden con COLMOD, los rellenos de color liso salen como rayas finas de colores equivocados que cubren solo una parte de la ventana.

MADCTL, 0x36, fija la orientación y el orden de los colores. En esta placa, 0x28 da una imagen horizontal de 480 × 320 correcta y sin reflejar, y el bit BGR que incluye es la razón de que los colores se envíen en el orden R, G, B de siempre. El rojo y el azul intercambiados se corrigen con ese bit, la imagen en espejo con los bits MX y MY y los ejes intercambiados con MV, nunca en el código de la aplicación.

¿ILI9486 o ILI9488?

En teoría, el controlador informa de su identidad: el comando 0xD3 devuelve un byte de relleno seguido de 0x00, 0x94 y 0x86 o 0x88. En la práctica, muchos shields de esta familia son de solo escritura. Sus búferes del bus están cableados en un solo sentido, de la tira de pines al panel, así que nada de lo que dice el panel llega nunca al host. Entonces la popular biblioteca MCUFRIEND_kbv vuelve a leer su propio byte de comando y da como ID 0xD3D3; su sketch de prueba marca ese caso como un shield de solo escritura.

En una placa así, el controlador se identifica a ojo. Inicialízalo con la secuencia del ILI9488 y dibuja rellenos de color liso, degradados de grises y de color y una rejilla de un píxel; después repite con la secuencia del ILI9486 y quédate con la que dé degradados suaves, buen contraste y ningún parpadeo. No hemos intentado leer el ID del nuestro. Con la secuencia del ILI9488 su imagen es correcta, así que esa es la secuencia que va a continuación.

RST: high 50 ms, low 50 ms, high 150 ms             ; hardware reset
0x01                                                ; SWRESET, wait 120 ms
0x28                                                ; DISPOFF
0xE0: 00 03 09 08 16 0A 3F 78 4C 09 0A 08 16 1A 0F  ; positive gamma
0xE1: 00 16 19 03 0F 05 32 45 46 04 0E 0D 35 37 0F  ; negative gamma
0xC0: 17 15                                         ; power control 1
0xC1: 41                                            ; power control 2
0xC5: 00 12 80                                      ; VCOM control
0x36: 48                                            ; MADCTL: portrait, BGR
0x3A: 66                                            ; COLMOD: RGB666
0xB0: 00                                            ; interface mode
0xB1: A0                                            ; frame rate
0xB4: 02                                            ; inversion control
0xB6: 02 02 3B                                      ; display function
0xB7: C6                                            ; entry mode
0xF7: A9 51 2C 82                                   ; adjust control 3
0x11                                                ; SLPOUT, wait 120 ms
0x29                                                ; DISPON, wait 25 ms
0x36: 28                                            ; MADCTL: landscape

De dónde sale la velocidad

El SPI mueve un bit por ciclo de reloj. El bus de 8 bits mueve un byte. Con el mismo reloj, eso son ocho veces más datos, y esa es toda la razón de que esta interfaz a la antigua siga viva: necesita trece pines en lugar de cuatro o cinco, pero llena una pantalla grande en una fracción del tiempo.

Además, con esta familia concreta de controladores el SPI parte con desventaja. Por SPI, el ILI9486 solo acepta el color completo en formato de 18 bits, y aunque la hoja de datos del ILI9488 recoge color de 16 bits en su modo SPI de 4 hilos, en la práctica estos chips se manejan con tres bytes por píxel, que es justo lo que hacen las bibliotecas más populares. La misma hoja de datos limita el reloj de escritura SPI del ILI9488 a 20 MHz. Para su bus paralelo admite un ciclo de escritura de 40 ns, es decir, 25 MHz, así que nuestros 20 MHz quedan dentro de la especificación. El ILI9486 es más lento: su hoja de datos pide al menos 66 ns por escritura, unos 15 MHz. Si resulta que tu placa lleva ese chip, empieza por debajo de esa cifra.

Eso sí, el bus solo es tan rápido como el host que lo maneja. Conmutar trece pines uno a uno con digitalWrite() convierte la interfaz más rápida de la placa en una de las más lentas. Escribir registros de puerto completos es mucho mejor, y un periférico de hardware con DMA es lo mejor de todo: el LCD_CAM de un ESP32-S3, el PIO de un RP2040 o el FSMC de un STM32 envían los bytes por su cuenta mientras el procesador prepara los siguientes.

Nuestra prueba: vídeo a 25 fps desde una tarjeta microSD

El host fue la ESP32-S3-CAM N16R8 de nuestro artículo anterior, conectada al shield con cables de puente. En esa placa, las 13 líneas del bus ocuparon GPIO que normalmente usa la cámara, así que la cámara se quedó fuera de esta prueba. El bus funcionó con el driver esp_lcd i80 de ESP-IDF sobre el periférico LCD_CAM del S3, con un reloj de escritura de 20 MHz, la secuencia del ILI9488, RGB666 y orientación horizontal. Dos búferes DMA de 30 720 bytes, suficientes para 10 240 píxeles cada uno, se turnan: mientras uno va camino del panel, el otro se está llenando.

El reproductor reparte el trabajo entre los dos núcleos. Uno lee archivos MJPEG de la propia tarjeta microSD de la placa; el otro decodifica cada fotograma con la biblioteca JPEGDEC y vuelca los bloques decodificados directamente en los búferes DMA, convirtiendo RGB565 en RGB666 por el camino. El resultado es vídeo estable a pantalla completa, 480 × 320, a 25 fotogramas por segundo. De los 40 ms que puede durar cada fotograma, el bus necesita 23. Por SPI con overclock a 40 MHz, el mismo fotograma necesitaría 92 ms solo en el bus, así que los 25 fps quedarían fuera de alcance antes de decodificar un solo píxel.

Para configurar el bus hacen falta dos estructuras. Así lo hace nuestro driver. RD no interviene para nada: esp_lcd no tiene vía de lectura, así que un GPIO normal se limita a mantener RD en alto.

esp_lcd_i80_bus_config_t bus_config = {};
bus_config.dc_gpio_num = PIN_LCD_RS;
bus_config.wr_gpio_num = PIN_LCD_WR;
bus_config.clk_src = LCD_CLK_SRC_PLL160M;
bus_config.data_gpio_nums[0] = PIN_LCD_D0;     // likewise [1] to [7]
bus_config.bus_width = 8;
// One DMA chunk: 32 lines of 320 pixels in RGB666
bus_config.max_transfer_bytes = 320 * 32 * 3;
esp_lcd_new_i80_bus(&bus_config, &i80_bus);

esp_lcd_panel_io_i80_config_t io_config = {};
io_config.cs_gpio_num = PIN_LCD_CS;
io_config.pclk_hz = 20 * 1000 * 1000;          // 20 MHz write clock
io_config.trans_queue_depth = 10;
io_config.lcd_cmd_bits = 8;
io_config.lcd_param_bits = 8;
io_config.dc_levels.dc_cmd_level = 0;          // RS low: command
io_config.dc_levels.dc_data_level = 1;         // RS high: data
esp_lcd_new_panel_io_i80(i80_bus, &io_config, &io_handle);

A partir de ahí, esp_lcd_panel_io_tx_param() envía los comandos con sus parámetros y esp_lcd_panel_io_tx_color() pone en cola los datos de píxel para el DMA y vuelve de inmediato. Ahí está también la trampa: un búfer no debe volver a llenarse antes de que termine su transferencia, o saldrán bloques de la imagen corruptos.

Quedan dos límites. Con los ajustes habituales, el controlador refresca el cristal desde su memoria unas 60 veces por segundo, y el shield no saca la señal de tearing effect que permitiría al host sincronizar sus escrituras con ese refresco, así que en los movimientos rápidos puede verse una línea de corte. Y un búfer de fotograma completo, 460 800 bytes en RGB666, solo cabe en una PSRAM externa, y por eso nuestro driver envía en su lugar trozos pequeños desde la memoria interna.

Qué host y qué biblioteca

El shield se diseñó para el Uno, pero el Uno es el hogar más lento que puede tener. La tabla resume las vías habituales; la guía de programación del final recoge las restricciones de pines de cada una.

Sea cual sea el host, planifica los pines pensando en la parte táctil: la capa comparte líneas con la pantalla y sus extremos analógicos necesitan pines con ADC. Lo vemos más abajo.

En un Uno, la forma más rápida de empezar es MCUFRIEND_kbv. Nosotros no hemos ejecutado este sketch en un Uno: es la vía estándar de la biblioteca, con un añadido para las placas de solo escritura.

#include <Adafruit_GFX.h>
#include <MCUFRIEND_kbv.h>

MCUFRIEND_kbv tft;

void setup() {
  Serial.begin(9600);
  uint16_t id = tft.readID();
  Serial.print(F("ID = 0x"));
  Serial.println(id, HEX);
  // A write-only shield reads back 0xD3D3: name the controller yourself
  if (id == 0xD3D3) id = 0x9488;
  tft.begin(id);
  tft.setRotation(1);              // landscape, 480 × 320
  tft.fillScreen(0x0000);          // black
  tft.setTextColor(0x07E0);        // green
  tft.setTextSize(3);
  tft.setCursor(24, 24);
  tft.print(F("Hello, 480 x 320"));
}

void loop() {}

Táctil sin controlador táctil

La capa táctil es la clásica resistiva de 4 hilos: dos láminas resistivas que se tocan donde presionas. No hay un XPT2046 ni un chip parecido que la lea. En su lugar, sus cuatro electrodos van conectados a líneas que la pantalla ya usa, y el host los mide con su propio ADC. Aplica una tensión a lo largo de una lámina y lee en qué punto hace contacto la otra; luego intercambia los papeles para el otro eje.

Qué líneas llevan los electrodos varía de una placa a otra, y en la nuestra todavía no las hemos localizado. En los shields de esta familia, los extremos analógicos suelen estar en LCD_WR, LCD_RS o LCD_CS, y los digitales, en líneas de datos como LCD_D6 y LCD_D7. Con un multímetro se encuentran en un minuto: con la placa sin alimentación, dos pares entre las líneas de control y las de datos marcan unos cientos de ohmios, alrededor de 300 en una lámina y 500 en la otra.

Leer la capa táctil significa, por tanto, tomar prestados esos pines a la pantalla. Espera a que el bus esté inactivo, mantén inactiva la línea de control que no es un electrodo para que el panel ignore el ruido, toma varias muestras y devuelve cada pin a su función de pantalla antes de la siguiente transferencia. Si te saltas ese último paso, obtendrás píxeles aleatorios y una pantalla congelada. Con un periférico de hardware como LCD_CAM es todavía más difícil, porque los pines hay que liberarlos del periférico y volver a conectarlos, así que decide cómo vas a leer la capa táctil antes de fijar el mapa de pines. Además, la capa táctil prefiere objetivos grandes: los botones del tamaño de la yema de un dedo le van mucho mejor que una interfaz al estilo de un móvil.

microSD, alimentación y retroiluminación

La ranura microSD tiene sus propias líneas SPI, SD_CS, SD_DI, SD_DO y SD_SCK, en los pines D10 a D13 del Uno, eléctricamente separadas del bus de la pantalla. En cualquier otro host puede ir a cualquier pin que admita SPI. No la hemos probado en esta unidad: para el vídeo de arriba, el ESP32-S3 leyó la ranura de su propia placa. Si no la usas, deja sus líneas sin conectar o mantén SD_CS en alto.

La alimentación entra como 5 V por el pin 5V. El regulador de la placa genera 3,3 V para el panel y los búferes, y un host de 3,3 V maneja la lógica directamente. No toques el pin 3V3 de la tira: se desconoce a dónde está conectado y no sustituye a la alimentación de 5 V. La retroiluminación no tiene pin de control y permanece encendida mientras la placa recibe alimentación, así que no se puede atenuar ni apagar por software; DISPOFF y SLPIN borran la imagen, no la luz. No hemos medido la corriente. Como referencia aproximada, la especificación del panel de un shield para Uno parecido, también de 3,5 pulgadas, da 90 mA típicos para su retroiluminación de seis LED, así que con una fuente USB floja o con el pequeño regulador de una placa de desarrollo conviene comprobarlo con un amperímetro.

Qué construir con él

480 × 320 es un tamaño cómodo: lo bastante grande para una gráfica con rótulos legibles, una foto o una fila de botones del tamaño de una yema, y lo bastante pequeño para llenarlo deprisa. Por eso esta clase de pantalla aparece una y otra vez en proyectos, tanto en este mismo shield como en sus parientes.

1. Una estación meteorológica

El montaje más popular de todos. En el proyecto de Instructables Second Multi-functional Weather Station, un Arduino Mega lleva justo este tipo de shield de 3,5 pulgadas con ILI9486, junto con un reloj DS3231 y sensores DHT22 y BMP280, y usa la ranura de tarjeta del shield para un álbum de fotos de unas mil imágenes convertidas a BMP. Otros montajes prescinden por completo de los sensores. En el blog thesolaruniverse, un ESP32 con un shield de 3,95 pulgadas del mismo diseño obtiene el tiempo de OpenWeatherMap por Wi‑Fi y lo dibuja a través del bus de 8 bits con TFT_eSPI. Un proyecto de Elektor de diciembre de 2023 hace lo mismo en una placa Makerfabs ESP32-S3 con un ILI9488 de 3,5 pulgadas y lee los ajustes del Wi‑Fi y la ciudad de un archivo en la tarjeta de memoria.

2. Un marco de fotos

La ranura microSD convierte el shield en un marco de fotos casi por sí sola. MCUFRIEND_kbv trae un ejemplo, showBMP, que lee archivos BMP directamente de la tarjeta en los pines 10 a 13 e indica cuánto ha tardado en cargarse cada uno. En un ESP32, el driver esp-idf-parallel-tft de nopnop2002 muestra archivos BMP, JPEG y PNG en los shields de esta familia y además calibra su capa táctil. En las transiciones, como los fundidos y los barridos, es donde el bus paralelo compensa: cada paso de una transición redibuja toda la pantalla, y un fotograma completo cuesta 23 ms en este bus frente a una décima de segundo o más por SPI.

3. Un reproductor de vídeo

Nuestra propia prueba está en el extremo exigente: MJPEG desde una tarjeta a 25 fps. Como punto de partida ya hecho, los ejemplos MJPEG de la biblioteca Arduino_GFX muestran la tasa media de fotogramas y desglosan el tiempo entre lectura, decodificación y dibujo, lo que los convierte en una prueba de rendimiento muy práctica para cualquier placa. Larry Bank, autor de JPEGDEC, el decodificador que usa nuestro reproductor, manejó un viejo shield para Uno de 3,5 pulgadas con ILI9486 desde un RP2040 mediante PIO y DMA y reprodujo en él GIF animados; su artículo se titula Breathing new life into an old LCD shield.

4. Una consola de juegos

Los juegos necesitan justo lo que mejor se le da a este bus: redibujar muchos píxeles muchas veces por segundo. El proyecto ESP32-S3_Uno-nofrendo ejecuta el emulador de NES nofrendo en una placa ESP32-S3 con formato Uno, con un shield ILI9488 de 8 bits enchufado directamente, y carga las ROM desde la tarjeta; todavía no tiene joystick ni sonido. En el extremo más sencillo, un clon de Tetris para Arduino Mega con un shield ILI9486 saca su música por un transmisor FM de coche, así que, para oírla, sintonizas una radio en 87,5 MHz. La serie de tutoriales de Dumblebots construye un programa tipo Paint y un tres en raya sobre el mismo tipo de shield de 3,5 pulgadas, capa táctil incluida.

5. Un panel táctil en la pared

Un panel domótico es el trabajo obvio para una pantalla táctil de este tamaño, y aquí suelen ganar los parientes ya hechos. El WT32-SC01 Plus combina un ESP32-S3 con una pantalla de 3,5 pulgadas y 480 × 320 en el mismo tipo de bus de 8 bits. openHASP lo convierte en un panel controlado por MQTT y construido sobre LVGL, y, con un componente de la comunidad, ESPHome puede manejarlo para Home Assistant. AirQualitySensor-IDF convierte la misma placa en un monitor de calidad del aire: lee sensores de partículas, CO₂, temperatura y humedad y dibuja seis horas de historial con LVGL. Si tienes una impresora 3D, puede que ya tengas una pantalla de esta clase: la Color UI de Marlin funciona en pantallas táctiles de 3,5 pulgadas y 480 × 320 como la MKS TFT35, conectadas al STM32 de la impresora por el bus paralelo FSMC.

6. Instrumentos

La traza de un osciloscopio hay que redibujarla muchas veces por segundo, algo que le va bien a un bus rápido. Un proyecto abierto combina un STM32F303 con una pantalla ILI9486 de 3,5 pulgadas para un osciloscopio de 2 Msps con un registro de 4096 puntos. DLO-138, un firmware abierto para el popular kit DSO-138, maneja la pantalla ILI9341, más pequeña, de ese kit por un bus de 8 bits y lo convierte en un osciloscopio de dos canales con otros dos canales digitales. Para indicadores, medidores y gráficas, TFT_eSPI tiene una carpeta entera de ejemplos escritos para 480 × 320.

Algunas ideas más que la gente ha montado con pantallas de 480 × 320:

• Un navegador GPS sin conexión. IceNav-v3 dibuja mapas de OpenStreetMap sin conexión en un ESP32-S3 y admite paneles ILI9488 por SPI y por buses paralelos de 8 o 16 bits.
• Una pantalla de «ahora suena». El mando para Spotify de ThingPulse muestra la carátula del álbum y adapta el color de fondo a la portada en un ILI9488 de 3,5 pulgadas.
• Una radio con vista de espectro. Un receptor de todas las bandas basado en el chip Si4735 y un ESP32 dibuja un espectro y una cascada en un ILI9488 de 4 pulgadas y 480 × 320.

Parientes: la misma pantalla en otros formatos

El shield pertenece a una familia numerosa. Si su formato o su bus no encajan en un proyecto, puede que encaje alguno de sus parientes. Todos son de 480 × 320, salvo los shields para Uno más pequeños:

Puntos fuertes y débiles

Conclusión

El shield TFT LCD de 3,5 pulgadas parece una reliquia de la época del Arduino Uno, y en un Uno se comporta como tal: ocupa casi todos los pines y llena la pantalla al ritmo de un procesador de 8 bits. Pero dale un host con un buen periférico paralelo y el viejo bus demuestra por qué ha sobrevivido: un byte por ciclo de reloj, un fotograma completo de 480 × 320 en 23 ms, vídeo a 25 fps.

Para una estación meteorológica, un marco de fotos, un panel de control o un pequeño instrumento es más que suficiente, siempre que el primer arranque parta de una configuración que se sepa que funciona:

1. Comprueba que no haya cortocircuitos entre 5V, 3V3 y GND y, al conectar, empieza por GND y por 5 V en el pin 5V.
2. Conecta según las etiquetas del reverso, nunca según la posición, y mantén LCD_RD en alto desde el principio.
3. Usa la secuencia del ILI9488, COLMOD 0x66 y MADCTL 0x28 a 10 MHz o menos.
4. Dibuja primero rellenos de color liso y degradados; si la imagen sale desvaída o parpadea, prueba la secuencia del ILI9486.
5. Sube el reloj poco a poco, hasta 20 MHz con un ILI9488.
6. Añade la capa táctil y la tarjeta microSD al final, de una en una.