-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Littlefs #162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Littlefs #162
Conversation
|
Thanks for this PR! As you may have noticed, I'm a bit late in the backlog of PR to review. Sorry for the delay. |
|
I'm awake all hours. Mostly I just wanted to get some clarity on where the project was headed. For this specific PR, what immediate usecases should a general purpose filesystem on Pinetime support? |
|
In my opinion, a first use-case will be the user settings. For now, we have only 1 settings : the display brightness. The value of this setting is keps in RAM so it's reset each time the watch reboots. Using a configuration file in the SPI flash would allow InfiniTime to restore this setting at each reboot. In the future, we can implement more user settings : screen orientation, 12/24 hour format, language, theme, advertising name on BLE,.. Other future use-can might be assets for applications : apps may need more storage for graphics, for example. Also, we'll need a non-free binary blob to enabled step counting on the motion sensor. As we cannot include this file in the source code, we could allow the user to send this configuration file over ble. Oh and a big one: dynamically loadable applications. For now, all apps are built into the binary. One day, if we manage to build dynamically loadable apps, we will want to send them over BLE to the SPI flash, and then load them into the internal flash to run them. |
|
tell me when you're available so that we can discuss some things. |
|
It's not easy for me to tell you when I'll be available, I work on the project on my free time, when work and family allows it ;) What control I desire over the source base. I'm not sure what you mean with "control" ? Yes, I review all PR carefully and merge them when I'm convinced that the code works, is coherent with the rest of the code and is understandable/maintainable. That's why I sometimes take a long time to review them... I'm not sure than now is the time for a big refactoring. In fact, I think I should try to share my views and plan for the short/medium term of InfiniTime, but basically, I would like to think about v 1.0 : a first minimal version that would be usable by the user. I'm not sure if dynamic applications should be a priority. However, that does not mean that you cannot work on it in the meantime. I guess that feature won't be a easy one and that it'll require a lot of thinking and work before we reach a usable state. |
|
I've just had a better look at this PR. If I understand it correctly, it add LittleFS to the project and provide a wrapper class? Could you explain the new CMake file you've added to the project? And why a new version of cmake must be installed in the Docker? |
|
The latest versions of CMake provide FetchContent which allows you to point to a repos and have CMake bring in the source/project. Unfortunately debian hasn't updated CMake versions in quite awhile, so the current apt package is too old (hence the Dockerfile update to bring in the latest CMake). As for architecture LittleFs is essentially an abstract class, and to port it to a hardware, you wire it up to a an implementation of program(), read(), erase(), sync() methods per the hardware. To make it C++ there is a shallow class wrapping of the lfs C methods and bind them to the implementation. |
|
Maybe this PR could be merged if I fork it and use submodules instead of cmake fetchcontent? This reduces the amount of variation in dependencies and lowers build environment requirements, though it might not be as nice as fetchcontent. |
|
Similar feature have been implemented and merged in #438, we can close this PR. |
let's chat more on discord....