-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port to LVGL v7.0 #101
Comments
It's in
It's in
It'd be best to create a new one based on Could you make a build test to see if there are any serious issues? |
I will do the tests here: https://github.com/C47D/lv_port_esp32_v7 |
What is the size and resolution of the display and LV_DPI? |
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. Besides, please modify |
The LCD size is 3.2" (inches), ok I will modify |
So the actual DPI is: `sqrt(320^2 + 240^2) / 3.2 = 125. If you set to |
Awesome, thank you! You can enable |
I'm getting 33FPS, with CPU from 18% to 28% and peaks of 34%. |
@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). |
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. |
@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. |
Hi, I took a video of the demo using the test/no-tp branch. |
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:
|
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. |
I also saw this happen once on my STM32F7, but I didn't have time to investigate further. It was a few days ago. |
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 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 |
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 I suspect the latest because |
I suggest running the |
I call |
Ah, good to know. I thought you are using the DMA based |
I call |
@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. |
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 |
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. |
@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 :/. |
I think I found the issue but the picture is not perfect yet. These are the interesting parts of
So it's a typical Read-Modify-Write issue. I've pushed a trivial fix. Let's see if it helps. |
It looks really helpful, thanks for the PR, hopefully more to come :) |
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>
.
|
@C47D |
No, I haven't. Did you tried to? |
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>
.
|
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 |
I would not add the note until someone figures it out. The cores should be the same. |
I would guess that there's another task running on the APP_CPU that we're unaware of. |
I've found these topics |
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:
|
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? |
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>
.
|
Maybe #136 is related? |
@barbiani Could you review it? I don't have access to my pc to test it right now |
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. |
What I am experiencing is that I get better performance when lv_task_handler() is scheduled on core 0. |
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. |
Closed with #110 being merged into master. Further performance improvements can be discussed in new issues. |
A small optimization to prevent uneeded context switches.
|
Nice to see that LVGL feature being used, thanks for the tip @barbiani :), mind to send a pull request for it? |
I'd add |
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. |
I am using 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. |
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>
.
|
ST7789: Fix data length overflow on `send_color` by changing the length parameter from uint16_t to size_t
List of necessary changes:
The text was updated successfully, but these errors were encountered: