Variable "on the fly"

I was reading about creating variables within the loop() and it seems to be impossible to do in arduino.
I am currently sending a message from the phone’s bluetooth and inside the loop it is separated (uning Separador.h library) into data that i then transform inside the loop() into “text”, input effect, output effect, speed, intensity of the leds and pause, the text is projected on a led screen through the MDparola.h library. This works great.
My problem is the following:
I want to project a number m of messages, creating a number m of variables(on the fly). How can it be done?

    for (int n = 0; n < m; n++)
    {
      mens[n * 6 + 1] = s.separa(texto_entrada, ',', n * 6 + 1);
      
      mens[n * 6 + 1].toCharArray(buffery[n * 6 + 1], 200);
      
      effecte[n * 6 + 2] = s.separa(text_in, ',', n * 6 + 2).toInt();
      effects[n * 6 + 3] = s.separa(text_in, ',', n * 6 + 3).toInt();
      speed1[n * 6 + 4] = s.separa(text_in, ',', n * 6 + 4).toInt();
      int[n * 6 + 5] = s.separa(text_in, ',', n * 6 + 5).toInt();
      pause[n * 6 + 6] = s.separa(text_in, ',', n * 6 + 6).toInt();
  
    }
.
.
.
P.displayText(buffery[cm], PA_LEFT, speed1[cm], pausa[cm], efectoe[cm], efectos[cm])
.
.
.

Of course you can create variables within loop. Just declare them. But I don't think that is what you mean.

data that i then transform inside the loop() into "text"

Some functions that create "text" from variables:

itoa() and ltoa() convert integers into ASCII strings ("text").

dtostrf() does the same for floats.

sprintf() converts all types of variables into one or more lines of text.

Similar functions convert ASCII text into numerical values, like atol() and atof().

the RAM memory of arduino chips is far smaller than the ram used in PC's and phones. most languages intended for operating systems with several gigs of ram can easily expand dynamic requests for more memory on the fly to add last minute variables and resize arrays but this is an inefficient process.

in arduino land. things work differently. you must declare the variables you will be using in the sketch. there is no big operating system running in the background to hand out more memory in the middle of runtime.
so the the official answer to your question is "NO".

the good new is that these little board can still do big things.
if you are unsure of how big an array may need to be, it is common practice to simply declare your arrays
to the biggest length they could possibly become. as long as the memory is available there is no downfall to having an array with 100 elements and only using 10. this approach is still more efficient than literally reassigning memory for an unknown amount of variables.

if you believe your sketch is approaching your ram limit then there is indexing techniques to hand out bytes for different purposes like an operating system would but it would need to be coded yourself or through a library and would be more inefficient that using the "big array" buffer techique i mentioned first.

this is a main diffence between arduino programming and C# or java.
arduino sketches dont allow resizing of arrays. even if you could you wouldnt want to for profficiency reasons. there are always work arounds though.

jremington and taterking, thaks so much!

I will decrare a number of m=20 variables after the loop() s...

Let me test it...

taterking:
the RAM memory of arduino chips is far smaller than the ram used in PC’s and phones. most languages intended for operating systems with several gigs of ram can easily expand dynamic requests for more memory on the fly to add last minute variables and resize arrays but this is an inefficient process.

in arduino land. things work differently. you must declare the variables you will be using in the sketch. there is no big operating system running in the background to hand out more memory in the middle of runtime.
so the the official answer to your question is “NO”.

the good new is that these little board can still do big things.
if you are unsure of how big an array may need to be, it is common practice to simply declare your arrays
to the biggest length they could possibly become. as long as the memory is available there is no downfall to having an array with 100 elements and only using 10. this approach is still more efficient than literally reassigning memory for an unknown amount of variables.

if you believe your sketch is approaching your ram limit then there is indexing techniques to hand out bytes for different purposes like an operating system would but it would need to be coded yourself or through a library and would be more inefficient that using the “big array” buffer techique i mentioned first.

this is a main diffence between arduino programming and C# or java.
arduino sketches dont allow resizing of arrays. even if you could you wouldnt want to for profficiency reasons. there are always work arounds though.

There’s a whole lotta mis-information in there. Memory in the Arduino is allocated in PRECISELY the same manner as in a PC, using malloc, and it’s brethren. The only difference is there is much less RAM to allocate. Arrays CAN and other data objects can be created, destroyed and re-sized, if done properly. But, it is not for beginners who don’t fully understand what the’re doing.

Regards,
Ray L.

RayLivingston:
There's a whole lotta mis-information in there. Memory in the Arduino is allocated in PRECISELY the same manner as in a PC, using malloc, and it's brethren. The only difference is there is much less RAM to allocate. Arrays CAN and other data objects can be created, destroyed and re-sized, if done properly. But, it is not for beginners who don't fully understand what the're doing.

Regards,
Ray L.

the big difference is the lack of garbage collection. So if you keep allocating and freeing the same size things over and over you're probably OK. But as soon as you start allocating and freeing things of different sizes you end up with holes in the heap memory where things just don't fit. Eventually the whole thing is full of little holes and you can't allocate anymore space even though you're only using like half the total heap memory because you can't find a hole big enough to hold what you want to allocate.

On the PC you have code that goes in and "defragments" the RAM for lack of a better word. Without that dynamic allocation ends up working for a while and crashing the program after some time.

Definitely need to know exactly what you're doing to use dynamic memory on a small micro like this. You have to handle everything yourself. You don't have an OS there to do all those housekeeping tasks.

Delta_G:
the big difference is the lack of garbage collection. So if you keep allocating and freeing the same size things over and over you’re probably OK. But as soon as you start allocating and freeing things of different sizes you end up with holes in the heap memory where things just don’t fit. Eventually the whole thing is full of little holes and you can’t allocate anymore space even though you’re only using like half the total heap memory because you can’t find a hole big enough to hold what you want to allocate.

Size of the blocks is not so much the issue, it is more their locations that is the issue. When a block is freed, if it is adjacent to another free block, the two will be joined into a single, larger free block. So, it does what it reasonably can to maintain as many large blocks of free memory as possible. IIRC, malloc also will allocate from the smallest free block that can satisfy the request. Regardless of the size of the blocks you’re allocating, if you’re doing huge numbers of mallocs on an Uno, you surely have a poor design. With reasonable use, at the hand of someone who understands how it works, it works just fine.

Regards,
Ray L.