Preventing a variable from changing in the long run?

MikeLemon
Posts: 45
Joined: Tue Feb 02, 2021 5:55 pm

Preventing a variable from changing in the long run?

Postby MikeLemon » Fri Apr 01, 2022 5:20 pm

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
Posts: 19
Joined: Thu Nov 02, 2017 12:40 am

Re: Preventing a variable from changing in the long run?

Postby mgsecord62 » Fri Apr 01, 2022 5:49 pm

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

MikeLemon
Posts: 45
Joined: Tue Feb 02, 2021 5:55 pm

Re: Preventing a variable from changing in the long run?

Postby MikeLemon » Fri Apr 01, 2022 6:21 pm

mgsecord62 wrote:
Fri Apr 01, 2022 5:49 pm
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.

User avatar
mbratch
Posts: 303
Joined: Fri Jun 11, 2021 1:51 pm

Re: Preventing a variable from changing in the long run?

Postby mbratch » Fri Apr 01, 2022 9:03 pm

MikeLemon wrote:
Fri Apr 01, 2022 6:21 pm
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
Posts: 45
Joined: Tue Feb 02, 2021 5:55 pm

Re: Preventing a variable from changing in the long run?

Postby MikeLemon » Sun Apr 10, 2022 8:08 pm

mgsecord62 wrote:
Fri Apr 01, 2022 5:49 pm
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 :D

Thanks for helping :)

ESP_Sprite
Posts: 9709
Joined: Thu Nov 26, 2015 4:08 am

Re: Preventing a variable from changing in the long run?

Postby ESP_Sprite » Mon Apr 11, 2022 1:07 am

MikeLemon wrote:
Sun Apr 10, 2022 8:08 pm

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 :D

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
Posts: 45
Joined: Tue Feb 02, 2021 5:55 pm

Re: Preventing a variable from changing in the long run?

Postby MikeLemon » Mon Apr 11, 2022 9:18 am

ESP_Sprite wrote:
Mon Apr 11, 2022 1:07 am
MikeLemon wrote:
Sun Apr 10, 2022 8:08 pm

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 :D

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.

Who is online

Users browsing this forum: jsmith56x and 182 guests