Building for ESP32

[madwizard-thomas]

Hi,

I'm trying to get lvgl-rs to run on ESP32 (m5stack core2 module to be precise) on a windows host and ran into some issues with cc and bindgen in lvlg-sys. The esp32 environment does not need cross but normally works out of the box with the correct target (xtensa-esp32-elf in my case). Most issues were fixable by specifying the right environment variables. For anyone playing along at home, besides the .\export-esp.ps1 script you will need:

CROSS_COMPILE, CC, AR for cc to pick the right compiler, and C_INCLUDE_PATH for bindgen to find the system headers. In powershell (for my specific version):

$ENV:CROSS_COMPILE="xtensa-esp32-elf"

$ENV:CC="xtensa-esp32-elf-cc"
$ENV:AR="xtensa-esp32-elf-ar"

$ENV:C_INCLUDE_PATH = (@(
 "lib\gcc\xtensa-esp32-elf\8.4.0\include", 
 "lib\gcc\xtensa-esp32-elf\8.4.0\include-fixed",
 "xtensa-esp32-elf\sys-include", 
 "xtensa-esp32-elf\include"
) | % { Join-Path "$HOME\.rustup\toolchains\esp\xtensa-esp32-elf\esp-2021r2-patch5-8_4_0\xtensa-esp32-elf\" $_ }) -join ";"

However bindgen cc still had an issue that env vars could not solve. Because the lvgl crate uses a magic trick to read the raw bindings.rs from the lvgl-sys crate, it has a build dependency on lvgl-sys. Because the build scripts executables themselves are built for the host platform rather than the target platform, this will build lvgl-sys twice, one for the host (windows in my case) to link to the build script of lvgl and one for the target platform to link in the final executable. Building lvgl-sys (for a windows target) fails on windows. cc actually uses the xtensa compiler (only because of the $CC env var) but the TARGET env is set to windows (the target is a windows executable) and it will pass the wrong flags to the compiler (like -m64) because it thinks it is msvc.

The bindgen step actually works because it uses clang and the active clang configuration set by the ESP environment targets ESP.

My workaround (and possible solution) is to put the compiling (cc) step in lvgl-sys behind a specific default feature while keeping the bindgen step, then disabling this feature in lvgl's lvgl-sys build-dependency (because it only needs the bindings and not the full lib). Although I wonder if on other platforms like linux the build and normal dependencies may generate bindings for different targets?

[nia-e]

Interesting, thanks for opening this :D Will admit that I didn't expect this to be an issue, hm.
Can you open a PR with your current patches? We can see what to do from there.

[cartoush]

Hello I confirm it creates the same problems on linux, @madwizard-thomas could you share your patches ? I've been trying to reproduce them but I did not manage to get it working

[madwizard-thomas]

I tried replying to your e-mail but it bounces. Anyway, I can't access the source right now but I think I the main thing is to skip the cfg.compile("lvgl") in lvgl-sys/build.rs when it is a build dependency of lvgl. I added a feature flag for this compilation that is on by default, then explicitly disable this step for lvgl-sys in [build-dependencies] of lvgl/Cargo.toml. The build step does not need a compiled library to work and this fixes the problem.

I can look up the details later if you can't get it to work.

(sorry sent this reply via my work account first so I replaced it with this one)

[nia-e]

Does the resulting binary still work? I'd assume this means the user has to manually link it to a dylib LVGL

[madwizard-thomas]

Yes, and no manual step needed. This only causes the build step of the lvgl crate to depend on a version of lvgl-sys without a library (only bindings), but the normal (non-build) step still depends on the normal version of lvgl-sys (lib + bindings). The issue here is that the build executable is a host targeted executable, while the normal executable is the embedded target.

Ideally, lvgl's build step would not depend on lvgl-sys at all, but it does because of the let widgets_impl = lvgl_sys::_bindgen_raw_src(); workaround that reads the generated source of another crate.

[nia-e]

Interesting find, thanks so much! You can open a PR for this if you'd like and I'll take a look today.

I don't think it's viable to decouple lvgl from lvgl-sys, though; most of the lvgl crate consists of wrappers around the unsafe C functions, and statically generating the bindings and bundling them here as a huge file of extern fns is not a viable solution (that used to be how it worked, and it was a mess).

I'll also look into this more, since building lvgl-sys twice will use up a lot of space and maybe there's some way to strictly build for the target, thus keeping the compile command in.

[cartoush]

I still havent managed to get it working, I did add a default feature in the sys crate and disabled default features in the lvgl crate but I'm still getting undefined references

[weixiongmei]

@madwizard-thomas Could you provide a buildable examples of the esp-rs+lv_binding_rust? I'm trying to use the lv_biding_rust on the ESP32S3, but failed on compiling, the .c headers can't be found..... Thanks

[madwizard-thomas]

IIRC if the drivers feature is enabled it would force the SDL library so you need to remove it from lvgl-sys build as well if it is not available on your host. You also need the environment variables from my initial post (these are for windows, besides the export-esp.ps1 script). I used an empty lv_drv_conf.h
In lv_conf.h, you may need to reduce LV_MEM_SIZE, I also disabled LV_USE_LOG and LV_USE_DEMO_WIDGETS.
Any specific errors?

[weixiongmei]

@madwizard-thomas I had disabled SDL driver, set all the features in lv_drv_conf.h to 0.

[profile.release]
opt-level = "s"
lto = "off"

[profile.dev]
debug = true    # Symbols are nice and they don't increase the size on Flash
opt-level = "z"
lto = "off"

[features]

default = ["std", "hal", "esp-idf-sys/native"]

pio = ["esp-idf-sys/pio"]
all = ["std", "nightly", "experimental", "embassy"]
hal = ["esp-idf-hal", "embedded-svc", "esp-idf-svc"]
std = ["alloc", "esp-idf-sys/std", "esp-idf-sys/binstart", "embedded-svc?/std", "esp-idf-hal?/std", "esp-idf-svc?/std"]
alloc = ["embedded-svc?/alloc", "esp-idf-hal?/alloc", "esp-idf-svc?/alloc"]
nightly = ["embedded-svc?/nightly", "esp-idf-svc?/nightly"] # Future: "esp-idf-hal?/nightly"
experimental = ["embedded-svc?/experimental", "esp-idf-svc?/experimental"]
embassy = ["esp-idf-hal?/embassy-sync", "esp-idf-hal?/critical-section", "esp-idf-hal?/edge-executor", "esp-idf-svc?/embassy-time-driver", "esp-idf-svc?/embassy-time-isr-queue"]

[dependencies]
log = { version = "0.4.20", default-features = false }
esp-idf-sys = { version = "0.33.2", default-features = false }
esp-idf-hal = { version = "0.41.2", optional = true, default-features = false }
esp-idf-svc = { version = "0.46.2", optional = true, default-features = false }
embedded-svc = { version = "0.25.3", optional = true, default-features = false }
lvgl = "0.6.2"

[build-dependencies]
embuild = "0.31.3"

LVGL was added by the command
$ cargo add lvgl

Build command
$ DEP_LV_CONFIG_PATH=`pwd` cargo build

Compiling failed with ESP-IDF v5.1

  running: "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lvgl/src" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor" "-I" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lv_drivers" "-I" "/usr/include" "-I" "/usr/local/include" "-DLV_CONF_INCLUDE_SIMPLE=1" "-o" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world/target/xtensa-esp32s3-espidf/debug/build/lvgl-sys-6f91473d3a419559/out/7a316a986ee17f7b-psa_crypto_driver_wrappers.o" "-c" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world/target/xtensa-esp32s3-espidf/release/build/esp-idf-sys-9b340c643fa42c58/out/build/esp-idf/mbedtls/mbedtls/library/psa_crypto_driver_wrappers.c"
  cargo:warning=/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world/target/xtensa-esp32s3-espidf/release/build/esp-idf-sys-9b340c643fa42c58/out/build/esp-idf/mbedtls/mbedtls/library/psa_crypto_driver_wrappers.c:24:10: fatal error: 'common.h' file not found

  cargo:warning=#include "common.h"

  cargo:warning=         ^~~~~~~~~~

  cargo:warning=1 error generated.

  exit status: 1

  --- stderr


  error occurred: Command "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lvgl/src" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor" "-I" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world" "-I" "/Users/root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lv_drivers" "-I" "/usr/include" "-I" "/usr/local/include" "-DLV_CONF_INCLUDE_SIMPLE=1" "-o" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world/target/xtensa-esp32s3-espidf/debug/build/lvgl-sys-6f91473d3a419559/out/7a316a986ee17f7b-psa_crypto_driver_wrappers.o" "-c" "/Volumes/SSD1 1/Source Codes/Rust/std-training/intro/hello-world/target/xtensa-esp32s3-espidf/release/build/esp-idf-sys-9b340c643fa42c58/out/build/esp-idf/mbedtls/mbedtls/library/psa_crypto_driver_wrappers.c" with args "cc" did not execute successfully (status code exit status: 1).


root@RootMBP hello-world % 

[madwizard-thomas]

The error seems to be in the esp-idf mbedtls library, I'm not sure this is an lvgl issue. Does the project compile without lvgl?

[weixiongmei]

@madwizard-thomas Pretty sure the issue is causes by the LVGL-RS, if I comment the line of #lvgl = "0.6.2" , the project built & run successfully. Seems like it's because the include path of the C headers files are missing when compiling for the LVGL-RS, because I edited the file of psa_crypto_driver_wrappers.c, I changed the path of the "common.h" to a absolute path, other header files will be missing.... Just need a way to include all the header files of the ESP-IDF when compiling the LVGL-RS, do you know how to do it? Thank you!!

[madwizard-thomas]

I haven't tried esp-idf in a while (it takes forever to compile with rust) but I tried a new no-std project with the latest espup (cargo generate), added lvgl configs and compiled it on windows (using the export-esp.ps1 environment) without source modifications with three fixes (the feature to disable the compilation part seems no longer needed but would save a useless compile step):

First error is error occurred: Failed to find tool. Is cc installed?.
This doesn't happen on linux I think but solution is to define CROSS_COMPILE:
$env:CROSS_COMPILE="xtensa-esp32s3-elf"

Then next error is: lv_conf_internal.h:11:10: fatal error: 'stdint.h' file not found
This seems to happen because bindgen doesn't have a (correct) sysroot. You can specify with a cc arg indirectly:
$env:BINDGEN_EXTRA_CLANG_ARGS='--sysroot "C:\Users\Thomas\.rustup\toolchains\esp\xtensa-esp32s3-elf\esp-12.2.0_20230208\xtensa-esp32s3-elf\xtensa-esp32s3-elf"'

Then it fails on lv_hal_tick.h:19:10: fatal error: 'stdbool.h' file not found
Solved by adding additional include paths:
$env:C_INCLUDE_PATH="C:\Users\Thomas\.rustup\toolchains\esp\xtensa-esp32s3-elf\esp-12.2.0_20230208\xtensa-esp32s3-elf\lib\gcc\xtensa-esp32s3-elf\12.2.0\include\"

After that it works, at least for no-std esp.

For linux (I tried it with the auto generated development container in vscode), replace these with export ENV=.. and the correct linux paths.

Pro tip: you can add the following to the env section in .cargo/config.toml so you don't have to specify DEP_LV_CONFIG_PATH manually all the time:

[env]
DEP_LV_CONFIG_PATH = { relative = true, value = "." }

Back on topic, even though it seems to compile on windows, it does generate bindings twice, both for the host target and the actual target, and lvgl/build.rs uses the host target bindings rather than the actual target's bindings (because the build script is build for the host and depends on the host version of the bindings). These bindings are not the same (types differ in many places) , at least on windows and likely on linux as well so this may cause issues.

[enelson1001]

Has anyone successfully been able to use this crate on ESP32.

I have exported the following env variables

export C_INCLUDE_PATH="/home/ed/.rustup/toolchains/esp/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/xtensa-esp-elf/include"

export BINDGEN_EXTRA_CLANG_ARGS='--sysroot "C:/home/ed/.rustup/toolchains/esp/xtensa-esp32s3-elf/esp-13.2.0_20230928/xtensa-esp-elf/xtensa-esp-elf"'

But get the following error.

running: "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" 
"-I" "/home/ed/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lvgl/src" 
"-I" "/home/ed/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor" 
"-I" "/home/ed/esp-rust-projects/esp32-s3/hello-tft/." 
"-I" "/home/ed/.cargo/registry/src/index.crates.io-6f17d22bba15001f/lvgl-sys-0.6.2/vendor/lv_drivers" "-I" "/usr/include" 
"-I" "/usr/local/include" 
"-DLV_CONF_INCLUDE_SIMPLE=1" 
"-o" "/home/ed/esp-rust-projects/esp32-s3/hello-tft/target/xtensa-esp32s3-espidf/debug/build/lvgl-sys-6bb1eb053b806f99/out/551e7f5eb83719ea-ssl_debug_helpers_generated.o" 
"-c" "/home/ed/esp-rust-projects/esp32-s3/hello-tft/./target/xtensa-esp32s3-espidf/debug/build/esp-idf-sys-1f81883f55744c57/out/build/esp-idf/mbedtls/mbedtls/library/ssl_debug_helpers_generated.c"

  cargo:warning=/home/ed/esp-rust-projects/esp32-s3/hello-tft/./target/xtensa-esp32s3-espidf/debug/build/esp-idf-sys-1f81883f55744c57/out/build/esp-idf/mbedtls/mbedtls/library/ssl_debug_helpers_generated.c:25:10: fatal error: common.h: No such file or directory

  cargo:warning=   25 | #include "common.h"

  cargo:warning=      |          ^~~~~~~~~~

  cargo:warning=compilation terminated.

  exit status: 1

Anyone have any suggestions?