Array size (bytes)

Hello!

I am trying to make a lookup table for accurate sensor readings. For testing purpose, I have made a code consisting of 200 random values between 0 and 200.

Using integers in this example gives 200x 2 bytes(16bit) so 400 bytes, this fills my RAM memory so I will place it in another memory

The strange thing is while compiling the sketch uses only 190 bytes while the array is 400?

Why does the compiler show me a smaller value? and which one is true? Using an Arduino Uno the memory space for variables is expensive.

Thanks in advance, code below:

#include <Arduino.h>
int f     = 0;
int Size  = 0;
int i     = 0;
int LUT[] = {
86,39,51,133,50,138,162,1,2,58,169,76,139,
120,69,53,58,88,114,0,113,
163,119,42,14,26,105,8,106,85,101,122,75,110,87,43,163,10,102,82,155,97,100,170,112,
76,116,69,41,85,50,66,25,159,95,154,129,64,141,99,113,81,120,102,126,162,98,156,75,153,44,66,147,2,93,63,
21,11,174,157,46,74,126,135,61,48,62,177,101,144,105,176,25,
122,137,103,163,74,148,14,175,126,79,56,13,156,139,75,156,
36,105,175,33,109,168,19,73,13,66,88,39,131,39,156,101,25,131,50,
82,161,51,67,60,158,110,49,135,58,19,45,88,74,24,134,9,51,43,151,155,
71,44,34,20,1,84,114,136,150,169,58,117,176,54,56,52,132,137,1,93,40,36,18,167,46,116,112,104,
85,24,58,107,159,73,130,80,140,11,38,165,7,0,109,77,28,139,129,26,69,39,
35,53};


void setup() {
  i = 0;
Serial.begin(9600);
}

void loop()   {
  f =  LUT[i];
  Size = sizeof(LUT);
  Serial.println(Size);
  delay(10000);
}

Which Arduino are you using?

Please, screenshot with the compilation message something like:

Must be something in the compiler, using version 1.8.8 I'm seeing the same results as the OP, but if I do something as simple as print the value of f the memory usage increases to include the array.

Adding Serial.println(i) gives 1984 bytes program storage space, 192 bytes dynamic memory,

Change to Serial.println(f) gives 2398 bytes program storage space, 594 bytes dynamic memory.

The compiler must be optimizing the array out of existence since the only use of its contents is to set a variable that is never used.

david_2018:
Must be something in the compiler, using version 1.8.8 I'm seeing the same results as the OP, [...]

Post#1 has used UNO and IDE 1.8.5. The following screenshot shows the compilation result as to the usage of memory space.

RAM space used :596 bytes

Oops, forget which computer I was on, this one is still running 1.8.7, and compiling for an UNO.

IDE 1.8.8

Compiling for UNO,

also tested with Atom w PlatformIO with same results

Please, screenshot with the compilation message something like:

Or even better copy the text and paste it here in code tags like this

Sketch uses 1450 bytes (4%) of program storage space. Maximum is 30720 bytes.
Global variables use 188 bytes (9%) of dynamic memory, leaving 1860 bytes for local variables. Maximum is 2048 bytes.

Screenshots - just say NO !

UKHeliBob:
Or even better copy the text and paste it here in code tags like this

Sketch uses 1450 bytes (4%) of program storage space. Maximum is 30720 bytes.

Global variables use 188 bytes (9%) of dynamic memory, leaving 1860 bytes for local variables. Maximum is 2048 bytes.



Screenshots - just say NO !

This is really very good! But, I wished to test the OP that he has really compiled the sketch.

Don't worry about it, the compiler can see that you do nothing with the array, so it optimized it away. Once you do something with it, you'll get the answer you're expecting.

The fact that sizeof doesn't count as using the array is a little intriguing though.

@OP

Yes! You have really compiled it; sometimes, we fail to develop confidence! Sorry for any kind of inconvenience.

Okay I will keep that in mind, thanks for the answers!

A nasty compiler optimizer. If I did not check it I would easily run out of space.

If you have a maximum value of 200 then you should use byte instead of int so that array takes up half the space.

Metallor:
If you have a maximum value of 200 then you should use byte instead of int so that array takes up half the space.

Coincidentally, all array items are less that 200; so, the OP can easily declare the array with type byte. The RAM usage comes down to 394 bytes in place of of 590 bytes with IDE 15.0 and UNO.

wildbill:
The fact that sizeof doesn't count as using the array is a little intriguing though.

sizeof() does not reference any contents of the array, only its size. The array size is known at compile time, so the compiler still knows the size of the array even if it optimizes all the contents out. Assigning it to the variable f doesn't count, because f itself is never used so it is also optimized away. If you want to ensure that variable access is never optimized out by the compiler, declare the variable volatile.

I am trying to make a lookup table for accurate sensor readings. For testing purpose, I have made a code consisting of 200 random values between 0 and 200.

Why do you believe you need such a large table? What are you using it for? 200 elements is a very large amount, and I'm not sure what it would do to assist "accurate sensor readings". What sensor, and for what purpose? I smell the whiff of a potential XY problem.

@Jiggy-Ninja

It sounds like you love some challenges, In a previous post on the project page, I asked what would be faster a 3 or 4th order functions or a LUT with or without interpolation.

It is a project at home in my free time, I'm building an inverted pendulum with PID or in the future LQR control.

The pendulum is on a linear rail and moved with a timing belt and a reduction to the DC motor.

After some experimenting and some search, I have discovered that using a PWM frequency to control comes with pros and cons. When using short ON times the current has not enough time to rise when using a high-frequency PWM. When the pendulum is stable the corrections needed are small and thus results in short PWM pulses.

My plan was to measure with a force sensor(strain gauge) what the force will be on the belt on different PWM signals. And then fit a function on it or use a LUT to be able to control precisely.

Future plans are using a BLDC motor but that will be the next chapter.

*note, I've tried a LUT and a function (example as above) in MATLAB to calculate the calculation time. It gave me a 4 times faster response when using the function.

I'm curious what you're thoughts are :slight_smile:

Most of the time when people ask about weird or crazy things it's because they don't know what they're doing. It looks like that doesn't apply to you and you've done your homework. :smiley:

This is a pretty classic case of the speed-memory tradeoff in Comp-Sci. Pre-computed tables take more memory, but are faster. A formula saves a lot of that memory, but takes CPU cycles to compute. If you need the speed and have the memory, you might as well use it.

When using short ON times the current has not enough time to rise when using a high-frequency PWM.

What frequency is your PWM exactly? If you're using the default frequency of an Uno, that's very slow. 1 or 2 kHz I think, which might be too slow for fine control. What frequency is your control loop running at? Your PWM frequency should be several times faster than the control loop freqeuncy, and the control loop frequency should be several times faster than the response time you want out of the physical system.

Motors are basically only controlled with PWM (especially BLDCs), it's just important to use the right specs for your PWM to make it work properly.