Skip to content

Suitable for microcontroller onboard flash? #29

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

Open
kisielk opened this issue Feb 19, 2018 · 5 comments
Open

Suitable for microcontroller onboard flash? #29

kisielk opened this issue Feb 19, 2018 · 5 comments

Comments

@kisielk
Copy link

kisielk commented Feb 19, 2018

Is littlefs suitable to use with a microcontroller's onboard flash? Specifically on something like the STM32F4 series.

@geky
Copy link
Member

geky commented Feb 19, 2018

I know of at least 2 projects that are using littlefs on onboard flash successfully.

It depends on how much onboard flash you have. Each file in littlefs takes up at minimum 1 block (erase unit), each directory takes up 2 blocks, and the superblock takes up 4. It's a good idea to overallocate by ~1.5x so that the copy-on-write structures have room to move around, more based on how long you want to the device to last as the underlying blocks wear out (this simulation lets you try out scenarios).

Onboard flash is usually quite small compared to external flash, so the wasted space from 1 block per file may be a problem. I have some plans to improve this but it will take a while to implement. Other than that you should be fine.

Other notes about onboard vs external SPI flash:

  • Onboard flash usually has an order of magnitude fewer erase cycles (10,000 vs 100,000). You usually don't want to write to onboard flash often.
  • Writing (specifically erasing) may lock your device for ~100ms if you don't have separate flash banks. This can prevent interrupts that would otherwise be realtime.

If littlefs doesn't fit, SPIFFS is another filesystem in this space that's better optimized for very small storage, I've heard good things about it.

Let me know if that answers your question.

@kisielk
Copy link
Author

kisielk commented Feb 19, 2018

Thanks for the detailed answer. The 4 blocks required for the superblock would probably be the limiting factor for me. Usually I have 1 - 5 different types of information that need to be persisted, each of which would constitute a "file". On the F4's I'm using the sector size is around 128 KByte for the big sectors (5-15) where I store this data. Because there's so few sectors, having to sacrifice 4 of them just for the superblock would probably not work for all my applications.

The data is only written on explicit user request, so the longevity isn't as much of a concern.

@geky
Copy link
Member

geky commented Feb 19, 2018

Makes sense. Have you looked into SPIFFS? It doesn't have a superblock and stores files much more compactly. It sounds like it would fit your use case quite well.

@kisielk
Copy link
Author

kisielk commented Feb 19, 2018

I've used SPIFFs on a product with external QuadSPI flash, but haven't tried it on the internal one yet. I guess I should give it a try. Actually I was considering swapping the FS on that product for littlefs :)

@geky
Copy link
Member

geky commented Feb 22, 2018

Ah! That's exciting to hear

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

No branches or pull requests

2 participants