Before you read, note that I'm a long-term fan of
Teensy microcontrollers from PJRC and
BuyDisplay IPS display panels and modules. Some say "fanboi", but I do use other stuff also (other microcontrollers, and even more often non-Buydisplay OLED models); I'm just happy with the quality and performance of those.
Also, my solutions often involve some kind of small interface board or something designed in EasyEDA, typically with components such that you can get it made and assembled at JLCPCB or similar. (
Here are past examples.) On the hardware side, I'm only a hobbyist, though.
Is this possible?
Very.
For example,
Adafruit 0.96" 160×80 TFT takes 160×80×16×25 ≃ 5,120,000 bits ≃ 640,000 bytes per second to display video. A microSD card can handle that fine, and SPI running at 8-12 MHz should suffice. Each frame consists of a few bytes of "command" (that varies slightly between different controller chips in the display module), followed by 160×80×2 = 25,600 bytes of data. You do need DMA support, and to be able to transfer the current frame to display while reading the next frame (in uncompressed format – easily done using e.g. ffmpeg tools) from an SD card or via full-speed USB. (Full-speed USB tops out at just under 1Mbytes per second, so at 25fps, so the maximum pixel size is about 160×125.)
Thus, the microcontroller you use needs at least 64k of RAM, and sufficiently high-speed SPI peripheral. (The ST7735S is spec'd to handle SPI up to 15 MHz, 66ns SCLK cycle.) Note that you cannot use the SD card holder in that adapter, because you need the full SPI bandwidth to the display. You'll need a separate SPI bus to an SD card.
Thus, the question is 1) the connection method to the display (SPI suffices for such small resolutions for ~ 25fps), and 2) the microcontroller capabilities.
My preferred solution would be to use a
Teensy 4.1, as it has sufficient speed, RAM, and a built-in SD card socket, to interface to the above display. The Adafruit GFX library would need adapting (or the SPI commands needed to initialize the display and send a full frame of data added to one of the Teensy SPI DMA libraries), but otherwise it should be very straightforward. (If I had one of those displays, I could help you do it, as I do have Teensies myself.)
In fact, I do believe each Teensy 4.1 can handle
two of such SPI-connected displays at the same time, displaying different video streams to both (separately), even for slightly larger resolution displays like the BuyDisplay
0.96" 80×160 or
1.08" 128×220 IPS panels. (IPS giving nice viewing angles.)
For use with the BuyDisplay modules, you'd need to create small interface boards, so you can use 10 to 12-pin FPC or ribbon cable between the display module and the microcontroller, so you can do modeling clay or 3D print to make the display into a real TV, and move the microcontroller to somewhere more accessible. Not too long, though, just a few inches at most. Think behind or inside a wall, not below the entire model.
The interface board needs to provide a current-limited source (around 3.1V to 3.4V, 15-20mA for both of those above), preferably controlled by a PWM'ble signal; the connector or connection (FPC soldered directly to pads) to the display module, and pads or connector for the cable to the microcontroller. I'd use
EasyEDA and have them made and assembled at JLCPCB. The Adafruit module has that board, but I'd prefer the board to be the same size as the display module, so you can use modeling clay or 3D print a TV-looking enclosure for it.
A completely different approach would be to consider is the
LilyGo LCD + ESP32 boards. For example, right now Banggood sells the
TTGO T-Display ESP32 with 1.14" TFT one (135×240) for under 13€ apiece + shipping. Perhaps you could have a small Linux WiFi server (router) to stream the video to the displays in real time, wirelessly? I'm not absolutely certain what kind of frame rates you could get, especially using one server to
N such boards, but looking at the specs, it should work fine. The board shape is not optimal for making into a TV-like unit, though.
With sufficient buffering and not too noisy WiFi environment, a small Linux single-board computer should be able to send 8-10 such streams in parallel, especially if it uses a native SSD; SD cards won't have the small-I/O read bandwidth for more than a couple of streams. I don't use Raspberry Pi's though, I prefer Odroids, Rock Pis, et cetera, without the hardware USB issues Pi's have. Plus I don't like how the Foundation interfaces (or, prefers not to interface
directly to, and obfuscate connections to) the open source software projects their products completely rely on.
You can use various tools to obtain video files, including Youtube downloaders. Wouldn't it be funny to have Dave's videos play there?
The free
ffmpeg command-line tool can decompress, scale, convert the data to RGB, and even write the individual frames as separate PPM files (which basically contain the raw data). You might need a trivial helper that reads the PPM files, converts the color format to 15/16-bit, and saves it as a binary file, possibly including any extra data you might wish to include in the data files (maybe very low volume low-quality audio?), but that's it.
All this is much, much easier to do in Linux than in Windows, though, because of the wealth of existing command-line tools you can chain to get stuff done.
At 25fps, the data stream for
W×
H is about 400×
W×
H bits per second. For all the above suggestions this is below 13 Mbits/s, thus within achievable SPI DMA (given ESP32 or Teensy 4.x or Teensy MicroMod). For the uncompressed 16-bit video stream at 25fps, this is 0.64 Mbytes/s (160×80), 1.41 Mbytes/s (220×128), or 1.62 Mbytes/s (240×135). Correspondingly, one hour of such uncompressed video takes 2.3 Gbytes, 5.1 Gbytes, or 5.8 Gbytes, respectively. If we consider the typical FAT 2GiB file size limit, the playable maximum loop lengths would be 55 minutes, 25 minutes, and 22 minutes, respectively. With an unformatted SD card there would be no such limits, but you'd probably need to use Linux tools (
dd et cetera) to write to the SD cards.
There is one visual effect, though, that the above may suffer from:
tearing.
This is because the display modules update their contents 60 times a second, but the SPI bus cannot update the display more than 20-40 times a second. This means the display will show a mix of two or three frames. If the native display update direction is used, this will split the display horizontally; if the normal display update direction is used, this will split the display vertically. It is very unlikely to be synchronized, so there won't be a tear line at a stable location, it will vary from frame to frame. See page 84 of the
ST7735S datasheet (buydisplay.com) for an illustration.
How noticeable this will be, I do not know.
However, this is the underlying reason why I am using Teensy 4 to interface to larger (2.4", 2.8"; 320×240 or 480×320) versions of these displays using a parallel connection. Teensy 4.x/MicroMod can easily sustain a 320×240×16bit×60 data flow from an USB host even over USB Serial, because it has a high-speed native USB instead of some USB-to-Serial converter chip;
here is the real-world test in the other direction as an example. It also uses a proper SDIO interface (not SPI) to the SD card, so given a good quality microSD card, the data transfer for the raw video is no problem either. The issue is that most display modules' controller chips cannot support fast enough data rates over SPI, so the "8080/6800"-style parallel bus is used instead. Teensy 4.x/MicroMod does have 2×512 KiB (1,048,576 bytes) of RAM, so having two full framebuffers in RAM (480×320×16bpp is 307,200 bytes = 300 KiB), one being received from the host, and another being sent to the display when the TE pin indicates a vertical retrace is starting (so the transfer stays ahead of the display update, and changes the contents of the display before it has been completely displayed). It also means the data must be sent in the native order (short direction contiguous in memory).
I do know that the BuyDisplay
1.44" 128×128 (70°/70°/60°/70° viewing angles) supports a 8-bit parallel data interface and has TE/retrace output pin. The smallest IPS panel I can find is
1.3" 240×240; the
1.69" 280×240 also has rounded corners. All these would give tear-free video, but would need a bit more software work on the Teensy side. Their resolutions are small enough I
believe Teensy 4.1 could drive three of them in parallel (separate videos) using FlexIO shenanigans; two for sure. (The third FlexIO does not support DMA, but the two others and the SDIO interface do; and there are enough I/O pins. So, it is a question of whether the code can do the third update in software, while the two others use DMA, all four (three displays and the SDIO) being asynchronous to each other.)
Limiting oneself to two displays max per Teensy would mean the same stuff would be useful to magiceyes stuff (some experienced Teensy users do Halloween eye tricks using pairs of small displays and a Teensy).
Apologies for the wall of text.
Home
Help
Search
Login
Register
