Preventing a variable from changing in the long run?

[MikeLemon]

Hi,

I'm attempting to build a simple stopwatch and currently trying to get into making the ESP32 operation reliable in a long time running programms of more than a day, I'm using the esp_timer_get_time() and esp timer function, FreeRTOS to make this code work and

In order to measure time I basically take a reference time point from esp_timer_get_time() into a long global variable in main.c but I'm facing an issue as after around 30minutes or more not sure exactly the Ref point variable appears to be corrupt and gives a wrong time making the timer useless.

What could cause it? how do you prevent it?

I've tryed using decorating my TimeRed Variable with static and voletile but it doesn't work

[mgsecord62]

I believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.

[MikeLemon]

I believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.

Are you sure long isn't defined as int64_t in ESP IDF?

as for the signed or not I thick the last bit signifies the timer overflow maybe shouldn't touch it.

[mbratch]

Are you sure long isn't defined as int64_t in ESP IDF?

Print `sizeof(long)` to your console to tell for sure. I'm guessing you need `long long` to get 64 bits.

Maybe you could show some code detail to help analyze the issue.

[MikeLemon]

I believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.

Turns out you are right, the ESP IDF define a long as a 32 bit number just the same as int, doesn't make sense but what ever, nothing cheap comes perfect

Thanks for helping

[ESP_Sprite]

Turns out you are right, the ESP IDF define a long as a 32 bit number just the same as int, doesn't make sense but what ever, nothing cheap comes perfect

Thanks for helping

That's more-or-less a C quirk and not so much ESP-IDFs fault. C was developed on 16-bit machines, so an int is the native word size of the machine but at least 16-bit. A long is at least 32 bit, and a long long is at least 64 bit. While it's possible to make e.g. a long 64-bit (as the spec defines it as 'at least' 32 bit), many compilers don't as the general assumption is of it to be 32 bit.

If you want to have actual certainty about bit numbers (as in, more than 'at least' 32 bits), you'd use e.g. int64_t, as mentioned earlier.

[MikeLemon]

Turns out you are right, the ESP IDF define a long as a 32 bit number just the same as int, doesn't make sense but what ever, nothing cheap comes perfect

Thanks for helping

That's more-or-less a C quirk and not so much ESP-IDFs fault. C was developed on 16-bit machines, so an int is the native word size of the machine but at least 16-bit. A long is at least 32 bit, and a long long is at least 64 bit. While it's possible to make e.g. a long 64-bit (as the spec defines it as 'at least' 32 bit), many compilers don't as the general assumption is of it to be 32 bit.

If you want to have actual certainty about bit numbers (as in, more than 'at least' 32 bits), you'd use e.g. int64_t, as mentioned earlier.

Guess you realize something new every day it was just weird for me to assume that long is just as big as int and I always had a tendency to specify absolutely what is the length of the variable with the int64_t a like designation, but for some reason in this particular time I went with the word form long instead of the numerical one, but I'm glad we could solve it as simply as that.