A 480 x 272, 16-bit SPI panel needs about 62.7 Mbit/s to show 30 fps video, roughly four to eight times what an 8 to 16 Mbit/s SPI link carries. Shield-class wiring cannot play real video from an SD card. Pick a graphics-controller module with quad SPI, a wider parallel feed, or a ready signage display that plays the card itself.
No, not as real video. A shield that shifts every pixel from the microcontroller to the glass over plain SPI runs out of bandwidth long before a clip runs smoothly. Full-screen 480 x 272 frames at 16 bits per pixel need about 63 Mbit/s at 30 fps. A small board clocking SPI at the usual rates moves 8 to 16 Mbit/s, a shortfall of four to eight times. The card is not the problem, the bus is. To play motion on this class of panel you need one of three other builds: a graphics-controller module that composes frames in its own memory, a wider parallel or bridge feed, or a ready signage display that plays the card by itself. Below is the bandwidth arithmetic, the options compared, and the decision for each case.
The number that decides it
Plain SPI moves one bit per clock, so a bus clocked in MHz carries that many Mbit/s. Small microcontroller builds run 8 to 16 MHz. Practical reports sit near or below the clock rate: an estimate for a small panel driven by a microcontroller with DMA puts a 16 Mbit/s link at about 17 fps, falling to about 11 fps when the pixels travel in an 18-bit color format. One single-board-computer build reports about 26 Mbit/s as its stable rate.
Tuning buys a lot and still loses to the arithmetic. A builder who pushed a common SPI controller with DMA measured about 50 Mbit/s as the practical maximum. A display supplier notes that a 320 x 240 panel at 30 fps already sits at the edge of a standard 1-bit SPI bus, which is about 37 Mbit/s of payload. Two documented pushes show where the ceiling is: a case that took SPI-driven video playback from 2 to 35 fps, and a build that holds 60 fps on a small SPI panel from a single-board computer. Full-screen 30 fps at 480 x 272 needs more than any of these rates delivers.
Example: 30 fps from an SD card on a 480 x 272 panel
Take the panel in the question, 4.3 inches diagonally at 480 x 272, and work the payload for 30 fps in 16-bit color:
- Pixels per frame: 480 x 272 = 130,560
- Bits per frame: 130,560 x 16 = 2,088,960 bits, about 2.09 Mbit
- Payload at 30 fps: 2,088,960 x 30 = 62,668,800 bits per second, about 62.7 Mbit/s, before the window-setting command bytes that precede each block of rows
Set that against the bus. A 16 Mbit/s link supplies 16,000,000 bits per second, so the fastest it can carry a full screen is 16,000,000 / 2,088,960 = 7.7 fps, and real rates land below that once overhead and the time spent decoding the file are counted. A link at half that clock manages 3.8 fps.
The shortfall agrees from the other direction: 62.7 Mbit/s is 3.9 times a 16 Mbit/s link and 7.8 times an 8 Mbit/s one. Slowing the film does not fix it. Fifteen fps at full screen still needs 2,088,960 x 15 = 31.3 Mbit/s, about twice the 16 Mbit/s rate, and 24 fps needs 50.1 Mbit/s, which would eat a best-case tuned bus with nothing left for touch polling.
Decision from the numbers: whatever the card and codec supply, plain SPI cannot shift 62.7 Mbit/s of payload to the glass, so full-rate video on shield wiring is out.
The options compared
A build either moves the composing work off the microcontroller's bus or gives up full rate. Four ways this gets done:
| Option | How frames reach the glass | Realistic result | Where it wins |
|---|---|---|---|
| Plain SPI shield as-is | Raw frames shifted bit by bit through the microcontroller | Under 8 fps full screen on a 16 Mbit/s link, less after overhead | Logos, icons, small animated windows |
| Graphics-controller SPI module | The module has its own video memory and composes frames on the chip; the board sends compact draw lists over dual or quad SPI | Full-rate clips: quad SPI at that clock carries 64 Mbit/s, enough for the 62.7 Mbit/s of full-screen 30 fps | Real video inside an existing microcontroller design |
| Parallel or bridge feed | A wider bus, or a second board dedicated to feeding the panel | Tens of Mbit/s, so 30 fps is reachable on some combinations | Keeping the main board while a co-processor drives the glass |
| Ready signage display | The display plays the card's files itself; inputs are confirmed with the quote | Full-rate video with no playback code | A standalone status or notice board at the machine |
Where each option wins
Keep the shield for small motion. Pre-render the clip into raw frames on the card and refresh only the moving window. A 100 x 100 pixel window in 16-bit color is 100 x 100 x 16 = 160,000 bits per frame; at 15 fps that is 2.4 Mbit/s, easily inside a 16 Mbit/s link. This is the same trick as playing an animated GIF on a touchscreen that has no GIF support, and it is the way to get motion out of shield wiring.
Choose the graphics-controller module for real video. Modules built around a dedicated display controller carry their own frame memory, so the microcontroller sends short draw lists and stops shifting two million bits a frame. The multi-bit SPI modes close the bandwidth gap: dual SPI moves 2 bits per clock and quad SPI moves 4, so the same 62.7 Mbit/s fits inside a 16 Mbit/s quad link with 1.3 Mbit/s to spare. Suppliers of these modules sell the panel module, an adapter shield and a flat-flex cable as a set.
Go wider when the design must keep its main board. A parallel interface or a co-processor board dedicated to the glass removes the single-bit ceiling. A general-purpose computer board brings its own playback faults to check; fixing video stutter on a Linux signage player lists the usual causes in the order to test them. Keep ribbon leads short at these clock rates, or the bits arrive smeared.
Use a ready display when the screen stands alone. If the job is a notice or status board showing video beside the line, a ready signage display plays the files itself and the microcontroller keeps its control job. When a file refuses to play there, the cause is usually the file, as covered in why a video plays over USB but not in the player app.
The decision
- Full-rate video, screen standalone: the ready signage display. The card goes in the display, no playback code is written, and the microcontroller keeps its control job.
- Full-rate video inside an existing microcontroller design: the graphics-controller module with its own video memory and quad SPI.
- Short loops and small moving regions on the shield you already have: pre-rendered frames in a window sized to the bus, about 15 fps at 100 x 100 pixels, 7.7 fps full screen on a 16 Mbit/s link.
Recommendation: do not build SD-card video as a plain SPI shield. Pick a graphics-controller module with quad SPI when the display lives inside your microcontroller design, and a ready signage display when the screen is a standalone board at the machine; keep the existing shield for static screens and pre-rendered animation in windows of about 100 x 100 pixels at up to 15 fps.
Questions
Does the SD card limit the frame rate?
No. A 10 fps stream of full 480 x 272, 16-bit frames is about 20.9 Mbit/s, roughly 2.6 MB/s of card bandwidth, which even a basic card moves with room to spare. The bottleneck is the SPI bus between the board and the panel, so a faster card changes nothing. Spend the effort on the bus, the decoder or the display.
Would raising the SPI clock reach 30 fps?
Only a little. Standard SPI in this class is specified up to about 40 to 80 MHz, but 30 fps at 480 x 272 needs about 62.7 Mbit/s of payload, which would consume an 80 MHz single-bit bus entirely before any command bytes. Practical builds land lower still, with reports clustering between about 26 and 50 Mbit/s. A wider or multi-bit bus closes the gap, not a faster clock.
Can I halve the data rate to make it fit?
Yes, by trading area or rate. A quarter of the screen, 240 x 136 pixels, at 30 fps in 16-bit color needs about 15.7 Mbit/s, which a 16 Mbit/s link can just carry. Full screen at 15 fps still needs about 31.3 Mbit/s, about twice that link. Updating only a small window per frame is the reliable way to fit a plain SPI bus.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.