Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Feature: support both internal and external (SPI) flash in Storage module #1899

Open
fanoush opened this issue Jul 29, 2020 · 2 comments
Open

Feature: support both internal and external (SPI) flash in Storage module #1899

fanoush opened this issue Jul 29, 2020 · 2 comments

Comments

@fanoush
Copy link
Contributor

fanoush commented Jul 29, 2020

It would be nice to have both internal flash for code and also external SPI flash primarily for data supported by Storage module. Currently only one way (memory area, size) can be selected in board file.

Any ideas how this could be done with current Storage API or other modules? Was thinking file paths like "ext/filename" or maybe drives "int:filename", "ext:filename" with one of them being default and optional. Loading two storage modules would be a bit strange(?). Or could module accept parameters like require("Storage")("SPI") to pick the second one like this?

This could be usable for NRF52832 devices with SPI flash which only need SPI for data files but still have enough space for code in internal flash. Idea being that internal flash is faster and directly mapped so does not need extra RAM copy of data.

Would you merge stuff making Storage module more complicated like this? Or maybe some other full blown filesystem for SPI would be better than modifying Storage code?
@gfwilliams
Copy link
Member

Yes, this could be a good idea. Even on Bangle.js certain things (like the bootloader?) would probably benefit.

Internally I don't think it's a huge problem to have >1 set of start/end addresses for the functions (maybe easiest to just have 2 global variables that are constants if the feature isn't available).

In terms of choosing where files are, IMO "ext/filename" would be a mistake (unless you could then read the file with just "filename") as it doesn't give you the option of moving pre-existing files into internal flash to speed things up.

Maybe just an extra options argument to .write? Or a Storage.setWriteLocation(...)?

@fanoush
Copy link
Contributor Author

fanoush commented Jul 29, 2020

Oh, you mean the namespace would be shared and you would decide only when creating the file where it is located but then it would be unified view, so "file1" and "file2" could be each in different area. And when opening file you would search both areas. Well yes that could be used too and maybe would look or be simple to use (at first). Somehow I feel this could also produce complicated hard to understand cases - like file created in wrong place and filling it while there is still free space in the other. Or even file spanning both areas (as a bug or feature) behaving differently when different parts are read (also garbage collection or deleting files could be interesting in such case).

@fanoush fanoush mentioned this issue Oct 28, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gfwilliams @fanoush