For context, I have my project using LVGL v9.5 with FreeRTOS and LV_USE_OS == LV_OS_FREERTOS.
Until recently, I also had #define LV_USE_FREERTOS_TASK_NOTIFY 1
The project also has a dedicated LVGL thread, and access to LVGL is controlled using the now-exposed lv_lock/lv_unlock
Internally, we control the pace of the LVGL thread using Task Notifications for things such as FSync calls, “thread exit” signals, as well as controlling the pacing of lv_timer_handler.
However, we started to notice that sometimes the LvglThread would be signalled with a pulNotificationValue(from xTaskNotifyWait) matching our exitFlag. However, the signal wasn’t coming from us.
Upon further investigation, I noticed that the random signals were set by either lv_thread_sync_signal or lv_thread_sync_signal_isr implemented by lv_freertos.c.
#1 In summary, when enabling LV_USE_FREERTOS_TASK_NOTIFYthe current implementation of lv_thread_sync_signal_isr and lv_thread_sync_signal will signal the calling task in a way that, in scenarios like mine, will conflict with external usage.
#2 Another concern that I have is that the use of xTaskGetCurrentTaskHandlein lv_thread_sync_waitcould result in LVGL consuming Thread Notifications of “third-party” tasks if, for whatever reason, this call ends up being made in the context of a thread other than a thread “owned” by LVGL (not sure if this call is possible at the moment, but it does require manual tracing to ensure that it doesn’t “leak”).
I’m still working through this situation (for now I’m back to LV_USE_FREERTOS_TASK_NOTIFY 0but I would like help understanding all the contexts where LVGL will use Task Notifications and finding solutions so we can address #1 and ensure #2 doesn’t happen.
I think that for #1, we should make it abundantly clear that by enabling LV_USE_FREERTOS_TASK_NOTIFY, as of now, the user is giving up usage of “Task Notification”.
As a solution, I propose using the Indexed version of Task Notifications that is supported as of FreeRTOSv10.4.1+. When available, enabling LV_USE_FREERTOS_TASK_NOTIFYshould also offer the user an additional define to set the TaskNotify Index that is to be used by LVGL.
This would enable both “User” and LVGL to leverage Task Notifications.
As for #2 I think it requires a deeper dive and/or runtime checks to enforce that only LVGL-owned tasks are being operated.
Please let me know your thoughts.