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
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
Let’s get back to our footprint test sketch.
The truth is, the Blynk library can get even smaller
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!