To make things clear, we are not planning to rely on any C++ features that are known for excessive code size or bloat. Performance should be similar or identical to the current version - this is mainly a syntactical change that would get rid of some ugly hacks in the current codebase.
I’m mainly using lvgl on ESP32, Teensy 3.6+, and FPGA targets.
I’ve updated the first post.
Why not other languages like Go or Rust?
Probably because you will not able to run it on 8-bit … 32-bit tiny MCU’s.
There are compilers for 32 bit mcus in both languages. And I dont think LVGL was made for 8 bit MCUs
We want a language that is fully compatible with C/C++ infrastructure without requiring extra bindings.
I agree with you
Anyone, who can use C only, could you explain your situation? At first glance, C++ should be available everywhere (for any MCU, able to run LVGL). I’d like to understand your cases.
C++ should be available everywhere
Java is available everywhere, too.
No, i cant use java on 8 bit mcu
I can use lvgl C only. I am working on dualboot solution for android devices, https://github.com/Android-Boot-Manager and in some cases we replace phones bootloader. For example on Volla Phone we have 1 mb partition for lk (little kernel) based bootloader. We have a lot of problems fitting evrything there, and there is no space for libc++. But libc is there, bcz lk needs that.
@luka177 are you sure libc++
will be mandatory? with --specs==nano-specs
my projects are built with ordinary newlib-nano.
Here are no wish to write in cpp style, only in “c with classes”.
No, i cant use java on 8 bit mcu
Oh, sure you can, just google e.g. AVR JVM. And you could, some 20 years ago, too; e.g. using the TINI stack in Dallas Semiconductor DS80C380.
But that’s not the point.
The point is, that a tool being available does not mean it’s suitable. There are many, MANY reasons to use or not to use a given tool/feature.
C is the least common denominator for microcontrollers in particular, and LVGL being in C is a precious asset, increasingly rare these days.
OTOH, I understand Gabor’s desire to migrate to C++ - at the end of the day, he painstakingly reproduced some of the features which would come automatically with C++.
For me personally, C++ as a showstopper, though.
JW
Still what about size, wount lvgl become bigger?
It’s likely to not change that much in either direction, since the existing “fake” objects would be replaced by standard C++ logic. However, I haven’t done any profiling of C++ classes to know the exact cost compared to our current solution.
In general - no, size will be ~ the same.
Having a proper C++ API will make using LVGL. For example, I wouldn’t need to remember if method X comes from obj or from Label. Just typing my_label.set_pos in the IDE and the autocompletion will find it.
BTW, the limits that I face are around RAM and screen update speed (number of pixels to push to the TFT controller) and not that much around ROM, code size, or computation speed.
Hello,
I’m back on this subject long time after, but my 2 cts
I like developing in C++ but definitively prefer to keep C as main target : I’m hacking on very slow machines (15+ year old PC, SBC like BananaPI, …) and, unfortunately, C++ compiler are pains on them due to resources usages (memory, CPU, …).
So I would prefer to have a lightweight as possible LVGL even if I wrote a C++ building when I develop for ESP32.
Bye
Laurent