We will be covering the following content and more!<\/p>\n\n\n\n
- Why should you know about Arduino memory?<\/li>
- What is Memory in Arduino?<\/li>
- How to Measure Arduino Memory Usage<\/li>
- How to Optimise Memory Usage on Arduino<\/li>
- Arduinos for Memory Intensive Projects<\/li><\/ul>\n\n\n\n<\/div>\n\n\n\n
![\"\"](\"https:\/\/blog.seeedstudio.com\/wp-content\/uploads\/2021\/04\/ArduinoMemCover-1030x601.png\")
<\/figure>\n\n\n\n<\/div>\n\n\n\n
\n\n\n\n<\/div>\n\n\n\nWhy Should You Know About Arduino Memory?<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nIn broad and simple terms, the purpose of memory blocks in Arduino microcontrollers is to store run-time data or information temporarily or permanently. For example, both the code that you upload to your Arduino and the variables declared in that code are stored in memory. In fact, memory is an essential component of any type of computer!<\/p>\n\n\n\n
<\/div>\n\n\n\nMicrocontrollers like Arduino are built small and affordable to serve specific purposes and thus have relatively limited computing resources. Compared to modern computers which have Gigabytes (109<\/sup>) of memory as norm, microcontrollers function with memory sizes of Kilobytes (103<\/sup>) to a few Megabytes (106<\/sup>). Hence, it\u2019s important to use the memory resources on our Arduino with careful consideration.<\/p>\n\n\n\n
<\/div>\n\n\n\nSource: Dots and Brackets<\/em><\/figcaption><\/figure><\/div>\n\n\n\n <\/div>\n\n\n\nWhen memory is not managed well, your Arduino might fail in a variety of ways. Sometimes, this can be as obvious as the code not uploading to your board like shown above. In other cases, everything might appear to run fine for awhile, only for the microcontroller to stop responding later on – that\u2019s much more tricky!<\/p>\n\n\n\n
<\/div>\n\n\n\nIn any case, unless you’re working with a faulty board, it\u2019s almost certain that any code that compiles but doesn\u2019t work as it should is suffering from a memory problem. When that happens, it\u2019s important to understand what goes on behind the scenes so that we can diagnose and fix the problem!<\/p>\n\n\n\n
<\/div>\n\n\n\n
\n\n\n\n<\/div>\n\n\n\nWhat is Memory in Arduino?<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nThere are three types of Arduino memory that you should be aware of:<\/p>\n\n\n\n
- Flash<\/strong> or Program Memory (PROGMEM)<\/li>
- SRAM<\/strong> – Static Random Access Memory<\/li>
- EEPROM<\/strong> – Electronically Erasable Programmable Read-Only Memory<\/li><\/ul>\n\n\n\n
<\/div>\n\n\n\nFlash Memory<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nFlash memory is a type of memory that is used for storage, similar to what we see in USB thumb drives and SD cards. It is non-volatile, meaning that it will retain stored information even if no power is supplied.<\/p>\n\n\n\n
<\/div>\n\n\n\nIn an Arduino, Flash used to store the program code and any additional data. Since data held in flash memory can\u2019t be modified by executing code, they are first copied into the SRAM before the code is run.<\/p>\n\n\n\n
<\/div>\n\n\n\nSRAM<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nSRAM stands for Static Random Access Memory, and is arguably the most important component of diagnosing memory issues in Arduino. You can imagine it as a memory block that is shared amongst three main components: Static Data<\/strong>, Heap<\/strong> & Stack<\/strong>.<\/p>\n\n\n\n
<\/div>\n\n\n\n<\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\n- Static Data <\/strong>– This section of the SRAM stores data that doesn\u2019t change in the programme, such as global and static variables.<\/li><\/ul>\n\n\n\n<\/div>\n\n\n\n
- Heap<\/strong> – The heap exists next to static data an is used for dynamically allocated data items, such as variables created by executing code.<\/li><\/ul>\n\n\n\n<\/div>\n\n\n\n
- Stack<\/strong> – The stack is used to keep track of function parameters, including local variables, interrupts, and function calls. Each function call will increase the size of the stack, while returning from a function will return that memory to the free memory pool.<\/li><\/ul>\n\n\n\n<\/div>\n\n\n\n
You might have noticed that the stack and heap are located on opposite ends of the free memory. As either of them grow, they consume more and more of the free memory, effectively \u201cmoving towards\u201d each other. Most memory problems are the result of the stack and heap \u201ccolliding\u201d, which can cause a corruption of the data held in memory. As mentioned, some corruptions may cause an immediate crash, or the code may still continue to run for a period before problems emerge. It depends!<\/p>\n\n\n\n
<\/div>\n\n\n\nEEPROM<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nSimilar to flash, EEPROM is another form of non-volatile memory that you can use to read and write data. However, you will have to do so byte by byte, which can be slightly more inconvenient than what we\u2019re typically used to. You can think of it as an in between of both flash and SRAM – a read\/writable flash or non-volatile SRAM, as you will!<\/p>\n\n\n\n
<\/div>\n\n\n\nNote:<\/strong> Most EEPROMs have lifespan of around 100,000 write\/erase cycles, so be careful with placing EEPROM read \/ writes in loops!<\/p>\n\n\n\n
<\/div>\n\n\n\n
\n\n\n\n<\/div>\n\n\n\nHow to Measure Arduino Memory Usage<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nBefore optimisations, we\u2019ll have to begin our diagnosis by measuring the amount of memory that our program uses.<\/p>\n\n\n\n
<\/div>\n\n\n\nFlash<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nIt\u2019s super convenient to measure Flash memory – in fact, the Arduino IDE will do it for you! Whenever you compile or upload your code, the IDE will show you exactly how much memory is being used by your upload and what percentage of the selected board\u2019s memory that uses. For example, the sketch I uploaded below uses just 35K or 7% of the Wio Terminal\u2019s flash memory – very comfortable!<\/p>\n\n\n\n
<\/div>\n\n\n\n<\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\nEEPROM<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nYou have to write to the EEPROM byte by byte, so you should know exactly which addresses are being used. When in doubt, you should double check your code! While it\u2019s not the main focus of our article, an example of reading and writing data with the EEPROM is shown for reference below. You can also learn more about how to use the EEPROM on an Arduino with the official documentation<\/a>!<\/p>\n\n\n\n
<\/div>\n\n\n\n\/\/ Write data to a given address\n#include <EEPROM.h>\nEEPROM.write(address, value);\nEEPROM.read(address);<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nSRAM<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nTo measure the usage of our Arduino\u2019s SRAM, we can use a convenient function call from this arduino library<\/a> which measures the free RAM available, freeMemory(), which is also defined below.<\/p>\n\n\n\n
<\/div>\n\n\n\n#ifdef __arm__\n\/\/ should use uinstd.h to define sbrk but Due causes a conflict\nextern \"C\" char* sbrk(int incr);\n#else \/\/ __ARM__\nextern char *__brkval;\n#endif \/\/ __arm__\n \nint freeMemory() {\n char top;\n#ifdef __arm__\n return &top - reinterpret_cast<char*>(sbrk(0));\n#elif defined(CORE_TEENSY) || (ARDUINO > 103 && ARDUINO != 151)\n return &top - __brkval;\n#else \/\/ __arm__\n return __brkval ? &top - __brkval : &top - __malloc_heap_start;\n#endif \/\/ __arm__\n}<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nRecall that the objective when managing SRAM is to avoid a collision between the heap and the stack. Thus, what freeMemory() actually provides us with is the amount of free memory available between them.<\/p>\n\n\n\n
<\/div>\n\n\n\n<\/figure><\/div>\n\n\n\n
<\/div>\n\n\n\nSince the size of the heap and the stack will change throughout the program execution (ie. they are dynamic), it\u2019s also important to monitor the free memory available throughout various points of the code by calling the freeMemory() function regularly.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\n\n\n\n<\/div>\n\n\n\nGreatest Memory Offenders<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nDespite our best efforts to optimise memory, some devices and drivers will simply require more SRAM to function. In those cases, it\u2019s important to identify the offenders and work around them!<\/p>\n\n\n\n
<\/div>\n\n\n\nFilesystems<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nIf your Arduino interfaces with a SD or MicroSD card, a large memory buffer of 512 bytes will need to be allocated to facilitate the reading and writing of data. If possible, it\u2019s advised to move the contents of your program to your flash memory, since it will also be faster.<\/p>\n\n\n\n
<\/div>\n\n\n\nAnything with Pixels<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nOLED displays, RGB lights, you name it – these things hog memory! Each pixel is defined as a combination of Red, Green, Blue (RGB) values, and will consume 3 bytes of SRAM. Don\u2019t underestimate that number, since small displays can already easily have thousands of pixels! Of course, monochrome (single colour) displays will only require 1 byte for every 8 pixels, but that\u2019s still 1K for SRAM for a display as small as 128 by 64 – choose wisely!<\/p>\n\n\n\n
<\/div>\n\n\n\nTinyML<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nTinyML is a new concept that aims to bring machine learning to tiny and cost effective microcontrollers. Considering that most ML is done on desktop-class computers, there\u2019s no doubt that this stretches the memory consumption on microcontrollers. If you want to build edge ML applications, you\u2019ll have to be even more careful of memory consumption since it\u2019s necessary to work around the ML model.<\/p>\n\n\n\n
If you\u2019re keen to learn more about Edge ML, I highly encourage you to read our previous article here<\/a>.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\n\n\n\n<\/div>\n\n\n\nOptimising Memory Usage on Arduino<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nIf your program is failing due to a memory problem, you\u2019re in luck. For each type of Arduino memory, there are a few basic modifications that we can make to our code in order to reduce the memory used. With some finesse, you just might be able to once again get it under the memory limits! In this section, we\u2019ll only talk about optimising flash and SRAM, since EEPROM memory tends to be quite straightforward.<\/p>\n\n\n\n
<\/div>\n\n\n\nNote:<\/strong> Memory optimisation is a deep and advanced topic in the world of computing; deeper knowledge on this subject can certainly bring you much further! The steps shared in this article are just some of the steps that beginners can take to optimise their code!<\/p>\n\n\n\n
<\/div>\n\n\n\nOptimising Flash Memory<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nThe best way to reduce the size of your program is to identify which of its parts are really necessary, and to eliminate those that aren\u2019t to save space. For example:<\/p>\n\n\n\n
<\/div>\n\n\n\n- Eliminate unused libraries, functions and variables<\/strong>.<\/li>
- Look out for unreachable code<\/strong>, such as conditionals that will never be true.<\/li>
- Consolidate repetitive code<\/strong> by wrapping it in a reusable function.<\/li><\/ul>\n\n\n\n
<\/div>\n\n\n\nOn the extreme end of things, you can consider eliminating the bootloader to save even more space. However, I wouldn\u2019t recommend this as bootloaders serve several important functions in development processes and can make your life easier. If you\u2019re still keen on making this happen, have a look at our bootloader programming article<\/a>.<\/p>\n\n\n\n
<\/div>\n\n\n\nOptimising SRAM<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\nSRAM is the most complex of all three memory types to use, but there are also more options when it comes to optimising it.<\/p>\n\n\n\n
<\/div>\n\n\n\nUnderstand the Behaviours<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nAn important aspect of SRAM management that may confuse some beginners has to do with the heap. We know that the heap is used for dynamically allocated variables in the program, but there is an important issue that arises if you don\u2019t use it carefully, known as heap fragmentation<\/strong>. Let\u2019s look at an illustration of a heap to understand this.<\/p>\n\n\n\n
<\/div>\n\n\n\nSource: Brew<\/em><\/figcaption><\/figure><\/div>\n\n\n\n <\/div>\n\n\n\nThe entire heap holds 64KB of memory. Up until Step 3, subsequent allocations take up neighbouring memory addresses, which is rather straightforward. Now, observe what happens when the second allocation is freed. Although we now theoretically have 32KB of free memory like we did in Step 2, the maximum size of any subsequent allocation is now 16KB instead of 32KB! In this case, the memory available from freeing the second allocation is known as buried heap space<\/strong>, and heap fragmentation<\/strong> has occurred.<\/p>\n\n\n\n
<\/div>\n\n\n\nBuried heap space is not usable by the stack, but can be used for subsequent heap allocations. Hence, poor heap management can cause the heap to grow quickly towards the stack, accelerating a memory corruption!<\/p>\n\n\n\n
<\/div>\n\n\n\nUse Local Variables<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nA good way to circumvent the heap problem is to use local variables in your functions. Local variables are variables which are declared inside a function, and are only available for use within that function. This way, the memory usage becomes part of the stack as opposed to the heap. The benefit of this is that the memory used by stacks are completely freed<\/strong> when the function is returned, which allows our code to work in the same manner without opening it up to vulnerabilities from heap fragmentation!<\/p>\n\n\n\n
<\/div>\n\n\n\nOffloading to Flash \/ PROGMEM<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nNormally, our code dynamically loads static variables into SRAM, which wastes precious memory in the heap since we\u2019ll never have to modify them. Fortunately, there are several methods to tell our program to leave such variables out of SRAM, and to instead reference them directly from flash memory.<\/p>\n\n\n\n
<\/div>\n\n\n\nFor Strings:<\/strong><\/p>\n\n\n\n
Literal strings consume a very large amount of memory, but there is fortunately an easy way to reduce their memory usage. By wrapping strings with a F() macro as shown below, we tell the program to store the string in Flash, saving us a ton of precious SRAM!<\/p>\n\n\n\n
<\/div>\n\n\n\nSerial.println(F(\u201cThis is a string that eats a lot of memory, but not anymore!\u201d));<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nFor Other Data:<\/strong><\/p>\n\n\n\n
<\/div>\n\n\n\nYou can also do something similar to other data types by using the PROGMEM modifier<\/a>. After the data is moved into the Flash memory, you will need to use special functions defined in the pgmspace.h<\/a> library to read and write data. As you might tell, this presents a slight inconvenience, but is great for reducing SRAM consumption!<\/p>\n\n\n\n
<\/div>\n\n\n\nReserve() Memory<\/strong><\/h3>\n\n\n\n
<\/div>\n\n\n\nThe reserve() function creates a buffer for a string that might grow in the future. That way, the program will not have to reallocate memory to the string as it is being modified by the program.<\/p>\n\n\n\n
<\/div>\n\n\n\nWhy is this important? Well, when strings are being modified, it\u2019s common for intermediary variables to be created to facilitate the operation. When this happens, the heap memory allocation gets chaotic and a new section of memory often has to be allocated for the final string object. This creates opportunities for heap fragmentation to occur, which will reduce the memory efficiency of our program!<\/p>\n\n\n\n
<\/div>\n\n\n\n - Look out for unreachable code<\/strong>, such as conditionals that will never be true.<\/li>
- Eliminate unused libraries, functions and variables<\/strong>.<\/li>
- Stack<\/strong> – The stack is used to keep track of function parameters, including local variables, interrupts, and function calls. Each function call will increase the size of the stack, while returning from a function will return that memory to the free memory pool.<\/li><\/ul>\n\n\n\n
- Heap<\/strong> – The heap exists next to static data an is used for dynamically allocated data items, such as variables created by executing code.<\/li><\/ul>\n\n\n\n
- SRAM<\/strong> – Static Random Access Memory<\/li>
- Flash<\/strong> or Program Memory (PROGMEM)<\/li>
![\"\"](\"https:\/\/lh5.googleusercontent.com\/fcu0IXcAVxo5HoYGsNdbT2oX_l11rdhpUct6mPMmdzY14JSwHmzhzE_WQW56-2Zxus9mgkk3TEREt3dNIyxwFFT_95YawCA7H85BwYlLz-wTi0qlW13vIzrQPgnFR2cF1avOOU2n\")
![\"\"](\"https:\/\/lh6.googleusercontent.com\/bdDI7i5w7qrOPzqHKKbmpxeKiX68oqiyNMxLtC_EgUPUr_XfeCsW6De76BrfvBGFDYcnDpRTraOSy_g2NVt_cryu_zoOQ13aaFis09zfR1XJ0mEPQxHcgOPQg4lTsfeoTQVEmDn_\")
![\"\"](\"https:\/\/lh6.googleusercontent.com\/c38J7oEga1uFSgwkb9z8sul17BEEXwE24deqZwNh2czwH00l3vNc7yLqu7SDMki3YeqOo5Mn0YoriA6e8sZwbUI0NSmWK-t77ixStuB0X1t5uUQ4B_ionEXpth0Lygx_SKUcshvh\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/lh4.googleusercontent.com\/DGl7oFIJvmTFj88oh8EY3TIUEGP0zxRVwzrPUjlYhK9FPGGsasIiwMfdyBCdLTN01JHwuaEOiy6KOdUzh-6BZoLUjeYEPd3r-1fKHj-aD4Ox81ap8BipH4VUvMhLZYdk0PFGD434\")
<\/figure><\/div>\n\n\n\n![\"\"](\"https:\/\/lh4.googleusercontent.com\/9p_0sZzWT5lDlV3g7dKCLUcflyfzzv_SIrATBwI1DJyA9Rt8PseK1nDZFys9CV6wEXqxpfbmIVj1Ur1yz_bIPEYxd9n6U6rP6YJd94drANS3NoygMhUUJFP2zOLz5TmaRNsmXLT2\")
<\/figure><\/div>\n\n\n\n