Hi @fstengel!
Micropython does not support every esp-idf version.
It supports only specific versions, as specified in the Makefile.
Micropython requires changes and fixes in order to work with different versions of esp-idf.
There is some discussion over this on Micropython GitHub:
Regarding lv_micropython, which is a fork of Micropython -
I try to align it to major Micropython releases (latest is v1.12), so lv_micorpython is compatible with esp-idf versions supported by Micropython v1.12.
Hi @amirgon
First of all thank you for the extensive work produced in making lgvl and micropython work together.
I am fully aware that only specific versions of the esp idf work when compiling any version of micropython. That is why I asked the quesiton. My methodology for testing is:
readme.md.readme.md found in the root of the project and the one found in ports/esp32. I pay a particular attention to the esp-idf hash.mpy-cross, then micropython.I did this for (micropython/master, idf 4 hash 463a9d8), (lv_micropyton, idf 3 hash 6ccb4cf), (lv_micropython, idf 4 hash 310beae). The first two work without any problem, the last one fails as shown in the original message. So there must be something weird with the version of the esp idf V4 used, or one has to install something extra to make it work.
This is why I asked whether anybody has been recently able to compile using esp-idf 4 hash 310beae.
As the op of this…my “issue” was in the make file (as I referenced on feb-26)
Using…
git checkout 310beae373446ceb9a4ad9b36b5428d7fdf2705f
.
I saw a xtensa path error in my build, so I did this first…
changed all path occurrences of xtensa to xtensa-debug-module in the Make fie.
Then I also applied this fix…
The path change and flipping the order of the includes where both done at the same time.
If you see a xtensa path error… just change the path first and test.
And if that does not get you thru, then try apply the flipping the order of the includes change.
I hope this helps!
It took me days to get this to work and have no idea why these changes were necessary.
I was just following the the basic build instructions as insidious as they are.
I am no git expert… but are updates in micropython automatically reflected in lv_micropython ??
@GC-RmG wrote :
And I could compile. So the issue was with that switch. I would never have found it by myself. Basically, I applied the patch and everything went well. I stll need to try the build firmware to see if everything really works…
Thanks again
I just flashed the resulting firmware on my M5Stack and played a bit with it. It seems to work. Now, if I could just change the version string from 1.9.4-xxx to 1.12-yyy. I think one has to toy around with git tags…
Glad that worked for you !!!
That fix was applied to the master micropython branch.
it appears no maintenance is being performed.
lv_micropython has not appeared to be updated since 1-17-2020 !
I also get on boot…
a) flash read err, 100
b) Chip revision…
c) incorrect version 1.9.4 (1.12 is used)
Do not get the issues with pure micropython builds.
I currently also have have other problems.
Support is almost nonexistent as stated at the beginning of this thread…
Without a huge following, fixes are going to be non-existent unless one is very familiar with the code.
Me personally I might have to look for a commercial package as my project is not for fun.
Good luck.
I also exierience issues b ad c. My boot sequence is not showing issue a.
For issue b : I do not think it is a real problem. It basically tells you that the firmware can run on a revision 0 chip and since yours is revision 1, well it will run. If it bothers you, add the line
CONFIG_ESP32_REV_MIN_1=y
in, say, ports/esp32/boards/sdkconfig.base. Personnaly, I would create a “personal” board that would be derived from TINYPICO.
For issue c, I think one simply has to change the git tag. I’ll have to check things out.
I guess my question is why do binary’s from micropython, not exhibit these outputs?
My project is using an ESP32 Wrover now, things could change later.
The answer is simple : different esp-idf version. In an older version one had the warning you see. In newer versions, the warning becomes an info:
I (xxxx) This chip is revision 1 but project was configured for minimum revision 0. Suggest setting project minimum revision to 1 if safe to do so.
And this info is only shown if the log verbosity is sufficient. One can set it using esp.osdebug:
import esp
esp.osdebug("*", esp.LOG_INFO)
osdebug's first argument is ignored unless it is None, in which case the verbosity is set to LOG_ERROR
No, but in most cases, we can semi-automatically update lv_micropython by running a single command.
As @amirgon mentioned…
The last major release of Micropython was in December 2019. As such, the latest merge with MicroPython occured on Jan 17th.
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.
GETTING ERROR…
rich@RG-x360:/mnt/c/tpi-dev/lvgl/lv_micropython$ git merge micropython/master
*** Please tell me who you are.
Run
git config --global user.email "you@example.com"
git config --global user.name “Your Name”
to set your account’s default identity.
Omit --global to set the identity only in this repository.
Follow it’s instructions. This must be the first time you’ve tried to commit on this machine.
You need to open these files (VSCode is a good editor to use for this) and resolve the merge conflicts. Essentially, git couldn’t figure out how to apply some of the new changes on top of the underlying code.
Once you’re done that, you can run git status on the command line. It will list the “unmerged paths”; you should add these to the commit with git add <file paths>. Then you can run git commit to actually do the merge.
If you’d prefer, I can do this for you and leave the result on a branch of lv_micropython.
I really appreciate your help !!!
You’ve probably read my RANTS and now you know why.
Before I waste too much of your valuable time I should learn how to fix these errors on my own.
I am using VSC…
What am I resolving exactly??
Here’s a good tutorial:
It looks like you merged it successfully. See if you can compile MicroPython; sometimes git complains about lib/lv_bindings but the build works without problems. If it doesn’t work I can give you the steps to fix lib/lv_bindings.
MAKE STOPPED HERE… any ideas
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$ Try running git submodule update --recursive in the base lv_micropython directory. Then run the build again.