sunton_esp32_2432S028 ( usb type -c version on CircuitPython 9.1.0-beta.0)

[dosipod]

CircuitPython version

CircuitPython 9.1.0-beta.0

Code/REPL

not sure

Behavior

not sure

Description

I got a great deal on alie ( not sure now it is that great ) for $2 esp32 with sunton_esp32_2432S028
https://www.aliexpress.com/item/1005006470918908.html
Using CircuitPython 9.1.0-beta.0 on sunton_esp32_2432S028 the display is not working
as expected . It is the same HW listed here but with addional usb type-c
https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display

I am new to CircuitPython and not sure using another driver would solve this as the box
is labled with ST7789 but some say it might be using ILI9341 , i tried both but with no luck.

The HW worked as expected with openHASP and somewhat with tasmota ( did not have time to test much yet)

Sorry for the messy post and pics but i would be happy to provide any specific info that might help

Additional information

No response

[SeanTheITGuy]

the ILI9341 and ST7789 are virtually the same driver, and will work with the same init string (primarily what the driver provides). The only difference is that the ILI9341 has options for setting more finely tuned gamma settings. That looks like an offset error, but since the display is 320x240, which is the full capacity of that controller chip, there is no offset to change, to my understanding.

Are you releasing the display and then attempting to initialize it yourself with a driver? There is no need for that. Simply use "display = board.DISPLAY" without a release(). If that works, then something in how you were initializing the display manually was causing the issue.

[RetiredWizard]

Were the graphic displays you posted generated by CircuitPython code? If so, posting the actual CircuitPython code you used would be very helpful.

[dosipod]

I used CircuitPython with ttgo display and it worked as expected out of the box . In the case of sunton_esp32_2432S028 i used the default with the bin from here https://circuitpython.org/board/sunton_esp32_2432S028/
The text does not work as in the pic , the code i used for Bitmap is copy paste from the site

import board
import displayio
import time
import pulseio

board.DISPLAY.brightness = 0
splash = displayio.Group()
board.DISPLAY.root_group = splash

odb = displayio.OnDiskBitmap('/LVGL_320_240.bmp')
face = displayio.TileGrid(odb, pixel_shader=odb.pixel_shader)
splash.append(face)

Wait for the image to load.

board.DISPLAY.refresh(target_frames_per_second=60)

Fade up the backlight

for i in range(100):
board.DISPLAY.brightness = 0.01 * i
time.sleep(0.05)

Wait forever

while True:
pass

[SeanTheITGuy]

I wonder if the issue is that yours, unlike mine, is coming up with the screen in portrait on boot, for some reason, but circuitpython is trying to talk to it in landscape. Hence why a 240x240 pixel portion of the screen works, where the real screen and virtual screen overlap

[dosipod]

I am suspecting an issue with the driver as with openHASP i kinda faced the same issue until i changed it . I am wondering if the HW listed here https://circuitpython.org/board/sunton_esp32_2432S028/ is the one without usb type-c and hence my board is a new version . I wanted to keep CircuitPython if any info is needed but i will try to go back to openHASP and get as much details as possible of how did the display worked as expected and then try to apply the same changes to CircuitPython . Being new to CircuitPython does not help make this any faster but I will try to at least inform others that this might be that great HW after all as it seems with too many variants

[SeanTheITGuy]

Yes, the one the CircuitPython definition is based on is the version without the USB-C port. Makes me wonder what else they changed between revisions. I suspect the issue lies in the MADCTL command of the init sequence sent to the LCD. While mine starts up with a widescreen rotation with the provided settings, yours is starting up in portrait with a mismatch in the display object size to LCD dimensions. I'm not sure there's an easy answer, without someone having both versions to test.

[RetiredWizard]

There's probably a way to init the display with the correct init string using Python. So you would start by throwing away the board display (displayio.release_displays()) and then create a new display object using the displayio/fourwire builtin libraries.

[dosipod]

I am only testing that for educational reasons as the $2 price might also draw others to the same deal . I will try to document what changes is done in each firmware stating with openHASP and tasmota .

I am now facing issues serial flashing the HW as my PC rebooted twice so might be a while but never the less i will keep trying

[RetiredWizard]

These commands will manually build the display on the Micro USB display version:

import fourwire
import board
import microcontroller
import displayio
import adafruit_ili9341

displayio.release_displays()
spi = board.LCD_SPI()
bus = fourwire.FourWire(spi,command=microcontroller.pin.GPIO2,chip_select=microcontroller.pin.GPIO15)
import adafruit_ili9341
display = adafruit_ili9341.ILI9341(bus,width=320,height=240,backlight_pin=board.LCD_BCKL)

The adafruit_ili9341 library doesn't do anything except set the _INIT_SEQUENCE to be passed into displayio.Display so rather than calling adafruit_ili9341.ILI9341, you could call displayio.Display and pass in a modified init_string.

Edit: Added the missing spi assignment

[dosipod]

Thank you guys , i will surly try whatever possible .
I have managed to setup the display correctly with openHASP using a bin marked ili9342 driver

Not sure there is CircuitPython ili9342 driver ( i see only ili9341 ) but i will try the command listed by @RetiredWizard with ili9341 and any other driver that is available

[RetiredWizard]

I did get the displayio.Display call to work with this command:
display = displayio.Display(bus,init,width=320,height=240,backlight_pin=board.LCD_BCKL)
I filled the init variable with the init sequence from
https://github.com/adafruit/Adafruit_CircuitPython_ILI9341/blob/main/adafruit_ili9341.py

That should give you everything you need to try modified init_sequences on your device.

[RetiredWizard]

Interestingly, out of curiosity I set the init variable to an empty string "", and the display still came up fine after running my displayio.release_displays() script from above. I'm guessing that means the display doesn't reset it's initialization when the displayio.release_displays() command is executed.

[dosipod]

@RetiredWizard Thank you very much for the help
Not sure what happened now but tried your commands and facing issues with the board disconcerting from PC with serial ( I faced this even before ) and also facing network timeout . I would have to use another laptop shortly and possibly reboot the test
router as this board is rebooting my PC for some reason .

Just to double check with you meanwhile the needed changes for adding the ILI9341 driver .

1. Copy adafruit_ili9341.mpy & adafruit_ili9341.py under lib ( or is it only adafruit_ili9341.mpy )
2. set the _INIT_SEQUENCE as you listed ( i have no clue where and how to do that )

[RetiredWizard]

You only need the .mpy they are both the same library, the .mpy has just been pre-compiled so it's a bit more efficient and takes up less memory/space.

If you use the adafruit_ili9341 library you don't need to set the _INIT_SEQUENCE, the library defines the _INIT_SEQUENCE internally.

If you want to experiment with different _INIT_SEQUENCES, then you won't use the adafruit_ili9341 library, you'll create the display object using displayio.Display instead.

The ESP32 board is a bit difficult to work with since it doesn't create a CIRCUITPY drive and there seems to be a serial communication bug #8658.

I have the 2432S028 Sunton board with the MicroUSB connector and I've found that every other time I plug it into my computer the computer does not enumerate the serial port. I'm sure that's a symptom of the hardware design but I don't know if it's just my board, the particular version of my board or all of the S028 boards. I am using Linux, I don't know how other operating system would react to the inconsistent USB enumeration issue maybe your reboot issues are related.