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
Preventing a variable from changing in the long run?
-
- Posts: 19
- Joined: Thu Nov 02, 2017 12:40 am
Re: Preventing a variable from changing in the long run?
I believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.
Re: Preventing a variable from changing in the long run?
Are you sure long isn't defined as int64_t in ESP IDF?mgsecord62 wrote: ↑Fri Apr 01, 2022 5:49 pmI believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.
as for the signed or not I thick the last bit signifies the timer overflow maybe shouldn't touch it.
Re: Preventing a variable from changing in the long run?
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 perfectmgsecord62 wrote: ↑Fri Apr 01, 2022 5:49 pmI believe that you need to use a int64_t type for your variable. A (signed) long variable will overflow at ~2147 seconds.
Thanks for helping
-
- Posts: 9709
- Joined: Thu Nov 26, 2015 4:08 am
Re: Preventing a variable from changing in the long run?
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.
Re: Preventing a variable from changing in the long run?
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.ESP_Sprite wrote: ↑Mon Apr 11, 2022 1:07 amThat'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.
Who is online
Users browsing this forum: jsmith56x and 182 guests