For an upcoming new project I wanted a colour (UK spelling) LCD screen (ideally OLED), 256×256 (or greater) resolution and nice and cheap. It was not an easy 2 minute task. There were no OLED screens offering what I wanted (that I could see at the time). So compromises were made, in the end I purchased a 128×128 pixel screen (none OLED) for around $3.50 (£3.20, 3.50 Euro). Not as cheap as I thought I might get one for but the cheapest I could find. There were a lot of sellers offering this screen and it’s shown below.
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 project (after the Space Invaders one, see https://www.xtronical.com/programming-series-space-invaders-on-arduino/), 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 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. Wifi is also available but will not be required for this project unless we implemented a World High Score Table perhaps! There are newer versions, ESP32, available with even more power but are more expensive and we don’t need that level of performance for this project. I’m using a NodeMCU from Lolin, which is basically a breakout board for the ESP8266 so that you can use it easily on breadboards or small production runs using through hole.
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 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 NodeMCU is shown below:
LCD Screen | NodeMCU ESP8266 |
---|---|
5V | 3v3 |
GND | GND |
LED | 3v3 |
SCL (SPI Clock) | D5 (Hardware Spi Clk) |
SDA (SPI Data) | D7 (Mosi, Data to Screen) |
RS (Register Select) | D4 (labelled as DC in Adafruit code) |
RST (Screen reset) | D3 |
CS (Chip Select : Defined as Slave Select in SPI) If low this device is active on data lines | D2 |
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. It is actually on even when not connected giving adequate brightness in my opinion. SCL is the SPI clock and goes to the NodeMCU’s hardware SPI pin (pin D5). SDA is actually the SPI MOSI connection and goes to the NodeMCU’s SPI MOSI pin (D7). 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 D4. RST is the screen reset and and is connected to pin D3. 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 D2. 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 D2.
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
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->GraphicsTestESP8266”. 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.
There is an issue with the line drawing routine within the Adafruit GFX library, so this part of the original demo was removed. Basically it forces the NodeMCU to reset. As I’m not going ot be using this I’ve decided for now to ignore this issue.
That wraps it up for this article, hope it was helpful 🙂