ILI9488 3.5 inch TFT

The red 3.5 inch 320x480 SPI TFT with an XPT2046 touch panel: an ILI9488 that takes 18-bit color only, three bytes a pixel.

It has fourteen pins down its edge, in the same order as the 2.8 inch ILI9341 touch board. Aliases: ILI9488, 3.5 inch TFT, 3.5 inch LCD, MSP3520.

To touch it, press on the picture while the circuit runs, and drag to move your finger. Let go and the finger lifts.

Pins

Pin	What it does
`VCC`, `GND`	Supply and ground. The board runs from 3.3 V, or 5 V through its regulator.
`CS`	The display's chip select, active low.
`RST`	The display's reset, active low.
`DC`	The display's command or data line (`RS` on some boards).
`MOSI`, `SCK`	The display's SPI data in (`SDI`) and clock.
`LED`	The backlight. Low puts it out; left unwired, it is on.
`MISO`	The display's data out (`SDO`), never driven here. Leave it unconnected.
`T_CLK`, `T_CS`, `T_DIN`, `T_DO`	The XPT2046 touch controller's SPI bus and chip select.
`T_IRQ`	Low while the panel is pressed.

The touch pins may be left unwired when the sketch does not read the touch.

Properties

None.

What the model gets right

18-bit color. The ILI9488's SPI interface has two pixel formats, 3 bits and 18 bits; the 16-bit RGB565 that the ILI9341 and the ST7796S take is not one of them. So drivers for it send COLMOD 0x66 and three bytes a pixel, red, green and blue, each in the top bits of its byte, and that is what the part takes. A driver that sends 0x55 and two bytes a pixel, an ILI9341 driver pointed at this board, gets two pixels for every three it meant, in the wrong colors, as on the bench. The 3-bit mode, two pixels a byte, works too.

Speed. Three bytes a pixel is half as many again as RGB565, so a full-screen fill takes longer than on the ST7796S. With TFT_eSPI on an ESP32 here, fillScreen() takes 261 ms on the ILI9488 and 192 ms on the ST7796S.

Rotation. setRotation() writes MADCTL, and the picture turns: 320x480 in rotations 0 and 2, 480x320 in 1 and 3.

The touch. The XPT2046 is the 2.8 inch board's: readings come from where your finger is on the glass, about 200 at one edge and 3900 at the other. In TFT_eSPI's rotation 0 (MADCTL's MX), the picture's columns run from the glass's far edge, so a bigger raw X is further left.

The start-up sequences TFT_eSPI and the ILI9488 library send (gamma, power, VCOM, frame rate) are taken and change nothing on the glass, because they set analog voltages the simulation does not have.

What it does not model

Reads: nothing answers on MISO, so readPixel() gives black. On the bench the ILI9488's SDO does not let go of the line when CS is high, which is why the display's MISO is left unconnected when the touch controller shares the bus. Vertical scrolling, partial mode, the gamma tables and the BGR bit. The parallel (8 and 16-bit) versions of the board.

Code

#define ILI9488_DRIVER
#define TFT_MISO 19
#define TFT_MOSI 23
#define TFT_SCLK 18
#define TFT_CS   15
#define TFT_DC    2
#define TFT_RST   4
#define TOUCH_CS 21
#include <TFT_eSPI.h>

TFT_eSPI tft = TFT_eSPI();

void setup() {
  tft.init();
  tft.setRotation(1);           // 480x320
  tft.fillScreen(TFT_BLACK);
  tft.setTextColor(TFT_WHITE, TFT_BLACK);
  tft.drawString("ILI9488, 18-bit color", 10, 10, 4);
}

void loop() {}

TFT_eSPI reads its driver and pins from User_Setup.h; in Mokxi they are #defines above the #include, with the same names. ILI9488.h, the Adafruit-style ILI9488 library (ILI9488 tft(cs, dc, rst)), works too, on any board.

Common mistakes

An ILI9341 driver, or ILI9341_DRIVER in TFT_eSPI, on this board: wrong colors and a squeezed picture. Use ILI9488_DRIVER. The display's MISO wired to the same pin as the touch controller's T_DO: on a real board the touch readings then come back as garbage. Expecting it to be as fast as a 2.8 inch ILI9341: it has twice the pixels and three bytes each.

See it in action

ESP32 ILI9488 touch paint at /templates: an ESP32 DevKit draws a palette and paints where you press. Press Run and draw on the glass.