Using a Teensy to drive a video or slideshow LCD

Status
Not open for further replies.

NKG

Member
Hi, and thanks for maintaining this forum. I've been looking through some of the previous posts and it looks amazing.

I'd like to put this out here, though. I'm building a model of the space pod from 2001: a Space Odyssey, and I want to get working display monitors in the cockpit. This means six tiny 16x16mm screens.

The problem is the ST7789-based 1.54" TFT LCD and Adafruit Feather solution I've tried is simply no good. The redraw is so low that bitmaps come rolling down like curtains. The movie displays switched from screen to screen instantly.

Thus I need either a slideshow with extremely rapid (perhaps buffered?) image loading, or full-on movie playback. I'd prefer the former. It's really not that complicated - I just want to display a bunch of previously created colour bitmaps in a loop, ideally with variable timing between each one.

Would anyone have any suggestions on how I could do this with a Teensy? I've seen the code by Max MC Costa, and that looks very interesting, but I'm not sure if it can do what I need. More than one LCD/OLED driven by the same microcontroller would of course be a great bonus!

Thanks for any tips!

- NKG
 
The 2.8" ILI9341 from PJRC.com has room [~43mm x ~58mm] for 6 masked 16mmx16mm windows and it has good optimized drawing to a T_3.2 - it can do multiple units with unique CS pins as well. It can play movies

Not sure if that speaks to the 'model' question?

Another fast SPI display is the 1.44" ILI9163 - it has maybe 25x28 screen area - and it should have working BMP code too.
 
Thanks so much for taking the time to reply; much appreciated!

I admit my original question wasn’t super clear. I’m basically looking for a combination of screen, microcontroller, and code infrastructure that can display either brief movie loops or a series of still images without visible redraw. (ie: each slide must snap onto the screen effectively instantly - the viewer mustn’t be able to see a slow descending curtain as the next bitmap loads in)

As for screen size - I definitely wasn’t clear! The six screens aren’t all next to each other, so multiple LCDs/OLEDs would be required. One pair of the six has each display angled to the other, and thus two panels at least 16x16mm in size would be needed. The other two pairs are about 2mm apart and so either you’d need two 16x16 screens with enough clearance between them, or one screen at least 16x34mm in size.

So either 5 or 6 small screens are needed. Hence any way of driving multiple screens from one controller would be great.

Thanks again!
 
There is a smaller 2.2" version of the ILI9341 - that would hold two 'screens' each and using the same controller would update quickly. PJRC doesn't stock them (or plan to again) at this time AFAIK. I don't have one at hand it seems - but they are non touch (should seem brighter) and large enough for 2*26 x 16 mm in at least one direction.

Those smaller 9163's with fewer pixels should work ( IIRC they could updated at 100+ fps) as well and update quickly with the library I found linked here on the forum. These could be the two extra screens. Though spacing them 2mm apart might be an issue.

I assume you don't need all the power of a T_3.5 or T_3.6 - but with their dual SPI it might help with connectivity. Though IIRC the T_3.2 has enough CS pins to run 4 or 5 on a single SPI bus. That is assuming you can get both libraries to run together - which I don't think I tried.

The author of the 9163 lib hasn't been around lately and bitmaps were a bit of a puzzle - but that may have cleared up - or it may have just been me.
 
Thanks for the reply! Definitely more stuff to look into.

It’d be awesome if anyone with experience running optimized code to display rapidly-drawn bitmaps, or full-on motion video, could comment. I’ve seen a few sample YouTube videos, but not much by the way of tutorials for less experienced folks like me. There’s the Adafruit animated eyeball example, but it’s presented as something of a canned project.

Thanks again.
 
I'd use a ILI9341-driven SPI display, like the one Paul sells, or its smaller brother. They have the best support here in this forum and can be very fast.
Then, choose the right controller for your project.
I'd use one with enough memory to store the bitmap in the ram -> T3.6. The ili9341_t3 library has a function to copy a memory block to the display. Reading from SD and displaying adds accesstime for the SDCard.
Better is to read the entire file into the RAM and to copy it then from there to the display.
"moving pictures" should'nt be different files per frame - perhaps create your own file format with the raw data frame after frame in the same file.
Depending on the resulting size, it may be possible to store all in an external SPI Flash chip - this is faster than SD, too.
All this need high SPI speeds, and therefore short cables are important. Try to make the connections as short as possible.
 
Thanks for the suggestion! The ILI9341 LCDs look interesting, and are certainly affordable. But most of the ones I've seen are too large to fit the model. Most seem around 2.4" to 3.2" diagonal. That's why I was looking at Adafruit's ST7789 based LCD - 1.54" diagonal is a better match for the double screens.

The screenshot here should give a sense of what I'm looking for. The two middle screens are not on the same plane, so each would require an LCD at least 14x14mm in size. The outer pairs are on the same plane, and are 16x16mm in size, with a 2mm separator. So a single LCD at least 16x34mm would work.

*01_14_3400309.jpg

I appreciate the coding suggestions, though I'd have to say that designing my own raw file format is kind of beyond my abilities. Well, that's not true. Utterly beyond my abilities. :)
 
I suspect optimizing 6 displays might be too much for the Teensy.

First of all there is a special optimization for optimizing some displays on the Teensy. In order to use it, you have to use the optimized drivers, and you must use 5 special pins and SPI (there are 9 possible pins you can use, but 4 of the pins overlap with other pins). You need to use both the D/C and CS pins from this set. You can share the D/C pin, but the CS must be separate for each display. This optimization uses DMA to speed up the display. However, using this it means you can only drive 4 displays (4 CS pins plus a D/C pin).

Besides running out of pins, you might run out of memory to hold the frames, etc.

Paul talks about the special pins in:

The uncanny eyes program written by Phillip Burgess (of Adafruit) and it is based on the optimizations Paul originally did for the ILI9341 display (and this optimization has since been ported to a few other displays):

IIRC, when I last measured it, I was seeing 85 frames/second when I used 2 TFT ST7735 128x128 displays (using a Teensy 3.2), and it dropped to something like 40 frames/second when I switched to two SSD-1391 OLED 128x128 displays with a Teensy 3.5.

Since Phillip Burgess wrote the uncanny eyes program, the Adafruit ST7735 driver offered by PJRC.COM has languished, and there hasn't been any recently ports to it in the last few years. This means the ST7789 devices aren't included in the current PJRC.COM driver. Thus you have a choice, you can use the PJRC driver on the older displays or you can use the Adafruit driver and get the newer display support but that does not have the special Teensy optimization.

I haven't really watched the 2001 movie since I saw in the mid 1970's, so I don't remember precisely what the displays showed. But if it is mostly text based, you might want to look at the smaller intelligent displays that you just send commands, instead of redrawing the whole screen, such as digi-ole (this cuts down a lot on the communication overhead):

I would imagine you might want the units with flash memory, because you might be able to pre-load the frames you want to display.

You might want to look around for displays with the FT810 or newer chip inside. The one I know about is gamedunio3, but at the moment it is sold out, and it is larger than you want (one option might be to use a larger display and just put a mask over it to make it look like 6 smaller displays):
 
Last edited:
Thanks for the detailed reply! Very interesting and useful. :)

A shame that codebase hasn’t been kept up - I’d have thought that rapid display functionality is something a lot of projects could benefit from as a standard feature. The slow “windowscreen” loading effect is really quite objectionable for a lot of things, surely! And the ability to display video on tiny screens is a pretty useful thing.

I’ll have a look further. It seems 1.8” diagonal displays are a reasonable size to cover the two pairs of side displays in the model without wasting too much screen area and the accompanying drop in resolution. And if one microcontroller can drive two screens that at least could make things a bit easier perhaps.

Anyway. Thanks for the comments, everybody! Being fairly new at this sort of thing and not exactly being adept at optimizing video drivers I was hoping for a solution out there that might be closer to turnkey, but perhaps I’ll figure something out... :)
 
Status
Not open for further replies.
Back
Top