* 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
Advanced Users can post their questions and comments here for the not so Newbie crowd.
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
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.
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.