I also agree
I was able to build an ESP32 firmware by:
- casting
(mp_rom_error_text_t)
whenever I got the error with the incompatible pointer cast - as hinted, changing
mp_instance_cast_to_native_base
intomp_obj_cast_to_native_base
whenever the problem appeared.
This being said, I have not tried that firmware. I’ll dot that momentarily and I’ll keep the forum posted.
I have not tested the firmware extensively. I basically ran a very short test interface using lvgl. It looks as if it works. Fingers crossed …
I am not at all familiar casting or the C language.
Could you show in more detail your method(s).
It would be immensely appreciated !!!
My workflow was very basic:
- 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 inlib/lv_bindings/driver/generic/modlvindev.c
I 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 ofports/esp32/build-GENERIC_SPIRAM/lvgl/lv_mpy
. In that file I changed line 98 from
return mp_instance_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));
to:
return mp_obj_cast_to_native_base(mp_obj, MP_OBJ_FROM_PTR(native_type));
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
…)
Man aren’t you the ambitions one !!
50-ish?
Can we expect an update any time soon ??
Is this a one-time thing or on every build?
p.s. where is this error log?
@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.
fstengel… your the man !!
I started by forking lv_micropython (https://github.com/fstengel/lv_micropython), followign the usual method (git clone-recurse-submodules xxx etc.) and then followed what is exposed in the post linked below
https://forum.lvgl.io/t/esp32-micropython-build-errors-lots/1754/22?u=fstengel
If you’d like to update
lv_micropython
manually, you should be able to clone it and then run the following commands:git remote add micropython https://github.com/micropython/micropython.git git fetch micropython git merge micropython/master
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 formp_instance_cast_to_native_base
and replace it withmp_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.
is this correct…
gen_mpy.py 7 locations
modlvindev.c 1 location
modILI9341.c 2 locations
modrtch.c 1 location
modxpt2046.c 2 locations
Ouch, no. Sorry for my lack of clarity. Your lines 549-550 should look like this:
mp_obj_new_exception_msg_varg(
&mp_type_SyntaxError, (mp_rom_error_text_t) "Can't convert %s to %s!", mp_obj_get_type_str(mp_obj), qstr_str(mp_type->name)));
What this does is forcing the string to become an object of type mp_rom_error_text_t
…
And you have to repeat it for the 13 locations you found. Basically insert the (mp_rom_error_text_t)
just before the "
of the string…
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…
THANK YOU VERY MUCH " fstengel" !!!
I feel much better that I am using the most recent release!
Is there any way that the correct version is displayed?
again thank you !
Weird. My boot sequence shows:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5068
load:0x40078000,len:14024
load:0x40080400,len:3760
entry 0x40080638
MicroPython v1.12-635-g269836295-dirty on 2020-04-12; ESP32 module (spiram) with ESP32
Type "help()" for more information.
>>> help("modules")
__main__ gc uasyncio/core uos
_boot ili9341 uasyncio/event upip
_onewire inisetup uasyncio/funcs upip_utarfile
_thread lodepng uasyncio/lock urandom
_uasyncio lvesp32 uasyncio/stream ure
_webrepl lvgl ubinascii uselect
apa106 machine ubluetooth usocket
btree math ucollections ussl
builtins micropython ucryptolib ustruct
cmath neopixel uctypes utime
dht network uerrno utimeq
ds18x20 ntptime uftpd uwebsocket
esp onewire uhashlib uzlib
esp32 rtch uhashlib webrepl
espidf sys uheapq webrepl_setup
flashbdev uarray uio websocket_helper
framebuf uasyncio/__init__ ujson xpt2046
Plus any modules on the filesystem
Notice the two differences: the version and the size of the second segment. My board (a M5Stack) does not show the flash read error either.
Just for reference I am using a
WEMOS LOLIN D32 Pro V2.0.0 ESP32 wrover
I downloaded your repo, made the changes, flashed…
and this is what I got
How can my binary be different than yours?
Also why -dirty why not -lvgl or somthig
more info…
sys.platform:
esp32
sys.version:
3.4.0
sys.implementation:
(name='micropython', version=(1, 12, 0), mpy=10757)
Sigh. My git-fu is really not up to standard Basically, the tag that builds the version message (v1.12 vs v.1.9.4) did not go through. Go figure. As far as I can tell, the -dirty
suffix comes from the fact that this is several commits since the last release. You get that also in official downloads.
Thank you you’ve been extremely helpful and informative.