Table of Contents
1.8" and 1.44" TFT displays and classic Arduinos
Small 1.8“ (160×128) and 1.44” (128×128) TFT displays with ST7735 controllers have been available from Asian suppliers for a while now. They are only slightly more expensive than the very inexpensive Nokia 5110, and are about the same physical size but offer color and greater DPI.
One of the concerns with with TFT displays is that they are data gluttons, which means they will put a lot of stress on a piddly Uno/Nano/Pro Mini with regards to memory consumption, processing time, and data transfer time. However, it's not unreasonable to hope that a really small TFT display might still be workable, so I cobbled together some tests to see if that might be the case with these little displays. In the tests that follow, I am striving to answer first whether the rendering updates will be fast enough for reasonable use and second whether there will be any memory left to do anything interesting.
Unfortunately, it looks like none of the available libraries work well enough with the Uno/Nano/Pro Mini to make these displays really appropriate for large text-based content that changes. The Ucglib library with solid font rendering and a 16 MHz processor comes very close though. However, a 3.3V 16 MHz Arduino isn't available, so this means you'll have to complicate things a bit by using level converters.
The results are a bit of a disappointment because the displays are otherwise incredibly charming.
I ran a number of tests using all the libraries I know of that let you interface to a ST7735-based display. These tests were conducted with a 3.3V 8 MHz Arduino Pro Mini equivalent unless noted and a 1.44“ (128×128) display that I bought through eBay from a vendor in China.
Oli Kraus' Ucglib is designed to support a range of TFT displays with a common code base. This is the most appealing library for me because of the range of available fonts it has available out of the box.1)
I ran two test cases: one using solid font rendering and the other with transparent. In both cases, faster hardware SPI was used over slower software SPI. I ran both test cases with both a 3.3V 8 MHz Pro Mini and a 5V 16 MHz Nano, for a total of four tests.
As you can see from the videos, the speed isn't entirely acceptable. I am assuming this is mostly due to the burden placed by the pretty fonts' data. Frame rates with a 16 MHz processor are double those of an 8 Mhz processor (no surprise). Even though the transparent font rendering is technically faster, the solid rendering artifacts are less annoying.
Solid rendering with a 16 MHz processor is almost good enough, but a 16 Mhz implementation requires level shifting since no 16 MHz 3.3V boards are available.
Solid font rendering
Transparent font rendering
Arduino TFT library
Arduino has a standard TFT library that supports the ST7735. It assumes the upper left corner of the display is actually what appears to be the bottom left of the corner (i.e., the screen is rotated 90 degrees.) This creates an issue with the 128×128 screen because that display essentially cuts off the bottom 32 pixels of the screen to achieve its lower resolution. So, everything needs to be rotated and shifted by 32 pixels if you use this library with a 128×128 display.
Overall, the results are fast, but you need to be OK with the blocky text rendering and integer font size scaling. While blocky fonts have a certain charm, it's not the right charm for most applications.
Adafruit ST7735 Library
Adafruit's popular GFX platform has support for the ST7735. With this library, the display is rotated 180 degrees relative to Ucglib, which means you need compensate for a top margin when rendering things on a 128×128 screen.
The Adafruit library with its default font performs and looks almost the same as the Arduino TFT library.
Fancy large font
When a large fancy font is used, the performance between the Adafruit library and Uclib narrows. I suspect that with a font as large as that used in the Uclib examples, the results would be close to identical. Which is to say, not fast (or light?) enough.