Goodbye SPIFFS, Hello LittleFS! - #53
Conversation
Updated config.cpp and config.h to use LittleFSs instead of SPIFFS.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 50004782ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Initialize LittleFS first (always available) | ||
| if (!LittleFS.begin(false)) { | ||
| Serial.println("[CONFIG] LittleFS mount failed, attempting format..."); | ||
| if (!LittleFS.begin(true)) { |
There was a problem hiding this comment.
On devices upgraded from an existing SPIFFS-based release, LittleFS.begin(false) will fail because the flash partition still contains a SPIFFS image; this new fallback immediately calls LittleFS.begin(true), which reformats that partition before loadPersonality() or the fallback config migration can read /personality.json, /porkchop.dat, or /porkchop.conf. Users without an SD copy, and all personality settings which are only stored in the internal FS, get reset to defaults on first boot, so the migration needs to read/copy the old SPIFFS data before enabling format-on-fail.
Useful? React with 👍 / 👎.
|
The tale is supposed to be funny, don't take me wrong 😄 |
|
I've tried fresh install of this fork to Cardputer Adv and discovered that personality data don't save, all settings drops to default values after restart. [boot] Turned on because (1= POWERON_RESET or 5==ESP_RST_DEEPSLEEP) (Other= Probably forced by launcher)--> 12 UPD: the error has gone after manualy creation of spiffs partition via M5Launcher PM. But. |
Launcher works better with merged binaries, so it can read the partition table and create whatever partition the firmware needs. As you used the "firmware.bin" to test, this partition wasn´t created, leading to that error you saw at first time This latest version of Launcher (2.7.2) has an issue.. It is not reusing the pre-existent "spiffs" partition if its size is different from a pre-determined size (0x70000), and it probaly prompted you to remove data, or doing something before install. So It has removed and recreated the "spiffs" partition if its size is not the predetermined size, not respecting the existent one, losing the config you made before. I have it fixed on Launcher Beta, for 2.8 that will come soon (today, I Hope) To enhance your test, you can try the merged binary by: |
"spiffs" partition i've manually created was exactly 0x70000 size but you're right: when I was installed the Bruce, PManager asked me to remove some data and than performed "optimize flash" - presumably that’s when it recreated the "spiffs" partition. |
2 participants
The Tale of the Overly Excited Porkchops
Once upon a time in the vast digital countryside, two neighboring farmers—Bruce and Meshtastic—shared a large, fertile plot of memory. Their fields were vast enough to cultivate all kinds of data and welcome new producers, provided everyone followed the same farming guidelines and land management system (the filesystem).
One day, a new farmer arrived at the estate with a lively herd of small pigs—the M5PORKCHOP project. The pigs were placed in their own corner of the farm (the SPIFFS partition), and quickly became a popular attraction. Visitors frequently toured the estate, stopping by the Bruce and Meshtastic fields before heading over to see the pigs.
The porkchops loved the attention. In fact, every time visitors arrived after exploring the rest of the farm, the pigs got so excited that they threw wild mud parties. They ran amok, knocked down fences, and inadvertently plowed over the entire shared estate—reformatting the land in such a chaotic way that neither Bruce nor Meshtastic could harvest their data anymore!
The farmers realized the problem wasn't the pigs—it was the fragile structure of the SPIFFS land management. To restore peace and ensure all producers could coexist safely, they decided to upgrade the entire estate to LittleFS. With LittleFS's sturdy fences and atomic land protection, even when the porkchops throw their wildest parties, the rest of the farm remains completely unharmed.
🚀 Why Switch from SPIFFS to LittleFS?
SPIFFS has served the ESP32 community well, but it has been officially deprecated in favor of LittleFS. Here is why this migration benefits M5PORKCHOP:
Power-Loss Resilience (Copy-on-Write): LittleFS uses atomic operations and a copy-on-write dynamic. If the device loses power or resets while writing a file, the filesystem rolls back to the last valid state instead of leaving a corrupted file behind.
Wear Leveling: LittleFS actively distributes write/erase cycles evenly across the flash memory sectors, significantly extending the lifespan of the onboard SPI flash chip.
Real Directory Support: Unlike SPIFFS, which simulates directories using flat filenames containing slashes (e.g., /folder/file.txt), LittleFS natively supports true directories and subdirectories, improving file lookup performance and structure.
Lower RAM Footprint: SPIFFS indexes the entire filesystem in RAM on mount, which grows with flash size. LittleFS utilizes dynamic indexing, keeping RAM usage much lower and predictable.
Faster Operations: Directory listings, file opens, and seeks are notably faster in LittleFS compared to SPIFFS on larger partition sizes.
And the most important thing.. While using Launcher, it won't lose data when moving back and forth from Meshtastic or Bruce, so nobody loses data. 😉
🛠️ Changes Included in this PR
Updated config.cpp and config.h to use LittleFSs instead of SPIFFS.
Updated file initialization and mounting logic.