Was just exploring this nodemcu thing i bot from amazon, and looked up spiffs. evidently it is a way to use memory like it was eeprom.
Came upon this term wear leveling, and was wondering, could this refer to a notion I had when using mega, that in order to not store data on the same place in eeprom and thus wear it out, had somebody come up with a way to move data around.
Yes, I know I would just continue reading and I will, but first I want to know if my guess was right. Because I had thought about doing something like that on my own. So I found it interesting that the idea was already there.
evidently it is a way to use memory like it was eeprom.
It is more like a way to use non volatile memory like a small filing system (Serial Peripheral Interface Flash File System)
but was i right about the were leveling part, as a way of spreading the usage of said memory?
sevenoutpinball:
but was i right about the were leveling part, as a way of spreading the usage of said memory?
That is what wear-leveling is for. But, wear-leveling is not something you can implement in a SPIFFS system. If there were to be wear-leveling, it would need to be handled by SPIFFS, not by you.
That's fine. I was just amused by the name. Interesting stuff
it's from GitHub
What spiffs does:
Specifically designed for low ram usage
Uses statically sized ram buffers, independent of number of files
Posix-like api: open, close, read, write, seek, stat, etc
It can run on any NOR flash, not only SPI flash - theoretically also on embedded flash of a microprocessor
Multiple spiffs configurations can run on same target - and even on same SPI flash device
Implements static wear leveling
Built in file system consistency checks
Highly configurable
What spiffs does not:
Presently, spiffs does not support directories. It produces a flat structure. Creating a file with path tmp/myfile.txt will create a file called tmp/myfile.txt instead of a myfile.txt under directory tmp.
It is not a realtime stack. One write operation might last much longer than another.
Poor scalability. Spiffs is intended for small memory devices - the normal sizes for SPI flashes. Going beyond ~128Mbyte is probably a bad idea. This is a side effect of the design goal to use as little ram as possible.
Presently, it does not detect or handle bad blocks.
One configuration, one binary. There's no generic spiffs binary that handles all types of configurations.