Page 10 of 14
Re: Replacing LWIP
Posted:
Mon Apr 22, 2019 3:40 amby eriksl
Please note that the LWIP lib version from Espressif has the options set to use pvPortMalloc and friends for memory allocation. The "regular" LWIP has the options set default for using static memory. If you want to keep that behaviour, you'll need to add two options to lwipopt.h:
Code: Select all/**
* MEM_LIBC_MALLOC==1: Use malloc/free/realloc provided by your C-library
* instead of the lwip internal allocator. Can save code size if you
* already use it.
*/
#define MEM_LIBC_MALLOC 1
/**
* MEMP_MEM_MALLOC==1: Use mem_malloc/mem_free instead of the lwip pool allocator.
* Especially useful with MEM_LIBC_MALLOC but handle with care regarding execution
* speed and usage from interrupts!
*/
#define MEMP_MEM_MALLOC 1
Re: Replacing LWIP
Posted:
Mon Apr 22, 2019 8:28 amby davydnorris
Fantastic work mate! You should do a pull request for Espressif to replace their 3rd party dir with this.
Even if you don't I'll be pulling this into my project once I'm done, and I'll work on the DNS and SNTP compatibility bits
Re: Replacing LWIP
Posted:
Mon Apr 22, 2019 8:37 amby eriksl
That is very good news!
I don't think it will be worth the effort to try and get it into the Espressif repo though, they're clearly not interested in the non-os-sdk stuff anymore. And honestly, I think they'd rather get rid of the ESP8266 altogether. The ESP32 is easier for them to maintain because it has full user space and system space separation (so even if the technical bits of the radio interface would get out, we still couldn't access it). Also I have noticed that ESP32 is considerately more expensive, I think the ESP8266 doesn't yield enough (anymore). I am a bit sad about this.
Now I think of it, I still have this little shared project in mind, where collect all we know about the memory and I/O space. I think I have a few interesting additions, I hope others have some as well.
Re: Replacing LWIP
Posted:
Mon May 06, 2019 6:45 pmby davydnorris
I may be moving to your lwIP sooner than I thought...
I've found a nasty problem in the tuanpm based MQTT library that has been fixed in the ESP_RTOS and IDF versions, so I am considering moving to that library and it's lwIP based. It may also offer me additional advantages as it has a web transport as well as traditional MQTT native protocol.
Basically, the current MQTT library doesn't handle message publishing when QOS > 0 and you have higher volume or bursts of messages - it only remembers the last pending message sent, so if you publish a second message before the first one has completed, you lose the end of the transaction.
In addition the publish callback is in the wrong place for QOS > 0, which is why it wasn't found earlier - when I fixed the publish callback I found I wasn't getting it reliably, which then led me to find the race condition.
I'll either patch the current library with a pending message queue, based on the RTOS, or patch the whole RTOS version to work with NonOS - it's 50/50 at the moment which is simpler.