Using LittleFS with ESP32 but app still compiles with SPIFFS+LittleFS #471
Replies: 4 comments 8 replies
-
|
@HankLloydRight The problem you are encountering is due to the difference between the version of the LittleFS library that had integrated into the ESP32 core 2.0 and an ordinary version published on the ESP32 LittleFS repository. The original LittleFS_esp32 deploys Little FS class and instance as fs::LITTLEFSFS and LITTLEFS: https://github.com/lorol/LITTLEFS/blob/f0817ca5264745acce697092de2bf218b3aa5b2e/src/LITTLEFS.h#L39 On the other hand, in ESP32 Core 2.0, they are declared as fs::LittleFSFS and LittleFS: https://github.com/espressif/arduino-esp32/blob/c2e5957f35b0441e7c954e247437456fabe3800f/libraries/LittleFS/src/LittleFS.h#L39 This change in the ESP32 core 2.0 was made to ensure compatibility with the ESP8266, but as a result, backward compatibility with legacy code for LittleFS_esp32 has been lost. This problem does not occur when building in the Arduino IDE environment because it assumes that LittleFS is integrated with the ESP32 2.0 core. And its class and instance are I temporarily implemented a way to absorb the above gap in the AutoConnect library to support ESP32 LittleFS in AutoConnect and PageBuilder, but eventually dropped it. That's because we estimated that it would not take much time for PlatformIO to support ESP32 core 2.0. How to avoid the problem for now:You will need to employ one of the following two methods. The following workarounds have their limitations. Those limitations will be lifted in the next release as AutoConnect v1.3.4 and PageBuilder v 1.5.3.
|
Beta Was this translation helpful? Give feedback.
-
|
Wow, thank you Hieromon! You are the best. Thanks for the extremely detailed explanation. Since I don't use the Arduino IDE and only use Platform.io, it seems that Option #1 is the way to go. (modify AutoConnectFS.h and PageBuilder.h) I made those changes and now the code compiles cleanly and my code size went down about 29k. No change in free stack space though. Interestingly, the SPIFFS library is still in the dependency tree. It's remained unchanged from what I posted above. Is that expected? |
Beta Was this translation helpful? Give feedback.
-
In the past, I have also found spiffs in the dependency tree output by PIO and wondered about it. But that seems to be the specification of the PIO Library Dependency Finder (LDF). If
And also, PIO determines what to compile based on its own detection, so After building the project, start the Inspector, open Symbols search and search for spiffs. You will see that the firmware does not contain any spiffs. And you do the same search using littlefs as a keyword, you will see that littlefs is present in some of the text sections. |
Beta Was this translation helpful? Give feedback.
-
|
Hieromon, I turned off But you're right, in the inspector I didn't find any references to SPIFF when I run the Memory Inspector/Symbols. Do you take any contributions for your work or a preferred charity for donations? |
Beta Was this translation helpful? Give feedback.
-
|
@HankLloydRight Thank you for appreciating my work. Fortunately, at the present time, I am earning enough to stay healthy with my family through my regular job. Therefore, for the time being, I am able to continue to maintain and enhance the library without any donations. Of course, tomorrow never knows. What I expect to most users is the sharing of knowledge. The AutoConnect source code is not so elegant. Also, AutoConnectAux's method of accessing AutoConnectElements does not fully utilize the capabilities of C++. This is largely due to the limitations of statically-typed languages, which must be able to be deployed in the limited memory space of the ESP32 and ESP8266, which can be difficult for users who primarily use Arduino as their programming framework. I would also like to hear from general Arduino users to provide use cases they are experiencing. It will bring me new discoveries and a strong motivation to develop even better libraries. I expect you to provide it to me. You have taught me the following through this topic: "AutoConnect needs to support the legacy LittleFS_esp32 in ESP32 core 1.0.6 with PIO." Without your contribution, I would not have supported the legacy LittleFS_esp32 library in ESP32 core 1.0.6. Its discussion in my mind was already over. However, your post may have saved other users. It's only a possibility, though. But I find that very valuable. Thank you for your contribution. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to show you what I'm working on using your libraries: https://ildac32.com/ thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Awesome!, Thank you inform to me. In addition to being capable as a standalone ILDA player, it can be controlled interactively using a cell phone! I'm happy to contribute to the high degree project like you're making. By the way, observing the video you introduced, I assume that the ILDAC-32 will encounter a situation where it loses WiFi connection during WiFi control. Do you use AutoConnectConfig::autoReconnect with reconnectInterval? Does it work as expected for you? |
Beta Was this translation helpful? Give feedback.
-
|
Support for the LittleFS_esp32 legacy library in ESP32 core 1.0.6 has been released as AutoConnect v1.3.4 and PageBuilder 1.5.3. |
Beta Was this translation helpful? Give feedback.
-
|
@HankLloydRight Hello, Today I have something to let you know. The platform-espressif32 platform maintains compatibility with ESP32 Arduino Core 2.0. So the LittleFS_esp32 library installed individually in the Arduino library folder is no longer needed. And if it is left behind, PlatformIO's LDF will detect the LittleFS_esp32, which is supposed to be a residue. Upon that detection, the FS class is expanded to LITTLEFS. In other words, the FS class will be expanded to LITTLEFS prior to 2.0.0 (which is legacy), even though it is a library dependency for Arduino Core 2.0.0 or later, resulting in a compile error for AutoConnect. This error can be resolved by simply deleting the LittleFS_esp32 folder from the Arduino library folder. If you are already aware of this, then my concern is unfounded. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Hello.. Thank you. I was not aware of the new espressif32 4.2.0 platform. I upgraded my project to espressif32 4.2.0 and Autoconnect 1.3.4 and changed a few lines of code and it compiled and ran. But the bigger problem I have now (unrelated to Autoconnect) is that my interrupt loop and CPU pinned loops are totally messed up. Before the upgrade using espressif32 @ 3.5.0, I had CPU1 handling all the user interface I/O, SD card I/O, Wifi, and BLE I/O while CPU0 was only sending data points to the DACs at 30khz-70khz. I am using an interrupt timer by setting a timerBegin with timerAttachInterrupt, timerAlarmWrite, and timerAlarmEnable to fire the function to send data to the DAC, and it was working perfectly and an extremely stable interrupt clock. But once I upgraded to 4.2.0, the loop timing is very unstable and now crashes when I go to change the interrupt timers. Something between 3.5.0 and 4.2.0 totally changed how internal tasks are assigned to CPU0 and CPU1, and it totally wrecked my stable running project. I just downgraded to [email protected] and back to the legacy LITTLEFS (and Autoconnect 1.3.4) and all is restored back to the previous state with my project. But I have no idea how to go about debugging the new framework to solve these problems. I think I'll have to pin future development to [email protected]. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @HankLloydRight, I was a little curious about your mention of the poor performance of the peripheral, so I did some research. I have not yet been able to fully identify the factors, but I will tell you that I have found something that may be relevant to this topic. In other words, are the peripheral libraries that your project depends on really thread-safe? That is, as long as the CPU is running in a pseudo task slice, it doesn't matter. Direct reading of registers is the most extreme of that. Essentially, the peripheral read process should be separate from the writing process. Before processing a read, we need to confirm the commit of the write transaction (usually surrounded by beginTransaction and endTransaction). As a result of the adoption of ESP-IDF 4.4 in Arduino Core 2.0.2, thread-safe and asynchronization transactions are required assuming a complete IRQ drive. I've seen many Arduino libraries with their own wild logic that doesn't follow that approach. (Even that are well-known and frequently used) And I have observed that many of the libraries distributed with the esp32-arduino core 2.0.2 and later have been rewritten to be thread-safe using semaphores and MUTEX. If the loop timing instability you are encountering is the result of access to the periphery being refactored to an IRQ-driven model, then the timer interrupt technique will not solve the problem. It would require transaction-based asynchronization. This could force a significant change in the structure of your project, but the only benefit you would gain from it would probably be a long-term service of IDF 4.4. (Espressif has already ended support for the IDF 3.x series) |
Beta Was this translation helpful? Give feedback.
-
|
@Hieromon -- Your knowledge, insight, and willingness to help people is phenomenal. I can't thank you enough. What you described is a little beyond my knowledge base, but I think it totally hits the nail on the head. Let me elaborate: In my project, I'm using 4 12-bit SPI DACs (MCP4922) to send analog data to the laser projector. Bit banging in this case is actually much faster then hardware SPI. When I started out, I was using this github library https://github.com/RobTillaart/MCP_DAC to communicate with the DACs. But his library is for generic Arduino projects and uses analogWrite(), which is very slow and did not provide the performance I wanted, but his code is portable. So I took his code and changed it to use direct register writes on the ESP32 like this: Initialization code: And then these functions to write to the DACs on those pins using the pin registers: This gave me the performance I needed. I then setup an interrupt timer to send points to the DACs like this: The portENTER/EXIT_CRITICAL_ISR functions are commented out because that slowed down the performance too much, and leaving them out had no negative effects. Maybe that's my problem! Then in the main loop(){} function I have: That's the most important parts of my code. When I compile this for espressif32 >= 4.0, the timing is way off and the patterns drawn are very unstable as you described. As such, I've already pinned my code to [email protected]. And from the sound of it, it looks like I won't ever be able to move past that. But at least now the LittleFS integration with Autocorrect is working great! Thank you again for your help and insight. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I've converted my main ESP32 app to use LittleFS instead of SPIFFS, which is working great. But I still see SPIFFS being compiled in the dependency tree due to AutoConnect and Pagebuilder:
The code compiles clean and runs great, even with both SPIFFS and LITTLEFS in the tree. I'd like to figure out how to not have SPIFFS compiled into the code, hopefully freeing up some code and stack memory. For the record, I am not using any of the Autoconnect features of uploading files or custom web pages that actually need to write to the local FS.
I've read this entire page: https://hieromon.github.io/AutoConnect/filesystem.html#selecting-appropriate-filesystem and I've added this to my platformio.ini file:
But when I do that, I get a long list of compile errors (see below). I've search and search and tried everything I could find, but can't figure out how to get this to compile with only LITTLEFS. I'm sure it's probably one little thing that's triggering all these errors, but I sure can't figure it out. Help me Hieromon, you're my only hope!
Thank you, and thank you for your awesome library!
-HLR
Beta Was this translation helpful? Give feedback.
All reactions