Dynamic apps and custom watchfaces

[JF002]

Verification

• I searched for similar feature request and found none was relevant.

Pitch us your idea!

I want to install new watchfaces and apps without flashing the whole firmware

Description

InfiniTime is currently a monolithic firmware : everything is built into a single binary file : OS, drivers, applications & watchfaces, fonts, pictures,...

This feature request is about adding the possibility to create and install new watchfaces and app without having to rebuild and flash the whole firmware.

InfiniTime is not quite ready yet to support these features, but we are slowly but surely moving forward to that:

• The PineTime is equipped with a huge 4MB SPI flash memory
• We've already implemented a filesystem (based on LittleFS on that SPI flash memory
• We've also implemented a BLE FS API to allow companion apps to access to this FS via BLE
• We are working on [moving assets fonts and picture to that external memory

There's of course still a lot of researches, experiments and work to do before we can enable dynamic app and custom watchfaces.

Over the time, a few feature requests on this topic were opened, and I create this one to group them all.
Those existing feature requests are :

• API for plugins? #113
• Adding the ability to change the watch face without reflashing InfiniTime #421
• Add a way to make customized watch faces #755
• Support more than four watch faces #1055

[Elara6331]

I had an idea for this a while ago. It may be possible to use WebAssembly for this. Searching online, I see that there are a few projects that have successfully run WASM on microcontrollers. It will be slower than native, but if it can be done, should be an improvement over something like MicroPython. My concern would be memory usage, but I don't know just how much memory it uses.

There seems to be an example for ESP-IDF here, which uses FreeRTOS: https://github.com/bytecodealliance/wasm-micro-runtime/tree/main/product-mini/platforms/esp-idf. I'm not sure how applicable it would be to InfiniTime, but it might be useful.

Obviously, native code would be preferable, but I'm just not sure how to accomplish that without having to recompile every time you add something.

[Tiggilyboo]

If a binary can be transferred to the SPI memory via the BLE service and then executed directly on the watch, this would be ideal for performance without the VM / dynamic code execution baggage, nor additional compilation or interpreter overhead.

The question though still remains on how to "execute directly" from the FS?

Since the platform is FreeRTOS, the only way I can think of is through static linking (I don't think FreeRTOS can do dynamic linking). So how might this be approached? One such design could implement a lookup table of addresses (slots) which point to a point of flash memory to load. Each slot could follow a structure / API which must be followed (via some header for this purpose) in order to load / unload, access lvgl and underlying services.

Looking forward to seeing what people come up with on this, exciting times ahead!

[Elara6331]

Of course, as I said, native code is preferable. However, I think its implementation, if possible, would be A LOT more complex and while the performance of WASM would be lower, I think that it would be a lot easier to implement, which would increase maintainability in the future and decrease the amount of bugs both because of the easier to understand implementation, and because WASM is already a relatively mature standard.

Another issue is that I would prefer not having to load a header or anything else that is language-dependent at all as that would make it more difficult if not impossible to use languages like Rust and TinyGo to make apps for InfiniTime.

[lvlgl]

Should the dynamic apps be as capable as standalone apps are? It could be done with an external Android app which has a UI builder for PineTime and a Scratch-like interface to program actions/transitions between screens

[toastom]

I'm currently working on a tool that does involve the recompilation of InfiniTime, although it more easily allows the user to choose which apps and watchfaces they want to include in the build. The result will hopefully allow people to create a less bloated system to save memory for other larger or less memory-efficient apps and resources (tons of pictures and fonts?). It's still in the ridiculously early stages right now (not at all functional) and I'm no expert in bash or CMake, but the idea is to simply run a bash script and have it simply not include some user-defined apps in the build. It's called "infinitweaks" right now. Again, I just started this so it doesn't function but that's the idea.

[NeroBurner]

I think infinitweaks could be implemented purely in CMake configured by cmake-options. We can add compile defines and add the source files to the main target with target_sources()

[hrmckay]

With the Pebble watch you could (still can) download watch faces and apps. In my opinion this ability was what made the Pebble so popular, a lot of amazing faces and apps were created. There were four major ways to create a watch face or app.

1. Download the SDK, compiler, libraries and follow the documentation to build an app or watch face.
2. Use the Watch Face Generator, a web site which is now gone, to build a watch face by moving elements like the time, day of the week, etc into place on the watch face, add some personal elements like background pictures, and let the web site build the watch face and download it for you.
3. Use an Android app called Canvas to build a watch face similar to the way the Watch Face Generator did, or like the current Android apps like Facer or Watchmaker.
4. Use a web site called CloudPebble, which is now gone, to create a watch face or an app by writing C code in a web based editor (or you could upload the code) and then letting the web site compile it with the proper libraries and download it. Much easier then option 1.

Excellent documentation was supplied online.

[Avamander]

Side-note: This has been discussed a few times in the InfiniTime chat rooms. I do recommend searching for relevant keywords to find valuable info about. One potential approach not listed here are PIC functions copied dynamically into internal flash and then executed. Something akin to the PIC approach described in this blog post: https://mcuoneclipse.com/2021/06/05/position-independent-code-with-gcc-for-arm-cortex-m/