Setting up lvgl_micropython on the "Cheap Yellow Board" (CYB) aka Sunton ESP32 2432S028R 2.8" resistive touch LCD board

[gitcnd]

Setting up lvgl_micropython on the "Cheap Yellow Board" (CYB) aka Sunton ESP32 2432S028R 2.8" resistive touch LCD board #281

The "Cheap Yellow Board" is a popular screen. There's 3 versions (see https://github.com/rzeldent/platformio-espressif32-sunton/blob/main/esp32-2432S028R.json for differences). Below is how to set up the original or v2 boards, which use the ili9341 display driver and xpt2046 touch chips (curiously, my board had "7789" on the box, but it is not a st7789 driver.

Below is how I got the screen and touch working on my ESP32 2432S028

Build:-

python3 make.py esp32 BOARD=ESP32_GENERIC BOARD_VARIANT=SPIRAM DISPLAY=ili9341 INDEV=xpt2046

Note: the xpt2046 driver is my modified one with "swapxy" feature added, which it does not work without.

(Optional) backup your flash before overwriting it:

export PORT=/dev/ttyS6 esptool.py --port $PORT read_flash 0x0 0x400000 lcd_2.8inch_ESP32-2432S028R .bin

Flash:-

esptool.py --port $PORT write_flash 0x0 lvgl_micropy_ESP32_GENERIC-SPIRAM-4.bin

Upload a test:-

ampy --port $PORT put lvgl_test_2432S028R.py

Run it:-

mcu_serial.pl -port $PORT
import lvgl_test_2432S028R

The test program:

#WORKS lvgl_test_2432S028R_l.py

import lcd_bus
from micropython import const
import machine



# display settings
_WIDTH = const(320)
_HEIGHT = const(240)
_BL = const(21)
_RST = const(-1)  # ST7789_DEV_CONFIG_RESET_GPIO_NUM=GPIO_NUM_NC
_DC = const(2)  # ST7789_SPI_CONFIG_DC_GPIO_NUM=2

_MOSI = const(13)  # ST7789_SPI_BUS_MOSI_IO_NUM=13
_MISO = const(12)  # ST7789_SPI_BUS_MISO_IO_NUM=12
_SCK = const(14)  # ST7789_SPI_BUS_SCLK_IO_NUM=14
_HOST = const(1)  # SPI2

_LCD_CS = const(15)
# _LCD_FREQ = const(80000000)
_LCD_FREQ = const(24000000)  # ST7789_SPI_CONFIG_PCLK_HZ=24000000

_TOUCH_CS = const(33) 
_TOUCH_FREQ = const(2000000)  # GT911_I2C_CONFIG_MASTER_CLK_SPEED=400000

spi_bus = machine.SPI.Bus(
    host=_HOST,
    mosi=_MOSI,
    miso=_MISO,
    sck=_SCK
)

display_bus = lcd_bus.SPIBus(
    spi_bus=spi_bus,
    freq=_LCD_FREQ,
    dc=_DC,
    cs=_LCD_CS,
)

# we are going to let the display driver sort out the best freame buffer size and where to allocate it to.
# fb1 = display_bus.allocate_framebuffer(_BUFFER_SIZE, lcd_bus.MEMORY_INTERNAL | lcd_bus.MEMORY_DMA)
# fb2 = display_bus.allocate_framebuffer(_BUFFER_SIZE, lcd_bus.MEMORY_INTERNAL | lcd_bus.MEMORY_DMA)

import ili9341  # NOQA
import lvgl as lv  # NOQA


display = ili9341.ILI9341(
    data_bus=display_bus,
    display_width=_WIDTH,
    display_height=_HEIGHT,
    backlight_pin=_BL,
    backlight_on_state=ili9341.STATE_PWM,
    color_space=lv.COLOR_FORMAT.RGB565,
    color_byte_order=ili9341.BYTE_ORDER_RGB,
    rgb565_byte_swap=True
)


import task_handler  # NOQA

import xpt2046  # NOQA

spi0_bus = machine.SPI.Bus(
    host=2,
    mosi=32,
    miso=39,
    sck=25
)

touch_dev = machine.SPI.Device(
    spi_bus=spi0_bus,
    freq=_TOUCH_FREQ,
    cs=_TOUCH_CS
)


display.set_power(True)
display.init(type=1)
#display.set_rotation(lv.DISPLAY_ROTATION._180)
display.set_backlight(100)
indev = xpt2046.XPT2046(touch_dev, swapxy=True ,startup_rotation=2)

# 0     - works nicely, but sideways
# 1     - sketchy - might be _WIDTH/_HEIGHT mixup?
# 2     - works nicely, but sideways
# 3     - sketchy backwards horizontal
# 4

#touch_dev = machine.SPI.Device( spi_bus=spi_bus, freq=_TOUCH_FREQ, cs=_TOUCH_CS)
#cnd    indev = gt911.GT911(touch_dev)  AttributeError: 'Device' object has no attribute 'write_mem'   File "gt911.py", line 50, in _write_reg

th = task_handler.TaskHandler()

scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x000000), 0)

slider = lv.slider(scrn)
slider.set_size(300, 50)
slider.center()

main_label = lv.label(scrn)
main_label.set_text('HELLO WORLD!')
main_label.align(lv.ALIGN.CENTER, 0, -50)

# Create and position the R label
r_label = lv.label(scrn)
r_label.set_text('R')
r_label.set_style_text_color(lv.color_hex(0xFF0000), 0)
r_label.align_to(main_label, lv.ALIGN.OUT_TOP_LEFT, -20, -10)

# Create and position the G label
g_label = lv.label(scrn)
g_label.set_text('G')
g_label.set_style_text_color(lv.color_hex(0x00FF00), 0)
g_label.align_to(main_label, lv.ALIGN.OUT_TOP_MID, 0, -10)

# Create and position the B label
b_label = lv.label(scrn)
b_label.set_text('B')
b_label.set_style_text_color(lv.color_hex(0x0000FF), 0)
b_label.align_to(main_label, lv.ALIGN.OUT_TOP_RIGHT, 20, -10)

Screenshots:-

[kdschlosser]

with the XPT touch you ALWAYS need to run the calibration routine. Do not set the swap_xy parameter and simply initilize the driver then add this code directly below the driver startup..

if not indev.is_calibrated:
    indev.calibrate()

The calibration data is automatically saved into NVS so it is persistent between restarts. If you remove erasing the ESP32 prior to flashing firmware the changes will even be persistent between flashes of new firmware.

[hudsonmdkd]

First - thank you both (kdschlosser and gitcnd) for the work you have put into this! Kevin in particular, I can't believe how much you have done to make building LVGL so easy for the rest of us!

I am totally new to all of this and just got the CYD board. This is my first time getting the firmware to build and upload, and my first attempt at running a demo on the display.

As always, ymmv, so wanted to share a couple of things I discovered while trying to get this going.

1. I found that I had to remove the swapxy=True on the touch to even get the sample code to run - it was giving me an error (TypeError: unexpected keyword argument 'swapxy'). Simply removing that argument seemed to do the trick.
2. Once it was running, the display was acting up - I had to swap the _WIDTH and _HEIGHT values to get things to display properly. The text/slider now display correctly, and I can move the slider successfully, but everything is in portrait mode versus the landscape that appears to be intended.

I'm going to keep poking at it, but really appreciate the starting point!
-Matt

[kdschlosser]

OK so here is the skinny on your current issues.

I will update the example. I am sorry I forgot to remove that as I changed the API when I added the calibration routine.

Rotation is always a sore point when dealing with these small sized displays. There really isn't a standard on how it is done tho they have tried to make one it hasn't taken hold (probably because of the cost involved in getting certified).... The other issue with displays is the display panel and the driver IC are 2 wildly different pieces. Tho most display you purchase come with the driver IC built in the manufacturer is the one that purchases the panel from one vendor and the driver IC from another and puts the 2 together so you get a display.. a panel can have the exact same pixel count and exact same color depth but have a different resolution. All panels have a "native" resolution which is the actual width and height of the display in pixels. For whatever reason display manufacturers will flip those numbers around when selling a display. so ma panel that is native 400 x 800 resolution ends up being sold as an 800 x 400. This is infuriating to say the least because it causes a headache when trying to get the display running... So keep that in mind...

Then you have the display IC and how it handles orientation. This once again another sore subject because if we use exactly what is stated in the data sheet for the display IC things might end up very different looking with the display that is attached. That is again due to the native orientation of the display but also it has to do with how the display has been mounted in whatever it is being used in.

what you need to do to make everything work as it should is to get the display to show in it's native resolution so if it is a 400 x 800 display then the width should be set to 400 and the height to 800. These do not get set to how you want to view it that is what the rotation does. but we need to have a starting point and the native starting point is where we need to be.

Then we have the touch. the resolution of a touch panel might not align with specific pixels of the display. The touch IC could have a resolution of 1024 x 768 instead of 400 x 800. see the issue there? That is what the touch calibration will fix. It remaps the ranges and it also handles alignment issues with the touch panel. If the touch panel has been attached to the display slightly crooked fear not. the touch calibration creates a transform matrix that will take care of doing a digital alignment of the panel.

So remember display in native resolution then start the touch panel, then do the calibration of the touch panel. That is the order things need to be done in.

Because if differences in display panels and display IC's there is what is called an orientation table. This orientation table holds the register values for the different rotations. the goal is the display always rotates clockwise meaning the rendered grafix do, you have to physically turn the display counter clockwise to view it. That is how everything works so if you make any adjustments to the orientation table they are set as follows.. [0°, 90°, 180°, 270°].. If you have the display set to it's native resolution but things are out of wack then you might need to make an adjustment to the orientation table to get it to display correctly.

what I need to know is what the width and height are of the display. and I need to know if it actually aligns properly with what is being displayed.

as an example

width x height == layout
320 x 480 == portrait
480 x 320 == landscape

If you set the width and the height to 480 x 320 but it's being displayed in portrait then there is an issue that needs to be fixed. If the layout is correct for the resolution being given and the touch is working properly then we are in great shape. all you need to do is rotate the UI using display.set_rotation(lv.DISPLAY_ROTATION._90) and that will change the layout so it is landscape. Touch is automatically taken care of at the same time. If what is being display is upside down because of how the display is mounted there is also lv.DISPLAY_ROTATION._180 and lv.DISPLAY_ROTATION._270 to handle that problem.

The cool thing with how the code is written is the rotation is not a compile time thing that has to be set. It is a runtime thing. That means you can dynamically rotate the display at any point in time while your code is running. Welcome to the world of handheld portable devices and MEMS sensors, you can change the rotation based on how the user is holding the device.

[kdschlosser]

The orientation tables in the display drivers are set to what seems to be the most popular displays and how their touch panels are attached to the displays There are cases where the orientation tables will need to be adjusted to get the touch to work properly where it's not upside down. Calibration does solve this problem but the cost is additional overhead because of the math involved. This is one of the things I plan on moving into C code because it will be able to do the math about 200 times faster. ideally if you are able to get the touch oriented to the display graphics properly without needing to run the calibration that is always going to be the best way to do because then there is only a very small amount of overhead when using rotation and no overhead when no rotation is used.