Getting the TimeStamp betterway in ms in STM32F4

[darla14]

Posted on May 09, 2016 at 06:15

How can we get the timestamp information in a better way in ms - using systick configured @1ms and calling HAL_GetTick() to get the time in ms or using RTC?

#systick #priority #!stm32f4-!stm32f401-!rtc #stm32f4

[markb]

Posted on May 09, 2016 at 07:25 This is what I am using...

time_t getRTCAsUnixTime(void) {
RTC_DateTypeDef date;
RTC_TimeTypeDef time;
HAL_RTC_GetTime(&hrtc, &time, FORMAT_BIN);
HAL_RTC_GetDate(&hrtc, &date, FORMAT_BIN);
struct tm tm = {
tm_sec: time.Seconds,
tm_min: time.Minutes,
tm_hour: time.Hours,
tm_mday: date.Date,
tm_mon: date.Month - 1,
tm_year: date.Year + 100,
tm_isdst: 0
};
return mktime(&tm);
}

volatile uint64_t utc; // mS since epoch

void HAL_SYSTICK_Callback(void) {
// other stuff here that has to be done each ms
++utc;
}

utc = (uint64_t)getRTCAsUnixTime() * 1000;

[darla14]

Posted on May 09, 2016 at 10:36

Hi,

struct tm tm = {
tm_sec: time.Seconds,
tm_min: time.Minutes,
tm_hour: time.Hours,
tm_mday: date.Date,
tm_mon: date.Month - 1,
tm_year: date.Year + 100,
tm_isdst: 0

is

struct tm tm correct?

code is not compilable.

[Andrew Neil]

Posted on May 09, 2016 at 11:11

''How can we get the timestamp information in a better way''

''Better'' than what?In what way(s), exactly, do you want it to be ''better''? Or, in other words, how do you think your current way is inadequate?

[darla14]

Posted on May 09, 2016 at 12:29Better in the way that it is not affected by the interrupts.What pripority we have to set for systick in case we are using it and if there are other peripheral interrupts whose priority is more than Systick will it not prevent from Systick getting updated., in terms of precision in granularity, in terms of ease of Port from one family to another(F4 to L4 port) and in terms when the MCU goes to sleep.I have seen that the behaviour of my system is different if I base my solution on the basis of SysticTimer vs on the basis of rtc time.

[Tesla DeLorean]

Posted on May 09, 2016 at 14:56

As explained here several times the issue with SysTick is that it must PREEMPT, which is not the same as the classic ''priority'' mindset. You need to adjust the Priority Grouping, and reconfigure the handler settings, so the interrupt occurs even if you are in other interrupts spinning.

Better yet, don't use a software timer for these purposes, and don't idle in interrupts. Consider using a 32-bit timer (TIM2) clocking at 1 MHz (1 us) or a fractional second as accommodated by the 16-bit prescaler. If the chip powers down in STANDBY you'd need to use the RTC, but where it is just the CPU sleeping and the TIM keeps clocking, a timer would be fine. Perhaps the code example doesn't compile because it uses C++ like syntax rather than strict C. Check your compiler option settings, or just add some bracketed scope.

[markb]

Posted on May 09, 2016 at 16:44 -std=gnu99

[darla14]

Posted on May 12, 2016 at 09:19Is there a possibility of Systick Timer getting reset ,what I mean is can HAL_GetTick() becomes zero or rolled over? It has a return type of uint32, does that means if we configure Systick @1ms  then we cab get HAL_getTick() max value = 0xFFFFFFFF

  = 49 days.?

what will be the value after 49 days? 0? can HAL_GetTick() return Zero in between in any case without shutting down the system?

[Tesla DeLorean]

Posted on May 12, 2016 at 09:53

It will roll over, and provided you do the 32 bit unsigned math properly this will all work fine unless your desired timeout actually exceeds 50 days.

With two time stamp values a and b, delta = b  - a, delta will be the elapsed ticks. Do, and understand, the math.

[darla14]

Posted on May 12, 2016 at 10:07

yes I am taking the elapsed ms(ticks) as delta

if((HAL_GetTick() - oldTimeTick) >= 1000) {//do task}

oldTimeTick is of uint32 types. , Here as you said there will not be any reset or rollover condition before ~49 days.Right?