1

In my project, i have some data to save permanently. After some research i got many examples and informations to do that with eeprom. I used it effectively. After all i decide to deep dive to esp8266 and i got some information about spiffs. Now i know what spiffs is and what its purpose. But i am wondering what is difference between eeprom vs spiffs? I know both of them using flash memory as same and we can write and store data with them but why spiffs? Why eeprom ? What are their pros and cons or etc.?

  • Thanks for the answers. I completed some missing parts about it – Dogan Cignakli Jan 9 at 3:28
2

I don't think it makes any difference from a hardware point of view. The benefits of using the eeprom library is that it avoids rewriting unchanged data (if you use spiffs you might want to implement that as well) and that the esp is compatible with the arduino environment, where there is a real eeprom.

On the other hand, SPIFFS has its advantages (e.g. easy upload, space). It's up to you...

| improve this answer | |
4

On the ESP8266 there's very little to choose from between the two. It all really boils down to what you want to store and how you best want to access it.

EEPROM emulation is ideal for small bits of data - configuration values and that sort of thing. Where you just want to store a few of values that would seldom change.

SPIFFS though is better at dealing with large amounts of data. Since it's a filesystem it can store actual files, and that makes it ideal for serving images and static data for web pages, for example.

A SPIFFS filesystem can be built on your PC from files of your choice and then uploaded over serial using mkspiffs and esptool.py or the SPIFFS tool that can be installed into the Arduino IDE. That means the files are very easy to update.

SPIFFS is not so great when it comes to writing data though - experiments have shown that it gets quite slow when writing often. EEPROM doesn't suffer from such a problem, but then you can't write as much data to EEPROM as you can to SPIFFS.

So that's really all there is to it. Neither is "better" than the other, but each is better suited to different ways of working or to different styles of data.

| improve this answer | |
2

I will also add a few more things:

SPIFFS acts like a String or Serial object -- so you can do a println() or whatever else you want, and read/parse it back out. There's also a digital-level access that lets you read or write memory structures directly, too. It is wear-leveled and is wonderful for anything where you need multiple independent configs or lots of (searchable!) data.

You can also upload files (or download them) from a web server, and most things that support Strings to write to can use a File as well (YMMV).

EEPROM is not (unless you specifically downloaded a 3rd-party library to do so) wear-leveled on this system and uses one sector of flash. Writing to it too often will cause the sector to fail (~10,000-100,000 times, so it's a lot though). You are also limited by the size of the sector, so the maximum size of the data you can store is 4096 bytes.

Furthermore, EEPROM is written like an array. All your data ends up in this array, and you have to keep track of where each piece is and how large it was (potentially across multiple libraries, files, or functions). Worse, you can't tell if you changed the format since it was last saved (reuploaded your code or something), so you really should have a checksum or something.


TL;DR: SPIFFS is larger (storable capacity and in terms of code to access) and wear-leveled. It has a lot of convenience features, and lets you write or compose complex data.

EEPROM is tiny and has a limitation on how many times it can be committed before it fails (bad for datalogging and stuff). At best you can write memory blocks to it.


Edit: SPIFFS has now been deprecated due to lack of support by the devs, which is somewhat sad. It has been replaced by LittleFS, which (annoyingly to me) has more overhead AND does not do static wear-leveling (it only wear-levels to free space when a file is edited/moved, and does not reuse memory consumed by files that don't change (even if those have by far the least wear)). The interface (aside from changing all instances to "LittleFS" instead of SPIFFS, and some other minor things) is largely the same to the user otherwise, however, so this post still applies.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.