ESP8266 Community Forum

- Sat Aug 22, 2020 9:10 am #88423 I use ESP.getHeapFragmentation(), ESP.getFreeHeap() and ESP.getMaxFreeBlockSize() to monitor the memory allocation. Also I'm doing (at least try to do...) all dynamic allocation at startup and avoid runtime dynamic heap allocation other than internal network buffers. It's not MISRA compliant, but it is close enough to allow 24/7 runtime for my application.

- Sun Aug 23, 2020 5:49 pm #88446

How do you guys check how much RAM you actually have left?

I use system_print_meminfo() and system_get_free_heap_size()

- Fri Aug 28, 2020 7:27 am #88518

Beware of blindly switching from async-mqtt to PangolinMQTT. The library is in early state and has it's own problems/differences for example:
1. It can be used only as an singleton
2. It hangs the whole system when you put in bad credentials by mistake or when SSL certificate expire
3. memory fragmentation is bigger
4. because of point 3 and internal bug inside the library the getMaxPayloadSize() function is unreliable after some time
5. string payload handling is incompatible with the rest of the world

Point 2. So do other libraries.
Point 5. Totally incorrect on several fronts:
ALL MQTT payloads are length-delimited blocks of arbitrary bytes. There is NO SUCH THING as a "string payload". So, the "rest of the world" is wrong.
Pangolin provides several utility functions to CORRECTLY handle C-strings if that is what you decide to put in the payload, i.e ABCD is stored as ABCD\0 with a length of 5. This allows users to handle the payload with standard C-string functions without having to unpack the payload, or jump through hoops so store it.
It also provides - of course - the same raw binary + length function that every other library does, so that people who dont understand the utility functions and want to make hard work for themselves can use do it the hard way.

I recommend that you read the documentation:

MQTT payloads are NOT "strings" of any form or description and CANNOT be treated as such without serious problems and potential crashes

MQTT payloads
ALL MQTT payloads are length-described blocks of arbitrary bytes aka "BLOB" (Binary Large OBjects). They don't have to be large - mostly they contain only a few characters of temperature or some other sensor reading etc, but the term is a good one because it describes ALL payloads including the tiny ones.

The correct C/C++ datatype for such data is either byte or uint8_t. It is NOT, never has been and never will be char.

Therefore, any reference to payload data that is not a uint8_t or a uint8_t* pointer to that data is also WRONG. The biggest problem in assuming tht "its the same as a char*" is that 99% of C string functions use char* for the simple fact they operate on C strings and MQTT payloads are NOT C strings.

Seeing a char* then can easliy seduce the programmer into thinking what it points to is a string as 99.9% of the times he has seen it before, it does. Thus "Oh, char* - must be a string then, I'll pass it to strlen or strcpy or strXXXanything else" - but if you do any of those things with an MQTT payload, your code will probably crash, because it is NOT a C string.

That fact alone should be enough to remind you to always address payload data with a uint8_t* - if it isn't, you are going to have problems.

The MQTT specification has little more to say on the payload than this:

3.3.3 Payload
The Payload contains the Application Message that is being published. The content and format of the data is application specific
Think about "application specific": it means any app can put anything it wants in there... so why do some people assume it's a string? It's not, it's whatever the application that sent it chose to put in there. That's why it has no structure or type - that is up to you. It's just a "BLOB" of bytes whose correct C / C++ type is uint8_t[]. It is up to your code to check / validate / confirm that the contents are as expected. Failure to do so, or a faulty assumption about its contents will almost certaily lead to corrupt data at best and at worst, a crash.

Please don't incorrectly describe things as "incompatible" when your basic facts / understanding are flawed.

Finally, the above minor issues will soon be fixed - given that asyncMQTT simply does not work @ QOS 1 or 2 and regularly crashes and riandom intervals, cotrrecpts data, cannot handle large packets etc etc and has at least 16 fatal bugs....pangolin's minto annoyances are a small price to pay for stability.

More info https://github.com/philbowles/PangolinMQTT/blob/master/docs/bugs.md

- Fri Aug 28, 2020 11:57 am #88524

Beware of blindly switching from async-mqtt to PangolinMQTT. The library is in early state and has it's own problems/differences for example:
1. It can be used only as an singleton
2. It hangs the whole system when you put in bad credentials by mistake or when SSL certificate expire
3. memory fragmentation is bigger
4. because of point 3 and internal bug inside the library the getMaxPayloadSize() function is unreliable after some time
5. string payload handling is incompatible with the rest of the world

Point 2. So do other libraries.

Really? Any examples? The implementation inside PangolinMQTT actually bricks the whole device because of this

https://github.com/philbowles/PangolinM ... T.cpp#L103

and the only way out is reflashing the device even when the application has an emergency mode based on periodic crashes counter. It is actually fatal error!

Point 5. Totally incorrect on several fronts:

I don't want to vaste my time (again) so I'll be brief: All about this I've write here https://github.com/philbowles/PangolinM ... -654936108 , the evidence was here also given by Pfeerick, solution was also offered and I'm not the only one with this feeling.
When I use Paho (C/C++/Python), I can write client.publish('topic', 'Hello World'), when I use MQTT.js (Javascript), I can write client.publish("topic", "Hello World"), when I use https://github.com/knolleary/pubsubclie ... sp8266.ino (CPP/Arduino) I can write client.publish("outTopic", "Hello world") - they are compatible, but when I use PangolinMQTT and write client.publish("topic", 0, false, String("Hello world")) the others see crippled message data. Even worse is if you use PANGO::payloadToCstring() - you get character pointer to data without terminating /0 character.

So I'm saying it again PangolinMQTT string payload handling is incompatible with the rest of the world. At least right now. Period.