1

In my project I need three arrays to store data inside.

I define a maximal number of elements as a macro variable. However, at a certain point in the setup function, the program could determine, that the arrays would actually store a smaller number of elements. In other words, it is possible (and even likely) that there is more memory reserved for the arrays than actually necessary.

As I think that memory might be a critical factor on a micro controller like the Arduino, I would like to set the excess memory free.

Is there a way to dynamically resize and shrink the arrays at runtime?

Something like this (pseudocode)

#define maxSize 50
int theArray[maxSize];

int actualSize = getActualArraySize();
// sets actualSize to a value <= 50, let's assume actualSize = 20
shrinkArray(theArray, actualSize);
// shrinkArray doesn't exist :) I need something like that.
  • 1
    Arrays can not be resized, but if you know the required size of the array before any data is written into it, you can declare theArray as a pointer instead of array: int *theArray; and then later allocate the required amount of memory: theArray = malloc(requredArrayLength * sizeof(int)); - Would that solve your problem? – jarnbjo Nov 15 '16 at 12:19
  • 2
    However, if it is not the case that you somewhere else use an inversely proportional amount of memory to the size of these arrays, it might not be necessary to save bytes here. E.g. if you conditionally reduce an array of ints from 50 to 30 elements, you will save 40 bytes of memory only if the condition is met and you can not rely on this memory always being available for other purposes. – jarnbjo Nov 15 '16 at 12:27
  • 2
    I am not sure if you understood what I wrote in my second comment. What are you intending to use the 120 bytes for, which you may save, as long as you won't be sure if the memory is actually available. Do you have any other parts of your code, which will need more memory if a short password is configured? If not, spare yourself the effort and forget about those 120 bytes, since you won't have any situation, in which you can use them. – jarnbjo Nov 15 '16 at 13:57
  • 2
    The amount of memory available has no bearing on the speed the MCU runs at all. You are thinking of a phenomenon on PCs where when there is not enough memory available some memory is "swapped" to hard disk, which slows it down. Since there is no hard disk, no swapping, no memory management, none of that applies. So speed can never be affected by lack of RAM in the way you are supposing. – Majenko Nov 15 '16 at 14:33
  • 1
    Neither a microcontroller, nor a desktop computer will magically run faster if you use less RAM. On a desktop computer, your software is usually running in a multitasking environment and it might be advantageous to save RAM to leave resources for other processes, but on the microcontroller you are 'on your own' and can manage the resources as you need them and not worry about other processes. – jarnbjo Nov 15 '16 at 14:34
1

This is a common question when designing software. The simple answer (rule of thumb) is statically allocate the maximum size of the array. In this case the maximum size of the arrays. This simple rule will keep you out of trouble and make testing etc much simpler.

Using dynamic allocation (adjusting array size etc) especially for small scale embedded systems such as the Arduino opens a "can of worms" with possible memory (heap) fragmentation and hidden concurrency and performance issues.

If the required maximum size of the array is 32 elements the application has to allow that and there is no memory to save. Statically allocating will make the sketch simpler and easier to test.

Cheers!

  • 1
    To elaborate a little, while you CAN allocate the arrays smaller, there's really no point leaving some memory free: the program has to work even in the worst case, with the arrays as big as they'll ever be, and it won't work any better if you sometimes have some memory left over. – Mark Smith Nov 15 '16 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.