Port to LVGL v7.0 #101

C47D · 2020-04-21T19:39:11Z

List of necessary changes:

Update lvgl submodule.
Update lvgl example submodule.
Update lvgl configuration file.

kisvegabor · 2020-04-21T20:29:38Z

Update lvgl submodule.

It's in dev-7.0 branch

Update lvgl example submodule.

It's in rework-7 branch

Update lvgl configuration file.

It'd be best to create a new one based on lv_conf_templ.h in dev-7.0.

Could you make a build test to see if there are any serious issues?

C47D · 2020-04-22T15:15:02Z

I will do the tests here: https://github.com/C47D/lv_port_esp32_v7
Once we get it working I will update this repo

C47D · 2020-04-23T05:20:47Z

First teaser, still some work to do i think

kisvegabor · 2020-04-23T06:09:01Z

What is the size and resolution of the display and LV_DPI?

C47D · 2020-04-23T15:24:34Z

Size of the screen is 320*240, LV_DPI is 100, now it have the proper configuration (of display size and orientation).

kisvegabor · 2020-04-23T17:53:57Z

The demo recognizes if it's a small, medium, large or extra large display and sets the layouts accordingly. This display should have been recognized as small.
What is the size of the display (in inches). We can calculate the real DPI from it.

Besides, please modify LV_DISP_SMALL_LIMIT to 25 in lv_conf.h.

C47D · 2020-04-23T18:47:26Z

The LCD size is 3.2" (inches), ok I will modify LV_DISP_SMALL_LIMIT to 25 and upload a pic.

kisvegabor · 2020-04-23T19:10:41Z

So the actual DPI is: `sqrt(320^2 + 240^2) / 3.2 = 125.
And width of the display is 320/125 = 2.56".

If you set to LV_DISP_SMALL_LIMIT to 25 lvgl will consider > 2.5" display as medium-sized and create this ugly layout. So please set it to 30 (3.0") instead of 25.

C47D · 2020-04-23T19:36:35Z

Much better

kisvegabor · 2020-04-23T19:39:55Z

Awesome, thank you!
I'll recalculate the default size limits.

You can enable LV_USE_PERF_MONITOR in lv_conf.h to see the current FPS and CPU usage.

C47D · 2020-04-23T20:43:03Z

I'm getting 33FPS, with CPU from 18% to 28% and peaks of 34%.

embeddedt · 2020-04-23T20:44:21Z

@C47D I'm curious; what FPS do you get at the moment when you scroll past the gauges in the Values tab? I'd like to compare with what I see on STM32F7 (I get 14-18 FPS while scrolling; it increases after that).

C47D · 2020-04-23T20:58:30Z

Hi @embeddedt, this particular display doesn't have a touch controller, I will try to setup another display to measure the FPS values you've requested.

kisvegabor · 2020-04-24T08:06:27Z

@C47D I've modified the demo in test/no-tp branch. It changes between the tabs automatically and shows the gauges on the second tab.

C47D · 2020-04-24T14:19:34Z

Hi, I took a video of the demo using the test/no-tp branch.

https://youtu.be/BJv-vr03RsM

kisvegabor · 2020-04-24T14:47:41Z

Thank you!

There is still huge FPS drop when the gauge is fully redrawn. At least refreshing the needle only is not that bad.

I have a few questions:

What is the size of the display buffer?
Do you use 2 buffers with DMA in flush_cb?
Have you enabled -Os or -O3 optimization?
What is the speed of the SPI?

C47D · 2020-04-24T16:06:56Z

Hi, I'm not at home right now I will update my reply with the data you requested.

I had an issue with the demo, the demo stopped working after some minutes and the screen is stuck, I have tried to replicate the issue but it stopped at different times. I will try to add the log functions to lvgl so I can know when it stops.

embeddedt · 2020-04-24T16:15:48Z

the demo stopped working after some minutes and the screen is stuck

I also saw this happen once on my STM32F7, but I didn't have time to investigate further. It was a few days ago.

C47D · 2020-04-24T17:39:30Z

Added some printf debugging points to see where the display is getting stuck and I can't replicate the issue, the demo has been running for almost an hour, but noticed that the lv_tick_task is still running.

There's also a new issue on the lvgl repo which uses the same dev board as me and doesn't report the issue Dev-7.0 performance experiments

kisvegabor · 2020-04-24T17:39:34Z

I also saw the freeze but I thought it's a bug in my hacky display driver. I've already debuged that it stops on a while(vdb->flushing); I still don't know if lv_disp_flush_ready is not called or it's called but as it is called from an interrupt (for all of us) it might mess up things somehow. I mean some assembly level you-never-find-it bug.

I suspect the latest because while(vdb->flushing); reads a bit field which can be quite complicated on assembly level.

kisvegabor · 2020-04-24T17:41:16Z

I suggest running the lv_demo_stress() which makes much more drawing.

embeddedt · 2020-04-24T17:41:53Z

I call lv_disp_flush_ready directly from the flush_cb function, so it can't be entirely an interrupt-related issue.

kisvegabor · 2020-04-24T17:46:02Z

I call lv_disp_flush_ready directly from the flush_cb function, so it can't be entirely an interrupt-related issue.

Ah, good to know. I thought you are using the DMA based flush_cb.

C47D · 2020-04-24T18:19:44Z

I call lv_disp_flush_ready from a callback when the SPI finished transferring the data via DMA.

C47D · 2020-04-24T18:48:49Z

@kisvegabor Do you know if it's possible to get a backtrace when the application is stuck? I'm searching some tutorials to debug the esp32 chip with gdb.

embeddedt · 2020-04-24T18:53:25Z

If you have debug symbols available and can attach to the device with GDB after it's already running, you should be able to interrupt execution, type bt, and get a decently usable backtrace.

kisvegabor · 2020-04-24T19:11:39Z

It seems @embeddedt knows it much better than me 🙁

I added some debug code and will run the stress demo all night, and hopefully it'll freeze.

C47D · 2020-04-24T19:30:07Z

@embeddedt Thanks, I do have debug symbols available, but it's a pain to setup the ESP32 tools on Windows, I was using the WSL but can't run openocd there, so i have to setup the toolchain in Windows directly :/.

kisvegabor · 2020-04-24T20:09:56Z

I think I found the issue but the picture is not perfect yet.

These are the interesting parts of lv_disp_buf_t. So there are 4 bits next to each other. When going to the next part to refresh lvgl might write the last 3 fields. So what I suspect is:

When e.g. last_area is set, first the whole bitfield is read to a register
An interrupt comes and set flushing = 0
In the register read in 1) the last_area is set but flushing is still 1 too because it was cleared in the "real" variable.
The register is written back and it overwrites the flushing bit.

So it's a typical Read-Modify-Write issue.
It all makes sense but @embeddedt said he doesn't use interrupt in the flush_cb.
So @embeddedt, are you sure you weren't using an interrupt based driver when it froze for you?

I've pushed a trivial fix. Let's see if it helps.

persello · 2020-05-08T23:02:57Z

Hello, I just tried the dev-7.0 branch with my ILI9488. I had some problems with the default frequency set to 64MHz by the f6113af commit. I have to say, I'm on a breadboard, so this could be the issue here, and I won't get any PCBs for my project until late this summer. From what I have tested, 64MHz seems just above the "sweet spot" for this display driver (data sheet says max. 40MHz, but I reached 60MHz with no artifacts), since the screen contents are intelligible but heavily damaged. Could it be possible to have a custom default frequency for this driver set to 40~60MHz and maybe, in the future, having the ability to set a custom one from menuconfig? I have never used Kconfig but looking at it, it doesn't seem that difficult, so I could at least try to add this small feature tomorrow or in the next few days.

EDIT: Created a draft pull request #126 (this is my first PR and Kconfig edit, so changes/edits/suggestions are welcome and no problem if rejected).

C47D · 2020-05-09T00:39:00Z

It looks really helpful, thanks for the PR, hopefully more to come :)

barbiani · 2020-05-09T01:46:12Z

60MHz is actually 40... and 64 is 80. The esp32 does not have fractional clock multipliers so the last jump is from 40 to 80.

…

On Fri, May 8, 2020, 21:39 Carlos Diaz ***@***.***> wrote: It looks really helpful, thanks for the PR, hopefully more to come :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYLTJCPP5Q6TYEM7PZCPK3RQSQ27ANCNFSM4MNR4RYA> .

barbiani · 2020-05-24T21:02:13Z

@C47D
Have you ever tried running guiTask in the PRO_CPU? I can not understand why it is much faster than APP_CPU. This is true if wifi/bt are disabled.

C47D · 2020-05-24T21:09:16Z

No, I haven't. Did you tried to?

barbiani · 2020-05-24T21:12:26Z

I did. About 2x the FPS.

…

On Sun, May 24, 2020 at 6:09 PM Carlos Diaz ***@***.***> wrote: No, I haven't. Did you tried to? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYLTJBXAECWZDGLWS3INYLRTGEIPANCNFSM4MNR4RYA> .

C47D · 2020-05-24T21:22:40Z

Do you think we should add a comment about that on the source code? I'm about to merge the dev-7.0 PR into master, I'm finishing some arrangements in the README.

If you could give it a try it would be great, #110

barbiani · 2020-05-24T21:26:48Z

I would not add the note until someone figures it out. The cores should be the same.

embeddedt · 2020-05-24T21:42:23Z

I would guess that there's another task running on the APP_CPU that we're unaware of.

kisvegabor · 2020-05-25T11:23:56Z

I've found these topics
https://www.esp32.com/viewtopic.php?t=9315
https://www.esp32.com/viewtopic.php?t=8558

barbiani · 2020-05-25T14:22:50Z

It has something to do with running lvgl in a task. This approach gives the same result as running lvgl in core 0 but without the drawbacks of sharing the core with the comms stack.

Do expect 2x the performance over lv_port_esp32.

I just changed it to:

void lv_tick_hook (void) {
    lv_tick_inc(1);
}

esp_register_freertos_tick_hook(lv_tick_hook);

C47D · 2020-05-25T15:57:36Z

So instead of running a periodic timer and increase the LVGL tick on the callback of it you are increasing it at the FreeRTOS tick rate?

barbiani · 2020-05-25T16:03:11Z

I am running lvgl in a timer callback (that is called in a core 1 task) and lv tick in an interrupt. There is no semaphore.

…

On Mon, May 25, 2020, 12:57 Carlos Diaz ***@***.***> wrote: So instead of running a periodic timer and increase the LVGL tick on the callback of it you are increasing it at the FreeRTOS tick rate? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYLTJHMLRD63IC42WPZHQDRTKIP3ANCNFSM4MNR4RYA> .

embeddedt · 2020-05-25T17:22:04Z

Maybe #136 is related?

C47D · 2020-05-25T18:10:27Z

@barbiani Could you review it? I don't have access to my pc to test it right now

vheathen · 2020-05-25T19:47:20Z

@C47D
Have you ever tried running guiTask in the PRO_CPU? I can not understand why it is much faster than APP_CPU. This is true if wifi/bt are disabled.

Could it be connected to this?

Timer callbacks are called from a task running on the PRO CPU.

C47D · 2020-05-25T20:36:02Z

I think @barbiani meant the task that runs LVGL, which is attached to APP CPU, not the CPU of the tick timer.

vheathen · 2020-05-25T22:24:45Z

I think @barbiani meant the task that runs LVGL, which is attached to APP CPU, not the CPU of the tick timer.

Yes, I understand it. If a timer callback runs on the different (in regard to the LVGL task) core it might have speed penalty (I didn't dig into the lv_tick_inc() func so don't know how expensive it is). If the LVGL task started on the same core as a timer callback then performance is higher than if it started on an another core, so it is just a guess.

barbiani · 2020-05-25T23:40:02Z

What I am experiencing is that I get better performance when lv_task_handler() is scheduled on core 0.

C47D · 2020-05-26T00:52:47Z

For this demo is OK to pin the lvgl task to CPU 0, or don't even create a new task for it. Once the users try to enable WiFi or BLE into their applications they would need to pin the lvgl to CPU 1.
Is this right?

C47D · 2020-06-04T18:42:15Z

Closed with #110 being merged into master. Further performance improvements can be discussed in new issues.

barbiani · 2020-06-09T22:48:11Z

A small optimization to prevent uneeded context switches.

uint32_t lv_delay;	
while (1) {
	if (xSemaphoreTake(xGuiSemaphore, (TickType_t)10) == pdTRUE) {
		lv_delay = lv_task_handler();
		xSemaphoreGive(xGuiSemaphore);
	}
	vTaskDelay(lv_delay);
}

C47D · 2020-06-10T00:18:00Z

Nice to see that LVGL feature being used, thanks for the tip @barbiani :), mind to send a pull request for it?

embeddedt · 2020-06-10T00:22:26Z

I'd add lv_delay = 10; at the beginning of the loop body. That way if the semaphore doesn't get taken the thread will always sleep for 10 ms and try again. The current code could sleep for an undefined amount of time as lv_delay has a potentially undefined value.

barbiani · 2020-06-10T00:33:01Z

Good point. The idea was posted. I have it as static.

Could increase the sem take timeout... but anyway, it sleeps exactly the amount needed by lv_task_handler();

The performance monitor cpu usage drops a lot.

barbiani · 2020-06-10T20:58:03Z

Nice to see that LVGL feature being used, thanks for the tip @barbiani :), mind to send a pull request for it?

I am using CONFIG_FREERTOS_HZ == 1000. If it is set to 100hz (10ms) most delays will be broken in 2 or more.

Does it make sense to delay a task by 1ms if the system tick is 10ms?

embeddedt · 2020-06-10T21:03:25Z

Does it make sense to delay a task by 1ms if the system tick is 10ms?

In general, I believe delays get rounded up to the system timer frequency, therefore the task will effectively be delayed for up to 10ms.

I don't know if FreeRTOS follows that rule or not but most RTOSes do from what I know.

barbiani · 2020-06-10T21:06:23Z

This would hurt lvgl performance. So the benefit is lost unless the tick rate is 1000hz.

…

On Wed, Jun 10, 2020, 18:03 embeddedt ***@***.***> wrote: Does it make sense to delay a task by 1ms if the system tick is 10ms? I believe delays get rounded up to the system timer frequency, therefore the task will effectively be delayed for up to 10ms. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYLTJBPH3VVSMTIL5YZTS3RV7YKXANCNFSM4MNR4RYA> .

C47D mentioned this issue Apr 24, 2020

Dev-7.0 performance experiments lvgl/lvgl#1471

Closed

C47D closed this as completed Jun 4, 2020

C47D mentioned this issue Jun 14, 2020

hope the main lib can add a T9 keyboard. lvgl/lvgl#1477

Closed

Port to LVGL v7.0 #101

Port to LVGL v7.0 #101

Comments

C47D commented Apr 21, 2020 • edited Loading

kisvegabor commented Apr 21, 2020

C47D commented Apr 22, 2020

C47D commented Apr 23, 2020

kisvegabor commented Apr 23, 2020

C47D commented Apr 23, 2020 • edited Loading

kisvegabor commented Apr 23, 2020

C47D commented Apr 23, 2020

kisvegabor commented Apr 23, 2020

C47D commented Apr 23, 2020

kisvegabor commented Apr 23, 2020

C47D commented Apr 23, 2020

embeddedt commented Apr 23, 2020

C47D commented Apr 23, 2020

kisvegabor commented Apr 24, 2020

C47D commented Apr 24, 2020

kisvegabor commented Apr 24, 2020 • edited Loading

C47D commented Apr 24, 2020

embeddedt commented Apr 24, 2020

C47D commented Apr 24, 2020

kisvegabor commented Apr 24, 2020

kisvegabor commented Apr 24, 2020

embeddedt commented Apr 24, 2020

kisvegabor commented Apr 24, 2020

C47D commented Apr 24, 2020

C47D commented Apr 24, 2020

embeddedt commented Apr 24, 2020

kisvegabor commented Apr 24, 2020

C47D commented Apr 24, 2020

kisvegabor commented Apr 24, 2020 • edited Loading

persello commented May 8, 2020 • edited Loading

C47D commented May 9, 2020

barbiani commented May 9, 2020 via email

barbiani commented May 24, 2020

C47D commented May 24, 2020

barbiani commented May 24, 2020 via email • edited Loading

C47D commented May 24, 2020 • edited Loading

barbiani commented May 24, 2020

embeddedt commented May 24, 2020

kisvegabor commented May 25, 2020

barbiani commented May 25, 2020 • edited Loading

C47D commented May 25, 2020

barbiani commented May 25, 2020 via email

embeddedt commented May 25, 2020

C47D commented May 25, 2020

vheathen commented May 25, 2020

C47D commented May 25, 2020

vheathen commented May 25, 2020

barbiani commented May 25, 2020

C47D commented May 26, 2020

C47D commented Jun 4, 2020

barbiani commented Jun 9, 2020

C47D commented Jun 10, 2020 • edited Loading

embeddedt commented Jun 10, 2020 • edited Loading

barbiani commented Jun 10, 2020 • edited Loading

barbiani commented Jun 10, 2020

embeddedt commented Jun 10, 2020 • edited Loading

barbiani commented Jun 10, 2020 via email

C47D commented Apr 21, 2020 •

edited

Loading

C47D commented Apr 23, 2020 •

edited

Loading

kisvegabor commented Apr 24, 2020 •

edited

Loading

kisvegabor commented Apr 24, 2020 •

edited

Loading

persello commented May 8, 2020 •

edited

Loading

barbiani commented May 24, 2020 via email •

edited

Loading

C47D commented May 24, 2020 •

edited

Loading

barbiani commented May 25, 2020 •

edited

Loading

C47D commented Jun 10, 2020 •

edited

Loading

embeddedt commented Jun 10, 2020 •

edited

Loading

barbiani commented Jun 10, 2020 •

edited

Loading

embeddedt commented Jun 10, 2020 •

edited

Loading