Enable lv_binding_micropython as USER_C_MODULE

[Carglglz]

This is an updated version of #242 which allows to build lv_binding_micropython as a USER_C_MODULE with latest upstream MicroPython.

Tested on :

• unix port (linux, macOS)
• esp32
• stm32 (PYBV1.1)

This also adds tests that can be run with MicroPython test suite in both desktop (unix port) and devices.

$ ./run-tests.py ../../user_modules/lv_binding_micropython/tests/api/basic.py
pass  ../../user_modules/lv_binding_micropython/tests/api/basic.py
1 tests performed (34 individual testcases)
1 tests passed

These tests are :

• api: MicroPython-LVGL API (display/touch simulated)
• display: Display driver integration (touch simulated)
• indev: Touch driver integration (requires user input)

For devices display/touch driver is not included, see more information at tests/README.md

[PGNetHun]

Thank you, I will test it, too!

[Carglglz]

@MathyV I've just updated the tests, you should be able to run tests/display with your driver (I've already tested it and it works but I have no physical display to get visual feedback )

[kdschlosser]

I am confused as to the purpose of this PR. The purpose of a user c module should be to keep the binding code self contained where modifications to the micropython build system would not need to be made to get it to compile.

[Carglglz]

The purpose of a user c module should be to keep the binding code self contained where modifications to the micropython build system would not need to be made to get it to compile.

Which it is exactly this, the tests are not necessary just convenient, if necessary I can split this PR.

where modifications to the micropython build system would not need to be made to get it to compile.

I am confused too, where do you see these modifications? 👀

[kdschlosser]

There is no PR in https://github.com/lvgl/lv_micropython that removes all of the code that has been added to the build system to compile LVGL into micropython. I am making an assumption about that repo still being used because I am not seeing any kind of a connection between this repo and micropython anywhere that would indicate something different.

I am also failing to see how this is able to be compiled as a user c module as there is no micropython.cmake or micropython.mk which is what is used to compile it as a user_c_module. The cmake file is not as important but the makfile must be named as micropython.mk in order for the micropython build system to locate it due to a directory and not a file needing to be provided in a make build.

[kdschlosser]

I am trying to figure out how I would use this as a user_c_module. What to I point micropython to?

[Carglglz]

There is no PR in https://github.com/lvgl/lv_micropython that removes all of the code that has been added to the build system to compile LVGL into micropython. I am making an assumption about that repo still being used because I am not seeing any kind of a connection between this repo and micropython anywhere that would indicate something different.

No, this is independent of lv_micropython, with this PR anyone can build lv_binding_micropython as a USER_C_MODULE from upstream MicroPython.

I am also failing to see how this is able to be compiled as a user c module as there is no micropython.cmake or micropython.mk which is what is used to compile it as a user_c_module

Not sure where you are looking at 😕 they are here

I am trying to figure out how I would use this as a user_c_module. What to I point micropython to?

Just create a directory next to MicroPython repo e.g. named user_modules, then clone lv_binding_micropython inside.

To compile unix port just do

micropython/ports/unix$ : make USER_C_MODULES=../../../user_modules

In my case I compile my own unix variant for convenience (not necessary)

 make VARIANT_DIR=$MY_VARIANTS/UNIX_DEV -j4

UNIX_DEV is just a copy of variants/standard but with:

this added to manifest.py

include("$(MPY_DIR)/../user_modules/lv_binding_micropython/ports/unix")

this added to mpconfigvariant.h

// Required for LVGL
#define MICROPY_ENABLE_SCHEDULER       (1)
#define MICROPY_MODULE_BUILTIN_INIT    (1)
#define MICROPY_PY_SYS_SETTRACE        (0)

And this added to mpconfigvariant.mk

FROZEN_MANIFEST ?= $(VARIANT_DIR)/manifest.py
USER_C_MODULES ?= ../../../user_modules

In any case lv_micropython could be updated to add custom variants but again I don't think it is necessary.

[kdschlosser]

OK so say I clone this repo in my IDE's project folder. Then I clone micropython 1.23 into the binding cloned folder. To build it I would have to use the following command to build

make -c micropython/ports/unix USER_C_MODULES="../../../../"

When I do that make is going to search every single one of my other projects in a recursive manner and look for micropython.mk files. It is going to also do this for the directory the binding repo has been cloned into and if it finds any micropython.mk files anywhere it is going to compile those as user c modules as well.

If this PR is accepted when the lv_micropython repo gets updated I am guessing it is going to break due to the gen_mpy script being altered to work with micropython 1.23.

How were you able to handle the build with the ESP32s driver reliance on the esp-idf and that version needing to be 4.4 where as micropython 1.23 uses 5.1.x or 5.2.x I don't remember which. Support for 4.4 was removed in micropyton 1.21 I believe, it may have been 1.20...

compiling LVGL as a user c module was never the issue, it was compiling the rest of the things that go along with it. How dows one go about setting up the display drivers?

I am thinking that you may have missed this...

https://github.com/lvgl/lv_binding_micropython/tree/65d882d1c9958c4842d577741c7e70556282576f/driver/esp32

everything in the drivers folder also needs to be handled as well. The .py files need to be frozen into the firmware and I am not seeing where that is done.

[Carglglz]

OK so say I clone this repo in my IDE's project folder. Then I clone micropython 1.23 into the binding cloned folder. To build it I would have to use the following command to build
make -c micropython/ports/unix USER_C_MODULES="../../../../"
When I do that make is going to search every single one of my other projects in a recursive manner and look for micropython.mk files. It is going to also do this for the directory the binding repo has been cloned into and if it finds any micropython.mk files anywhere it is going to compile those as user c modules as well.

No this is what I meant

my_ide_project: $ tree
.
├── micropython 
 ...
└──  user_modules
       └── lv_binding_micropython 

If this PR is accepted when the lv_micropython repo gets updated I am guessing it is going to break due to the gen_mpy script being altered to work with micropython 1.23.

The check passed which seems to build lv_micropython with the contents of this PR

the gen_mpy script being altered to work with micropython 1.23

Again those changes should be backwards compatible as the check confirms...

compiling LVGL as a user c module was never the issue, it was compiling the rest of the things that go along with it.

Yes it was, bindings.cmake only works with rp2 port

How dows one go about setting up the display drivers?

The display drivers are a nice thing to have but not necessary to build lvgl as a USER_C_MODULE, i.e. pure MicroPython drivers could be added to the manifest file of a board, or C based ones as an independent USER_C_MODULE in a cmake file, e.g.

include(${CMAKE_CURRENT_LIST_DIR}/lv_binding_micropython/micropython.cmake)
include(${CMAKE_CURRENT_LIST_DIR}/lvgl_esp32_mpy_drivers/micropython.cmake)

How were you able to handle the build with the ESP32s driver reliance on the esp-idf and that version needing to be 4.4 where as micropython 1.23 uses 5.1.x or 5.2.x I don't remember which. Support for 4.4 was removed in micropyton 1.21 I believe, it may have been 1.20...

I am thinking that you may have missed this...

https://github.com/lvgl/lv_binding_micropython/tree/65d882d1c9958c4842d577741c7e70556282576f/driver/esp32

everything in the drivers folder also needs to be handled as well. The .py files need to be frozen into the firmware and I am not seeing where that is done.

I'm aware of this, see my comments #242 (comment) and
#242 (comment)

[chieve-bale]

is there possible to create new repositories under lvgl org. lv_micropython is real confuseing with micropython version and idf version. there is saying in README.md lv_micropython as a example to show how to bind lv_binding_micropython,but when i try to figure out how to bind as a submodule under official micropython repo, it is real not friendly and easy to achieve.
so for freshman like me, make lv_bind_micropython as a independent user c module is real esay to achieve. there is a good example repo in my consideration:
https://github.com/devbis/st7789_mpy.git
or
https://github.com/russhughes/st7789_mpy.git
i know this may let lv_micropython work error, so i advise to create new repo。it may let the code maintenance more easy( i guess)
for .py driver or others just write into manifest.py and be include in project manifest.py

sorry about my terrible english explanation, it is not my first language.

[TheBestJohn]

Just popping in to say this is great work. I just got this successfully running on a LILYGO T_Display using the latest Micropython.
I copied the utils and Stdriver to my freeze directory and I had to modify my partition file as it seems to make the micropython.bin quite a bit beefier.

I haven't done too much with it yet as I'm still learning the ropes of this library but I did get me a press me button on a display with no touch inputs. There was some initial issues with the uasyncio stuff but I haven't looked too closely into that as it may be an error I made with the partitions.

EDIT: The crashing seems to happen when I re-upload my script. Not sure the proper teardown of lvgl yet but it doesn't seem to be due to this C modulization but instead something to do with the co-processor or something

[Carglglz]

@TheBestJohn
Thanks for testing this!!

EDIT: The crashing seems to happen when I re-upload my script. Not sure the proper teardown of lvgl yet but it doesn't seem to be due to this C modulization but instead something to do with the co-processor or something

This may be related to #343 , not sure how are you uploading the script (probably there is a soft reset involved?) but you need to do a hard reset or call lvgl.deinit() before the soft reset (at least for the LVGL side). Respect to the driver yo may need to deinit SPI too (although this may not work see again #343, but that would be on the MicroPython side)

The are some tests that you may want to run with

$  ./run-tests.py ../../user_modules/lv_binding_micropython/tests/api/*.py --target esp32 --device /dev/tty.<ID>

haven't done too much with it yet as I'm still learning the ropes of this library but I did get me a press me button on a display with no touch inputs.

For touch inputs you need to register an "input device" have a look at testdisplay.py and indev docs. Then lvgl.task_handler() needs to be called to be able to process events, see lib/lv_utils.py, which can be done using a timer or as an asyncio task, i.e the asyncio event loop must be running.