Building for ESP32 #102
Comments
|
Interesting, thanks for opening this :D Will admit that I didn't expect this to be an issue, hm. |
|
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 |
|
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) |
|
Does the resulting binary still work? I'd assume this means the user has to manually link it to a dylib LVGL |
|
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 |
|
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 I'll also look into this more, since building |
|
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 |
|
@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 |
|
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 |
|
@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"Compiling failed with ESP-IDF v5.1 |
|
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? |
|
@madwizard-thomas Pretty sure the issue is causes by the LVGL-RS, if I comment the line of |
|
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 Then next error is: Then it fails on 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 Pro tip: you can add the following to the env section in 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. |
|
Has anyone successfully been able to use this crate on ESP32. I have exported the following env variables But get the following error. Anyone have any suggestions? |
|
I was able to get lvgl to build on my ESP32S3 device without errors. I used the following command to build lvgl so I could look for errors My first error was not finding 'bits/libc-header-start.h' file This error was solved by doing the following: My second error was not finding string.h file This was solved by editing the config.toml file to add additional items to rustflags. Since I was editing the file I added DEP_LV_CONFIG_PATH environmental variable setting The last error I got was a ctor error. I updated lvgl in Cargo.toml to look like the following. |
|
I spoke to soon. When trying to build lvgl in my project I get the following error I solved this by using the following build command. But then the next error I get is the following. I did verify that SDL2 is present in /usr/lib/x86_64-linux-gnu. But then I get the following error For now (since I don't know how to fix) I made changes the the build.rs file located in lvgl-sys directory so I could build without any errors. I will update if I have any more problems or solution to the SDL2 problem |
|
It is because it is trying to link the SDL2 library compiled for the host to the xtensa binary, that will never work. You either need an SDL library compiled for your embedded device, which probably isn't supported or available, or disable SDL. Unfortunately the current lvgl-rs library automatically includes it when the drivers feature is enabled, so either disable the drivers feature or comment the lines out like you did. Most of these problems are either the cc or bindgen crate compiling for the wrong platform. On linux it will sometimes even work but actually generate the bindings for the host. You can add this to lv_conf.h to check: (use If this error triggers it is compiling/generating bindings for the wrong platform. It will also then also likely generate a lvgl library for the host but because it is never referenced (lvgl's build step does not actually call lvgl-sys's C functions) it will never be linked in. If you would add for example lv_init() to I have some ideas to cleanup build.rs and fix some of the problems, I'll try to find some time to create a PR. CROSS_COMPILE and a sysroot for bindgen will still be necessary environment variables though, because in the end we are cross building. |
|
I added your suggestion. And the error triggered. I have noticed that the build.rs program compiles for both the target = host and the target = xtensa-esp32-espidf. So I assumed everything would just work out correctly. I have couple more questions related to implementation. All the examples given use the Simulator and I am struggling with how to run any of the examples with a real world display. I would like to use a display that is written in Rust not C. I was looking at using register_raw but that doesn't seem to work either. |
|
I can confirm that the build with the changes I made does not run the the esp device. The WDT is triggerd and the esp32 reboots when trying to execute the following instruction. I will keep trying different settings. I hope madwizard-thomas will submit a PR that will resolve the problem. |
|
PR is submitted but it fixes the cross-compilations issues only, I think you are having unrelated issues. The drawbuffer is probably too large, I think it uses the stack the way you set it up so it probably runs out of stack. Try a drawbuffer of 10 lines for example, it doesn't have to be the same size as the display buffer. |
|
@madwizard-thomas Thank you for your work and submitting the PR. Hopefully it will get approved The drawbuffer size was the problem setting HORZ_RES = 320 and VER_RES = 10 fixed the wdt timeout. Now I just need to figure out how to get the DisplayRefresh updates to work with my display. Everything compiles OK but my screen is not refreshed. I put a println inside the closure and know that lvgl is calling display_update that is registered. |
|
@enelson1001 are you using SPI display or RGB display with EPS32? I can't find any info about how to use 16-Bit RGB display with ESP32-Rust. If you're using RGB display, could you share a little info or example code for that? Thank you~~~ |
|
@weixiongmei If I something working on the RGB display I will let you know. |
|
@madwizard-thomas I have also added PSRAM settings to my sdconfig.defaults file. The program crashes with Do you know how to make the DrawBuffer use the heap PSRAM |
|
Note that normally only 4M of the 8 is available, you need to use the himem
API to get to the other 4M. That restricts what you can use the upper 4M
for.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/himem.html
…On Sun, Nov 19, 2023, 11:07 AM enelson1001 ***@***.***> wrote:
@madwizard-thomas <https://github.com/madwizard-thomas>
I have board with 8MB of PSRAM. I would like to use this memory for the
DrawBuffer. I have added the feature alloc to lvgl in the Cargo.toml file.
lvgl = { version = "0.6.2", default-features = false, features = [
"embedded_graphics",
"unsafe_no_autoinit",
"alloc"
] }
I have also added PSRAM settings to my sdconfig.defaults file.
CONFIG_SPIRAM=y
CONFIG_SPIRAM_MODE_OCT=y
CONFIG_SPIRAM_SPEED_80M=y
The program crashes with Could not allocate memory
Do you know how to make the DrawBuffer use the heap PSRAM
—
Reply to this email directly, view it on GitHub
<#102 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPWAWV6WZR3KYNGB6RPZATYFI4DPAVCNFSM6AAAAAAXDWLIZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXHEYTQMZTGA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I was trying to allocate about 150k bytes so that should not have been a problem correct? |
|
Correct
…On Sun, Nov 19, 2023, 11:24 AM enelson1001 ***@***.***> wrote:
I was trying to allocate about 150k bytes so that should not have been a
problem correct?
—
Reply to this email directly, view it on GitHub
<#102 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPWAWUJMD5U3YLKUSFEDBLYFI6FFAVCNFSM6AAAAAAXDWLIZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXHEZDGMJTGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@weixiongmei See the examples below for using lv-binding-rust on the these devices M5Stack ESP32S3 - Not using touchscreen ESP32S3 - Using capacitive touchscreen |
|
@enelson1001 Very appreciated! |
|
@enelson1001 Have you figure out how to use the external RAM for display buffer yet? Thanks~~ |
|
@weixiongmei |
|
@enelson1001 Can you share the external RAM example once you have figured out please? thank you!!!! |
|
For those interested I have a more robust example using lv_binding_rust on a Aliexpress ESP32S3 development board with a 7 inch display and a capacitive touchscreen called weather-forecaster. |
and others
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):
However
bindgencc 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?
The text was updated successfully, but these errors were encountered: