Why not replace Systick by hardware timer?

[ABaus]

Recently a thought popped up when I had a look through interrupt handlers (Using HAL):

As Systick handler gets called every millisecond (if not changed to something else) only to increase a counter, doesn't this unnecessarily waste valuable compute time?

We could just configure a hardware timer to increase every millisecond and replace HAL_GetTick() by a new function that just returns the timer value.

I have never heard of anything like that and searching on the web was unsuccessful as well.

Are there any problems I might have overlooked here?

Of course you would have to use a 32-bit timer, which there are not many thereof. However I usually have a spare one.

[Pavel A.]

First, the HAL timer is not always systick.

In FreeRTOS projects the HAL timer must be something else because FreeRTOS wants the systick for itself.

Yes, implementing HAL timer as you propose (32-bit TIM without interrupts) is possible, we did it in some projects.

-- pa

[TDK]

I use DWT->CYCCNT to control delays and measure durations in many of my projects. It works well.

The HAL SysTick related functions are weakly defined and can be redefined to set up whatever clock system you want.

[Tesla DeLorean]

It has been suggested here before. TIM2/TIM5 are 32-bit Timers on many STM32, but not ALL

Microsecond resolution might be easier on some platforms as the TIM prescaler is 16-bit on all platforms, so not going to get milliseconds on platforms clocking >65MHz

I don't trust ST to have all the timeouts/delays fully aware of different units of time.

I don't think a 1ms SysTick wastes a lot of time, and can do other house keeping, the real flaw is that interrupt priorities and use of the SW tick can fail in a blocking loop that is running at a higher priority. And why block in an interrupt/callback for multiple milli-seconds? Bad design and lack of user awareness, most don't grasp the need for brevity.