You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now that LVGL has more accurate timing, we can use LVGL tasks to refresh apps instead of having DisplayApp do it. Using LVGL tasks to take care of refreshing lets each app choose the refresh rate, or not have it at all. Also it's better when less things are dependent on a task loop.
LVGL for some reason runs all tasks with higher priority again after a task with a lower priority has finished. The screen draw task is LV_TASK_PRIO_MID, so if the refresh task priority is lower than mid, it will redraw the screen. If the screen draw takes longer than the refresh period, the refresh task will be run again, which will run the screen draw again, resulting in an infinite loop and lv_task_handler() never returns. Because of this, the refresh task must be at least LV_TASK_PRIO_MID.
I think it would be better and a smaller patch to simply stop calling some DisplayApp's Refresh() on our own and let LVGL do it. Meaning that instead of a static void refresh(struct _lv_task_t* task) in every watchapp we could have a single one and just call the correct bool Refresh().
I think it would be better and a smaller patch to simply stop calling some DisplayApp's Refresh() on our own and let LVGL do it. Meaning that instead of a static void refresh(struct _lv_task_t* task) in every watchapp we could have a single one and just call the correct bool Refresh().
Good idea. I've now created RefreshTaskCallback(lv_task_t*) in the Screen class. I still wanted to make the Refresh functions void though as the return value doesn't matter any more.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Now that LVGL has more accurate timing, we can use LVGL tasks to refresh apps instead of having DisplayApp do it. Using LVGL tasks to take care of refreshing lets each app choose the refresh rate, or not have it at all. Also it's better when less things are dependent on a task loop.
LVGL for some reason runs all tasks with higher priority again after a task with a lower priority has finished. The screen draw task is
LV_TASK_PRIO_MID, so if the refresh task priority is lower than mid, it will redraw the screen. If the screen draw takes longer than the refresh period, the refresh task will be run again, which will run the screen draw again, resulting in an infinite loop andlv_task_handler()never returns. Because of this, the refresh task must be at least LV_TASK_PRIO_MID.