{"id":17307,"date":"2023-02-03T20:30:25","date_gmt":"2023-02-03T20:30:25","guid":{"rendered":"https:\/\/wolles-elektronikkiste.de\/?p=17307"},"modified":"2024-11-27T08:37:15","modified_gmt":"2024-11-27T08:37:15","slug":"sram-management","status":"publish","type":"post","link":"https:\/\/wolles-elektronikkiste.de\/en\/sram-management","title":{"rendered":"SRAM Management"},"content":{"rendered":"\n

About this post<\/h2>\n\n

In this article, we will dive into the depths of SRAM (Static Random Access Memory). In doing so, I will explain the difference between stack and heap and show how variables are created and managed in these memory areas. In this context, we will also address the question of why one should be careful when using strings in Arduino sketches. Finally, I’ll give you some tips on how to use the SRAM resource sparingly.<\/p>\r\n

All this is not new, and there are already quite a few good articles about it on the web. I think what sets this post apart from many others is the level of detail and the approach. Above all, I want to show very concretely on address level what is going on in the SRAM when different variables are created. I will also show you how to determine the addresses of variables in the heap. “Forensic Arduinoistics,” so to speak.<\/p>\r\n

The article assumes basic knowledge about pointers, references and the address operator. If you have difficulties with this, please read my last post.<\/p>\r\n

What topics I will cover:<\/p>\r\n

    \r\n
  1. Flash, SRAM and EEPROM<\/a><\/li>\r\n
  2. The SRAM at a glance<\/a><\/li>\r\n
  3. How variables are stored in SRAM<\/a><\/li>\r\n
  4. Stack Management<\/a><\/li>\r\n
  5. String handling in SRAM<\/a>\r\n
      \r\n
    1. String analysis in stack and heap<\/a><\/li>\r\n
    2. Heap fragmentation <\/a><\/li>\r\n
    3. Concatenating strings<\/a><\/li>\r\n
    4. So, should I use strings or not?<\/a><\/li>\r\n<\/ol>\r\n<\/li>\r\n
    5. Character Arrays<\/a><\/li>\r\n
    6. Force variables into the heap<\/a><\/li>\r\n
    7. Saving SRAM with PROGMEM and F()<\/a><\/li>\r\n<\/ol>\r\n\n

      1. Flash, SRAM and EEPROM <\/h2>\n\n

      1.1. Overview<\/h3>\n\n

      The design of the memory of a microcontroller depends on the model. In this article, I mainly refer to the ATmega328P, which is used for example in the Arduino UNO, Nano and Pro Mini.<\/p>\r\n

      As you can see in the diagram on the right, the ATmega328P has three different memoriy areas, namely the relatively large flash<\/strong>, the SRAM<\/strong> and the EEPROM<\/strong>.<\/p>\r\n

      Even though the memory design of other microcontrollers differ quite a bit (see table below), the SRAM is comparatively smaller in all of them compared to the flash and is thus a resource worth protecting. <\/p>\r\n\n

      \"Memory<\/a>
      Memory of different microcontrollers<\/figcaption><\/figure>\n\n

      The flash<\/strong> is also called program memory. When you upload your sketches, they are first compiled, then translated into machine-readable code, and finally written to flash. The bootloader is also located there. The flash is non-volatile, i.e. the memory content is retained even when the MCU is disconnected from the supply voltage. Moreover, it does not change during program execution, so there are no runtime problems with it.<\/p>\r\n

      The EEPROM<\/strong> is also non-volatile. I have described it in detail in this post<\/a>. It is particularly well suited for data that may change during the runtime, but on the other hand should be permanently preserved. This could be, for example, calibration factors for sensors or data from the last program run. <\/p>\r\n

      The SRAM<\/strong> is your working memory. It is reserved for the variables of your programs. One of the challenges in dealing with the SRAM is that its occupancy rate can only be planned to a limited extent.<\/p>\r\n\n

      1.2. Memory usage details during sketch upload<\/h3>\n\n

      When you upload your sketches to your microcontroller via the Arduino IDE, you will get an info like the following:<\/p>\r\n\n

      \"Memory<\/a>
      Memory usage details during sketch upload.<\/figcaption><\/figure>\n\n

      In this example, the program uses 9716 bytes of the available<\/em> flash, or: 31% of 30720 bytes. Actually, 32 KB of flash are available, the difference is due to the bootloader. 2048 bytes of SRAM are available. Of these, the sketch uses 751 bytes (36%) for global variables. This value is known at compile time and does not change during runtime. Local variables, on the other hand, “come and go.” How many of them are “alive” at any given time and how much space they require cannot necessarily be predicted.<\/p>\r\n\n

      1.3. Static and dynamic – confusing terms<\/h3>\n\n

      RAM is the generic term for SRAM (Static RAM) and DRAM (Dynamic RAM). SRAM and DRAM differ in their physical structure. SRAM is considerably more expensive, but also faster and more power-efficient. Mostly, SRAM is used in microcontrollers. More information about the differences between SRAM and DRAM can be found here<\/a>, for example. <\/p>\r\n

      In the ESP32 documentation, the term DRAM is used for Data RAM to distinguish it from IRAM, the Instruction RAM (see here<\/a>). So, it is not a physical difference, but a functional one.<\/p>\r\n

      Sometimes the SRAM is also called dynamic memory – for example in the Arduino IDE, as we have just seen. Still others mean only the heap when they talk about dynamic memory.<\/p>\r\n

      And to complete the confusion, the global variables and the static local variables are called “Static Data”, which are stored in a specific area of the SRAM.<\/p>\r\n

      I will therefore try to avoid the terms “static” and “dynamic” as far as possible.  <\/p>\r\n\n

      2. The SRAM at a glance<\/h2>\n\n

      In my previous remarks I did not mention the memory area for the registers because it is not available for free use. It is located below the SRAM and is the reason why the memory addresses do not start at zero, but in the case of the ATmega328P at 256:<\/p>\r\n

      \n
      \"The<\/a>
      The SRAM of the ATmega328P<\/figcaption><\/figure>\n<\/div>\nIn the lower area of the SRAM, the already mentioned static data or variables are stored. All other variables are either in the stack or in the heap.\u00a0 The stack is filled from top to bottom, and the heap from bottom to top. If there is not enough memory, the two areas collide (without error message!). In this case, the program will no longer function as desired. However, it is not possible to predict what the specific impact will be.\r\n\r\nForget for a moment the fact that the stack “hangs from the ceiling” like a stalactite and imagine it like a stack of books. There are no gaps due to gravity. New books (e.g. when functions are called) are placed on top of the book stack and taken down again from there (return from the function). Thanks to systematic planning, no books have to be pulled out of the middle or bottom of the book stack. It’s the same with the stack memory, except that the world is upside-down.\r\n\r\nWhen you remove a book from a stack, the gap is filled due to gravity. New books will be placed on top of the pile. It is the same with the stack, except that the world is upside-down.\r\n\r\nA heap is less orderly than a stack – in this respect, the naming of the heap fits well. However, I would describe the heap more as a kind of bookshelf that you (first-)fill strictly from the bottom up. If you take out a book, there will be a gap. Then, when you put a new one in, it will rarely be the same size. If it is smaller, then it will fit in the gap, but the gap will not be completely filled. If, on the other hand, it is larger, it will have to be placed on the top. So, the books are not pushed together to eliminate gaps. And if you don’t do something about it, more and more space on your bookshelf will go unused over time.\r\n\r\nThis problem is called heap fragmentation. In practice, it occurs mainly when string objects are used. But we’ll look at that in more detail shortly, step by step and with practical examples.\n\n

      3. How variables are stored in the SRAM<\/h2>\n\n

      3.1. Example sketch<\/h3>\n\n

      In the first example sketch, we create a motley assortment of variables, and we show where they can be found in the SRAM.<\/p>\r\n\n

      \r\n
      int a = 42;\r\nint b = 43;\r\nint c = 44;\r\n\r\nvoid setup() {\r\n    Serial.begin(9600);\r\n    delay(2000); \/\/ needed for some boards\r\n    int d = 45;\r\n    int e = 46;\r\n    int f = 47;\r\n    char g[] = \"I am a char array\";\r\n    char h[] = \"I am a char array, too\";\r\n    char i[] = \"No surprise what I am\";\r\n    String j = \"I am a string\";\r\n    String k = \"I am a string, too\";\r\n    String l = \"Guess what I am\";\r\n\r\n    Serial.println(F(\"Addresses in SRAM:\"));\r\n    \r\n    Serial.print(F(\"a (int, global): \"));\r\n    printVariableDetails(a);   \r\n    \r\n    Serial.print(F(\"b (int, global): \"));\r\n    printVariableDetails(b);  \r\n    \r\n    Serial.print(F(\"c (int, global): \"));\r\n    printVariableDetails(c);  \r\n    \r\n    Serial.print(F(\"d (int, local): \"));\r\n    printVariableDetails(d);  \r\n     \r\n    Serial.print(F(\"e (int, local): \"));\r\n    printVariableDetails(e);  \r\n    \r\n    Serial.print(F(\"f (int, local): \"));\r\n    printVariableDetails(f);  \r\n    \r\n    Serial.print(F(\"g (char array): \"));\r\n    Serial.print((int)&g);\r\n    Serial.print(F(\" - \"));\r\n    Serial.println((int)&g + sizeof(g) - 1);\r\n    \r\n    Serial.print(F(\"h (char array): \"));\r\n    Serial.print((int)&h);\r\n    Serial.print(F(\" - \"));\r\n    Serial.println((int)&h + sizeof(h) - 1);\r\n    \r\n    Serial.print(F(\"i (char array): \"));\r\n    Serial.print((int)&i);\r\n    Serial.print(F(\" - \"));\r\n    Serial.println((int)&i + sizeof(i) - 1);\r\n    \r\n    Serial.print(F(\"j (String): \"));\r\n    printVariableDetails(j); \r\n    \r\n    Serial.print(F(\"k (String): \"));\r\n    printVariableDetails(k); \r\n    \r\n    Serial.print(F(\"l (String): \"));\r\n    printVariableDetails(l); \r\n}\r\n\r\nvoid loop() {}\r\n\r\ntemplate<typename T>\r\nvoid printVariableDetails(T &i){\r\n    Serial.print((int)&i);\r\n    Serial.print(F(\" - \"));\r\n    Serial.println((int)&i + sizeof(i) - 1);\r\n}\r\n\r\n\/* For those who are not familiar with templates: \r\n * If you have functions to which you want to pass different data types or which shall \r\n * return different variable types, you can use templates to avoid defining several functions\r\n * for each data type like:\r\n * void printVariableDetails(int &i){.....}\r\n * and:\r\n * void printVariableDetails(String &i){.....}\r\n *\/<\/pre>\r\n
       <\/p>\r\n<\/div>\r\n\n
      Here is the output on an Arduino Nano:<\/p>\r\n\n
      \"example_1.ino<\/a>
      example_1.ino – output when using an Arduino Nano<\/figcaption><\/figure>\n\n
      3.2. Review of example_1.ino<\/h3>\n\n
      What we can conclude from this:<\/p>\r\n