Building lv_micropython for esp32s3 and RGB display

Hi All,

I purchased a 4.3" LCD board with an esp32s3 chip for the purpose of playing with micropython and having a board that had a variety of input and output options. I’ve struggled for the last couple of weeks trying to get an lv_micropython build.

I can build micropython (@master), I’ve built the esp-idf display demos and deployed those to the board, so I have confidence in my build environment and the hardware.

I’ve tried building lv_micropython on OSX and Linux, I’ve tried building the release/v8 build with the 4.4 esp-idf and the top of tree (@master) build with esp-idf 5.1.2. I’ve had no luck at all. I know that I probably need @kdschlosser 's lv_bindings build for the RGB panel driver, but even just trying to build the esp32 port without anything exotic fails for me. Below I’ve documented the processes I’ve tried (at least the most basic variation of them) and the failures they’ve generated.

My primary goal is to play with micropython on the board, and of course be able to output things to the display, not necessarily become an master in lvgl and lv_micropython… I guess what I’m saying is that if someone could build a firmware binary for me… I’d take it :slight_smile:

Any help would be greatly appreciated.

Regards.
Lance

OS: OSX 11.7.10
Python: 3.8 (so gevent will work)
ESP-IDF: v4.4
lv_micropython: release/v8
Docs: https://github.com/lvgl/lv_micropython/blob/master/ports/esp32/README.md#setting-up-the-toolchain-and-esp-idf

## Start from scratch
% rm -rf esp .espressif
% mkdir esp
% cd esp
## Get v4.4 of esp-idf (lv_micropython and esp32s3 supported)
% git clone -b v4.4 --recursive https://github.com/espressif/esp-idf.git
% cd esp-idf
% git submodule update --init --recursive
% ./install.sh all
% . ./export.sh
## Clone lv_micropython (use release/v8 branch hoping for stability)
% cd .. (to ~/esp)
% git clone -b release/v8 https://github.com/lvgl/lv_micropython.git
# I know I need an RGB LCD driver, which isn't in this release, but just
# trying to get something to compile.
% cd lv_micropython
% git submodule update --init --recursive lib/lv_bindings
% make -C mpy-cross
% cd ports/esp32
% make submodules
% make
FAIL::
[1148/1578] Generating ../../genhdr/qstr.i.last
FAILED: genhdr/qstr.i.last /Users/lance/esp/lv_micropython/ports/esp32/build-GENERIC/genhdr/qstr.i.last
<SNIP>
Lots of redefined warnings.. e.g.:
In file included from /Users/lance/esp/esp-idf/components/esp_hw_support/include/soc/spinlock.h:11,
                 from /Users/lance/esp/esp-idf/components/freertos/port/xtensa/include/freertos/portmacro.h:42,
                 from /Users/lance/esp/esp-idf/components/freertos/include/freertos/portable.h:51,
                 from /Users/lance/esp/esp-idf/components/freertos/include/freertos/FreeRTOS.h:63,
                 from /Users/lance/esp/lv_micropython/ports/esp32/mpconfigport.h:10,
                 from /Users/lance/esp/lv_micropython/py/mpconfig.h:62,
                 from /Users/lance/esp/lv_micropython/py/mpstate.h:31,
                 from /Users/lance/esp/lv_micropython/py/runtime.h:29,
                 from /Users/lance/esp/lv_micropython/py/argcheck.c:30:
/Users/lance/esp/esp-idf/components/soc/esp32s3/include/soc/cpu.h:24: warning: "RSR" redefined
 #define RSR(reg, curval)  asm volatile ("rsr %0, " #reg : "=r" (curval));

Then a python traceback:
Traceback (most recent call last):
  File "/Users/lance/esp/lv_micropython/py/makeqstrdefs.py", line 203, in <module>
    preprocess()
  File "/Users/lance/esp/lv_micropython/py/makeqstrdefs.py", line 73, in preprocess
    for output in p.imap(pp(flags), chunks):
  File "/usr/local/Cellar/python@3.8/3.8.18_1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 868, in next
    raise value
  File "/usr/local/Cellar/python@3.8/3.8.18_1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
  File "/Users/lance/esp/lv_micropython/py/makeqstrdefs.py", line 57, in run
    return subprocess.check_output(args.pp + flags + files)
  File "/usr/local/Cellar/python@3.8/3.8.18_1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 415, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/local/Cellar/python@3.8/3.8.18_1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/Users/lance/.espressif/tools/xtensa-esp32s3-elf/esp-2021r2-8.4.0/xtensa-esp32s3-elf/bin/xtensa-esp32s3-elf-gcc'
<SNIP>
returned non-zero exit status 1.
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
make: *** [all] Error 2

#####################################

OS: Debian 12 (bookworm)
Python: 3.11.2
ESP-IDF: 5.1.2 (latest per docs)
lv_micropython: master branch

## Start from scratch
% rm -rf esp .espressif
% mkdir esp
% cd esp
% git clone -b v5.1.2 --recursive https://github.com/espressif/esp-idf.git
% cd esp-idf
% ./install.sh all
% . ./export.sh
% cd .. (to ~esp)
% git clone https://github.com/lvgl/lv_micropython.git
% cd lv_micropython
% git submodule update --init --recursive lib/lv_bindings
% make -C mpy-cross
% cd ports/esp32
% make submodules
% make
FAILED:

[1/1] idf (5.1.2)
CMake Error at /home/pi/esp/esp-idf/tools/cmake/build.cmake:266 (message):
  Failed to resolve component 'esp_adc_cal'.
Call Stack (most recent call first):
  /home/pi/esp/esp-idf/tools/cmake/build.cmake:302 (__build_resolve_and_add_req)
  /home/pi/esp/esp-idf/tools/cmake/build.cmake:303 (__build_expand_requirements)
  /home/pi/esp/esp-idf/tools/cmake/build.cmake:595 (__build_expand_requirements)
  /home/pi/esp/esp-idf/tools/cmake/project.cmake:547 (idf_build_process)
  CMakeLists.txt:67 (project)

Hi @ronnocol. I apologize for not answering your question in the other thread. You’ve probably seen there has been a lot of discussion about the MicroPython bindings for LVGL over the last 6 months to a year, especially regarding ESP32. I’ll give you a (not so) brief synopsis.

The bindings were written with drivers for ESP32 built-in, and those drivers were written for ESP-IDF 4.x. Some of the touchscreen drivers referenced ADC_CAL, which is implemented in the ESP-IDF differently for ESP32-S3, so the bindings would error out when compiling for ESP32-S3 targets. The maintainer of the bindings stepped down last summer, so they have been in an unusable state for ESP32-S3 since then. In the meantime, base MicroPython moved to using the ESP-IDF 5.x further compounding the problem of compiling for ESP32 targets. @kdschlosser has been working on making the bindings compile as a USER_C_MODULE and writing new hardware drivers for both ESP32 and non-ESP32 targets. He is doing this work as a community member, not the official maintainer of the bindings. Recently, there has been activity on the bindings that don’t involve the work he has put in. He pulled his fork to work through some things in the meantime.

As of right now, the official bindings (branch master) won’t compile for ESP32 targets and @kdschlosser’s bindings aren’t accessible, so, unless you already have @kdschlosser’s bindings downloaded, your only recourse is to wait for someone to release binding that will compile. I have written drivers in MicroPython that work, but they require the binding to compile. I know what to remove from the bindings so they don’t depend on any ESP-IDF and will compile, but that is a hack that I really don’t want to publicize. Instead, I think we just have to wait. I’m confident we’ll have something usable very soon, but I’m not in collaboration with anyone making the decisions, so I can’t say how soon.

I read that you recently had surgery and are looking to work with LV_MicroPython to pass the time. I hope you are healing well. If you can, I suggest you get an RP2040 board to get started while waiting for the ESP32 work to be released. The RP2040 doesn’t have a lot of memory like the ESP32, so make sure to get a lower resolution display, no bigger than 320x240. I use the RP2040 with an ILI9341 and GC9A01 (240x240 round) and it works fine. If you’re just getting started in electronics, it will be easier for you if you find an all-in-one display with RP2040 built in OR buy something that just plugs in, like an Adafruit or QT Py. Before you spend money on the RP2040, download the master branch of lv_micropython and make sure you can get RP2040 to build. It’s A LOT simpler than ESP32. For that matter, make sure you can get the Unix (linux) target to build and then just run MicroPython on your computer while you’re at it. You can use my drivers for RP2040, but you won’t need any drivers at all for Linux.

Short version: there’s work being done to make the bindings work for ESP32, but as of today, if you are just getting started, you’re better off with a different board. My preference is the RP2040, but other people may have different suggestions for you.

@bdbarnett,

Thank you so much for the thorough and thoughtful reply. Being new to this type of computing, I had no idea that there was such a different level of support for displays, not just by type of display, but by chip, etc. I only went with the ESP32 series, because that’s what a buddy of mine mentioned when he first told me about micropython, and then I found this “all-in-one” board that had an easy plug to play with different sensors, built in screen, and I thought it would be a “easy” platform to play with during recovery (I had a heart bypass, things are going well, things for asking… but breadboards aren’t the easiest thing to play with right now.)

I absolutely should have done more research in this area of electronics/computing, but just took for granted that “things should work” coming from a world of either graphics cards just work, or the computer is in the cloud, and all you get is an ssh console anyway. So I appreciate you catching me up on the state of MCUs and displays. I’ll take a look at RP2040 based products, I have every other version of Raspberry Pi, so a bit of surprise I didn’t go there first I suppose :slight_smile:

I’m not going to give up on this WaveShare board, but will perhaps let it sit on the shelf for a bit, and moving the bindings to a USER_C_MODULE sounds amazing. I have created a few and contributed to a few open source projects so completely understand involvement as a community member and also know how frustrating it can be to be chasing upstream requirements. I appreciate your entire communities great works, and hope that at some point I can contribute even in some small fashion.

Once again, I appreciate your response, I do apologize for hijacking your display drivers thread. I’m looking forward to one day getting graphics on a screen controlled by a MCU.

Best Regards.