Arduino Blynk library static memory footprint report

The Blynk library for Arduino was built using some special techniques to reduce amount of consumed memory, and we’re really proud of what we have now.

I’d like to share some numbers with you. I have recently created a footprint test sketch, which allows us to keep eye on the numbers as we continue to develop the library. Currently, this is what it shows for Arduino UNO:

Sketch uses 4,574 bytes (14%) of program storage space. Maximum is 32,256 bytes.
Global variables use 101 bytes (4%) of dynamic memory, leaving 1,947 bytes for local variables. Maximum is 2,048 bytes.

“But wait, my Arduino USB Serial example uses 10,292 bytes (31%)!!!” - you will ask, and this is a legitimate question :wink:

First of all, you can bring it down to 5,886 bytes by removing the SoftwareSerial library and disabling BLYNK_PRINT (it will disable Blynk library printouts). Same applies to Ethernet, WiFi or any other shield option, they have their own footprint.

Still there is some small difference, and this how much the Hardware Serial of the Arduino takes. For example, the simple default DigitalReadSerial example from the Arduino IDE takes 2,690 bytes.

I hope this explains things to you :relaxed:

Let’s get back to our footprint test sketch.
The truth is, the Blynk library can get even smaller :smile:
We can turn on some optimization options (before including any of Blynk headers):

#define BLYNK_NO_BUILTIN   // Disable built-in analog & digital pin operations
#define BLYNK_NO_FLOAT     // Disable float operations

While it disables some important parts of Blynk library, with these options we get:

Sketch uses 3,092 bytes (9%) of program storage space. Maximum is 32,256 bytes.
Global variables use 79 bytes (3%) of dynamic memory, leaving 1,969 bytes for local variables. Maximum is 2,048 bytes.

Just one more note.
As you can see, Blynk “uses 101 bytes (4%) of dynamic memory”.
This corresponds to the static part of dynamic memory.
Blynk library itself doesn’t use heap during operation (only on initialisation, for some types of shields).
It uses the stack instead. And this is very good for stability, long runs, optimization, etc…

Hope you like this report. I believe the library can be further optimized, so if you have have any ideas, please let me know.

Cheers! :slight_smile:

5 Likes

@vshymanskyy,

First, 101 bytes for global variables is quite impressive. Nice job.

Second, I think I am running into free SRAM limitations in my Blynk sketch, which is necessarily quite large. Do you have any insights into the maximum depth of the stack at runtime in normal Blynk operations? My code is not getting past Blynk.connect() before it starts getting bizarre errors, which seems like a potential stack overflow problem.

Thanks!

RD7

hello!

@vshymanskyy, could you please explain in details what these things do:

these 2 are the same? removing the SoftwareSerial library == disabling BLYNK_PRINT?

#define BLYNK_NO_BUILTIN   // Disable built-in analog & digital pin operations
#define BLYNK_NO_INFO      // Skip device info
#define BLYNK_NO_FLOAT     // Disable float operations

thank you!

No they are not. Software is Serial “emulated” serial output and BLYNK_PRINT prints status info, so that last one possibly could use SoftwareSerial, but it’s not the same.

1 Like

ok. i understand. and what about

#define BLYNK_NO_BUILTIN   // Disable built-in analog & digital pin operations
#define BLYNK_NO_INFO      // Skip device info
#define BLYNK_NO_FLOAT     // Disable float operations

what are they exactly do?
if i use only virtual pins, can i disable the first one?
BLYNK_NO_FLOAT means i can not send float values from hardware to blynk server?

Exactly.
And no-info frees some memory by skipping meta info sending (this might hurt in future, so better not to skip this)

1 Like