New answers tagged memory-usage
-1
As someone interested in how hardware enables computing, there are actually a number of fascinating facts as to why the heap is dangerous on embedded systems beyond just not having much RAM. Most issues you'd encounter with an Arduino or similar system are not from exceeding the RAM's size with variables, but from memory fragmentation. This is a side effect ...
1
I'm adding this not so much to add to the answer as to add some real world implications for those that may be down this particular rabbit hole. It's nice to talk about what could happen theoretically, but a new programmer may still be tempted to think that he can out-think these limitation and still do something useful. Here is some real world talk about ...
4
For starters, fix your library
As noted by @crasic, dynamic memory allocation is generally not recommended for embedded systems. It may be acceptable for embedded devices which have a larger amount of free memory - embedded Linux is commonly used, for example, and all Linux apps/services will tend to use dynamic memory allocation - but on small devices such ...
6
Dynamic allocation is generally discouraged in embedded applications because you cannot guarantee that you do not exceed (attempt to allocate more than) the available memory. Static allocation will generally have this guarantee although out-of-memory bugs may still be possible.
Additionally, far fewer services or tools are available to automatically manage ...
15
Most Arduinos (like the Uno or Nano) have very few RAM, thus you first need to make sure, that you never allocate too much memory. Also dynamically allocating memory can lead to heap fragmentation (heap being the part of memory, where dynamic allocation happens).
In most cases you would want to allocate memory of different sizes (for example arrays of ...
4
You have probably learnt that objects created with new are stored in
the heap, while globals are stored in the .data and .bss sections, and
locals on the stack¹. This distinction, however, only exists in the
software. At the hardware level, .data, .bss, heap and stack are just
arbitrary portions of the RAM.
Think of what would happen if the RAM was erased, ...
0
It is now very common to read from EEPROM in an ATTiny, particularly an OSCCAL value. It has also been the case for some embedded devices to perform a superfluous write and read back to external EEPROM during POST. Every boot.
In addition, available cores include options to suppress EEPROM erase in programming, this is fuseable.
In ancient times AVRDUDE ...
0
An AVR-based Arduino is a poor choice for writing an "OS" in the modern sense. It's just too resource constrained. It doesn't have enough RAM, it doesn't have enough flash memory, it's too slow, it doesn't have protected memory or paging, it doesn't have video display, it doesn't have a file system, and on and on.
If you look at an Apple II, ...
Top 50 recent answers are included
