stack overflow?

I believe i may have overflowed the stack however i am not sure can somebody else have a second opinion? I have just done something stupid.

    frequency = (100000*crossed)/(100*sample_split*32);
    Serial.print(crossed);
    Serial.print("   ");
    Serial.println(sample_split);
    Serial.print("   ");
    Serial.println(frequency);

this is the output of printing.
11 20
4294966580

That code doesn't compile. So, how are we to test it? You also didn't specify which Arduino board.

If i gave you full code it wouldnt work as i am talking to another board that is connected to a bluetooth mobile app. However you have all the variables used in the equation i have ran it into a calculator and comes nowhere near what the arduino is makes it out to be. i have made a small modification to see the memory however it appears to have plenty. the board is an arduino mega.

    frequency = (100000*crossed)/(100*sample_split*32);
    Serial.print(crossed);
    Serial.print("   ");
    Serial.println(sample_split);
    Serial.println(frequency);
    Serial.println(freeMemory());
    Serial.println("   ");

output is

11 20
4294966580
7007

i'd need to see the variable types. is crossed long?

crossed and sample_split are uint8_t and frequency is uint32_t

these are my local variables i also had a buffer that was uint8_t buffer[318][2] which i made global thinking it may help with the stack.

  uint8_t vmin = 255;
  uint8_t vmax = 0;
  uint16_t i = 0;
  uint8_t threshold = 0;
  uint16_t crossed = 0;
  uint8_t sample_split = 0;
  uint16_t volt_split = 0;
  uint16_t volt_split_ref = volt_split;
  uint32_t frequency = 0;
  uint32_t frequency_ref = frequency;
  uint16_t time_div = 0;
  uint16_t time_div_ref = 0;

Learn how to make an MRE.

the problem with an mre is that if i create the same scenario in a simplified sketch the stack would not over flow.

i have placed this code into a c++ shell http://cpp.sh/ and the results are very different.

// Example program
#include <iostream>
#include <string>

int main()
{
  std::string name;
  uint8_t crossed = 11;
  uint8_t sample_split=20;
  std::cout << (1000000*crossed)/(1*sample_split*32);
}

Yes this is c++ however the behaviour should be the same.

the output is 17187

zoltan1337:
Yes this is c++ however the behaviour should be the same.

No.

int type on arduino is 16-bit
int type on most desktop platforms is 32-bit

What makes you thing you have overflowed the stack?
You've exceed the range of the int type. That's integer overflow.

frequency = (100000L*crossed)/(100L*sample_split*32);

I see someone already posted the answer, but a bit more explanation:
The calculation by default will be done using 16-bit integers, which is causing an overflow condition where the number is too large to be stored in 16 bits. Explicitly declaring that one of the numbers is a 32-bit long in each of the multiplications will cause the calculation to be done using 32-bit integers and give the correct answer.

  frequency = (100000L * crossed) / (100L * sample_split * 32);

The problem you are having with the mre is that the compiler knows enough at compile time that it is doing the calculation during compilation and hard coding the answer into the code.

i get the following results (the denominator is truncated)

crossed 11
sample_split 20
frequency 17
#if 0
uint16_t    crossed = 11;
uint8_t     sample_split = 20;
uint32_t    frequency = 0;
#else
uint16_t    crossed = 11;
uint16_t    sample_split = 20;
uint32_t    frequency = 0;
#endif

void calc (void) {

    Serial.print   ("crossed ");
    Serial.println (crossed);

    Serial.print   ("sample_split ");
    Serial.println (sample_split);

    frequency = (100000*crossed)/(100*sample_split*32);

    Serial.print   ("frequency ");
    Serial.println (frequency);
}

// -----------------------------------------------------------------------------
void setup() {
    Serial.begin (9600);

    calc ();
}

// -----------------------------------------------------------------------------
void loop() {
}

Thank you i thought bit lengths where universal

Just as an examples, this is an mre what will demonstrate the problem you were having. The compiler can make it frustrating at times, because it is very good at optimizing code and will remove code and variables that it sees as unneeded.

uint16_t crossed = 0;
uint8_t sample_split = 0;
uint32_t frequency = 0;

void setup(void) {
  Serial.begin(9600);
  delay(1000);
  //use random numbers to make sure calculations are done at runtime
  //note - random will always generate an identical sequence of numbers 
  //       unless you use randomSeed(), so the final number is predictable
  crossed = 10 + random(3);
  sample_split = 19 + random(3);
  
  frequency = (100000 * crossed) / (100 * sample_split * 32);
  Serial.println("math with 16-bit integers");
  Serial.print(crossed);
  Serial.print("   ");
  Serial.print(sample_split);
  Serial.print("   ");
  Serial.println(frequency);

  frequency = (100000L * crossed) / (100L * sample_split * 32);
  Serial.println("math with 32-bit integers");
  Serial.print(crossed);
  Serial.print("   ");
  Serial.print(sample_split);
  Serial.print("   ");
  Serial.println(frequency);
}

void loop() {

}

100000 x 11 = 1,100,000 = 0x10C8E0
Because 1000000 exceeds the size of a int (16-bits) this calculation and result uses long (32-bit)

100 x 20 x 32 = 64,000 = 0xFA00
Because none of these values exceed the size of int, the calculation and result uses int (16-bit)
0xFA00 in 16-bit signed is MINUS 1,536
You have overflowed the maximum range of an int

1,100,000 / - 1,536 = -716 = 0xFFFFFD34

Because (presumably) frequency is unsigned...
0xFFFFFD34 = 4,294,966,580

zoltan1337:
Thank you i thought bit lengths where universal

No, the C standard says you are free to chose any size of 16-bits or greater.

On 8-bit platforms with limited resources and no hardware acceleration it is very common to see the default size of int as 16-bits.
As Dave would say: A trap for new players.

zoltan1337:
Thank you i thought bit lengths where universal

you defined sample_split as uint8_t.

the problem is the compiler calculated the intermediate value, the denominator delimited within the parenthesis, with the same number of bits.

And, of course, none of this has any thing to do with the thread's title: "stack overflow".

gfvalvo:
And, of course, none of this has any thing to do with the thread’s title: “stack overflow”.

Other than the OP’s speculation that the error was being caused by a stack overflow.