Add LittevGL Embedded GUI Library

[rleh]

LittlevGL is a free and open-source graphics library providing everything you need to create embedded GUI with easy-to-use graphical elements, beautiful visual effects and low memory footprint.

• https://littlevgl.com/
• https://github.com/littlevgl/lvgl

Status

• LittevGL git submodule in ext/
• lbuild module with basic options
  • Which additional options would be useful?
• Example for STM32F469-Discovery board: Currenty status: hardfault during lv_init()
• Example for SSD1306 display

[mikewolfram]

If you get it work I'd be interested to see how much code space it actually requires. I had the same issues, lv_init() failed all the time. I'm not sure whether the memory they use isn't really zero'd at startup or maybe an alignment issue?

Regarding lbuild options, would it make sense to allow most of the options in lv_conf.h to be set through options?

[rleh]

allow most of the options in lv_conf.h to be set through options

Of course! Once I have a little bit of experience with LittlevGL (at least on the F469-Discovery and with a SSD1306 display) I will add more reasonable options.

---

I'm not sure whether the memory they use isn't really zero'd at startup or maybe an alignment issue?

That's one of my suspicions, too. I checked the memory where _lv_img_cache_array is located immediately after Board::initialize():

Address: 0x20000D9C=C0000000
Address: 0x20000DA0=C1000000
Address: 0x20000DA4=FFFFFFFF
Address: 0x20000DA8=FFFFFFFF
Address: 0x20000DAC=FFFFFFFF
Address: 0x20000DB0=FFFFFFFF
Address: 0x20000DB4=FFFFFFFF
Address: 0x20000DB8=FFFFFFFF
Address: 0x20000DBC=FFFFFFFF
Address: 0x20000DC0=FFFFFFFF
Address: 0x20000DC4=FFFFFFFF
Address: 0x20000DC8=FFFFFFFF
Address: 0x20000DCC=FFFFFFFF
Address: 0x20000DD0=FFFFFFFF
Address: 0x20000DD4=FFFFFFFF
Address: 0x20000DD8=FFFFFFFF
Address: 0x20000DDC=FFFFFFFF
Address: 0x20000DE0=FFFFFFFF
Address: 0x20000DE4=00000000
Address: 0x20000DE8=00000000

Anybody any idea why this memory is not zero?

[salkinium]

Anybody any idea why this memory is not zero?

Try memsetting the memory to zero before calling lv_init(), perhaps it'll then fail somewhere further down and give you more clues.

[salkinium]

Perhaps lv_init is calling calloc()? But for TLSF this is implemented with memset (correctly as I believe). Hm…

void *__wrap__calloc_r(struct _reent *r, size_t size)
{
	(void) r;
	void *ptr = __wrap__malloc_r(r, size);
	if (ptr) memset(ptr, 0, size);
	return ptr;
}

[rleh]

I'm gonna close the pull request and stop working with LittlevGL.
The effort to integrate it is not worth it, instead I will see if I can build a (for now lightweight) C++ GUI toolkit based on https://github.com/salkinium/upainter.

[mikewolfram]

Since I'll need an UI soon I'd help. Maybe you can share your idea?

[rleh]

In modm we currently have this very basic GUI module: https://docs.modm.io/develop/api/stm32g474vet7/group__modm__ui__gui.html
Maybe that is useful for you in the short term?

At some point in the future I would like to implement something with nearly the core feature-set of LittlevGL but with a modern C++17 API. upainter already implements color management, rendering, event system and basic geometries with C++14 and looks like a solid base (@salkinium told me he would be ok with re-licensing it as MPLv2).

I will probably use the existing "modm" module for my upcoming project, because I don't have the time to create a C++ graphics library in the near future.

[mikewolfram]

I already had a look into the modm UI module and was actually thinking to enhance it to my needs. Need to dig more into it, but I think it is sufficient for our needs. We don't need anything fancy like themes, sophisticated widgets or animations etc. In our case the display would be turned off most of the time (saving power) and when it is turned on it is to inform the operator with status or what to do.

[mikewolfram]

Is there a more complex example demonstrating the use of the UI module?

[rleh]

modm::gui is used in the @roboterclubaachen|s robots. But the code has no clear license, so I can't just publish it. (It is also in parts quite bad code.)
Here is an excerpt: https://gist.github.com/rleh/56b42afa05e74c0568c480a263dec1c3

It would be nice to have a advanced example demonstrating the capabilities of modm::gui.

[salkinium]

I completely forgot about upainter until @rleh pointed it out to me. It was written as an exercise in applying old 70s/80s graphics papers and algorithms and then got a little out of hand, as per usual when I touch a computer… The project was intended to be a drop-in replacement for the FT8XX graphics accelerator (which is why there is a fixed point math class), most notably used in the Gameduino2/3 shields: https://excamera.com/sphinx/gameduino3/index.html

Note that upainter would just be a new graphics backend, it doesn't have any support for GUI elements like modm::gui, so the plan would be to hack upainter into modm::{Buffered}GraphicDisplay and re-use modm::gui anyway. So we'd have to use modm::gui anyways for the foreseeable future.

[rleh]

But upainter already offers much more functions for drawing than modm::{Buffered}GraphicDisplay, or am I missing something?

[salkinium]

It offers more drawing functions, however they are low-level functions. Things like bitmap rendering isn't implemented, so you have to do raw pixel access. But that's basically what graphic display does, except it also implements low-level drawing primitives. So you can replace these with upainter, but without adapting the API to expose the improved colors, you'd only get a minor improvement.

[rleh]

LittlevGL/LVGL integration: See #603