Skip to content

Conversation

@redengin
Copy link

let's chat more on discord....

@JF002
Copy link
Collaborator

JF002 commented Jan 12, 2021

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.
Is there something specific you would like to talk about on Discord? It looks like you are active on the chat when I'm sleeping, so I'm not sure our timezones will allow direct communication ;)

@redengin
Copy link
Author

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?

@redengin redengin mentioned this pull request Jan 13, 2021
@JF002
Copy link
Collaborator

JF002 commented Jan 13, 2021

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.

@redengin
Copy link
Author

tell me when you're available so that we can discuss some things.
I want to better understand what control you desire over the current source base.
I want to refactor the current source base to leverage upstream changes.
I want to refactor the current system to fully leverage threading and support dynamic applications.

@JF002
Copy link
Collaborator

JF002 commented Jan 19, 2021

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 ;)
You can use this issue (or a more specific one) if you want to discuss about the project if you want.

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.

@JF002
Copy link
Collaborator

JF002 commented Jan 19, 2021

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?

@redengin
Copy link
Author

redengin commented Jan 20, 2021

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.

@Avamander
Copy link
Collaborator

@JF002

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.

@JF002
Copy link
Collaborator

JF002 commented Jul 13, 2021

Similar feature have been implemented and merged in #438, we can close this PR.

@JF002 JF002 closed this Jul 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants