Hi, newby here. I’m working through this demo: https://www.youtube.com/watch?v=5LuIpnN7eks
…trying to get LVGL working with an ESP32S3 1.28" display.
Is it just me, or do a lot of people have issues just getting the LVGL samples to compile in the Arduino IDE? So far I’ve had about five compile issues, ranging from:
error: ‘lv_indev_drv_t’ does not name a type; did you mean ‘lv_indev_data_t’ (a gazillion of these)
to
error: ‘lv_indev_drv_register’ was not declared in this scope
to
error: variable or field ‘my_disp_flush’ declared void
to
error: ‘my_touchpad_read’ was not declared in this scope
…and many, many more.
Is the code on the github (GitHub - lvgl/lvgl: Embedded graphics library to create beautiful UIs for any MCU, MPU and display type.) the right code to use, and is any regression testing performed prior to publishing to detect conflicts with prior versions, or are new versions just randomly deployed which cause errors in examples/code written in past versions because a variable or function name was changed?
Not trying to ruffle feathers or offend, just trying to understand why nothing with LVGL seems to compile without errors, even with following the ‘copy demos from lvgl directory to src directory’ (are we still doing that?) kind of oddities.
Thanks in advance for guidance.
Hi @jobo722
No offense, but I’m not sure what kind of newbie you are—whether it’s with the LVGL framework or C compilation in general. If you’re just starting with embedded development and want to create some cool UIs using LVGL but run into compilation errors, I suggest taking some time to understand what these errors mean and how compilation works. This knowledge will be really helpful later when you work on other frameworks or projects. Otherwise, even if you manage to bypass this compilation error by following a guide online, you’ll likely run into another one soon.
If you’re already experienced in embedded development but aren’t sure how to integrate LVGL with your project, I understand your struggle. To be honest, I’m not a fan of IDEs like Arduino because they hide what’s happening behind the scenes, and when issues arise, it’s hard to know where to start debugging. I’ve never used Arduino myself, and questions like yours can be tough for others to answer clearly.
Just this afternoon, I tried integrating the latest version of LVGL into my Pico RP2040 project as a fun exercise using CMake. For me, it wasn’t too difficult, as long as you understand some compilation concepts. I believe LVGL also provides a way to integrate via Makefile, though I haven’t tried that yet.
Recently, I also try with my home stm32f4 board, it also quite easy. You can have a look at here
Happy learning !!!
dchithinh, thanks for the reply…I appreciate it. While I’m not an Arduino/ESP32 expert by any means, I’ve worked in a hobby sense with both for around 10 years, so I’m familiar w/ the fundamental structure. My question is specifically about LVGL regarding the version incompatibility. One example is the Wondershare ESP32-S3 1.28" display sample code (from their wiki) notes that it will only work with LVGL v8.3.10, which I’ve found to be true. I’m using this as an example, because the easy answer would be ‘well, Wondershare needs to upgrade their configuration to support LVGL latest 9.3.0’…but the issue isn’t isolated to Wondershare. It’s almost like, as stated above that LVGL haphazardly deploys new versions, deprecating old functions, renaming objects which render any samples generated in prior versions useless. This also means that I need to turn my Arduino IDE ‘auto-update library’ functions off, as if it is on auto-updating the LVGL library will, again, render prior code obsolete, generating tons of compilation errors. Maybe changing from Arduino IDE to another platform would help with the debugging…but the bigger question I’m asking is…why are there so many compilation errors in the first place that have to be debugged in order for some pretty basic examples and code to be used…wondering if there is any regression testing going on with LVGL at all, or is it more of a ‘deploy and hope for the best…they’ll figure out what changed’ approach. I’ve read a lot on this forum and see frequent ‘tried it for two weeks, moving on to XX’ responses, hoping that I’m missing something with respect to the cause of extensive cases where newer versions of LVGL render a ton of online examples case studies in debugging compilaiton errors.
Yeah, Understandable.
One of my colleagues used LVGL for a hobby project, and he told me it’s a great UI library to experiment with. The only drawback, according to him, is that the versions change so quickly — which he doesn’t really like. Haha.
At the end of the day, it’s just our hobby, so no need to stress. We’ll mess around, break things, fix them, and pick up some cool skills along the way.
Happy learning!!!
Even though I didn’t help much in your case