More CYDs (Cheap Yellow Displays), Less Frustration

A few years ago, a Chinese electronics vendor (Sunton) started selling an inexpensive PCB with a ESP32 module, QVGA touchscreen LCD display, microSD card slot and (misconfigured) audio amplifier. More recently, these boards have branched out into a large collection of permutations of ESP32 MCU + LCD that has been collectively called the "Cheap Yellow Display" because of the PCB solder mask color and low price. Due to the variations in the display types, GPIO connections and MCUs, one program can't be used on all of them without significant modifications. I've been collecting and testing these boards and have tried to make life easier for people using them by adding the unique configuration info into my bb_spi_lcd library.

The Frustrations

Let me back up a bit and describe what I'm trying to fix. The LCD displays used on these boards are generally supported by multiple Arduino libraries, but in order to use them you need to know the display type, GPIO connections and configuration flags (e.g. inverted, red/blue swapped). A popular library in use is TFT_eSPI written by Bodmer. This library supports all of these displays, but chose to use a compile-time (aka .H file) way of managing them. The user is required to set up a lot of macro defines and/or copy and edit a .H file filled with the unique info for the target display. Here's an example of what that looks like:

(TFT_eSPI User_Setup.h)

I don't want to paste the code into this article because it's too long to see in a quick glance. Suffice it to say that for a user who is not a C++ expert, nor experienced with these displays, editing that file can be a challenge. Not only does it need to be edited, but it needs to be copied and renamed. If you want to change displays, you need to copy a different User_Setup.h or edit it. Either of these actions is not a reasonable request for Arduino users just to set the display type. All of the previous steps allow you initialize and use the display. Now if you want to use the touch sensor you must find a similar set of cryptic info and correctly initialize and calibrate it. Here's a brief look at that code:

// Touchscreen pins
#define XPT2046_IRQ 36   // T_IRQ
#define XPT2046_MOSI 32  // T_DIN
#define XPT2046_MISO 39  // T_OUT
#define XPT2046_CLK 25   // T_CLK
#define XPT2046_CS 33    // T_CS

SPIClass touchscreenSPI = SPIClass(VSPI);
XPT2046_Touchscreen touchscreen(XPT2046_CS, XPT2046_IRQ);

  // Start the SPI for the touchscreen and init the touchscreen
  touchscreenSPI.begin(XPT2046_CLK, XPT2046_MISO, XPT2046_MOSI, XPT2046_CS);
  touchscreen.begin(touchscreenSPI);
  // Set the Touchscreen rotation in landscape mode
  // Note: in some displays, the touchscreen might be upside down, so you might need to set the rotation to 3: touchscreen.setRotation(3);
  touchscreen.setRotation(1);

Now The Easy Way

After looking at the situation above, I can sympathize with the people that give up on these projects in frustration after encountering a myriad of errors and failed attempts. I came up with a way to simplify both display and touch sensor initialization and use. Since the unique types of CYDs are limited in number, I created unique names and configurations for each. These configurations include info about the touchscreen. Here's an example of how easy it is to get started. This code is published here.

If you notice above, there are only 2 lines of code needed to initialize the display and touch sensor (lcd.begin and lcd.rtInit). The named constants I created are all that's needed to specify your board. The original CYD (DISPLAY_CYD) is a 2.8" ILI9341 LCD w/resistive touch controller on a separate SPI bus. A newer variant with 2 USB connectors has a different LCD (ST7789) and different GPIO connections. To switch to that model, simply change the name to DISPLAY_CYD_2USB. Here's the program running on the original 2.8" version:

If you look at the README to my CYD_Projects repo on Github, I list the names of the CYDs and what they mean. bb_spi_lcd supports many more pre-configured displays (e.g. M5Stack products).

Where to go from here?

There's still plenty of work to be done fixing bugs/omissions and adding support for newer boards. What do you think? Does bb_spi_lcd reduce frustration? I also wrote LVGL support for bb_spi_lcd. I'll publish it shortly.