ES3N28P board

[uraich]

Hi, I bought a LCD Wiki ES3N28P board with a 320x240 pixel display controlled by an ili9341 controller.
I created a pin definition file (hw_es3n28p.py) using the es3n28p manual and I tried everything with a standard micropython and this ili9431 driver
Things seem to work apart from a color problem.
Now I tried a simple program in lvgl_micropython drafted after the example project. Compilation for the esp32s3 for the ili9341 and the ft6336 touch pannel looked ok. I had some problems during compilation because the esp-idf virtual environment was located in ~/.virtualenvs by esp-idf install.sh (esp32.py did not find it) and flashing did not work because the first arguments in the argument list were -m esptool (esptool should be called via python and not directly).
I somehow managed to fix these and I managed to flash lvgl_micropython to the board.
Then I wrote
basic.py
to try it, but I had no luck.
My backlight is active high and did not come on (is self._backlight_pin.value(not backlight_on_state) correct?). I removed 'not' and the backlight came on.
First I called display.init(), which crashed because it cannot find _ili9431_init.py. Setting a type helped.
I do not see _flush_cb being called.
On the display I see a single small black vertical line. Changing the screen background color has no effect. How can I debug these problems?
I copied ili9341.py to myili9341.py and display_driver_framework.py to mydisplay_driver_framework.py and I uploaded these to be able to easily make changes. Of course I modified myili9341.py to call mydisplay_driver_framework.py.
Any hints on how to debug this thing? Is it possible to draw simple objects (e.g. a color filled rectangle) with the driver without passing through lvgl? Any other hint?
Thanks

[kdschlosser]

OK put on the brakes for a second..

the MCU you have is an ESP32-S3 N16R8. That means you have 8MB of PSRAM and 16mb of flash. Wat is not know is if the flash is quad spi or octal spi and we need to know that...

The display IS that is being used is an ILI9341V and it states that the IC is using a 4 lane connection to the MCU. That means the display is using quad SPI.

I am not sure why you are trying to use a driver that has nothing to do with this library and I am not going to be able to assist you with that driver because I am not the person that wrote it. There is a driver for your display that is included with this library and I recommend that you use that driver. If you have an issue with the driver that is included with this library I will be able to help out with any issues you might be having...

The file you have provided that contains the code you are running doesn't include a lot of code that is being imported in other files. I am not going to be able to assist unless I see all of it.

[uraich]

Hi Kevin,
The MCU is octal spi and I got the settings right, first go. The interpreter worked fine. Well, I had some problems with your builder/esp32.py script, as explained above but was able to fix this.
It is not easy to figure out exactly what needs to be done to get a first hello_world program to run on a CPU card with a screen and touch combination that is not in the README and of course you cannot describe all the combinations existing.
So, I ended up with a black screen and lvgl_micropython looked like a black box to me.
Therefore I tried a standard micropython (without lvgl) with an external ili9431 driver, which I could easily upload. If I managed to get this to work, then I would at least understand the initialization settings your driver would need. I did not expect any help from you on this. In fact, that worked except of wrong colors, which I did not mind. So, experiment ended, back to lvgl_micropython:

In order to figure out what was going wrong, I extracted your ili9341 driver and display_driver_framework, renamed them and uploaded the modified versions to the ESP32 (this is probably the "additional imports" you are referring to) . Now I could put print statements into the driver to try and figure out what went wrong. I drafted my hello world program (I called basic) after main in temp_humidity_micropython_lvgl, the project you linked into your README. This crashed, because the display init now expects an init type (1 or 2). Is is better to default the type to 1 instead of None, to avoid the crash? or to supply _ili9431_init.py which is expected when type == None? There is no mention in the README about this.The main.py program from the example project would also crash. I guess, the type parameter was added later.
With type set to 1 the program did not crash any longer but the screen stayed black. Again, I referred to main.py but could not see any reason, as compared to my program, why this could be the case.
More print statements in your renamed driver showed that the backlight was off. (main.py does not switch it on either). Therefore I modified your driver to switch the backlight on (I reversed this later and called the corresponding lvgl function to do that in the basic.py program). But still nothing on the screen.
More print statements in the driver showed that flush_cb was never called and therefore the image was not transferred to the display. Finally I figured out, that I had to call the task_handler for this to happen.
That finally made things work and I could revert to your original driver without all the prints. Here the colors were also wrong but I was able to fix this rather quickly. The main problem was that black and white were inverted.
You see that using your bindings is not as simple as that, if you start with an unknown board. Maybe I should write a short note, on the points you should be careful about, based on my experience? You might want to add it to the README?
One more thing:
I think that you have a bug in builder/esp32.py: When calling the compile script with deploy added, the script crashes when trying to flash. I printed out the args you pass to esptool and the first 2 args are -m esptool. These are the parameters you need if you call esptool via python, but you are calling esptool directly and then "-m esptool" must be removed.

Let me take this opportunity to thank you for the tremendous job you are doing. Thank you also for quick answers in the discussions.
Now I put on the brakes!

[kdschlosser]

No worries. I will help you get up and running. It's actually a lot easier than you think it is...

Using the information from that one file that you attached Here is a code example that should work for ya...

from micropython import const

import lcd_bus
import ili9341
import machine
import lvgl
import i2c
import ft6x36
import lvgl as lv


# display settings
_WIDTH = const(240)
_HEIGHT = const(320)
_HOST = const(1)
_LCD_FREQ = const(40000000)

_LCD_DC = const(46)
_LCD_CS = const(10)
_LCD_BL = const(45)

_SPI_MOSI = const(11)
_SPI_MISO = const(13)
_SPI_SCK = const(12)

_TP_SDA = const(16)
_TP_SCL = const(15)
_TP_RST = const(18)  # not used
_TP_INT = const(17)  # not used

# -------------------------
# SPI BUS
# -------------------------
spi_bus = SPI.Bus(
    host=_HOST,
    mosi=_SPI_MOSI,
    miso=_SPI_MISO,
    sck=_SPI_SCK
)

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

# -------------------------
# I2C BUS
# -------------------------
i2c_bus = i2c.I2C.Bus(0, _TP_SCL, _TP_SDA)
tp_device = i2c.I2C.Device(i2c_bus, ft6x36.I2C_ADDR, ft6x36.BITS)

# -------------------------
# DISPLAY DRIVER
# -------------------------
display = ili9341.ILI9341(
    data_bus=display_bus,
    display_width=_WIDTH,
    display_height=_HEIGHT,
    backlight_pin=_LCD_BL,
    color_space=lv.COLOR_FORMAT.RGB565,
    # color_byte_order=BYTE_ORDER_BGR,  # this may fix your color issue. 
    rgb565_byte_swap=True  # you might need to set this to False.
)

display.set_power(True)
display.init(type=1)
display.set_color_inversion(True)  # you might need to change this to False

tp_driver = ft6x36.FT6x36(tp_device)

# always set the rotation after the touch has been started
display.set_rotation(lv.DISPLAY_ROTATION._90)

display.set_backlight(100)
        
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x00ff00), 0)
dispp = lv.display_get_default()

# Create a white label, set its text and align it to the center
label = lv.label(scrn)
label.set_text("Hello world")
label.set_style_text_color(lv.color_hex(0xffffff), lv.PART.MAIN)
label.align(lv.ALIGN.CENTER, 0, 0)

# use the task handler to handle when the display is supposed to be updated.
# it's easier to let the code I wrote handle this. 
import task_handler

th = task_handler.TaskHandler()

There are several things that control the color that would cause it to not be displayed properly.

• color_byte_order: there are 2 setting for this, either BYTE_ORDER_RGB or BYTE_ORDER_BGR. it is defaulted to the first one.
• set_color_inversion: this is a function in the driver. It takes True/False as a parameter. This will invert the binary for the pixel data.
• rgb565_byte_swap: Typically this needs to be done but not always. leave it how it is set at True and if all of the rest of the things don't work try setting it to False

I believe you need to have your settings as I have set them in the code example I gave you.

[kdschlosser]

If the build script is crashing push the output to a file and attach the file to a post here so I can take a look at it. To do that add > output.log to the end of your build command. When the build is running you will not see anything on the screen so wait until you get a prompt again and that is when it will be finished.

[uraich]

Thank you so much. Even before your code I already had the thing working and my code looks very much like the one you sent me.
Please have a look at the init function of display_driver_framework on the ili9341. I think it would be better to change the parameter default to 1 or 2 or to provide a _ili9341_init routine. This would avoid a crash if no type is given.
Now I can start implementing the examples. I intend to split apps into a header.py file with all the init code needed by all apps, then the gui code, which is of course different for each example and finally a trailer with an endless loop, which avoids that the program drops back to the repl.You can then create a working example simply by concatenation of the files.

[kdschlosser]

can't do that. the reason why it is like that is because other types of display do not have an initialization value that needs to be passed. so the default is None. when the code sees that it is None then the code uses a different import for the init sequence.

[uraich]

I send you the script I use to compile my esp32 version of lvgl and the log.
compile_esp32s3.sh
and this is the crash report:
crash.txt
As you can see, it compiled fine. The problem is that your script calls esptool directly (not the python -m command) and then '-m esptool' is interpreted as non existant parameters to esptool.
I simply wrote another flash.py script, with the correct command, you print just before the crash log text and that works.

[kdschlosser]

When the build is finished the last output that you see is instructions on what to do to flash the ESP32. Copy that line and paste it into the script you send me after the build command. replace the port as needed to align with the port you have the ESP32 plugged into. Then it will work without any issues by simply running the script that has the build command and the flash command.

[uraich]

That's what I did.

[kdschlosser]

you used the exact command that is at the end of the build output without using the deploy argument?

[uraich]

Well, I put the esptool command, that is printed at the end of the build and put it into a separate shell script. I then used this shell script to flash the interpreter.
One more little thing:
I told you that I had worked with Amir Gonnen to produce the Python equivalent of the C examples in the lvgl docs. I still have this code and I started to adapt it to the new interpreter. You can find the information here:
I created header and trailer files with the needed initialization code such that the GUI code is separated out. Combining header_unix.py, your_program.py and trailer_unix.py allows to create a working unix program, idem for the esp32 with header_esp32.py ...
There are 2 shell scripts which do the concatenation: run_lvgl.sh for unix and make_esp32.sh for the esp32.
The getting_started examples are working.

[kdschlosser]

I have never heard of anyone having an issue with using that command that is printed out at the end of the build. I use it and it works fine. Is the only thing you are updating is the port correct?

If you can send me a log of the complete build output I want to see if something is getting mucked up somewhere in the build script that is mangling that output for some reason.

[uraich]

Sorry Kevin, I guess I explained myself badly or you somehow misunderstood me. I told you that I had a problem with the build command when putting deploy at the end (we discussed this and you saw the output of the command). I saw however, that the build was successful and that the problem came from the call to esptool exclusively. Therefore I copied the flash command you print at the end of the build, into a new shell script and I used that script to do the flashing, and that worked perfectly! I got my lvgl_micropython uploaded and I was able to work with it. I told you about the problems I had when writing my first lvgl hello world program for the esp32, but these problems are also solved!
I now have a lvgl_micropyhon with which I can work! At least for the moment, there is no problem left.
It would be interesting for me however if I could get access to the file that is created by the binding generator. Do I find this somewhere after a build?
Thanks again for your help

[kdschlosser]

you can get access to it. It's in the build folder for your board in lib/micropython/ports/esp32/....

I wanted to make sure the build was outputting the correct command for the flashing instructions. I have to look at how the deploy is being handled and I would need a copy of the flash command the build is outputting to see where I am mucking it up in the build script when doing the deploy.

[uraich]

I can tell you, where you are "mucking up":
You should do this (for my board):

python -m esptool --chip esp32s3 -p /dev/ttyACM0 -b 460800 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_size 8MB --flash_freq 80m --erase-all 0x0 /opt/ucc/micros/esp32/lvgl_micropython/build/lvgl_micropy_ESP32_GENERIC_S3-SPIRAM_OCT-8.bin

but you are calling esptool directly. In my case, I also have esptool installed as a command as you probably also do. The command you give in the compile script, when adding deploy is this:

 esptool -m esptool --chip esp32s3 -p /dev/ttyACM0 -b 460800 --before default_reset --after hard_reset write_flash --flash_mode dio --flash_size 8MB --flash_freq 80m --erase-all 0x0 /opt/ucc/micros/esp32/lvgl_micropython/build/lvgl_micropy_ESP32_GENERIC_S3-SPIRAM_OCT-8.bin

To try this, I removed the first two entries in the argument list (args). In line 1699 of builder/esp32.py (or close to it, as I had to modify the script, such that it can find my esp-idf python virtual environment) you call: esptool.main(args). With "-m" and "esptool" removed from the args list it works.
Now, I do not know if simply removing these arguments is the best solution to the problem.

[kdschlosser]

OK I just pushed a commit that should fix it.