ESPV3.1 and following relases

[jumjum123]

Let me tell some experiences with ESPV3.1 and our application,
- size of binarys raised from V3.0 with 1050kb to 1280kb with V3.1
- wifi connect to my homenet not working reliable anymore, only 1 out of 10 works
- compiling error with V3.1.1 (just downloaded), different definition in h-file and in c-file
- fixed locally, size of binary raised again, now its 1318kb, and new strange messages

Comparing with other boards (ARM, etc)
- memory left for application is about 40kb, compared to 35 kb on ARM with 48KB RAM
- size of binary is very big, at least twice to next comparable
- speed of application is close to an 72Mhz Arm

[loboris]

Providing some details about your application and configuration could help understand your experience.
When comparing with arm, are you comparing the same application (the same functionality, FreeRTOS)?

[vonnieda]

I will add that there seems to be a significant size increase from 3.0 to 3.1 as well. I can provide numbers later on, but it's definitely a concern when I dip my toes into 3.1.

[ESP_Angus]

Hi jumjum123,

- size of binarys raised from V3.0 with 1050kb to 1280kb with V3.1
- wifi connect to my homenet not working reliable anymore, only 1 out of 10 works
- compiling error with V3.1.1 (just downloaded), different definition in h-file and in c-file

These are indeed concerning problems. Can you please give some more details about some of these:

- For flash size, which features are you using in your app? Can you please post the output of "make size-components", ideally for your app running v3.0 and v3.1?

- For failure to connect to WiFi, what kind of information (log messages, event reasons) do you get when it fails to connect?

- What specific compilation error do you get with V3.1.1?

[jumjum123]

Sent some additional information to an ESP-named guy privately.
Did this privately, because I had to add a link pointing to my private server.
And I want my server to stay as unknown as possible. Its an old contract and I've to pay if traffic exceeds limit.

To WIFI-problem we found that esp_wifi_set_mode does more than before, and this way confused our event handling.
To avoid the compiling error, this was already fixed in ESP-IDF master 6 days after deployment of V3.1.1

For memory consumption just seen some interesting information in viewtopic.php?f=13&t=8628
Following that, ESP32 needs 110kb to support https_server. Thats a lot, more than ESP8266 even has.
Adding core BLE-Server functionality reduces around the same amount.
200kb are already gone for an empty hello_world application.
Projects are mentioned that are fighting for some KB.

If this FAQ is correct https://www.freertos.org/FAQMem.html#RAMAlloc1 , FREERTOS cannot be the only reason
So, search goes on

[ESP_Angus]

Hi jumjum,

Sorry, that was me that you sent the information to. I'm glad you sorted the other V3.1 issues mentioned.

I followed up binary code size issues internally and have some information for you, that I forgot to post back to the forum (sorry):

• For overall code size, there are some unnecessary increases in total binary size of V3.1 for WiFi due to changes made to support ESP-Mesh (even if it's not used in the firmware). This will be fixed in V3.2.
• For Bluetooth code size, there are some inevitable increases in code size due to some parts of the BT controller being moved out of ROM to fix some bugs.
• We're looking into ways to automate tracking/monitoring of overall binary size in our development process, so we can attempt to avoid too much growth when we add extra functionality.
• If you're not already, compiling with Release optimisations and setting Assertions to Silent will reduce binary size.

Following that, ESP32 needs 110kb to support https_server. Thats a lot, more than ESP8266 even has.
Adding core BLE-Server functionality reduces around the same amount.
200kb are already gone for an empty hello_world application.

This point seems to be about DRAM and heap size, not total binary size - is that right? We are mindful that ESP-IDF can be a memory hog in some configurations, and we're working on ways to reduce this.

200kb are already gone for an empty hello_world application.

With v3.1.1, the hello_world application uses 13020 bytes of static DRAM plus 21052 bytes from the heap at runtime in Debug configuration. This is 33 kilobytes of RAM. Master branch uses 1KB less static DRAM due to some fixes. 3.5KB of this is the default app_main() task stack size, and will be freed if app_main() function returns.

30KB of RAM just to get basic OS functions is still a lot, we'll keep looking at what we can do to reduce this.

The linked post mentions 298572 bytes free heap in hello_world on master, this is 36KB less than the 328KB of total DRAM in the chip (the difference is mostly due to some DRAM reserved by ROM functions.)

(Note: When the datasheet mentions 520KB of total RAM this is 328KB DRAM+192KB IRAM, only DRAM is commonly used for heap although it's also possible to allocate from IRAM under some restrictions.)

Following that, ESP32 needs 110kb to support https_server. Thats a lot, more than ESP8266 even has.

Are you talking about the ESP-IDF HTTPS server (the new esp_http_server component has HTTPS support if you use the master branch version), or a different HTTPS server?

For TLS sessions in particular, reducing the mbedTLS maximum content length will reduce total memory usage if you know that the client won't send long TLS messages (or will enable maximum segment length negotiation). For example, changing this to 8KB will save 16KB of heap per TLS session.

In IDF v3.2 you'll be able to enable "asymmetric" TLS buffer sizes so the outgoing buffer can be even smaller, possible to save 12KB and still support receiving full length TLS messages.

[jumjum123]

@ESP_ANGUS
thanks for the information. Looks like I've to wait for V3.2 release
1st test on V3.2 returned some missing python modules, I've to look deeper into that.

I've added information about DRAM usage, knowing that this was not part of my first message.
From my point of view it belongs into the same group of problems, the memory hog
Its still a question for me, why our application (Espruino) has not much,much more memory on ESP32, compared to ESP8266

Oh, difference between DRAM and IRAM, this was not on my screen before. Have to find more information.
May be with that I will better understand the topic around running out of IRAM.

I took the number for heap usage from linked topic (latest comment) and did not recheck by myself.

Using Release optimisations and setting Assertions to Silent is part of our project for long time now.
Otherwise we wouldn't get it running into a 1348KB partition.