Why uwTick in HAL is uint32_t type?

[EAlek.11]

This simple question was interested by me for this reason: for uint32_t type uwTick can only count up to 4294967295 ms. It is only 49 days. In practivce it realy achievable value of or working time without reboot. In any applications it may be not enought. The HAL library may be more useful if user will can change uwTick type on CubeMX project level to uint64_t. Please can you add this feature in next releases?

P.S. I know that all STM32 have embedded RTC and it can obtain timebase for longer periods. But if the application is very simple, using of RTC will be overkill for it.

[TDK]

uint32_t is the natural and fastest integer type on the STM32. If you need more than 49 days, there are other options. I can't see it changing just to suit your own needs.

[Pavel A.]

By the way, this funny fact hints to the real meaning of the Pentecost. It is approx. 32-bit worth of milliseconds.

This is a hidden message from ancient aliens, or whoever invented it, to check for timer overflows.

[Tesla DeLorean]

Most people aren't using delay loops or timeouts lasting 49 days.

Simple unsigned math works across the wrap, and doesn't need 64-bit math.

The 64-bit math would add a lot of clutter to delays that typically need to be sub-second, and rarely into minutes.

You're in the distinct minority wanting to increase the code burden in this way.

If you need a 64-bit count, create one, it's hardly difficult, or have a second count. Call it u64LongTermTick.

[grzegorz]

Time keeping is not only about delays and loops, it's also storing current time. uwTick would be good to store milliseconds since 1970 so we can easily have UNIX time on STM32. And if you implement _gettimeofday(struct timeval * tp, struct timezone * tzp) syscall you can use standard time() and std::time() functions in your STM32 code. It is much simpler than RTC.

It's a pity that two of three replies here show very narrow look at this topic. OP's qustion is not bad. It would be good to consider changing uwTick to 64 bits. Please note that time_t was also changed from 32 bits to 64 bits. The only problem I see is that uint64_t is not atomic on STM32.

[LCE]

The SysTick is just not made for "long-time-keeping", it's a very CPU-efficient (32bit var increment) way of handling time within "typical CPU alive-time", like timeouts, task scheduling and so on.

And nobody keeps anybody from not using HAL, you're still free to change stuff.
Or use another timer. Or put in some other variables to count SysTick overflow.

So many options...

[Andrew Neil]

---

@grzegorz wrote:

Time keeping is not only about delays and loops.

---

Indeed - but uwTick is about delays & loops:

/** @defgroup HAL_Exported_Functions_Group1 Initialization and de-initialization Functions 
 * @brief Initialization and de-initialization functions
 *
@verbatim
 ===============================================================================
 ##### Initialization and de-initialization functions #####
 ===============================================================================
 [..] This section provides functions allowing to:
 (+) Initializes the Flash interface, the NVIC allocation and initial clock 
 configuration. It initializes the systick also when timeout is needed
 and the backup domain when enabled.

So, in choosing uint32_t, that would have been the key consideration

[Tesla DeLorean]

>OP's question is not bad.

Ok, but they asked WHY it was the way it is.

It's for arbitrary short delays, and it's not tied to any time-line or epoch.

I build stuff with the expectations it will be running 7/24/365, I'm not working for Boeing or Airbus..

https://www.reddit.com/r/todayilearned/comments/n96vi8/til_the_boeing_787_needs_to_be_rebooted_every_51/

https://forums.theregister.com/forum/all/2019/07/25/a350_power_cycle_software_bug_149_hours/

You can't being to imagine how many broken time and calendaring systems I've had to deal with over the years. Leap year handling tending to be the most profoundly broken. Or that execute slower and slower as the decades roll onward.

Anyone with a remote amount of situational awareness know short counts will wrap, and 32-bit / 1ms counts wrap within 50 days.

And frankly the biggest problem with clocking systems in MCU is getting the time/date setup, unless you can pull from GPS/GNSS or NTP

You can make long-counts if you want, the HAL is abstracted in a way you can do that.

But as you point out most of this isn't atomic, and an interrupt driven software count is readily blocked and perhaps not even viable in interrupt context or call-backs.

Accounting for time is undoubtedly an important topic, but just expanding the count is a very intellectually lazy method, one that would address a "functional safety" box checking exercise, but not explain why a system hangs for 4 millennia and then starts running normally again. Should be focusing of the code that cause s**t to fail in 49 days, or think a timeout of that scope has any place in the code base.

[Tesla DeLorean]

But Andrew, Andrew, I need a timeout that spans the entire time available in the universe and beyond..

Anyway back to parking cars..

[grzegorz]

Nobody asked for long delays. You are making classic straw man fallacy. Please don't post if you have nothing to say.