ESP8266 Community Forum

- Sat Apr 18, 2020 8:55 am #86640 ok thanks!!!
if this is the case I definitely prefer the SPIFFS way to the EEPROM way of managing data.

- Sat Apr 18, 2020 10:29 pm #86656

ok thanks!!!
if this is the case I definitely prefer the SPIFFS way to the EEPROM way of managing data.

This sentence is still not quite right - there are multiple ways you can manage persistent data in your ESP module, but they all require you to set aside an area of the flash (aka EEPROM in this conversation but you are better off calling it flash) to be used specifically for storage.

As mentioned before, the ESP is able to address up to 1M of flash at any one time as your program/code space. The ESP bootloader maps this area to addresses starting from 0x000000 and that's where your compiled code is set up and linked. The standard ESP bootloader lets you define two of these program areas - one at the start of flash, and one half way through the flash (two equal partitions). This is how it does its Over The Air (OTA) firmware updates - it runs from one partition and writes the downloaded firmware into the other one, then reboots into the newly written code partition.

In reality you can actually have as many program areas as you want, and there is an advanced bootloader called rboot that manages up to 256 program areas of different sizes (up to 1M), which gives you a lot of flexibility. I use this to have a device setup program and two OTA firmware partitions. The device setup gets used when the device is booted for the first time and it sets up and registers the device, then it tells the ESP to reboot into the main program partition and that's what runs from that point on.

Any flash memory that you are not using for program space can be used for persistent storage. This includes the top end of your program space if you are using the standard bootloader and don't use the whole 1M for code. You address this empty space with an unsigned 32bit integer, so that gives you the ability to read and write to the entire flash from within your program.

The ESP SDKs provide functions that allow you to manually read, write and erase the flash - you can read and write the flash along 4 byte boundaries, but you can only erase the flash in 4kB sectors, so you allocate your storage on 4kB sector boundaries within your flash, but you can then read and write to it in bytes.

There are several libraries out there that use these underlying functions but make them more user friendly, and SPIFFS is one of those. SPIFFS uses these low level functions to manage a region of flash that you define as if it was a file system, and then lets you create, open, read, write and delete text or binary 'files' in this space. SPIFFS is particularly useful for setting up a mini web server with HTML files that you want to serve up.

I wrote a library that works like a journal file system or database - it lets you read and write data structures to the flash instead of files. This is useful for storing configuration data or offline sensor readings etc. You can find it here: https://www.esp8266.com/viewtopic.php?f=166&t=19530

So in the end, when you say you prefer the SPIFFS way rather than the EEPROM way, what you're really meaning is that you prefer to use the higher level SPIFFS functions instead of the low level flash read/write functions, but there are several approaches out there that may be better than SPIFFS depending on what you are trying to do.

You also haven't mentioned what you are using to program the ESP8266 - if you're using Arduino then there are both SPIFFS and raw data reading libraries available for the ESP. IF you're using NonOS or RTOS then you can use SPIFFS or the code I posted above

- Sun Apr 19, 2020 7:08 am #86659

ok thanks!!!
if this is the case I definitely prefer the SPIFFS way to the EEPROM way of managing data.

This sentence is still not quite right - there are multiple ways you can manage persistent data in your ESP module, but they all require you to set aside an area of the flash (aka EEPROM in this conversation but you are better off calling it flash) to be used specifically for storage.

As mentioned before, the ESP is able to address up to 1M of flash at any one time as your program/code space. The ESP bootloader maps this area to addresses starting from 0x000000 and that's where your compiled code is set up and linked. The standard ESP bootloader lets you define two of these program areas - one at the start of flash, and one half way through the flash (two equal partitions). This is how it does its Over The Air (OTA) firmware updates - it runs from one partition and writes the downloaded firmware into the other one, then reboots into the newly written code partition.

In reality you can actually have as many program areas as you want, and there is an advanced bootloader called rboot that manages up to 256 program areas of different sizes (up to 1M), which gives you a lot of flexibility. I use this to have a device setup program and two OTA firmware partitions. The device setup gets used when the device is booted for the first time and it sets up and registers the device, then it tells the ESP to reboot into the main program partition and that's what runs from that point on.

Any flash memory that you are not using for program space can be used for persistent storage. This includes the top end of your program space if you are using the standard bootloader and don't use the whole 1M for code. You address this empty space with an unsigned 32bit integer, so that gives you the ability to read and write to the entire flash from within your program.

The ESP SDKs provide functions that allow you to manually read, write and erase the flash - you can read and write the flash along 4 byte boundaries, but you can only erase the flash in 4kB sectors, so you allocate your storage on 4kB sector boundaries within your flash, but you can then read and write to it in bytes.

There are several libraries out there that use these underlying functions but make them more user friendly, and SPIFFS is one of those. SPIFFS uses these low level functions to manage a region of flash that you define as if it was a file system, and then lets you create, open, read, write and delete text or binary 'files' in this space. SPIFFS is particularly useful for setting up a mini web server with HTML files that you want to serve up.

I wrote a library that works like a journal file system or database - it lets you read and write data structures to the flash instead of files. This is useful for storing configuration data or offline sensor readings etc. You can find it here: https://www.esp8266.com/viewtopic.php?f=166&t=19530

So in the end, when you say you prefer the SPIFFS way rather than the EEPROM way, what you're really meaning is that you prefer to use the higher level SPIFFS functions instead of the low level flash read/write functions, but there are several approaches out there that may be better than SPIFFS depending on what you are trying to do.

You also haven't mentioned what you are using to program the ESP8266 - if you're using Arduino then there are both SPIFFS and raw data reading libraries available for the ESP. IF you're using NonOS or RTOS then you can use SPIFFS or the code I posted above

Wow man thanks for the answer, I really appreciate it.
I'm using Arduino it's simple and portable, I'm a noob and still not understanding why use rtos or nonos over arduino.

What are the real benefits of nonos or rtos over the arduino way?

Thanks

- Sun Apr 19, 2020 9:37 am #86661 BTW might it not be clear by now: "EEPROM" is something unique to Arduino, not to ESP8266. The ESP8266 does NOT have EEPROM. Arduino can emulate the EEPROM found on other microcontrollers while using FLASH. I am not too sure whether you'd want to, because EEPROM is generally very small and limited. I guess it's used to run existing Arduino stuff designed for other microcontrollers.