High-rez microcontroller displays

Truly MINI screens

I’ve been working for a while on a project that requires very small, very high resolution display screens. Namely, a scratchbuilt miniature of the EVA pod from the film 2001: a Space Odyssey. The pod had a set of six animated displays inside the cockpit. When Kubrick shot the movie, in the mid 1960s, computer graphics didn’t exist, let alone flat panel screens. So he used animations displayed using 16mm film projectors.

The pod cockpit as seen in the movie.

But how to reproduce these displays in model form? I don’t want boring static backlit transparencies. Well, fortunately for me we live in a digital age of microcomputers and everything. And tiny video screens are now ubiquitous.

So here we go. Animations on a super high-resolution miniature screen. Very cool.

What this page is about

This a long page full of blah blah, describing how I was able to get animations working on some high-quality miniature screens.

If you just want to know how to add animated GIF software to a Lilygo T-Display S3 AMOLED microcontroller board, then skip all the next stuff and jump to the “installing the software” section.

This information deals with one specific microcontroller board, but it can in general terms be applied to other such boards which can use the “Arduino_GFX” libraries. I’ve used the technique on Lilygo T-Display S3, Lilygo T-QT, m5stack AtomS3, and and m5stack ESP32 Basic Core boards successfully.

While I focus here on my 2001 miniature, very small screens like this can be useful for all sorts of model-making applications – hobby and professional. You could make TV sets for a doll house, screens and displays for all kinds of diorama situations, small interactive readouts for simulated space helmets, and so on.

Here’s a quick X-wing computer test on a lower-resolution but delightfully tiny Lilygo T-QT. Pew pew pew!

The goals of the Mini Screen project

For my project I wanted tiny digital screens matching the following criteria:

Over the years I’ve tried different things, but all have all been kind of dissatisfying. Small displays for microcontrollers tend to be pretty low resolution, and a lot of TFT displays lose a ton of contrast and look blue-grey and awful when viewed off-centre. I evaluated dozens of microcontroller boards and LCDs (see the list at the end of this page)

But recently (early 2023) a product came on the market that finally meets my requirements!

This is a writeup on how to get this device to work, since it’s all pretty fiddly. Note that I have zero financial interest or stake with any company mentioned here, and I have not received anything from any of them either.

A little proof of concept with animated GIFs running on the Lilygo board. The pictures of the displays are offset on the screen intentionally. This won’t be my final animation, as I’m going to redo the images from scratch and also display them to match the film as closely as possible. But it’s impressive how legible the tiny text is. This test includes screenshots taken from the HAL Project.

The Lilygo T-Display S3 AMOLED

This hardware from Lilygo, a small Chinese manufacturer of microcontroller boards, is excellent. Its integrated screen is fantastic; the best I’ve ever seen on a microcontroller. A big improvement over your typical pixellated and washed-out TFT LCD.

The display uses AMOLED technology, so each white dot is actually made up of three microscopic LEDs. Unlike LCDs, which backlight the whole screen and then use liquid crystals to block light for black areas, AMOLED screens are simply off where a black pixel is required. This makes them really high-contrast and potentially lower power in operation. They also don’t require sheets of polarizers, making them better for off-axis viewing (ie: looking at the screen from an angle other than straight on).

The main drawbacks are that AMOLED displays tend to have shorter operational lifespans than LCDs - they can burn in and fade over time. And they can also colour-shift subtly when viewed off-axis.

Anyway, the screen is almost as high rez as a smartphone, and black areas are truly black. It’s an elongated rectangle; a bit of an unusual shape but it perfectly matches my requirements. The screen is protected by a laser-cut acrylic frame, which I can cut back as required.

The salient technical specs are:

* Square dots 82.5 μm in size work out to 308 points per inch. This approximates the screen quality of the first "Retina" iPhones, which were 326ppi. Modern phones are usually around 450-500ppi.

The board is speedy enough, and uses a tiny ESP32-S3R8 dual-core LX7 microprocessor chip. This is a microcontroller designed by Chinese firm Espressif Systems, manufactured by Taiwanese semiconductor foundry TSMC, and using CPU designs from American software company Cadence/Tensilica. (that’s the modern global world of computing today!)

It has 16MB flash storage (though you may not be able to use all of it for annoying software reasons described later). It has a nice modern USB C port. It also has a ton of interesting features I don’t need, such as onboard 2.4 GHz Wi-Fi with 3D antenna & Bluetooth 5 LE, an antenna socket, two small programmable pushbuttons in addition to a hard reset button, loads of solder pads for additional hardware, a lithium cell socket (cell not included), a STEMMA QT compatible/4-pin JST-SH socket for easy I2C connectivity, and a green SMD LED.

The product isn’t perfect - it demonstrates some tearing at high framerates, and it does not have a microSD card slot - but it’s pretty great on the whole. And it’s really quite affordable – at time of writing about $26 US or £20 UK.

Two boards, showing each side. So this is the whole thing. The larger of the two black squares is the actual ESP32 S3 CPU.

The products it’s not

Note this article covers the T-Display S3 AMOLED, not the earlier T-Display S3 which is cheaper and has a lower-resolution screen.

There’s also the confusingly named T-Display AMOLED, which lacks the “S3” in the name even though it also contains an ESP32 S3 chip. That one uses a 1.47" AMOLED touchscreen, the same as some smart watches. It’s not as long, is touchscreen only, and I haven’t tried one since at time of writing it isn’t shipping.

What software is supplied?

Unfortunately, Lilygo’s software is rudimentary at best. They’ve stuck a few driver libraries in a Github repo, and jotted some half-finished notes in a readme. That’s kind of it. They expect you to code everything from scratch using the Arduino IDE or whatever. No example code. You really have to know what you’re doing to use this thing.

Compare that to the way Chinese firm m5stack supports its boards - they have a bunch of documented code for the experts, upload apps for desktop/laptop machines, and even a nice drag and drop graphical UI environment for kids and casual beginners. Very cool, though they do cost a bit more accordingly. Unfortunately the m5stack boards that have integrated displays – I considered using the Atom S3 for a while – are all lower-resolution and TFT LCD, meaning they have mediocre off-axis viewing.

Putting animated graphics on the board

Anyway. All I want to do is upload an animated GIF file to the T-Display board and have it play in a loop when I turn it on. That’s it. Not exactly complicated. I mean, animated GIFs have existed since 19 freakin’ 87! Three and a half decades of dorky memes.

The main drawback with using animated GIFs is the limited colour palette: 8 bits, or 256 colours. I’m not showing photos here – the animations were of pretty flat line art graphics – but there’s still visible banding in my graphics in places, because of the restricted number of colours available to a standard GIF. So that is a problem.

Banding or posterizing, caused by the limited GIF palette, is evident here. I’ll probably rework the graphic to minimize this sort of thing.

Anyway. Getting simple GIF animations to work is not as easy as I’d like it to be. The LVGL software that Lilygo uses can theoretically play them. But after a lot of messing about I couldn’t get it to play back anything at all.

Even if I could, it looks like I’d have to break each animated GIF into separate images stored in a local C array encoded in ASCII format for uploading, which would be a time-consuming mess every time I needed to alter an image.

Fark. I just want to stick a file in there and have it play!

What about PNGs? Movies?

Well, I’d love to switch to 24 bit APNG if I could - the images would look so much better than the colour-limited GIF format. Unfortunately from what I can see neither LVGL nor Arduino_GFX support animated PNG. And stupidly, neither does Photoshop. Which is such a bummer. It’s 2023 and we’re still using crappy 8 bit GIFs, when we could be using PNGs...

As for actual video, the ESP32S3 is perfectly capable of handling low-framerate video, but the bottleneck is the connection to the display. Though at least it is QSPI, which is faster than old-skool SPI. And LVGL supposedly has FFmpeg support. But the code is complicated and finicky, with only certain formats supported. (eg: MJPEG and RGB565)

Fortunately there’s no need for full-blown video with my project anyway, because I’m effectively modelling a very low framerate slideshow. Keep It Simple. GIFs have lousy colour, but are easy to use. And they also let you specify arbitrary frame time values, thus sort of simulating variable framerates.

Arduino_GFX

Although I couldn’t get LVGL to cooperate, there is a collection of open source software built by Github user moononournation and other kind developers, called Arduino_GFX, that now handles the Lilygo device. He’s incorporated a bunch of graphic tools into one library, and supports a large range of boards and displays.

In June 2023 he added support for the Lilygo AMOLED board. His code can play back animated GIFs stored in a filesystem on the board. Fantastic.

Here’s how to use it. It took weeks to figure out this whole thing, so I’m posting it here in case anybody else is also struggling.

Now it is possible to code for this board using either MicroPython or the PlatformIO IDE, but I have not investigated these options yet.

Filesystem Woes

The easiest thing would be if Lilygo had put a microSD card socket on the board. But since they hadn’t, the next best bet would be to build a basic filesystem into the board’s firmware. You should then be able to upload files easily. You’d think this would be simple, right? The board has a damn USB port on it! Why can’t you just plug the thing into a computer, have it simulate a USB class storage device, appear on the desktop, and drag some files over? Easy. Microcontrollers aimed at kids: the BBC micro:bit and Adafruit’s Circuit Playground Express do that!

But no. The Lilygo board has no filesystem at all. So you have to install one, such as SPIFFS or LittleFS, or even FAT. But then how do you transfer a file into your board’s filesystem from your computer?

Well, it turns out that there are plugins that enable this capability within the Arduino IDE. You install the software, a menubar item appears in the IDE, and you can upload your selected file or files from a "data" folder in your Arduino sketch’s folder. Great.

Except... no. The latest and greatest Arduino IDE software, version 2.0 and higher, DOESN’T SUPPORT THESE PLUGINS. Seriously. And they have nothing that replaces this functionality.

So you have to go back to Arduino 1.8.19, which is older abandoned software and no longer under development. And hope for the best that it keeps working. Okay then.

The Arduino IDE sucks

And speaking of the Arduino IDE, I have to say I hate it. It’s free to use, sure. But the software and its ecosystem are a clunky, erratically designed, messy house of cards. Its UI is disorganized, with stuff scattered all over. Everything is brittle and you waste hours troubleshooting because its debugging capabilities are nil.

And it forgets your settings! All the fucking time. I have to constantly go back and re-select the port, for example. Over and over and over.

I’d pay for something less flaky. Rant rant rant.

Installing the software

Anyway. These are the specific steps to install the Arduino IDE, the ESP32 software, the Arduino_GFX libraries, and the file upload plugin. Finally - we’re getting to the useful part of this page!

These instructions are for a Mac running macOS 13.4 Ventura. I’m not writing up how to do this on a Windows PC or a Linux box because I haven’t got one of those. But much of this would still be applicable.

Get the Arduino IDE

This is the IDE (integrated development environment, for varying values of the word “integrated”) written by Italian board maker Arduino, that lets you compile code for their line of small microcontrollers. Since it’s open source a lot of their competitors also use it.

Get the ESP32 software

This is the software from Espressif, makers of the ESP32 CPU chipset, that allows the Arduino IDE software to compile code for those chips. The Lilygo board uses the S3 version of the ESP32 CPU.

Install GFX Library for Arduino

This is a set of open source libraries that allow boards like the Lilygo to display graphics, including animated GIFs.

Install the filesystem uploader

This is a tool that allows you to upload animated GIF files to the Lilygo board. It supports the SPIFFS, LittleFS, and FAT filesystems. I use LittleFS since it’s the default for the Arduino_GFX library.

Fix the missing esptool problem

One of the delights of working with open source software is that stuff is always breaking and acting weirdly, and it’s difficult to figure out what’s going on. In the case of the uploader plugin, it turns out it’s hardcoded to look for a specific Python tool for handling the communications with the chip. If it’s not in that one expected location, the plugin won’t work.

So if you get the error message “esptool not found!” when running the filesystem uploader, then try this fix suggested by the author of Arduino_GFX:

/usr/bin/pip3 install esptool

ln -s ~/Library/Python/3.9/bin/esptool.py ~/Library/Arduino15/packages/esp32/tools/esptool_py/4.5.1/esptool.py

Obviously you’ll need to update the symbolic link command to whatever version of the ESP32 software you’re using, and thus whatever directories are appropriate.

Configure the Arduino IDE

There is no preset board definition available for this AMOLED board. You have to use a generic ESP32 S3 board definition and change a bunch of settings.

Lilygo list most of the values that you need to set on the Arduino IDE through a whole series of pulldown menus. (note to Arduino: this is a poor choice of UI for selecting this stuff!) However Lilygo list them in the order in which they appear in Arduino IDE 2.x.

So here’s the settings list in the order in which they appear in Arduino 1.8.19, since it’s time-consuming to set these menu items when they’re in the 2.x order. I’ve marked the ones that need to change from the defaults in boldface.

You may need to change the partition scheme, depending on what you’re uploading. Unfortunately you don’t have a lot of choices in that regard. Even though the Lilygo board has 16 MB of RAM, there’s no partition option that lets you access more than 3MB of it, which is a drag since that’s not a filesystem limit. I’m sure those values are stored in an editable conf file somewhere, but I haven’t located it yet. Incidentally the menu command mentions SPIFFS only, but the setting seems to apply to LittleFS also.

Note that because the Arduino IDE is so shit you’ll probably have to wade through these menus time and again resetting some of these functions in the future, since the software keeps forgetting them. The active port seems the most commonly lost setting. I’ve had this problem with different versions of the Arduino IDE, on different versions of the OS, and with several different microcontroller boards.

Prepare the Animated GIF software

Navigate to:

/Documents/Arduino/libraries/GFX_Library_for_Arduino/examples/ImgViewer/ImgViewerAnimatedGIF

Make a duplicate of the “ImgViewerAnimatedGIF” folder and put it into the top level of the Arduino folder or wherever you want.

Critically, if you’re coding for an AMOLED board, delete or comment out this line:

// #define GFX_BL DF_GFX_BL

If you don’t deal with this line, your graphics will appear green. AMOLED boards do not have backlights, so this LCD command for TFT LCD backlights breaks things.

Leave the backlight code in place if your screen is a TFT LCD, such as a Lilygo T-Display non-AMOLED or T-QT.

Urgh. Yes, this is how the AMOLED screen will look if you send the board a backlight command.

Next, we need the relevant AMOLED lines from the Arduino_GFX_dev_device.h file:

Find the Arduino_DataBus line and replace it with:

Arduino_DataBus *bus = new Arduino_ESP32QSPI(
   6 /* cs */, 47 /* sck */, 18 /* d0 */, 7 /* d1 */, 48 /* d2 */, 5 /* d3 */);

And find the Arduino_GFX line and replace it with 

Arduino_GFX *gfx = new Arduino_RM67162(bus, 17 /* RST */, 0 /* rotation */);

Incidentally, the same approach applies if you’re coding for a related product, such as the non-AMOLED Lilygo T-Display-S3, or the Lilygo T-QT. Just search for the correct DataBus and GFX lines in Arduino_GFX_dev_device.h and paste those in.

Make a GIF

I’m not going to cover the process of making an animated GIF file. There are obviously a lot of tools out there that can be used for this. I personally use Adobe Photoshop since you can stack a bunch of layers consisting of all the different frames, then assign them different time values. Obviously your GIF should probably have the same pixel dimensions as the display that you’re using.

The ability to specify frame display times in Photoshop is really handy because the actual 2001 animations were displayed on-screen for varying lengths of time. And this is obviously a much more CPU and space efficient way of displaying these images than outputting an actual video file. You can also, through a lot of careful work, have independent left and right display timing.

As griped about earlier, GIF only supports 256 discrete colours. And, also as noted earlier, the screen does tear a bit on rapid frame changes. So flashing text set to 0.04 seconds per frame (ie: basically 24 fps) will exhibit the problem, sadly.

Compiling and uploading

At this point it should be a simple matter of compiling and uploading the code, and uploading the animated GIF file that you prepared earlier. Oh yes.

It will probably take a few tries to get both tools to upload your code and data successfully. You might have to power-cycle the board, reset it, curse, etc. You might also need to experiment with different partition types.

But once it’s all done the board should play the animated GIF in a loop. Sit back and watchen the blinkenlights.

3D Model

I’ve built a 3D model of the Lilygo T-Display S3 AMOLED board for my own planning purposes. (ie: figuring out how the real board would fit within a 3D model.)

If it’s useful to anyone else, here’s the STL of my model. Note that it is NOT 100% accurate, and it’s missing a lot of internal components of the real board - I mostly modelled the bits that stick out, and added some internal bits to make it more printable. I make no promises it will work for your application, but it should be reasonably close in size, which is the point.

LilygoTDisplayS3AMOLED.stl

Is the screen removable from the board?

Not easily, no.

It’s something I wondered about, because the width of the acrylic frame around the display does interfere with my project. However, because the display is so incredibly thin – a mere 0.89mm – Lilygo wisely mounted it in a recess that’s been CNC-routed into a clear acrylic frame. This acrylic frame is then attached to the PCB with clear gel tape at three locations. Ingeniously the rubbery resilience of the gel tape actually serves as a spring mechanism for the two pushbutton covers built into the frame.

The acrylic is raised off the board surface because of the thickness of the gel tape. Now, you can carefully cut out the tape with a sharp knife and release the display from the board. This gives you some flexibility in placement.

Don’t try this at home.

However, separating the display and board is risky. The flat flex cable linking the two is fragile and easily torn, and it attaches to the board with a very easily broken ZIF connector.

Separating the display from the frame is even riskier. The super-thin and delicate display is stuck inside the acrylic frame’s recess with thin double-sided tape, and I don’t think it’s realistically possible to remove it without breaking the display. If it weren’t recessed you could have been able to slide a thin knife between the display and acrylic, but that isn’t possible in this case.

So you have the width of the acrylic frame limiting how close the screen can be positioned to things. Or you can just buy a replacement bare screen and install it in place of the Lilygo one, which is what I’ve done. The DWO DO0200FS01 is a pin-compatible replacement.

But I would warn anyone who wants to give this a go — the flex cable is thin as paper (strong but can be creased or torn at the edges), the ZIF connector flip-clamp can be broken by sneezing on it, and the display itself is a piece of glass thinner than a microscope slide! The AMOLED display is way thinner than your typical miniature TFT LCD.

There's a reason that Lilygo chose to mount the display in a protective acrylic frame, and it’s a good one.

An unprotected bare DWO screen plugged into the Lilygo board.

Incidentally, speaking of the screen, I’ve seen at least one review complaining about bad pixels — that their board had a ring of red dots on it. That’s actually a printed red circle on the protective plastic sheet that ships on the screen, and not on the screen at all! (you can see it in the photo above - it's the rough ring of dots to the left side of the screen)

Oopsie.

Screen ideas that didn’t work out

In case it’s useful for anyone else - here are a bunch of options that I considered and rejected before settling on this product.

My screen size requirements are for a 1:6 miniature of the 2001: a Space Odyssey space pod cockpit interior. (not the 1:8 Moebius commercial kit of same)

Small computers and HDMI video

Raspberry Pi type computers are capable of driving HDMI monitors, so that was one possibility. However, I couldn’t find much by the way of HDMI monitors that were small enough. The tiniest were 2-3 inches diagonally, with most 5-7 inches.

iPods and toy MP4 players

Later model Apple iPod nano players had video playback. And there are tons of cheap disposable mini video players, often styled after iPod nanos, on the auction market. In theory these could be cannibalized and adapted for use as tiny screens.

In practice the actual iPods were discontinued years ago, and most fake cheapies are poorly made and designed for specific applications. So, cheap as they are, I didn’t feel like spending ages buying various models in search of one that works and converting it. It is a fun idea, however. I’m sure someone will find this a rich seam to mine.

Indeed, I've heard that the communicator and tricorder props from Star Trek: Discovery and Star Trek: Strange New Worlds actually use old-skool late-generation iPod nanos inside their shells to play back video.

Adafruit microcontrollers and high-resolution LCDs

Adafruit, an American supplier of electronics for makers, has a number of useful products that seem pretty appropriate for making a working model screen. The company produces a ton of affordable microcontroller boards, supplies free software to work with them, and also carries a bunch of high-resolution screens as well as regular ones.

Unfortunately I couldn’t find any Adafruit products that really worked for this project. The reason is that when I tested it the Adafruit display software wasn’t fast enough. You can show an image on a screen, but instead of instantly appearing on-screen it sort of gradually loads like a lowering window blind. There’s no buffering as it loads the bitmaps over the SPI bus. No video playback either.

This obviously doesn’t look right for the pod EVA screens, since images snapped on-screen instantly as the movie projections looped.

Teensy

The Teensy line of Arduino-compatible microcontrollers is a possibility. There are a number of software packages that allow for a Teensy to output video to colour LCDs. A version of this software package was used to make the creepy moving eyes project published by Adafruit. This code requires the Teensy device since it takes advantage of specific hardware built into that product that allows for the rapid transfer of data to the screen.

Unfortunately the codebase is tied to specific LCD drivers, appears not to be regularly updated, and requires a fair bit of expertise to install and use.

Bare display modules

Here’s a list of commonly available LCD displays, minus any CPU boards.

Side note to microcontroller display sellers: please put useful information about the device you’re selling on your website! For example, many people need to know the precise active area (the actual bit that lights up) of the display and the physical dimensions of the screen.

You won’t believe how many places only list useless stuff like the approximate diagonal of the screen in inches, rather than the actual X-Y dimensions in millimetres! I had to spend ages searching the web for display manufacturer technical PDF documents just to uncover this basic info.

0.66"
13.42 × 10.06mm active area
18.46 × 18.10 mm
64 × 48px
Super low-rez. Way too small.

0.85"
AtomS3, Lilygo T-QT ESP-32-S3
15.2 × 15.2 active
17.6 × 20.1 PCB for raw panel
128 × 128 px
0.11875mm × 0.11875 per pixel
A tiny bit undersized. Okay resolution; glows slightly when viewed off-axis.

Left: the m5stack AtomS3 in its sturdy little case and right: the Lilygo T-QT.

TinyTV 1
25.7 × 22.2mm PCB
20.1 × 13.4mm active area
96 × 64 pixels
Very poor resolution

0.91"
80 × 160 pixels
27 × 16.8mm?
11.5 × 20mm active area
Low rez, too small

0.96"
24 × 30mm PCB
11 × 22mm active area
80 × 160 pixels
Doesn’t cover whole screen; crap resolution

1.1" round
No good; doesn't fit anyway.

TinyTV 2
IPS 26mm/1"
Basically the 1.14" so no good
30.4 × 28mm PCB
14.9 × 24.9mm active area
135 × 240 pixels / 135 × 216 pixels

The TinyTV 2 in its clear plastic enclosure. An excellent choice for people who want a plug and play solution, though you do have to press the power button on the top to turn it on.

1.14"
135 × 240 pixels, 260 ppi, decent rez
14.9 × 24.9 mm active area
Module PCB size 30.5 × 28 mm
Not tall enough. Same as TTGO T-Display, only without the long PCB.

1.3"
28 × 40mm PCB or 27x30
23.4 × 23.4mm active area
240 × 240 pixels
So-so resolution. Covers each square, but impinges on two vertical rows to the side, and part of the top row of the horizontals.

1.44"
25.5 × 26.5mm active area
29 × 34.5mm PCB
128 × 128 pixels
Crappy resolution.

1.54"
44 × 42 PCB
32 × 31 active
240 × 240 pixels
Decent rez. Sold by Adafruit. Covers 1 screen but not 2. Sticks out a lot on the sides owing to PCB size.

1.54" square
27.7 × 27.7mm active
240 × 240 pixels
36 × 40mm PCB
Touchscreen, which doesn't help me.

1.69"
240 × 290 pixels
28 × 32.5mm active area
30 × 37.4mm PCB
36.5mm wide  ×  22.5 tall needed
OK rez, but doesn’t cover both side displays. Rounded corners

1.77"
54 × 34mm PCB
35 × 28mm active area
160 × 128 active area
Crap resolution. Does not cover both square screens, but sticks out at the top of the panel. Also covers top row of horizontal buttons and 2 vertical rows of screen-side buttons

Lilygo TTGO T-Display
25 × 51.5mm PCB
14.9 × 24.9mm active area
135 × 240 pixels
1.14" LCD, 260 ppi, ESP32 CPU
Resolution so-so. Poor off-axis. Can’t put them side by side given the space limitations

Lilygo T-Display AMOLED 1.47"
25.2 × 51.5mm PCB
194 × 368 pixels
Possibly 19.36 × 36.2mm display
Possibly 17.46 × 33.12 mm active area
Touchscreen only, too narrow for side displays, not shipping at time of writing

1.8" (used by WeAct Studio etc)
35 × 56mm PCB
28 × 35mm active area
128 × 160 pixels
Lousy resolution, doesn’t cover 2 screens

lilygo T-Display-S3 1.9"
ESP32 with acrylic cover
26 × 62mm PCB
22.7 × 42.7mm active area
36.5mm wide  ×  22.5 tall needed
170 × 320 pixels
Size OK. Resolution so-so; poor off-axis viewing as TFT

Top: the older T-Display-S3 and bottom: its vastly better younger sibling, the T-Display-S3 AMOLED.

2"
IPS ILI9342C
320 × 240 pixels
40.8 × 30.6mm active area
0.1275mm × 0.1275mm per pixel
46.5 × 41.5 × 2.5mm LCD PCB
54.5 × 47.5mm PCB
TFT LCD; not great resolution; too big.

Useful resources

T-Display-S3 AMOLED product page

T-Display-S3 AMOLED Github repo

Arduino_GFX Github repo

Arduino_GFX Github discussions page

ESP32: Upload Files to LittleFS using Arduino IDE

Mac compatible ESP32FS plugin

Volos Projects - a YouTube channel from a guy who specializes in Arduino projects

If it doesn’t work

I’m probably not going to be able to help you if you can’t get your file to play. I’m not a developer, and I’m not versed on the detailed ins and outs of how this stuff works - let alone on what to do when it all breaks. I’ve put this material up here because I spent ages figuring this all out, these steps worked for me, and I hope they help someone else! That said, if you notice an error or have a suggestion for improving things, please drop me a line.

My recommendation is to post to the discussion areas associated with the software in question and see if someone there can give you a hand. Good luck!

Regrettably I'm not in a position to distribute the animations that I built for my project.

28 July 2023