Can a 2.4 inch 240x320 TFT display show video?

Yes, a 2.4 inch 240x320 TFT display can show video, but with significant limitations. To be clear: it’s not going to stream 4K or even 480p smoothly. The hardware is designed for static images, text, and basic UI elements, not full-motion video. However, under specific conditions—like low frame rates, pre-processed data, and a fast microcontroller—you can get recognizable video playback. The key bottlenecks are the display’s resolution, interface bandwidth, and the controller’s processing power. Let’s break down the numbers so you know exactly what’s possible.

Resolution and Pixel Count

The 2.4 inch 240x320 TFT display has a total of 76,800 pixels. That’s tiny compared to a standard 1080p display (over 2 million pixels). For video, this means you’re working with a very low-resolution canvas. A typical 240p video (like from old YouTube or CCTV feeds) is 320x240, which is close but not identical. The display’s native orientation is 240x320 (portrait), so you’d need to rotate or crop the video to fit. If you’re feeding it a 240x240 square video, 20% of the pixels are wasted. The pixel density is about 167 PPI (pixels per inch), which is decent for small text but not sharp for video. At 2.4 inches, you’ll see individual pixels if you’re closer than 12 inches, but that’s acceptable for a small embedded project.

Interface Speed and Refresh Rate

Most 2.4 inch 240x320 tft display modules use SPI (Serial Peripheral Interface) or parallel MCU interfaces. SPI is common for low-cost microcontrollers like Arduino or ESP32, but it’s slow. A typical SPI clock speed is 20 MHz to 40 MHz. For a 240x320 display with 16-bit color (2 bytes per pixel), each frame is 76,800 pixels * 2 bytes = 153,600 bytes. At 20 MHz SPI, theoretical max throughput is 20 Mbps, but real-world overhead (command bytes, latency, chip select) drops it to about 15 Mbps. That translates to roughly 12 frames per second (FPS) for raw data transfer. But you also need to account for the display controller’s internal refresh rate. The ILI9341, a common controller, has a max refresh of about 60 Hz, but it’s limited by SPI speed. In practice, you’ll get 10-15 FPS with SPI. Parallel interfaces (like 8-bit or 16-bit MCU) can push 30-40 FPS, but they require more GPIO pins and a faster microcontroller.

Color Depth and Memory

These displays support 16-bit RGB565 color (65,536 colors) or 18-bit RGB666 (262,144 colors). For video, 16-bit is standard. Each pixel uses 2 bytes, so a single frame needs 153.6 KB of RAM. If you’re using a microcontroller with 320 KB SRAM (like an ESP32), you can buffer one or two frames. But that leaves little room for code or other data. For smooth playback, you need double buffering (two frame buffers) to avoid tearing. That’s 307 KB, which is tight. Many microcontrollers (like Arduino Uno) have only 2 KB RAM, making video playback impossible without external memory. You’d need a chip like the ESP32, STM32, or Raspberry Pi Pico. Even then, you’re limited to low-resolution, low-color video. For example, a 320x240 video at 15 FPS with 16-bit color requires a data rate of 2.3 MB/s, which exceeds SPI’s real-world capability. So you’d need to reduce color depth (e.g., 8-bit or 4-bit) or lower the resolution further.

Video Source and Encoding

You can’t just stream an MP4 file directly. The display expects raw pixel data (RGB565 or RGB666). You need to decode the video on the microcontroller, which is computationally heavy. A 240x320 video at 10 FPS requires 1.5 MB/s of decoded data. Microcontrollers lack hardware video decoders, so you’d rely on software decoding. For example, an ESP32 at 240 MHz can decode MJPEG (Motion JPEG) at about 5-10 FPS, depending on compression. MJPEG is simpler because each frame is a JPEG image, so you only need a JPEG decoder. But JPEG decoding eats RAM: a 240x320 JPEG frame might take 50-100 KB of working memory. For MPEG or H.264, you’d need a dedicated chip like the ESP32-S3 with hardware JPEG acceleration, or a Raspberry Pi. Pre-processing the video on a PC (e.g., converting to raw RGB565 frames stored in flash memory) is a common workaround. You can store a 10-second video at 10 FPS and 240x320 resolution in about 15 MB of flash. That’s doable with a microSD card or large SPI flash chip.

Practical Performance Data

Here’s a table showing realistic video playback scenarios for a 2.4 inch 240x320 TFT display:

Display Controller Limitations

The display controller (e.g., ILI9341, ST7789) has a fixed refresh rate. For ILI9341, the maximum is 60 Hz, but that’s with a fast parallel interface. With SPI, the controller’s internal line buffer (about 320 pixels) limits how fast you can write data. The controller expects data to be written in a specific order (e.g., column-by-column). If you send data too slowly, tearing occurs—where the top of the screen shows a new frame while the bottom still shows the old one. To avoid tearing, you need to use a vertical blanking interval (VBI) or double buffering. Most microcontrollers don’t support VBI, so double buffering is the only option. That doubles memory requirements. The display’s pixel clock (the speed at which it updates pixels internally) is typically 10-20 MHz. For a 240x320 display, a full frame at 10 MHz pixel clock takes 76,800 / 10,000,000 = 7.68 ms, so a theoretical 130 FPS. But the interface is the bottleneck, not the pixel clock.

Power Consumption and Heat

Playing video increases power draw. The display itself consumes about 50-100 mA at 3.3V (165-330 mW). The microcontroller adds more: an ESP32 at 240 MHz with SPI active draws 100-200 mA. So total power is 300-500 mW. For battery-powered projects, this is significant. A 2000 mAh LiPo battery would last 4-6 hours of continuous video playback. Heat is not a major issue for these displays, but the microcontroller might get warm (40-50°C) under sustained load. The display’s backlight (typically 4-6 LEDs) draws 20-40 mA, which is a fixed cost regardless of video.

Real-World Use Cases

Despite the limitations, people do use these displays for video. Common applications include:

• Animated GIFs: Pre-converted to raw frames, stored in flash. 10-15 FPS is acceptable for simple animations.
• Security camera feeds: Low-resolution, low-frame-rate (5-10 FPS) MJPEG streams from a camera module. The ESP32 with a camera (OV2640) can capture 320x240 video and display it on the TFT.
• Retro game emulation: Game Boy or NES games run at 60 FPS, but the display’s resolution (240x320) is close to the Game Boy’s 160x144. With a fast microcontroller, you can get 30-40 FPS.
• Data visualization: Instead of video, you can display scrolling graphs or waveforms at 20-30 FPS, which looks like video.

Hardware Recommendations

If you’re serious about video, avoid Arduino Uno. Use an ESP32 with PSRAM (8 MB) for frame buffering. Or use a Raspberry Pi Pico with the PIO (Programmable I/O) to drive the display faster. For the best performance, use a parallel interface display with an STM32F4 or Raspberry Pi Zero. The 2.4 inch 240x320 TFT display is a good choice for prototypes because it’s cheap and widely available, but don’t expect Netflix-quality playback. You’ll need to pre-process video on a PC, convert it to raw RGB565, and store it in flash or stream it over serial. The maximum practical video length is limited by storage: a 1-minute video at 10 FPS and 240x320 resolution takes 90 MB of raw data. That’s doable with a microSD card.