ESP8266 Community Forum

- Sat Oct 24, 2020 8:07 am #89194 Hi Buddies,

I looked into the SDK libraries from Espressif to find that the module wdev.o of libpp.a takes up nearly 12KBytes memory from he bss section as below:

bss 0x3ffe**** 0x2f88 libpp.a(wdev.o)
0x3ffe**** wDevCtrl
0x3ffe**** WdevTimOffSet
*fill* 0x3fff**** 0x8

Similar as well, a lot of memory is taken up from the bss by SDK libraries!

Considering SO LIMITED dram0_0_seg avaliable for user codes!

Any hits or suggestions to save dram0_0_seg from SDK Libaries?

Thanks!

- Thu Oct 29, 2020 5:30 am #89246 It seems like "wdev" stands for "wireless" "wifi" or "wlan" device.

What I can see from the interface to lwip, it's memory buffer for sending and receiving frames. So I guess it's required.

There are various ways to regain A LOT of DRAM memory though, making this amount for "wdev" no longer an issue. The most important one is that everything you use (variables and their storage, initialised or unitialised) are copied to DRAM before your code starts. The problem is you can make them completely "const" but that is not enough to make them NOT end up in DRAM. You explicitly need to make the variables of storage in section ".flash.rodata". That's enough though, if you use an initialiser, make sure you declare an array and not a pointer. If you declare

Code: Select all__attribute__((section(".flash.rodata"))) const char *test = "test";

the value of "test" will still end up in DRAM, so do it this way:

Code: Select all__attribute__((section(".flash.rodata"))) const char test[] = "test";

Then, anything you put in flash (and not copy to DRAM) must be referred to as 32 bit words. You cannot address a single byte or 16 bit word. Also the 32 bit word needs to be 32 bit aligned (i.o.w. bit 0 and 1 need to be zero).

Also I am not sure the "standard" linker config file exactly names it that way, it could be the section is named otherwise or not even present, I guess the others here could extend on that.

It's very well possible make an environment of tools around this that make operation "seemless". The SDK has an "snprintf" version that should do this (but I tried once and got a crash, so I don't trust it). For myself I have a set of functions that allows me to use "flash" strings almost as if their in DRAM. This saves me something like 20 kbytes, without it, I would have been stuck a long time ago.

- Sat Nov 07, 2020 4:02 am #89328 [quote="eriksl"]It seems like "wdev" stands for "wireless" "wifi" or "wlan" device.


Thanks alot for the reply at first!

Second,

as per "wdev", two SDK variables of wDevCtrl and WdevTimOffSet take up a lot of bss here

Third,

"wdev" is just an example. There are much more dram0_0_seg eaten by SDK for examples:

0x242 by libmain.a(user_interface.o)
0x480 by liblwip.a(dns.o)
0x322 by libpp.a(pp.o)
0xaa4 by libpp.a(esf_buf.o)
0x67c by libnet80211.a(ieee80211.o)
0x421 by liblwip.a(mdns.o)
......
All of above take drram0_0_seg!

Forth,

The methods you suggested above are traditional, and there are also many more methods provided by Espressif documents, and can help you save limited memories BUT, much much much more dRam0 wasted in Espressif SDK Libaries should and could be released out by some ways such as removing some unused modules via gcc tools, but need to be verified.

- Sun Nov 08, 2020 11:43 am #89343 If you apply all I recommended, it isn't that bad. Please remember that there is very little hardware available for wireless handling. Many things, that usually are handled by a piece of hardware, must be processed by the cpu and so they WILL take memory. That is including a few frames of buffering, for both sending and receiving. Remember that every frame has to be encrypted or decrypted (using WPA AES), there is no hardware support there. Each wireless frame is about 2400 bytes, so you do the math...

Another place where you can buy yourself a lot of DRAM memory is the LWIP library. The version shipped with the SDK has a lot of buffer memory allocated to a number of sockets, tcp segment reassembly etc. It will take most of the memory from the heap so you won't see it in the linker output, but it will definitely decrease the amount of memory you can use. The way to go is to compile LWIP yourself, with only the options and sizes you're actually using. It can save you up to about 16 kbytes, not bad I think.

Then there is the ~2.5 kbytes somewhere that apparently is never used (at least not with my usage, the SDK never writes anything there). So I am using that for buffer memory as well, saves another 2.5 kB.

And finally, if you still think too little RAM is available and/or don't want to spend the effort to squeeze out every last bit, the the ESP8266 isn't really for you, I'd suggest using the ESP32 in that case. It has much more memory and it has a higher layer of abstraction in their IDK, which most people seem to like (and I personally hate).