Support ESP32-S2, ESP32-C3, ESP32-S3 #227
Comments
amirgon
added
help wanted
|
Run in to this issue while I was looking for support for imxrt11xx platforms, since the main repo already supported them. I would like to do it my own, but I could not find any detailed document for what exactly need to be done. The readme of this repo is all about how to use this lvgl as a mp module, but mothing about porting. Another article I could find is this https://blog.lvgl.io/2019-02-20/micropython-bindings The readme link is link to this repo's readme, bruh... |
|
@424778940z - See #242. That PR still needs some work, but when it's merged you will be able to add LVGL as a Micropython external C module, so porting to new architectures will be much easier. This issue is about supporting ESP32-S2, ESP32-C3, ESP32-S3 because ESP ports have an extra complication where in addition to LVGL, the ESP BSP library API (ESP-IDF) is automatically converted too, so users can use it directly in Python code. (See Pure Micropython Display Driver in the blog). You are right that the documentation focuses mostly on how to use the Micropython bindings. That's what interest most users. Advanced users who want to port to new architectures are welcome to diff micropython repo with lv_micropython and learn from the differences. Remember that all the work, including the documentation, was done by volunteers on their spare time. So comparing this to Microsoft error message is not really fair. |
|
I have been using esp32s3 for a whole day, and I keep reporting errors. It turns out that esp32s3 chip is not supported yet!! |
Correct. |
|
Waiting for Support ESP32-S2, ESP32-C3, ESP32-S3! |
@jd3096-mpy see #243 - this adds ESP32-S3 support. |
|
I hope this gets added soon. I just wrote a python driver for the ili934 using an 8bit parallel interface. all of the work functions are decorated with I am not able to test it because I only have s3's on hand at the moment. There are a couple of things that I have forced like setting the d0-d7 pins sequentially to GPIO pins that are also sequential and are all in the same GPIO register. Makes setting the state of the GPIOs easier to deal with. I still have to tie in the touch interface and this is going to be a tad more challenging to do because of the shared pins. I need to know more about the mechanics of how the input side of things works in lvgl to be able to do this. Or if a Python driver can be written for a touch interface. I don't know how the loop in lvgl works. I am hoping that the use of viper code isn't going to mess with lvgl either. I am making an assumption that the viper code runs in the same manner as the native code and when the code is running things like ISRs don't break into the running code. The parallel interface should offer a HUGE speed increase because there is no need to swap the high and low bytes for the colors. I am also directly accessing the registers for the GPIOs through pointers and not using the built in machine.Pin class. Maybe there is someone that would be willing to lend a hand with getting the touch interface working. |
|
On a side note I will match the 100.00 already being given to get this done. |
|
There is a choice to make here. Code can either be duplicated from the latest micropython esp32 port in the drivers for the esp32 port in lv_binding_micropython OR there can be a minimum micropython version that gets set into place for the esp32 port and includes from micropython can be made in the drivers for lvgl so the code isn't duplicated. with the esp32s3 there is no adc_gpio_init function available and the way the adc blocks are handled is different. micropython has already sorted out the mechanics of this and created helper functions to deal with it. I think that setting a minimum version of micropython that lv_binding_micropython is allowed to use would the cleanest and also the easiest way to get it working with all of the different esp32 variants. Most of the issues are differences in the macro names or some macros not being defined all together. I corrected the errors in the gpio_to_adc array in the modrtch.c file using the following code #define GPIO_TO_ADC_ELEMENT(adc, x) [x] = CONCAT3(CONCAT3(ADC, adc, _GPIO), x, _CHANNEL)
static const int gpio_to_adc[] = {
#if CONFIG_IDF_TARGET_ESP32
GPIO_TO_ADC_ELEMENT(2, 0),
#elif CONFIG_IDF_TARGET_ESP32C3
GPIO_TO_ADC_ELEMENT(1, 0),
#endif
#if CONFIG_IDF_TARGET_ESP32
GPIO_TO_ADC_ELEMENT(2, 2),
GPIO_TO_ADC_ELEMENT(2, 4),
#elif CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3 || CONFIG_IDF_TARGET_ESP32C3 || CONFIG_IDF_TARGET_ESP32H2
GPIO_TO_ADC_ELEMENT(1, 1),
GPIO_TO_ADC_ELEMENT(1, 2),
GPIO_TO_ADC_ELEMENT(1, 3),
GPIO_TO_ADC_ELEMENT(1, 4),
#endif
#if CONFIG_IDF_TARGET_ESP32C3
GPIO_TO_ADC_ELEMENT(2, 5),
#elif CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3 || CONFIG_IDF_TARGET_ESP32H2
GPIO_TO_ADC_ELEMENT(1, 5),
#endif
#if CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3
GPIO_TO_ADC_ELEMENT(1, 6),
GPIO_TO_ADC_ELEMENT(1, 7),
GPIO_TO_ADC_ELEMENT(1, 8),
GPIO_TO_ADC_ELEMENT(1, 9),
GPIO_TO_ADC_ELEMENT(1, 10),
GPIO_TO_ADC_ELEMENT(2, 11),
#endif
#if CONFIG_IDF_TARGET_ESP32 || CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3
GPIO_TO_ADC_ELEMENT(2, 12),
GPIO_TO_ADC_ELEMENT(2, 13),
GPIO_TO_ADC_ELEMENT(2, 14),
GPIO_TO_ADC_ELEMENT(2, 15),
#endif
#if CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3
GPIO_TO_ADC_ELEMENT(2, 16),
GPIO_TO_ADC_ELEMENT(2, 17),
GPIO_TO_ADC_ELEMENT(2, 18),
GPIO_TO_ADC_ELEMENT(2, 19),
GPIO_TO_ADC_ELEMENT(2, 20),
#endif
#if CONFIG_IDF_TARGET_ESP32
GPIO_TO_ADC_ELEMENT(2, 25),
GPIO_TO_ADC_ELEMENT(2, 26),
GPIO_TO_ADC_ELEMENT(2, 27),
GPIO_TO_ADC_ELEMENT(1, 32),
GPIO_TO_ADC_ELEMENT(1, 33),
GPIO_TO_ADC_ELEMENT(1, 34),
GPIO_TO_ADC_ELEMENT(1, 35),
GPIO_TO_ADC_ELEMENT(1, 36),
GPIO_TO_ADC_ELEMENT(1, 37),
GPIO_TO_ADC_ELEMENT(1, 38),
GPIO_TO_ADC_ELEMENT(1, 39)
#endif
};and that has left me with the following compilation errors. as you can see most of the issues at this point are simple macro naming problems. the only one that is a big hang up is the missing adc_gpio_init function and that function is not so simple to replicate what it does. If a decision is made to use the already written functions to handle this issue in the esp32 port of micropython ass new esp32 boards get released changes will be made to micropython to handle those boards and little to no changes will need to be made in lv_binding_micropython to support the newer boards. |
|
is there someone willing to give this a try? decompress the attached file into driver/esp32 I was using this command to compile it I am getting this error and it might be something in my setup and not with the code changes I have made. I want to rule out the code changes I have made. |
|
ok I figured out what functions need to be removed from lv_espidf.c so the compiling completes without error. I need to figure out how to keep gen_mpy from creating those functions. The majority of lv_espidf.c doesn't even need to be created. There is no reason to expose the entire espidf to the python interpreter. The availability of running viper code pretty much negates exposing it all together. Using viper code the GPIO registers can be accessed directly which would allow for fast updates to the GPIO pins. I am not sure what other need there is to expose any of the espidf other than being able to manipulate the GPIOs |
|
If anyone wants to give this a go to see if it works I would appreciate it. It should compile without errors. I do not have an SPI display to test it with. https://github.com/kdschlosser/lv_binding_micropython/tree/esp32-s-c-h_support |
Good job! but report errors in the last stage:
|
|
did you use the repo I linked to or did you use the files I attached in a zip?? If you used the zipped files don't, use the linked repo instead |
Sorry，I git the wrong repo branch. |
I think there is still something wrong with SPI, I use lilygo t embed the screen is st7798v3 170x320 |
|
OK so there is a result at least. That's a good thing. going to have to hammer out any kinks in it. Can you post the exact Micropython code you are using? And do you have the exact model number of the Lillygo piece you are using? I want to see if everything is aligning properly between the screen the Micropython code and the c code.. |
|
and that returned value is ESP_ERR_INVALID_ARG hmmm... |
Yes,here is the error code form esp-idf WIKI [ESP_ERR_INVALID_STATE](https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/api-reference/system/esp_err.html#c. here's my mpy code: disp = st7789( lv.init() Load the screenlv.scr_load(scr)` fbdriver is the copy of ili9XXX.py so I can test the driver. |
Here is the offical repo: The GPIO marked in the picture is wrong, I am sure. https://github.com/Xinyuan-LilyGO/T-Embed/blob/main/example/tft/pin_config.h #define PIN_LCD_BL 15 |
|
I believe I found the issue. I committed the changes to that same branch on my fork that I linked to in a previous post. Give it a try again. It has to do with the DMA channel being used. If you have the repl open when you boot the ESP it will spit out any error codes if one does show up. |
|
Use the script below to run the test with import machine
import ili9XXX
import lvgl as lv
disp = ili9XXX.st7789(
mosi=11,
clk=12,
cs=10,
dc=13,
rst=9,
power=46,
backlight=15,
backlight_on=0,
power_on=0,
width=170,
height=240,
rot=ili9XXX.LANDSCAPE
)
lv.init()
scr = lv.obj()
btn = lv.btn(scr)
label = lv.label(btn)
label.set_text("Button") |
|
Traceback (most recent call last): Also no attribute:
SPI_HOST -- 0 only these const are defined I try to chagne these const with value instead It shows the same screen. |
Oh my god ,this repo works!!! power=machine.Pin(46, machine.Pin.OUT) disp = ili9XXX.st7789( lv.init() style_base = lv.style_t() Set only the properties that should be differentstyle_warning = lv.style_t() Create an object with the base style onlyobj_base = lv.obj(lv.scr_act()) label = lv.label(obj_base) Create another object with the base style and earnings style tooobj_warning = lv.obj(lv.scr_act()) label = lv.label(obj_warning) screen: |
GOD,I just found this repo works! Thanks for you working,too. |
|
OooooOOoOO I forgot one other thing. Just like before you need to specify the color depth in the same manner when compiling. changing 16 to whatever the color depth is for your display. That needs to be added onto the make.py compile line. |
|
There's some typing errors but after compiling it is stil hanging on task handler, the driver sends the first chunk of data to display and lvgl hangs, display is blank. |
|
OK i fixed the type errors and committed the changes. So that should be good to go. Let me see about returning the buffers as an array.array object. Maybe that will correct the problem. |
|
I just pushed a commit. see if that fixes the issue with the buffers. I have not tested the code at all so lemme know how you make out. |
|
Error compiling /include/modlcd_bus.h:173:48: error: 'BYTEARRAY_TYPECODE' undeclared (first use in this function) |
|
Ok I missed an include. I will see if I can get that fixed from where I am. I am not at home |
|
OK I added the include. |
|
I made a bunch of changes. I am hoping that this time I have the buffers fixed. It would be nice if it is. I updated the make.py script. The second go around compiling after changing the partition size is now a whole lot faster, it doesn't compile the entire things again. I also updated it so it resizes up and also down if needs be. I added a command line switch to turn off the resizing, I also have the script automatically disabling I2C for the time being. This is due to an upstream bug in MicroPython. It has been reported and hopefully it will be fixed along with the btree issue in the next release. Fingers crossed there. A added some additional output to the build that is easily seen so the user will know what is taking place when the build starts over again. Just informative messages is all. I did test compile before I committed and pushed the changes. So there should be no type errors when compiling. |
|
The code compliled but SPI display still not working, I've made some tests using a upy driver and the problem is that disp_drv.flush_ready() is never called in your code, this hags lgvl waiting the display, there's some problem with SPI transfer. Using soft SPI (without DMA) LVGL is running fine. |
|
There's too a error in framework line 274 " lv.flush_ready(disp_drv)" (not the cause of hang) , you could fix LVGL V8.3 for now because V9.0 API is a mess. |
|
OK I will have a look and see what's up with it. So the issue is in the bus driver somewhere. Just as a question what are the parameters you are passing to the bus driver. I would like to se if maybe I am initializing it incorrectly and if that is the source of the hang. I am going to dig out my MCU's and displays. I will put together a couple of testing setups. I probably will not do any more updating of the repo until I get everything working properly. |
this is the simple code I'm using to test |
|
ok so first thing is your frame buffer is WAYYYYY to big. it's not going to fit into DMA'able SRAM. I still have to add exceptions for the buffers failing to be made. That should fit without any issues. just a heads up with the ESP and using SPI. host 1 host 2 The reason why is due to it not being 100% hardware and a redirect needs to take place. That limits the speed the SPI is able to do. If you want full speed to be available then connect to those pins. You can save some pin connections still and set miso and cs to -1. the wp and hd pins are also set to -1 if you are not using quad spi. |
|
the speed is actually limited to 26.6 mhz. my bad on that one. |
|
I made a couple of small changes. so I would update your code and try it again with the buffer size change |
|
I added the exceptions for memory allocation. |
|
Also, version 9.0 isn't a mess. the API has changed. It works just fine. |
|
Tested reducing the framebuffer and the hang stopped but screen still blank( cant recall when I increased buffer size), recompiled new version and there's some errors on buffer error msg but compiled fine, the problem now is another error on flush cb: |
ESP32-C3/S3/S2 SPI can go up to 80Mhz using gpio matrix. only original ESP32 have this 26.6Mhz limit but I've tested and could reach 60Mhz on a ESP32 rev3 using SPI through GPIO matrix |
|
says it right here in the documentation
so 26.6 mhz is as fast as it will go using full duplex over the GPIO matrix. scroll to the top and check for yourself. The documentation is set to the ESP32S3. |
Yes, this note exists in all ESP32 model docs but only on ESP32 original there's a note about timing linking to it, all othes says
on esp32 original there's this note: The 26Mhz is only full duplex but I can't much use for full duplex on a display bus |
|
Update: fixed some code and now the LCD BUS using Spi is sending perfect data to display with or without DMA, the only problem is that the transmission needs to be syncronous because the code is unable to call a python function from C, direct calling gives infinite recurssion and sheduled call never gets called on Py VM. |
|
PS: I'm using the code with mpy malloc and works fine, the bus passing a array buffer and sending back with dereference from py |
|
Yes you can create a byte array and pass it to C code and it will work as a buffer. Problem is no ability to specify where that data is to be stored, DMA SRAM, DMA SPIRAM, SRAM or SPIRAM, It goes into where ever it is going to fit. |
|
I'm using your commit d782fec before change the frame buffers, on framework flush_cb need to uncomment the code to not get segfault when passing the buffer back to C and include
after flush_cb code to not hang LVGL on wainting flush loop, this way the LCD_BUS works in sincronous (slow) or unmanaged DMA (a little faster) |
|
I know what is going on with the flush function I am trying to dereference more memory than has been allocated. That is what is causing the segfault/hang. SIZE can no longer be used to determine the color depth that is being used. It should now read That should fix the issue in the flush function. |
|
How things are done is when the buffer gets passed to the display driver initially that buffer gets converted into an LVGL CArray. That CArray then gets passed to the flush function and this is the reason why you need to use the dereference. doing that converts the object into a MicroPython MemoryView object I have to change the C code to handle collecting the pointer from that memoryview object to pass it to the driver as an actual C pointer. I just figurred all of this out in the last couple of days. |
The hang is due to mp_sched_schedule never beeing called on python code ( maybe the lvgl wait flush never returns the control to mpy) and if you change to mp_call_function get recursion error |
|
After spending countless hours/days/weeks trying to get a mix of MicroPython 1.22, IDF 5.1.2 and LVGL 9.1 working as a USER_C_MODULE I could directly use from my MicroPython build using any and all resources I could find I finally caved and gave up trying to adapt existing solutions. I crafted a custom repository that is specialized for my use case but still worth sharing in case others find it useful and perhaps it is useful to get this issue, PR #242 or PR #341 moving. You can find the repository here: https://github.com/MathyV/lvgl_esp32_mpy If you have an ESP32 connected to an ST7789 display over SPI, this solution will probably work out-of-the-box for you. Finally, a small movie that shows it's working: PXL_20240516_011152235.TS.2.mp4 |
|
Thank you the countless hours/days/weeks you put into it and for sharing the result! 👍 @kdschlosser is into approaching it from a new perspective too and he also made good progress, but I'm not sure what is the exact status on his end. |
Micropython already supports ESP32, ESP32-S2, ESP32-C3, ESP32-S3.
However lv_micropython only supports ESP32 today.
The goal is to add support for ESP32-S2, ESP32-C3, ESP32-S3 in lv_binding_micropython and lv_micropython.
This includes:
Each should be built with the correct ESP-IDF version as explained in Micropython ESP32 port README.
Related issues:
This is a sponsored issue, meaning that if someone implements it he or she gets a payment from the Accumulated donations of LVGL. Learn more HERE.
We can give 100 USD for fully implementing this.
CC: @kisvegabor @embeddedt
The text was updated successfully, but these errors were encountered: