STM32 encoder mode sample rate

[lk.dgironi]

Hello,

I'm working on a STM32 project which use the timer in encoder mode.

TIM2 of my STM32F103C8 is set in Encoder Mode, I've enabled the TIM2 global interrupt.

I'm evaluating the counter at each interrupt.

Prescaler is 0, Counter Period is 65535.

Main clock is 72Mhz.

I've read the datasheet but it's not clear to me if the Counter Period in this mode is referred to the sampling rate of the encoder, or to the max Interrupt sampling rate.

I mean, If my motor encoder has a sampling output rate of 1KHz, do I need to set a Counter Period of 72Mhz/1KHz, or if i set higher than this the interrupt will "lose" some count, cause interrupt counter is 16bit (65536 count) but encoder output would be 72000000/1000 = 72000 count?

Thank you!

[waclawek.jan]

> I'm evaluating the counter at each interrupt.

Just don't, fullstop.

This is a very very bad idea for many reasons, one of them being interrupt latency.

And stop using the idiotic Cube/HAL nomenclature, that's just confusing. Read the RM and use nomenclature from therein. There's no Counter Period, you have TIMx_ARR register content. Use its maximum for encoder, TIM2 is a 32-bit counter, why would you want to cripple it down to 16 bits? Sample the encoder's value regularly, more often than it would roll over at the maximum ARR in your hardware. Sample it either in other timer's interrupt or in any other means.

Read the TIM chapter in RM.

JW

[lk.dgironi]

Thank you!

I confirm you I'm not full stopping, Evaluating for me means incrementing a 32bit unsigned variable with the content of __HAL_TIM_GET_COUNTER (i.e. timer counter), just this. My main logic is running separated from the interrupt in the a main loop.

Isn't TIM2 16 bit register by RM? (15.1 TIM2 to TIM5 introduction: The general-purpose timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.)

I've read RM but it's not clear to me this statement "Encoder interface mode acts simply as an external clock with direction selection. This means that the counter just counts continuously between 0 and the auto-reload value in the TIMx_ARR register (0 to ARR or ARR down to 0 depending on the direction)."

By Figure 93 seems that the counter clock is related to TI1 and TI2 (encoder) input, and that's fine and agree statement above.

If so, does it means the sample rate is defined by the internal hardware timing, switching time of internal mosfet and so?

My interrupt HAL_TIM_IC_CaptureCallback is called on input capture, I don't understand the calling rate, which in some way defines the sampling rate. What's the link with ARR?

[AScha.3]

>> it's not clear to me this statement "Encoder interface mode acts simply as..

ok, encoder mode is for motor with encoder on shaft ->

if stand still, value in counter is 0 and stays 0.

now turn forward, ...counter ie. go 11...43...112. stop. stay 112.

now turn backward 112...89..77. stop . 77 in counter.

so you now posution of motor very exactly; maybe your encoder has 120 counts per revolution,

then (when controlling a CNC ) you want exact 3.5 revolution forward, you drive the motor until you read 3.5 x 120 = 420 in counter . for example...

[lk.dgironi]

Thanks!

That's clear. What is not clear, like in Figure 93. What is not clear to me is, does it means the sample rate is defined by the internal hardware timing, switching time of internal mosfet and so?

Also does the interrupt HAL_TIM_IC_CaptureCallback is called on input capture, what's the calling rate?

[Uwe Bonnes]

There is no "encoder sampling rate". The encoder counts continuos and the count direction is determined by the polarity of the edges. There is no use of the input capture interrupt. Reread the reference manual section for the timer and perhaps the timer cookbook too.

[lk.dgironi]

Thanks!

That confirms me Figure 93, i.e. the counter clock is related to TI1 and TI2 (encoder).

So the maximum sampling rate is referred to hardware constraints (internal switching time of the PIN circuit).

In the HAL manual __weak void HAL_TIM_IC_CaptureCallback (TIM_HandleTypeDef *htim) is "Input Capture callback in non blocking mode.". That's why I though it's an input capture callback.

If there is not input capture interrupt, why is my interrupt function (HAL_TIM_IC_CaptureCallback) called each time there's a TI1+TI2 change? Note that Timer counter CNT could be as low as 1 when HAL_TIM_IC_CaptureCallback is called.

[waclawek.jan]

> My interrupt HAL_TIM_IC_CaptureCallback is called on input capture,

> I confirm you I'm not full stopping, Evaluating for me means incrementing a 32bit unsigned variable with the content of __HAL_TIM_GET_COUNTER (i.e. timer counter), just this. My main logic is running separated from the interrupt in the a main loop.

That is irrelevant.

As I've said, the main problem is interrupt latency (and the ISR execution duration). If the transitions are faster than that - and they may be, even if with unidirectional movement don't at the reversals or just due to vibrations close to decision point - you will both have the mcu choking from an inflow of interrupts and potentially missing some of them.

This may be not an issue in a particular application, but in other applications you may regret that decision at a later point. You've been warned.

> Isn't TIM2 16 bit register by RM? (15.1 TIM2 to TIM5 introduction: The general-purpose timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.)

Yes, you are right, I am wrong. (In most STM32, TIM2 and TIM5 are 32-bits, and until today I though this is the case with 'F1 too). Sorry for the confusion.

> If so, does it means the sample rate is defined by the internal hardware timing, switching time of internal mosfet and so?

No. Timers are synchronous, nothing in them changes faster than their internal clock, derived from APB clock (but may be not equal to the APB clock). The internal clock is what would increment the timer would it be not set to encoder mode.

In other words, timer samples its inputs by its internal clock, so the minimum period between two transitions which is guaranteed to be "seen" by the timer is given by the internal clock period. In yet another words, the maximum frequency of a 50% duty cycle input signal is half of the internal clock frequency.

In fact, the input channels are also subject to digital filtering, see TIMx_CCMRx.ICxF (and TIMx_CR1.CKD for the DTS clock divider) so that would also decrease the maximum input signal frequency; but by default these are set so that the sampling is at the internal clock frequency as described above.

> What's the link with ARR?

Absolutely none. ARR is important to know, how often you have to sample the CNT, and how to handle over/underflow exactly.

JW

[lk.dgironi]

Really thanks for clarifications.

> As I've said, the main problem is interrupt latency (and the ISR execution duration). If the transitions are faster than that...

That is why I'm doing the less i could in the ISR, just coping the CNT value to a 32 bit unsigned var. Up to now is working in my application, but I would like to check it with faster sensors (i.e faster encoder input)

>No. Timers are synchronous, nothing in them changes faster than their internal clock, derived from APB...

That's ok. By default they samples at a internal clock derived by APB. But in encoder mode

by Figure 93 of RM (https://www.st.com/resource/en/reference_manual/cd00171190-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf) seems that the counter clock is related to TI1 and TI2 (encoder) input, not to internal timer clock. The counter is clocked by each valid transition on TI1FP1 or TI2FP2. For this reason I thought the limit for the clock is by PIN hardware.

> Absolutely none. ARR is important to know...

That is the key point to me, if there is no link with ARR, the CudeIDE/HAL "Counter Period" setting, that set ARR is useless.

And also, what does trigger the interrupt function?

Sorry to bother your why dump questions.

[waclawek.jan]

> The counter is clocked by each valid transition on TI1FP1 or TI2FP2.

Yes. But those signals are not directly coming from pins, they are sampled by the internal clock.

> if there is no link with ARR, the CudeIDE/HAL "Counter Period" setting, that set ARR is useless

That's not entirely true. ARR does not determine the maximum input signal's frequency, but it does determine the point where counter will overflow/underflow. As I said earlier, that determines how often should you sample CNT. And I keep repeating, don't use the capture interrupt, use some means for periodic sampling of CNT independent from TIM2.

> And also, what does trigger the interrupt function?

That depends on what did you set in TIMx_DIER.

JW