I am using the current latest code in V9.0 so whatever is in that branch for the multi instance should also be in the master branch code for v9.0 of LVGL. Would have to ask @kisvegabor if that is the case.
I don’t know I guess I’m just very confused
lvgl@0f9ee is the master branch which updated yesterday. which means latest lvgl v9. the release v8.3.10 is literally latest release.
lvgl is still developing on v9. not yet released.
??? It looks right to me.
So I started from scratch, ripped out the old repo reinstalled and ran this command…
python3 make.py esp32 -mpy_cross -submodules -clean BOARD=ESP32_GENERIC BOARD_VARIANT=SPIRAM CFLAGS=“-DMICROPY_PY_MACHINE_I2S=0”
got error…
[ 70%] Building C object esp-idf/main_esp32/CMakeFiles/__idf_main_esp32.dir/workspaces/v2-lvupy-1.21/lv_binding_micropython/driver/esp32/lcd_bus/src/spi_bus.c.obj
make[3]: Leaving directory '/workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32/build-ESP32_GENERIC-SPIRAM'
make[2]: Leaving directory '/workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32/build-ESP32_GENERIC-SPIRAM'
make[1]: Leaving directory '/workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32/build-ESP32_GENERIC-SPIRAM'
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: Leaving directory '/workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32'
/workspaces/v2-lvupy-1.21/esp-idf/tools/check_python_dependencies.py:12: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources
Including User C Module(s) from ../../../../micropython.cmake
Found User C Module(s): usermod_lcd_bus, usermod_lvgl, lvgl_interface
/workspaces/v2-lvupy-1.21/lv_binding_micropython/driver/esp32/lcd_bus/src/modlcd_bus.c: In function 'allocate_buffers':
/workspaces/v2-lvupy-1.21/lv_binding_micropython/driver/esp32/lcd_bus/src/modlcd_bus.c:57:147: error: 'ret' undeclared (first use in this function)
57 | mp_raise_msg_varg(&mp_type_MemoryError, MP_ERROR_TEXT("Buffer size is to large to fit into DMA memory try decreasing the size (%d)"), ret);
| ^~~
/workspaces/v2-lvupy-1.21/lv_binding_micropython/driver/esp32/lcd_bus/src/modlcd_bus.c:57:147: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [esp-idf/main_esp32/CMakeFiles/__idf_main_esp32.dir/build.make:3504: esp-idf/main_esp32/CMakeFiles/__idf_main_esp32.dir/workspaces/v2-lvupy-1.21/lv_binding_micropython/driver/esp32/lcd_bus/src/modlcd_bus.c.obj] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/Makefile2:4797: esp-idf/main_esp32/CMakeFiles/__idf_main_esp32.dir/all] Error 2
make[1]: *** [Makefile:130: all] Error 2
make failed with exit code 2, output of the command is in the /workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32/build-ESP32_GENERIC-SPIRAM/log/idf_py_stderr_output_82078 and /workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython/ports/esp32/build-ESP32_GENERIC-SPIRAM/log/idf_py_stdout_output_82078
make: *** [Makefile:62: all] Error 1
@SL2021-Dev ➜ /workspaces/v2-lvupy-1.21/lv_binding_micropython (MicroPython_1.21.0_Update) $
At least im getting past the 16 to 18% mark !
Is setuptools still an issue?
DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources
when I do the next commit you will not have to specify the cflags. it will take care of this internally.
So what do I need to do now Kevin in order to build this repo.
wait a few minutes for me to test the last changes I made to make sure it will compile.
At the moment I really don’t need to remove any items, I just copied that from a previous post.
I thought It had something to do with the failure to build.
Ok I just tested it and it does compile.
python3 make.py esp32 -clean BOARD=ESP32_GENERIC BOARD_VARIANT=SPIRAM LVFLAGS="LV_COLOR_DEPTH=16"
you want to use the command above.
broken link on your repo…
not able to…
@SL2021-Dev ➜ /workspaces/v2-lvupy-1.21/lv_binding_micropython (MicroPython_1.21.0_Update) $ git submodule update --init --recursive
Submodule 'lvgl' (https://github.com/lvgl/lvgl.git) registered for path 'lvgl'
Submodule 'micropython' (https://github.com/micropython/micropython.git) registered for path 'micropython'
Submodule 'pycparser' (https://github.com/eliben/pycparser.git) registered for path 'pycparser'
Cloning into '/workspaces/v2-lvupy-1.21/lv_binding_micropython/lvgl'...
Cloning into '/workspaces/v2-lvupy-1.21/lv_binding_micropython/micropython'...
Cloning into '/workspaces/v2-lvupy-1.21/lv_binding_micropython/pycparser'...
fatal: remote error: upload-pack: not our ref 6e64a912fa9e777d46cc66b0da68fa31f56d5680
fatal: Fetched in submodule path 'lvgl', but it did not contain 6e64a912fa9e777d46cc66b0da68fa31f56d5680. Direct fetching of that commit failed.
Just got my S3’s in. So I can do some actual testing now. I have an I8080 display and an SPI display kicking about. I have to put work on this on hold for a day or 2. I have another task that needs my attention.
Hello everyone!
I had an error: BYTE ARRAY TYPECODE is not defined. Added #include “py/binary.h” to rgb_bus.c. Build was successful
HA! I had made that change already and forgot to commit it. sorry about that !
@kdschlosser Importing lvgl and i80bus tires goes without errors. I have a wt32 sc-01 plus device. Is there a display driver for integration with lvgl? Are there any examples of how to do this?
You would be best to ask @bdbarnett how to get that display running. There were some tweaks he had to make to the ST7796 driver to get it to work, something about the reset pin for the display being tied to the touch panel reset pin. Color inversion also had to be set to get it to display properly.
We have been hammering away at testing the bus drivers without LVGL involved. I am not sure if it will work with LVGL just yet still working that part out.
Which reminds me, there is something I wanted to change so a user doesn’t have to worry about setting it. I also have to fix something in the memory allocation portion as well.
Gonna go to bed tho. I am beat.
I don’t understand. Already broke my head. When initializing, lv.init() crashes and is disconnected from the com port. The try except handler does not show an error. Build Micropython_1.21.0_Update
This is more than likely a problem with the garbage collection. I will have to dig into what could be causing it. That is an area I have not dug deep into so I am not all that clear on how it actually works. I just finally got my ESP32-S3’s in and got the firmware to recognize the SPIRAM and the SPIFLASH properly it’s the new 8MB Octal SPIRAM with 32mb of octal SPIFLASH. there is no board built into MicroPython that I could use so I had to code up a way to create a custom board from the command line.
I did make some changes to the memory allocation so if the buffer does not get allocated None
will get returned. The user can then check if the buffer is None and act as needed in Python code. I thought it best to do that instead of raising an exception that would need to get caught. Exception catching in Python is expensive so if there is a way to not have to do that I rather go that route, which is what I have done.
I also removed having to pass the buffer size to the bus classes. This is handled internally by the driver when the init
function of the bus driver gets called. This also makes it easier when using the RGBBus. The RGBBus is not actually a bus it is a display driver that is written in C code. It is apart of the IDF and it’s API is completely different than the other bus drivers. The RGBBus handles making the frame buffers internally so the buffers need to get collected instead of being passed to it. this is all optionally handled internally in the display driver so the user doesn’t have to collect the buffers in order to pass them to the display driver.
I have spent the last 8 hours or so combing over the gen_mpy.py script to try and make heads or tails of what is going on in it. I discovered a MAJOR flaw in the code when I was doing this. This flaw is going to have to be corrected for previous releases of the binding as well as the update I am working on.
@kdschlosser
Fine. Today I’ll try to play with the parameters:
–spiram=[0, 2, 4, 8, 16, 32, 64, 128]: amount of SPIRAM
–spiflash=[2, 4, 8, 16, 32, 64, 128]: number of SPIFLASH setsCONFIG_ESPTOOLPY_FLASHSIZE_*
–spiram-freq=[0, 40, 80, 120]: setsCONFIG_SPIRAM_SPEED_*
I will set them according to N16R2. 16 - flash and 2 - SPAIRAM