-
Notifications
You must be signed in to change notification settings - Fork 7.6k
ESP32 WiFi scanning sketch binary is 86Kb larger, consumes 55Kb more RAM in 2.0.0 vs 1.0.6 #5630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In this comment it was mentioned that "the OS has become larger to support more features". However this is unofficial and somewhat vage, and the example sketch here does not use Bluetooth BLE at all. |
The platform.txt for 1.0.6 specifies -Os as a build flag. The equivalent file for 2.0.0 specifies -O2 instead. On a sample project I maintain, the binary size increased from |
I can confirm the same problem with 2.0.0, I go back to 1.0.6 that works well in this meaning.
This is a big down side for this release :-( |
Arduino has no fault here. Memory usage and features come from ESP-IDF. There are reasons why they decided to change memory usage of different components. In any case, you can file an issue there. |
At least in the issue of binary size, I disagree. The platform.txt is a file that exists only for Arduino IDE compatibility, and its contents should therefore be managed by the arduino-esp32 project. I grepped the master branch of the esp-idf repository here in github, and no mention of platform.txt was found. As I commented earlier, changing the compile flags from -O2 to -Os (the 1.0.6 default) already yielded measurable binary size reductions. Why was the compiler flag changed in the first place? I suspect that if the entire library shipped with 2.0.0 were recompiled with -Os , most if not all of the binary file size increase would disappear. |
Continuing the comparison from #5474 (comment), this time with IDF's example/wifi/scan: IDF release/v3.3, default sdkconfig: 572000 bytes The OP mentions that the Arduino scan example became 86kB larger in 2.0.0 compared to 1.0.6. If we assume that 48kB out of these 86 are due to code bloat in IDF, there is still more than 30kB to be accounted for. Given the 52kB difference between the default sdkconfig and the one used in arduino-esp32 v2.0.0, there might be some room for improvement. As mentioned in the linked issue, |
@avillacis, @cjcr, @fdivitto a) bin size of 632405 bytes
I created a repository with a new Arduino Core 2.0.0 that can be tested. In order to install it as a separated board for testing, please follow the instructions from
In case it works fine for a number of users, we will commit it for the next ESP32 Arduino release. |
@SuGlider Thx for this! Is the result achieved by changed settings in sdkconfig? If yes which changes you have done? I am interested since we do build the Arduino libs ourselves (changed sdkconfig settings needed) and would like to integrate and test your changed setup. If not which changes have you made? |
Yes, result is achieved mainly by changes in sdkconfig in Arduino Lib Builder. There is also a change to platform.txt to use -Os (optimize for size) and a change I. WiFI library to tweak wifi configs before calling wifi_init(). The branch is for making it easy for testing. I'll post a PR with all those changes as soon as I have a number of successful user reports back and then I'll send its information here to this issue. |
@SuGlider Thx for your answer. Compared your choosen sdkconfig with ours. The are no major differences. Since we do not use Arduino IDE Platform.txt is not relevant. Using Option -Os too. |
@Jason2866 I'll post the PR here next week. |
@SuGlider Thx, a lot! Will wait for the PR. Btw. Arduino Lib builder does fail at the moment because LittleFS is updated and cmake stops. |
@SuGlider With your latest commit it works. :-) More free mem and flash. Great work! |
on commit deacf43 sdkconfig modifications to build libraries with compile optimization to size (-Os) keep all the bootloaders with -Os and no boot messages changes max number of sockets from 10 to 16 disables LWIP "Experimental PPP and SLIP" because it adds about 60K to the binary size and it's not used in Arduino on commit a133257 sets WIFI LWIP to try first to allocate from SPIRAM on esp32 (this is esp32s2 default configuration) defines SPIRAM_MALLOC_ALWAYSINTERNAL to 4096 bytes on esp32 (same as default for esp32s2) disables SPIRAM_MALLOC_RESERVE_INTERNAL on both esp32 and esp32s2 to release more RAM to heap Related PRs in Arduino-ESP32: espressif/arduino-esp32#5789 espressif/arduino-esp32#5791 Related issue: espressif/arduino-esp32#5699 espressif/arduino-esp32#5474 espressif/arduino-esp32#5630 espressif/arduino-esp32#5751
) Summary Modifies WiFi lib to allow dynamic buffer allocation along with SPIRAM MALLOC enabled This gives more heap space to the users Related PR in Arduino Lib Builder: espressif/esp32-arduino-lib-builder#47 Impact WiFi will work the same as it was in version 1.0.6, restoring free heap. close #5630 close #5474 close #5699 close #5697
@SuGlider, I downloaded your changes and it seems to work a charm on Wifi. Around 50k more. SerialBluetooth seems to use around a 100k itself as well |
We are about to officially release Arduino Core 2.0.1 RC1 that will incorporate these changes. Thus, if everything goes well, the final release Arduino V2.0.1 will solve this and some other important issues. |
…pressif#5791) Summary Modifies WiFi lib to allow dynamic buffer allocation along with SPIRAM MALLOC enabled This gives more heap space to the users Related PR in Arduino Lib Builder: espressif/esp32-arduino-lib-builder#47 Impact WiFi will work the same as it was in version 1.0.6, restoring free heap. close espressif#5630 close espressif#5474 close espressif#5699 close espressif#5697
Hardware:
Board: ESP32 Dev Module
Core Installation version: 1.0.6 , 2.0.0
IDE name: Arduino IDE
Flash Frequency: 80Mhz
PSRAM enabled: no
Upload Speed: 115200
Computer OS: Fedora 34 x86_64
Description:
When testing many of my Arduino-ESP32 project with 2.0.0 versus 1.0.6, I notice that both required binary space and RAM use are consistently larger in 2.0.0 versus 1.0.6. This introduces the risk that projects that previously worked comfortably within allocated app partition and RAM space under 1.0.6, will now require extra partition space, risking overflows, and/or crashes because of insufficient ram. Nothing has been changed except the version of SDK (1.0.6 versus 2.0.0).
Sketch: (leave the backquotes for code formatting)
Debug Messages:
Under 1.0.6, this sketch compiles into a 638608-byte binary, and shows the following output:
Under 2.0.0, the exact same sketch compiles into a 724912-byte binary (86304 bytes larger), and shows the following output:
The sketch now sees 226955 bytes of free RAM (versus 282076 bytes under 1.0.6), an unexplained 55121-byte increase.
This is worrying because some of our projects using ESP32 boards (with no PSRAM) are already having trouble running OTA updates via their web interface under 2.0.0, as apparently a 4096-byte malloc() inside the Updater object now fails where it previously succeded with 1.0.6.
The text was updated successfully, but these errors were encountered: