InfiniTime VS littlefs

New releases are available here: https://github.com/InfiniTimeOrg/InfiniTime/releases/

The PineTime is a great smartwatch if your main use cases are checking the time and displaying new notifications from your phone. The build quality is great and the hardware is very similar to the original Fitbit Versa. Battery life varies with use, and I get about 5-7 days on a charge.

The most well-maintained OS for the PineTime is InfiniTime:

https://github.com/InfiniTimeOrg/InfiniTime

I'm not aware of any major brands that offer account free service.

As far as I know, Tizen smart watches can function well on their own after setting up the account once and I believe cloud synchronization is optional. However, Tizen is a dead end with Samsung getting back to Android Wearable.

There's PineTime (https://www.pine64.org/pinetime/), which is very barebones but open source. Popular firmware, such as InfiniTime (https://github.com/InfiniTimeOrg/InfiniTime) can also be flashed onto several smart watches available on your favourite Chinese import stores (for example: https://github.com/StarGate01/p8b-infinitime for the Colmi P8).

Read further about the new update and grab it for your PineTime here: https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.12.0

Ticket opened here: https://github.com/InfiniTimeOrg/InfiniTime/issues/1724

Pointers correctly round-trip through unrelated pointer types, provided the alignment for both types is compatible.

At least one bit does look a bit questionable: lfs_mlist is treated as the common initial sequence of lfs_dir and lfs_file, even though it isn't, and common initial sequences only apply to union fields anyway. Example cast of struct dir * to struct lfs_mlist * (probably valid of itself, assuming the alignment is compatible): https://github.com/littlefs-project/littlefs/blob/c733d9ec57... then use struct dir as if it were actually a struct lfs_mlist: https://github.com/littlefs-project/littlefs/blob/c733d9ec57...

(There's other occurrences of the same kind of thing.)

Strictly speaking, I think this might be unfixable without a bunch of work, but so much stuff does this kind of operation that any compiler that doesn't do what you expect will have been fixed by now. (Assuming you're not one of those people who is going to pop up and tell us with a straight face that what we should expect is for the compiler to do absolutely anything - except, perhaps, for having it generate correct code, which would be defective behaviour that should be eliminated.) Maybe improve the odds by using lfs_mlist as the common initial sequence of both structs, and fingers crossed that the compiler considers the union rules to apply to this case too. Or compile with -fno-strict-aliasing.

Also, it looks like you're writing to the flash every second the engine is running. Do you have an idea of what the endurance of that might be? I'm not too familiar with this but supposedly the flash on the Pico is good for at least 100K program/erase cycles and Micropython uses LittleFS on RP2040 which does wear leveling. I looked for more official info and the rp2 port code backs that up with a note: "the flash requires the programming size to be aligned to 256 bytes". And the littlefs readme does say it does wear leveling and other good stuff.

Maybe first go and localize which assumption has been voided, i.e. what of the many places in littlefs that raise this error actually raise it? And... erm... what littlefs are you talking about? https://github.com/littlefs-project/littlefs doesn't seem to have a fs_close() function...

Rather easy to add LittleFS for file storage onto the NOR flash. https://github.com/littlefs-project/littlefs