2020-09-11 05:59 AM
Hello,
I use signed integers since a long time in delay calculations using 16 or 32 bit counters.
Indeed, it suffices to do a simple signed subtraction between the two counter values to obtain an exact delay even if the counter has looped back in the meantime (only once max loop of course)
Is it possible to change declaration of HAL_GetTick () to int32_t and not uint32_t ?
It is a source of errors that are difficult to detect on a machine operating 24 hours a day.
With a 32b counter per millisecond, it takes only about 50 days to complete the loop.
cordially
2020-09-11 06:17 AM
> it suffices to do a simple signed subtraction between the two counter values to obtain an exact delay even if the counter has looped back in the meantime (only once max loop of course)
The same is true for an unsigned subtraction.
> Is it possible to change declaration of HAL_GetTick () to int32_t and not uint32_t ?
If you want to edit all instances of the function and where it's used, sure. But that seems like a lot of work for little gain.
2020-09-11 06:20 AM
uint32_t dont have an issue computing delta time that crosses the wrap point.
2020-09-11 07:18 AM
uint is used in HAL_GetTick() because unsigned overflow is well defined in C/C++, signed overflow is undefined.
Test with a 8 bit value:
the delta value is: 0x01 - 0xFE = 0x03 (the expected value).
You can't use a simple substraction on 32 bits signed integers.
2020-09-11 08:11 AM
We spent years getting this kind of brain damage out of the ST code
uint32_t finish_time = HAL_GetTick() + 100;
while(1)
if (HAL_GetTick() > finish_time) break;
2020-09-11 10:25 AM
Yes I also checked on 8b.
I don't remember where this error came from, but it has been stuck in my mind for a long time. Like what, you always have to question yourself.
It at least allowed me to review my copy.
thank you all