Previously – an overview of the particular screen I’m using
In this post I’m going over the actual display functionality. So we’ll finally have something that draws stuff on the screen instead of just messing with the touch/sd.
Compatibility
In part 4b, I use TFT_eSPI, a popular library for TFT screens that is able to interface with many TFT screen drivers. However, it is designed for 32 bit microcontrollers, and the arduino mega I have been using is only an 8 bit microcontroller. So for this part, I have used a different library specifically for the screen I have.
You can use a 32 bit microcontroller with these steps too. The TFT_eSPI library is just more feature rich.
The screen I have has an ST7796 display driver.
In the arduino ide, install the Adafruit ST7735 and ST7789 Library by Adafruit. In its description it also lists the ST7796S SPI display.
Wiring
In the samples from Adafruit, it is important to note that their code revers to TFT_DC. This is the Data/Command pin, which is labeled on our board as LCD_RS.
The remaining pins are straightforward, though they use TFT instead of LCD. But the pin labels are easy to understand.
You can verify that the screen is working by running
Basics of TFT
When I first started thinking of doing a screen on an arduino, my first worry was about how screen refreshes would work. I was greatly over complicating things.
I’m used to libraries where you’ll have a subclass of a view, and if you implement a Draw function of some sort, then you’re responsible for drawing the view in its completeness, for every frame. So if you don’t draw something, then its not there.
When you extend that idea to an arduino where you’re implementing your loop function, it is understandable why I would assume that every single time loop is called, I would have to draw every pixel. And therefore you would have to worry about making sure your loop doesn’t do delays for too long, or the screen would clear. etc.
As fortune would have it, this was just a great misunderstanding on my part of how these things work.
If you consider the old land of the old computers like a Commodore 64, you would have a segment of your ram dedicated to what is on screen. The video routines would just read your video memory and display that on screen. So once you poke the memory to put something in it, it stays there until something else changes that memory.
The same is true for an arduino playing with a TFT screen. If you draw something, it stays there until you draw something else.
There are certain functions that will replace instead of just covering it up.
If you draw text, it will replace. so you don’t have to undraw the text. but if you draw lines or shapes, they won’t replace the whole x/y boundary of what you have drawn
So if you draw a circle moving across the screen, you will have to undraw the part that is no longer in that circle, or you will quickly just draw a rectangle across the screen
Advanced Displays/GUI
Unfortunately with the low power of the 8 bit microcontrollers, writing a GUI is fairly involved.
There aren’t any great gui libraries, so you will have to draw your rectangles, and compare your touch events to the rectangle dimensions manually.
If you have access to a 32 bit microcontroller, to be able to use TFT_eSPI and/or LVGL, then you can write a UI that is a bit more advanced.