It’s not really a project but it’s LvGL related. I’ve written an article on Medium describing in detail how to port LvGL to a monochrome display. The official blog already has something similar so I’ve opted not to write there.
1 Like
Excellent write-up! A lot of the information is also useful for color displays.
One suggestion: it’s a good idea not to call lv_tick_inc in the same loop as lv_task_handler, because the latter can take an inconsistent amount of time to execute, which will mess up the timing.
One suggestion: it’s a good idea not to call
lv_tick_incin the same loop aslv_task_handler, because the latter can take an inconsistent amount of time to execute, which will mess up the timing.
Interesting. Would it suffice to pass the correct elapsed time to lv_tick_inc? Say, instead of having a fixed delay in the loop using a function to ascertain how many milliseconds actually passed since the last call.
It’s usually simpler to just call it from a timer.
There are cases (as you’ve seen) where calling it in the same loop as lv_task_handler will work fine. However, we have seen several issues which end up being caused by using it in that manner. For maximal compatibility, just avoid putting them in the same loop. Use a timer interrupt or an OS task.
A second option is to leverage the LV_TICK_CUSTOM support if your platform has it. Using that removes the need to call lv_tick_inc.
That’s probably the option I will prefer to use, thank you
@Mattia_Maldini
Really awesome writing both technically and “literarily”! It’s easy to follow and good to read.
It’s great the there is LittelvGL post on medium too. 
1 Like
I am using 200hz timer interrupts but providing the time fetching function looks simpler. Any reason why not convert the code to use LV_TICK_CUSTOM?
EDIT: BTW, I do not use animation, LVGL tasks, etc.
If you can use LV_TICK_CUSTOM, there is no disadvantage to doing so.