- Fri Apr 05, 2019 2:11 am
#81568
I've been busy with the following, the last few days, which may be interesting. I noticed the free heap space going down and up all of the time, when using LWIP. That means we can never know if there is enough memory available for proper LWIP operation and it's the obvious drawback of using a memory heap mechanism.
I noticed that LWIP also has a static memory mode, where a character array of size X is declared in bss and then LWIP does it's own memory allocation. Tried it and failed, crash. After much debugging is appears there is something very simple going on, the function that's supposed to initialise this array, is commented out by Espressif (...). I learn to love these guys more and more with every minute! So enabled it again and it started to work. Now I am fiddling with the LWIP "tuning knobs" to make optimal use of the allocated memory. With heap based allocation that's all invisible and "everyting" is possible. Until memory runs out.
The amount of memory I need to have allocated in the static model frightens me a bit, in the sense that all of that amount is also used in the heap model, we just don't see it. In other words, if you have, say, 5k of memory available, you can already run into problems sending large payloads. As LWIP debugging is turned off by default, you will never know why it failed.
So now this is my next step, get all of the LWIP tweaks right, have a certain amount of statically allocated memory for LWIP and the all of the rest, we know we can use and don't bother LWIP.
For being able to send payloads of 4k (4 * TCP MSS), I'll probably need around 6k of memory dedicated to LWIP. For the receiving of payload, LWIP can probably use the same memory, but I didn't check that yet. This memory is used for both TCP and UDP payloads, BTW.
And also BTW, for my code, I'll probably remove DNS and MDNS support as I'm not using it anyway and it just uses more memory.
And lastly, while debugging the above issue, I already updated some LWIP source files with the content of the stock LWIP 1.4.1 version. Differences are a few small bug fixes from the LWIP team and it made me see what changes Espressif had made (and I reverted them, wherever possible). Now I only need to do the other 90 files, I'll do that another time I guess
End goal is to have a clean "stock" LWIP with the minimum of patching to have it run on ESP8266. From there it should be doable to move on to LWIP 2.