next topic »

[on:]

In the online description of math.h (http://www.arduino.cc/en/Math/H) the following comment regarding the Atmega8 chip is made:

The Atmega8 chip, which is now dated, but still supported, does not have enough memory to be able to use the math.h library so you will probably need to update to an Atmega168 if you wish to use any of these functions."

I have tested an Atmega8 chip on an UNO board by calling a couple of functions from the math library.  The sketch basically reads in an analog pin, scale the value to a voltage and then uses Serial to print the values.  I have added 4 functions from math to test what will happen, but everything appeared normal:
x = 5.0000
log(x) = 1.6094
log10(x) = 0.6990
exp(x) = 148.4131
square(x) = 25.0000

No apparent problems (and the 4 math statements added 840 bytes to the sketch size), so I think the math.h web page should be modified so that it does not imply an Atmega8 cannot call these functions.  I suggest that the quoted sentence gets changed to something more accurate such as:

The Atmega8 chip, which is now dated, but still supported, has little memory so care should be taken when calling math functions to not run into memory constraints.

[Reply #1 on:]

I have tested an Atmega8 chip on an UNO board by calling a couple of functions from the math library.

Which functions?

Did you try the sin(), cos(), and atan() functions?

[Reply #2 on:]

I only tested the log, log10, exp & square functions.  I've given my Atmega8 away but will post results for trig functions once I get hold of another one.

There are quite a number of functions in math, I guess the trig ones you mention (sin, cos, atan) are the heaviest on resources?

[Reply #3 on:]

I guess the trig ones you mention (sin, cos, atan) are the heaviest on resources?

I don't know that for a fact, but I suspect that they are near the top of the list in terms of code size to link in the functions.

square() is pretty lightweight. All it does is multiply the input by the input to create the output. Float multiplication is slow, but not particularly difficult. Float division is slower. I don't see that you (directly) tested that. I'm not sure what log and log10 do, internally, but I'd guess that one calls the other.

Perhaps you could add one function at a time, and see how the sketch size changes. Add sin() and see what happens. Then, add cos() and see what happens. Add others, and see when you run into problems.

You might look at the FreeMemory() function, too, to see how the math.h functions affect SRAM.

[Reply #4 on:]

I used the following sketch as baseline for testing math functions:

Code:

void setup(){
  pinMode(13, OUTPUT);
  Serial.begin(115200);
}
int v;
#include <MemoryFree.h>
void loop(){
  v = analogRead(A0);
  Serial.println(v);
  v = freeMemory();
  Serial.println(v);
  delay(1000);
}

This basic sketch compiles to 2714 bytes and the freeMemory function returns 810 bytes.  I called various functions from the math library one by one using the following pattern:
Serial.println(function(v)).  The compiled size of each sketch increased by between 1670 bytes when calling atan(v) & 2310 bytes when calling pow(v, 0.123); the free memory dropped to 808 bytes but stayed constant no matter which function was called.  Other function calls such as sin, cos, tan, log, log10, exp etc. added code that fell between these two extremes.  Finally I made a sketch that calls all the functions mentioned in the online math page:

Code:

void setup(){
  pinMode(13, OUTPUT);
  Serial.begin(115200);
}
int v;
double x, y;
#include <MemoryFree.h>
void loop(){
  v = analogRead(A0);
  Serial.println(v);
  x = (double)v / 234;
  y = 0.123;
  Serial.println(x,8);
  Serial.println(cos(x), 8);
  Serial.println(fabs(x), 8);
  Serial.println(fmod(x, y), 8);
  Serial.println(modf(x, &y), 8);
  Serial.println(sin(x), 8);
  Serial.println(sqrt(x), 8);
  Serial.println(tan(x), 8);
  Serial.println(exp(x), 8);
  Serial.println(atan(x), 8);
  Serial.println(atan2(x, 0.1), 8);
  Serial.println(log(x), 8);
  Serial.println(log10(x), 8);
  Serial.println(pow(x, 0.123), 8);
  Serial.println(square(x), 8);
  v = freeMemory();
  Serial.println(v);
  delay(10000);
}

This sketch compiled to 6428 bytes and the free memory reported was 800 bytes.  Clearly there is sufficient flash memory and SRAM available on the Atmega8 chip to call some math functions and still have enough resources to do other stuff like read an analog pin and send data over the serial port.

[Reply #5 on:]

Then, I agree that the original warning is a bit over the top. Where do you draw the line, though, and how do you define, in terms that everyone can understand, what happens when you use more than your available memory (both SRAM and Flash)?

[Reply #6 on:]

Hmm, that is more of a philosophical question than a technical one I'm afraid.  I have recently ran into memory problems (on an Uno) reading data into a buffer and then transmitting that buffer to a PC over a serial connection.  Everything worked fine and I started increasing the buffer size and things worked even better, I increased the buffer size some more and suddenly nothing worked.  I struggled to identify the problem until I saw a similar problem on a board with an Atmega8, but the error occurred at smaller buffer sizes.  I kept looking at the binary sketch size thinking that there was plenty of memory left to work with. Once I realized there is a difference between flash & SRAM memory it was easy to trace the problem back to the size of the buffer that overfilled SRAM.

Memory limitations, management & troubleshooting is probably worth a web page on its own.