Measure rate of change

[Nico3]

I am measuring temperature from sensor via i2c in a loop with one second delay. There are various other functions also in loop. Those functions may take time from 10ms to 500 ms depending on Rx_Callback. 

I need to measure rate of change of temperature from sensor. I can implement HAL_Gettick() to get accurate time internal between two measurements. But I am afraid that HAL_Gettick() counter will reset to 0 after few days. 

Is there any other way to measure accurate timing between two measurements of temperature ?

[LCE]

> But I am afraid that HAL_Gettick() counter will reset to 0 after few days.

So what? Shouldn't be a problem with the correct unsigned integer calculations.

[TDK]

HAL_Gettick resets after ~50 days.

Temperature rate of change is generally slow. A better method would be measure the change over the past ~minute or 10 seconds or something. 10ms is too quick for this measurement, the resolution of a temperature sensor is quantized and isn't going to yield an accurate delta over such small time scales.

Using HAL_GetTick is fine. Could also use a timer to get more accuracy, but timing accuracy isn't going to help much here.

[Nico3]

rate = (T2- T1)/(Tick2- Tick1)

when counter is reset, Tick1 :  XXXXXX   (some big number)

Tick2: 0

At this step, the calculated rate will be wrong. please correct me where I am wrong. 

[Nico3]

yes, I think i didn't write clearly. I am measuring temperature every one second approx. There is while loop with one second delay. 

Basically needs temperature gradient to know if there is any fire or abnormal heating. 

I was thinking to use one second time for gradient calculations but isn't tick from Hal_Get give me more accurate time between two time measurements. 

I also want to avoid using Timer.

[LCE]

Check unsigned integer arithmetic, I think it's called wrap-around when an overflow occurs. So make sure that the tick difference is an unsigned value, then it should always give the correct number - if I'm not mistaken...

So do something like this:

uint32_t u32TickNow = HAL_GetTick();
uint32_t u32TickDiff = u32TickNow - u32TickOld;
u32TickOld = u32TickNow;

rate = (T2 - T1) / u32TickDiff;

[TDK]

For HAL_GetTick, which uses a uint32_t counter, the calculation will be correct. That is why it was chosen that way. Convince yourself:

uint32_t start = 0;
uint32_t end = 0;
start -= 42;
// verify that start is a large value and end == 0
uint32_t delta = end - start;
// verify that delta == 42

[Pavel A.]

The next C standard, C23, will (or already does) support sized integer types other than 8/16/32/64 bits.  This compiler will correctly handle the same unsigned wrap-around trick with, for example, 24-bit values.