Shield TFT LCD de 3,5 polegadas: um ecrã de 480 × 320 num barramento rápido de 8 bits

A maior parte dos pequenos ecrãs usados em projetos de amadores fala SPI: uma linha de relógio, uma linha de dados e cada byte a passar espremido, um bit de cada vez. O shield vermelho de 3,5 polegadas deste artigo funciona de outra maneira. Ao virá-lo, em vez de MOSI e SCK, encontram-se oito linhas de dados, de LCD_D0 a LCD_D7, pelo que cada ciclo de relógio transporta um byte inteiro. Com 480 × 320 píxeis, uma película tátil resistiva e uma ranhura microSD, é um dos maiores ecrãs que encaixam diretamente num Arduino Uno, sem um único fio.

Vale a pena olhar para ele com atenção, mesmo para quem nunca teve um Uno. Ligámo-lo a um ESP32-S3, que tem um periférico 8080 por hardware, pusemos o barramento a 20 MHz e reproduzimos vídeo de 480 × 320 em ecrã inteiro a partir de um cartão microSD, a 25 fotogramas por segundo; o resultado pode ver-se na secção sobre a velocidade. A seguir: o que há na placa, como funciona o seu barramento e como programá-lo, de onde vem a velocidade e onde se perde, e o que construir com ele, de uma estação meteorológica a uma moldura digital ou a um painel de parede.

De que placa se trata

As lojas vendem-no como «3.5 inch TFT LCD Shield for Arduino UNO/Mega», e há várias fábricas a fazer placas que parecem iguais, mas diferem nos componentes. A deste artigo é vermelha, com a serigrafia «3.5″ TFT LCD Shield» e o código de data 2026-01-27. O pormenor mais revelador está num canto: dois quadrados impressos com ILI9488 e ILI9486, e nenhum deles marcado. O controlador propriamente dito está montado em chip-on-glass, escondido debaixo do painel, pelo que a placa não diz qual dos dois traz.

A nossa mostra uma imagem correta e estável com a sequência de inicialização do ILI9488, por isso o mais provável é ser um ILI9488. É uma hipótese de trabalho, não uma identificação: os dois controladores partilham os comandos básicos, e a sequência errada muitas vezes também produz imagem, só que com mau contraste ou cintilação. Outra placa da mesma loja pode trazer o outro chip. Na frente há uma película tátil resistiva de 4 fios, com um cabo flexível de quatro contactos ao longo da margem superior e o vidro marcado H1454 7-3. Não há nenhum chip controlador de toque em toda a placa.

Características técnicas

Primeiro, um pouco de aritmética. Uma imagem tem 480 × 320 = 153 600 píxeis: 460 800 bytes com três bytes por píxel, 307 200 com dois. O barramento de 8 bits move um byte por impulso de escrita, por isso a 20 MHz transporta 20 milhões de bytes por segundo, e uma imagem completa demora 23 ms, ou 15,4 ms com dois bytes por píxel. O SPI move um bit por ciclo de relógio. A 20 MHz, o limite que a folha de características do ILI9488 fixa para a sua interface SPI, a mesma imagem demora 184 ms, e mesmo em overclock a 40 MHz demora 92 ms.

Os pinos: ligar pelas inscrições

O shield segue a disposição do Arduino Uno, mas as inscrições contam mais do que os números do Uno. O byte de dados está repartido de uma forma que surpreende muita gente: LCD_D2 a LCD_D7 ficam nos pinos D2 a D7 do Uno, enquanto LCD_D0 e LCD_D1 passaram para D8 e D9, para que D0 e D1 fiquem livres para a porta série do Uno.

Há duas coisas que apanham muita gente desprevenida. As inscrições estão impressas só no verso, por isso, com o ecrã virado para si, as filas da esquerda e da direita trocam de lado: a ligação faz-se estritamente pelas inscrições, nunca pela posição. E, num Uno, o shield ocupa quase tudo. O que sobra são D0 e D1, que são a porta série, o A5 sem inscrição e os pinos SPI partilhados com o cartão de memória. O I²C desaparece, porque o A4, o SDA do Uno, é o LCD_RST. Por isso, uma estação meteorológica com um par de sensores pede um Mega ou, melhor ainda, uma placa de 32 bits com fios de ligação.

Como fala o barramento de 8 bits

O barramento é do estilo Intel 8080, a que a folha de características do ILI9488 chama DBI Type B. Não tem relógio no sentido do SPI: o anfitrião põe um byte em D0–D7 e dá um impulso em WR, e o painel captura o byte no flanco ascendente. O RS diz o que é o byte: 0 para um comando e 1 para um parâmetro ou dados de píxeis. O CS delimita a transação, o RST repõe o controlador e o RD é o impulso de leitura.

E o protocolo é só isto. Um comando sai com o RS baixo, e os seus parâmetros seguem com o RS alto. Os píxeis não são diferentes dos parâmetros: depois do comando RAMWR, 0x2C, cada byte enviado com o RS alto vai parar à memória do painel, e o fluxo pode continuar o tempo que o anfitrião quiser.

Desenhar: uma janela e um fluxo

O controlador guarda a imagem inteira na sua própria memória e atualiza o vidro a partir dela sozinho, por isso o anfitrião só envia o que muda. Para desenhar, abre uma janela: o CASET, 0x2A, define a primeira e a última coluna, e o PASET, 0x2B, a primeira e a última linha. Depois do RAMWR, os píxeis preenchem essa janela da esquerda para a direita e de cima para baixo, sem coordenadas pelo meio. Duas funções de barramento, uma para um byte de comando e outra para bytes de dados, são tudo o que é preciso para portar o 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);
    }
}

É na janela que a velocidade se ganha ou se perde. Convém enviar o maior número possível de píxeis dentro de uma só janela: uma janela por píxel custa onze bytes de comandos e coordenadas por cada três bytes de cor.

Formatos de píxel e orientação

Dois registos decidem o aspeto da imagem. O COLMOD, 0x3A, define o formato de píxel. 0x66 é RGB666, três bytes por píxel com a cor nos seis bits superiores de cada byte, e é isso que funciona na nossa placa. 0x55 é RGB565, dois bytes por píxel: as duas folhas de características indicam-no para o barramento paralelo e as bibliotecas populares usam-no aí, mas ainda não o testámos neste exemplar. Se os bytes enviados por píxel não corresponderem ao COLMOD, os preenchimentos sólidos saem como riscas finas de cores erradas que cobrem só parte da janela.

O MADCTL, 0x36, define a orientação e a ordem das cores. Nesta placa, 0x28 dá uma imagem horizontal de 480 × 320 correta e sem espelhamento, e é o bit BGR incluído nesse valor que faz as cores seguirem pela ordem simples R, G, B. O vermelho e o azul trocados corrigem-se com esse bit, o espelhamento com os bits MX e MY e os eixos trocados com o MV, nunca no código da aplicação.

ILI9486 ou ILI9488?

Em teoria, o controlador identifica-se: o comando 0xD3 devolve um byte fictício seguido de 0x00, 0x94 e 0x86 ou 0x88. Na prática, muitos shields desta família são só de escrita. Os seus buffers do barramento estão ligados num só sentido, da barra de pinos para o painel, pelo que nada do que o painel diz chega alguma vez ao anfitrião. A popular biblioteca MCUFRIEND_kbv acaba então por ler de volta o seu próprio byte de comando e indica 0xD3D3 como ID; o seu sketch de teste assinala esse caso como um shield só de escrita.

Numa placa assim, o controlador identifica-se a olho. Inicializa-se com a sequência do ILI9488 e desenham-se preenchimentos sólidos, gradientes de cinzento e de cor e uma grelha de um píxel; depois repete-se com a sequência do ILI9486 e fica-se com a que der gradientes suaves, bom contraste e nenhuma cintilação. Não tentámos ler o ID na nossa. Com a sequência do ILI9488 a imagem fica certa, e por isso é essa a sequência que se segue.

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 onde vem a velocidade

O SPI move um bit por ciclo de relógio. O barramento de 8 bits move um byte. Com o mesmo relógio, são oito vezes mais dados, e é só por isso que esta interface antiquada ainda anda por aí: precisa de treze pinos em vez de quatro ou cinco, mas preenche um ecrã grande numa fração do tempo.

Nesta família de controladores em particular, o SPI tem ainda outra desvantagem. Por SPI, o ILI9486 só aceita cor completa em formato de 18 bits, e, embora a folha de características do ILI9488 indique cor de 16 bits para o seu modo SPI de 4 fios, na prática estes chips são comandados com três bytes por píxel, que é exatamente o que fazem as bibliotecas populares. A mesma folha de características limita a 20 MHz o relógio de escrita SPI do ILI9488. O seu barramento paralelo admite um ciclo de escrita de 40 ns, ou seja, 25 MHz, pelo que os nossos 20 MHz ficam dentro da especificação. O ILI9486 é mais lento: a sua folha de características exige pelo menos 66 ns por escrita, cerca de 15 MHz. Se a sua placa tiver afinal esse chip, convém começar abaixo desse valor.

O barramento, porém, só é tão rápido quanto o anfitrião que o comanda. Alternar treze pinos um a um com digitalWrite() transforma a interface mais rápida da placa numa das mais lentas. Escrever registos de porta inteiros é muito melhor, e um periférico por hardware com DMA é o melhor de tudo: o LCD_CAM de um ESP32-S3, o PIO de um RP2040 ou o FSMC de um STM32 enviam os bytes sozinhos enquanto o processador prepara os seguintes.

O nosso teste: vídeo a 25 fps a partir de um cartão microSD

O anfitrião foi a ESP32-S3-CAM N16R8 do nosso artigo anterior, ligada ao shield com fios de ligação. Nessa placa, as 13 linhas do barramento ficaram com GPIO que normalmente são da câmara, pelo que a câmara ficou de fora deste teste. O barramento funcionou com o driver esp_lcd i80 do ESP-IDF, no periférico LCD_CAM do S3, com um relógio de escrita de 20 MHz, a sequência do ILI9488, RGB666 e orientação horizontal. Dois buffers de DMA de 30 720 bytes, que chegam para 10 240 píxeis cada um, revezam-se: enquanto um segue a caminho do painel, o outro vai sendo preenchido.

O leitor reparte o trabalho pelos dois núcleos. Um lê ficheiros MJPEG do cartão microSD da própria placa; o outro descodifica cada fotograma com a biblioteca JPEGDEC e empurra os blocos descodificados diretamente para os buffers de DMA, convertendo RGB565 em RGB666 pelo caminho. O resultado é vídeo estável de 480 × 320 em ecrã inteiro a 25 fotogramas por segundo. Dos 40 ms de que cada fotograma dispõe, o barramento gasta 23. Por SPI em overclock a 40 MHz, o mesmo fotograma precisaria de 92 ms só no barramento, pelo que os 25 fps ficariam fora de alcance antes de se descodificar um único píxel.

Configurar o barramento exige duas estruturas. É assim que o nosso driver o faz. O RD não entra de todo: o esp_lcd não tem caminho de leitura, por isso um GPIO comum limita-se a manter o RD a nível 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 daí, esp_lcd_panel_io_tx_param() envia comandos com os seus parâmetros e esp_lcd_panel_io_tx_color() coloca dados de píxeis na fila do DMA e regressa de imediato. É também aí que está a armadilha: um buffer não pode voltar a ser preenchido antes de a sua transferência terminar, senão saem blocos da imagem corrompidos.

Restam dois limites. Com as definições habituais, o controlador atualiza o vidro a partir da sua memória cerca de 60 vezes por segundo, e o shield não leva aos pinos o sinal de tearing effect que permitiria ao anfitrião sincronizar as escritas com essa atualização, pelo que um movimento rápido pode mostrar uma linha de corte. E um buffer de imagem completo, 460 800 bytes em RGB666, só cabe em PSRAM externa, e é por isso que o nosso driver envia antes pequenos blocos a partir da memória interna.

Que anfitrião, que biblioteca

O shield foi desenhado para o Uno, mas o Uno é a casa mais lenta que pode ter. A tabela resume os caminhos habituais; o guia de programação no fim tem as restrições de pinos de cada um.

Seja qual for o anfitrião, convém planear os pinos a pensar no toque: a película partilha linhas com o ecrã, e os seus terminais analógicos precisam de pinos com ADC. Mais sobre isso adiante.

Num Uno, o arranque mais rápido é com o MCUFRIEND_kbv. Nós próprios não corremos este sketch num Uno: é o caminho habitual da biblioteca, com um acrescento para placas só de escrita.

#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() {}

Toque sem controlador tátil

A película tátil é do tipo resistivo clássico de 4 fios: duas camadas resistivas que se tocam onde se carrega. Não há nenhum XPT2046 ou chip semelhante para a ler. Em vez disso, os seus quatro elétrodos estão ligados a linhas que o ecrã já usa, e o anfitrião mede-os com o seu próprio ADC. Aplica uma tensão a uma das camadas e lê o ponto em que a outra camada lhe toca; depois troca os papéis para o outro eixo.

As linhas que levam os elétrodos variam de placa para placa, e na nossa ainda não as identificámos. Nos shields desta família, os terminais analógicos costumam estar em LCD_WR, LCD_RS ou LCD_CS, e os digitais em linhas de dados como LCD_D6 e LCD_D7. Um multímetro encontra-os num minuto: com a placa sem alimentação, dois pares entre as linhas de controlo e as linhas de dados medem algumas centenas de ohms, cerca de 300 numa camada e 500 na outra.

Ler o toque significa então pedir esses pinos emprestados ao ecrã. Espera-se até o barramento estar em repouso, mantém-se inativa a linha de controlo que não é elétrodo, para que o painel ignore o ruído, recolhem-se várias amostras e devolve-se cada pino ao seu papel no ecrã antes da transferência seguinte. Sem este último passo, o resultado são píxeis aleatórios e um ecrã congelado. Com um periférico por hardware como o LCD_CAM é ainda mais difícil, porque os pinos têm de ser libertados do periférico e voltar a ser associados a ele, por isso convém decidir como se vai ler o toque antes de fixar o mapa de pinos. A película também prefere alvos grandes: botões do tamanho da ponta de um dedo servem-lhe muito melhor do que uma interface ao estilo de um telemóvel.

microSD, alimentação e retroiluminação

A ranhura microSD tem as suas próprias linhas SPI, SD_CS, SD_DI, SD_DO e SD_SCK, nos pinos D10 a D13 do Uno, eletricamente separadas do barramento do ecrã. Em qualquer outro anfitrião, pode ir para quaisquer pinos com SPI. Não a testámos neste exemplar: para o vídeo acima, o ESP32-S3 leu a ranhura da sua própria placa. Se não for usada, deixam-se as suas linhas desligadas ou mantém-se o SD_CS a nível alto.

A alimentação entra como 5 V no pino 5V. O regulador da placa produz 3,3 V para o painel e para os buffers, e um anfitrião de 3,3 V comanda a lógica diretamente. O pino 3V3 é para deixar em paz: não se sabe a que está ligado, e não substitui a alimentação de 5 V. A retroiluminação não tem pino de controlo e fica acesa enquanto a placa tiver alimentação, pelo que não pode ser regulada nem desligada por software; DISPOFF e SLPIN apagam a imagem, não a luz. Não medimos a corrente. Como referência aproximada, a especificação do painel de um shield Uno semelhante de 3,5 polegadas indica 90 mA típicos para a sua retroiluminação de seis LED, pelo que uma alimentação USB fraca ou o pequeno regulador de uma placa de desenvolvimento merecem ser verificados com um amperímetro.

O que construir com ele

480 × 320 é um tamanho confortável: grande o bastante para um gráfico com legendas legíveis, uma fotografia ou uma fila de botões do tamanho da ponta de um dedo, e pequeno o bastante para se preencher depressa. É por isso que esta classe de ecrã aparece constantemente em projetos, tanto neste mesmo shield como nos seus parentes.

1. Uma estação meteorológica

A montagem mais popular de todas. No projeto do Instructables Second Multi-functional Weather Station, um Arduino Mega leva exatamente este tipo de shield ILI9486 de 3,5 polegadas, juntamente com um relógio DS3231 e sensores DHT22 e BMP280, e usa a ranhura de cartão do shield para um álbum de cerca de mil fotografias convertidas para BMP. Outras montagens dispensam por completo os sensores. No blogue thesolaruniverse, um ESP32 com um shield de 3,95 polegadas do mesmo desenho vai buscar o estado do tempo ao OpenWeatherMap por Wi‑Fi e desenha-o através do barramento de 8 bits com o TFT_eSPI. Um projeto da Elektor de dezembro de 2023 faz o mesmo numa placa Makerfabs ESP32-S3 com um ILI9488 de 3,5 polegadas e lê as definições de Wi‑Fi e a cidade de um ficheiro no cartão de memória.

2. Uma moldura digital

A ranhura microSD faz do shield uma moldura quase por si só. O MCUFRIEND_kbv traz um exemplo showBMP que lê ficheiros BMP diretamente do cartão nos pinos 10 a 13 e indica quanto tempo cada um demorou a carregar. Num ESP32, o driver esp-idf-parallel-tft de nopnop2002 mostra ficheiros BMP, JPEG e PNG em shields desta família e também calibra a sua película tátil. É nas transições, como esbatimentos e cortinas, que o barramento paralelo compensa: cada passo de uma transição redesenha o ecrã inteiro, e uma imagem completa custa 23 ms neste barramento, contra um décimo de segundo ou mais por SPI.

3. Um leitor de vídeo

O nosso próprio teste fica no extremo mais pesado: MJPEG de um cartão a 25 fps. Como ponto de partida já feito, os exemplos MJPEG da biblioteca Arduino_GFX mostram a taxa média de fotogramas e repartem o tempo entre leitura, descodificação e desenho, o que os torna uma boa referência de desempenho para qualquer placa. Larry Bank, o autor do JPEGDEC, o descodificador que o nosso leitor usa, comandou um velho shield Uno ILI9486 de 3,5 polegadas a partir de um RP2040 através de PIO e DMA e reproduziu nele GIF animados; o seu artigo chama-se Breathing new life into an old LCD shield.

4. Uma consola de jogos

Os jogos precisam exatamente daquilo em que este barramento é bom: redesenhar muitos píxeis muitas vezes por segundo. O projeto ESP32-S3_Uno-nofrendo corre o emulador de NES nofrendo numa placa ESP32-S3 em formato Uno, com um shield ILI9488 de 8 bits encaixado diretamente, e carrega as ROM a partir do cartão; ainda não tem joystick nem som. No extremo mais simples, um clone do Tetris para Arduino Mega com um shield ILI9486 vai buscar a música a um transmissor FM de automóvel, e para a ouvir sintoniza-se um rádio nos 87,5 MHz. A série de tutoriais da Dumblebots constrói um programa de desenho ao estilo do Paint e um jogo do galo no mesmo tipo de shield de 3,5 polegadas, com película tátil incluída.

5. Um painel tátil na parede

Um painel de casa inteligente é a utilização óbvia para um ecrã tátil deste tamanho, e aqui os parentes já prontos costumam ganhar. O WT32-SC01 Plus junta um ESP32-S3 a um ecrã de 3,5 polegadas e 480 × 320 no mesmo tipo de barramento de 8 bits. O openHASP transforma-o num painel controlado por MQTT e construído sobre LVGL, e, com um componente da comunidade, o ESPHome pode comandá-lo para o Home Assistant. O AirQualitySensor-IDF transforma a mesma placa num monitor da qualidade do ar: lê sensores de partículas, CO₂, temperatura e humidade e desenha seis horas de histórico com LVGL. Quem tem uma impressora 3D pode já ter um ecrã desta classe: o Color UI do Marlin corre em ecrãs táteis de 3,5 polegadas e 480 × 320, como o MKS TFT35, ligados ao STM32 da impressora pelo barramento paralelo FSMC.

6. Instrumentos

O traço de um osciloscópio tem de ser redesenhado muitas vezes por segundo, o que convém a um barramento rápido. Um projeto aberto junta um STM32F303 a um ecrã ILI9486 de 3,5 polegadas para fazer um osciloscópio de 2 Msps com um registo de 4096 pontos. O DLO-138, firmware aberto para o popular kit DSO-138, comanda o ILI9341, mais pequeno, desse kit por um barramento de 8 bits e transforma-o num osciloscópio de dois canais com mais dois canais digitais. Para mostradores, medidores e gráficos, o TFT_eSPI tem uma pasta inteira de exemplos escritos para 480 × 320.

Mais algumas ideias que outros já puseram em prática com ecrãs de 480 × 320:

• Um navegador GPS offline. O IceNav-v3 desenha mapas do OpenStreetMap offline num ESP32-S3 e suporta painéis ILI9488 por SPI e por barramentos paralelos de 8 ou 16 bits.
• Um ecrã «a tocar agora». O comando para Spotify da ThingPulse mostra a capa do álbum e combina a cor de fundo com ela num ILI9488 de 3,5 polegadas.
• Um rádio com vista de espetro. Um recetor de todas as bandas construído com o chip Si4735 e um ESP32 desenha um espetro e uma cascata num ILI9488 de 4 polegadas e 480 × 320.

Parentes: o mesmo ecrã noutros formatos

O shield pertence a uma grande família. Se o seu formato ou o seu barramento não servirem para um projeto, talvez sirva um dos seus parentes. Todos têm 480 × 320, exceto os shields Uno mais pequenos:

Pontos fortes e fracos

Conclusão

O shield TFT LCD de 3,5 polegadas parece uma relíquia da era do Arduino Uno, e num Uno comporta-se como tal: ocupa quase todos os pinos e preenche o ecrã ao ritmo de um processador de 8 bits. Mas, com um anfitrião que tenha um verdadeiro periférico paralelo, o velho barramento mostra porque sobreviveu: um byte por ciclo de relógio, uma imagem completa de 480 × 320 em 23 ms, vídeo a 25 fps.

Para uma estação meteorológica, uma moldura digital, um painel de controlo ou um pequeno instrumento, isso chega e sobra, desde que o primeiro arranque parta de uma configuração comprovada:

1. Verificar se há curto-circuitos entre 5V, 3V3 e GND e, depois, ligar primeiro o GND e os 5 V ao pino 5V.
2. Ligar pelas inscrições do verso, nunca pela posição, e manter o LCD_RD a nível alto desde o início.
3. Usar a sequência do ILI9488, COLMOD 0x66 e MADCTL 0x28 a 10 MHz ou menos.
4. Desenhar primeiro preenchimentos sólidos e gradientes; se a imagem sair desbotada ou cintilar, experimentar a sequência do ILI9486.
5. Subir o relógio passo a passo, até 20 MHz num ILI9488.
6. Acrescentar a película tátil e o cartão microSD no fim, um de cada vez.