Add LITTLEFS to ESP32 Builds
thomastech opened this issue · comments
SPIFFs is not recommended and has been replaced by LittleFS. With that in mind, LittleFS was added to ESPUI, which worked fine for ESP8266 builds. But ESP32 compiles failed, as reported in issue #94. So using compile directives it was removed from the ESP32 builds in a PR. Therefore ESP32 builds are back to using the outdated SPIFFS.
However, ESP32 supports LITTLEFS provided by the LittleFS_esp32 library. From my investigation the failed ESP32 compile issue was due to code syntax. The solution is to have ESP32 builds use "LITTLEFS" instead of "LittleFS". The text's case make a difference to the Arduino compiler.
That is to say, ALL appearances of "SPIFFS" need to use "LITTLEFS" instead. Even the header file. For example:
ESPUI.h file:
#if defined(ESP32)
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>
#include "LITTLEFS.h"
#include "WiFi.h"
#else
{snip snip}
ESPUI.cpp file (example snippet, there are several places that need updating):
#if defined(ESP32)
File root = LITTLEFS.open(dirname);
#else
{snip-snip}
The beginSPIFFS() function name should not change. This will preserve backwards compatibility with existing end-user programs.
Be sure to install the LittleFS_esp32 library.
TLDR; Restoring the LITTLEFS function to ESP32 builds is possible. Please consider adding it back to ESPUI.
- Thomas
For an example of the ESP32 LITTLEFS patch please see my zip file posted in issue #98.
- Thomas
Cool, I think I will do that
Hm... LITTLEFS has also been added to the v2 arduino core: https://github.com/espressif/arduino-esp32/tree/master/libraries/LittleFS
@thomastech I added your changes to master, could you please give it a quick try ?
I did revert the addition of the String&, as I am not really a fan of this change, it is breaking and I do not see the advantage of it...
Changes are live on master
Greetings
@s00500 Thank you for creating the PR, I appreciate it.
I successfully tested "pio_examples\gui" project on a ESP32 (ESP8266 compiles, but did not test). To successfully compile & run I had to make changes to the platformio.ino file.
Here is the revised platformio.ino file:
; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html
[platformio]
src_dir = ./src
data_dir = ../../data
[env]
lib_extra_dirs = ../../
board_build.filesystem = littlefs
extra_scripts =
LittleFSBuilder.py
[env:esp8266]
platform = espressif8266
framework = arduino
board = nodemcuv2
lib_deps =
bblanchon/ArduinoJson @ ^6.18.5
me-no-dev/ESP Async WebServer @ ^1.2.3
[env:esp32]
platform = espressif32
framework = arduino
board = esp32dev
lib_deps =
lorol/LittleFS_esp32@^1.0.6
bblanchon/ArduinoJson @ ^6.18.5
me-no-dev/ESP Async WebServer @ ^1.2.3
In the updated platformio.ini is an "extra_scripts" entry. The file it specifies is required for uploading littlefs formatted data files into FLASH. In other words, no need to use separate tools such as the ESPUI.prepareFileSystem() or ESP File uploader. Just use the "Upload File System" feature within PlatformIO.
To use the script there are two companion files that must be installed in the example project's root directory (same dir as platformio.ini), as follows
mklittlefs.exe
LittleFSBuilder.py
Files (and more info) available from here:
https://github.com/lorol/LITTLEFS/tree/master/examples/LITTLEFS_PlatformIO
To avoid unnecessary issue tickets I highly recommend you include the extra_scripts feature in the distribution. Without these changes the littlefs data files will fail if a user uses platformIO to upload them.
And I have a couple of unrelated bugs to report in case you want to fix them too. These bugs are in ALL the example projects (e.g., gui.ino, gui-generic-api, tabbedGui.
Correction # 1
Change this:
WiFi.mode(WIFI_AP);
WiFi.softAPConfig(apIP, apIP, IPAddress(255, 255, 255, 0));
WiFi.softAP(ssid);
To this:
WiFi.mode(WIFI_AP);
delay(100);
WiFi.softAPConfig(apIP, apIP, IPAddress(255, 255, 255, 0));
WiFi.softAP(hostname);
Correction # 2
Change this:
IPAddress apIP(192, 168, 1, 1);
To this:
IPAddress apIP(192, 168, 4, 1);
What do these changes accomplish?
The first correction fixes two issues.
[1] The 100mS delay is necessary because the WiFi stack isn't ready for WiFi.softAPConfig() until SYSTEM_EVENT_AP_START has been delivered (initiated by WiFi.mode() function). Without the delay the provided apIP arg is ignored and the AP defaults to 192.168.4.1.
[2] Using the ssid for the WiFi.softAP() arg can be confusing to the end-user. If ssid has the name of their router and it fails negotiating a connection then the AP will broadcast this same name when they search for the ESPUI hotspot. So when browsing the list of AP's to choose from it can appear to be the user's regular router. A unique name should be used instead. The hostname works well for this.
The second correction is needed because after fixing the WiFi.softAPConfig() problem described above, the provided apIP will no longer default to 192.168.4.1. So a network friendly apIP address needs to be used.
And as mentioned, I validated the code on a ESP32. Hopefully someone will volunteer to check it on a ESP8266.
- Thomas
In retrospect I should have created a separate github issue ticket for the code fixes in the ESPUI Example projects. If you want me to do that then just let me know.
- Thomas
Hey @thomastech,
Looks like great fixes, could you create a PR for them ?
Looks like great fixes, could you create a PR for them ?
I'm a github amateur. So leaving this up to me will probably take a lot longer than usual. But when my current project is finished I will try. Hopefully someone else beats me to it.
- Thomas
Ok, I added some of the changes,
As for the ip issue: I never experienced it to use 192.168.4.1, it was always available on 1.1 for me... not sure why, but changing to 192.168.4.1 makes more sense in the context of the ESP as it is the default
As for the ssid issue: good catch from a usability side! I changed it to not use the hostname though, but a generated SSID from the chipID, users can always adapt this later but I think it is a nice default, so multiple devices get different SSIDs
Thank you for updating the example project. Are you still interested in having me create a PR for Platformio's LittleFS file upload changes (LittleFSBuilder.py)?
- Thomas
OK, understood. Thanks again for the PR.
- Thomas
You can replace all the instance of LITTLEFS with LittleFS in espui.cpp
and in espui.h #include "LittleFS.h" instead of #include "LITTLEFS.h"
You can replace all the instance of LITTLEFS with LittleFS in espui.cpp
and in espui.h #include "LittleFS.h" instead of #include "LITTLEFS.h"
LittleFS.h is needed for ESP8266
LITTLEFS.h is needed for ESP32
The latest ESPUI release handles both library versions. That is to say, the depreciated SPIFFS has been replaced with "littlefs" on both platforms.
- Thomas