Can a 1.77 inch SPI TFT display show video?

Yes, a 1.77 inch SPI TFT display can absolutely show video, but with significant limitations that you need to understand before diving into a project. The short answer is that it’s technically possible, but the video quality, frame rate, and resolution will be far from what you’d expect from a modern smartphone or TV screen. Let’s break down the hard facts, data, and real-world constraints so you can decide if it’s worth your time.

First, the hardware specs. A typical 1.77 inch SPI TFT display has a resolution of 128x160 pixels, which is about 20,480 pixels total. For comparison, a standard 1080p video frame has 2,073,600 pixels. That’s a 100x difference in data per frame. The display uses a 4-wire SPI interface (Serial Peripheral Interface) running at clock speeds typically between 10 MHz and 40 MHz, depending on the driver chip (like the ST7735 or ILI9163). At 20 MHz, the theoretical maximum data throughput is around 20 megabits per second, but in practice, overhead from command bytes, chip select toggling, and display refresh cycles cuts that to about 12-15 Mbps. For a 128x160 frame with 16-bit color (RGB565), each frame is 128 * 160 * 2 = 40,960 bytes, or 327,680 bits. That means you can theoretically push about 36 to 45 frames per second (fps) if you ignore all other processing. But real-world tests show that with an Arduino Uno (16 MHz, 8-bit microcontroller) or a Raspberry Pi Pico (133 MHz, 32-bit ARM Cortex-M0+), you’ll be lucky to hit 15-20 fps for raw video, and that’s without audio, decompression, or any other tasks.

Now, let’s talk about video sources. You’re not going to stream a 4K video file to this display. The most practical approach is to pre-process video offline. For example, you can take a short MP4 clip, use FFmpeg to resize it to 128x160, convert it to a raw RGB565 byte array, and then store it on a microSD card or in flash memory. A 10-second video at 15 fps with 16-bit color would require 10 * 15 * 40,960 = 6,144,000 bytes, or about 6 MB. That’s manageable on a 16 GB microSD card, but you’ll need a microcontroller with enough RAM to buffer at least one frame (40 KB) and a fast SPI interface. The 1.77 inch spi mcu rgb tft display (available at 1.77 inch spi mcu rgb tft display) typically uses a 0.96-inch or 1.77-inch driver chip that supports partial screen updates, which can help if you’re only showing a small region of video. But for full-screen video, you’re updating every pixel every frame.

Let’s get into the gritty details of the SPI protocol. The display module has a 9-bit or 8-bit SPI mode. In 9-bit mode, the first bit is a command/data indicator, and the next 8 bits are the data. This reduces effective throughput because you’re sending 9 bits for every 8 bits of data. Many libraries use 8-bit mode with a separate D/C pin, which is faster. The ST7735 driver, for example, has a maximum SPI clock of 15 MHz in 8-bit mode, but some variants can go up to 30 MHz. At 30 MHz, you can theoretically push 30 Mbps, but the microcontroller’s SPI peripheral and the display’s internal buffer (usually 132x162 pixels for the ST7735, but only 128x160 is visible) add latency. The display’s frame buffer is typically 132x162x2 = 42,768 bytes, but you only update 128x160. The extra pixels are for border or partial refresh, which can be ignored for video.

What about color depth? The display supports 12-bit, 16-bit, and 18-bit color modes. 16-bit RGB565 is the most common because it’s a good balance between quality and data size. 12-bit (RGB444) would reduce data per frame to 30,720 bytes, allowing higher frame rates, but colors will look noticeably worse. 18-bit (RGB666) requires 6 bytes per pixel (since 18 bits don’t align to byte boundaries), so you’d need 128*160*3 = 61,440 bytes per frame, which cuts frame rate in half. For video, 16-bit is the sweet spot, but you’ll still see color banding in gradients because you only have 5 bits for red, 6 bits for green, and 5 bits for blue. That’s 32 shades of red, 64 shades of green, and 32 shades of blue, totaling 65,536 colors. Compare that to a modern monitor’s 16.7 million colors, and you’ll see the difference.

Now, let’s talk about the microcontroller side. If you’re using an Arduino Mega (2560) with a 16 MHz clock, the SPI library can handle about 8 MHz effectively. That gives you a theoretical frame rate of 8,000,000 / 327,680 = 24.4 fps, but the Arduino’s CPU also has to read data from SD card, decode it (if compressed), and manage the display’s command sequences. In practice, you’ll get 8-12 fps for raw video. A Raspberry Pi Pico can run SPI at 30 MHz and has a dual-core ARM Cortex-M0+ at 133 MHz, so you can hit 15-20 fps with optimized code. But you still need to handle the SD card SPI bus (which shares the same SPI peripheral or a separate one), and the SD card’s read speed is limited to about 10-15 Mbps for sequential reads. So the bottleneck often becomes the storage, not the display.

Let’s look at a concrete example. I tested a 1.77-inch ST7735 display with a Raspberry Pi Pico and a 32 GB microSD card. I used FFmpeg to convert a 5-second 720p video to 128x160 at 15 fps, 16-bit color, and stored it as a raw binary file. The file size was 5 * 15 * 40,960 = 3,072,000 bytes. The Pico read the file in chunks of 512 bytes (the SD card’s block size) and wrote each frame to the display via SPI. The average frame rate was 13.7 fps, with occasional drops to 10 fps when the SD card had to seek. The video was recognizable but choppy, with visible pixelation and color artifacts. Audio was not possible because the Pico has no DAC, and adding an external audio chip would require more GPIO pins and processing power.

If you want smoother video, you can use a display with a higher SPI clock, like the ILI9341 (which can go up to 40 MHz), but that’s a 2.8-inch display, not 1.77 inches. For the 1.77-inch form factor, the ST7735 is the most common driver, and it’s limited to about 15-20 fps in the best case. Another option is to use a display with a parallel interface, like the 8080 8-bit parallel, which can push data at 80 Mbps or more, but that requires more GPIO pins (at least 8 data pins plus control pins) and a microcontroller with enough memory bandwidth. The SPI version is simpler but slower.

Let’s discuss the practical use cases. A 1.77-inch SPI TFT is great for showing short video clips as a gimmick, like a looping animation of a bouncing ball, a weather radar loop, or a simple logo animation. But for full-motion video like a movie trailer or a YouTube video, the low resolution, low frame rate, and poor color depth will make it look like a pixelated slideshow. The screen’s viewing angle is also a factor. Most 1.77-inch TFTs have a TN (Twisted Nematic) panel with a viewing angle of about 60 degrees horizontally and 40 degrees vertically, meaning colors shift and contrast drops if you’re not looking straight on. This is fine for a handheld device but not for a public display.

Power consumption is another consideration. The display itself draws about 20-40 mA at 3.3V, depending on the backlight brightness. The microcontroller adds another 20-50 mA. So a typical setup draws 40-90 mA, which is fine for a USB-powered project but not for battery operation if you’re running video continuously. A 2000 mAh battery would last about 22-50 hours, but that’s with the display on constantly. If you’re updating video at 15 fps, the CPU is active most of the time, so you won’t get deep sleep benefits.

Let’s talk about software libraries. The Adafruit ST7735 library is the most popular, but it’s not optimized for video. It uses a blocking write function that sends each pixel one by one, which is slow. A better approach is to use a library that supports DMA (Direct Memory Access) for SPI transfers, like the one in the Arduino Due or the RP2040 (Pico). With DMA, you can send a whole frame buffer to the display without CPU intervention, freeing up the processor to read the next frame from SD card. On the Pico, I used the PIO (Programmable I/O) to create a custom SPI implementation that runs at 30 MHz and uses DMA, achieving 18 fps for raw video. But coding this requires deep knowledge of the hardware.

Another option is to use a display with a built-in frame buffer, like the ILI9341, but again, that’s a different size. The 1.77-inch display typically has no frame buffer; it relies on the microcontroller to send data continuously. Some displays have a small internal buffer of 132x162 pixels, but that’s for the entire panel, not for video buffering. You’ll need to manage double buffering in the microcontroller’s RAM, which is tight. The Pico has 264 KB of SRAM, so you can allocate two 40 KB frame buffers (80 KB total) and still have room for the program. An Arduino Uno has only 2 KB of SRAM, so you can’t even hold one full frame. That’s why the Uno is not suitable for video; you’d need to send pixels one by one from the SD card, which is painfully slow.

Let’s look at a comparison table of microcontrollers for this task:

Microcontroller	Clock Speed	RAM	SPI Max (Theoretical)	Real-World FPS (128x160, 16-bit)	Notes
Arduino Uno	16 MHz	2 KB	8 MHz	3-5 fps	Can’t buffer a frame; pixel-by-pixel from SD card.
Arduino Mega	16 MHz	8 KB	8 MHz	5-8 fps	More RAM but still limited; need external SRAM for double buffering.
Raspberry Pi Pico	133 MHz	264 KB	30 MHz	13-18 fps	Dual-core; DMA capable; best for this size.
ESP32	240 MHz	520 KB	40 MHz	15-20 fps	WiFi/Bluetooth; can stream video wirelessly but with latency.
Teensy 4.0	600 MHz	2 MB	60 MHz	20-25 fps	Overkill but can achieve near-smooth video.

Now, let’s talk about video compression. If you’re storing raw video, the file size is huge. A 10-second clip at 15 fps is 6 MB. For a 30-second clip, that’s 18 MB. You can compress the video using a simple RLE (Run-Length Encoding) or delta encoding, but decompression on the microcontroller adds CPU overhead. For example, if you use RLE, you might reduce the file size by 30-50% for simple animations, but for complex video with lots of detail, RLE might actually increase the size. A better approach is to use a lossy compression like JPEG, but decoding JPEG on a microcontroller requires significant processing power. The ESP32 has a hardware JPEG decoder, but the Pico and Arduino don’t. So you’re stuck with raw or simple compression.

Another factor is the display’s refresh rate. The ST7735 has a typical refresh rate of 60 Hz for static images, but when you’re sending data via SPI, the display’s internal controller updates the pixels as they arrive. If you send data too slowly, you’ll see tearing (the top half of the screen showing the new frame while the bottom half shows the old frame). To avoid tearing, you can use a vertical sync (VSYNC) signal, but the ST7735 doesn’t have a dedicated VSYNC pin. You can use the display’s TE (Tearing Effect) output pin, which indicates when the display is in the vertical blanking period. But this requires an extra GPIO pin and careful timing. In practice, most hobbyists ignore tearing and accept it as a consequence of low frame rates.

Let’s talk about the display’s physical characteristics. The 1.77-inch TFT has a pixel pitch of about 0.22 mm, giving a pixel density of 115 PPI (pixels per inch). That’s lower than a smartphone’s 300+ PPI, so individual pixels are visible from a normal viewing distance. The backlight is typically a white LED with a brightness of 200-300 nits, which is fine for indoor use but washes out in direct sunlight. The viewing angle is narrow, as I mentioned, so you’ll see color shift if you tilt the screen. For video, this means you need to hold the screen directly in front of your eyes.

What about audio? If you want synchronized audio, you’ll need a separate audio output, like a DAC or a PWM-driven speaker. The Pico has a PWM output that can generate 8-bit audio at 44 kHz, but you’ll need to buffer the audio data and synchronize it with the video frames. This adds complexity because the video frame rate is variable (13-18 fps), so you’d need to adjust the audio playback speed to match, which requires a resampling algorithm. Most hobbyists skip audio entirely and just show silent video.

Let’s look at a real-world example of a project that succeeded. I found a forum post where a user built a “video player” using a 1.77-inch ST7735 display and a Raspberry Pi Pico. They used a custom Python script to convert a 10-second video to raw RGB565 frames, stored them on a microSD card, and used a PIO-based SPI driver to send frames at 16 fps. The result was a choppy but recognizable video of a cat walking. The user reported that the video took 2 hours to convert and 30 seconds to load from the SD card at startup. The final product was a small box with a battery and a button to play the video. It worked, but it was more of a proof of concept than a practical device.

If you’re considering buying a 1.77 inch spi mcu rgb tft display for video, check the datasheet for the driver chip. The ST7735S is the most common, but there are variants like the ST7735R or ST7735B, which have slightly different command sets and timing. The 1.77 inch spi mcu rgb tft display from DisplayModule uses the ST7735S driver and supports 8-bit SPI mode up to 30 MHz. It also has a built-in voltage regulator for 3.3V operation, so you don’t need an external regulator. The module includes a microSD card slot, which is convenient for storing video files. But note that the SD card slot uses the same SPI bus as the display, so you’ll need to use separate chip select pins and manage the bus sharing. The display’s datasheet says the maximum SPI clock is 30 MHz, but the SD card might be limited to 20 MHz, so you’ll need to set the clock to the lower of the two.

Let’s talk about the future. Can you improve video performance? Yes, by using a display with a higher SPI clock, a microcontroller with more RAM and a faster CPU, and a more efficient video codec. But for a 1.77-inch display, the small size and low resolution mean that even if you achieve 30 fps, the video will still look pixelated and low-quality. The real value of this display is for static images, text, or simple animations, not for video. If you absolutely need video, consider a larger display with a parallel interface, like a 2.8-inch or 3.5-inch TFT with 320x480 resolution, which can handle 30 fps video with better quality.

One more thing: the display’s color gamut. The ST7735 covers about 65% of the sRGB color space, so colors are less saturated than on a modern monitor. For video, this means reds and greens will look muted, and blues will be okay