I have used 240*320 TFT display with 60Hz refresh frequency . I have created two screens .
Animation screen :
Created with GIF . No other objects are present in this screen.
I get 40 FPS and CPU load 60 - 65%
Timer handler function takes around 18ms.
Main screen :
It contains all typical cluster features like speedometer , tacho gauge , fuel gauge , trips .
In order to realize these features, I used customized images and lvgl container label to group the child’s on the screen.
I get 35 FPS and CPU Load 65% - 75%
Timer handler function takes around 25ms.
I have used FreeRTOS in my system where lv_tick_inc is called from task for every 5ms and timer handler called from separate task with 5ms periodicity.
Here problem statement is that As timer handler takes more time , tacho bar update behaviour is steppy . Screen transition takes 160ms time.
What MCU/Processor/Board and compiler are you using?
MCU - IMXRT1172AVM8A
Compiler - GCC
What LVGL version are you using?
LVGL version - 8.3.0
NXP Gui Guider - 3.0
What do you want to achieve?
If i get any possible ways to reduce the timer handler execution timing , that’s great. The excepted execution timing is less than 5ms.
What have you tried so far?
Double buffer method - As I have RAM Constraint , i couldn’t try this method.
Optimization level - O3 Which reduced timing from 50ms to 25ms.
Code to reproduce
Add a code snippet which can run in the simulator. It should contain only the relevant code that compiles without errors when separated from your main code base.
The code block(s) should be formatted like:
/*You code here*/
Screenshot and/or video
If possible, add screenshots and/or videos about the current state.
This is a late reply, but if you still have issues I hope it can be of some help…
Without being able to see how your application is implemented it is quite hard to speculate, which may be why no one has replied. Here are a few non-specific suggestions…
I have found from experience if your screen contains a large number of objects which are continuously updated you may be able to reduce the number of updates and improve the performance by only calling set functions when something changes. This created a drastic performance boost for my projects.
For example in my GUI’s I might have a the temperature of the system displayed but I only call lv_label_set_text_fmt() when the value changes.
So in the screen update routine I would have something like this…
double current_sys_temp;
lv_obj_t * sys_temp_label;
void update_screen1( void ) {
static double last_temp = 0; // Keep a copy of the previous value to check if it changed.
if( last_temp != current_sys_temp ) {
lv_label_set_text_fmt( sys_temp_label, "System Temperature: %.2f", current_sys_temp );
last_temp = current_sys_temp;
}
// More labels, text boxes and widgets to check and update here...
}
I hope that makes sense.
I also found a good way to optimise this and visualise what is actually being refreshed all the time is to enable the following option in lv_conf.h:
/*1: Draw random colored rectangles over the redrawn areas*/
#define LV_USE_REFR_DEBUG 1
(I apologise if you already know this but, be sure to rebuild and relink the library after this change!)
Whilst this completely destroys the performance of the system you can however see exactly what is being refreshed on the screen, I have some very complex large screens running at resolutions of 1440 x 900 pixels and this helped me to optimise them with ease.
To help you optimise your implementation of FreeRTOS with LVGL you may want to take a look at my post here which describes a reasonable methodology to use with FreeRTOS and LVGL, this has for my own purposes proven reliable and performant for two very large projects.