Hello,
I’m thinking of a project which will require me to use the wifi.h library with an ESP32 and also write some variables to EEPROM. Does the wifi.h library use the EEPROM to store the network details? If so, how do I make sure not to use the addresses that the wifi library uses when writing my own variables?
Don't think so.
On an ESP32 platform you don't use EEPROM btw, but for instance SPIFFS.
I recommend using the preferences library to store the Wifi credentials of your network.
Here's a tutorial that does just that.
The ESP32 does not have a EEPROM.
That may help in a way but I will still need to use the wifi.h library as it will be a commercial project and the wifi.h library creates a web portal for people to store their own wifi credentials, as I wont know them in advance, the wifi.h library I assume must store it in the 512 bytes of EEPROM, but the Perferences library must also use the same EEPROM so maybe the two are not compatible. Essentially I will be storing wifi credentials and also som very basic user entered data to the EEPROM. I may need to look through the library code to see if they both use the EEPROM and if they use the same addresses.
It does have 512 bytes of EEPROM flash memory
Please point out where in the documentation that you find that the ESP32 an EEPROM.
API Reference - ESP32 - — ESP-IDF Programming Guide latest documentation (espressif.com)
Why do you think the Wifi library uses the EEPROM? It does not.
The ESP32 does not have an EEPROM. The EEPROM library for the ESP32 simulates an EEPROM, but actually uses flash memory.
Preferences also uses flash memory.
Ah ok, my terminology is a little wrong, but still, if i use preferences library and wifi library, could there be an issue where they overwrite each other’s data in the flash storage? Or is there no risk of this?
No, because WiFi does not use flash memory. Why do you think it does?
Can you point us to where the wifi library for the ESP32 uses flash storage?
The ESP32 has a memory space for Core0, a memory storage space for core1 and a shared memory space. When the WiFi.h is used from the Arduino ESP32 core, core0's memory space gets allocated for WiFI.
The default core for setup() and loop() is core1 and core 1's memory space.
WiFi uses some of the shard memory space, If core1 is not using freeRTOS then core1 does not use the shared memory space.
When creating task and using WiFi, pin all tasks to core1. Core0 can be used for user defined tasks but it is not recommended when WIFi is in use.
The one place that data can be over written is when accessing the shared memory space with malloc and its like. When using malloc on the shared memory space use the ESP API's macro wrappers, see API Reference - ESP32 - — ESP-IDF Programming Guide latest documentation (espressif.com), ps_malloc and ps_calloc.
I have eaxmple code of the use of ps_calloc and ps_malloc. They work under the Arduino ESP32 core.
ETA, malloc is not aware of the ESP32's shared memory scheme, thus the reason for the macros.
ETA. There are other memory spaces available for the user such as RCT_SLOW and RTC_FAST. RTC SLOW memory can be used to pass data from the ULP processor to the main processor or have data persist across deep sleeps. While 8K of 32 bit RAM is available as RTC_SLOW ram the Arduino ESP32 core can only access 2K.
Sorry, I’m not explaining myself very well! I’m planning to use the wifi manager library (GitHub - tzapu/WiFiManager: ESP8266 WiFi Connection manager with web captive portal) with the preferences library, wifi manager will take the ssid and password via a web portal so I assume it must store that in flash memory?
The code is open source, so you could have a look. A quick glance suggests that they either use SPIFFS or NVS, and the main concern is that there's an 'erase' function that seems to erase all flash/nvs contents indiscriminately. I leave further digging up to you. Just keep in mind that non-volatile storage on ESP platforms works in a more sophisticated way than on entry-level Arduinos where you basically have to manually keep track of what is stored in which location. The ESP platform takes over this task and functions more or less like a simple file system (SPIFFS) or database (NVS).