modules: lvgl: add automatic lv_timer_handler call

[uLipe]

inside of its own thread when user enable it on
the LVGL Zephyr options menu, using this option makes the calling of the lv_timer_handler driven by an internal timer and thread. Options like priority and stack size for this thread are exposed making it configurable by the application.

Worth to mention, this option is disbaled by default due the nature of the current samples of the LVGL that invokes lv_timer_handler from the application

[JarmouniA]

We will need a testcase somewhere in tests/samples with this option enabled

[AndreCostaaa]

Pretty cool feature 🚀

[pdgendt]

A cleaner solution IMO is:

• Have a k_work_q as the "thread"
• Use a k_work_delayable to be (re)scheduled
• Call lv_timer_hander in the delayed work handler and re-schedule based on the result

EDIT: Added benefit: the work queue could be user exposed to allow submitting/scheduling more work onto the LVGL thread.

[uLipe]

@pdgendt I implemented using the workqueus, I kepi the previous one on the commit history, for easy comparisation

[pdgendt]

@pdgendt I implemented using the workqueus, I kepi the previous one on the commit history, for easy comparisation

Didn't notice this, please squash in that case.

[uLipe]

@JarmouniA what would be a good way for testing this option? Just duplicate one of the samples but using this option and removing the sleep loop? BTW this can be part of another PR?

[uLipe]

Thank you @pdgendt , I exposed also the workqueue via a function

[pdgendt]

Awesome stuff, do you see the same gains you had like using the timer? It probably should as these use the same low level primitives.

[JarmouniA]

@JarmouniA what would be a good way for testing this option? Just duplicate one of the samples but using this option and removing the sleep loop?

If I understand the purpose of this PR correctly, putting

zephyr/samples/modules/lvgl/demos/src/main.c

Line 56 in 1ba9504

lv_timer_handler();

and

zephyr/samples/modules/lvgl/demos/src/main.c

Line 64 in 1ba9504

uint32_t sleep_ms = lv_timer_handler();

in between ifndef CONFIG_LV_Z_RUN_LVGL_ON_WORKQUEUE... endif then adding a testcase in sample.yaml with extra_configs: CONFIG_LV_Z_RUN_LVGL_ON_WORKQUEUE=y would work, no?

[uLipe]

@pdgendt yes they offer the same performance and better timer slippage correction than using the sleep loop approach, but the workqueue is much cleaner

[uLipe]

Added the tests case on the demo samples as pointed by @JarmouniA , the missing piece of this PR, please everyone take another look :)

[faxe1008]

Agreeing with @JarmouniA, one case for building the sample with the new option should be good enough, otherwise LGTM :^)

[uLipe]

@JarmouniA @faxe1008 , got it, I left only the case of the demo benchmark then please PTAL again :)

[JarmouniA]

@JarmouniA @faxe1008 , got it, I left only the case of the demo benchmark then please PTAL again :)

still seeing all of them

[uLipe]

Uhh, It seems I edited from the wrong place, thanks for notice @JarmouniA, just corrected :)

Thank you!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[uLipe]

@kartben any chance on making this on the 4.2? This change will improve significant the timing characteristics of the LVGL core.

[JarmouniA]

@kartben any chance on making this on the 4.2? This change will improve significant the timing characteristics of the LVGL core.

only bug fixes are backported.

[uLipe]

Nevermind @JarmouniA, @kartben the 4.2 is already out, I was thinking that Zephyr was approaching on feature freeze