What MCU/Processor/Board and compiler are you using?
ESP32-WROOM-32
What do you want to achieve?
Compile the MicroPython bin with LittlevGL.
What have you tried so far?
I have cloned the lv_micropython project and the ESP_IDF.
I have successfully programmed my ESP32 with the ESP_IDF, although I’d like to try using micropython.
I have successfully put the standard micropython binary on the ESP32, although it doesn’t come with a graphics library.
Code to reproduce
In the lv_micropython folder:
cd ports/esp32
make
complains of having the wrong commit of the IDF checked out.
However, the IDF repository doesn’t seem to contain the desired commit.
Screenshot and/or video
Errors in ESP_IDF:
git checkout 6b3d
fatal: Cannot switch branch to a non-commit '6b3d'
Errors in lv_micropython:
make
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
** WARNING **
The git hash of ESP IDF does not match the supported version
The build may complete and the firmware may work but it is not guaranteed
ESP IDF path: /home/marshal/esp/esp-mdf/esp-idf
Current git hash: 3bb7dba9957ee71a236058322ae5e70f96f9a104
Supported git hash: 6b3da6b1882f3b72e904cc90be67e9c4e3f369a9
find: ‘/home/marshal/esp/esp-mdf/esp-idf/components/json/include’: No such file or directory
find: ‘/home/marshal/esp/esp-mdf/esp-idf/components/json/port/include’: No such file or directory
find: ‘/home/marshal/esp/esp-mdf/esp-idf/components/xtensa-debug-module/include’: No such file or directory
CC /home/marshal/esp/esp-mdf/esp-idf/components/bootloader_support/src/bootloader_clock.c
/home/marshal/esp/esp-mdf/esp-idf/components/bootloader_support/src/bootloader_clock.c:14:28: fatal error: esp32/rom/uart.h: No such file or directory
compilation terminated.
make: *** [Makefile:663: build/bootloader//home/marshal/esp/esp-mdf/esp-idf/components/bootloader_support/src/bootloader_clock.o] Error 1
You need to checkout the commit id 6b3da6b1882f3b72e904cc90be67e9c4e3f369a9 (that roughly matches the v3.3-beta3).
After you do the checkout of that commit id, remember to run the git submodule update --init -recursive (you may need to delete some folders to get rid of other checked out submodules, git will report the failures and in case you will need to sort them out).
Because the ESP-IDF version used is a bit old as well as micropython, if you decide to go down the road of cloning the official micropython repo and add lvgl and not using the lv_micropython repo, a few hints:
clone the last stable version, not the master (last stable is 1.11)
make the app partition in ports/esp32/partitions.csv bigger, with LVGL you will easily hit the limit (you can’t do OTA anyway because of the size with micropython)
to let micropython write into the app partition you need to set a few variables in the sdkconfig board
CONFIG_PARTITION_TABLE_CUSTOM_APP_BIN_OFFSET=0x10000
CONFIG_APP_OFFSET=0x10000
CONFIG_WL_SECTOR_SIZE_4096=y
CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ALLOWED=y
CONFIG_SPI_FLASH_WRITING_DANGEROUS_REGIONS_ABORTS=
(I have a few additional ones)
take a look to the guide to add the support for the lv_bindings but a diff between the 3 main files is the sacred graal, I do like very much the approach taken in the Makefile for the esp32 of lv_micropython so I replicated it as well for the bootloader (even if it gave me a few headaches because the bootloader_init.c has to be excluded when the bootloader_support component is built for the app, for whatever reason is not automatically excluded in the code itself when building without the def BOOTLOADER_BUILD)
the latest version has a few interesting things, you can backport them fairly easily (esp32_partition as is, you need to add a few headers to make it compatible with the micropython version 1.11, a few line-picked diffs to add support for the mdns library and a few additional things)
the master in the micropython repository has a nice thing though, that I didn’t backported, and I think has a fairly speed up on the network operations … it pins all the tasks created on the app core and then for the network operations is uses the non thread safe version of the calls (potentially if you are careful with that approach you can even turn off the GIL)
Yes, that’t the reason for which I said “if you decide to go down the road of cloning the micropython repo and add lvgl” but I should have specified the “official micropython” repo, I will update the post to avoid confusion
Interesting replies.
It turns out that my issue was the IDF was checked out as a submodule of the ESP_MDF.
I didn’t realize a submodule doesn’t contain the whole commit history.
@amirgon thanks for the heads up! Because I didn’t had previous experience with micropython I preferred to use the latest stable branch but indeed there are a few interesting new things in the master.
Adding the binding myself showed the amount of work necessary and the amount of possible problems and I was wondering if there was a way and potentially while a was looking around, I saw that micropython can be built as a library so I was wondering if it’s worth splitting up the two things.
But it would mean having an ad hoc repository for each build that may work in my case (I care currently only about esp32) but you are maintaining 3 different forks that makes the approach more challenging even if it’s very likely that once done, if it works, the code changes to the code would be really minimal.
Micropython provides a way to add an external module (“cmodule”), and we can think of LittlevGL as such external module.
This could allow using LittlevGL with any micropython version very easily.
However, there are a few complications:
The cmodule does not provide a way to allow the external library use the Garbage Collector. LittlevGL is using it extensively.
There are a few changes and fixes in micropython itself which I could not get integrated into upstream, for example this and this
so changes to micropython would be needed anyway, and the motivation for using cmodule is lower.
I see, but having it as module would let you (me or anyone else) easily update micropython.
Maybe there is an hybrid way to do it, one that would require just a very small amount of ad hoc code in the ports for the garbage collector having all the other functionalities in the module.
I will look into cmodule just to figure out what it does offer and what it doesn’t and if the limitation in the garbage collector is architectural or just a missing bit that can be added without changing everything.
I just updated lv_micropython to upstream micropython.
It’s probably possible, but needs some research.
When I have time I might explore this, but it’s not a high priority right now.
Feel free to try and let me know what you find out!
