Build for ESP32 BOARD=GENERIC_SPIRAM
Merged latest mircopython
Using hash (v4.0) (experimental): 463a9d8b7f9af8205222b80707f9bdbba7c530e1
Build stops here…
CC ../../lib/lv_bindings/driver/generic/modlvindev.c
In file included from ../../lib/lv_bindings/driver/generic/../include/common.h:4,
from ../../lib/lv_bindings/driver/generic/modlvindev.c:5:
../../lib/lv_bindings/driver/generic/modlvindev.c: In function 'indev_read':
../../lib/lv_bindings/driver/generic/modlvindev.c:131:40: error: passing argument 2 of 'mp_obj_new_exception_msg' from incompatible pointer type [-Werror=incompatible-pointer-types]
&mp_type_RuntimeError, "indev instance needs to be created before callback is called!"));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../py/obj.h:275:35: note: in definition of macro 'MP_OBJ_TO_PTR'
#define MP_OBJ_TO_PTR(o) ((void *)o)
^
../../lib/lv_bindings/driver/generic/modlvindev.c:129:37: note: in expansion of macro 'nlr_raise'
if (!self || (!self->callback)) nlr_raise(
^~~~~~~~~
In file included from ../../lib/lv_bindings/driver/generic/../include/common.h:4,
from ../../lib/lv_bindings/driver/generic/modlvindev.c:5:
../../py/obj.h:734:86: note: expected 'mp_rom_error_text_t' {aka 'struct <anonymous> *'} but argument is of type 'char *'
mp_obj_t mp_obj_new_exception_msg(const mp_obj_type_t *exc_type, mp_rom_error_text_t msg);
~~~~~~~~~~~~~~~~~~~~^~~
cc1: all warnings being treated as errors
../../py/mkrules.mk:64: recipe for target 'build-GENERIC_SPIRAM/lib/lv_bindings/driver/generic/modlvindev.o' failed
make: *** [build-GENERIC_SPIRAM/lib/lv_bindings/driver/generic/modlvindev.o] Error 1
make: Leaving directory '/mnt/c/tpi-dev/lvgl/lv_micropython/ports/esp32'
(bld-lvgl) rich@RG-x360:/mnt/c/tpi-dev/lvgl/lv_micropython$
VSC shows… expected an expression in modlvindev.c file
I tried to sort this out by explicitely adding a cast (mp_rom_error_text_t)to line 131 in modlvindev.c. But that only solves one problem. The next series is in build-GENERIC_SPIRAM/lvgl/lv_mpy.c (where does that file come from ?) Amongst others, one has:
build-GENERIC_SPIRAM/lvgl/lv_mpy.c: In function 'get_native_obj':
build-GENERIC_SPIRAM/lvgl/lv_mpy.c:98:12: error: implicit declaration of function 'mp_instance_cast_to_native_base'; did you mean 'mp_obj_cast_to_native_base'? [-Werror=implicit-function-declaration]
return mp_instance_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mp_obj_cast_to_native_base
build-GENERIC_SPIRAM/lvgl/lv_mpy.c:98:12: error: returning 'int' from a function with return type 'mp_obj_t' {aka 'void *'} makes pointer from integer without a cast [-Werror=int-conversion]
return mp_instance_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Both errors make me think that some things changed internally in py/* and that there are incompatibilities between the lvgl bindings and the current micropython/master branch…
I ran make LV_CFLAGS="-DLV_COLOR_DEPTH=16 -DLV_COLOR_16_SWAP=1" BOARD=GENERIC_SPIRAM
I looked at the error log and performed the alterations.
Went back to point 1 until there were no more errors…
What alterations did I perform?
For the error: passing argument 2 of 'mp_obj_new_exception_msg'... error I did as follows. For instance in lib/lv_bindings/driver/generic/modlvindev.cI changed line 131 from:
&mp_type_RuntimeError, "indev instance needs to be created before callback is called!"));
to
&mp_type_RuntimeError, (mp_rom_error_text_t) "indev instance needs to be created before callback is called!"));
For the error error: implicit declaration of function 'mp_instance_cast_to_native_base', I changed ‘mp_instance_cast_to_native_base’ to ‘mp_obj_cast_to_native_base’ as in line 98 of ports/esp32/build-GENERIC_SPIRAM/lvgl/lv_mpy. In that file I changed line 98 from
I do not remember how many modifications I made, but there were a lot (50-ish? in about half a dozen files, some of them generated: those in build-GENERIC_SPIRAM…)
@fstengel - lv_mpy.c is a generated file.
If you don’t want to change it on every build, better change gen_mpy.py which contains the templates from which lv_mpy.c is generated.
Yes, I just discovered that. “only” 8 thingies that need to be changed. Being a noob with git, I’m not quite sure on howto submit a patch/diff to cover the modifications. However lv_mpy is not the only file that needs to be patched. Some seem to be generated (mp_lodepng.c for instance), but I also had to patch at least: modrtch.c, modILI9341.c, modlvindev.c and modxpt2046.c. What’s weird is that those are all drivers.
Since lv_micropython is aligned to official releases of Micropython, it does not make sense to accept patches on the mainline that are not aligned with the supported Micropython release.
But we can probably accept it on a branch, for people who want a more up to date Micropython/esp-idf.
Fair enough. What I could do is describe what I did in order to be able to build lv_micropython with the latest of micropython/master which is quite a few commits ahead of the version found in the lv_micropython github repo.
It’s quite possible you’ll have to resolve some merge conflicts but that will give you all of the latest changes in Micropython.
I modified the offending files and pushed the whole lot to my repo. You can start with this repo. But your work is not finished.
Now, there are 5 files that are part of the lv_bindings submodule. I can modify them, but I do not know how to push them (and I dare not messing up the lv_bindings repo…) the files are (the root is lv_bindings):
gen/gen_mpy.py
driver/generic/modlvindev.c
driver/esp32/modILI9341.c
driver/esp32/modrtch.c
driver/esp32/modxpt2046.c
In those files I had to:
search for mp_obj_new_exception_msg (there are two variations) and place a (mp_rom_error_text_t) before the string that appears as a second argument
in gen_mpy.py search for mp_instance_cast_to_native_base and replace it with mp_obj_cast_to_native_base.
As far as I can tell that is all I had to do in order to be able to compile lvgl with micropython/master and esp-idf V4.
If somebody proficient in git could give me a way of pushing the modifications I did in the lv_bindings submodule, without messing up the original, that would help a lot…
…
