Refactors watch faces. Replace lv_tick_get() with xTaskGetTickCount()

[SteveAmor]

Tested on hardware and all timings are the same.
Also saved some flash memory.

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	373056B	-32B
data	948B	0B
bss	22536B	0B

Run in InfiniEmu

[JF002]

@SteveAmor What's the rational behind this change? I'm not sure I understand why we should use xTaskGetTickCount() instead of lv_tick_get() in apps.

[mark9064]

They're the same tick counter, and I think it's confusing to have two. I think it makes sense to unify on one tick counter API, and the system tick counter is the better choice of the two as it's used everywhere else. Important things to know about the tick counter such as its bit width, signed-ness (and therefore wraparound semantics) and tick rate are well known and defined for the system tick counter

[JF002]

Since apps are mostly based on LVGL, I think that it would make more sense to use LVGL API as much as possible, and reduce the dependencies to other libs as much as possible.
In this case, lv_tick_get() effectively abstract FreeRTOS which makes the code more portable and consistent.

[mark9064]

I agree, but I think simplicity is more important than perfect coupling

In this case, we will need to implement a millisecond level timer, as LVGL only works in milliseconds and currently we provide it FreeRTOS ticks (1024Hz rather than 1000Hz)

[JF002]

Yes OK, that makes sense 👍 . I guess we can still hide FreeRTOS in a utility class that do all the calculations if we need that kind of abstraction in the future.

[NeroBurner]

I agree to use one timing related API makes things clearer. And if we use only one then that is the one that will get used by other contributors.
And for me personally I had more exposure to xTaskGetTickCount() than to lv_tick_get(). So just from a feeling perspective I would go with xTaskGetTickCount as well.

Changes look sane