search

lvgl / lv_binding_micropython

LVGL binding for MicroPython
MIT License
237 stars 156 forks source link

Enable lv_binding_micropython as USER_C_MODULE #341

Open Carglglz opened 1 month ago

Carglglz commented 1 month ago

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 :

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 :

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

PGNetHun commented 1 month ago

Thank you, I will test it, too!

Carglglz commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Carglglz commented 1 month ago

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

Screenshot-PR-341

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 commented 1 month ago

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 commented 1 month ago

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 https://github.com/lvgl/lv_binding_micropython/pull/242#issuecomment-2087739448 and https://github.com/lvgl/lv_binding_micropython/pull/242#issuecomment-2103572023