A video is now available supporting this article, click below and/or read on
Connecting a colour screen over SPI to ESP32 based MCU’s is a straight forward process and is extremely similar to using one with the Arduino or ESP8266. Firstly though you need to ensure that you have set up your ESP32 to work with the Arduino IDE, see this article if you have not already done so and then come back here.
Requirements
An ESP32 Module
Some wires!
A SPI based colour LCD, this article will use a 128×128 unit, ST7735 chip set
The Screen
The screen I chose is shown below, finding one very similar will probably make your build easier, but as long as your screen is an SPI screen using the ST7735 driver chip then you should be good to go.
As can be seen from the connections it accepts both 5V and 3.3V with the 5V side having a pre-soldered pin header. This particular one was ordered from Ali-Express and had a picture of a cartoon boy on the screen. I suspect buying any with the same pin connections will give you the same screen as the one above.
For my new Frogger project (after the Space Invaders one), I wanted a screen where I could directly port the Arcade graphics and screen layout without too much messing about re-designing graphics. But for the price point I wanted this proved impossible. Most arcade games of the early 80’s did not go above 256 pixels in any give direction so porting the graphics should be easy I thought. At half the resolution (128×128) I hope that transferring the graphics will not be too tedious and that in most cases I can simply reduce the number of pixels in each image by half.
Due to the planned game being more advanced than Space Invaders I needed a processor with more memory and speed than the Arduino could offer. Enter the ESP8266 processors which offer faster speeds and lots and lots more memory. However they proved to have too few input pins to make controlling the game feasible. So its big brother, the ESP32 was the obvious choice, it has more power than the ESP8266 (not that that was an issue) and more importantly it has loads of input pins, cool! Wifi is also available but will not be required for this project unless we implemented a World High Score Table perhaps! I’m using a NodeMCU development board which brings out all the ESP32’s pins to headers and enables the board to be plugged into a 5V USB power source. It also adds a USB controller chip to handle program transfers with the host computer.
Connections – very careful now!
Looking at the back we can see +3v3 (this screen can be powered from 5v as well), several grounds (Gnd) and SCL/SDA. This should mean that this device is an I²C device and can be easily connected to our Arduino. Err… Think again. This screen gave me no end of problems as connecting it to the I²C connections and running any demo I could find on the internet did not get anything on the display. I went back and looked at the listing for this device, it stated SPI Bus not I²C ! So it began to become apparent that this screen had an SPI interface. SCL and SDA would logically seem to be SPI clock and data (MOSI) respectively but other pin labels didn’t match normal SPI protocol labels. Reading several resources for other different screens and looking at the source code for the examples in the Arduino IDE Examples library lead me to find the correct connections to power and use this screen.
Voltages
If you read the other article on connecting this to the Arduino we used the 5v side, so you would think that we would use the 3v3 side (as this is a 3v3 processor). So I soldered up a header to this side. Made all the connections required…. and it didn’t work. I then spent some time trying to figure it out. I got my scope out and probed the SPI, all looked OK. I eventually just gave up and connected everything up to the 5v side and…. It worked!! I’m not sure if it was some dodgy soldering by me or if this side of the board is not implement fully by the manufacturer but either way I now have a working board. All my initial connections were fine and if I’d used that side in the first place I’d have been up and running in minutes and not hours! Grrr….
The connection table for a the ESP32 NodeMCU is shown below:
Power is self explanatory. LED adds a little extra brightness to the screen but it does still work if not connected. I’ve seen resistors added in series here and even variable ones to vary the brightness but I’ve ran it directly connected on this screen with no issues and wouldn’t want it dimmer as its not ultra bright. Connect it to the 5V pin of the NodeMCU to get 5V from the USB connection, this will make the screen nice and bright and clear. SCL is the SPI clock and goes to the NodeMCU’s hardware SPI pin (pin GPIO18). SDA is actually the SPI MOSI connection and goes to the NodeMCU’s SPI MOSI pin (GPIO23). RS is a Regsiter Select pin for ST7735 driver chips, this maps to a variable called TFT_DC in the Adafruit code (explained later) that I was using for testing. This controls whether we are sending a command to the ST7735 chip or actual data. I think that Adafruit call it DC meaning Data Control, but I’m not sure. On some boards it may even be referred to as A0. For our purposed we connect it to GPIO2. RST is the screen reset and and is connected to pin GPIO4. These last two can connect to any NodeMCU pins that are not used for other functions. CS is Chip Select (usually referred to as Slave Select in the SPI protocol) and again can connect to any pin but I use the official SPI SS for the ESP32, GPIO5. If this is pulled low then this device can receive or send data on the SPI bus. If only one device in your design you could pull this low permanently and not use GPIO5.
Below is the connection diagram for this set up.
Driver Code
When presented with this board (as mentioned above) it was difficult to work out where wires should go and what driver software I needed for the display. Looking at the solitary chip on the board and Googling revealed nothing. So I went back to the sellers listing and found buried deep in a sub-page description the phrase “7735 drive”. Googling this revealed Adafruit had written some drivers for this chip for a board they had created (which also had an SD card slot on it as well). It was not surprising I didn’t find the 7735 chip on the board as this chip is designed to by embedded onto the back of the screen. It was being armed with this source code and other web pages dealing with different chip sets but similar displays that I managed to work out (with a little trial and error) the connections talked about previously above. Initially I used the Adafruit driver code but gave issues with this screen (as it was designed to work with the one they sell). Look below.
Text clipped off at top, missing quite a bit of start of text
Should be fully rounded rectangles but clipped at top
Top of triangles clipped
Also when the screen orientation is rotated (in software) so you can write to the display any way up then more things either correct themselves or mess up again.
Fixing the ST7735 driver to work with this screen.
So we have some work to do still to make this work well with our display. The driver we have used to get this up and running was not designed for this display exactly. Things appear clipped and off screen. There were other issues with colour (i.e. red was blue and blue was red amongst other colour problems) and other graphics routines were not correct. I won’t bore you with all the tiny re-writes I did but just supply you with the new driver for this particular display. This driver is very specific, i.e. only targeting this display and resolution but it may well work with many other similar displays. At the time of writing I have no other displays to test with but will be expanding the driver code as and when required. The full driver code is available from the link below, add it into your Arduino in the usual manner (Adding libraries to the Arduino IDE.)
You will also need the Adafruit graphics library at
Load up the example code that should now be available at “Files->Examples->XTronical ST7735 Library->GraphicsTestESP32”. This is basically the Adafruit example with just some tiny changes (It goes through all the tests for each rotational position of the screen) so that it uses the new driver file and slightly altered initialisation routine.
Upload and run the code and all the routines should now work.
That wraps it up for this article, hope it was helpful 🙂