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.

[SeanTheITGuy]

If I'm not mistaken, the serial comms bug you refer to affects the C3 and C6 but not the ESP32-D0WD, right? Regardless, the main issue I had with this board seeming to be unstable was a power related issue. When the screen intializes, it's a thirsty board, and most USB ports lack the amperage to keep the board stable. To that end, while working on it, I've hooked it up to external 5v using the included JST connector as well as the USB port to the computer. With the board in question here, with two USB ports, you could probably run the computer to one and a usb power line from a wall adaptor or a battery bank to the other.

[dosipod]

Thank you guys , I feel good to know that it is not only me with this board ( I honestly now know why it was only $2 ) . I am using a laptop now to experiment further which i will continue to do . I will post here if I get somewhere but I do wish to warn others that you do get what you paid for with this board as wiring an external display to a bare esp32 might not be a bad idea given the shortcoming I could see

[dosipod]

@RetiredWizard It is working now ( at least the size ) , color are still off but text and pics fits now , I used your commands with only width=240,height=320 swapped

display = adafruit_ili9341.ILI9341(bus,width=240,height=320,backlight_pin=board.LCD_BCKL)

I will continue to experiment to fix the colors mismatch which i assume is okay with your board , appreciate the quick help from you both , if you have any idea on how to fix that also then please let me know

[RetiredWizard]

It took me a bit to track down the JST connector that came with the board, it's a size I don't have stocked :grin: but adding the supplemental power didn't seem to change anything for me. The board is drinking about 150mA from the second supply so I bet some USB ports would have problems.

The C3/C6 bug might be something slightly different than the ESP32 paste bug but there's definitely an issue with the ESP32 as well. I just tried the same large paste on an ItsyBitsy ESP32 and it behaves the same way as on the Sunton, after about 240 characters the data in the paste buffer starts getting dropped.

[RetiredWizard]

if you have any idea on how to fix that also then please let me know

If you point me to where you found the LVGL_320_240.bmp file, I'll load it up and see if the colors look better.

[dosipod]

I could not add it here but it is just a bmp ( 24 bit bitmap ) file i made with paint to calibrate the display , the same way worked with TTGO display If you just load a picture with green , red and blue then that would do the same

[SeanTheITGuy]

This is a colourspace issue. Do: display = adafruit_ili9341.ILI9341(bus,width=240,height=320,backlight_pin=board.LCD_BCKL, invert=True)

The invert=true should put you in the right colorspace.

[dosipod]

Adding invert=true give me TypeError: unexpected keyword argument 'invert'

[RetiredWizard]

I suspect the invert keyword goes somewhere else, but I can't find it in the documentation, Sean may come up with it.

I don't know if this is the right approach but you could try using the built in color spaces and see if any of them work for you:

face = displayio.TileGrid(odb,pixel_shader=displayio.ColorConverter(input_colorspace=displayio.Colorspace.RGB565_SWAPPED))

The builtin color spaces are:

RGB888: Colorspace¶
The standard 24-bit colorspace. Bits 0-7 are blue, 8-15 are green, and 16-24 are red. (0xRRGGBB)

RGB565: Colorspace¶
The standard 16-bit colorspace. Bits 0-4 are blue, bits 5-10 are green, and 11-15 are red (0bRRRRRGGGGGGBBBBB)

RGB565_SWAPPED: Colorspace¶
The swapped 16-bit colorspace. First, the high and low 8 bits of the number are swapped, then they are interpreted as for RGB565

RGB555: Colorspace¶
The standard 15-bit colorspace. Bits 0-4 are blue, bits 5-9 are green, and 11-14 are red. The top bit is ignored. (0bxRRRRRGGGGGBBBBB)

RGB555_SWAPPED: Colorspace¶
The swapped 15-bit colorspace. First, the high and low 8 bits of the number are swapped, then they are interpreted as for RGB555

There's apparently also a "BGR" version of each of these, i.e. BGR555_SWAPPED, etc...

[SeanTheITGuy]

Yes, it's something about being in BGR when it expects RGB, or vice versa. The reds are blues and the blues are reds.

[RetiredWizard]

Unfortunately, it looks to me like the colorspace that works on my version is RGB888 and for some reason there is no BGR888 :frowning_face:

[SeanTheITGuy]

You can change the BGR/RGB in, again, MADCTL, in the init sequence :D

[dosipod]

RGB555_SWAPPED seems very close ( not 100 % ) but I suspect that may also have to do with the pictures i am using which i have to change in any case due to size . I will try to load new pictures with reduced size and see the effect of changing color spaces .

I can close this if you wish ( i do want to keep it open as much as possible to pick your brain :) )

I also see invert=true in the doc with other drivers

[SeanTheITGuy]

You can always come on the adafruit discord. It's more or less the same crowd in #help-with-circuitpython and other channels as you'd get here.

[RetiredWizard]

Try renaming/deleting your adafruit_ili9341.mpy file and putting this one on your device. adafruit_ili9341.zip

It should then take the invert keyword as well as as bgr=True keyword option which may be what you want as well.

If this works, we can put the change in as a PR to the library.

[dosipod]

I did join the discord today looking for info on that board , i only came to gh because i am just experimenting with CircuitPython and used the installer with other boards like the TTGO which worked out of the box so thought that the beta testing report would help ( granted the board listed here https://circuitpython.org/board/sunton_esp32_2432S028/ is not the exact one I have ) @RetiredWizard sure i will try the new adafruit_ili9341.mpy

[RetiredWizard]

We should probably take this to the Discord Circuitpython help channel and create a thread though, I'm not sure how much noise this is going to generate for the Adafruit folks as an issue.

[RetiredWizard]

oops :/ adafruit_ili9341.zip

This may actually switch the rotation as well, so you may need to swap back the width and height values.

[dosipod]

@RetiredWizard The new driver seems to work ( the display rotated for some reason with bgr=True so i tried to adjust it ) display = adafruit_ili9341.ILI9341(bus,width=240,height=320,backlight_pin=board.LCD_BCKL,bgr=True,rotation=270)

Sure i will close this as the display is kinda working ( I prefer if it is closed by someone else ) , appreciate the help really , i unfortunately past my allocated time and cant be on discord for this small thing until i do a bit of homework on Circuitpython but i am kinda impressed by the quick help i got on this , please keep it up

[DJDevon3]

yep that's the way to do it. There was no argument for invert. First time I've seen a BGR argument, didn't know that was a thing, very cool! There will be more driver options like this going into 9.0. This format makes it much easier to add optional init sequence arguments.

    def __init__(self, bus: FourWire, *, bgr: bool = False, invert: bool = False, **kwargs: Any):
        init_sequence = _INIT_SEQUENCE
        if bgr:
            init_sequence += (
                b"\x36\x01\xC0"  # _MADCTL Default rotation plus BGR encoding
            )
        else:
            init_sequence += (
                b"\x36\x01\xC8"  # _MADCTL Default rotation plus RGB encoding
            )
        if invert:
            init_sequence += b"\x21\x00"  # _INVON

        super().__init__(bus, init_sequence, **kwargs)

You can also add rotation. Native display rotation is separate from displayio rotation. Native rotation can run more efficiently. However it adds complexity with rotation upon a rotation in conjunction with displayio. Ideally you would setup native rotation here and then always have displayio rotation=0. Native rotation can really complicate things when it comes to a touchscreen because most touch drivers rely on native rotation always being 0. So if you add native rotation, displayio rotation, and then try to calibrate a touch driver.... things can get complicated.

Also rotation is independent of refresh orientation. You can have a display in landscape mode with a portrait mode refresh scan. It is possible to have a bottom to top, left to right, or right to left refresh. Ideally you want to set refresh mode to match the native rotation as most people are accustomed to top to bottom refreshes.

These and many more display options become available to you with init sequence customizations and reading the datasheet to see what options are available to customize.