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.

[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]

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

Anyway back to parking cars..

[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...