Multi face support, analog clock, 12/24 config

[joaquimorg]

Changes made to this pull request:

• Possibility of having several watch faces, to change the watch face just make a long press on the watch.
• New analog watch face.
• Configuration to choose between 12h or 24h
• Added some color to the default digital clock
• New component to manage configurations and save generic states (Work in progress)
• Go back to the same menu page when we leave an app

[JF002]

Thanks for this high quality PR, @joaquimorg !
I reviewed most of it and it looks good to me!

Apart from a few formatting details, I have only 1 point of attention : bg_clock. If I understand correctly, it's the backgound of the analog clock (and it's quite beautiful!). But, as this is a 240*240px bitmap, it uses a bit of space (14KB). That's ok because we still have a bit of space available, but this new asset increases the total size of the FW to 397KB. Not an issue right now as we still have some room (the max size if ~460KB) buuuut... we are getting closer and closer to the limit!

I can see 2 ways to improve this :

• compress/RLE encode the bitmap so that it needs less space
• store it in the external spi flash memory.

I'm not saying it should be done in this PR as it works fine right now, but that's definitely something we'll have to think about in the near future to be able to add other watchfaces that also needs graphical assets.

I'll add some comments to fix the formatting issue and then we'll be able to fix the conflicts and merge :)

[joaquimorg]

Size really starts to be a problem, but we can only solve this when we are able to load this type of images from Flash.
I think that RLE does not work with LVGL, since it had to be written directly to the lcd or create a buffer which caused memory problems.

[JF002]

Size really starts to be a problem, but we can only solve this when we are able to load this type of images from Flash.
I think that RLE does not work with LVGL, since it had to be written directly to the lcd or create a buffer which caused memory problems.

I think it should be possible to use RLE with LVGL using the image encoder API. The doc say that we can implement a decoder than provides images line-by-line to lvgl, which is exactly how the RLE decoder I use works.

[joaquimorg]

Size really starts to be a problem, but we can only solve this when we are able to load this type of images from Flash.
I think that RLE does not work with LVGL, since it had to be written directly to the lcd or create a buffer which caused memory problems.

I think it should be possible to use RLE with LVGL using the image encoder API. The doc say that we can implement a decoder than provides images line-by-line to lvgl, which is exactly how the RLE decoder I use works.

I hadn't thought about that option.
What I have been trying to develop is a way to use the flash, and have a basic way of managing files, without using litefs, to save memory, the upload would be done via bluetooth of a zip with resources, these resources would be written in the flash where all the images, fonts, etc ... would be easier to customize the fonts and also the background images, without taking up space in the firmware.

[JF002]

What I have been trying to develop is a way to use the flash, and have a basic way of managing files, without using litefs, to save memory, the upload would be done via bluetooth of a zip with resources, these resources would be written in the flash where all the images, fonts, etc ... would be easier to customize the fonts and also the background images, without taking up space in the firmware.

Yes, that kind of features would be a better solution in the long term. Even with optimizations, we'll fill the whole internal memory one day or another :)

So you're implementing your own file system instead of using a lib like littlefs? Is there a reason? Or is Littlefs using a lot of (RAM?) memory?

Anyway, I'm interested in this feature, let us know when you have something to show us!

In the mean time, I'll try to finish the review of this PR, sorry for the delay !